Stop Starting and Start Finishing

One thing that I’ve always struggled with is a short attention span; I tend to get bored pretty easily. One thing I like about my current job is that I get to work on a lot of different stuff, which helps keep me interested, but it’s still difficult to maintain focus, and I’ve been looking into different systems to help with that. Earlier this month my son was born, which is awesome but means I have less time and energy, more expenses, and less income (due to my wife staying home to take care of the baby), which adds that much more pressure to try to be really good at my job.

One of the things I tried last year was KanbanFlow, which is a free (and paid, though I haven’t felt the need for the paid features) tool for tracking your work; I liked the ease of use but didn’t really feel that I was getting that much out of it and more or less stopped using it. Recently, however, I’ve been reading the book Kanban in Action, which clarified for me what I should be doing, and I’ve started using my Kanban board again. I’m actually feeling more productive, so I thought I’d document what I’ve been doing.

My Kanban board is set up like this:

Screen shot of the top of my Kanban board
My Kanban board as of this morning.

One of the big things in Kanban is the Work in Progress (WIP) limit; the idea being that if you limit how much work you (or your team) can take on at any one time, then each piece of work flows through the process more quickly. This leads to less work overall, because any issues get found more quickly, before you have a chance to forget the details of what you’ve been working on. By limiting how many balls you have in the air at any given time, you also reduce the number of context switches you need to make, which helps you to be more efficient. In this case, you can see that my “In progress” column – the things that I’m actively working on – has a limit of three items; once that’s full, I can’t start working on anything else until I’ve moved something out of that column. Or as the book says – stop starting, start finishing!

My process here is to start the week by making all the decisions about what to work on and put those things on the to-do list in rough order of priority. At the start of the day, I can move a day’s worth of work over to the “Do today” column (under anything that might be left over from the day before); as things move off my “In progress” list, new items get pulled in from the top of “Do today”. Once I’m done with development that someone else needs to look at, it moves to “Waiting on someone else”; when it comes back it goes back into my “Do today” column. Any new tasks that come in can go into any of the first three columns or simply thrown on the backlog, depending on urgency; a customer issue will be worked on immediately but anything else needs to wait until the current task is complete.

Pretty straightforward so far, right? Even if I’m bored with working on something, it still needs to get done so I can move it out of the “In progress” column, and I need to stay on task to be able to clear out the “Do today” column. This brings us to the next part, the pomodoro timer:

Screenshot of the pomodoro timer

The pomodoro technique works with the understanding that it’s extremely difficult to stay focused for long periods of time, and that our brains need to rest every so often. Thus, you work for a timed 25 minutes and then get a 5 minute break to walk around, visit the restroom, check Facebook, whatever. The timer here lets you select the task you’re working on, so you can use it to keep track of how much time you’ve spent on each task. Meanwhile, it’s easier to stay focused because you know there’s a clock ticking down and you just have to stay on task for a little while longer before you can take a break. When the pomodoro ends, you’ll be asked if you stayed on task, if so, you get rewarded with FlowPoints. It’s a simple motivational system, but it seems to work.

Another technique is to break up those tasks that require the most decision making, so we’re not constantly making demands on the same part of the brain. Do the important development first, before spending time answering emails. Put in some mindless tasks, like filling out time cards and walking to meetings, in between heavy programming sessions.

On Writing [and Editing]

Warning: rant ahead.

Probably most software developers have at least heard of Donald Knuth’s The Art of Computer Programming. Supposedly a 12-chapter book in seven volumes, the first volume was published in 1968 and we’re now partway through volume four (the fifth portion thereof expected to release in June). I’ve never read a significant amount of the work, but over the years I’ve occasionally dipped into it when researching a particular topic; it’s written as a reference book, and it works well for that.

I bring up these books not because they are particularly readable (they’re universally acknowledged as being quite dense, and very few people even claim to have read through them) or because of the speed with which they were written (although spending half a century on one project is impressive!) but because of Knuth’s dedication to getting the work exactly right. Aside from spending an astonishing amount of time on each book, he has long offered a reward of one hexadecimal dollar ($2.56) to anyone finding an error (including typos).

"Spellcheck" misspelled, with red underline

Most of us, of course, can’t put in that kind of effort (or time) to our writing. We (hopefully) have something to say, but there’s always the pressure to get it out there quickly and move on to the next project. I’ve seen more than a few programming blog posts that looked like they covered interesting material, but the writing was so bad that it wasn’t worth the effort to puzzle out what they were trying to say. (To be fair, many programmers have a first language other than English and deserve some leeway there). Books are even worse, due to the greater investment; I’ve given up on more than a few books due to the number of typos in the first chapter. Technical books, fortunately, seem to be better edited than most, but are by no means exempt from this problem.

