Lessons From A Lifetime Of Being A Programmer

Over my 3 decades of being a programmer, I have learned a few things. Here are a few goodies. I bet I can make more.

• Customers only know what they want after they see it.

I learned this in my first job. Customers won't realize what is actually necessary until you can show it to them. Functional prototyping always beats long lists of words.

• Given enough time all security will fail.

Security in today's world is incredibly challenging to get right. You have to be perfect all the time but a hacker only has to succeed once to defeat you.

• Given that your security will fail the outcome depends on whether you planned for that situation ahead of time.

If you assume an attacker will breach your defenses eventually you need to plan for what will happen then. If they get in but can't use what they steal because you used properly security practices such as making database contents undecipherable or isolating servers from each other you make the likelihood of being on national news low. Defense in depth always beats a thin layer.

• Good security is not an expense but a strategic asset; bad security is an expensive kick in the assets.

All throughout my career I've heard people complain about how complicated or expensive it is to do security right, yet when it fails you can wind up losing billions of dollars more. Saving a few bucks only to lose your company is dumb.

• It's hard to make something complex that looks simple but it's easy to make something complex look even more complex.

This is true in programming, in design, in almost any creative act. I've always tried to write code that was as simple as possible for me (or anyone else) to understand. If you try to make code too complicated or too clever the likelihood that it work correctly is low. Of course I've seen code forever where the programmers went through enormous effort to make things incomprehensible.

• Success comes from learning from your mistakes; failure comes from thinking mistakes are normal and to be tolerated.

I've heard so many people claim that since programming is hard continually making mistakes is normal and crappy software is inevitable. People also learn to tolerate crap because they've heard this repeatedly. Yet you as a programmer shouldn't accept this and try to make any mistake only once. The hope is that eventually you've made them all once and now you are likely to only make non-crappy software. No one is ever going to be perfect but you need to be on that road at least.

• The only thing that never changes is change itself and you can't change that in any way.

Planning for the world of tomorrow thinking it will be just like today is pretty dumb. Especially in the programming world nothing lasts forever. A luddite attitude, thinking you can keep change at bay, never works.

• Never stop learning, the technology steamroller is right behind you waiting for you to stop.

My favorite metaphor is the big roller right behind your ass trying to run you down. It's the only way to last a long time as a programmer, knowing you have to keep moving forward. Once you rest and figure you know everything you wind up a flat spot in the road.

• The entire software industry is built on top of wild ass guesses.

All my career people have insisted on estimating how long something will take, whether small or large, and all my career everyone has always always wrong. Long ago prophets who foretold the future incorrectly were stoned; these days they just roll into the next sprint.

• Just because it works for you it doesn't necessarily work for me or the programmer behind that tree.

There are an infinite number of choices you can make in any software project. Some of them will be superior, some acceptable, and most terrible. But what applies to you and your situation and your set of choices might not be applicable to others at all. It's always good to hear what other people are doing but I've always disliked when people insist that what they do is the only way to do something well.

• The most important skill in an ever changing world is evaluation.

This isn't obvious to everyone, but the ability to see something new, or see what others are doing, or to compare multiple ways of doing something and then pick the best option for you, your team, your project or even your company is incredibly valuable. Most people I've seen are not very good at this. Most leaders are really terrible at this. It's easy to just do what someone tells you you should do or something you read in a blog or just do what everyone else is doing. It's much more difficult to look at things from all sides and your needs and pick something that seems to be best at that point. Of course you have to make some decision, people are often paralyzed by having to evaluate which often leads to picking something random or following the herd.

• There is more than one way to skin a cat; from the cat's perspective it doesn't matter.

Customers don't care what your problems are they just want your software to do what they need done. If your systems are failing, exceptions are happening, your hardware is broken, your programmers are terrible, hackers are hacking: it's not really of any interest to the users. It's nice to be honest when things go wonky, as they will sometimes, but it's better to ensure the crap is unlikely long before the customer ever sees your work.

• Quality is best measured at the customer.

No matter how many metrics you might have, how many checklists you have checked off, how many code reviews you practice, how many tests you wrote; none of this matters unless the customer sees that your software does everything it's supposed to do and never does anything it's not supposed to do. The customer's opinion of your code's quality, performance, design and usability is ultimately the only thing that determines quality.

• What you don't know will kill you because you failed to log anything.

I am constantly amazed even today that people still don't collect sufficient logs, crash reports and usage information to know for a fact what their software is doing. People who don't collect such information always overestimate the quality. You won't know if you don't measure and record. The customer of course will. I've always insisted on detailed and useful logging, tracking crashes, reading reviews and comments and anything else I can get my hands on to know of any problems as soon as they happen. Yet I've known people who think such things have nothing to do with being a programmer.

• There is always some better way to do anything but time marches on.

The hardest balance in evaluating what to do is when to stop looking. You might miss a better way but if it takes too long there might be no further reason to do anything. This is hard to get right but sometimes making a lesser choice today beats a better choice next year.

These last two are quotes from a salesperson I worked with a long time ago. Not exactly something I agree with, it is a lesson of sorts.

• Always look for dumb customers with money.

My favorite quote from a salesperson I knew at a consulting firm. From his perspective, finding people who don't understand technology but had plenty of money to burn was the mother lode. Smart people ask too many questions; poor people can't afford to pay you. I'm glad I'm a programmer!

• My job is to lie to customers, your job is to make me look good.

My second favorite quote from the same salesperson. He loved to promise the impossible and then reap the rewards when we actually made it work. It's cool to get to do challenging things but doing the impossible every time is too much pain. My suggestion is find a better salesperson!