In my first several months as a junior developer, everything was brand new and intense. Expectedly, most days I was overwhelmed by the amount of information being thrown at me and the breadth of everything I had to learn. I was very motivated to do my best to learn quickly, not only so I could become a productive, valuable contributor on my team, but also so I could put intention towards getting a promotion.
Going through the first 6 months of my first position was an emotional roller coaster. Some weeks I felt like I was learning and moving fast, and that I was contributing more and more to deliverables for my team. Other weeks, however, I felt like I hadn’t contributed anything, even if in hindsight, I was still learning a ton even when I wasn’t writing many lines of code. Looking back, I can see now that, sometimes, progress as a developer can be hard to mark and internalize, especially when I felt like I was just trying to keep my head above water with everything I had to learn and know.
I also had a big goal of working hard towards getting “junior” out of my title to achieve a promotion to a mid-level engineer position. Being able to demonstrate my ongoing accomplishments and increased capacity for more labor-intensive work would be important to make this happen. This certainly added pressure to my work flow, knowing I wanted to show that I could handle more responsibility soon. One thing I came to realize though, too, working on a small team at a small company that had only ever had a single junior developer before, was that there wasn’t yet a lot of structure or metrics in place to determine how a junior developer could accomplish getting promoted.
At some point while working towards this goal and struggling with the emotional ups and downs of growing in my role, my partner (who is also in tech but further along in his career than me) shared an experience he had had that he felt could help me as I worked to feel confident in taking on more complex problems at my job. One of his new reports expressed they were having a hard time emotionally at work. This person was still relatively new in their career as well and had started working on more complex problems within their role. They were delivering what needed to be delivered and doing good work, but they didn’t feel like they were doing well because the pace at which they moved now was slower. Because they weren’t shipping as regularly as they used to, they were struggling in their confidence to feel that they were doing enough to contribute to their team. This simply wasn’t true. Taking on more complex problems requires more time and effort than solving small, concise problems will, but generally provides greater benefit to a company and its customers. While talking with his employee, my partner realized that it was important to provide structure and opportunity for more junior employees to have regular “wins” to keep morale up, while also gradually building them up to be able to tackle more intensive problems. I, too, felt the growing pains of being able to take on more complex problems but the loss of feeling like I had accomplished something daily or weekly because the number of my “wins” were fewer, even if the weight of the wins I did have was greater.
I came to realize that I wasn’t doing a good job of seeing my accomplishments and growth as they were happening. I needed to find a way to do so, so I set out to create a system that would help me build confidence and recognize wins as they happened. Simultaneously, I knew I needed to keep better track of my accomplishments to share with my direct manager that could provide clear evidence through metrics to support an eventual promotion. In order to do this, I came up with a simple but valuable reflection template - the template you will see below - with a mix of qualitative data and quantitative metrics that I used to track my professional growth and work contributions at the end of the week every week while the details of the week were still fresh in my mind. Eventually, I started my reflections earlier in the week and added to my weekly reflection as I recognized that I was doing or had accomplished something I wanted to mark. Doing so regularly helped my confidence as a junior developer immensely. No longer would I float through weeks, feeling like I had contributed or grown little. No longer would my brain miss all the ways, big and small, in which I was moving along nicely in my professional growth.
Weekly Reflection
Date: _______________
What did I learn this week?
What goals or deliverables did I complete?
What did I find challenging?
What areas can I improve on?
How did I support others?
What is one (+) thing I should do next week that would make the week successful?
What do I want to learn next week?
Metrics
Pairing/collaboration count: ________
Total Points Worked on this Week: _________
Tasks deployed: _________
Bugs fixed: _________
PRs opened: _________
Any other metrics worth mentioning:
A couple of things are worth explaining briefly in this template, namely, in the metrics section. My team uses a task management system within two-week sprint cycles where at the beginning of each sprint, we prioritize tasks that need to get done and ascribe “points” to each task. These points range from 1 to 8 and serve as guesstimated markers for scope and how much effort any given task will take. A ‘one’ could be something as simple as updating the verbiage of a copyright statement. An ‘eight’ is a task large and/or complex enough that it is very likely going to spawn a few additional tasks to keep the scope of the needed deliverable reasonable as progress is made. Tasks for bugs in existing projects are not given points as it is much harder to quantify the level of effort required for unexpected and undesired results in a feature.
I wanted to track the number of times I paired with a teammate or collaborated on a task, as sometimes, the time I spent paired with colleagues wouldn’t translate directly into tasks I could claim responsibility for but were still work that I contributed to. I wanted to track the total number of task points I worked on and the number of tasks I was able to deploy. I also wanted to track the number of PRs I opened, as sometimes PRs get closed without deploying to production, but that doesn’t mean that work wasn’t still valuable to the company or wasn’t an opportunity for me to learn. I also wanted to keep track of which tasks were bugs I worked on, since their scope can be widely varied in complexity and can take a long time to isolate and solve. I iterated over this template as I was using it the first few weeks to get it to a place that was useful for my day to day developer experience and easy to use. To help me remember to set time aside for doing these regular reflections, I added a recurring 30 minute event to my work calendar on Fridays that included the URL to this Google Doc reflection template. (Substituting “copy” for “edit” in the URL of a google file allows one to quickly and automatically make a copy.)
Feel free to use this template as a starting point for your own reflections to support your own growth as a junior developer. Since I have started doing weekly reflections, now, when I do 1-on-1’s with my manager, I am able to regularly provide them with evidence of my growth as a developer and demonstrate the increasing complexity, breadth, and quality of my work while I work towards getting promoted. Just as importantly if not more, clearly identifying my growth and accomplishments, especially while I was struggling to see or feel like I was getting better in my first developer role, was invaluable to boosting my confidence and morale. And making a practice of reflecting on and tracking one's work and accomplishments as a developer isn't just valuable as a junior dev; this practice can continue to provide benefit throughout one's career and evidence of one's growth over time.
Getting your first job in tech as a developer is an incredible accomplishment. Dealing with the reality of the growing pains in that first role isn’t just technically challenging, however; it is also emotionally challenging. Finding ways to ease that transition, like making a point to regularly track one’s accomplishments, can make a big difference in a developer’s emotional well-being, as well as encourage professional and technical development.
Top comments (0)