The most difficult problems you will ever face as a programmer

Niagara Falls and city lights at night I was given a problem to solve at work earlier this week and I pretty much totally choked.  To be honest it wasn’t that hard of a problem – I obviously can’t share it with you here, but I will say that (among other things) I completely, totally blanked on how to find if two lines on a plain intersect and didn’t have a laptop handy to look it up.

This bothered me all week and got me thinking about my career as a programmer and the kinds of problems I’ve been asked to solve.  Everything we do as programmers, developers, or software engineers boils down to solving problems–so what have I been doing all these years?  Finally I realized that of all the difficult problems I’ve worked on in my professional career, most of them were difficult because of:

  • Imposed constraints;
  • Convoluted business rules and vague requirements;
  • Political or organizational issues; or
  • Human factors.

That last type of problem I actually really enjoy working on, but let’s put that aside for the moment.  Notice anything missing from that list?  Only rarely have I encountered problems that required really complex logic, difficult algorithms, or lateral thinking.

Why is this?  Have I shied away from those sorts of problems, or been unable to hack it?  I don’t think this is the case.  I did well enough on the SAT and GRE, and I can usually get myself back up to speed for solving logic puzzles in a week or two.  My guess is that my career is pretty typical, and that most of the problems that most companies face are due to constraints, vague business rules, organizational issues, and human factors.

This flies in the face of the kind of education most of us get as programmers.  At OWU the computer science department always erred on the side of math – we spent more time on concepts than practical applications.  I really, really value the kind of coursework I had in college but when it comes down to it, I learned just two things that I use on a regular basis:

  • Basic concepts and common programming paradigms; and
  • How to learn new languages, programming paradigms, etc.

I really enjoyed discrete math, but have rarely needed all the combinatorics.  Hacking scheme in my AI class was very cool but that’s the last time I’ve done any alpha-beta pruning.  I have successfully solved problems with some relatively mundane insights:

  • Don’t rely on memory, take notes and find references.
  • Look for low-hanging fruit.  Does the database even have indexes?  Do you really need to debug 2,000 lines of Javascript that essentially reimplement the concept of linking?
  • If you ever have a technical quandry, you’re probably not the only on in the world with the same question.  Chances are one of those other people has already asked the question somewhere on the web, and with a little luck someone else has already posted the answer.
  • Don’t get involved in political struggles between teams and don’t play the blame game.  Be unerringly pleasent in contentious situations, and if someone agrees to something in a meeting follow up with and email or some kind of documentation.
  • Prototype and iterate, people tend to use vague terminology and don’t always want exactly what they think they want.

So, if you’re going to end up implementing shopping carts or interfaces between large internal systems most of your career, why bother with brain teasers and algorithm interview questions?  Does this mean all that fancy book learning should be thrown out the window?

No!  Of course not!  If you do, when a really juicey problem does come along you’ll choke like me.

I’ve come to the conclusion that I need to make a concerted effort to look for problems that are difficult not because I don’t have enough time to do them, or because the two teams involved hate each other, or because the business analyst said “X is always Y” when he meant X is usually Y.  My guess is I’ll be hit with some soon at work.

In the mean time, got any good logic puzzles?  Textbook problems?  Favorite websites?  Feel free to post them in the comments below to get me started.

2 thoughts on “The most difficult problems you will ever face as a programmer

  1. I find that math is scary for me, (I’m still twitching from the two lines on a plain comment), however logical puzzles can be fun and engaging. They can also drive you right up a wall until that moment when you realize the answer. The best ones take a few sentences (or even only one) to setup the situation and leave you to come up with the answer. So, here is one for you. The answer is quite simple, once you figure out the shortcut through all the clutter. Riddle: A man lives on the 8th floor of an apartment building. Every day after work he walks home and takes the elevator to the 3rd floor and then takes the stairs the rest of the way up. On days when it rains he rides the elevator all the way to the 8th floor. Why?

  2. One tool I used to make learning the hard stuff easier was to learn the art of proof. In maths, you can use something as simple as statistical analysis to intuit the theory, and in compsci you can use simulators. Some of my greatest leaps in compsci and maths were in discoveries resulting from simulating the problem space. And,writing simulators (and analysis tools) is solid learning in itself.

Comments are closed.