Pulling it Off Isn’t Enough
Pulling off a project does not make a developer “good.”
I’ve been struggling with a way to explain this that doesn’t come off as semantic hair splitting, patronizing, or potentially dogmatic. It has been surprisingly difficult. You would think it would be obvious that professionals should have professional standards, that there is more to software and web development than just “pulling it off” or “finishing the job.”
I believe that I finally have a good analogy.
The Three Chefs
Imagine that you are an established restaurateur who is going to hire a new chef. You narrow a large pool of candidates down to three chefs. You like all three for different reasons and so you decide to let each of them temporarily try out the job.
The first one is an excellent chef. He can quickly and efficiently follow your existing recipes and has also invented some of his own that have really impressed you, however, there is one little problem. He has some bad habits in the kitchen and tends to not be as careful with keeping his area clean, and making sure he doesn’t reuse utensils in ways that could cause cross-contamination. But you are confident that if you hired him, you could easily train him to improve his habits so that they are up to the standards of your existing kitchen staff.
The second chef is great at quickly and efficiently executing your existing recipes, but his own recipes did not impress you much. He is however, quick, very skilled, and is excellent at keeping his area clean, and meticulously avoiding cross-contamination. You want a chef that can ultimately expand your menu, and you aren’t sure yet if this chef will be able to do that, but you know he will be a great addition to your existing kitchen staff.
Chef number three is a reasonably good cook but does not like following your recipes. He does not like being told how to do things by the other people on your team, and so he often neglects crucial steps in some of your existing processes. In addition, major practices that the rest of the staff follow he mostly ignores. He does create reasonably good food, however, he makes up for his average cooking skills with embellishments that recipes didn’t call for and that customers didn’t ask for.
For example, he adds an extra sauce to a dish that didn’t call for it. He may add three types of garnish for a recipe that called for one, and he is perpetually reinventing the existing recipes when he is not ignoring them entirely. You liked him because he worked very hard. He came in early and left late, and he also seemed very creative and eager to please the customers.
However, in addition to his inability to work well with others, and his bad recipe following skills, he just does not understand the basics in keeping your cooking space neat and orderly. Cooking safety rules are also often neglected and the rest of the staff is perpetually watching him to try and catch potential safety problems like undercooked food before they end up on a customer’s plate.
All three of these chefs can “pull off the job.” If you ask them to make a steak, they will all make a decent steak. They can all cook reasonably well, and work hard to please the customers.
I’m sure that if an actual chef read this they would be pulling out there hair trying to tell me that the chefs with bad food handling and kitchen hygiene aren’t really “pulling off the job.” But that is kind of how it is in development. We do not have the very real and immediate risk of making a customer sick, so bad code hygiene and bad code practices can sometimes go by uncaught and unchecked in ways that just wouldn’t work in a professional kitchen.
So if you are the restauranteur who do you hire? I would get rid of chef three right off the bat. Hiring him would be a huge risk with very little potential reward.
The other two might be a bit harder. The first one represents a big risk if you can’t get him to curtail his bad habits quickly, but his skill and creativity makes him a great choice for expanding your menu.
Chef two on the other hand has exactly the professional skills that you are looking for, but at the immediate moment does not seem to be as great at creating his own recipes. However, he might be just a few years and a little training away from being great at that, and he does not represent the scale of risk of the first chef.
Suppose for example that two weeks into hiring the first chef, you discover that he is still using bad practices in the kitchen, do you fire him? How long will you tolerate a potential risk to your food safety?
The second chef is likely your best business decision.
The Three Developers
So how does this analogy translate to software and web development?
The first chef represents the superstar developers with the crap-tastic code hygiene. The developers who are always pulling off amazing feats, but with code that cannot be understood or reused. They can pull off great things quickly, they can suggest inventive new features, but you need someone to review their code heavily and regularly, or you are asking for major problems down the road.
Chef two represents those developers who care about quality and professionalism, who only write good code but may be too busy to invent or suggest the next big amazing feature. They not only pull off their projects, they also write code that is reusable, testable, and understandable.
Chef three is your super-special developers who think that their way of developing is just as good or better than anyone else’s. They also believe that adding extra features is always a good idea and always makes the product better. They believe that they are super special in the world of development, and that every thing they do must be done in a super customized way because only they are special enough to understand how to do things their way.
They make up for their perpetual drift away from best practices, and your established product by adding all sorts of extra little features and customizations that you never even imagined that you needed. But these developers are a perpetual problem. Their projects are always over budget, over-engineered, hard to manage, and they perpetually reinvent the wheel.
In addition, their impulsive product changes often introduce extra bugs, extra configurations, and require extra documentation. In some cases the product changes actually reduce the usability or functionality from its previous iteration and causes other developers to have to do extra work troubleshooting new interfaces, and hunting down unknown bugs. Code hygiene isn’t a thing that the super-special developers know about or care to know about.
Each of these developers “pulls off” their projects, but each represents their own sort of risk. Once again, developer variety three — the super-special style developers are the ones that you should be avoiding. They will create more problems than they solve and represent an extreme risk to the value of your software.
By comparison, if you can get your “superstar” developer ones to get their code to the quality level of your “clean coding” developer twos and you could get developer twos to be as inventive as your developer ones, then you would be on your way to an excellent professional team. You need the creative, and inventive, but it needs to be balanced with solid professionalism, because at the end of the day you still need to deliver that software project on time, with reusable code that is easy to understand, test, and debug.
I have been on multiple teams where the developers vary drastically in their professionalism and skills, and yet often all of the developers are seen as equivalent.
Newer and less experienced developers are often so easily impressed with what other developers “pull off” that they can’t actually distinguish between developers who are excellent, and developers who are shoddy.
“Look at the feature that super-special developer pulled off… It’s neat. So what if the client didn’t ask for it, and won’t use it? I want to build something neat too…”
The same problem exists with managers and non-technical coworkers who often do not know how to appropriately gauge technical work.
We have to be able to distinguish between the skilled developers who work with professionalism, and as a result creates tremendous value for their business, and those developers who creates perpetual problems in their wake and treat their software projects like a weekend hobby.
This is so basic in other industries that it is strange that we do not have clearly understood and discussed standards in the world of professional programmers and developers.
I know which chef’s food I would want to eat, and honestly, for me it doesn’t matter how well you can cook. If you don’t have a clean kitchen and good professional standards for how you handle your utensils and food, I would not want to eat at your restaurant at all.
Software touches everything and we should be just as concerned about who is writing our code and how well they are writing it.
