So You Want to Be a Senior Developer. Start Being Curious
Paying attention is something that is drummed into you from childhood. But it's passive listening. The real value comes from understanding and making connections.
A client wanted to explore adding biometric login to their app. Months earlier, a penetration test had flagged the risk of rooted devices. We made recommendations, the client reviewed them, implemented, moved on.
But biometric data, stored on a user's device, that changes the risk. No one else had made the link yet. Flagging it early changed the conversation from "how can we do this?", to "how can we do this securely?".
That's what this post is about. Not just paying attention, but seeing how things fit together.
Stand Up and Listen
Standups are a huge learning resource that you may be overlooking.
In the example above, I wasn't assigned to investigate biometric login. But when my colleague mentioned the strands they were exploring, I made the connection. If I had simply treated it like a daily update, zoned out and gone back to work, I would have missed so many opportunities to learn and contribute.
Look for areas of overlap, look for similar problems that might share a solution. Have you already solved a problem someone else is struggling with? Take notice of what the rest of the team is saying. Did they flag a connection you didn't see? Think about how they got there, or ask them later if you still don't understand.
Seniority doesn't come without experience, but it doesn't just have to be YOUR experience. You don't need to have all the answers yet, the important thing is that you're looking for them.
Physician, Heal Thyself
Code reviews are not just about improving the quality of the code, they're also about improving the author. Read reviewer comments with an open mind, ask questions, and take those lessons on to the next task.
Look beyond your own code reviews. How have others approached their tasks, what feedback did they receive, do you understand the reasoning behind it? Ask questions!
Take the lessons you learn from reviewing other's code back to your own. Look at it with a critical eye. Would someone else be able to read and understand it? What would you raise if it wasn't yours?
Reframe
The tech doesn't matter, it's the thinking behind it that lasts. Focus on books that teach you how to solve problems, rather than give you the solution.
My personal recommendations to get started with:
Clean Code by Robert C. Martin - Make your code readable for those who come after.
Head First Design Patterns by Freeman, Freeman et al. - Start recognising the repeating patterns in your and other's work.
The Pragmatic Programmer by David Thomas and Andrew Hunt - Building the habits and instincts that will stick with you throughout your career.
Refactoring by Martin Fowler - Navigating and improving existing code.
As with the code, read them critically, translate them to your context. Some concepts may not map cleanly. Bridging that gap is where the journey to senior begins.
Not My Problem
As a frontend developer, when investigating a bug, my job is to figure out where it lives. If the data coming from the backend is correct, the fix lies with me. If it isn't, the issue belongs somewhere else.
For a long time I would keep going. Checking logs, sending Postman requests, digging into middleware code. Trying to hand over a diagnosis rather than just a problem. I thought I was being helpful.
What I was actually doing was taking longer than they would, and taking the learning opportunity away from them in the process.
Now I give them the cURL, the timestamp, and the response. That's everything they need. They diagnose it faster than I ever could, and they thank me for it.
Knowing where your expertise ends isn't a limitation. Listen to the backend developer. Listen to the subject matter expert. Listen to the person who has spent years in the problem you've just wandered into. You'll learn more, and the work will be better for it.
What have you noticed today? Join the discussion.