Articles having to do with… technology.

Managing Towards Failure


I used to enjoy racing cars. I was never very good at it, but that never stopped me from being passionate about it. In an effort to get better at driving insanely powerful cars I would take courses from professional drivers / instructors.

One day an instructor told me something that stuck with me. During a particularly frustrating moment for him, as we were spinning into the infield yet again, he said “You always go where you look, there are no exceptions!” As it turns out, every time I approached this particular corner I would focus my eyes on the grass infield rather than the pavement. As a result, my hands would subconsciously steer the car ever so slightly too far into the turn. When you’re moving at a car at an extremely high rate of speed, “ever so slightly” makes a big difference.

The next time through the corner I made a concerted effort to stare at the pavement instead of the grass. It was weird, because I actually couldn’t see the grass when I did this. Guess what. I made it through the corner. Of course, on the next corner I found the infield again but that’s for another story.


There’s a term I’ve developed over my years of watching management, I call it “Managing Towards Failure”.

It’s something you see just about everywhere you go and as far as I can tell it’s a management style that has a roughly 0% chance of success.

In summary, managing towards failure is the practice of making management decisions based on failures. Focusing in on failure, just like looking at the grass infield, steers you towards… you guessed it, failures.

In technical management I’ve seen the following all-too-common example:

A team of 10 developers are tasked with creating a medium-sized product with a 6 month timeline. In the first two months eight of the developers make estimates with around 80% accuracy. Two of the developers, however, trend closer to a 20% accuracy. As time goes on, management continually looks to improve the team’s overall estimating accuracy by coming up with ways to mitigate the two less accurate developers. Often, this mitigation takes the form of added “process”.

New process elements are designed specifically to keep the under-performing developers from failing. Unfortunately, as is normal with “process”, all of the other developers (who were accurate with their estimates in the first place) will be held to these same standards.

As the project gets into the final stretch developers begin struggling to get all of their paperwork and development done. Management gets increasingly frustrated with the developers for not delivering results; developers get increasingly frustrated with management for imposing more controls that limit the creativity and productivity.

Once the project shows up late or failed altogether, more mitigating process is added at the project planning level. Next time there’s a project of similar size, the pre-existing process that was designed around the worst developers remains. The next project adds its own failures, the cycle continues.

Eventually management focuses on why everything fails and adds more measures to prevent failure rather than recognizing the heroes who save what can be saved. All the while the original two developers who couldn’t estimate in the first place got no better at estimating, they simply learned to do paperwork.

The entire team was held to the standard of the worst performers and ultimately no one performed well. No one on the team got better at anything (except maybe paperwork). The original weak performers never got better at estimating, they may appear better because the rest of the team was drug down to their level, but they never actually improved. Management’s focus on failures has created more failures.

The Root Issue

I feel like the root issue speaks towards today’s prevailing management culture. Most often, the management I’ve worked with has been terrified of catastrophe. The higher level the manager has achieved, the more pronounced their fear of things going horribly awry. Their fear of failure is far stronger than their desire to innovate. If your mandate is to “avoid catastrophic failure” then how successful can you be? It’s important to remember that “didn’t go horribly awry” is not equal to “great success” in any form. Ever.

The Solution

The solution is something that management-types have been preaching for years but not really following. Reward success, don’t punish well-intentioned failures. If you focus on success and high performance, you’ll get more success and high performance. As a manager it is, by far, the more difficult road but the results have been proven time and time again. Find disciplined managers who don’t fear failure and trust them to do an amazing job. Because in the end, if you fear failure even a little it will choke out the bravado you need to be a great success.


ISO Recorder – A Must Have PowerTool


As part of my parting duties for a job I’m leaving I have been asked to set up a virtual environment with all of the projects requiring older platforms. This is something most developers have a virtual machine for, but sharing one across the company makes a lot more sense. It’s something we had intended to do for some time but just never got around to.

In doing this, I had to consult our software stockpile to find the old CDs of Visual Studio 2002 (it was originally just called Visual Studio .NET). Since my new-format MSDN subscription doesn’t allow me to download the ISOs of this directly, I was tasked with create an image of each of the CDs so they could easily be mounted on the server (there’s no physical optical drive).

Creating an ISO should be something that Windows has native support for now, but it doesn’t. So I set about finding the best easy, quick and free solution I could.

I came up with ISO Recorder.

It’s quick to install, it’s free, it doesn’t require a reboot and it makes the process as easy as selecting the drive, right clicking and creating an ISO. It’s rare nowadays that we find such laser-beam focus in software without bloated options. But this did exactly what I needed to do and did it quickly. For that, it gets a mention on my blog.

