By Bob Walsh and Matt Cornell
(Note: Matt Cornell – programmer, personal productivity coach, blogger and all round good guy and I are teaming up for a weekly series of blog postings here and at Matt’s blog, http://ideamatt.blogspot.com on how programmers can be much more productive. Our goal is combine our experience, ideas, knowledge and a few bad puns to give you, our fellow programmers, a personal productivity toolkit of ideas and best practices.
If you’ve been working as a programmer for more than a few years, a lot of our Productivity for Programmers tips will sound familiar. But there’s a world of difference – like the difference between being the programmer you want to be and being unemployed – between knowledge and action. These posts are going to be all about action.
Another way to describe what we’re trying to do for you is give you a set of tools, practices, attitudes and viewpoints that will make you outsource-proof, whether you work in Boise, Idaho or Bangalore, India. We submit that wherever you are in the analog world, your ability to survive and prosper as a programmer means finding and using the physical, mental, emotional and even philosophical tools we will be covering. Brutally put, given your replacement is a click away, how are you dramatically increase your Internet Price? We hope by implementing, not just reading, about the productivity tools we’re going to recommend in this series.
One more quick point before we get to the good stuff: whether you are Joe Java, Navashen the .NET head or Doug the Delphi guy, these techniques and best practices apply. That goes double for whatever software development methodology you’re into (or stuck with), your age, or if you plan to use this toolkit to start and grow your micro-ISV software startup or to become the Reigning Programmer God in your enterprise’s IT department. It’s all good, and it is all up to you!).
Trusted Systems (yours, not theirs)

In this first part of Productivity for Programmers, I’d like to focus on five trusted systems every programmer needs and should have: Tasks, Decisions, Version Control, Code Snippets and Bugs. While covering these five topics in detail would take a good chunk of a book (I know, I wrote one on this and more J), I think what’s more important is focusing on key affordances and characteristics of each of these systems so that they do in fact deliver increased productivity.
By trusted system, I mean a system you – not your boss, not fate, not anyone – owns and controls which captures 100% of its problem domain in a way you can rely on day in and day out. A system that you cannot rely on is worse than no system, be it the apps you develop or the methods you use to maintain and improve your productivity.
In fact, that you have a system that you can trust is far more important whether you write it yourself or go Open Source, it exists on your desktop or is a Web 2.0 app in the Internet Cloud, you buy it from a from a micro-ISV or whoever: It has to work for you and you will need to be able to trust it.
The Trusted Tasks system.

This is the biggie. Given the complexity, massive information loads and the sheer number of technologies involved in being a programmer today, if you don’t have a leakproof system for capturing, tracking and processing at least all of your work tasks, you’re somebody else’s roadkill in this globalized economy. (If you think that statement applies to non-programmers too, I think you’d be right).
Here’s why: no matter whether you’re a first year CS major or can write OS’s in your head for fun, you mind can only deal with x amount of information at any one time. We’ve all experienced trying to write a piece of difficult code that just was too complex to get a grip on, only to find that a few hours or days later it was suddenly doable. What changed? You mind did. Having a trusted tasks system offloads a huge number of distractions, tangents and irrelevancies to the one thing you are doing at any given time. This is a good thing.
There’s two components to a trusted Tasks system: the physical means of collecting and storing future tasks other than your head and the mental habits, practices, insights and knowledge that you need in your head to operate your system. While there have been many people over the years with gifted insights as to how to manage tasks, one man stands above the rest in our opinion: David Allen, creator of the Getting Things Done methodology. GTD works, and it works extremely well for programmers.
If you’re not familiar with GTD, this Wikipedia article, this Squidoo lens and of course David Allen’s seminal Getting Things Done: a Guide to Stress Free Productivity are great ways to start. GTD has a lot of parallels with martial arts: the basic moves are simple, but the power comes from combining, integrating, internalizing those moves and the more you learn, the more you realize you can go deeper and learn more and gain more. I’d like to think my blog at http://ToDoOrElse.com will help, but I know Matt’s blog at http://ideamatt.blogspot.com/ will help.
Let’s look at the physical component of a trusted task system for a moment. [disclaimer: I sell such an app, and am developing the next generation of the same.]. Whether you implement GTD on paper, in a desktop app, in a web app or some entirely different way your trusted tasks system needs a minimum of three characteristics to work:

  • It must be extremely fast and easy to collect all tasks into it.
  • It must be extremely fast and easy to manage those tasks so that you can work on the correct task at any time.
  • You must be able to trust your system, and that your system will be there tomorrow.

The fact is these three characteristics are required for each of these trusted systems.
There is no single one “right” physical GTD system, anymore there is any one “right” piece of music. The question you’ll need to answer is which tool or tools works best for you, giving you the best set of tradeoffs for your circumstances. Here’s a very partial list of GTD systems – you’ll find a lot more both at Merlin Mann’s 43folders.com’s wiki and Listable.com’s list of GTD software.
Paper: D*I*Y Planner, Moleskines, Next Action Cards, paper.
Windows: the “official” Getting Things Done Outlook Add-In, MyLifeOrganized, Thinking Rock, Monkey GTD, FusionDesk, MasterList Professional
Mac: Kinkless GTD, Ghostaction, Thinking Rock, Monkey GTD
Linux: Thinking Rock, Monkey GTD, Tomboy
Web: Tracks, Basecamp, Ta-da Lists, Vitalist, MyToDos
Decisions, Decisions

