Panorama Values: Progress Over Perfection

When I joined the Panorama Education team, I was still very new to this field of work and full of anxiety. While I understood that I was hired for a beginner level position, I was worried of all the mistakes I could make and that I may not perform well enough. Contrary to the unpleasant thoughts and expectations I was giving myself, I have never experienced any of the fears I had. Panorama was a safe space to learn and grow. I felt that their value of Progress Over Perfection was truly practiced daily.

The first time my manager asked if I was interested in leading an epic, I definitely felt shaken but after my experience working here so far, I felt reassured that I could tackle a new challenge. I had plentiful pairing sessions, many Slack threads where peers were more than happy to talk and answer questions, and several occasions to talk to individuals on Zoom. Never did I feel that anyone was upset at me for asking questions, writing the wrong thing, or even merging a bad ticket. We focused on finding the solution and understanding what we could learn from all these opportunities.

I was a co-captain with my teammate who joined the same day as me, and it was a great experience for us both. We worked together exploring a spike to plan out a technical path and ended up writing only a handful of tickets for a relatively small project. However, as we started developing, we learned that we had some initial misunderstanding, but our manager quickly helped us prepare another meeting and further discussions. We focused on communicating clearer rather than the mistakes already made. Also, one of the tickets I had written and worked on ended up being much larger than we estimated. This was something we addressed in our after action review, where we discussed that we could have benefited from sharing out the initial spike with the team in the early stages, as extra eyes could have caught the issues we weren’t prepared for. Initially, I felt embarrassed by how severely I underestimated this ticket and had to bring in so many pairing sessions to complete it, but afterwards I simply felt a ton of appreciation for my team. They were here to provide support and help the project succeed. It’s okay to not be perfect and make mistakes. All of the pairing sessions helped me learn a lot about our code and skills in developing. The experience collaborating with different team members and planning out a project felt invaluable and I’ve gained so much more insight and appreciation for the process.

Now I’m experiencing my 2nd project being a co-captain and I’ve been practicing what I’ve learned. I’m communicating earlier and more frequently. I’m putting in extra effort into making resources to stay organized. I reach out for extra eyes and support sooner rather than later. While I still don’t feel like I have the confidence to lead an epic by myself, I certainly feel much more prepared this time around. Even though I’ve had some misunderstandings and mistakes in this epic as well, the tickets I’ve written feel more digestible and detailed. The technical path seems clearer and I have a stronger understanding of how things work. Overall the process feels smoother, and while I still have a lot to learn, I’m proud of the progress I’ve made.

This has been my story and below are how my peers, Corey H., Dan F., and Ila K. experienced Progress Over Perfection here at Panorama Education.

Corey Hornbeck

Software Engineer — Infrastructure Squad

The transition from a 20-person startup to a developed engineering team can be a humbling experience. Before Panorama, I was pushing code without tests. Fast-forward to my first month, I realized my code structure isn’t readable and my tests don’t actually test anything. I’m exaggerating here — Panorama has had a genuine take on self-improvement — but before I joined last year, I was stuck in a “good enough” mindset; if your code worked, that’s all that mattered.

In my previous team, I was the 3rd full stack engineer. We were all decent at coding but pretty mediocre when it came to software engineering. Code readability, tests, and documentation were forbidden phrases as we had to quickly develop internal tools and test our GPS devices before shipping to customers. There also wasn’t much structure in our codebase beyond the typical MVC framework. In a startup of 20 people (before remote work was a thing), it was all too easy for Marketing to pull you into a new project. There was almost no time to document your feature additions so future engineers wouldn’t bang their head against a wall trying to debug your code.

Panorama’s Progress Over Perfection value has been very refreshing considering big tech companies like Amazon have become memes for their PIPs. At first it was frustrating to not get PRs approved until you use the right indentation, but you immediately see how valuable readability is in a vast codebase. In one instance, I received an error because I used the `in?` method on `NilClass`. I thought Ruby didn’t support safe navigation into hashes, so I just typed out `some_obj&.downcase&.in?(%w[a b c])` since it fixed the error. In my PR, the reviewer reached out in Slack to let me know we should be asking why we’re receiving the error here but not other repos where safe navigation is used. I quickly realized the file didn’t include ActiveSupport, which adds a method to `NilClass` for safe navigation. It was a small thing, and even though it made me feel pretty naive, I was glad my reviewer’s feedback was constructive. It definitely beats receiving feedback when you’ve merged code that breaks the app. It’s this type of interaction that fuels a safe environment to learn and progress your attitude towards better engineering practices.

