About three months into my current job, I had my first opportunity to work in my company's backend/API codebase. It was an adventure, and while it ended well, it also solidified my desire to work primarily on our front-end codebase. Since then, I've had a few opportunities to work in the backend codebase and while I have completed them all with varying levels of success, working in the backend codebase is never my favorite thing to do. In fact, before this week, I hadn't worked on a backend ticket in about 3-4 months. One of my goals for the second half of 2020 was to become a more well-rounded developer and contribute to all of our codebases, and when I realized (as part of my reflections on my first year at the job) that I hadn't contributed to the backend in a while, I knew I wanted to take on a backend ticket before the end of the year. As part of a project that my team is working on (that I will be contributing to) we needed to create a new API endpoint, and I volunteered to work on that ticket.

Now that I had a backend ticket assigned to me, it was time for me to get to work. My first step was to figure out what needed to be done. I started by reading through the tech plan for this project to make sure that I understood what this new endpoint would be returning. From there, my next step was to see how someone else had implemented a new endpoint, so I took the opportunity to look over a PR where one of my teammates added a new endpoint. My team's backend engineer had volunteered to walk me through what needed to be done, so we had a call where he explained all the parts that needed to be completed and in what order. Based on that conversation, I made a more detailed list of exactly what I wanted to do (including any new files that needed to be created) so that I was fully ready to get to work.

I can sometimes get too absorbed in work and solving problems on my own, but since I'm not very familiar with this codebase, I knew that just letting myself continue to try to problem solve without help was not likely to lead to success. I set myself a hard limit of one hour to work on each item in my detailed list of tasks, and decided that if I wasn't close to completing the item in that hour, I would ask for help. Things started out going well, but when I ran into some trouble, I just kept going and didn't respect my one hour deadline, which I knew meant the task was going to take longer than I expected. After about a day of doing things that way, I decided that for the future I was going to set an alarm to go off every hour as a way of reminding myself to ask for help. What I ultimatley ended up doing was setting an alarm for 30 minutes from when I started the task, getting up to take a break, and then setting another alarm for 30 minutes later. My intention was to ask for help after the second 30-minute work period, but I never ended up needing the help.

Once I had the list of what needed to be done, the actual work was fairly straightforward. My initial approach to the work was to do all of the work and wait until the end to write tests, which I think was a mistake. After a few days of work I decided to spend the next morning writing tests for all of the components, and that helped me identify some areas where my code was not doing what I expected. There was one area where I had wanted to introduce a new interface to make the API call more efficient, but I had trouble making that work, so I ended up using an existing interface with the hope that I could apply the efficiencies later (spoiler alert: I was later able to get this new interface up and running). After a few days of work, all of my tests were passing and my code seemed like it was doing what I expected it to do, and I was ready to get feedback on my work. I put in a PR, posted it in the appropriate Slack channel, and tagged two potential reviewers. I also sent it over (via DM) to my teammate who had written the tech plan on this so that she could take a look. Some comments were left, and I'm excited to dig into them deeper and figure out how to improve my code.

The biggest thing I learned from this ticket was the actual work of creating the new endpoint. This is something I had never done before, and while I'm not running to do another one any time soon, if I am asked to do similar work again, I know that I can do it and will be much more confident in my work. I struggle a lot with my confidence at work, and having a ticket where I went in not really having any idea what to do and was able to complete the work in less than a sprint (and the PR was put up in less than a week) helps me feel like I can do this and I do belong here. Another important lesson that I learned is that the key to accepting feedback is framing it properly. Often when I put up a PR, I put it up with the hopes that it will be improved and I can merge my work. With this PR, I knew there would be suggestions for improvement (the likelihood of me doing something this big and not getting any comments on my first try is pretty low), and when I received those comments, I was excited about them, not upset or unhappy that my work was going to take longer. I also came out of this experience with an area where I need to improve - I need to be better at reaching out and asking for help when I get stuck. There are times when I probably can solve a problem with more time, but I might solve it more quickly by asking for help - and I need to be better at asking for that help.

This ticket is not yet complete - I still have some edits to make based on PR comments and maybe some optimizations - but I already consider it a success. I stepped outside my comfort zone, worked on something that was entirely new to me, troubleshooted some bugs in my code, and I'm on track to complete the task in a timely manner. Beyond the code, I do have improvements to make to my process (like learning to ask for help as soon as I realize I might need it) and finding the right time to write my tests). But overall, I think this ticket is going very well and while I still prefer working on the front end, I do feel a little more comfortable with the idea of jumping into our backend codebase a bit more often.