The Perspective of Great Developers

I’ve noticed a perspective that differentiates great developers from good developers.

Most projects consist of code that the team writes and third-party code that the team purchases or obtains from an open source provider.

Average developers conceptualize third-party code as a fixed entity to call upon and use. Good developers usually become experts with the third-party components they use.

Micah and Matt

Great developers view code they didn’t write as an open and modifiable resource (assuming the code is open source). Great developers aren’t reluctant to look behind interfaces and fully understand, or even modify, the implementation.

The perspective difference is elegantly described by Robert M. Pirsig in Zen and the Art of Motorcycle Maintenance.

I’ve noticed that people who have never worked with steel have trouble seeing this… that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes… pipes, rods, girders, tools, parts… all of them fixed and inviolable, and think of it as primarily physical.

But a person who does machining or foundry work or forge work or welding sees “steel” as having no shape at all. Steel can be any shape you want if you are skilled enough, and any shape but the one you want if you are not. Shapes, like this tappet, are what you arrive at, what you give to the steel. Steel has no more shape than this old pile of dirt on the engine here. These shapes are all out of someone’s mind.

I was pleased when Andy Keller’s recent Software GR talk hit upon the mindset of ownership for the code you buy or use from a third-party provider. When something goes wrong with your product, your customers don’t care if you wrote the code or got it from someone else. As a steward of your product, you have the responsibility to expediently fix issues that occur.

When issues do occur with a third-party component, great developers are worth their weight in gold.

A great developer will expose third-party bugs with automated tests and then create and submit a patch back to the provider.

Anecdotal forum browsing will show that average developers post questions and wait for an expert to do the thinking. Average developers may be blocked for days while they wait for an expert to investigate the issue and provide a solution.

Even though open-source resources allow average teams to be greatly productive, when quality and dependability matter, there is no substitute for great teams.

Average developers can become great developers by adopting the mindset of ownership and a perspective of fluidity towards third-party code. Don’t look at code you work with as a fixed entity. Understand the ideas and intent behind the code and craft it back into shape when necessary.

Do you have a story to share where you or your team stepped up to solve a problem with third-party code?