This is a reply to the article Your Job Is Not to Write Code by +Laura Klein. 

It IS my job to write code. That code has to meet the expectations of the end users, the product manager (PM), the Quality Assurance Manager (QM), the support team, and myself.

The PM has to set the bar. Functionally and performance wise. If the PM leaves it up to me to decide what the code should run on, on what kind of hardware, that PM is not filling the role. The PMs are the ones that set the targets.

In a proper development team, it is NOT the developers job to test that the code runs on all variants of hardware. This is where you have testers, and a PM and a QA Manager (QM) that define the bar of what is acceptable function and performance in accordance with the specification you created.

The developer may be given his/her own test machine which can be used for “worst case” scenarios, but it is the test team that has to validate on a decent sample set of environments.

I might be a hired hand, and probably do not know all there is about the trade that the software is developed for, nor do I know the clients or how they actually use the software. Over time, I might learn this, but only as far as the PM lets me.

It is my job to think of the what-if’s. Actually, writing code is all about what-if’s. However, it is the specifications that decide the scope of the what if’s.
Should I recognize different number formats? Date formats? International characters? Right to left text? What should the default value be when a calculation fails due to a division by zero? What should the correct behavior be when a criteria is not met? All these things are about specifications defined by the PM according to the needs of the clients.

When I “check in code”, I should NEVER EVER check it into production. I should push it to a proper staging environment, and write roll out documentation, then the test team should roll it out on a test environment, validate that it works, refine documentation and then hand it to the support team for rollout to production.

If the PM did not ensure that there is proper QA, it is that PM that is responsible for the shitty code in production. If the product doesn’t do what the customer expects, it’s the PM that did not write proper use cases and proper specifications and operational parameters, and it would be the PM that did not ensure that the QM had created the necessary test cases and functional specifications.

My skill is not customer management. My skill is not necessarily to know the business that the client is in. My skill is to transform various degrees of incomplete specifications into something that resembles what the customer wants, within reasonable time, and with a reasonably high quality.

The PMs are the ones that defines what the customer wants.
The QMs decide if what I wrote, meets that definition.
The support team will be the ones that verify that the definition actually was complete and correct.

Good software meets expectations. Good software is a process. Good process depends on team work. Team work depends on a certain degree of separations of roles. Roles are defined by responsibilities.

My role as a developer is to write code that meets expectations.

In some companies, these roles may boil down to just a few people — or even just a single individual. The roles are still there. The responsibilities are still there.

If the CEO doesn’t understand or care about these roles and allot the necessary time and/or resource — that company will be fighting fires, playing blame games, and losing clients.

Sincerely,
Your Developer
Lars Fosdal