I've recently come across a question in a developer forum asking about "how to advance to a senior developer role". As I once started as a junior developer, I have appreciated articles I've read about other people's journey, as they inspired me to always do better and improve.
Now as a person in technology, it only makes sense that most of the advice given by other senior developers were to increase domain knowledge in a tech stack that they are building their career on. I feel that there's a lot of guides about developer roadmaps in various technologies already, so let me be different and share about my own tips on the other side of being a great developer: good behavior.
There's a reason why there's a behavioral interview!
Now, how did I conclude that behavior is one key to seniority? Well, let me tell you a quick story about myself. From college, I was an academic achiever. I do my homework well, pass (and mostly ace) all my exams, and consistently got high marks because of it. But I was a shy girl. As competent as I was, I never took initiative to do public speaking, lead school activities, and just settled on the background. I still graduated with an academic distinction.
Going to the early part of my career, I know that I was a great developer. I deliver code and contributed a lot to the product. But somehow, with feedback, I was mostly looked at as someone average. After all, I was just doing my job description. Nothing exceptional there.
With experience, I encountered different problems to solve, that required me to step up and learn "new behaviors" to get through them. There is a popular quote:
Experience is the best teacher.
Through the process of performance reviews, I was made aware of people's feedback and what I may have done in the past that they want me to continue doing. I've noted down all the good feedback and listed common behaviors that people identify as positive, and something they look for in a teammate or leader.
Consistency with these behaviors certainly brought me in a better position in my career, and when people ask me for career advice, I always advocate to improve on behavior as much as you improve on learning technology. I hope to share these simple tips as guidance, as you may find yourself in a similar situation requiring a demonstration of such behaviors.
1. Show respect
As basic as it sounds, you'd be surprised how many people don't understand etiquette. Simple things like not being late, giving others a chance to speak, giving feedback in a constructive manner is showing respect and should be done consistently. Be excellent in showing respect, and others will provide you with the same level of it. Quid pro quo.
Failing on the basic things makes you fail as a leader.
2. Ask; but...read, before you ask.
Never assume that you are an expert who knows everything. If a requirement is unclear, clarify. Even if you understand a requirement, re-state the requirement back to the person and verify if you have the same understanding. It saves a lot of time not having to re-work things because of misunderstanding. A good developer asks. That includes asking for training if you feel unequipped to tackle a problem.
Now, how do you level up? Read before you ask. In a previous job, I escalated a blocker to a senior software architect and said I am blocked from my task if this isn't resolved. I didn't provide any details, and just said it doesn't work as expected.
Looking back on it, maybe I sounded as someone giving him a problem and expecting he resolve it for my sake.
I was scolded in email, and told to provide more information as it helps the person understand the problem better, eliminate assumptions, and generally save time. It was a big learning experience from me. From then on, I never escalated an issue without doing an investigation first. Partly because I agreed with what he said, and partly because I was suddenly scared of asking him again. 😂
Never ask unless you have done the bare minimum of investigation. It's a bare minimum on a developer's job description to be a problem-solver. Asking help without doing the bare minimum is just plain lazy (ouch!). Developers have a rich knowledge base of solutions to common problems (and resolution options). If you ever encounter a question in a forum to which you have a different solution, make sure to add a note to help others who come after you. Give back to the community.
3. Scare yourself with your goals
Always do the things that scare you. I still need to constantly remind myself this when planning what I want to do for the year. A wise mentor once reminded me of the saying: "shoot for the stars, land on the moon". If I keep on setting easy goals, I won't really progress much in my career. If I set a big goal that I never imagined I could do, I am forcing myself to learn new things to reach the goal. And even if I don't meet it by a certain timeline, I would still be able to have done some tasks under it, having progress towards the goal (at least at a percentage).
4. Take initiative on solving unsolved problems
A team has goals required to be delivered at a certain timeline. Now, in the interest of time, the team sometimes decides to do the easy way as opposed to the right way. The easy way fulfills the requirement, but might introduce a future problem to the product. In software, we call this technical debt.
At times, technical debt is a compliance issue. We accept the risk of non-compliance, to keep the business running. If ever you catch yourself with free time, why not try picking up one of the aging debts of your team and solve them. The benefit is you learn a task that nobody wants to do, you help the team sleep better at night, and you make upper management happy as you clear up your debt board!
5. Documentation makes a mark!
For me, documentation is like teaching (only in written format). Writing technical documents that guides others saves effort especially on repetitive tasks. I handle changing tasks everyday, and when I get a task I've done before, my weak memory fails me, and I have to think of the solution all over again, even if I have already spent x number of hours on it before. I don't want to spend another x number of hours on the same task, so I keep a note of what I did and easily go back to it when faced with a similar task.
I found that this extra effort has helped other teammates as well, including serving as a guide for onboarding new developers to the team. Your teammates will certainly appreciate it. At times, technical documentation also helps me reflect on accomplishments at work and serves as a reference for doing performance reviews.
Wow, looking back at all these experiences makes me admire my former mentors for having the patience to train the younger me. There's certainly a lot more behaviors we commonly see among leaders that are good to imitate. If you have other tips, feel free to add them in the comments for other readers to discuss on!
Top comments (2)
Wonderful points and eloquently delivered. From this I've realized that I need to set some more explicit goals and make sure they scare me.
I agree with everything here especially documentation!! You can never have too much information!