Dan Franklin

Software Engineer — Data Ops Squad

I was only at Panorama for a few months before the opportunity came to take on a major project: upgrading the Ruby version used by one of our major products, Student Success, from Ruby 2.6 to 2.7. I was looking for a big challenge, so I volunteered.

I was new to Ruby, having learned it at Panorama, but in a previous job I’d upgraded our PHP language version several times. Here, most of the work had already been done; my primary job was to do more extensive testing, particularly of the code that interfaces to the student information systems we support.

I quickly ran into an obstacle: summertime. It turns out that when schools go on vacation, their SIS configuration isn’t in the best position for testing, since it is between academic years. I persevered, but it slowed my progress.

My tests succeeded. I discovered an issue in building our images that would have impacted developers when they updated.

Finally I felt ready. I put up my changes, which were approved and merged into the main branch, and they went live that evening.

The next morning I learned that my changes had to be reverted: temporary files created during the SIS interface process were disappearing before they could be read.

I still don’t know how this problem escaped my testing.

I felt pretty bad about this, but true to Panorama’s value of Progress Over Perfection, no one criticized me or asked me to explain how this could have happened. On the contrary: one of my colleagues suggested that, given all my hard work, I should consider taking the day off. I chose not to, but it was very comforting that no one had the attitude that since it was my fault, I needed to find the problem and fix it ASAP.

With the help of a more senior team member, we identified the problem: an interaction between Ruby’s garbage collection, the internals of Ruby’s Tempfile module, and our use of lazy evaluation caused temporary files to be deleted before they could be read. I applied a simple workaround to all the relevant places in the code, and the next time the code was launched it worked.

While it was a chastening experience to have my code reverted, the reaction of the rest of Panorama has enabled me to take on more projects where I start out feeling unprepared, knowing that my team will support me as I learn.

Ila Krishnamoorthy

Software Engineer — Integration Tools Squad

In March 2020, right before the onset of the pandemic, I graduated from a coding bootcamp in Spain. I clearly remember, cruising at 35,000 feet on the last flight out of Barcelona, a distinct and pungent fear. Both for the impending COVID pandemic but also for the unknown landscape of my life ahead. I had just made a huge leap out of my comfort zone of the Arts and into the technical domain.

In the Arts, I had known how things worked, I knew how to walk the walk and talk the talk. Language in particular was used in a more fluid and tenuous manner, often indirect with a certain amount of on the fly meaning-making. I walked through that space with ease but now I had to learn to maneuver through a world where accuracy of language and didactic specificity reigned supreme.

Cut to March 2021, one full year later, I began working as a junior full stack developer here at Panorama. On paper, I should have been nervous, a new job in a new field in a new modality of working (remote/Zoom/etc), a new language (my bootcamp was in JavaScript and we code in Ruby), and I was, but not for the reason’s mentioned. I felt like I couldn’t communicate with people like I used to. I remember once talking to a PM and leaving it feeling like they had been speaking another language. I felt useless during planning meetings and was constantly using the wrong terminology or felt at a loss for words during pairing sessions and daily standups. I wasn’t used to dealing with this barrier and it made me feel acutely not… perfect.

After the first few weeks I opened up to my manager about how I was feeling. We spoke at length about the nature of communicating technical topics and about how I could regain the confidence I had had in my previous life. I started to pay close attention to how different folx wrote their tickets, drafted their asks in Slack, gave status updates, and communicated technical information with non-engineering coworkers. I identified which type of communication styles were most natural to me and started out simply trying to emulate them. During weekly touch-bases with my manager we reflected on the progress I was making and were both pleased to see that I was engaging more and more in meeting spaces and that conversations around me were starting to feel a lot more like plain english. Day by day I was chipping away at that overwhelming feeling of otherness and eventually I realized I was able to slip into tech-speak without much thought. Everyday I am grateful for Panorama’s continued emphasis on Progress Over Perfection. It is one of the many shared values that has given me the space to grow into my role and become the engineer I am today.