Article summary
I’m at what feels like a weird point in my career as a software developer. Four years of experience isn’t nothing. But, in a job where we change projects routinely, I sometimes worry that I get more breadth and not enough depth of experience. In contrast, things were easier as a new dev. I paired with a senior, and everything they said was a new thing for me to learn. Nowadays, it’s easier for me to settle into a routine on a project, taking care of work to move things along. It’s also easy to drift without much of a need to push the boundaries of what I’m working on or what I know.
At first, this was a comfortable new status quo. After a long period where everything I did was something new to me, something known and routine was appealing to me. However, after some time, I recognized that I still wanted to keep finding a deeper understanding of my work and continue to prepare myself for taking more responsibility for my projects.
Teach and Learn
“Get a deeper understanding of my project” is a pretty broad goal. It’s too broad to just pick something to start learning about without fear of going down a rabbit hole that won’t benefit the project. But, fortunately for me, an opportunity arose when we started onboarding new members to our team. Suddenly, there were people with minimal experience with our domain and tech stack that wanted to learn more. So, I started putting myself in a position to answer their questions as they had them.
It’s common knowledge that teaching something is a great way to reinforce your own understanding of it. That definitely has held true for me as I’ve tried to be the go-to person to answer questions on the project. Teach and Learn is also one of Atomic’s six values, and it’s benefited me greatly in this early stage of my career. With this experiment, it really feels like I’m teaching to learn.
Deepening Understanding
I used to get by with being able to add components to our front-end project or update business logic in our API. But, by teaching the new folks on the team, I was forced to reevaluate my understanding of the project as a whole. Why do we use certain patterns? What’s going on when we’re routing from one page to another? How does our CI pipeline really work?
In my routine, I had stopped asking questions like these and started taking entire parts of the project for granted. Putting myself in a position to answer all the questions of team members seeing it for the first time gave me a great excuse to deepen my own understanding. It did this in a way that helped me and our new team members, without any guesswork on my end for arbitrarily picking things to learn about.
I’d definitely recommend this strategy to anybody in a similar position. Since making a conscious effort to work this way, my day-to-day work has felt more stimulating and has helped me practice a new style of learning. It’s felt like the right step forward in my career as well. I’m not entirely relied upon to know everything about my projects, but when I put myself in a spot where I’m the first person to try to answer a question, it feels like progress toward improving my sense of technical leadership. It’s been an experiment that I’m definitely going to continue.