Today I did something reckless; I emphatically agreed with one point of view without first hearing the opposing argument and that was wrong. The first article, your job is not to code, written by Andrés Osinski, asserts that the role of a programmer should be more than just a code monkey but a requirements gatherer and communicator. The opposing view point (the one I agreed with), your job is to code, written by Josh Symonds, says that the only thing you should be doing is writing code and to ensure that you are great at it. After reading the articles I realised that both articles are correct depending on context.
Here’s my take on things. Firstly, if you’re hired as an engineer, then your primary role is to craft excellent software based on the requirements passed to you. You should strive to be an expert in your area, constructing reusable components, separating concerns, unit testing and relentlessly documenting your code. Now, I am not saying that you should blindly follow the technical specification without understanding the business case and asking relevant questions. If you are a lone developer or in a small team then your job is a problem solver. You are, by default, the person who will be looked to when there is a business problem. Finding a great solution, communicating this solution, architecting the implementation and crafting the final product is all in your remit. In bigger teams one would assume that there would be people, not you, whose role it is to work with the business teams to gather the requirements and build the technical specifications.
Ensuring that the solution is the right one for the problem is of obvious importance but it is equally important for the person building out the solution to ensure that they fully understand the requirements. Once clarified, it is then up to you to do what you do best and that’s writing great code!