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.
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?
Fixing bugs in Liferay is the kind of work I’ve been doing last year :)
Thanks for the comment jmarranz.
I can only imagine the fun you’ve been having :)
[…] has Ruby and Rails and Node and shows you how to easily do something that we all should be doing.The Perspective of Great DevelopersShawn Crowly of Atomic Object gives us a post about a road to becoming a great developer. In […]
Great post Shawn.
This also reminds me of a couple posts on programming “magic”. Giles Bowkett’s Do You Believe in Magic and Eugene Wallingford’s It’s All Just Programming. Some devs like to quarantine code into a black box and throw terms out like “magic” or “complicated” or “convoluted” without actually diving in. The last two could still be valid criticisms, but without ever trying to honestly learn the internals, that dev’s argument will be built around FUD.
Thanks for adding to the discussion Zach.
I like the two posts you referenced.
Thank you for this interesting post.
I’m hacking on Dspace project and Canvas LMS project, the hacks are not so deep, but it makes me more confident and inspiring for me to continue my learning process in software development. The way to understand the concept behind any code is interesting and … hard. Personally i need belief in code.
Very well put: “The way to understand the concept behind any code is interesting and … hard. Personally i need belief in code.”
Great stuff – this is something I’ve been thinking about a lot lately.
Although I’ve got my hands dirty with third-party stuff and submitted a fair number of patches over the years – I tend to hold back if the product is in a language I’m less familiar with.
For example; I’m less likely to start hacking on FFmbc (an open source video tool I use a lot) as it’s written in C and my experience is mostly in Java, Ruby and Perl.
One part of me thinks that you have to draw the line somewhere but then I think of an ex-colleague of mine who will pretty much hack on anything that moves if it doesn’t work right – language doesn’t seem to be a factor for him.
You’ve given me something to think about next time something breaks anyway.
Great article! Our team has lately been reluctant to jump to the inclusion of a gem whenever we’re trying to solve a problem. When looking around in sites like stackoverflow.com (which rocks, by the way), it’s common to see people suggest the use of a particular gem to solve the problem.
This is great, and one heck of a selling point for rails. Chances are good that someone else has already come up with a solution for your dilemma.
But it’s best for me to dive into the actual code behind the scenes first.
Anyway, thanks for the article!
Understanding the third party code is definitely a sign of a good developer, but being willing to modify it isn’t necessarily a good thing – I’ve run into quite a few cases where a simple one line change to a library would fix the problem, but is not an appropriate solution due to the effort required to maintain a custom build of that library as new versions come out.
You raise a good point Tom.
It is not a good idea to update third-party code and think the job is done. Future consequences need to be thought through.
Submitting a tested patch back to the provider and integrating an official update is a better approach than building your application off a private fork of the codebase.
Sometimes a privately hacked version is required to fix an issue in the short-term.
Regardless of approach, a team needs to carefully think through their long-term strategy and keep good documentation.
Thanks for comment and pointing out an important consideration.
Comments are closed.