Developers or Engineers?

By Avi Deitcher

Which do you hire, developers or engineers?

Nowadays, the most popular programming language is JavaScript, or, by its correct name, ECMAScript. Since "Eck-Ma-Script" is not a great marketing name except, perhaps, for a language for Ghostbusters EctoPlasm, it is not surprising that everyone still calls it JavaScript or just "JS".

Whether this is a good thing or not, and whether JavaScript is the worst or best language invented, is not a topic I am too interested in. Its popularity is a fact, and it is used to program everything from the browser to the server (Node / IO) to mobile apps (Appcelerator / PhoneGap) to devices (spark).

There even is a series of unmatched conferences on JS, JSConf, run by Chris Williams; if you have anything to do with JavaScript or robotics, you must attend his conferences.

All of this froth means that there is a huge amount of development in libraries and frameworks to assist in making JavaScript development easier. Some of these have become very popular and greatly eased development work - jQuery in the browser, express in the server - while others are providing better application development at the price of very steep learning curves, notably the very popular Google-driven Angular.

Unfortunately, one of the downsides of frameworks - in any language - is that they can become a crutch, leading developers to learn the framework rather than the underlying language and structure.

Many years ago, when I was a young kid first learning how to ice skate and play hockey, my instructors would not let me start with a stick. "Sure, you need a stick to play, but until you learn how to skate well, the stick can become a crutch you lean on and never learn proper skating." While I am sure they were exaggerating - I doubt I would have spent decades using a hockey stick as a crutch - undoubtedly they spoke from experience.  People who start without a crutch learn the basics much better.

Earlier this week, Alex Rboots posted an article, "Do Not Learn Frameworks, Learn the Architecture." While he appeared to be arguing against all frameworks, I find it more likely that he was advocating against people learning the framework as if it is a language, rather than the underlying JavaScript language properly, the architecture.

  1. A framework can be a crutch; someone who only learned the framework will be lost when the next one comes along.
  2. A framework is just a tool to be used when it fits. When you need something lighter, or different, if all you know is this framework, you will use the wrong tool, leaving a mess for others to clean up, and the business to pay the price.

The article reminded me of one of my hiring mantras in technology: never hire developers, always hire engineers.

I refer not to job titles; companies use them interchangeably. I refer instead to the mindset of the employee.

  • Developer (or administrator or operator) is a job title. It describes what the job is, often the technology to be used. It might be "hardware developer" or "software developer", or even more narrowly-defined, like "angular developer" or "C# developer".
  • Engineer is a character description. An engineer is a person who has learned the mathematical and scientific principles for understanding how things work, has learned to put them into practice, and truly enjoys figuring these things out.

Developers build software; engineers play with Lego. Developers read about their framework; engineers dream of building new frameworks. Developers shut down and go home; engineers go home and cannot shut it down completely.

If you need someone to build, say, a microservice, it is fairly easy to put together a job requirement full of the skills you need. For example, you are developing it in Java, with a MySQL replicated MySQL database, and a REST API provided by Jersey, running on CentOS Linux instances in Amazon Web Services EC2. You can hand a list to a recruiter and tell them, "if they match 3 of 5 or more with 2 years experience or more in each, I want to interview them."

This is easy, low-cost, and works great... until you discover that you need Cassandra instead of MySQL, or Ubuntu instead of CentOS, or to write in Go rather than Java. Oops. You now have a person who not only does not know many of the underlying technologies, but cannot even think about them when the problems arise. You look to your people to alert you when your choices are mismatched, but your formerly-great hire sees everything through a particular lens.

A few years back, I worked with a database team with several Oracle experts. They managed and tuned their databases well, and stayed on top of issues. Unfortunately, by the time I came in, Oracle was not the right solution for many of their problems. They needed to move away from 2 monolithic large Oracle databases to several smaller and more diverse data stores. The team, however, only could see through the Oracle lens. Every solution to their problems was another patched Oracle solution.

Engineers, by contrast, understand the underlying problems. They may know Java really well, but it is just a tool. The moment that Java creates issues, they will examine if there is a Java solution, and if the problem is more fundamental to Java and requires an alternate solution. Chances are good that an engineer already has been mulling alternatives and how they could fit in well before hitting this particular problem.

By the time you realize there is a problem, an engineer will have:

  1. Determined it is a problem;
  2. Found alternatives;
  3. Discovered what it would take to replace your current technology;
  4. Learned the basics of how the alternate works;
  5. Put together a proof-of-concept.

Before you know it is a problem, they have found it, proposed it, tried it, and trained your staff (i.e. themselves).

Of course, hiring engineers is much harder. Very few recruiters even know how to find and sift engineers - types of people - rather than developers - lists of particular job skills. This means much more work for you, both finding recruiters who understand what you are looking for, and recruiting them.

The payoff, however, is well worth it. Engineers have a far longer lifespan in your company, solve many more problems, even those you haven't thought of, and lead you ahead. Developers do what they are told.

Summary

As in every company issue, the problem starts and ends with the people. When you have technology issues that last longer than they should, if your technology solutions are dated, as a whole or their underlying components, fix the technology, but do not leave the underlying people problems alone.

Ask us to help solve your problems, and determine if you really have engineers... or just developers.