Be a Better Developer 4.5 – Being a Plumber - Tips
This blog post is part of a larger series named “Be a Better Developer”. You can check out the intro, “Stop Being a Code Monkey” to get started from the beginning. Each post will have a link to the previous ones and a final summary post will contain links to all entries in the series.
So, have you decided if you should be a plumber or not? Previously I said that I agree that “Don’t be a Plumber” is very sound advice, but I think there are times when you will just have to play that role as a developer.
On what appears on the surface to be a complete counter view to Brian Prince’s “Don’t be a Plumber” advice, Leon Gersing posted his own thoughts about why don’t be a Plumber is horrible advice (read the comments to his post… interesting stuff). What I took from Leon’s post is:
- Don’t assume that it can’t be done better.
- If everyone is not a plumber, then there will be no innovations, no new frameworks.
In Leon’s post he uses Nate Kohari as an example of someone who wanted to create an alternative dependency injection framework and not just use an existing framework like Spring.NET (If you haven’t looked at what Nate created with Ninject, you should). What I take away from Leon’s statement is that Nate saw a different way to tackle a problem and became a plumber, creating Ninject in the process. This is an awesome thing because now we have more options when it comes to a dependency injection framework. If there weren’t plumbers in the world, then we would all be writing a lot more code. I completely agree with this viewpoint, but at the same time when you are working on projects for a business who specializes in Tax calculations, should you really be spending time generating your own dependency injection framework? If you can’t find one that fits your needs, then perhaps, but make sure the choice to do so is in the best interest of the project.
So, I’ve concluded that while for the most part you should not be a plumber in the sense that you are writing a lot of plumbing code, but you may need to roll up your sleeves and get dirty from time to time if you don’t find something that fits your needs.
Finding the Right Pipes
In a comment to my previous post Maggie Longshore takes a different approach to the analogy. She states:
“If you think of plumbers as the ones that choose the right pipes, design how to network them and seal them from leaks then we should be plumbers. Occasionally a plumber may need to fashion a custom pipe, but they try not to make it the norm.”
As I discussed in Being a Researcher, you’ll need to know how to select a good framework or component for your needs. Given Maggie’s take on the analogy that means being able to select the right pipes. Choosing the right one will mean less work on your end for the plumbing it is responsible for. If the framework you choose doesn’t meet your needs then you may find yourself having to code around its short comings or doing a lot of extra work.
About a year ago I was between client engagements so I took some time to compare Spring.NET and Unity as two inversion of control containers. My goal was not discover which was “better”, but more to understand their differences. I wasn’t working on a project so my investigation was more about how they worked, what their features were and how they compared to one another. I created a series of unit tests that tested the features of each so that I could see how they accomplished similar tasks. I have to be honest and say I didn’t get too far into this before I was back on another project, but the exercise gave me a better understanding of the two frameworks and their capabilities.
My tip for choosing the “right pipe” is to check out several options and compare them from time to time. Keep an eye on what frameworks and helpers are in the ecosystem. If you haven’t already, check out various ORM frameworks, logging frameworks, dependency injection frameworks, etc. You don’t have to spend days on this, just get the latest drop of them and put together a simple “hello world” application with them. Most of these will have a small tutorial or sample you can try to get a feel for how they work. Understanding their differences, but more importantly just what is available, will put you in a better position to know which framework will work best for you on a project, or if you’ll have to be a plumber yourself for a while.
Don’t be Afraid To Look Under the Hood
In one of the comments to Leon’s post, Ben Von Handorf makes the statement that junior developers rely so much on the framework that they don’t understand what’s going on under the hood to the point that they get lost when something breaks. I’ve seen this too and I believe it is a symptom of taking the “Don’t be a Plumber” advice a little too far. One of the reasons I advocate researching the various frameworks is so that you are familiar with how they work. If something breaks or isn’t handled the way you expect you need to be capable of digging into the code of the framework to find out why. Understanding how the framework is built and what it is built upon will help you troubleshoot issues or understand how best to use that framework.
Here’s some homework for you: go grab the code for the most recent framework you used and walk through it. See how it operates and understand how it works. Can you think of a few ways to improve it? If so, share those ideas with the creators of the framework, or if it is an open source project, submit your improvements as patches!
Be Wary of the Not Invented Here Syndrome
On the complete opposite end of the spectrum from “Don’t be a Plumber” is the “Not Invented Here Syndrome”. This productivity killing disease often manifests itself in the form of developers deciding that they must write everything themselves. One of their favorite arguments is “If I code it I know how it works and it will be easier for me to maintain.” Another is “it’s just not that hard to write X. I can do that in a day and we’ll save money not buying a component.”
Here’s a great example: let’s say there was a project that had a requirement for a printed page from the application. This wasn’t really an in-depth report or anything like that, just a simple page of information printed. Instead of using a reporting control or package, the developer decided to write his own. How hard could it be? He just needed to build up a string and then push it to the printer right? On the face this is really simple, but once he got into having to write code that needed to center the text on the page, deal with margins, pad data or even left justify it became a lot more work. What took him a few days to produce could have been done in a few hours with a reporting package. He thought he was saving money by not getting a reporting package, but if you add up his hourly rate and how long he took on getting the code right I’ll bet he came out on the more expensive side.
Conclusion
To be a good developer you will need to be comfortable getting into some plumbing code when necessary, but for the most part you should be selecting tools to help you concentrate on the code that really matters for your solutions (what you are really trying to solve). You should understand how plumbing works, but not necessarily be ripping out or installing new plumbing on every project. Don’t be a plumber, but know when you need to implement something better!
Next up in the series will be a role that I find very hard – Being a Salesperson.
Previous Posts in this series: