Who is Alex?

Alex has been working in the software industry for about a decade. He started as a software engineer at startups focusing on building systems – first at a kernel file systems company and then at a distributed database company.

Eventually, he made the transition to become an engineering manager. He previously worked as a manager at Twitter and is currently an engineering manager at Google. He began sending his engineers to Mirdin during his time as Director of Engineering at Streamlit.

Why Mirdin?

As a manager, Alex has engineers that ask, “I wish I were a stronger engineer” or “I wish I knew technically what to be better.”

Most of the time, these engineers have never learned how to write code that’s extensible and survives as new features are built atop of it. Unfortunately, if this concept isn’t already known by the engineer, it’s hard to really explain why a piece of code isn’t great or provide structured knowledge on how to improve.

As a result, the only way for engineers to learn is through trial and error. It’s a raw input of time and observation, rather than some explicit process.

Mirdin solves this. The course teaches how to build something that can be extended and composed. In other words, the secrets to software engineering distinguish a junior or mid-level engineer from a senior, staff, or principal engineer. These are lessons that are not taught in colleges and never taught in boot camps.

Results post-Mirdin

Alex had sent two engineers who worked under him to go through the Mirdin course.

The first engineer was a fairly strong engineer who already had a background in devops but didn’t have the core fundamental systems or programming architecture-type skills. Those learning opportunities are also hard to come by.

After Mirdin, he became a much more confident engineer – his skills also became in line with someone who had a year or two more of experience due to the course. Alex was able to place him on bigger projects without needing to give him support, and had higher trust that his outputs would survive future extensions. In Alex’s words, he “went from a 5 to a 7”.

The second engineer was more junior, with a nontraditional background in tech. Because of her lack of experience, her work consisted of fairly small tasks, which didn’t expose her to harder problems for improvement.

Mirdin helped her onboard and ramp up as a full engineer. As a result of that, Alex was also able to trust her with more interesting problems. In Alex’s words, she went from “a 2-3 to a 5-6.”

As a macro level, he noticed that the two engineers were more engaged in their day-to-day work. They were now tackling complex issues that challenged them as engineers and helped them grow.

Building extensible software

For Alex, the challenge with software engineering is understanding and articulating programming decisions to build extensible software. The impact of “unclean” code isn’t felt when writing a feature for the first time. Rather, it’s felt the second time, when trying to extend the feature to support a new use case.

For example, Alex’s team had an internal system that sat in front of the database that wrapped all the logic for accessing the database. It was a great idea at the time but also led to a 10x increase in complexity when trying to make any fundamental data change.

It’s hard to see this on the outside. To realize that this was a problem, it required an engineer to reason about what it takes to change and modify code and think about the right layers, encapsulation, the right of boundaries, and the right ways of making code interact with other code.

That’s normally hard for engineers with even a couple of years of experience to understand. With Mirdin, the two engineers who went through the course were now able to articulate why they wanted to write code in a certain way and convince others around them, including engineers much more senior than them, to listen and implement their suggestions.

Final Thoughts

When asked about Mirdin’s pricing, Alex thinks that Mirdin could change 10x more and still be worth it. Doing the math, if Mirdin makes an engineer 5 or 10% more effective, it would be easily worth 5% of the engineer’s one-year salary. Mirdin currently charges less than that by a large margin.

At the same time, the best candidates for Mirdin are engineers who are ready to learn. He sends engineers to Mirdin when they realize that they don’t know how to grow without some kind of external input.

His final words for Mirdin were – “One of the things I love best about Mirdin as an Engineering Manager is that it’s hard to teach people how to write code like a Senior Engineer. I can teach them how to be a professional, like a Senior Engineer, but teaching them how to write better code is something that requires a level of precision teaching that I don’t frequently have the time to do as an Engineering Manager, or the context in what they’re doing… And with Mirdin, I can trust that they’ll be done right.”