My name is Ken Mazaika and I’m the CTO & Co-founder of The Firehose Project.

In my first job as a developer I was a bit… irresponsible. I had the freedom to quickly cobble together code without completely thinking it through. I didn’t need to fully understand what I was doing before I moved on to the next thing. I was capable of building things out very quickly. But I was also capable of making some pretty serious mistakes.

homer_giph

The environment at my next company was very different. Managers reviewed code extensively before it was accepted. They also favored a process centered around test driven development, as well as many other responsible practices. I was totally lost, and felt way outside my comfort zone. My experience coding on this agile team was off to a rocky start.

I went from feeling like a rockstar, capable of building anything, to feeling like someone who wasn’t very good at his job. I struggled. In the process, I started working with a developer who was the polar opposite of what I had become. His name was Chris.

Chris was the opposite of me in nearly every way.

He was a good dev. He cared about the code, when I only cared about the end result. I idolized Chris. I wanted to follow in his footsteps and “be like him when I grew up.” At least once a week, I tried to convince Chris to pair program with me. I would help him work on his tasks, and I would stay late to complete the work I had been assigned. It was the least I could do to get the chance to learn from such an amazing developer.

Chris helped me start looking at the source code of the Ruby on Rails framework. He helped me figure out what the rails source was actually doing behind the scenes. He taught me much of what I know and the patterns I use today.

On multiple occasions, coworkers would ask me why I organized my code in a certain way. My response:

“I’ve seen Chris do it this way in the past and I’m trying to write code in a style similar to his.”

Their response was straight and to the point:

“That’s not a good enough reason.”

I needed to justify why I made a code change. So from that point forward, I would think it through logically and find the reason why it was the right approach. After hearing my rationale, coworkers would generally agree and let me know how much they appreciated the insight.

Following in Chris’s footsteps allowed me to emulate him. To this day, I still appreciate the things I learned from him. I continued to work with him for a couple years, and I learned a remarkable amount from him.

But one day, something very different happened.

Chris proposed that our team approach a problem a certain way. I disagreed with him. I explained to Chris how I understood the benefit of his approach, but I made it clear that the trade-off of the decision was too great. I felt strongly that it was actually not a good idea.

I don’t remember what the specific code change was and I don’t remember whose opinion ultimately prevailed. Frankly, it really doesn’t matter at all, and for all I know, I was completely wrong. But, it was the day I realized something very important:

Nobody has all the answers.

Once I realized this, I understood that I couldn’t simply emulate someone who I respected. Instead, it was my job to critically evaluate every detail of every single potential solution.

I finally understood why my coworkers wouldn’t accept my go-to answer: “this is how Chris would do it.” Despite the fact that everyone on our team respected and looked up to him, that answer wasn’t enough.

I continued to look up to Chris and I continued to learn from him. But the moment when I finally challenged him fundamentally changed the way we worked together. When we pair programmed, I would go deeper. I understood what we were doing, but I wasn’t satisfied with that. I needed to challenge him to understand why we were doing something as well.

A few months later, Chris left our company to work as an iOS dev at Sonos. I was genuinely happy for him. I knew I would probably never pair program with him again. And I knew I would miss our experiences programming together. But he landed a pretty awesome position, and as a friend, I knew it was a good move for him.

Chris taught me a lot.

He taught me many of the details of the ruby programming language. He taught me details of the Rails framework and how to apply best practices to my applications. He taught me the engineering principles that I value most today.

But most prominently, he taught me the importance of critiquing a problem based on your merits as an engineer. And how you need to let go of any outside biases that can undermine your decision-making process, even if one of them is the opinion of a mentor who you completely respect. Just because you look up to someone doesn’t mean that you can’t disagree with some of their points of view. In fact, challenging your mentor is often one of the best ways to level up as an engineer or in any type of position.

If you enjoyed this post, you might want to share it with a mentor who helped change your career!

ultimate guide to programming languages

Recommended For You

Leave a Reply

Your email address will not be published. Required fields are marked *