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.
