Drive

I recently received an e-mail relating how certain programming constructs look elegant, but turn out to be grossly inefficient.  That got thinking about abstraction frameworks and how they increase perceived development speed, yet can have unintended consequences (performance being a big one).  That, in turn, got me thinking about why the guys on the thread could immediately spot the underlying inefficiency through visual inspection.

Are they inherently smarter? Maybe.

Did they screw up a similar project and learn? Possibly.

Are they driven to understand how things work at a fundamental level? Check.

What separates these guys from the huddled masses is an innate drive to understand their world (in this case, software engineering) down to the ones and zeros.  I’ve sat next to both of them while they code.  They have debuggers, output windows, browsers inspectors, and SQL execution plans running well after typical developers would have committed the code.

They have a drive to know their code is correct, fast, and readable.  They dissect it, improve it, and test it.  If someone is going to break their code, it will damn sure be them, not someone else.
But you protest.  Surely, they must not understand deadlines!  Clearly, they take longer!

You protest in vain.  These guys are among the most productive guys I’ve worked with.  Their code is clean before they release it.  There is rarely rework.  Because they have spent so much time understanding their tools, they avoid mistakes made by developers who focus on getting it done and checked-in.

Their breadth of understanding allows them to quickly select appropriate constructs and patterns based on the problem.  Contrast this with developers forced to solve problems based on what they know versus the nature of the problem itself.  More importantly, their depth of knowledge allows them to know why their solution will work and what its limitations are.  Most developers won’t fully understand why their solution works. Or what problems it can’t solve.

I’ll leave things here.  I plan to return to this last paragraph in a future post.