Have you ever had a friend ask you: What the hell are you doing all day in that office? What do you *do* when programming?
Here’s what I said to one of my friends last week, plus some additional thoughts I had in the days that followed.
Programming is like playing with Lego: You get to *build* things. Programmers need *curiosity and playfulness* in order to do their job. This is why programmers often get *bored*, too. We don’t want checklists, deadlines, or specifications. That spoils it for us. We don’t want to keep working on similar problems. This is why other people sometimes think we are unorganized or *lazy*.
Our work often requires a lot of concentration. When it is boring, we are sleepy and get *frustrated* because we’re falling behind in our schedule. When it is interesting, we immerse ourselves in the problem and think of nothing else. This is why we *hate being interrupted* in our work, this is also why we like to come late and *work at night*. Everything is calm and quiet, then.
Programming is like writing incredibly long and detailed instructions for computers. You have to tell them everything. This is why we like to be precise; the computer needs us to be *very* precise.
When customers report bugs, we have to ask them what they did, what they expected to happen, and what happened instead. And from that we have to guess the approximate location of the bug in our instructions, and then we have to read through it, very carefully, trying to find the bug.
When customers want a piece of software, we have to ask them questions in order in order to understand what they need. Then we go back to our office and try to devise a set of instructions that does what the customer wants. Customers don’t understand what we write, and we don’t understand what they need. This is why we need to talk so much. And when there’s a misunderstanding, we have to talk about it some more. Customers keep wanting more features, but we want to spend as little time on it as possible.
When writing the instructions there is no postponing of decisions, we have to write every single step now. This is why we like to know everything ahead of time. Since customers have trouble imagining the final product, however, they cannot tell us *how* they want their problems to be solved. Invariably, we will have solved their problems in unexpected ways. Sometimes the solution is too complicated for the customer, sometimes it is not powerful enough, sometimes it is unclear what the users has to do... As we keep working and the customer keeps testing the application, we slowly approach a state of balance. Ideally, this is when the acceptance test happens and the release is done.
#Software