github twitter linkedin email
The Best Developer I Have Ever Met Was the Worst
Aug 25, 2020
4 minutes read

Many moons ago I met the best developer I have ever encountered. I was enamored by their ability to recall any piece of information that they have ever seen. They had dozens of patents, scientific papers, and a work history nothing short of genius. They built tools and languages I used on a daily basis. They were a true prodigy and I could not believe I had the privilege of working under them.

Over the course of a year I helped build a service with them and ~20 other engineers. I was a mid-level engineer at that point and there were many principal engineers on the project. It was intellectually stimulating and challenging – and arguably the most complex work I’ve ever done. The kind of work you usually read in white papers, except it was a new white paper every day. It was impossible for me to keep track of everything, I was hardly productive at all, but I was competitive and determined. I challenged myself every day to keep up with the mad genius.

Other engineers would do design reviews of new features and offer ways to improve the product. Every time they left the room broken and disheartened because the engineer had said their ideas were not good enough and there was some better way to solve the problem. Nobody was ever able to contradict the engineer - they had so much power and influence on the team - and great technical solutions. When you deeply thought and examined the engineer’s counterproposals, they always made more technical sense than whatever you proposed.

In our zeal to create the perfect technical product, we had totally neglected how users would interact with it. We had created a service which was impossible to maintain because its inner workings were so complex and sophisticated. The majority of engineers could not meaningfully contribute to the code base and were wholly ineffective. Users of the service were extremely confused because the interaction model was complicated and unintuitive. When there were issues with the service, only a small handful of engineers even knew how to fix problems. This led to devastating day-long live sites - and frustrated customers.

If our own team had this much trouble talking about the problems we were solving and how to use the product, how were we ever going to explain it to customers?

After a year, the service collapsed. Our major customers were so angry at us breaking all the time that they went on to use a different product which was much simpler with far less functionality or future technical vision. We cried out - but we have so much more everything - to which they said they don’t need it and they care more about availability and consistency. Ouch.

I asked my manager at the time - who had nearly resigned at this point - if you had to do anything differently, what would you have done?

“I would have fired that engineer.”

I was shocked; “Why?” I asked. Whenever there was an issue with the service, they were the only ones who knew how to fix it. Whenever there was a technical problem, there could be no better person to design, review, or approve it. We would be woefully technically lost without them I exclaimed.

After that talk it was clear to me - by enabling one person to define the entire service and neglect customers along the way - we had created a disastrous product. We should have empowered and lifted the team up along the way and built something everyone could be a part of rather than bottlenecking on an individual. And that person never saw it that way - they viewed everyone else as intellectually inferior and stepped on people all the time.

I never totally agreed with my boss’ regrets. There are so many potential creative outlets for people like this, but you have to be very careful with how you are building your team along the way. You cannot compare them to anyone else; they are in a unique class of their own. There are very few people like this in the world and it is extremely dangerous to start comparing them to others or expecting others to perform similarly.

Yet I understood my boss’ perspective. The engineer ignored customers’ requests and led the product astray with all of their technical vision and power. They internally destroyed the team over time and failed to empower anyone along the way. They never became a force multiplier and arguably turned into a fractional multiplier. Seeing the destruction of this product changed the way I see software development now. And it’s the reason why the best engineer I have ever met was also the worst.





Back to posts