Sunday 15 January 2006

Computer Science vs Software Engineering

This article entitled Software Engineering, Not Computer Science (PDF), is probably the clearest definition of the difference between the two fields that I have seen to date. It also provides very interesting food for thought because many yearn to do computer science, yet most of us are employed doing software engineering.

In a way, it is a pity that there are not more computer science jobs available. I have encountered a few really smart people who love the discipline and would no doubt advance the field of computer science if they were given the chance. They just made absolutely horrible software engineers as they were not really interested in producing products. They were only interested in creating new things, no matter how unrelated or inapplicable to their task at hand.

Wednesday 11 January 2006

The Paranoid Programmer: From Junior to Mid

While chatting with a fellow developer, the question was asked: "How does one go about raising one's skills?" The answer to this sort of question is different for every person - every person has different talents and weaknesses and develops in different ways. At this moment in time, looking at the current Exoweb team, there are a few areas that I would particularly emphasize:

  • Paranoia
  • Mapper vs Packer
  • Quality Plateau
  • Knowledge Portfolio Investing

This particular entry is written mostly for Exoweb developers, but any feedback, comments or suggestions are welcome. Update 2006-01-15: Changed the title. Besides the fact that I've previously written something on what makes a senior, what I've written here will only get someone up to a mid level developer in Exoweb. There are a lot more things I left out on what makes a senior, like the soft skills.

Paranoia

Paranoia is good in a developer. Or perhaps some would prefer to refer to it as boundary checking. At any rate, it is always good for a developer to consider that Murphy's Law (anything that can go wrong, _will_ go wrong) is something we encounter far too often in our daily life. Once code is written and being inspected for improvements (you do go through your code again and see if you can improve it, right?), it helps a lot if the developer considers what can go wrong and how one can safeguard one's code against this.

As an example, one area that developers typically forget in web programming is url encoding. For instance, some insert usernames into the url as a variable. e.g. /user/john/details or /user_details?username=john. However, they forget that usernames can often include characters that are not legal in urls, such as spaces, &, ? or others. Worse, they may not even be ascii. In our global environment, it is no longer uncommon to encounter a lot of unicode characters. This of course leads to much pain later. Competent developers learn the first time they make this mistake and never repeat it. The superstars never make this mistake in the first place.

Paranoia can only go so far - you will miss something. Fortunately, that's what code reviews, pair programming, even more paranoid seniors and users^H^H^H^H^H beta testers are for - helping you catch your errors. But it helps the user experience (and your career) a lot if you catch as many of the bugs as possible before anyone else sees them.

Mapper vs Packer

The terminology comes from the Programmer's Stone, and it refers to a mindset. Are you a memorizer (pack information into your brain) or one who figures out the fundamental principles (maps connections between data points)? Packers have a tough time making senior in Exoweb because seniors are the ones that handle the most unusual, newest problems. For that, a packer has to find and pack the appropriate response. That can be rather hard to do. Instead, we need people who are adaptable to new situations and can figure out solutions to problems. Nothing is more annoying than a person constantly bombarding you with questions that could easily be answered with a little thought.

The Quality Plateau

Yet another term from the Programmer's Stone, this time in Day 2 of the website (I consider the first two days the most valuable). I wish they had a HTML tag to that particular section so I could link directly to it, instead of telling people to search for the heading. At any rate, that site shows how even code that is considered well written can be improved and made more readable. You may or may not agree with the style or the different methods used, but it is an eye opening experience - 26 lines of code reduced to 11 much more readable lines of code.

The Quality Plateau is not about reducing unnecessary variables, cramming things into as small a space as possible or holy wars about coding conventions. It is primarily about looking at your code and constantly finding ways to improve it. This mindset may seem expensive at first as you spend time looking over already functional code, but the long run benefits are enormous. Each time you see a way to improve your code, you learn something new for the next bit of code you write. Over time, you get better and better and start producing top notch code without much effort.

Knowledge Portfolio Investing

If the Quality Plateau is about constantly improving your code, then Knowledge Portfolio Investing is about improving yourself. This particular phrase comes from The Pragmatic Programmer, a book I highly recommend. As knowledge workers whose tools are only our intelligence and a computer, our greatest value lies in what is in our heads. If we do not constantly invest in increasing that asset, we will one day find ourselves penniless in our job - we will not have the value left to justify the high salaries that we believe we deserve.

It is hard to take time out to invest in ourselves, to learn something new every day. Work is tiring, our personal lives often seem more interesting and something always seems to come up. But none of us would have gotten this far if we hadn't invested time and effort in improving ourselves. No one in Exoweb has ever studied only the bare minimum required of them in school. Work should be no exception.

This is one of the reasons why Exoweb allocates 10% of work hours to employee improvement and tries to minimize overtime - to give every one of our developers time to continue developing themselves. This is a win-win situation for all parties involved as Exoweb's time and resource investment results in more competent and skilled developers. However, this all depends on the developers actually taking advantage of this time.

Final Thoughts

There are plenty of other things and more will be added over time as the situation change and other needs become more obvious. Of all of the above, the area that is ultimately most important is #4 - Knowledge Portfolio Investment. In the end, if a person is constantly trying to develop themselves, they will learn all the other areas.

The future, our industry and our targets are always moving. We can never be satisfied with hitting all the goals we set today, because by the time we hit them, needs will have changed and new goals are needed. However, if we are at least moving in the right direction, there will be a much shorter distance to travel to the new target after we hit the old one.

Sunday 8 January 2006

Public Key Missing in Apt

Just a quick blog about some key wierdness in the debian testing apt-get setup. Not sure where the exact problem stems from, but since the new year started, all debian updates are signed with the 2006 gpg key, which my testing systems did not seem to have. So you would end up with this error after doing an update:

Get:1 http://box.exoweb.net testing Release.gpg [378B]
...
Fetched 2810kB in 24s (114kB/s)
Reading package lists... Done
W: GPG error: http://box.exoweb.net testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

The problem being that the public key at the end is not recognized. Looking at the key management utility for apt (apt-key) didn't show any simple way for it to download the correct key from the debian keyring, so I ended up having to use a bit of a kludge. These were the commands I had to run (as root):

gpg --keyserver keyring.debian.org --recv-key 2D230C5F
gpg --armor --export 2D230C5F | apt-key add -

The first line downloads the public key and adds it to the root user's list of public keys. The command exports this from the root user's keylist to apt-key. The cleanest way to do this would probably be to use wget to get the actual key from its appropriate location, then pipe it to apt-key (it would be a one liner too). However, that is clunkier to do since one has to look up the appropriate location of the key, etc. In the end, adding just one public key to root's keyring was no real deal.

Ah well, back to your regularly scheduled hacking ...