RockMelt – My new default browser


Part of my job requires that I install just about every browser available. Something they all have in common is that every… single… one of them continually asks if I would like for it to be my default browser. They try to make it so enticing, “Don’t you want me to be your default browser instead of that scamp over there? I’ll be good to you!” It never works.

After all, being my default browser isn’t an easy job. I demand things from my browser that most web surfers never even conceive of. When I click a link, I have to trust my default browser to jump into the task quickly, accurately and with impeccable stability. And I’m not talking about sometimes, I’m talking about ALL the time, every time.

For quite a while, Chrome has excelled at the task of being my default browser. I still use other browsers from time to time, but they just don’t seem to stack up to my needs like Chrome does.

Along came RockMelt.

For me, RockMelt evoked a stroke of genius by basing their browser on the Chromium platform (the same one that Chrome uses). I don’t know whether this was a matter of necessity, function or preference but it’s what ended up making my decision for me. It’s like Chrome++. If you’re like me and you like pinned tabs, Chrome Apps and dozens of other awesome Chrome features you don’t have to lose any of them to change browsers and get some cool new social functionality.

So what exactly is RockMelt? From their web site:

RockMelt is re-imagining your online experience by creating a new web browser that makes it easy to stay in touch with friends, search online, and get updates from your favorite websites.

What that means to you is that it’s a fast, stable browser that integrates directly with Facebook and Twitter.

The best way to see what I’m talking about is to watch the RockMelt promo video, I’ll catch you afterwards:

After a week of using RockMelt as my default browser, here’s some things I’m really digging:

  • The sidebars allow me to have my social media items available, but not in the way
  • The ability to add ANY RSS feed to the sidebar
  • The ability to quickly and easily share whatever web page I’m looking at with my Twitter and Facebook networks
  • The sidebars are easily hidden with simple keyboard shortcuts (CTRL+SHIFT+[ and CTRL+SHIFT+])
  • It’s Chrome (which I love) just better

And some things I’m not so jazzed about:

  • No apparent support for Twitter DM (really?)
  • Twitter mentions are not noted on the icon, you have to open the feed, click the sidebar icon and then load mentions separately… Changing the color of the message notification if you had mentions would be a nice touch
  • There doesn’t seem to be a way to share something with all networks at once

Want in on it? You either need to be invited or you need to get in on their beta program, which you can do over on their web site (by connecting with them on Facebook).

Making simplyScroll Scroll Left-to-Right


The folks over at Logicbox have written a nifty little jQuery plugin called “simplyScroll” that allows you to easily and seamlessly scroll through a collection of images with little effort.  This is a great way to avoid making a Flash animation to accomplish the same task and… it works on the iPhone. We needed to use it to make a looped, seamless scrolling header for a site on the quick.

One caveat, however, it doesn’t have an easy built-in way to scroll in the opposite direction of the default (ie. “Backwards”) which is what our client wanted (at the last minute). We emailed the author and were told that it would take “quite a lot” of changes to make this happen.  The client was breathing down our necks on the tight deadline and we were running out of time, so I jumped in with both feet to hack the thing.

Now I realize this isn’t the “right” way to do it. This is an admitted hack because I didn’t have time to go back and do it correctly. Maybe the original plugin’s author will add the correct functionality or maybe I’ll have time to do it “right” and send it to them. But for now, this will absolutely work.

First, change the default function called when you use the “auto” functionality (line 152):


– becomes –


Now tell the position reset functionality that the default position is the sum of the width of all of your elements (line 219):

this.$clip[0].scrollLeft = 0;

– becomes –

this.$clip[0].scrollLeft = 5904;

The number “5904” is just the added up width of every element we ended up having in the animation.

It’s that easy!

jQuery, mootools and NextGEN Smooth Gallery – A tale of failure


Maybe I’m behind the ball on this, but I’ve never tried using multiple JavaScript frameworks on the same page.  I’m the kind of developer who likes to stick to a framework and then make it do what I need it to do.  Sure, all of the major frameworks have some unique and useful plugins, but cutting down on load time and complexity usually trumps any small amount of extra functionality I may gain from using multiple frameworks.

Today, however, I was asked to diagnose an issue with a client’s WordPress site.  All of a sudden the following JavaScript error had started popping up:

Error Console

The evidence

The folks who had been working with the site were at a loss as to why this would happen, so I started digging in.

