Be a What?
A Big-Picture Developer is a dev who understands the vision of the product they are building. They know the context of the feature they are working on and how it fits into the product as a whole. They put themselves in the shoes of the user and ensure the user experience is a good one. They build clean, maintainable software for their future selves and teammates. They give a damn.
Because if you work in a silo, building only what is defined in your ticket, never asking “the why” behind a feature, and never zooming out to see the big picture, then you will inevitably build the wrong thing or build the thing in the wrong way.
How Can I Be a “Big-Picture Developer“?
Start with Why
“Start with Why” is a really good book by Simon Sinek, but it’s also a key concept most devs don’t think about enough when building software.
If you don’t understand the context around a feature or bug you’re working on or a PR you’re reviewing, then stop what you’re doing and start asking why questions. Once you grok the context, everything you touch will be #blessed.
Take any opportunity to question assumptions and approaches that are “the way things have always been done”. Have a new team member coming on board? Pay attention to where they get confused and what questions they ask. Have a new feature request that doesn’t make sense? Make sure you understand the goal and what is driving the desire for this functionality. If you don’t get a clear answer, keep asking why until you understand.Justin Etheredge’s blog post (#9 in the list)
Use The 5 Whys Technique
The 5 Whys Technique (read more here) is a way to figure out the root cause of a problem. The main idea is to keep drilling down into a problem by asking “why“ five times. Once the root cause is understood, then the solution is clear.
Don’t Be a “Yes-man”
It’s easy to slip into the habit of saying yes to everything and doing exactly what you are told –I am guilty of this. But it’s important to keep in mind that managers, TPMs, and PMs sometimes get it wrong. They are human and humans make mistakes and oversights. So it is important to push back when the acceptance criteria isn’t clear, or when an edge case isn’t defined.
As a developer, you are in the weeds of the code. You can see more of the edge cases. You have the power to define exactly what the app does in all the different situations. So take your responsibility seriously and push back when something doesn’t make sense.
Encourage Full-stack, User-story-focused Tickets
Tickets are important to track and communicate progress of the work being done. However, sometimes we rely too heavily on managers, TPMs, and PMs to break down the work in perfect bite-sized chunks for us.
As a capable, full-stack developer, you are qualified to break down the work yourself.
Ideally, management writes up a ticket in the form of a user story with clear acceptance criteria, intentionally leaving out the technical implementation details. You then take full ownership of your assigned ticket, doing things such as the following:
- Add technical details based on your research and feedback from the team.
- Create sub-tasks for more bite-sized chunks of work.
- Delegate sub-tasks to other devs.
- Move tickets across the kanban board from “in progress“ to “ready for QA“, ensuring everything works in each environment.
Don’t do this ☝️
Get Involved in User Interviews and Client-facing Demos
If possible, it’s a good idea to regularly interact with/observe the end-users and clients. How can you build solutions to a problem you don’t understand? Meeting with users and clients will give you first-hand insights into the problems you’re tasked to solve.
Depending on what you’re working on and who your Product Manager is, this might not be possible for you right now. But whenever you get the chance to meet with users/clients you should definitely do it. You will learn a lot and gain more empathy for the end-users –motivating and preparing you to build a better system to suit their needs.
It takes a lot of work to be a Big-Picture Developer. But what the world needs you to be right now is not another robot or “yes-man”. We already have ChatGPT, Bard, Bing AI, etc –and they can code pretty well. But your team needs you, and all the humanity you can bring to the table.
Don’t underestimate your ability to understand the big picture. Asking a few “why” questions here and there will open the door to greater understanding and make you a better developer.