Whew! Even just scratching the surface of the first trusted system above took over 1,100 words; I promise to be more concise on the other 4 trusted systems.
Creating programs is about making decisions, large and small. From what kind of app will you create and sell to how to implement a 200 page spec, to how to code a single button, you are in the business of making decisions.
But are you remembering the decisions you make? That’s where decision logs come in. The idea is simple: keep a running chronological list of the decisions you make for each non-trivial, for money or important to you app you write. Document the Whys – why did you leave this feature out? Why did you use SOAP not REST? Why did decide to persist data in XML? Because you will forget.
Decision Logs persist the logic, arguments, assumptions and tradeoffs that predicate your code.
It’s up to you how detailed, crossindexed or comprehensive each decision log will be and whether it’s kept on paper, in a text file, in a wiki, in a private blog, etc. etc. At one time or another I’ve used all of those, including the archetype lab book. They all work, and they all set you above all the programmers who don’t keep decision logs.
There’s one more Decision Log I’d recommend keeping: your own personal IT Decision Log. Whether you sit at a desk where The Company has your box locked down tight, or you’ve got your own business and have more computers than close friends, you want one log where you maintain your backup procedures, what software you have installed and where the registration keys are and all the other key info bits you need to keep your end of the global IT infrastructure running right.
Version Control = safe sex for programmers

I know, you’ve heard it before: the horror stories of projects erased without recourse, the importance of having a safe place for your code and all the rest. The fact of the matter for most programmers is unless the people who sign your paycheck have put a system in place and enforce using it, you don’t do version control because they are too fracking busy to bother with it.
Well, get over it. It’s your neck on the chopping block if you dev box’s hard drive start sounding like a garbage disposal. You are professional programmer, and you are supposed to know this stuff. The good news is that modern (read not Visual SourceSafe) version control systems like Subversion, Vault and Perforce to name three can with very little effort give code a basic safety net. What’s more, whether you’re a full time salaried programmer for some company, a contract programmer, an independent developer or a micro-ISV all three of those version control systems can be implemented for a single programmer for free.
There’s two catches with version control: you’d better make sure on a scheduled basis that your code repository is getting backed up and you can drown in a quicksand pool of version control complexity specific to that program very quickly. My recommendation? Have a look at all three contenders, pick one to implement, log your implementation decisions/key info in your IT System Decision Log, resist the urge to dive deep and get back to coding.
My Invisible Friend – Code Snippets

The fourth trusted system a productive programmer needs is a nice warm secure place where all your favorite blocks of code can go to live and be happy. Again – except for the poor guys who still work for paranoid companies – a trusted system for capturing, classifying and reusing bright and shiny bits of code is a must.
Code snippets can both abstract out of your daily worklife repetitious tasks like coding CRUD and be a treasured place for you best routines, classes, objects and whatevers – the one’s you’re really proud of, or you learned from, or you don’t want to have to reinvent or all three.
And again, it’s entirely your choice whether you write it yourself, keep it in your IDE or keep it simple with an app like AX Tools Source+. I would suggest one thing to make sure your trusted code snippet system can do, and that’s move. Move to a new box, move with you when you change jobs, contracts or clients, even move to a new IDE. Because that day will come and your code snippets library is your personal institutional memory.
Your Trusted Bug System

Now this one might surprise you – you probably thought I meant the list of open bugs you need to fix, or a bug/request tracking system like Fogbugz. Nope. Yes, you need one of those too, but I’m talking about a different kind of bug tracking system: What’s your system for identifying, checking for and correcting bugs you consistently create? In the same way everyone who writes for a living has a set of misspelled words, ungrammatical phrases and misused words (top of my list? its/it’s), you need a trusted system to track the code writing errors you most frequently make. Why? Because until you do you’re not being honest with yourself and the penalty for that dishonesty is to keep making those same dunderheaded errors. Duh!
Like the other four trusted systems, the implementation details are far less important than implementing something you can refer to as the first thing you check for when your code breaks and you don’t know why. It can be a handwritten list, a set of index cards, a full blown database, part of some other system, whatever. The key thing to look for are patterns of mistakes in your code or design.
No programmer likes making or admitting to mistakes – that’s been the emotional wellspring of every programming methodology and silver bullet that’s come down the pike since this profession got started. But the payoff of paying attention to what you don’t do right is you get better at it and make fewer mistakes (or at least new, interesting ones J). And that’s a fair approximation what the difference between professionals and amateurs.
The Takeaway

Matt Cornell and I have started a weekly series on productivity for programmers, be they micro-ISVs, independent developers or salaried employees. To start with, there are five information systems a productive programmer should have: Tasks, Decisions,
Version Control, Code Snippets and Bugs. These systems have three things in common:

  • They are the one place you look for the information they house,
  • They are implemented in whatever software or physical form that works for you, today and in the future,
  • You can trust these systems with your hard-earned knowledge.

Action Tasks for you:

  1. Which of these five systems don’t you have?
  2. Schedule time to go shopping on the net for same.
  3. Implement one system, run it for at least 21 business days with daily reminders to yourself that you are now using this system. Tune, adjust and proceed.
  4. Loop.

Onward and Upward

That’s it for this first Productivity for Programmers post – next week Matt will be lead writing and I’ll be the back seat driver. Please add your comments, send us your feedback and to paraphrase the late Hunter Thompson, when the going gets tough, the tough become productive pros!
[tags]Productivity4Programmers[/tags]

2 Comments

  1. Good post! We already use Subversion for version control and Trac for bug tracking, but it seems that we will start using Trac as decision log too!
    I really like the idea for decisions log, because from time to time the customers want you to change something, you say “well, why not” and when the version is out, other customers start complaining for the change. Than you realize why you decided to make this feature work the way it was 🙂

  2. Pingback: #doesNotUnderstand:

Write A Comment