Tag Info

Hot answers tagged

57

Forgetting things is normal. Not remembering some tricks that helped you in the past is also normal. This is the first step one should acknowledge. Then there are some ways you can "store" knowledge for further revision: Find time and blog about it. The future-you will be very thankful to the present-you; Work with tiny demos and archive them in some way. ...


45

Direct answer to your question: Yes. Wikipedia has tons of non-IT editors. Longer answer: Your IT vs non-IT distinction here is a red herring. All people, IT or not, will still ignore a wiki if it isn't presented to them as something they should care about. Introducing a new data management system is always non-trivial to sell to people because you always ...


17

My key is Variety Repetition. Once can be fleeting. Seeing the 100th occurrence makes a difference! Memory by fingers. I remember code much better when I've actually typed it a few times. Code Library - Keep a personal stash of code and tricks you have used and seen. Centralization. I keep 1 file with all my usernames (hundreds) on 1 pc. I apply ...


12

One thing I'd try would be to try this: Pair up people in the first group with people in the second, Information is exchanged within the pairs from the first group people to the second group people. The people in the second group document their new found knowledge, The documents are then verified by the people in the first group. If there are errors, then ...


12

You might want to ask around about why they don't use it. And you might need to probe beyond the surface, non-thinking, "because I didn't think of it" answer. For example - I've been in situations where I used email instead of an internal wiki because: The wiki was really hard to use, and too time consuming to maintain - especially in terms of cross ...


11

Is WIKI really appropriate to store document for software development? Instead of writing docs, pdfs and other kind of files, why don't you unleash the WIKI's full potential as a collaboration tool? You can write your documents there, attach your diagrams and even better: if you use Fitnesse, you can turn your wiki pages into really useful and living ...


11

It depends on the wiki software. Generally non-IT people will prefer a wiki with a WYSIWYG editor and might not like wikis which require any kind of markup editing, even if the markup is very simple. For your bonus question: MediaWiki does not provide a native WYSIWYG editor. You can see which ones do in Comparison of wiki software.


9

I use TiddlyWiki a single html file wiki with lots of plugin possibilities, it combines great with dropbox. The getting things plugin makes it into a great tool for managing personal projects.. And as such i use it for current projects, little things I need to remember server names who knows what internal sites hour codes to book hours. ...


9

When I join a new company, it usually fills up with: Remote desktop / VM names. Folder paths for project documentation. SQL scripts for common fixes/cleanups in data. Common web-service end points / WSDL locations (I know you SOA guys...UDDI ;)) URL's to time sheet systems, bug tracking systems etc.


9

Don't focus too much on getting a perfect structure up front, better let it grow organically. It's the communication culture and process that matter. Below are some tips to maintain team wiki. fundamentals value feedback Ask for, collect and record any feedback you can get - mail, wiki page comments (most convenient btw), messenger, conversation. ...


8

Yes, that's sound a good solution, if you organize the page in a simple structure, easy to browse. Choose a wiki with a simple syntax. ( Dokuwiki is a simple one and not require a DB ) Edit: if you use a version control system, that is SVN or BZR, try Trac, where you can define milestone, keeping bug and features request, and define your own workflow to ...


8

Since multiple answers point to Trac as a suggestion I'd like to suggest a similar, but better in my opinion, alternative: Redmine. Redmine is a project management solution, including Wiki, Document Repository and version control integration. It's also written in Ruby on Rails and way easier to extend and hack than Trac, in my experience. More than ...


7

Having all documentation in one system instead of two can be a real advantage. Things like backup & restore, versioning, global search, global search&replace, cross-linking, and, as you wrote, putting all docs in one final document, will typically work with less "friction" when you don't have to maintain two different systems with overlapping ...


6

Typical scenario: customer says "Hey, this doesn't work anymore". I spend half a day finding a solution, and tell the customer what to do. One year later, another customer (or possibly the same one, of course) asks the exact same question. No way I can remember the complete solution after a year, so I effectively lose half a day looking for the exact same ...