After some digging and looking at the source code for the page I noticed that not only was jQuery being called twice (eesh) but mootools was being called as well.  The calls weren’t coming from the custom template that the site was using, they were coming from [dun dun dunnnn] INSIDE THE WORDPRESS CODE ITSELF!

After a little digging, I discovered that a Gallery plugin the client was using, NextGEN Smooth Gallery, was loading mootools to do some cool displays and animations for one of their image galleries.  The downside is that the call to mootools was on every page.

NextGEN Smooth Gallery

The culprit

You see… both jQuery and mootools like to use the dollar sign ($) to denote shorthand for their calls.  While this can be pretty easily overcome manually by calling jQuery directly (using jQuery.yada) any plugins that you have for one of the specific frameworks will very likely use the shorthand notation somewhere in the code.  If they do, you’re screwed.

So let my couple of hours of research serve as a warning to those would be framework cross-mojinators out there.  It’s not worth it!

Scammers: Way better with Facebook


I got a good chuckle out of a message I recently got on Facebook.  The message follows:


My name is Barrister Donald Gogo from Togo personal attorney to late Mr.B.A.Garvich. I am contacting you in respect of Twenty Million USD left behind by late Mr. Basel Garvich, who lost his life and family (wife & daughter) in auto crash in 2005. He has no next of kin and an heir is needed urgently who has same family name hence I have contacted you and to present you as heir to his estate so that the funds can be credited to your bank account as heir/relation.

I have tried all that I could to locate the immediate family but abortive. I have 14 days to provide the heir otherwise the funds will be declared unserviceable and confiscated. This is highly confidential, Please send your reply to, Tel:+2289798177.

I await your response for more detailed information.

Best regards,
Donald Gogo.

The fact that these guys have figured out how to fake a relative with an exact last name is a pretty impressive advance from the “I’m the deposed prince of Nigeria” scams that we’ve seen for years.  That they’re able to use Facebook to accurately target the name is going to get a new crew of people caught up in scams.

Now obviously, I have an incredibly rare last name.  If you meet someone with the same last name we ARE related.  And if there had been one of us who was worth $20m+ who had died, along with their family, in a horrific car accident I would know about it.  But not everyone is: A) used to seeing these things; B) savvy enough to realize it’s a scam; C) attentive enough to note that a “lawyer” is sending a message with many obvious grammatical errors.

It’s our responsibility as the technologically savvy to make sure our family and friends are at least in the know, if we can’t actually protect them.  Pass this along and make sure none of your favorite people fall for the scam.

Consolidating Google Accounts


I’ve been using the web and email for around 16 years now.  Over time I’ve been through a LOT of different services and so far, I have to say that Google has impressed me more than anyone ever by providing great, free services like Google Apps For Your Domain.  One of the downfalls of Google Apps has always been that you didn’t get access to the other cool Google services (like Google Voice and Google Reader, for example) unless you had a standard Google Account (GMail).  Well that’s no longer the case, Google has announced that you can now start consolidating accounts.  And consolidate I shall!  Along the way I’m going to write up how I accomplished things and any pitfalls I run into.

The Goals

I’ve got several goals that I’ll outline below, but there’s really only one… and that is to greatly simplify my life.  But working up to that, we have:

  • Consolidate all of my email accounts [7], calendars [10] and address books [2] down to two, a work and personal account
  • Lose NO data of any kind
  • Have the ability to manage all accounts from wherever I am via iPhone or the web
  • Do NOT lose the ability to communicate through all of my separate accounts easily (if someone is looking for me in regards to my band I don’t want to send them email from my work account, for example)
  • Get and manage all email quickly and easily
  • Start using more Google services than I was before by using one account for all of them

The Moving Parts

The services I’m dealing with break down like this:

  • Email – 1 GMail account, 4 Google Apps accounts, 1 Exchange account, 1 POP account
  • Calendars – 9 Google Calendars, 1 Exchange calendar
  • Contacts – 1 Google Apps Address Book, 1 Exchange address book

As you can see I’ve done a bit of work previously by getting most of my calendars and contacts moved over to the cloud via Google.  You may have to do some extra work if you haven’t already started that process.

Step 1 – Consolidating Email

I knew the biggest job was going to be getting email consolidated so that’s where I started.  I had a little bit of a unique situation in that I wanted to create a new, more friendly account for myself using one of my domains hosted through Google Apps.  The reason for this is that once I have this account associated with various Google services I don’t want it to say “” – I want it to say “”.  So I created a completely fresh account to work with.

Transferring Email From One Google Account To Another

