Goals for Next Year

Posted on December 18, 2009
Tags: , , , ,
A lot of people are setting new goals for the new year. I usually don’t do that - either you change something instandly or you never going to do it. But well, let’s say the change to 2010 just happens coincidently while I’m setting myself new goals.

Be rational

I’ve seen myself arguing in a very personal way in the past. I don’t think it is good. The problem with this is, that it makes you blind for better solutions, the outcome of a discussion is biased by your ego and your judgement is therefore flawed. One of the lightning talks at this years KiwiPycon actually opened my eyes with this, that we programmers have rather religious than rational discussions.

dsc_0106.nef

Especially whenever you say: “I believe…”, “I’ve the feeling of …”, “I guess…” are all applicants for coming up with arguments without any facts for backup. Good candidates to think again and get your facts sorted, before continuing further.

Write a Specification before Code

Do you also have a bunch of projects, which you started coding on and never got back to them? I have heaps of ideas, started coding and after the first barrier thought I’ll handle the problem later. I never fixed the problem and certainly never continued the implementation.

I realised that this is a stupid way of writing software. I used to write functional specs based on Joel Spolskys “Painless Functional Specifications” during work and realised: writing a spec before you actually write any code makes absolute sense:
  • you think about 60-70% of the details before you implement anything
  • while writing the spec, it raises other questions you haven’t thought about in the first place
  • if you use a text format like ReST, you can reuse the scenarios in the spec for doctests
  • and - last but not least - you know after the spec that you want to implement the idea or not.

Wonderland?

Motivation

All the ideas I’ve come up with in the past had mostly one flaw: they lacked of a motivation. Even 50% of the packages and components I’ve seen on pypi have this problem too. You’ll find for example three apparently similar packages and think:
  • What’s the motivation that this piece of software exists in comparison to the others? What problem does it solve better or what does it do better?

A motivation should answer those questions. If I’m writing a new project, that will be one of the first questions I’ll ask myself, before writing any code.

For any new project I start from now on: No spec, no motivation: no code.