Keep Writing Code, Even When It’s “Not Your Job”
Practical do’s and don’ts when code is not in your job description.
The internet is full of shallow opinions about who should write code.
If you search for “Should <insert profession here> write code?” you’ll only find superficial answers. There’s an undertone that it’s only necessary for software engineers. Everyone else has more important things to do.
Should only NFL players play football? Should only museum-worthy artists create art? Of course not. These are silly questions. If you want to play football, then play football. If you’re inspired, then create art.
Code is one tool of many in the toolbox. Carpenters have hammers. Painters have brushes. Developers have code.
This question, “should <insert profession here> write code?” is rooted in ego. It has an underlying tone that says, “Don’t write code; it’s not your job.”
So why then do we ask who should write code? Why is this even a question?
You have the freedom to code when it’s “not your job.”
Whether you previously wrote code full time or you’re just getting started, there’s no need to ask for permission. Enjoy it for what it is and create. Write code to speed up tedious tasks. Create prototypes to amaze your coworkers. Hack together APIs to show that anything is possible.
Your manager may say, “why are you writing code? Shouldn’t you be working on <insert higher priority thing here>?” Questions like this are sincere and have a legitimate purpose. And you can confidently reply, “I built it without delaying <high priority thing>.”
Ways you can make an impact today.
- Create proof-of-concepts
POCs are unexpected inspirations. They make the impossible possible. People stop talking about if it should be made and instead talk about how it solves the problem. - Write pseudocode for complex requirements
Developers have to translate requirements from prose to code. So why not skip the prose and write pseudocode? `if (x && (y || z)) { doA() }` is easier for a coder than if you wrote 10 sentences. - Seed ideas for inspiration
When you’re working with a team of designers and engineers, seed them with ideas. Build an app that says, “here’s a way we can solve this problem.” Code kickstarts conversations and inspires. Skip the debate on the feasibility and go straight into creating. - Prototype to improve customer feedback
Customers authentically react when they can see and touch it. Show an idea to a customer rather than explain it. Let them feel and touch it. You’ll learn faster. - Build internal tools to replace spreadsheets
I’m amazed at the number of critical business decisions are made using Excel. Complex spreadsheets with layers upon layers of macros. Build an app that saves time and reduces errors. - “Show me the code.”
It’s more reliable to read code than ask a coder to translate it into prose. “Can you show me where to find the logic that does (x)?” Skip the translation and go to the source. - Hack together tools and systems
Do you need a report that combines data from a CSV, an API, and a database? No problem, write a script to combine all three.
How to work with or manage a team of coders.
Many managers, designers, and entrepreneurs spent 5, 10, or even 15 years as full-time coders before they changed careers.
Now that you’re free to write code, how should you work with other coders?
There are many grey areas, and soft skills that I’ve distilled into black and white do’s and don’ts. I learned these when I switched from full-time coder to product management.
When they ask how long it will take to code:
Don’t: Give estimates on behalf of the team.
Do: Give your personal view of difficulty, but with a caveat, you’ll have to speak with the team.
When the team is deciding how to build it:
Don’t: Prescribe the solution.
Do: Inspire, question assumptions, and dig into the details.
When you see poorly written code:
Don’t: Demand changes or rewrite it.
Do: Ask questions and coach the coder, so they correct it.
When you ask the team to build something:
Don’t: Skimp out on the goal and only talk about what needs to change.
Do: Help them understand why, what you’re trying to accomplish, and the impact you expect.
When the deadline is close:
Don’t: Write code to meet the deadline.
Do: Order food, cancel meetings, and anything to shield the team from distractions.
Keep writing code.
I hope this helps you get past the shallow question about who should or shouldn’t write code. Code is one tool in the toolbox, and it’s for everyone. You can use it to solve, create, and inspire. Enjoy it.
For more about creativity and resistance, I recommend the War of Art.
Photo by Ezra Comeau from Pexels
