Programmers are talking in a weird mixture of acronyms and words which are featured in dictionaries but denote something completely different. A mouse isn't a mouse, bugs aren't bugs, tools aren't tools and so on. Reciperversexclusions, if you so wish¹. Programmers are working behind the scenes of just about everything that makes up todays economy. They are building software through a process - or call it an art - which is known as programming. Software is invisible but these days it is contained in almost any piece you can put your hands on (perhaps except for table spoons but this could change). Most likely you'll be made aware of the fact that something is software driven only if it fails to fulfill its purposes.

Things like these are what programmers are talking about, and The H2G2 Programmer's Corner is the place to do so. If you're interested in some more insight then here are a few thoughts.

You gain deep insight into the inner workings of a computer. You can help yourself when you know what's supposed to happen behind the scenes, without resorting to user support hotlines which try to keep you in endless loops in order to extract money from you. Your skills make you famous among your peers and everybody comes asking for your assistance.

You can circumvent restrictions which are imposed on you by system administrators. You know, they are people like you (that is, on their way to perfection, but not quite there), and it's a great feeling of success if you've found a backdoor system call which brings up Solitair although they deleted all icons and removed the command shell from the user interface. If all else fails, it is a great feeling of achievement to have written your own version of MineSweeper in JavaScript because every .EXE file produced by a compiler would automatically be packed into the next system backup where your project leader might see it and get to know what you're doing besides your assigned task.

Everybody on this planet can see your name written in large and friendy letters, once they've found the secret click-and-key sequence which produces the 'gang screen'.

You can enjoy the hidden sadistic fun of imagining people's faces when your program once again bails out to a blue screen in a critical moment, presenting one of your masterpieces in the field of composing cryptic error messages.

You've got the powers to write a desastrous computer virus or to hack someone's machine. No, of course you shouldn't but sometimes it's fun to dream of it. The strongest argument against actually writing a virus is that you are going to be its first victim.

You can impress people with techno-babble like

'The old GUI was based on 3D-CORBA reference passing by value rather than on a MP3-FTP implementation under FAQ. I've rewritten the whole thing in CCD-PCI 3.5 for USB and saved us all the hassle with the DDR protocol stack and OCR timing. It's the OLE client switching hardware again, you know...'.

You can enjoy heated debates over the GOTO statement, which programming languages are best, which operating systems really deserve to be called 'operating', and whether there is such a thing as a Real Programmer who can read and interpret a 4MB binary core dump.

You're not responsible for mistakes (see further down for a statement of the contrary). If a bridge spanning some 1000m collapsed under its own weight then everybody would point at the architect and the construction company and file $100 billion lawsuits against them. If your DOORS(TM) operating system crashes any time the user tries to open a file then you can refuse to take responsibility by pointing at the 20-page 'disclaimer' section of the license agreement which expressis verbis excludes any use of it in science, business, military, medical or hobby environments.

The feeling of achievement is something comparable to an orgasm (ok, roughly).

You've got a job which is challenging every single day. Learning is an essential part of it. There's no such thing as 'routine' because you're constantly developing new things. You're at the forefront of technology, tasked with shaping the future.

You'll soon find out that your dictionary of TLAs (Three Letter Acronyms) is growing faster than moulds on a forgotten piece of pizza. What makes matters worse, behind every new TLA there's a new concept which takes weeks for you to fully understand and in 50% of the cases you'll eventually find out that the 'revolutionary concept' is just another re-packaging of some arcane mechanism.

You're beginning to talk to yourself because you're developing some alter ego who peeks over your shoulder and keeps reminding you to comment your code. Writing comments draws away from your creative powers. Commenting one instruction costs as much time as writing three more instructions. Keeping comments consistent with what the code does is a Sisyphus task. But trying to understand even your own code after three weeks costs even more time. It can cost even more time if you did the commenting in the wrong way. You don't need to comment on what an instruction is doing (this should be obvious) but rather why it does so, and why it does its things in the given order.

People will laugh at you for such trivial things like failing to keep the units of measure consistent, eg, forgetting to convert metric units into imperials when writing the mission software for a Mars landing vehicle.

Bugs! No matter how careful you are, you will produce them, nothing easier than that. An ugly bug can keep you busy for days and weeks, your boss is asking for one status report after the other and the deadline is closing in. Even worse, you're on quicksand there! All your tools and the operating system are software too. That is, they have been written by other programmers who are producing bugs like you do. Not even in theory can it be proven that a program is 'correct' because it would be another piece of software which would have to do the job.

