When people talk about tools in the context of software development, they usually refer to stuff like Integrated Development Editors, Automatic Build Systems, Testing Frameworks, Documentation Extractors, or other useful applications that makes their lives as developers easier. Those are all great and productive tools, but they are not the most valuable ones. What really makes an effective developer is the habits he or she possesses.
One such habit, that helps me tremendously in my work, is keeping personal logs. I keep all kinds of logs: a work diary, a solutions log, books I’ve read, ideas I’ve had, a success journal. Well, to be honest, the last one doesn’t have much content; probably because of my Swedish background. For us “modesty is a virtue” and that’s what’s holding me back. At least that’s what I tell myself. 😉
When I keep a journal I prefer a simple format. Usually word documents are sufficient, sometimes with a special header format that visually separates the notes. There are times when I use a Wiki, but since I prefer a chronological order I tend to go with simple documents. They are easier to move around, and with tools like Google Desktop Search there’s no need for firing up a database to hold my straggling thoughts.
I like to think of the solutions log as the bare minimum, something that every developer should have. Of all my journals that I keep, I value the solutions log most. This is because it’s the most useful one, but also the easiest one to update. Whenever I run into a problem that doesn’t have an obvious solution, I follow the same pattern:
- Search the Internet for a solution. Nine times out of ten this puts me right back on track within minutes.
- If I can’t find a solution on the Internet I ask a colleague.
- If a colleague can’t help me (this is also a nine out of ten-er), then I have to find the solution on my own. This is a tedious task. Good thing it doesn’t happen very often.
- I document the solution in my solutions log.
My solutions log have the form of Q&A. But instead of questions it has problems, and the answers are called solutions. My P&S (as I call it) have helped me many times, because problems have a tendency to resurface. When they do – often years later – I know where to look for a quick solution.
I’m also very fond of my book log. I read a lot of books and to keep a track of them I make short notes. I don’t write fully fledged reviews but small notes on how I found the book and what I learned from reading it. Whenever I come across a topic I know I’ve read about, I consult my book journal. The notes there work like triggers that bring back the memories of the subject.
This was the first post in my new series: Tools of The Effective Developer. If you have an idea you want to share of an invaluable tool, send me a comment and maybe I’ll add it to my Blog Post Ideas Log.