Make it easy to write objectives

I have never worked with a software developer who enjoyed writing their quarterly or annual objectives.

Most had been previously burned out by laborious processes which either meant two objectives take hours to write, or they’re easy to write but vague enough that they take hours to evidence every 3 months. In some cases they’ve even had objectives in which they had no say because they were either handed to them directly by a line manager, or had “trickled down” from group or org OKRs.

My thoughts on this were triggered by Matt Jukes’ post about his feelings on OKRs, which I share. 

I have helped set objectives for dozens of developers in multiple organisations in the last 10 years. My own goals when doing this are:

  1. Try to make the process as painless as possible
  2. Try to align the objectives with what a developer wants to be doing – if possible work with them before the session so they can create some draft objectives of their own
  3. Don’t set more than three objectives for a quarter
  4. Make each objective SMART – you want to be able to look at it and say “yes this is done” or “no, this is not done” in clear terms. If you want to provide “levels of done” then that’s fine, but see point 1.
  5. Set objectives which help someone grow! Whether it’s giving them confidence by building on existing skills, or learning new ones, or even just really getting to a tricky problem they have been wanting to take on, lean into these! Make the objectives desirable! Can they always _all_ be like this? Probably not, but keep your eyes open for opportunities.

None of these sound like revolutionary approaches, but in my experience, they’re still exceedingly rare and this list has taken me pretty far in building both good relationships and good people.

Time management resolution

I don’t do resolutions, but I have changed how I approach something at work for this year, and so I guess that counts, right?

I now have regular blocks of time in my calendar marked out as “Busy. Any meetings added in this time will be declined.”. This was after I realised I had multiple days in a week where in 7 hours I was doing a dozen or more meetings and was feeling totally burnt out at the end of each of those.

I got back in touch with the people who had called those meetings (including myself, clearly my own worst enemy) and asked if my contribution had been valuable, and they said it had. There are very few meetings where I am a quiet observer so I’ll take their word for it, and I already reject meetings I don’t think I can be useful in or I suggest alternative people to attend, but the feedback means that if I’m usefully being glue then I need to take more aggressive direct action to protect my time and this is my first try at that.

Management material

So, despite my sterling attempt to delude myself last year it’s been years since I’ve been a developer rather than a manager, and it was about the time of this change in my role that this blog started to die out.

All I have now are opinions and guidance, which the internet is far too full of for me to want to add to (plus I am still very management-naive in a number of ways), but there’s always been room to contribute something new in the form of code.

But.

Off the back of that 57 day coding streak I decided to set myself a few other goals.

I keep a private blog where I write about my kids. Until the beginning of the year I’d posted about once a month and they mostly started with “its been far too long since I last posted, but…” and then detailed just the last few days, because when you’re the dad of a one year old, that’s all you can remember.

So far I’ve made twenty posts this year, including every day in March so far. I’m using an android app for this called goal tracker, although once installed it annoyingly just calls itself “calendar”. It has nice big ticks for each day, and this seems to be working.

This year and the end of last year ha vee also seen big streaks in “one second everyday” and “calorie counter fitness tracker”, the latter of which I use to feed extra data into my fitbit profile.

All of which is to say that I’ve been focusing in rather than out, and making sure I can make a daily commitment to something.

Being able to maintain even this somewhat small but continuous level of creativity (taking a video, writing a blog post, thinking about what I’m eating and where I’m going and how far it is), plus a couple of catalysts at work have helped me to think about the problems (and some more fun non-problems) I could get my teeth into both in and out of work.

Hopefully this will lead to a few more things being shipped to the outside as well as the inside, and can stop being worried that I simply don’t have anything to say anymore.

Being a good developer

In my last appraisal at work I got asked what I thought makes a good developer. I didn’t give a very good answer, mumbling something about keeping up with current developments, reading around the subject, always trying to improve themselves, comparing yourself to other people and so on.

It turns out that in the last few weeks some people have attempted to answer this question for me.

To start with, Alistair posted Developer Essentials listing the set of skills every developer should have in order to carry out their job. That is to say, all developers. No exceptions and no excuses. I agree with the list, despite failing on a couple which are either on the list of “things I’ve forgotten” or “things I hate” (although this is no excuse, and is in fact, a reason to know them).

More recently, Jeff Atwood has highlighted The Ultimate Code Kata which highlights some of Steve Yegge’s old advice about Practicing Programming and pointing to the Code Kata (which at some point in recent history I began but never completed).

The soundbite summary of Steve’s articles comes early on:

Contrary to what you might believe, merely doing your job every day doesn’t qualify as real practice. Going to meetings isn’t practicing your people skills, and replying to mail isn’t practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something.

This seems spot on to me. If you’re not growing as a developer, you’re not a good developer. If you’re continually content to let your skills languish until someone comes and shows you how to be better, you’re not a good developer.

Bugtracking

With wxVenus, I wanted to set up a public butracker. I wanted to avoid Google Code because of my recent account problems. At a previous company we used FogBUGZ and the developer-focussed bug-entry and editing was brilliant, so I was looking for something similar. I couldn’t find anything I liked immediately and so just to get started I began using Lighthouse which has a very nice, clear and simple user-interface which requires minimal effort to use (*cough*bugzilla*cough*), but it was locked to private-only. If I’d wanted to pay up I could have got anon-view but no anon-submissions IIRC.

At work we use a default install of Trac, which is reasonably horrible, but I know that it’s heavily customisable via a simple config system and plugins so I gave that a go (hence the previous post on mod_python). I obviously got something wrong when I was setting it up though because loading a single page took at least five seconds to appear as well as murdering my server, and it was completely unusable as a bugtracker. I tried running tracd (the standalone trac web server) and it responded much, much more quickly but still not fast enough to use.

In the end I did set up home on Google Code, but I’m not very happy about it. The interface is quite good, although typically for Google, sparse, but there’s no obvious API if I want to get my wiki pages or issues out, and I certainly don’t trust Google not to close my account again, even if by accident, so I’d be much happier hosting my own – tied into bzr ideally.

So is there anything out there that meets my simple, fast and free bugtracking needs? I am not bothered about milestones, priorities, ticket progress trackers or due dates. Just a list of bugs which I can arbitrarily re-order and add comments to will keep me happy.