2010
11.20

Practical Programming

(You’re doing it wrong)

Before we get on with the business of me pissing you off, let’s first get some background data. I work as a consultant. There, I’ve said it – get the prostitute jokes out of your system. Now, for some people working in a bubble never having to worry about interacting with other programmers code, the following conclusions might seem completely wrong. If so, congratulations – you are one of the lucky few with total control over you development environment. You have to take what I say into the following context; every month I work on code originally written by about 20 different people, then modified by another ten. Besides code written by me from scratch, of course. I work in my own environments but also in client provided ones, using a variety of tools more or less of my own choosing. An average month I probably write code in four or five different languages, and about as many dialects. It’s a mess, but it has also given me a quite unique insight in other peoples work structures.

I wrote my first piece of code when I was 10 years old. It was very basic in every sense of the word, since it was on my very first computer, a C64. I then carried on writing stuff for my own needs for a few years, until I finished school (barely) and started supporting myself by coding full time. This was well over 10 years ago now. Even so, I do not consider myself a true “programmer”, and this is why: My Ego is not big enough.

There are two main types of programmers (and right away I’ll make some mortal enemies disregarding the HTML-kiddies entirely, but I’m sorry – you do not even qualify): Practical programmers and Egocentric programmers (P-Coders & E-Coders). The E-Coder like to read book after book in The Tao of Programming (yeah, the irony was intended), tend to jump on the latest hype full throttle and write code so beautiful it should be framed and put in a museum. Furthermore, often times they are Programmers first and foremost, not often involved in other areas of business like IT management and alike.

The P-Coder on the other hand often have a more diverse knowledge base, has no problems configuring networks and managing servers (I’m not saying a E-Coder can’t do these things, but in my experience if they do, it’s not for the sake of learning or having fun but more of a necessary evil). P-Coders write code for the sake of obtaining a result or solving a problem as opposed to the E-Coders, that write code because this is what they love doing more than anything else. For the P-Coder the process of solving the issue at hand is often more rewarding than the end result, in terms of finished code.

In terms of plain writing code there is little question that the E-Coders are the best at the Programming itself, as a method – or even a philosopy, if you will. This however has little meaning in “the real world” where results, efficiency and money comes in to play. This is why.

Your Ego is killing all the bunnies

Having belief in oneself is a good thing. It makes you better at your job and even socially more capable. This, however, should not at any time be confused with thinking you are God. Self distance and is also a good thing, and even better is the possibility for self criticism, when required. Here are some examples to why it is good to keep your Ego on a leash when programming.

  • Beautiful code in many opinions is the code that is the most effective in the least amount of rows. Effective code is often very complex. Complex code makes other people debugging your code hate you. Too Complex code makes your boss angry for burning company time and money.
  • OOP has it’s uses, but for the sake of all things holy – use restraint. I’d never argue that for things like DB access, user handling or similar OOP is – quite frankly, the shit. However, when you have one single call in main and then the rest of your program mysteriously executes down the dark trails of 100’s of classes and sub classes, it’s safe to say you’ve gone overboard.
  • Frameworks also have their uses, but use your head – if you’re writing an app that makes coffee, don’t include a framework that can also grow and harvest the bean. Some might say this is to future-proof, I say it’s lazy. If you do use frameworks, include it with your source. When someone tells you future versions of their framework will be backwards compatible, they’re lying. In the world of components, this is even more true and has even worse impacts. Repent!
  • In reference to the two previous in combination with Web development, MVC Framworks are generally to be considered the spawns of Satan. Yes – if you’re building something gigantic it might be of use. The security ideas are correct. The rest is an endless soup of overhead designed to suck the life out of any programmer picking up where you left off. Let’s face it, Web development is normally not something that gets so advanced that it warrants enmeshing your company or your client to this degree.
  • When faced with a problem your Ego will slow you down in finding the solution. For example, E-Coders tend to take variables in the environment for granted on a larger scale than P-Coders. Start to look at a problem from an angle assuming “I can’t be wrong” and you will spend more time compared to keeping an open mind. The same goes for in-data related bugs. E-Coders tend to check for in-data errors at a later stage than P-Coders, who usually start out a debug session with verifying what is in the database or checking input parameters.
  • Parading around the latest Buzz might make you sound cool, but adopting each and every one at an early stage is extremely counter-productive. After some time has passed since the launch of  a new technology or methodology early adopters share their experiences, and every time there was this or that aspect that no one had seen coming. Keep your pants on and evaluate from a practical point of view so that you don’t look like a fool later. SOAP anyone?
  • Keep it together. For someone stepping in debugging your code, understanding it is like reading  a book. A book or any other readable text (except maybe mine) has a certain flow. Any time you move a piece of logic out of the flow it gets harder to read, especially for someone not fully initiated in all the ifs and buts of a project. In a proper debugger environment you can always step into functions, but it still adds a certain amount of stress for every one call. If you don’t need it, don’t use functions or classes just because you can. Code that you know only will be executed once belongs in the main flow. For the same reasons, avoid stored procedures unless they are really needed, like say for speed reasons. I know this will sting for some puritans and there are some other practical bonuses that will be lost as well, but it is such a serious breach of flow moving logic to the database it’s seldom worth it in the long run. Also, some IDE’s provide internal debugging for SP’s, but far from all – and if yours don’t even the more reason to use restraint.
  • Regular Expressions. Oh boy… First of, moving between languages and all the different dialects of RegEx is hell. It just is. Like all technologies, it has it’s uses; simple string matching, scripting binaries and things like that. Do not shift logic from your programming language into the RegEx parser. A programmer looking at a previously unseen complex RegEx will spend that much more time deciphering it, that there is simply no excuse for doing it – no matter how awesome it makes you feel writing that beautiful expression.

Some things I really would like to tell all E-Coders:

  • Never rewrite an old piece of code just because you know how to do it better. This will produce new bugs.
  • The old expression “assumption is the mother of all fuckups” still applies. Never assume that a previous programmer didn’t know what they were doing when something looks strange. Never assume your new shiny code will produce the same end result in all situations when rewriting something as vital as say, a global function.
  • Never fix bugs you happen to stumble across unless really serious. Report them to someone that has an idea of the bigger picture. A bug might have triggered a user behavior or setup pattern that you are unaware of and your fix might make things worse.
  • Never commit untested code. There is no excuse for not compiling before a commit no matter how small a change has been. If you’ve changed something that affects an SQL-statement, make sure to run through it before submitting the code.
  • The cold was is over. With it, the need to save every single byte on a source level. Format your code. Indent, space out your expressions, operators, etc. Name your variables and functions so that everyone understands. E-Coders often spend a day writing the most beautiful class, only to assign results from it to variables named x, y and z. Try to be consistent and don’t forget this also applies to your queries.

No Comment.

Add Your Comment