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?
Subscribe to:
Post Comments (Atom)
9 comments:
Awesome article =)
I bet Andy will stun you back with his marketing strategy and tell you that your app is too complicated for users to use comfortably =)
Ryan
http://blog.sina.com.cn/ryanteocc
I'm counting on him to do so. ;-)
Btw, remind me to pass you a book I consult regularly. It's called "Founders at Work".
Interviews with key people (including Joel) from:
Viaweb
37signals
Hotmail
Adobe
Lotus
Yahoo
Hotmail
Gmail
Six Apart
Tivo
Craigslist
Del.icio.us
Firefox
Flickr
PayPal
Research in Motion
Apple
etc etc..
text me on Sat morning, I might forget.
Ryan
Sounds good, Ryan. =) I'll do just that.
Since debug is hard, I suggest you to spend a bit more time to write good code so you can reduce the debugging time. I find it's more efficient that way ;-).
Cool post! Clearly explained to a non-geek yet the concepts highlighted relates to the geek in me too.. Seems like you are very much into Software Engineering too.. ha..
Founders at Work is quite good book.. I also suggest you read the book "The Passionate Programmer: Creating a Remarkable Career in Software Development." too.. Very inspiring book by the founder of GitHub and a early adopter of RoR. A must read before you start working and choosing your future career path.. :)
If you love Joel on Software, you'll love the book.. ahah..
D/L it here ba.. http://bit.ly/84rLdx
@Jason: thank you for the advice. Much appreciated. =)
@Bai: Thanks for the link! Wait, if it's written by the founder of GitHub it's probably a pretty new book, right? That's the guy who refused to work in Microsoft to start his own company ...
Kay, I've downloaded it now. Will read and tell you what I think of it (hopefully). =)
Thanks.
Ok, one of the guys to whom the post is dedicated has finally read it. Thanks Cedric for this. You forgot to teach me how to be sleepless and still alive and work well like you and others do. This is crazy. Two sleepless nights means two weeks for zombie-walking for me, for sure.
Anyway, I get what you mean. Actually, I am not in the team to manage you guys, but to learn from you and to work with you until the completion of the project and beyond. And with what we've been able to come up with today, I hope it is still a possibility. I have to admit I am still naive in thinking "impossible is nothing", which is a result of a story 'someone' told about a group totally re-doing their app in just two days.
Since I've had a better idea of how the process is like, I really want to know what parts of the plane we are building, how to make them, how much time needed, and how to track the progress? Another thing is how I can be of help during the process? What I have in mind is beside coming up with the idea, brainstorming the killer feature, I will also want to make use of my business knowledge to generate targeted users' opinions and how to market the app after it's been finished. Nonetheless, we are still at the first stage, should we spare some time to think abt the final project as well, as Kah Hong and Adhi also mentioned it...
Yours,
A geek-wannabe non-geek
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.
^^ yep. sure sounds like a lot of programmers (alright, me included ahahaha)
Post a Comment