Eighteen comments and counting. It seems my post contrasting the differences between day programmers and night programmers seems to have struck a bit of a cord with the readers of this blog. Here I have paraphrased some of the responses (sorry if I have misrepresented you – but you did it first ):

• I think only night progarmmers are reading this.
• I can’t believe that day programmers are the majority.
• I’ve got night programmer qualities but I’ve got a day job.
• I can’t figure out why the day programmer hasn’t been fired yet.
• I am so a night programmer.
• You are a day programmer if you think this post is about programming during the day vs. programming at night.
• You are wrong, night programmers are disruptive.

I’d like to thank everyone who as posted up to my blog so far and expressed their views, I really value the feedback, but I feel that I need to clarify what I was talking about. I think the second last paraphrased comment says it best – if you think this post is about programming during the day vs. programming at night – you are a day programmer.

Well – thats not quite right. I know some of the people that missed that and posted up, and they are very much night programmers – I was just using night and day analogy to create some contrast – because it really is that obvious.

The last paraphrased comment suggested that I was wrong and painted another picture of the night programmer that wasn’t quite so flattering:

• Night programmers want to solve the world in code.
• Produce complex solutions for simple problems.
• Over engineers every solution and creates alien artefacts.
• Won’t budge – even when they are wrong.
• Is critical of other peoples solutions.
• Will cause you the most trouble.

The person described above IS NOT a night programmer. Lets look at MY definition of a night programmer once again with some emphasis added.

• The mostly lead (or drag kicking and screaming).
• The develop deep understandings of complex things.
• They can visualise a solution and have sixth sense around design.
• They load the alpha/ctp/beta version of the tools at home.
• They participate in user groups and mailing lists.
• See programming is as vital to them as breathing air.

Mostly lead, deep understandings, visualisation, design, and participation. These things don’t seem to correspond to the description that Stuart provided - thats because they aren’t a night programmer.

When someone mostly leads it means they know when they have to step back and have someone else take the floor, but they also know when no progress is being made and can step up where there is a void.

When someone developers deep understandings of complex things, that doesn’t mean that they will in turn produce complex things – it simply means that they can grok what they are looking at.

When someone can visualise a solution and has a sense of design they actively try to reduce a solution to its simplest form – design is the process of coming up with the simplest solution that satisfies the requirements whilst balancing competing needs.

When someone participates its a two way dialog, them assist others around them by sharing their skills and knowledge but they are also open to learning new things. I’ve often seen the most experienced members of the team sit quietly next to a junior member for hours while the junior member goes on and on about something they are passionate about and that most experienced member not only assimilates the information but helps distribute it to the rest of the team.

A night programmer is an asset to any team!