One of the things I miss with being a programmer that you can look back on a day and see stuff that has been done. Or, better yet, when you know a bunch of code that you’re going to write but haven’t written it yet. I kind of like that feeling.
Nowadays I often have a really hard time looking back on a day and point to something that I have achieved (other than conversations and if I’m lucky some new realizations). And before I start my day there’s just a bunch of meetings to be had. Nothing concrete.
Ok ok - this post was about one particular practice, I often used when I coded, that I got reminded of the other day. And that I now tried to get that idea into my ordinary schedule. So far it’s been very useful.
I was listening to the (Swedish) podcast Väg 74, in particular the great episode with my friend Staffan Nöteberg. Staffan has an aura of calmness, purpose and being thought through. I always learn new things from him.
In this episode they talked about Mono-tasking, which is well beyond the scope of this post but very cool. Check it out!
Briefly the mentioned that doing and planning are two different modes in our brain and that it requires some effort to switch between them. That’s why, I think, it feels good to have a bunch of work (as the code not yet written I mentioned) to do and then just do it. Not knowing what to pick up is a bit harder and require another perspective and effort.
In particular it can be hard to start your days with a clean sheet of nothingness. Now you need to prioritise and sort before you can work. It feels a little bit cumbersome and can be hard to kick you into the day.
What did I do yesterday? What is most important of all those things? Questions like that might not be perfect to kick the day off with.
As a programmer there’s a little trick that you can use to get by this problem: leave a failing test. That is, just before you go home you write a test that shows how the next little piece of functionality will work once it’s done. It fails, of course, since you have not implemented that yet.
In the morning when you come back you run all the tests and this test is failing, pointing you right into the place where you left of and you get into the working mode again. It’s a lovely practice, even though it feels a bit backwards at first.
But I’m not programming (anymore)
It was at this point in the podcast that I got the programmer blues. I miss that feeling of knowing what is next.
Now I come into the office, have a look at my meetings and then device a plan for this day. The plan for the day practice is something that I picked up with my current client. It’s a good idea, since it helps me to structure the day a bit. But I still have a hard time to kick the day off with that, because I rather start working.
For the last week I tried a very simple little trick that seems to help; I create the plan for the day mid-day or afternoon. That means that I will have stuff still on my agenda, waiting for me as I get back.
Instead of doing 8-16 days (in my planning), I now do 13-12 days. As I come into the office I have a few things to pick up, or continue will.
I’ve found that this helps me to get into the day and my work in a better way. I hope that you find it useful to.