To The Non-Geeks

Earlier this afternoon Kah Hong, Andy and I were sitting down at the Biz canteen to work out some ideas for our Facebook app assignment. Adhi was away at Science, and so while we waited for him we started talking, dicking around a little, joking about pie-in-the-sky app ideas. Something struck me almost immediately. As Kah Hong and I went about discussing possible improvements for CORS and our app (and the rough technical implementations thereof), Andy cut in at various points to ask us to clarify things as we went along. This took me by surprise. He had no idea how and what we were going to do, apart from sitting in front of a computer screen and typing erratically. I had forgotten that to a pure business student (or a pure arts student, or a pure science student, etc), the process of creating software seems like a magical, imaginary thing. It was not too long ago, after all, that it seemed like that to me; at any rate I've yet to fully experience a complete development cycle - all the way from idea to spec to completion. And yet, if Andy is to help manage us, he would have to gain some basic understanding of how a software development team worked. I told him to read Joel on Software, and then I decided to write this post (in the spirit of documenting everything I learn in this module - heaven help me in that task).

The thing is this: I may not be a particularly experienced programmer, but I do know a few things that may come in handy for a manager new to programming in general. I do not know yet how we are to work together, but first on a list of things they must know about techies is, of course, programmer mentality. Here's an open letter to the non-geeks; the non-tech people in CS3216. It's about how the programmers think and how they work in your team, and it's very general, and slightly noobish, but I hope it does some good:

To the Non-Geeks in CS3216,
Greetings from geekland. We are the programmers you may work with, and you will probably find us slightly odd. Here are some things you should know in order to help you manage us more efficiently.

1. We write code. You probably already know this, but programming is the act of typing a very strange language into a computer. If you look over the shoulder of a working programmer, you are likely to find utter gibberish. Think of this utter gibberish as instructions in a language that you do not know, like Chinese, say, or Latin, or Greek. What we are doing when we program is that we are building different components of a final product. At the risk of sounding too idiotic, think of it as building a plane. First we lay down the skeleton, and then we lay down the engines, and then we put in the couches and shiny exteriors and paint.

2. Programming consists of three main stages. The first stage is planning. You know a programmer is planning when he stares out the window and doodles on a paper with a pen. Just as an engineer has to figure out what kind of engine to fit into a plane, a programmer has to figure out the best solution to a problem. An example of one such problem: programmers usually have to trade between time and space. Code that runs fast usually takes up a lot of space. On the other hand, code that saves space runs slow. A programmer's job is to find a balance between the two. This is but one simple example of the kinds of things programmers have to think about when designing their code; I won't go into detail, but they are really no different from a builder or engineer who has to choose from a set of varying materials.

The second stage of writing code is writing code. This is the easy part.

The third stage is called debugging. Debugging is the process by which programmers remove errors from software. Because programmers cannot see what they are building, they may sometimes connect the wires from one engine to the fuel tank (or someplace else) and so cause their plane to explode. Debugging takes a long time, because different parts of the plane that were built at different times may interfere with one another. Programmers don't usually know where things go wrong, or what causes things to go wrong, and so they would have to look carefully in their various interlocking plane parts to find possible errors.

3. Reading old code takes longer and is harder to do than writing new code. This is one reason debugging takes longer. Keep that in mind while planning programming milestones.

4. We speak gibberish. We may sometimes sound as if we are speaking goobledegook. We tend to talk quickly, and wave our hands about, and not make sense. This is normal. Please forgive us for this. Have patience, and understand that there are really only three main stages of programming, and a few interlocking parts in any software development project. Ask your programmers how many portions are completed, and which stage they are at for each portion (thinking or writing code; debugging happens later, usually, unless your programmers are reiterating their code - but nevermind about that).

5. Eep feature creep! Programmers love to write cool things. Sometimes we try to add too many cool things, and fail to produce a good end-product. This is where you come in. Look at the feature list. Arrange them in order of priority. Get rid of all the features that the app may do without, especially so when us technical people are approaching a deadline. Good design is not when there is nothing extra to add; it is when there is nothing left to take away (and still the product is able to solve the problem it set out to solve). Force us to do that. We would thank you for it.

6. Read Joel On Software. We are noobs (or at least, I am). He isn't. We're probably going to program in a slightly slapdash manner, especially so in this module, but Joel knows his stuff. He's been doing it for years. So read him. He should do you some good, if you're ever required to manage a bunch of programmers again in the near future.

Yours,
The citizens of Geekdom.

PS: Andy, guys, anything else to add?