What is a Dev's Job?

Is the job of a dev to write code?

NO

Writing code is part of the job, but it is not the whole job.

Is it the job of an author to write words? Or is their job to create a book/article/screenplay/etc?

Most developers are employed to create or maintain a software product. This can take many activities to accomplish, of which writing code represents a significant portion, but it is not the only thing. While other roles will engage with several parts of creating a product, lowering the dev’s responsibilities in those areas, there are still many activities within creating a product.

Treating devs as just a matter of writing code pushes us towards ideas like trying to ‘protect’ devs from useful meetings, instead of demanding that all activities, including coding, be looked at to make sure they are efficient and useful.

You have probably heard this adage (or one of its variants):
“If you have five minutes to chop down a tree, spend the first two and a half sharpening your axe”

Chopping down a tree is not about swinging an axe - it is about getting the tree down. As a result, you want each swing to be as precise and useful as possible. This idea can be applied to many things, including the act of delivering software.

A developer is not done just because they wrote code. They are done when the product is delivered (…and then maintenance work begins).

When looking at how developers (and the entire development team), the question is not “are they spending too much time not coding?” but “are they spending their time on activities which enable delivery?”

Not all code is written equally (looking at you code pushed at 2am), and not all meetings are useful. That said, many meetings are useful, just as much code is. However, just as code can be refactored to perform better, so can meetings and other non-code activity.

Everyone should be able to ask of any activity “is this actually helping us deliver or is this wasting our time or is there a better way to do this?”

PRs are a great example of an activity which is not writing code, but most people would agree is part of the job. If you work at a place which uses a branch-PR strategy, there is a good chance several PRs feel like a waste of time, or people feel like they waste time trying to get them reviewed.

There are several ways to accomplish the goals of “code in the product is reviewed for errors” and “knowledge sharing of code in product”, which tend to be the goals of PRs. For instance, pair programming is a useful way to accomplish both without the need for PRs. Ship/Show/Ask + strong CI/CD is another way of changing the activity from one generally dreaded and bottlenecked to a smoother experience.

Note: Reminder that merging code to master is not the same as being done. If your job is to build/deliver a product, you are not done until it is deliverable to the consumer.

This means quality is part of the job. Security is part of the job. Reliance, stability, etc, are all parts of the job.

While all the above have specialists, this doesn’t abdicate responsibility from the developers. These specialists guide and enable developers.

A dev is not there to write code. They are there to deliver software.