Design flaws! You could be halfway through a project and then notice that something is simply impossible. Perhaps the programming language is lacking a certain feature, perhaps the transfer protocol type that was chosen for the project doesn't provide reliable timing, perhaps something else. The frustration of having to throw away months' worth of work (and starting all over from a blank screen) is something you must be able to cope with.

It's a lonesome job. Most of the time you'll find yourself in the company of only a keyboard, a computer screen, and a mouse.

As a male programmer, you'll be sad to find out just how few females are in the same business, and that those few that are most likely are better qualified than you, and are in no way impressed by techno-babble or your kind of smalltalk. As a female, chances are that you're alone in the company and everyone tries to prove that they are better than you.

When thinking of becoming a professional programmer, you should keep in mind that there are some important differences between writing programs like 'MyMineSweeper' and writing software for real business. MyMineSweeper is written without specifications which you have to read or (gasp!) write. If you feel like adding or removing a feature then you just do it. The specs are in the back of your mind, and you amend them as you go along. There's no interface to other projects. If you detect a bug in MyMineSweeper then you are free to a) live with it, b) find and remove the bug or c) just use a workaround. If MyMineSweeper fails then you may have to reboot the computer and that was it. You'll acquire a habit of frequently saving your source file very soon. In contrast to that, business software is written to specs, there are project leaders and customers with their own ideas of features and timelines, and the bugs are there to be found and killed.

As a professional programmer you have to do really ugly things too. I know it's in very bad taste to mention the 'd-word' (Hi there, Mark ), but... somebody has to write the documentation. Lucky was a programmer who found some good software documentation when the Y2K bug was to be eliminated at the turn of the millenia. Good documentation is reflecting the current properties of the code, it will fully replace you in case you suddenly die of a heart stroke, and it is a myth like the Unicorn and therefore doesn't exist in the first place. Likewise, you'll have to read and understand cryptic specs. Or worse, you can end up with the task to write them .

Professional programmers are close to being paranoid when it comes to consistency and condition checking. Consistency checking should not be done at all, it should rather be rendered unnecessary: never store one piece of information in more than one place. For example, if there is a 'customer' database with your customers' names in it, then it is a bad idea to create a 'phone directory' file next to it, with (supposedly) the same names in it. They will never match.

Condition checking is essential if there are interfaces, eg: between modules of a program. And there are always interfaces, be they calls to the operating system or just subroutine calls within a module. Nothing can be taken for granted, even if it is explicitly mentioned in the pre-condition section of the specs for a subroutine. Rather than to assume; that an integer is in the range [LowerBound, UpperBound] when passed to the procedure, professionals insert an instruction to check for it. They know that the specs were written by another programmer, and the calling routine will be written by yet another one. After all, if you can present an 'Assertion failed in line 34997 of module 42' message then you can point at somebody else, and save a whole afternoon for better things than debugging a perfect piece of code. The same is true for the exit part of a subroutine: if there is a way to cross-check the results, then at least the beta version should perform the checking.

You're responsible for what your piece of software does or does not. Hobby programmers may face the necessity to format their hard drive after a program has gone wild. Professional programmers put their own existence and the lifes of others at risk. Even if a well-written license agreement protects you from being taken to court, the stock value of your company will plummet, you get fired, and a bad conscience will remain if your mission-critical software failed. Think of a spaceship which is heading directly into the sun because somewhere in the Megabytes of source code a simple minus sign was missing. Think of the first flight of the Ariane 5: never was there a more impressive revelation of a software bug than when the Ariane rocket ended as a firework. The worst thing that could happen to a programmer is to be personally identified as the one who wrote the fatal line of code. And somebody must write the software for heart pacemakers, clinical life support systems, airport radars, railway routing, nuclear power plants and all the other systems which cost lives if they fail.

Oh, by the way... is it true that the latest computer viruses were successful because they exploited yet another buffer overrun weakness of some err... professional software?

Well, that was a short philosophy of programming and programmers. Looking back over it, I notice that an important point is missing: it's fun!

Be seeing you over at the H2G2 Programmers' Corner.

Bossel

20.09.01. Front Page

Back Issue Page