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!
Yeah, I’d still agree with your term definitions and overall assesment. And I believe that night programmers would be an asset to any team.
But, like any other human - they might be human as well - meaing that they may be prone to any personality type, even a disruptive one. Additionally, I think there’s probably a higher chance that a night developers might suffer from the NIH (not invented here) syndrome when it comes to incorporating other solutions into their solutions.
(Maybe it’s just me, but I think most night programmers are also cowboys too - want to solve problems, need praise/attention, and get SERIOUSLY bored with anything remotely resembling maintenance…)
Honestly though, keep up the great ideas. I love watching an elucidation of these paradigms force its way through all the words/comments.
Michael,
I couldn’t disagree with you more about most night programmers being cowboys. I have seen plenty of day programmers who are cowboys. It is not unique to night programmers. But I have yet to find a day programmer who does much exploration beyond what it required. They stop at the first explanation they find. For example, while looking up information about using Reflection in Medium Trust, I found lots of references that said reflection was not possible in medium trust. A day programmer would stop right there. A night programmer digs deeper and finds out that those statements are only partially correct. Reflection of private/protected members are prohibited in Medium Trust. This is very typical behavior of night programmers.
To me the difference is that some developers see programming as a job and others see it as an avocation/profession. The night programmer is in a constant learning mode. They don’t stop at the surface explanation. They break out Reflector to figure out why something doesn’t work instead of just accepting the documentation at face value.
I actively seek Night Programmers for my development teams and can instantly spot them once I have found them. Take a look at most cubicle’s in your office. If you can barely see the developer because of all the technical books and magazines, then you have a night programmer. Ask a day programmer the author of the latest book they read and they are more likely to answer Tom Clancy than they are to answer Dino Esposito.
Passionate Cowboys are the ones to really stay away from - they’re absolutely sure they are right, yet refuse to back up their claims in any way!
“The person described above IS NOT a night programmer”
I agree, what happens is that a person like the one described defines itself as a “night programmer”, and thinks of himself as such and makes sure to get the message to people, and the problem is that very often people will buy that
much like in the same way these guys http://www.thedailywtf.com have formed the concept of a contractor (bills really high and does crappy job)
but a real night programmer doesn’t have to define himself as such, others define him as such
a night programmer, glows in the dark!
“Take a look at most cubicle’s in your office. If you can barely see the developer because of all the technical books and magazines, then you have a night programmer.”
SO NOT TRUE!!!
Glows in the dark - I love it
I can’t help but feel like in your day programmer/night programmer dichotomy, you’re just setting up the day programmer as a straw man. The people who have the qualities of your day programmer suck. I don’t think anyone can argue with that. But the fact remains that there is another definition of day programmer that can be useful and isn’t all bad.
*they are conventional in their thinking and approach
*circumspect in their expectations of themselves and their projects
*tend to value getting along.
When you highlighting features of the night you highlight “mostly lead” instead of “kicking and screaming”. Kicking and screaming, is pretty much never acceptable. Anyone who has been involved in a large project knows a few cases of this disrupt a project more than anything.
Conventional thinking might not be clever, but by definition, its easy to imitate. For simple problems where efficancy is “just a plus”, convention is just what you want. It makes it easier to grasp by someone else the next time around.
A programmer who goes home at 5 may not be the one you want on your project with that’s one month past its deadline, but he might be the one you want to hire. He won’t get burned out, and quit and he is likely to give you steady productivity instead of their work being peppered with bouts of total indifference.
I think if we look at things this way, we see that maybe there is room in the world for both types.
Girish,
I think you are getting hung up on the day and night thing still. Its got nothing to do with how long they work, or even where they work, its got to do with results.
What I am saying is that the _results_ that a day programmer produces are not as good as a night programmer. Now - if we are arguing who produces the best results it may just be the case that we are arguing about definitions, not substance.
Ok ok, I think I got it, night programmers are good, day programmers are bad, right? right? Riiiight …