Thursday, March 28, 2013

Programming in the Real World

I've been thinking a lot recently about the difference between how I program now versus what I thought programming was in college, in part because I've had the task of trying to convey that difference to several very bright and energetic recent graduates.

Here is some food for thought:

Choosing what to work on is choosing what not to work on.

There's always more work than time.  You have to choose wisely what is worth the effort, not from some snobby sense of code righteousness, but from what is most important for your users, what develops your application towards the ideal, and what can deliver the best experience for the investment.

Every change carries risk.

Even trivial changes can break things in ways you may not discover until later.  A code refactoring that shouldn't theoretically make a difference opens the door to unpredictable outcomes.  It's better to leave something alone if you aren't willing to test it.

Simplicity is better than elegance.

I love perl, but perl has a bad reputation for being unreadable.  A perl guru can probably solve a string manipulation problem in one line, no matter how complex.  Good luck maintaining that in the future, or getting someone else to maintain it.

Making it easy to understand is important for the future you.

There's a myth out there about programmers writing obscure code as "job security".  This is baloney.  Job security comes from doing good, dependable work, and writing unmaintainable programs will only make it harder on yourself later.  Writing code that's easy to understand isn't just for other people.  When you have a project that lasts longer than a semester (mine is over 7 years old now), you will not be able to remember it all, and having confusing method or variable names will only degrade your own productivity.

The art is in how you organize.

Figuring out what the algorithm is will only solve half the problem.  The implementation of an algorithm does not necessarily suggest a class hierarchy, method organization, or a data structure; you still have to implement that algorithm in some form.  This is where the true artistry comes in, to be able to express the algorithm in a way that is correct, minimal, efficient, and easy to understand.  And the only thing you have to work with is how you organize all the pieces.

The interface matters.

What do you call this method?  Is it public or private?  If it's public, can it successfully be executed out of context, or does it have dependencies that will cause it to break?  How your class presents to the outside world, and whether it delivers what it advertises, will make or break its usefulness to other members of your team.

Plan for the future, but implement for the present.

You want your code to be extensible in ways that allow it to grow.  But you don't want to spend all of your time implementing all of that growth at the beginning.  Create an architecture that allows for growth, but only implement what you need.  By the time you are ready for that growth, it may not be exactly what you originally thought it would.

Performance matters.

Unless you work with purely conceptual machines, or you're trying to solve P=NP, it's not enough to write an algorithm that can provably solve a problem.  It has to do it within the timeframe required, which might be seconds.  If you're working on the web, making your users wait for even 2 seconds might be enough to frustrate them.  Little mistakes, extra unnecessary iterations, methods that do extraneous work, can add up when executed many thousands of times over.

Write UIs for your mother

Unless your mother happens to be a computer professional, then pick someone else.  Know your audience, and make things simple.


  1. Nicely put. I'd throw in 2 references which address some of your themes:

    1: Simplicity is Wonderful, But Not a Requirement (

    2: Expertise, the Death of Fun, and What to Do About It (

    I take issue (but not here in a comment) with "performance matters". I think it's sufficiently nuanced we could each write books on it.

  2. You see, this is why programming blogs tend to be kinda useless - the author takes his own personal niche and assumes every other niche works just like that. Yes, this works for in the field you work. For example in the payroll software world there would be different rules.

    1. Miklos: You're welcome to your opinion. This is mine. I didn't presume it to be anything otherwise.

    2. I would like to drop in and say (as someone who has implemented said payroll software) these core abstract ideas apply to crafting anything. There's nothing wrong with this advice, especially to young programmers.

  3. This is pretty good general advice for any kind of developer trying to write maintainable code. Not only for other developers, but for "future self" as well. I can't tell you how many times I wanted to punch "past self" in the face for writing bad code, lol.