In my case I wanted the new account to have ALL of my old emails.  If it’s going to be my primary account I want to be able to quickly search and find old emails when I need them.  This step takes a long time (it ended up taking 2 days for me) to complete, so I’m listing some work to do up front to cut down on the time as much as possible.

  1. Clean up your existing account by deleting spam, trash and any imap generated junk mail/spam/trash folders.
  2. Get rid of any unnecessary messages you may have archived by searching for them and deleting them.  Even if you do this very well you will probably end up with a bunch of unwanted messages to sift through.
  3. Enable POP retrieval of your email in your Google account
    1. Go to Settings > Forwarding and POP/IMAP
    2. Adjust the “POP Download” section to however you’re going to want it to work
    3. Repeat for every account that you want to retrieve all historical email from
  4. Set your new primary account to start retrieving email
    1. Go to Settings > Accounts
    2. In the “Get Mail From Other Accounts” section click “Add a mail account you own”
    3. Go through the Google verification process
    4. If you cleaned your old accounts up, you may want to automatically archive email retrieved from those accounts for now (obviously disable this after you’re done)
  5. Set up temporary filters.  If you have a bunch of messages flowing in now is the perfect time to set up some account filters which will automatically organize the incoming email for you.  An ounce of prevention saves a lot of character building down the road! ;)
  6. Monitor your progress.  These POP accounts have some logic built into them that dictates how often they retrieve email so if you have a ton of email like I did you probably will have to babysit the process.  You can re-initiate a check by editing the entry for the POP account and saving it.

Once you have all of your old email moved over, archived and ready to go it’s time to start flipping switches!

Setting Up Sending

Before you’re quite ready to receive email on your new account you need to make sure that when you send email it looks like it’s coming from the right person.  Google makes this (like everything else) pretty straightfoward.

  1. Go to Settings > Accounts
  2. In the “Send mail as” section click on “Add another email address you own”
  3. Go through the verification process

In my case I wanted to set my account up so that whenever I hit “reply” the “from” field is the same as the one the original email was sent to.  In order to make that happen just check the radio button for “Reply from the same address the message was sent to” and make sure you save your changes.

Once you’re ready to send… you’re ready to receive!

Migrating To Your New Account

If you’re ready for all of your new emails to start coming to your new account you’ll want to set up forwarding from your old accounts.  You can do this as follows:

  1. Go to Settings > Forwarding and POP/IMAP
  2. Click “Add a forwarding address”
  3. Go through the verification process
  4. Set things up as you’d like them to work

Note that the email you get will have the original sender as the “from” address (not your account that you used to forward it) and will have the original “to” address (not necessarily the account you’re using to read it).  This is what allows you to send from the various addresses according to where the original email was sent.

Step 2 – Getting Services

This part is far easier than the previous section.  But you have to have access to administrate your domain on Google Apps in order to make it work, or your domain administrator has to be open to setting this up for you.

For Admins

  1. Log into the Google Apps domain admin account and click “Manage this domain” at the top
  2. Go to “Domain Settings” and make sure that “Automatically add new services when they become available” and “Enable pre-release features” are both checked
  3. Make sure that the Google Apps beta messages are addressed and enabled (if there are any)

For Users

  1. In your Google Apps mailbox, click on “More” at the top left
  2. Click “Even More”
  3. Go nuts!

Step 3 – Setting Up Your iPhone

There are two ways to set up your iPhone to access your Google mail account:

  • As Exchange – Allows email, calendar and contacts support
  • As GMail – Allows email and calendar support

One of my requirements is that all of this work happily on my iPhone.  I almost succeeded, but there is one thing you should know.  If you consolidate all of your accounts into one account, the account you consolidated to is the only one that you can send mail from on your iPhone.  This is important, in my case, because inevitably my iPhone ends up being my primary email client and while my accounts are all consolidated I need to be able to respond from whatever address the original sender was communicating with.  So this is a significant frustration, but there are a couple of workarounds:

  • You can set up imap accounts for all of your old accounts on your iPhone and then set them to never automatically check for email.  Then when you create an email you can define the “from” field.
  • You can use Google’s iPhone app to respond to email when you need to send it from a non-primary address.

How To Get Empathy To Connect To Google Apps Chat


So I’m doing more and more work on Linux these days and I’ve got an Ubuntu installation set up for that purpose.  Really it’s just a fun way for me to get a break from the Windows 7 world and develop in a new environment.  Anyhow… I ran into an issue with getting my Google Apps chat accounts working with Empathy.  I did some research online and didn’t come up with any solutions quickly, suggesting that the answer is harder to find than it should be!