Writing is meant to be read; make sure yours can be. If blog posts must be written quickly, consider cutting down on the number posted so as to take more care with each. When writing a more significant work, hire a good editor. My first book took only three weekends to write, but it was only 26 pages (of non-technical material) and still went through a round of editing before being published. I expect the book I’m working on now (which will be more technical) to take over a year to write and require several editors to make sure both the content and the language are correct. It still won’t be perfect; errors inevitably slip through no matter how many times you proofread (I’m still irritated over the one error I’m aware of in a graphic in my dissertation). But a focus on quality reflects well on you, and makes things easier for your readers.

I’m interested in what you have to say. Make it easy for me to hear it.

Roles, titles, and growing into expectations

Last week, I found out that I’ve been promoted to senior developer. From a practical standpoint, this doesn’t actually affect me at all; the titles system was put into place to deal with immigration requirements, and the ‘promotion’ doesn’t signify a change in my responsibilities or compensation. In fact, this actually happened over a month ago; it’s just of so little import that nobody bothered to tell me about it!

Still, this seems as good a time as any to reflect on where my career has been going, where I’d like it to go in the future, and what I need to do in order to get there.

Over the last year I’ve spent less time working on code (although that’s still what I’m usually doing) and more time doing project management-type activities: setting priorities, writing designs, explaining things and providing feedback to other developers. I’ve said in the past that I’m not interested in become a team lead (partially because I want to focus on becoming a better developer and partially because I don’t want to spend all day in meetings) but I find that I actually do enjoy overseeing a project.

I’m now feeling that I’d like to move into more of a software architect role. I’ve seen this defined as the person who takes the blame for the quality of the software; he sets the overall direction for the project. For the project that I’ve been overseeing, I’ve worked to set standards that everyone working on the project follows, and the result is code that’s much easier to work with; I actually feel that my biggest contribution to the company will be how much easier it will be to make updates to my team’s part of the software in the future.

So what do I need to do for this?

On the interpersonal side, pretty much every job I’ve ever had has involved me being in a leadership role, one way or another, so I have no issues with that and I enjoy helping the other developers; my only real challenge in this area is that I’m hard of hearing and many of the other developers have accents, so face to face meetings are challenging for me. Unfortunately that’s not really anything I can change; all I can do is work around it.

On the technical side, I feel like my largest challenge is in testing; when I’m doing PQA (programmer quality assurance) on other people’s code (or even my own) I don’t feel that I’m catching as many issues as I would like. So that’s something for me to focus on this year: improving my testing skills. Interestingly enough, this area is also one of my strengths; since I have a bit of an unusual background (teaching and editing) I do tend to catch different problems than the other developers. So my technical goal for this year is to improve my testing process. What I’m going to try to make time for is to go back and look at development I’ve touched where a bug got through, and see if that’s something I could have caught. If it is, maybe I can add something to my testing checklist so that kind of bug doesn’t get by me the next time.

In other words – I need to discover new steps I can take to improve my work and refine my processes to include those steps, playing architect on a small scale. The better the process – assuming it’s followed – the better the end result. What processes can you improve this year?

The daily accomplishment, or, did I get anything done today?

Today I installed a new faucet.

Not a big deal – I’ve done it before and it’s not that difficult, just a bit of a pain (and hard on my back). But I’m still counting it as my accomplishment for the day.

When I was a kid, I always planned to get stuff done over the summer – learn Java or whatever – but more often than not it didn’t happen. When your primary focus is on big projects, it’s easy to have days when you’re not seeing any progress, or worse, actually not making any progress. I had that problem with my dissertation – it was so involved that it was difficult to sit down and write out the next lemma. I have that problem still; I’m working on a new book, but it’s such a large project that it’s difficult to just work on a small part of it.

It’s no secret that the way to get a big thing done is to break it into a lot of little things; sometimes it’s just hard to work up the motivation to do the little things. What I’m trying this year is simple: at the end of every day, I want to be able to look back and say that I accomplished at least one thing. If it’s getting towards the end of the day and there’s no sense of accomplishment yet, well, that should be my kick to keep going until I have something.

Thursday it was finishing off a decent-sized piece of functionality I’ve been working on. Today it was replacing a faucet and writing a blog post. I don’t even remember what it was the other days, but I do remember that there was something – even if small – each day of the year thus far that made me feel that, that day, I had accomplished SOMETHING.

And when you keep accomplishing little things? Maybe it helps you find the motivation to get the big things done.

Now, about that book…