Category: Personal

I chose this to be the second lesson because I feel this is one of the things I learned through experience. It’s the basis of many many other lessons.

So what does it mean to be paranoid about your code? While you’re writing code, for some strange reason, you have this false confidence that it will work. It’s false because it’s statistically impossible to write code that works the first time. Consequently, you have to assume that everything you write will fail.

Sometimes a failure is not bad – it depends on what you’re writing. If you’re implementing a word count feature for a document editor and your code causes the editor to crash, then there’s always auto-save that will give the user his latest changes minus the last 2 minutes or so. But if you’re writing the auto-save feature for that same document editor, your feature can ruin big, important documents that belong to clients who will never buy software from you again.

In practice, being paranoid about code means that you should check every return value from every function and exit error situations as gracefully as possible (the optimum being working in a transaction-like manner). Include sanity checks and assertions as much as you can, so that during tests your code will crash early instead of dragging an error to the point where it can’t be found.

Both advices, “crash early” and “anything can fail”, are well known in one form or another. Today they seem obvious to me, but I first read them in a book called “The Pragmatic Programmer”, which is a great read for developers at all levels.

I decided to start the “My Programming Lessons” series with a lesson I don’t consider the most important but still important enough.

Learning when to quit programming is hard. You have a deadline, you’re stressed and things aren’t going well – maybe the compiler complains about something you don’t understand or maybe the program doesn’t print “hello” even though that’s the first line being executed (or so you believe). This is the exact time you should let everything go and simply head home to rest.

You should let go because when you’re in this state you’re probably more destructive than constructive. The next day, if you’re like me and you re-examine your code often, you’ll probably replace all the crappy code you wrote with smaller, better code that will work first time around. And that’s the good scenario. The bad scenario is that you’ll keep trying to rework that crappy code until it seems to work and this almost always means a bug is hiding in there somewhere.

It takes some insight to learn when the right time to quit is. For me, now that I have a few years of programming experience, I usually know when to quit before I’m destructive. If this time of the day arrived and I still feel like I have to work, I usually do other (not as critical) work like documentation.

I worked in Motorola for two years. I enjoyed working there very much, but decided to leave and look for a job in Linux and for a smaller company. I got tired of big companies and I also wanted some experience on Linux. The problem is that once you start working on one operating system (or technology) you pretty much get stuck with it, unless you get a chance to switch. I got a chance simply because there was enough demand and not enough Linux programmers to supply it.

So these days I work for Diligent on Linux. Programming on Linux brought me closer to what I learned in the university. The operating system itself has a very small collection of functions you can use (unlike Windows) and you have to work your way up from there using the huge collection of available libraries. For a Windows programmer like me it seems strange that there is no CopyFile(source, destination) function in Linux (which is part of the Windows API since the beginning of time). Also, some functions simply don’t implement all their advertised interfaces, like getting a process’s memory usage with getrusage(). What’s great about Linux is that you can see the implementation of the function, for example in the Linux Cross Reference. Also, in Linux, if you complain about something they will simply tell you: go and implement it yourself.

So this is my experience so far. I admit that I thought this series would be longer and maybe include more of what experience taught me over the years. However, when it comes to software engineering, there are so many gurus sharing their experience, code and their processes in a much more coherent way than I can, that it seems pointless to reiterate things. As an example, here’s Coding Horror’s top 6 list of programming top 10 lists post. I might start posting short “lessons I’ve learned” posts on this blog in the future.