For the uninitiated:

Q) Have you ever wondered what a software developer REALLY does?

A) Sit in front of the monitor confused. (or cursing… or both)

A while ago, I read an article about how developers spend their time. What Jeff Atwood postulates is that developers spend MUCH more time understanding code rather than typing in new stuff. I have to agree, with some colourful comments:

Its inevitable; the moment we do a linebreak, chances are that line is code is going to be modified in a near future. Better yet, the amount of time spend on doing so is small compared to the amount of time reading and understanding it! And this is your own code! Imagine how its like working with 5 people, or worse… 10?

Since we humans enjoy the company of each other, how about a little guide on how to spend more time code-staring together:

1. Do not comment your code. We are all Rockstar Programmers. The code speaks for itself, extreme L337n355. Actually I heard that is an actual Perl feature… not supporting multi-line comments and all. Straight from somebody who truly appreciates Perl: “Don’t use multi-line comments. If you have a piece of code that requires a multi-line comment, rewrite it so it doesn’t need to many lines of comment”. Genius!
2. Do not use version control. Its bad, its got 666 hidden somewhere in the source as a pre-proc directive. As an added bonus, when we overwrite files entirely, we just obliliterate it! BOOM, gone.
3. If you must use version control, take every opportunity to break the build. Its fun to update and find out that something you need to use is broken, especially if its not yours.
4. Do NOT use a debugger. Instead, use good ‘ol print-screen debugging. (heh, Here’s Linus Torvalds in an article called im-a-bastard-speech). For more fun, use print-screen debugging in concurrent programs or even better, when print-screen debugging is affecting the memory so that the behavior of your code changes.
5. Do NOT use already made functions, like for example in the libraries. I mean come on… where’s the fun if we use something that has been around for years and proven to function properly? Let’s rewrite atoi() and use it… its useful for interviews anyway.
6. Always copy and paste code! Typos that get in, stuff that isn’t relevant in the current context, the more, the merrier.
7. Do not design or architect your code. Planning is for the weak puh! The ad-hoc way of programming is more fun, just like writing essays and gets quicker results! Design patterns? Get OUT of here! We are smart people, we do not need to use what thousands of lesser geeks have been using to improve their architectures.
8. Run away if you have to practice Test-Driven development. Similar to version control, it has its origin in the worship of pagan lords; the temptation to have PRECISE requirements at coding time or to have HUGE time savings in the long term in terms of debugging can be hard to resist, but those are all evil.
9. Hack up all your classes together and don’t use helper functions. High cohesion and low coupling are to be avoided like the plague! Why have multiple files? Multiple classes? No way! Oh and let’s group classes together, sorting them by alphabetical order, the code is neater that way.
10. Hate process, even more so when you’re in a multi-person team. Project plans, Software Specifications, Software Architectures and Test plans are for wussies. Who the hell needs UML? You can draw pictures that nobody will understand an hour later. That way you look smart, you keep your plans secret and thus your job forever and you look smart.

The list can be much longer than this, but 10 is a nice number plus I’d have to write more as opposed to reading code.

For people who actually want to improve themselves, check out Software Carpentry, authored by Greg Wilson. It contains a series of lectures, including a section on the software development process.

Tuesday, October 3rd, 2006 @ 3:12 am software
RSS 2.0 Trackback