Developers, Your Job Is Not To Write Code

This essay is adapted from a lightning talk that I originally presented to coworkers in 2019.

The advice I've consistently given to developers who want to grow might seem counter-intuitive, but it's always held true for me—the first step to being a great developer is recognizing that your job is not to write code.

How do I know this to be true? Well, I've never spent a single minute of a one-on-one with a developer talking about code that they've written! That's just not what I spend energy on when I'm coaching someone. The path to becoming more senior is not through better coding.

Furthermore, your stakeholders—brace yourself!—don't give a shit about your clean code, the developer experience, tooling, or any other tinkering you might do. They'll be equally satisfied with a massive, complex feature or a single line change in a configuration file. All that matters is that you've delivered value.

Similarly, when working on a team you could be the Greatest Developer In The World but if nobody likes working with you or understands what you're doing every day then you're essentially a human paperweight.

So, there must be many more skills required of you than just typing into your favorite IDE. Thinking that "developers write code" is like thinking "carpenters hammer nails"—it's simplistic, naive, and a trap.

A Trap Hiding In Plain Sight

There are obvious signs you might be stuck in this "developers write code" trap. Some of these might apply at one time or another and that's OK as long as you're self-aware. But the more of this you exhibit on a regular basis, the more work you'll have to put in to extricate yourself. These signs include:

• Showing contempt or disdain for meetings.
• Not checking, acknowledging, or responding to messages.
• Not participating in "non-essential" conversations or social activities.
• Not tolerating interruptions or context-switching.
• Apologizing for delays in planned coding tasks.
• Measuring your output solely by counting pull requests.
• Not asking questions or thinking critically about the work.
• Not contributing suggestions, ideas, or solutions.
• Displaying a lack of curiosity in your problem domain.
• Worrying about your work at the expense of your teammates' work.

These can be fairly common developer stereotypes. The perception from other people that "developers write code" is also part of the trap. Let's hope you don't work for a certain "genius" CEO who asks you to print out your code for his own personal review!

To truly succeed you'll have to spot these anti-patterns and correct these assumptions for both yourself and others. You really have to own your narrative or someone else will do it for you.

Why It's A Trap

The "developers write code" trap is detrimental to your company, your team, and especially you. It will limit you and ironically make you a worse developer.

• Short-term thinking (e.g., "What's my next coding task?") means you're running in place.
• You're more likely to be emotionally invested in your code which limits your learning opportunities or potential solutions the next time that code needs to be touched.
• You'll be typecast (or extinct) as a specialist developer—remember when we had Flash developers...?
• Burnout is more likely because you're a passenger and not an active participant in the work or its destiny.
• You won't be given the novel and interesting challenges within your team, technical or otherwise.
• There will be fewer career paths available to you because you want to keep your fingers on the keyboard.

So, What Is Your Job Then?

If your job is not to write code, then what is it then? Fair question, and the answer is simple...

Your job is to solve problems.

Yep, that's it.

Obviously, we do solve some problems by writing code. But we also solve problems by reading code, testing code, debugging code, or deleting code (my personal favorite).

But wait, there's more! All of these things are your job as a developer and serve to solve a problem. Go ahead and read through this. I'll wait.

• Organizing and attending social events
• Volunteering
• Suggesting or enacting changes in process
• Interviewing candidates and reviewing resumes
• Attending conferences
• Being someone's rubber duck
• Showing people cool stuff you found
• Eating your own dog food
• Writing documentation
• Mentoring and coaching others
• Attending meetings
• Debugging or tracing code
• Chatting in the kitchen/hallway/etc.
• Testing code
• Testing in production
• Prototyping
• Giving demos and presentations
• Googling shit
• Estimating effort
• Doing lightning talks
• Reading code (PRs)
• Attending training
• Deleting code
• Designing systems and solutions
• Finding or reporting bugs
• Troubleshooting
• Brainstorming
• Reading Stack Overflow
• Asking questions
• Researching
• Being a subject matter expert
• Keeping up with Slack/email
• Unblocking teammates
• Talking to stakeholders
• Caring about the users
• Writing code

Most of these would typically be considered "soft skills" which is a term I despise. They're all equal skills. I don't position writing, communicating, empathizing, helping, or thinking in second place after the so-called "hard" skills.

You need all of it to be effective at your job and climb the ranks. As Tim Ottinger puts it programming is "mostly thinking" and your code is "just the residue of the work". Karl Sutt also has great communication advice that demonstrates how empathy itself is a useful skill requiring genuine effort:

Writing effectively is a superpower, there is no denying it. As a software engineer, you write a lot. Most of the writing you do is for computers. Businesses, however, consist of people.

Go Do Your Job

We all know developers in their default state would much rather be left alone to write code. I've been there, too. Coding is fun! It's comfortable! But I dare say it's too comfortable. Frankly, if you're not challenging yourself you're just doing something that anybody else could be doing in your place.

I encourage you to broaden your understanding of what a "great developer" is and then meet that definition.

Remember that your productivity and contributions are measured by more than just code output. Recognize that there's a long list of skills that are equally valuable and necessary and then pick the next one to get better at. Juniors and seniors alike can do this. There will always be another skill to polish.

Once you realize that you're more than just your code you'll be well on your way to becoming a better developer.