Musings of a New Grad Engineer

I joined Panorama Education as a Full-Stack Engineer fresh out of grad school. I’ve been very fortunate to have had a positive experience with my first job out of college, and wanted to share some of the important elements of day-to-day work that have made this an enjoyable experience. The following is a brief snapshot of what I’ve learned and am continuing to learn based on my own personal experience.

Engineering is collaborative

Back in school, coding was usually a thing you do yourself. Sometimes you’re working on group projects, but most of the time, it was me and my laptop. At Panorama, I’ve learned that there are parts of software engineering that are done individually, but there is a huge part of work that is collaborative. There are many opportunities to dig into a problem as an individual, but nothing can really get done without at least one other person. It is impossible to build and maintain something of large scale and impact alone.

Take code reviews, for example. It’s a way to help prevent bugs and helps engineers keep each other accountable. Since starting at Panorama, what I had once seen as merely a safeguard against bugs has become a well-established system to give and receive feedback and to learn from each other. Code review is at its core collaboration.

Working with others is essential. And when you’re working on a team, coding is not the only thing you do. You might be communicating closely with designers or product managers. You might organize technical projects to completion. You might mentor others, or participate in pair programming. Yes, this may mean that you’re writing less code than you would if you were building out an entire system by yourself, but I’ve learned that this trade-off leads to systems that are more likely to be resilient and sustainable, increases knowledge sharing, and fosters an overall more enjoyable work culture.

There is value in focusing on growing where you currently are

During my first few months of Panorama, I found myself occasionally thinking, “I’m not growing as an engineer if I’m not daily gaining skills that will prepare me for the next company.” Tech culture says that you should start looking for a new company after 2–3 years, or maybe even after 1 year. It was also my old student mentality: “What do I need to do to graduate?”

But then I realized I didn’t want to leave. I enjoyed working with my coworkers, I was learning and being challenged, and I was motivated by the work we were doing. I didn’t need to leave, nor did I want to. I was focused on how to prepare for the next company, instead of stopping and appreciating the opportunities I had to learn and grow where I was.

There is nothing wrong with wanting to switch companies after a couple years, and there are many situations in which leaving a company is the best thing for someone to do. What I have learned, though, is that career advancement in software engineering doesn’t need to mean moving to a different company.

Structured professional development on the engineering team is relatively new, and it isn’t perfect. Engineering at Panorama recognizes that and thus treats our levels document as a living document. We as engineers can give input into the development of this document and contribute to its evolution over time, and this evolution is transparent across the department. What I’ve grown to appreciate is the openness to feedback and the collaboration that exists here in building out what professional development looks like for Panorama engineers.

This overall approach in fostering engineering growth has played a key part in my experience at Panorama that keeps me here at this company. Structures and culture are in place such that my accomplishments are recognized, my weaknesses are improved with guidance and patience, and feedback is essential.

Imposter syndrome is still there, but good company culture can help some

Initially at Panorama, I realized that there lingered a mindset that I had developed during my college days- I had believed that the number of lines of code I churned out every week was directly correlated to my success as an engineer. And if it wasn’t the number of lines of code, it was the quality of the code and how fast I was able to churn out that high quality code. A lot of this mindset had been influenced by the technical interviewing process in the software industry: “I didn’t pass that technical interview. That must mean I’m not good enough of an engineer.”

Your ability to pass a technical interview is not at all related to your worth or your ability as an engineer.But sometimes, that imposter syndrome voice sneaks up even if you know that what it’s saying is false.

I don’t have a silver bullet for how to deal with imposter syndrome, but I do know that the company culture I’ve had the privilege of being part of has helped some. Panorama is really big on taking time to reflect. Weekly squad retrospectives and Before-Action-Reviews and After-Action-Reviews for projects are some examples of reflection being built into our daily work. This culture of reflection has encouraged me to reflect more personally. I’ve learned that reflection is so crucial in recognizing the patterns of thinking I fall under and determining if they are constructive. Spending time to do so makes it easier to identify that imposter syndrome voice.

There is also a strong belief amongst my coworkers that mistakes happen, and they should be used as experiences to reflect on and lessons to learn from, not something to be punished for. My coworkers are not just open to, but are eager to share mistakes and lessons learned from mistakes of the past. Having these models of humility in engineering has been gradually shaping my mindset on my own mistakes, as well.

Feedback from my manager and my peers has also been helpful for me in terms of imposter syndrome. When I feel like I’m falling behind, instead of being unsure if I’m doing well or not, I can trust my coworkers and managers that they will tell me what areas I can grow in, and what areas I’m doing well in. And if I’m not getting that feedback, I’m empowered to ask for it. As I have more feedback conversations with my peers and my manager, I’m repeatedly reminded that there is a shared understanding that we are here to support one another. That has really helped with imposter syndrome.

I’ve written about these lessons I’ve learned here, but I do still waffle between my old and new mindsets. I still sometimes ask myself if I’m really “being an engineer” if I’m not sitting alone coding 100% of my work week. When that happens, I remind myself that working on big problems is best done as a team. I still question if I should be spending time practicing technical interview problems so that I crush my next interview should I leave. When that happens, I ask myself if that desire to leave is rooted in job dissatisfaction, or in some perceived tech industry expectations. I still suffer from imposter syndrome. When that happens, I take a step back and try to reflect. It’s not easy, and the cycle repeats sometimes. But let this be a reminder to myself, and maybe to you, that it is OK- this is what growing looks like.

Originally published at https://engineering.panoramaed.com on June 7, 2019.