Over the course of my time at my new job, I've had the opportunity to code side-by-side with a few of my teammates. Whether it's walking me through part of the codebase, reviewing my code to see why it's not working, or helping me learn a new concept, my teammates have made themselves available to work with me and help me settle in. While I've had a few opportunities to code with others in the past, it wasn't part of my learning process at my last company, and I've found that working with my teammates has really helped me acclimate to my new job faster than I expected. I've also found that pairing with others improves the quality of my code and ensures that I am doing things in a way that allows our app to perform as we need it to.
One of the best parts of having teammates who are willing to take the time to work closely with me is that they can help me learn new concepts. Many of the things about my company's codebase are new to me, from how the code is organized to working in Typescript (and many things in between), and having someone help me navigate through these new concepts (I get a lot of Typescript warnings that I don't immediately know how to resolve) has made the learning process a lot easier. One example of this is one of the most complicated (and most interesting) things I've had to learn in this job. My team uses state machines (using the xstate library) in a few parts of our app. I had never been exposed to state machines before, and while I learned a bit from reading documentation and looking through the app, having my teammates explain the concepts to me (both in a general sense and how we use them) really helped me understand the code I was seeing.
Working with teammates also gives me an opportunity to receive guidance from someone with more experience. I was recently working on a task that involved a part of the app that uses state machines, and while I at that point had a decent general understanding of state machines, I wasn't entirely sure how to best use the state machine to achieve my goal. One of my teammates, who had originally set up this particular state machine, walked me through what needed to be done and where in the state machine code I should be making my changes. From working with my teammate, I learned about writing actions in xstate and how to use these actions to make changes to the state machine, and with that new knowledge, I was able to complete my assigned task.
There have been times where the teammate I'm working with is just as unsure as I am about how to solve a problem, but just having a second set of eyes on the code can help things become more clear. I recently was working on a new (to me) task in a part of the codebase with which I had never worked before, and I wasn't entirely sure where to get started. One of my teammates had offered to help me with the task, and while he too had never done this task before, having someone sit next to me and help me figure out what to try was what ultimately led me in the right direction.
Once my code has been written, I've found that working with a teammate can help me discover why my code may not be behaving as expected. Early in my time at this job I submitted a pull request for code that was working as expected in the cases I had tested. My teammate tested the code and found that it was not working as expected in certain situations. My teammate was able to determine what to do to make those situations work, and together we were able to incorporate that with what I had done with his suggesting to get the behavior of the app to be as expected in all situations. Working with my teammate not only exposed me to a bug that I hadn't found in my code, it also gave both of us the opportunity to fix the code in a way that works for all situations.
As much as I enjoy my silent solo coding time, I've learned a lot from pair programming (or just discussing code) with my teammates, and that has been a valuable part of my experience at my new company. Working with more experienced engineers has taught me a lot, both about the code I'm writing and about how to find solutions in the codebase, and I'm excited to continue to learn (and to hopefully one day be able to teach my teammates a few things).
Top comments (5)
I wish my silent coding time was silent. I spend it muttering to myself. I'm sure if anyone heard me they would think I was either crazy or a mad scientist ๐
I'm happy that I'm not alone in this, I do that all the time ! It helps me stay focused and keep my "mental map" of my code paths in sync with what I'm writing.
Seems to be more common than I thought.
Ha! I'm also regularly talking to myself during silent coding time. That's how the best work gets done!
It really does work ๐