6

In my organization, we have a very successful wiki implementation. It is based on MoinMoin, which is a Python wiki package. To make it successful, however, it took years of dedication in staff training and singing its praises. For an organization of around 80 full-time employees, I had to hold a number of beginning and advanced training sessions, plus spend ...


6

We're using LaTeX and SVN. Since LaTeX documents are just text files, it plays well with version control, unlike some binary or partially-binary formats. You get all the advantages (and disadvantages, admittedly) of version control you're used to from using it with your code. LaTeX takes a little setting up (to define your own styles/class), but once ...


6

Over the last year Evernote became a program I could not do without.I copy everything into Evernote. Code Snippeds, Screenshoots, Contact data, Version History and so on. So I don't have to remember so much details. I just know it's in there somewhere. The basic version is free. So try it!


5

I think that a wiki can be a great approach to the organizational problem you're facing. I also believe that non-technically oriented users are very capable of learning the wiki features with some caveats. I agree wholeheartedly with the comment about user acceptance being vital. You are more likely to face the "I'm not going to use it" or "It's just ...


5

Sherlock Holmes once said something like "A man's mind is like an attic. If you fill it up with trivialities, there is no room for anything truly important. For all of these details, we have the encyclopedia." Unless you have a photographic memory, and the problems therein, you won't remember everything. Build a set of resources, a personal library of both ...


5

Two types of answer Pessimistic view Corporate ordinary employee is lazy, passive, lowbrow executor, not interested in quality work, only in quantity. If he know Office, he haven't interest to know and use more Realistic view Contrary to code, historical aspects of "active" documents have a lot less value - every time only "now state" make sense in ...


4

Yes, wikipedia proved it. It require users to comply anyway, which isn't always easy, even if it is in their interest. People will resist to change.


4

Personally, I really like Tiddly Wiki. It has a pretty complete wiki syntax, is a self contained single html file and works well with a variety of web browsers without the need for a server. It even has an extensible plugin architecture which allows you to add plugins to do all sorts of interesting things like encrypting tiddlers or adding footnotes.


4

There are various "single source" solutions for documentation out there. A number of teams I've worked with have had great success with Madcap Flare. I especially like how it integrates well with source control and provides support for creating context-sensitive help. Full disclosure: I have NO relationship with Madcap, not even as a reseller. But I have ...


4

Well, maybe my case is particular ... but : I have every scrap of software i wrote since 76 on my laptop, programs, scripts, configurations, etc. So over time (must confess), my memory burden has shifted from remembering 'stuff' to remembering meta-data about stuff. Sure, a lot of it is not relevant anymore, but what i find that the hard part is having the ...


4

Like others, I keep track of things using bookmarks. I used to use Delicious, but have now moved to Pinboard. But I don't use this way as much as I used to. It seems like every programming problem I come across is a small google search away. And in the last year or so, I've started using Stackoverflow as one of my search terms! Whenever I come acoss a SO ...


4

First, it is important to choose a good Wiki. Choose one that: Is well maintained and has good support. Supports user authentication and has access control on documents or namespaces. Tracks changes to documents and provides a history. Allows E-mail notification of document changes. Has a good editor, preferably WYSIWYG, and supports lists, tables and ...


4

Whenever possible, reduce or eliminate the need for documentation by writing clearly understandable code instead of writing documentation to explain obtuse code. Keep the documentation as close as possible to the actual code it describes. In most cases, that means putting the documentation in the code itself. Some development platforms (e.g. Visual Studio) ...


3

It makes sense to store the documentation in the same repository as the source code. Sphinx seems like a good option to me. it takes reStructuredText files as input, which is easy to edit and diff it generates hyperlinked output (HTML, PDF, ...) you can reference your source code (Python, C, C++, JavaScript)



Only top voted, non community-wiki answers of a minimum length are eligible