Ah, the arrogance of software developers. (I’m a software developer myself, so I figure I have carte blanche to take aim at the foibles of my profession.) Why, just the other day, I reviewed a legal document, and pointed out several places where I thought it could be improved (wording, some incorrect references, and whatnot). Now, why do I think that I have any business looking over a legal document (a real lawyer will check it over too)? Well, why shouldn’t I? I think that most developers have a couple of the characteristics/behaviors listed below, and that these can lead to such arrogance.

1. Asking questions

Many developers have no fear, even take pride, in asking good, difficult questions about technical topics. Asking such questions can become a habit. A developer may ask a question, and feel comfortable about it, when he/she is entirely out of his/her depth.

2. Attention to detail

Developers tend to be capable of focusing on one thing to the exclusion of all else. This often means that, whatever the idea that comes along, a developer will focus on it exclusively. Such focus may turn up issues that were missed by the less attentive, or it may just be nit picking. (Finding small issues isn’t nitpicking when one is developing–it’s pre-emptive bug fixing.)

3. Curiosity and the desire to learn

Most developers are curious. In part because computers are so new, and in part because software technologies change so rapidly, hackers have to be curious, or they’re left behind, coding Cobol (not that there’s anything wrong with that!). This sometimes spills out into other portions of their lives, tweaking their bodies or the mechanics of an IPO.

4. Know something about something difficult

Yeah, yeah, most developers are not on the bleeding edge of software. But telling most people what they do usually causes some kind of ‘ooh’ or raised eyebrows conveying some level of expectation of the difficulty of software development. (Though this reaction is a lot less universal than it was during the dotcom boom–nowadays, it could just as easily be an ‘ooh’ of sympathy to an out of work .) Because developers are aware that what they do often isn’t that difficult (it’s just being curious, asking questions, and being attentive), it’s easy to assume that other professions usually thought difficult are similarly overblown.

Now, this arrogance surfaces in other realms; for example, business plans. I am realizing just how far I fall short in that arena. I’ve had a few business plans, but they often fall prey to the problem that the gnomes had in South Park: no way to get from action to profit. I’m certainly not alone in this either.

In the same vein of arrogance, I used to make fun of marketing people, because everything they do is so vague and ill-defined. I always want things nailed down. But, guess what, the real world is vague and ill-defined. (Just try finding out something simple, like how many people are driving Fords, how women use the internet, or how many people truly, truly love Richie Valens. You appear to be reduced to interviewing segments of the population and extrapolating.) And if you ask people what they want, they’ll lie to you. Not because they want to lie, but because they don’t really know what they want.

I guess this is a confession of arrogance on the part of one software developer and an apology to all the marketroids I’ve snickered at over the years (oops, I just did it again :). (I promise to keep myself on a shorter leash in the future.) Thanks for going out into the real world and delivering back desires, which I can try to refine into something I can really build. It’s harder than it looks.

2 thoughts on “Arrogance

  1. Tom Malaher says:

    My sister the lawyer made the reverse comparison for me.

    She said that writing a contract properly is like writing code: if you miss a corner case or one of the clauses in an if-else, you end up in “trouble”.

    In the case of software, “trouble” is undefined behavior or an exception being thrown. In the case of a contract, “trouble” means someone ends up in court.

    Programmers (Lawyers) carefully write code (contracts) to avoid “trouble”.

    My sister described going through a contract that one of her clients had written up himself, finding all sorts of missing cases. She kept saying to him, “What happens if …”, and he kept saying “Oh, I didn’t think about that.” She’s trained to think this way about contracts. The client isn’t. In just the same way, a novice programmer, who only knows the *syntax* of a programming language, can write code that compiles, but will fail miserably at runtime.

    This discussion gave me a whole new appreciation for what lawyers do (at least contract lawyers), and why they use language in such strange ways. They’re trying to “write code” using English, and so they end up having to assign specific meanings to words in order to be unambiguous. And note that it’s difficult to “debug” a contract. You only get one shot. So to that extent, being a lawyer is *harder* than being a programmer.

    Interesting link:
    http://www.groklaw.net/article.php?story=20040508214237601

    This shows two different versions of SCO’s complaint against IBM. The third column is IBM’s response. Check out paragraph 18(20) where SCO purports to define the Unix Operating System, and OS’s in general. I like IBM’s repsonse:
    “20. Denies the averments of paragraph 20, especially insofar as they purport to describe all operating systems or purport to identify UNIX as a single operating system.”
    Daimler-Chrysler’s response was a simple “Deny”, which I thought was incomplete. IBM’s lawyers have done a much better job, and obviously talked to some techie people during the process.

    I’ve been through one of these response-to-lawsuite processes, and the deal seems to be that you want to respond to each point (any point not responded to is considered as a stipulated fact in any future proceedings) and so the default response is to Deny. (Check out the response to Para 5)

  2. Dan Moore says:

    I used the reading of a law document as an example; I can think of plenty of other cases where I’ve assumed knowledge (and took stances based on that assumed knowledge) that I just didn’t have. User experience, database design, and company organization are all some.

    Maybe other professions are just as … generous in assuming that because they have skill X, it translates across a wide range of other disciplines. But I’ve not really seen that.

Comments are closed.


© Moore Consulting, 2003-2019