You probably all have been there. I am working on a certain code and something is not working. I know I have seen the error before, and I also know that I solved it before. But I cannot remember how I did it. What’s more frustrating is that I know that it cost me two hours of googling through various blogposts before I found the answer. I even bookmarked a site, but was it in Chrome, FF, IE that I made the bookmark? There’s quite a list of bookmarks, which one was it…?
I’ve tried lot’s of things, evernote, oneNote, mindmaps, wiki’s, etc. But I Always seem to fade away from these solutions when it’s crunch time. Is this solution working? Yes! Goto next issue. Basically I am to lazy and to unorganized for these solutions. Google is still my goto-guy for issues.
I am wondering how you are handeling these issues? Have you got an extensive library of patterns and solutions? How is it organized? How do you keep it up to date? Does anyone use the “answer your own question” feature of SO for this? How is that working? What to do with verbatim answers in blogposts?
8
Indeed, I can confirm these same problems in my work. Unfortunately, I cannot claim to have found the solution, but at least I’ve gotten to a point where it doesn’t bother me too much anymore. Here are a few ideas that help mitigating these problems:
-
As Basile mentioned in his comment, it is important to leave the URLs as comments for all sorts of codes that you had to lookup elsewhere. Note however, that these places are quite rare. You cannot just copy blog post code into production code (legal issues alone should stop you there, quality and other such arguments are up next). So most of the times, it is more like a nifty idea, which is explained in more depth in said blog post or stackoverflow answer. This also ties in with the next point, so in practice, these comments help even less.
-
DRY. Breath it. Live it. Do not repeat yourself! When you realize the new functionality you’re working on is similar to something else, then you have to look it up and eliminate any duplication as good as you can. In the long run, this severely limits the number of places in your code that you would have to look for.
-
The probably most important and easy way to handle this though is to outsource it. Not to some other country, but to your team members! When you come up with that cool new pattern – go tell someone about it! Never ever keep it to yourself, because then you are the one who has to remember it. If you see someone writing an Anti-pattern – tell them, don’t just fix the problem! In addition to transfering your knowledge to team members, reviews help you to profit from your previously outsourced knowledge. People also have diverse skillsets. Some have a freaking good memory. Often times more accurate and faster than google, because they have full knowledge of your project. Make use of that! It’s a win-win for everyone in the team.
-
Issue tracking with traceability is particularly helpful in dealing with errors. If you have an issue from the last time you have dealt with this error, then your issue tracking system should be able to find it for you (from a stacktrace, error message, whatever – but it must be in the ticket description in some way of course). Next comes traceability, i.e. given your ticket you should have a way to quickly find the part of your code that dealt with that problem the first time. Not a lot of google or blog-reading left really. This also ties in with version control, since you can rather quickly find the corresponding changeset when you know the part of the code (“blame” it), or when your commits are referencing the issue number.