Wednesday, July 25, 2012

In my last post, I ended with a comment about the importance of understanding solutions in order to solve a broader range of problems. Problems have an essence. If you understand the essence of a problem, you can draw from solutions for that class of problems.

Consider the problem of managing vaccination history for a patient. Take a moment to enumerate the essential characteristics of this problem. Can you think of systems you have seen or used that address problems with similar characteristics?

What would you say if I told you that tracking vaccinations is a very similar problem to your vehicle’s recommended maintenance schedule? If you don’t believe me, next time you get your oil changed, ask to take a look at the screen the service manager uses to upsell you on a new air filter. Replace each recommended service with a vaccination and you should see what I mean.

Experience with and exposure to varied solutions is important. However, it is not enough. You must internalize the relationship to the problems they solve and the essence of those problems.

Here is an approach that may help:

When you use tools (physical or software), identify the problem the tool solves. Ignore the features – focus on the problems. For example, don’t think of a hammer as something to “Drive a nail into a wall.” Think “Deliver force to an object.”

When solving a problem, tease out its essence. Find solutions that solve problems sharing essential characteristics. For example, replacing the lid on a paint can requires the use of directed force to seal the canister.

Go out and build an inventory of solutions and the problems they solve. The larger your solution inventory, the broader the range of problems you will be able to solve.

Thursday, March 15, 2012

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.