Then I remembered that using other clients the Google certificate always gave a warning.  So, all you have to do is check “Ignore SSL certificate errors” and use the normal account setup beyond that and everything works flawlessly.  For reference, the normal account setup is:

Login ID: [your full e-mail address]

Encryption required (TLS/SSL): checked
Ignore SSL certificate errors: checked
Resource: [whatever you want it to be]
Priority: 0

Override server settings
Port: 5222

10 Ways To NOT Suck At Programming


Recently I wrote a therapeutic rant for myself, called “10 Ways To Suck At Programming“.  The article got syndicated to some link sharing sites and picked up quite a bit of traffic and comments.  The comments here on my site were, for the most part, nice.  Comments elsewhere were a mixed bag with many people saying the sarcastic nature of the post wasn’t helpful.  While I didn’t see it as sarcastic (after all, it was quite literally telling you how to suck), and even though I’ve written many, many helpful technical articles that did nothing but collect dust, I figured I would take a shot at offsetting my previous rant with real steps programmers can follow to make themselves better.

Obviously, this is not a comprehensive list and most experienced programmers should already be well versed in what’s here, but it’s a decent start for newbies and probably a worthwhile reminder to some of the more experienced.

… and it will be interesting to see if an article intended to be helpful gets as much traffic as a 20 minute rant. ;)

#10 Store settings in a configuration file

Configuration files are a necessity in today’s programming world.  With most applications connecting to databases, e-mail servers, file shares and other outside resources it’s imperative that a good programmer store any information that has a possibility to change outside of the release cycle of the application in a configuration file.  This will allow the application’s settings to be changed without having to recompile (retest, redeploy) the application.

It is important, however, not to overuse configuration files.  Some things belong, some things don’t; and experience is really the best way to know which is which.  You can ask yourself, “Is this something that will likely change in the future?”  If the answer is yes, consider putting it in a configuration file.  The more often you can change the behavior of your application without having to recompile it, the more often you’ll look like a hero.

Examples of good information to store in a configuration file:

  • Database connection strings
  • SMTP server information
  • Any standard to / from e-mail addresses
  • File upload / download / archive paths

#9 Scope and store your variables

Databases are awesome tools and nowadays pretty much any application you’ll be asked to develop will use one of some sort.  However, when thinking of application performance database access and transactions are very expensive operations.  With that in mind a good programmer will access the database as few times as possible in order to fill the needs of the current application request.

One way to facilitate this noble goal is to store any information that your application needs in memory once it has been retrieved from the database.  A “get once, use often” approach can go a long way towards helping with performance (and to a lesser degree code readability).  Some information that is used so often that is even worth storing as a session variable in order to eliminate a request (database, disk, whatever) altogether.  Be careful with those, though, as they are often targeted for hacks and should never be solely depended on for functionality and should never contain any private information.

#8 Never use arcane plugins

Plugins and third-party code can make development go much, much faster.  Often times you can get more complete functionality by using them but there are trade-offs for this convenience.

  1. You have to learn to think like the person who wrote the plugin in order to use it
  2. You usually don’t know how the internals work
  3. They’re almost never meant for the exact situation you’re in

With all that said, the right add-on or plugin can be a life saver and you must, must, must be careful when evaluating whether or not to use one.  Here are some questions to ask to help decide whether a plugin is right for your app:

  • Does it do everything I need exactly as I need it right out of the box?
  • Is it well documented?
  • Does it have an active user and support community?
  • Has it been updated to coincide with major platform releases?
  • Is the documentation in your native language (yes, seriously)?
  • Will it take longer to write the functionality myself than learn to work with this plugin?
  • When I (or someone else) inevitably has to maintain or change this app in the future will it be easy to work with or around this plugin?

If the answer to any of these questions is “no” you should be wary.

#7 Always remove unneeded functionality

This one kind of comes with a caveat:  every programmer should know to use a good and dependable source control tool.  Even if you are the only person working on the code, a good source control tool can (and likely will) prove to be a life saver at some point.  You’ll cruise along not even knowing you need it and then BAM – you implement sweeping code changes that break everything.  If you’re using a source control tool correctly, undoing your changes should be fairly quick and painless.  If not, you may have just lost a client or a job.

With that in mind, try to never, ever leave unneeded functionality in your code base.  If you have written a great piece of functionality that is no longer needed delete it immediately.

When you’re actually making changes that steer you away from existing functionality you understand why you no longer need the functionality and you likely have an idea of what else it touches.  When you come back in six months, after seeing two or three other projects, you will likely have NO idea why that functionality wasn’t previously removed.  You’ll think, “Boy, I didn’t remove this, something somewhere must be using it.”  This problem compounds itself when you’re forced to start writing code around undeleted, unnecessary functionality.  So in the end it’s easier to just remove code and keep your code base clean.

