Jeff Atwood has some inspiring things to say today: Don’t Go Dark. Seriously. Read it.
Even if it’s just stuff he’s copied and pasted from others, it’s still something every developer should take note of.
(For those of you who are too lazy to click the link, here’s the one line summary: “programmers should never work alone for more than a few days in a row”.)
The reason it’s such an inspiring piece to read is that sitting in a dark room churning out code is probably how we feel, deep down inside, developing software should be. In an ideal world, we don’t have managers changing the specifications around every single day, we don’t have colleagues complaining about how our interfaces don’t do what they expected them to do and we do have team leaders that take a look at what we came up with after weeks of hard coding and heap lavish praise upon us for our brilliance. We just sit in a room all day and produce reams of beautiful, elegant code.
Like communism, this ideal is nonsense.
The reason our managers change the specifications around every single day is that they are incapable of telling us exactly what it is they want in terms we can understand and that we, in turn, have difficulty translating the politically motivated gibberish their management requires them to shroud their desires with into lines of code. Every time we finish a part of the project, it turns out to be nothing like what they had originally intended for us to build.
Our colleagues, in turn, complain about our interfaces because they are working on a completely different piece of the same project and what makes sense for us to supply them in an interface with, is quite possibly completely useless to them.
And the team leader? Well, he’s right. We’re not brilliant. What seems an inspired stroke of genius to us to them is convoluted garbage that will be impossible to maintain by someone else once we’ve moved on to a different job in another part of the country.
The idea of programming as nothing more than a simple exercise in problem solving where the cleverest bit of code wins the day is completely and utterly wrong. In the real world, it’s not cleverness that makes a project successful, it’s communication. An elegantly constructed algorithm will not help you one bit if it doesn’t help your manager solve the business problem he’s trying to solve and it won’t help your colleagues if it makes it more difficult for them to interface their code to yours. It should therefore come as no surprise that your team leader is indifferent about it. Real world projects succeed because the people working on them communicate well. What exactly is your manager trying to achieve? What are your colleagues working on? How well do you keep up with everything that’s going on?
If you’re sitting in a dark room for three weeks, you’re not communicating and the project will fail.