This article is one in a series. See the introduction here.
Everyone is driven by a desire to succeed, but for some, success does not come through superior skill or intellect; for some, success comes through will-power and determination. In the field of software development, such people can often be described as code-fiddlers. There was a time when I looked down on code-fiddlers, but I've since come to realize that they can perform better than me in some ways. To the untrained eye, code-fiddlers are hard to spot. They are able to meet goals and create working products just like everyone else, but we engineers understand the big underlying difference.
Code-fiddlers, you see, don't really know what they are doing. Okay, that's a bit extreme, but at its heart there's some truth to it. They obviously have some clue about programming. They know enough to be able to get their code working, but they don't fully understand why or how it works. You may be thinking that sounds absurd--how could anyone write complex functioning software that they themselves don't understand?! If you are incredulous, let me assure you, it's absolutely true. I have worked closely with many developers over the years that fit this very description. At first, I didn't believe it either. I still don't fully grasp how code-fiddlers manage to pull it off, but I assure you, they do. Perhaps it will make more sense by way of a metaphor...
I am no mechanic. Sure, I know how the various tools work and what they do. I know how to use a wrench. I even know the basic principles of how an engine works. I have watched true mechanics as they have practiced their craft. But I'm still lost. When I open the hood, I just stare at the engine, not knowing where to begin. I can't solve problems on my own. I do, however, know how to navigate a repair manual. I also know how to use a meter to read check-engine codes and search online to find tutorials showing how to fix them. If I can find step-by-step instructions, I can use my basic car-repair knowledge to follow those steps. I won't fully understand what I'm doing or why, but I will be able to muddle my way through to the resolution.
Code-fiddlers are able to write code in much the same way. They search for examples online, copy-and-paste them into a project, and then just keep fiddling with the code until they get it to work. Most coding problems, after all, have already been solved by someone somewhere, so all the code-fiddler needs to do is to find the best explanations, tutorials, and examples. Once they've found them, they can use their basic knowledge of the tools to mold those solutions into their project. Through this arduous process of searching, copying, pasting, and then fixing via trial and error, the code-fiddler gets the job done. All it takes is a little knowledge of the tools and some good old-fashioned determination. That's not to say that they have no talent. There is a definite skill to working with complex code that they don't fully grasp. Non-fiddlers aren't nearly as adept at that.
The surest sign of a code-fiddler is that, when they are asked if they can do something new, they won't be able to answer yes or no until after they have had an opportunity to give it a try. They won't have any detailed preliminary ideas regarding how they might implement it. They will first need some time alone to search for examples and to test them out. Another sign of a code-fiddler is that they won't be able to speculate as to reasons why bugs might be occurring in their code. Since they didn't really write much of the core code themselves, they won't know enough about how it really works to know why it is failing. They don't fix bugs by understanding what's wrong; they fix bugs by trial and error.
It may seem counter-intuitive, but code-fiddlers are typically very quick learners. Since they are adept at using technologies that they don't fully grasp, they have a speed advantage when learning new things. They don't need to fully understand things before they can start using or working on them. This is especially apparent when the need arises for them to work on legacy code. Where others will first need to take a step back and take time to try to understand how the legacy code works, the code-fiddler can jump right in and start fiddling.
As should be obvious, you do not want to assign code-fiddlers tasks related to designing frameworks or common tools. Ideally, you should never assign them to anything that has never been done before. The tasks where they will be most effective are the ones where they will be reusing or repeating an existing design. If the frameworks and tools that they need already exist, and a similar task using the same tools has already been done before, they will really shine. They will be able to look at the example of how it was done before, copy it, and modify it from there. They will require very little training and they will likely be able to get it done even faster than the engineer who wrote the frameworks and tools in the first place.
As I mentioned before, they also excel at fixing bugs in others' code. They may not fully understand why their bug fix works, but if that's important, another engineer could always analyze their fix to figure out why it worked. Even so, by having the code-fiddler do the legwork, the bug will be fixed and understood sooner and more efficiently than it would have been otherwise.
So, if you are looking for someone to churn out multiple modules that all conform to the same standard as another existing module, using the same tools and framework, then a code-fiddler is a perfect fit for the job. If you need someone to add some feature that's already been done before to a new area of the software, a code-fiddler will fit the bill. If you need a bug in some ugly legacy code to be fixed, a code-fiddler may be your best bet. Just don't make the mistake of tasking them with something that has never been done before. If you do, it will take them too long, they will get frustrated, and the end result will likely be rancid before it gets out the door.