#6 Always consider performance

What makes a good programmer?  The ability to effectively juggle the following points and still deliver timely, effective solutions:

  • Performance – is the code minimal and fast?
  • Scalability – is the code able to be expanded upon easily?
  • Manageability – how quickly can modifications be evaluated, estimated and made?

The preference for which of these to focus on first differs from programmer to programmer and often from project to project.  This is part of what gives each programmer their individual style.  But good programmers always consider all three, no matter the situation.  Readability falls under manageability, abstraction falls under scalability and everything falls under performance.  So no matter what your programming personality and style is, you should be considering performance.

I’m not (necessarily) referring to spending hours pouring over 10 lines of code to make sure it executes as quickly as possible.  I’m talking about taking a solid fundamental approach to gathering and manipulating data that doesn’t do any one piece of functionality more times than absolutely necessary.  #9 above eludes to this, but to go a little further:

  • Get your data once and use it in as many places as possible before disposing of it.
  • Have the absolute minimum amount of functionality inside loops.
  • Never perform accesses (disk, database, service) from within a loop unless absolutely necessary.
  • (In strongly typed languages) Know and use appropriate data types.
  • (In web apps) Perform as few server requests as possible.

If you think of things like this from the beginning of your project you are less likely to have performance issues in the end.  If you don’t agree with me now that it’s worth the initial extra effort you will after you spend 4 weekends straight rewriting poor performing code because you tried to save 10 minutes on the front end.

#5 Never nest major logic / functionality in loops

I mentioned this one under heading #6 above, but it bears repeating.  Loops are often the heart of any application, but they will absolutely kill your app if used improperly.  So you must be wary of anything that falls into a loop.

