Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I'm trying to bring more structure in my worklife by trying to maintain my 'knowledge' of new techniques/bugfixes/workarounds. I find them on google (sometimes after a while of searching) and fix my bug/learn new stuff...

I don't really expand my 'library' with this knowledge. So after a while, when I encounter the same bug, i need to search it again and this can be time intensive.

How do you guys keep track of this knowledge? I mean, most of us are on a busy workplace, with no time to memerize every bugfix/piece of knowledge about a product/language. I want to be able to reference this information in my own library. While trying to keep links, texts and code snippets organized and maintainable, rather then a textfile/Evernote for each subject, making it almost impossible to find and organize this information...

share|improve this question

marked as duplicate by durron597, Snowman, Bart van Ingen Schenau, jwenting, gnat May 8 at 9:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Possibly related: stackoverflow.com/questions/5103177/… –  Michael Kjörling Dec 16 '11 at 9:47

4 Answers 4

up vote 5 down vote accepted

You know, I used to worry about that kind of stuff. But here's the cool thing. When you're in the field long enough, you begin seeing patterns everywhere, even with your bugs. After you get some real experience it's no longer about memorization, but simply recognizing a recurring pattern. So there's a little bit of problem solving most of the time (even when you've encountered something before), but you always know where to start, and what "feels" like a false lead. In other words, my only guide is pure intuition (oh and I guess Google gets a pretty good workout too). So my best advice is MAKE A TON OF MISTAKES. It all starts to come together.

And if that doesn't work, just make your own wiki or something. Oh and drink caffeine, that always makes recall easier for me :)

share|improve this answer
Thanks, and I feel like that's working for me most of the time, but I'm talking about edge-cases. The bugs that are recurrent (once in a year stuff, which I can't seem to memorize because of my current workload). So wiki is actually a good way to go? –  Rickjaah Dec 16 '11 at 9:38
Yeah I keep one for the rare things that need precise documentation. It's not fancy and it's certainly not well laid-out, but the search function is all I really need anyway. It's just a stock mediawiki install. –  Chris Dec 16 '11 at 9:44
+1 for the combination of patterns and a wiki. –  Michael Kjörling Dec 16 '11 at 9:48

Setup a solutions log like these ones:



If you make them public, Google may find your own entry again if you are searching for it.

share|improve this answer

You might set up a wiki for techniques/bugfixes/workarounds of 3rd party products, so everyone gets to reference the same information and contribute to it. This way links, texts and code snippets could be coherently accessed. As for bugfixes/workarounds for your source code, I cannot exactly follow the need for memorization. I think once I'm able to recognize a problem, I should be able to solve it. For techniques or patterns, you might try if you can put them into a reusable library.

share|improve this answer
Think bigger, think: A junior developer writing a Web Part for use in Sharepoint 2010(first time use of it). Using different services in Sharepoint, which each have their own deploy and customization settings. And having no assigned time to actually get into Sharepoint and all of it's bugs. –  Rickjaah Dec 16 '11 at 9:40
Given the context, I recognize your pain..I don't have a better suggestion than keeping a wiki though, sorry.. –  henginy Dec 16 '11 at 11:39

For bugs specifically, one solution that nobody has mentioned yet is to have each bug fix in its own commit, and to give the commits meaningful names: that way you can just search your commit history. I also find that if I have a vague idea which file/project the bug occurred in, I can go and check out that specific commit history.

I also have a micro wiki with some of the really rare and really awkward workarounds.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.