I’m having something of an interesting experience at the moment- a real life learning experience. I find myself sitting on the other side of the table. See, I’m hiring a lawyer.

Some explanation is in order here. All my adult/professional life, I’ve been a software developer- which means that people come to me with problems to solve (mainly by writing code). And the customer always has an idea of what they want- precise, impossible to articulate, and (as a general rule), wrong. Or, if they’re being honest, they have no idea what they really want, they’ll just know it when the don’t see it. And I’m stuck trying to translate the handwaving, blobs and lines drawn on a whiteboard, and “you knows… kinda like but not really”s into terms that make some sort of sense in terms of computers and software. Preferably with only reasonable amounts of work involved (’Hurt’ is not short for ‘Hercules’, and Kevin Sorbo I am not).

The law is like software, in that it’s arcane, complicated, and strange. And you really want a professional involved (even better, a competent professional), or the results will be expensive, painful, and drawn out. Actually, the law, done badly, can be even more expensive, painful, and drawn out than software.

As a side note here- this is why license agreements written by programmers are worth as much as code written by lawyers. If you not know the language, and more importantly operating environment (also known as the body of precedent), you’re in for a world of hurt. For many of the same reasons.

So anyways- now I’m finding myself on the other side of the table, handwaving a lot, with more than my fair share of ums and kindas and you knows. And counting myself lucky that the guy on the other end of the table not only knows the law- he also knows my business, software. Which allows me to use terms specific to the problem domain at hand, like “cross module inlining” and “functors”- and he understands what I’m talking about (or can be taught with a very small amount of highly techincal explanation).

Which brings me to the real point of this rant- in my opinion, it’s not enough to know programming. You need to know something else- you need to know your customers business, whomever your customers may be. Programming is like Celtic music- pretty boring by itself, but great when mixed with something else. In my CD, I have lots of celtic plus something music- celtic plus rock, celtic plus classical, celtic plus jazz, celtic plus african, celtic plus new age- but no pure celtic. My all time favorite celtic back (the now defunct, alas, Six Mile Bridge) was two electric guitars, drums, and a Hungarian mandolin. God save me from the Clancy Brothers or the Irish Rovers- despite my ethnic heritage, that stuff is just dull. Now, Eileen Ivers doing “Pachabel’s Frolics”, where she starts the song in classical Violin mode, and ends the song in the pure Irish Fiddle (the difference between classical violin and Irish fiddle is one of attitude, not instrument), now that’s interesting.

And valuable- as a programmer, you are there to solve problems. This has a lot of implications. Solving the problem(s) may, likely even will, involve writing code. And debugging code- code that doesn’t work right doesn’t solve the problem, and thus has no value (except to the extent that it might be fixed and thus solve the problem). I don’t care if you are the grand national champion alligator wrestler, you’re there to drain the swamp, and you need to keep that in mind all the time. And customers don’t generally care about meta-solutions, things that aren’t solutions but might be turned into solutions with some programming- how is this different from the customer’s point of view than where they started? Beware of over generalizations. And so on.

You’re there to solve problems, and the first step to solving a problem is know what the problem is. Which requires knowing you’re customer, the person you’re solving a problem for. So, the most important thing for a programmer to know is something other than programming. This is something most programmers forget, and that we don’t do enough to teach new people coming into the business. And that’s a question we should be asking ourselves constantly. What problems are we solving? Who are our customers? What are their needs, possibilities problems?

Something every college student studying CS should know is that all programmers are, by necessity, double majors. That’s what I’m learning again, being on the other side of the table.

So, what’s your major?

Popularity: 3% [?]

Trackback URI | Comments RSS