Loops are something we have to use often, so every good programmer should know how to abstract functionality out of a loop (see #1 below for a simple example).  Besides the performance hits, tracing through functionality that is inside of a loop can be much more difficult because of all of the variables that come into play while looping.  Modern debuggers help tremendously with this task, but better tools shouldn’t excuse poor programming practices.

When you have time to review your code, start by reviewing loops and seeing if anything can be moved outside of them.

#4 Document effectively

There is a school of thought among some programmers that says, “Either you can read code or you can’t, why should I document it for you?”  And while this is true in theory, in practice adding appropriate documentation inside code makes it far, far easier to maintain.

Proper documentation is a skill and overdoing it is almost as big of an annoyance to those trying to maintain code as not doing it all.  Consider the following:

  • DO – denote reason and logic
  • DO NOT – denote functionality or process

What that means is:  tell the future programmer looking at this code why you did something, not necessarily how.  The “how” is the stuff they should usually be able to read on their own (unless you have to do some crazy, non-standard stuff).  More often when looking at the code they need to know “why” you did things a certain way.  Consider the following simple example:

for (int i = 0; i < var.length; i++) {

Now let’s consider two commenting options:

// iterate over each var
for (int i = 0; i < var.length; i++) { // increment i if it's less than vars.length
    doSomething(var[i]); // do something with the var at position i
} // finish the loop

– or –

for (int i = 0; i < var.length; i++) {
    doSomething(var[i]); // mark inactive vars for deletion

Now the first one tells you what is happening, about as pointlessly as a voice-over in a movie saying exactly what the characters on screen are doing. The second one assumes that you know what is happening functionally and instead just tells you what’s going on logically, which is far more valuable information when you’re in “put out the fire of the forest variety” mode.  In the first case, the future programmer would need to look up doSomething(var) and figure out what it was accomplishing. In the second version that information is at hand and valuable.

Which would you prefer if you got a call from an executive at 4:45PM on Friday that forced you to review this code?

#3 Use effective and logical variable names

There are a LOT of thoughts on this one and almost every programmer has a slightly different way of doing it.  So I’ll try to be ambiguous so we don’t start a war over it.

It is important to consider your variable names carefully.  Sometimes having the data type as part of the name is appropriate (intId) and sometimes that sort of thing can be inferred (id).  Either way, the name of the variable should hint towards the usage of the variable (note that “id” was in both).  Names like (vulSpok) and (humKirk) are not useful.

Now possibly just as important as choosing your style of naming variables carefully is being consistent.  As a programmer your code will have a certain “style” that others who inherit your code will have to learn in order to quickly and easily maintain your code.  That “style” may not be the same as theirs, but as long as it is consistent (and logical) you’ve done what you can do.

#2 Catch errors, or don’t

Let me start by saying that I know, academically, all errors should be caught and handled gracefully.  Let me also say that realistically, that almost never happens when deadlines are looming.

Hopefully the days of “Dr. Watson encountered an error” are behind us for good.  Most modern platforms will let applications die with a pretty decent error message.  So while it may not be ideal, letting errors fall through to the default error handling is better than manually mishandling the errors.  On internal or limited usage applications this can actually provide a pretty good idea of what the actual error is and where to start looking to fix it.

Now in an ideal world, programmers would have time to code a catch for anything that went wrong and do something cool, super-ninja style.  So if you have time and budget you should catch all possible errors and handle them.  If not, don’t catch them at all.

Just never, ever catch errors and do nothing.

#1 Never duplicate functionality

Reusable code is the holy grail of good programmers.  A good programmer should always be on the lookout for a way to write functionality once and then use it all over the place.  The benefits to this are too numerous to count.

So what is reusable code?

Let’s say, using our example above that you need to loop through your vars and doSomething() with them.  You could do it this way:

for (int i = 0; i < var.length; i++) {
    // mark inactive vars for deletion
    if (!var[i].isActive) {
        var[i].readyToDelete = true;
    } else {
        var[i].readyToDelete = false;

– or –

private void doSomething(var) {
    if (!var.isActive) {
        var.readyToDelete = true;
    } else {
        var.readyToDelete = false;

for (int i = 0; i < var.length; i++) {
    doSomething(var[i]); // mark inactive vars for deletion

It ends up being 3 extra lines of code in this example that will save you 4 lines of code each time you use it somewhere else.  So the first time you re-use the code in this rudimentary example you’ve saved yourself 75% effort across the board (coding, debugging, refactoring, etc).  Pretty nifty, huh?

Additionally, if you ever need to change the evaluation logic to, say, make sure that there weren’t any records that may be orphaned by deletion, you could change that logic in a single place and it would work everywhere throughout your code.

If you have any major items to add, feel free to do so in the comments.  If I get enough good ones perhaps I’ll update this article to include them.

10 Ways To Suck At Programming


I recently inherited a web app from a dirty, nasty, stinking contractor that claimed to be a competent enough programmer to be left alone to get things done. Unfortunately, we took him at his word. Functionally, most of the web app seemed to work at first glance. However, once the client took over the reins and actually started using it things went downhill fast. The contractor disappeared after payment (die reputation DIE!) and I was left to try and get things working properly and performing up to snuff while the client limped along with what they had been given.

I decided to document a few of the things that I found wrong along the way.  These are really just things that every good programmer should already know to avoid… but obviously some people need to be reminded (or taught).

Update – 05.18.2010 – Some people thought that this article was too sarcastic.  While I thought it wasn’t sarcastic at all, it does exactly what the title promises and teaches people to suck, I’m always game for being constructive.  So I wrote an offset to this article – 10 Ways To NOT Suck At Programming.

#10 – Don’t store settings in a configuration file

When you’re writing a sizable application, things like database connections and SMTP server information will be used throughout the app.  The best way to make sure your app is entirely immune to maintenance is to redefine those little bits of information every time you need them.  So instead of putting them in the configuration file (Web.config or whatever) just leave them in your compiled code.  Whoever inherits the app will thank you for sending them on a hunt through thousands of lines of code to change which SMTP server is being used.  What’s even more fun is when the next programmer only finds 14 of the 15 places where you’ve used this code and a single instance somewhere deep in the app silently breaks hundreds of times without anyone knowing.  Sometimes it’s helpful to build the variables in inconsistently concatenated strings. The repeated and more frequent interaction between the new developer and the disgruntled client will help strengthen their relationship.  And if you don’t hook up that love connection, who will?

#9 – Don’t store variables in [any] memory scope

One of the great things about databases is they store your bits of information and allow you to access them whenever you need them.  To make sure your app is as terrible as possible, you’ll want to be sure and access the database every time you need a bit of that information.  The more common the information is that’s needed, the bigger win you’ll have by making a new database connection to get that information.  Non-sensitive user information is a great use of this prinicple.  Don’t worry about defining a user’s information, such as “isAdmin” to a variable and using it throughout the current request.  Just query the database each time you need to know anything about the user.  After all, the client paid for that database, we’d better get as much spin out of it as possible!

#8 – Use arcane plugins

If the client has a non-standard request, such as formatting a table in a way that is outside the abilities of your WYSIWYG editor (colspan are hard).  You should definitely hit up the interwebs and search for random unsupported closed source plugins to do the work for you.  If you would spend almost an entire hour writing it yourself, you should spend at least 3 hours searching for and getting a plugin that does roughly but not exactly the same thing.  Bonus points if you can get a plugin that doesn’t do what you need, but offers 15MB+ of functionality you have no use for and include it without getting caught.  Bonus bonus points if the documentation for that plugin is in a language not native to your market (for example, if you’re working in an English speaking shop look for plugins that are documented only in Spanish or German).

#7 – Never, ever remove functionality

Over the course of developing a large application there are bound to be times when functionality you were working on proves itself to not be needed.  Now, to be sure to leave plenty of dead ends for those who come behind you to get lost in, never delete that functionality.  Maybe even comment out random parts of it, or even hundreds of lines of it at a time, but don’t delete it.  Imagine the hours of fun the future-crew for this app will have while they trace through this functionality only to find that it isn’t needed!  If you can make it seem needed, without actually needing it, it will even keep them from deleting it themselves…  This way the fun is exponential!  Oh, a bonus on this one… if your project uses source control and multiple server environments, be sure to have a different version of your files (both code and compiled) on each server and source control.  This way no one will know which one is live in production and who doesn’t love a good round of Code Russian Roulette?

#6 – Screw performance

Large applications, you know, the ones that pay the bills, are generally needed because they deal with large amounts of data.  Sure, during your development process you’ll create 20 or so test records.  Take my word for it, there’s no need to even worry about what happens once you get to 25 records, or even 1,000!  Obviously, all pagination will work just fine and performance will never take a hit.  So if it compiles, ship it!

#5 – Nest major logic/functionality in loops

Now obviously, we’ve already covered #6 so we know that we’re working with large amounts of data.  And inevitably, there will be plenty of looping through that data to do work with it.  If you want to make sure your application is really difficult to maintain and completely unusable to the client, you should embed major functionality and/or logic inside of these loops.  For example, instead of running a query against the database to get ALL the data you need, storing the data in memory and working with the variables in memory during your loop, just get all the data except one field up front and loop through it… then on each loop you should get all the data again, and now include your extra field.  This will guarantee that your app will never survive more than 5 concurrent users (re: #6).  So for review:  Get data > create loop > get data > work with data.  I’m sure you see some room for added idiocy in that process, so feel free to nest this idea as many times as you want.

#4 – Document NOTHING

Look, documentation is for morons.  I mean either you can read the code or you can’t, right (this was actually said to me at one point)?  Of COURSE the next programmer will be able to read the code.  What’s really fun though, is when you document absolutely nothing, especially not your intent.  It pays to keep them guessing.  You’re mysterious, like a ninja.  No need to let someone get all up in your grill, knowing everything about what you were trying to do.  Because if you document what you’re trying to do and then don’t end up doing it… well… that’s just embarrassing.

#3 – Use and reuse illogical variable names

There’s going to be a LOT of variables needed to work on this app, so you’d better choose a movie or television show with enough characters to use all the names.  Lord of The Rings, Star Wars and Family Guy are all good choices for this.  Maybe you can even form relationships with the variables.  That way, you never have to kill them!  You can have variables that are chameleons, changing their usage and values throughout processing and you can recycle them for something new each time you need a variable for new functionality.  It’s like they’re growing up, evolving, right before your eyes!  After all, you’re trying to be green and reduce your carbon footprint so recycling variables just seems like the responsible thing to do!

#2 – Catch all errors — and do nothing with them

Most languages / platforms nowadays have really good error handling built in.  They’ll die somewhat gracefully and give enough details through the default error output to be helpful.  You must not allow this to happen!  Start off by wrapping nearly every tiny piece of functionality in a try / catch phrase.  Then… inside the catch… put a comment, like “// It borked lawl.”  This will ensure that if anyone wants to work on this app, they’d better spend the time getting to know the app and it’s adorable character variables before they start wrecking the app altogether.

#1 – Duplicate functionality

If the client tells you that they need two pages:  One for an administrator that has all of the details on an item along with a button to delete it; and one for a regular user which has all of the details on an item without a button, you should create multiple pages to accomplish this.  In fact, if you can make pages for each user group that would even be better.  Making a separate page for each user is the ultimate success.  So ninja up and get serious on this one, because it’s your last line of defense against the teeming hordes of qualified individuals who will inevitably be bewildered while trying to update your carefully constructed Pandora’s box of an app.

This is by no means a comprehensive list.  On this project alone I could name 10 more things that could make you suck.  But I’ll leave it at 10 for now.  Anyone have more to add?

Go to Top