Coder or Engineer

by on February 10, 2016

Recently while interviewing a candidate, I posed the following question: “What are you most passionate about?” I was expecting the person to answer with some hard problem from the front-line of Software Engineering. However, they answered, “.. to learn more about Ruby.”

While not necessarily a bad answer, I did bring it up as a concern with other members of my team in the post-interview discussion. The consensus was that being a recent graduate, it is good that the person is focused on learning the tools before trying to solve the problems.

This revelation caused me to reflect on my own career and recall my early days of reading books on programming languages. It is not that I have mastered the tools, but somewhere along the way I became more interested in solving problems over learning every nuance of a language.

It seems there are two main types of developers: coders and engineers. The coder is most passionate about writing code while the engineer enjoys solving the challenges that one faces as a professional developer. Perhaps it is not two types, but a natural evolution of a career.

Typical recruiters always measure candidates by years with a specific technology. This means as a young developer, one is forced to highlight their experience with specific software stacks over the kind of problems they solve. As one becomes more seasoned, there is less use of recruiters. Instead, there are direct talks with technology managers who care more about what problems you can solve than the tools you used in the past.

Therefore as developers gain experience, they start to get measured on their problem solving ability more than their years with a technology. For example, my first development job required 2 years experience with Visual Basic 5 and Microsoft SourceSafe. Twenty years later, my current position required an ability to architect and develop Machine Learning systems with no technology requirements specified.

The reason is that during a 20 year career, one will work with so many technologies that it becomes almost irrelevant. I have worked with Visual Basic 3 to 6, C++, C, Java, C#, PHP, JavaScript, Ruby, Python, Go, Objective C, Flash, and some I have forgotten. The point is that only a small percent of my experience is relevant to the current job market.

So what has my years of experience given me that is valuable to an employer? I can make a web-service in Visual Basic, C++, C#, PHP, Ruby, Python, JavaScript, or Go. So can anyone else who has written code for more than a handful of years. What is valuable is a long list of hard earned gotchas, mistakes, and things that did not work. Including an ability to architect a solution based on these and current best practices that others have discovered through years of experience. This is the Engineer's role.

The coder's job is to implement the grunt work in whatever language or technology stack the Engineers have chosen. This usually means creating the software that no one else wants to write. The kind of work that senior developers have done countless times before and do not wish to ever do again. However, as the coder slugs away at his tasks, he or she will learn a long list of gotchas, mistakes, and things that do not work.

At this time, the coder will begin to second guess the engineers wisdom and start to recommend changes. Their reading library will change too. Instead of reading yet another edition of Bjarne Stroustrup’s C++, they will read more language agnostic books like those by Donald Knuth. Then one day, they will find themselves interviewing candidates perplexed by why those they are interviewing cannot implement a textbook quicksort algorithm in three different languages.