Are you a developer or a coding monkey?


Recently an acquaintance of mine came up with a good question “Do we really have a lack of developers in Malta?

So this stirred some thoughts in my head.  What is a developer? What is the differentiator between a developer and a coding monkey?

In the past, I would stray away from answering such questions, for fear that I am not experienced enough to answer them.  Yet it recently dawned on me that I am getting older, and along a mostly coincidental time-warp, I have amassed over 20 years of experience in the field, making me, potentially, qualified enough to put my opinions forward on the matter.

So, what is a developer? And what is a coding monkey?  I’ll start with a TLDR;

  • A developer, or more aptly, a software engineer, is someone who sees computer software in the same way that Neo saw the Matrix.
    code.gif
  • A coding monkey is someone who slaps his paws on the keyboard continuously until he produces a sequence of characters which coincidentally produce code that does what is required.
    6ygKuFu.gif

Over the years, I have had the pleasure of working with many developers, as well as the displeasure of working with coding monkeys.

These days, it seems that if you have a degree in any of the computer science disciplines you are considered a developer.  Yet this could not be farther from the truth.  Starting with my own experience of I.T. graduates in Malta; which at the time of writing, number approximately 335 a year, if I were to apply the ratio of good/bad developers that I have met in my life, then the actual good developers produced by Maltese academic institutions would number around 10 per year.

I have also been lucky enough to have spent all of my 20s travelling the globe, working and living in different countries (16+), and more importantly, working with developers from every nationality, and I can say that the ratio I witnessed in Malta is also applicable to other countries to some extent, with the exception of Slavic countries, which seem to produce highly skilled I.T. graduates at a far higher rate than any other country that I have witnessed.

So what is a good developer?

IMHO the differentiators of a good developer vs a coding monkey are the following:

  • Curious
    • they have an insatiable thirst to understand why and how the code is working
    • they need to understand how successful systems are designed since they want to steal those ideas for their own project
  • Creative
    • they apply a mix-n-match of all the knowledge they gained from studying other systems to their own project in a way that elegantly solves the problem at hand
    • when trying to solve a problem, they come up with ingenious ways to investigate what is going on and to make said investigation easier (even if it means spending an hour configuring their system to perform remote debugging, and even if it means decompiling third-party libraries)
  • Motivated
    • they are intrinsically motivated to learn as much as they possibly can in the time they have available
  • Patient
    • they RTFM!
  • Passionate
    • they take the quality of their work very seriously, like a religion and they get touchy when presented with sub-par work (whether they express this publicly or not)
  • Smart
    • they are capable of understanding what they are doing and can mentally trace a code-path through an entire system in their brain. i.e. like Neo in the Matrix, when they look at code, they don’t just see those 3 or 4 lines in front of them, but they see them in the context of the full system
    • they understand the problem they are trying to solve, and if the requirements do not make sense, they will question it and propose an alternative
  • Driven
    • they do not give up when faced with a problem to solve, on the contrary, they see it as a challenge to their intelligence, and they will persevere until they fully understand what is going on… even if this means they’ll be at it until 5am in the morning
  • Strategically Lazy
    • they will gladly spend extra time refactoring their code to ensure that any given logic exists only in one place, because they know that when the day comes for them to change this code, they only want to change it once, and in one place rather than having to scan the entire code-base to find all the places where they’re doing the same thing
    • they will also gladly spend time writing automation scripts because they feel that repetitive tasks are mundane and if a computer can do it, then it should, in the false hope that they can then use that time to chill and do nothing (in truth, they will probably use that time to play with some esoteric language or reading Jeff Atwood or Martin Fowler)
    • they will write tests for their code (either before they write it, or after) because they can’t be arsed to stay checking if it works in the future and they think their CI server should do that dirty work
    • they are averse to hacks, since they know that hacks eventually mean unpredictable behaviour which is hard to debug
  • Teachers
    • they are so passionate about their craft that they will gladly and patiently spend time trying to educate developers around them in the hope that they’ll eventually have another smart developer they can converse with and exchange knowledge with
  • Students for life
    • they spend most of their free time reading about new best practices and about the architectures of other solutions
    • they spend at least a couple of evenings a week experimenting with code or contributing to the ecosystem, be it through open-source projects, or merely replying to or correcting questions on StackOverflow.com
  • Pedantic
    • they understand that what they are doing is engineering, and therefore other than being correct, it also needs to be elegant, precise and reliable
    • they write safe code since they know that if it fails they will need as much information as possible to debug it
  • Pride
    • for them, asking for help is a last resort, they feel they should be smart enough to solve the problem themselves
  • Opinionated
    • they have strong opinions on how certain problems should be solved, and if you propose an alternate solution, you had better explain it to them logically and comprehensively to convince them to do it your way, otherwise get ready for a potentially unpleasant discussion
  • Respect
    • they have endless respect for other good developers, since they consider themselves lucky to be working with one
  • Artists
    • their code is concise and neatly organised in short, highly focused and mostly private methods
    • they stick to naming conventions religiously
    • their code documents itself
    • they love generics or whatever templating syntax is available in their chosen stack

All the great developers that I have met in my life share the above traits, and nowadays when I meet a more junior developer, I find it relatively easy to tell who will be a great developer and who will be a coding monkey.

So what is a coding monkey?

