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.