June 24th, 2008 by
Phil
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.
Tagged: coding, management |
No Comments »
March 27th, 2008 by
Phil
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.
Tagged: bugtracking, management, wxvenus |
8 Comments »