In contrast, the following are the traits of a coding monkey:

  • Demotivated
    • if something does not work, they will spend hours on end trying the same code over and over again, in the hope that by some magic, it might work eventually with almost no changes
  • Copy-pasters
    • they are experts in finding code snippets online and slapping them into their code with no changes, in the hope that they will just work
    • these are easy to spot.. they tend to leave variables running around called ‘myThis’ or ‘myThat’ and generally also leave code that does nothing
  • Lazy
    • they leave commented code all over the place and they commit this in PRs
    • the minute something does not work, they will immediately refer the problem to another developer in the hope they they’ll solve it for them
    • they do not ‘think’ about the problem they are trying to solve and simply do it as they are told, even if it does not make sense
  • Non-creative
    • if they cannot figure out what is going on, they give up immediately without even considering trying to figure out an alternate way to approach the problem
  • Sloppy
    • their code layout looks like an alphabet soup, you have a hard time reading it and wonder how it even works
    • they love writing methods with more than a 100+ lines, and they actually get satisfaction from it since they think they just wrote something complicated (in fact, it IS complicated, rather than complex)
    • they never even think about whether a method should be private, protected or public, let alone if a class should be sealed or not.  These thoughts simply never even occur to them.
    • they commonly ‘forget’ dirty experimental code and submit it in their PRs
    • they commit files with no changes
    • their commit comments have almost nothing to do with what they are committing
    • they leave spelling mistakes in their code, be it in method or variable names, or comments (code or commit)

Work Efficiency

So, from the above, it should be quite clear why some developers charge $5/hr for their work, while others charge in excess of $50/hr.

It is also a common misconception that good developers are fast.  In truth, from my experience, fast developers are just coding monkeys, since they just slapped something together without testing it and if you have any guarantee about this code it is simply that this code will most certainly fail, very quickly, and cost you MUCH more time to fix it.

The fault is partly that of managers, since they push developers to work fast, encouraging them to write sloppy code.  As a result, there is now a misconception as to how much time something should take to be written since projects are measured and estimated by managers who are used to sloppy developers delivering sloppy code in a short amount of time.

I say partly, because it is also the fault of the developer who accepted to write the code in such a short time and who produced the sloppy code in the first place… you are as much to blame, since you are the developer and you should be educating your manager in this regard.

Another side-effect of having coding monkeys on your team is that they take up the time of good developers by asking them questions all the time, leaving little to no time for the good developer to actually do what they are good at.

In Conclusion

So is there a place for coding monkeys on your team?

I would argue no. Coding monkeys only harm your project, both financially and in terms of team interference.

I will highlight two experiences from my past.

Scenario 1

There were 3 highly-skilled developers working on a project.  The technology was new to two of them, and they had one person on the team already skilled in this technology.

Their day was mostly very quiet, they had a stand-up in the morning, and other than casual jokes flying around everyone sat down and did their work.  The only discussions that actually occurred revolved around debating the most elegant way of solving a problem.

Needless to say, the project was very successful, delivered on time and below budget.

Scenario 2

There were 3 developers, 1 was a coding monkey and the other was a smart junior.  Same as for scenario 1, one was experienced in this technology and the other two were new to it.

Their day was very noisy, mostly due to the coding monkey constantly asking questions that they could very easily have figured out on their own with some brain power and the right motivation.  Additionally, more time was wasted because the coding monkey, not understanding what they were doing, explained their problem incorrectly, leading to more time spent trying to solve a non-existent problem.

As a result, the project kept slipping continuously since the more experienced developers were busy trying to solve the problems of the coding monkey and trying, albeit futilely, to educate the coding monkey.

Eventually the coding monkey was rolled off the team, yet the harm had already been done, and other than the time wasted trying to educate them, some bad code had already slipped through and made it to the master branch, so more time would need to be spent figuring out this code and fixing it.

What if you are a client?

If you are a client buying the services of a consulting company, the above should be of importance to you, since this will ultimately be reflected in the end-product you receive (if you ever receive it).

A tell-tale sign that a company employs coding-monkeys in comparison to real developers is their cost.  If they are cheap, then stay away from them.

There is a common misconception that writing code and producing software is easy.  This is wrong.  Not only because it is intrinsically complicated to write good code, but also because it is very hard to find good developers who consistently produce good code… and these developers are not cheap, because everyone wants them, so they will work for the highest bidder.

So, as a client, I would first ask my potential provider to show me how their recruitment process works.  What questions do they ask in interviews? Do the developers have to write any code in their interview?

Next, get a list of the developers who are going to work on your project, and simply search for their names on a web-search engine (ex. Google, Bing or DuckDuckGo).  If their names do not show up alongside a blog, a StackOverflow.com answer, GitHub or any other code-related site, then this is a very good indicator that this company employs only coding monkeys.

Advertisements

4 thoughts on “Are you a developer or a coding monkey?

  1. There’s another more serious drawback on the top of coding monkeys constantly asking questions: They will develop code that is extremely hard to read, hard to debug, hard to be changed or extended. That’s even worse than doing nothing or slowing everybody down because they are undoing other people’s progress. The team has to step back and fix the damage they made, thus the project is moving backward direction because of them. If unfortunate you have coding monkeys in your team, try to lock them in the cage and ask them do absolutely nothing, that way it’s better for the team and the project.

    1. Yes, exactly, very well said. In fact this is why in Scenario 2 I ended with ‘some bad code had already slipped through and made it to the master branch, so more time would need to be spent figuring out this code and fixing it’

anything to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s