Even though more than 20 years have passed, I still remember wondering what it would be like to finish university and start working. Up until that point, I had pretty much spent my whole life in school, with only a few, non-programming summer jobs thrown in. My expectations of what it would be like to work as a software developer were mostly correct, but there were a few surprises in the first few years, and here are the top five:
Programming seemed like quite a solitary job – a feature needs to be done, so you sit down at your computer and code it up. The truth is there is quite a lot of interaction with other people. You discuss your designs with your colleagues, you are in meetings reviewing new features, and you talk to the testers testing your code.
It really helps to be tactful and diplomatic during these interactions; if this doesn’t come naturally, learn how. One of the best books on the subject is How To Win Friends and Influence Peopleby Dale Carnegie. If you haven’t read it, I really recommend that you do.
It helps a lot to be able to write clearly in order to get your points across. To some extent, coding and writing are quite similar. In both cases you need to express your ideas clearly and unambiguously in a structured way. There are of course lots of e-mails that need to be written, but there is also documentation of the features you have developed, describing bugs in bug reports so that it is clear what the problem is, as well as writing good explanations for bugs you have fixed. There wasn’t much emphasis on writing at university, but being able to write well definitely is an asset at work.
Before I started working, I thought that you developed a feature, and then you were done with it. However, in reality you quite often come back to features. Maybe it was not exactly what the customer wanted, or you are adding more functionality to it, or similar funtionality so you want to combine it, or you are fixing a bug in it. One way or another, you often return to code you wrote before.
I didn’t really understand either that new features are almost always inserted into existing code. At university, we always developed programs from scratch, but that is almost never the case in the real world. Sure, you create new functionality, but it always has to fit in to what is already there. Therefore, a large part of creating a new feature is understanding the existing code in order for the new feature to fit in. This is something we never practiced at school.
At university I did an M.Sc. in Computer Science and Engineering. I studied communication systems, which included signal processing, error correcting codes, queuing theory and so on. We also had core computer science courses like algorithms and data structures, and I loved all of it. I thought it was really cool to be taught all these clever algorithms and data structures, and I expected to see them in use at work.
My first job was as a software developer at Ericsson in Montreal, working with the mobile switching center that handles calls in a cellular network. There was a lot of code controlling call set-up, hand-offs, roaming etc, but I was pretty disappointed to see that it was all done with quite basic data structures and algorithms. The most interesting part I found was the code keeping track of roaming subscribers currently in the system. It consisted of one thousand binary trees, where the last three digits of the subscriber number determined which tree a given subscriber belonged to. To find a subscriber, you picked the tree based on the last three digits of the number, then traversed the tree to find the subscriber. Apart from that, it was pretty much only linked lists or simpler.
So, given that there were no clever algorithms in use, and that the whole application was only using pretty basic data structures, it seemed at first that there wouldn’t be many challenges working on the system. Wrong! I quickly realized that the system is hugely complicated, not with complicated features, but in having lots and lots of simple features aggregated together. This is something I have seen in all systems I have worked with. Most features are dead simple, but because there are so many of them, you get subtle (or not so subtle) interactions between them causing bugs. The complexity of the system comes from the aggregation of many simple parts, not from any complex parts.