Thoughts on -10x Engineer

Today I read an interesting blog post titled 'How to be a -10x Engineer' written by Taylor. Its discussion in hacker news was boring and cliched at the same time. Everyone has seen this mythical -10x engineer in their career, but none of them commented whether they've shown any of these traits. For me, that blog looked like a perfect checklist to do some self-review. Please read the original blog first.

Nullify the output of 10 engineers.

I've done this a couple of times(?), but not intentional. At the time of requirement creation and review I didn't consider the potential road-blocks and some corner cases. This was identified only at the time of development and was difficult to manage.

Create 400 hours of busywork.

I've always been vocal about reducing the number of meetings. But I've to admit that I've dragged a project early in my career. It was a strategic decision that was advised by my then-supervisor at the expense of the client. We were ahead of our schedule in the current project and that might cause a gap before the scheduled start of the next project.

Create 400 hours of burnout/turnover.

Fortunately, I've worked with great colleagues throughout my career. But things went out of my control once. There was this developer who wasn't committed to the project and spent most of the time on loose talks. He/She delaying project tasks was a recurring theme and it resulted in a heated 1:1 closed room discussion. Soon after I escalated this to my supervisor and he/she was relieved from the project. That incident was an eye-opener for me regarding the hiring. He/She was rejected after the interview, but our supervisor forced us to hire that person as we were on a tight deadline.

Hold 10 engineers hostage in a technical discussion.

I have kick-started a few of these kinds of meetings. When I get an idea that the members won't reach a consensus, I'll reschedule the meeting with some higher-ups. This has worked for me so far.

Add 400 hours of communication overhead.

I used to loop a lot of people in the emails because I wanted to keep everyone informed. But soon I understood the drawbacks, when you sent a mail to a distribution list (DL) nobody replies. Everyone will think that someone in the DL will reply. Nowadays, I make use of @mentions in Outlook to address a particular person from whom I'm expecting a reply. Also now I sent emails with bullet points instead of paragraphs to ease the reading.

Waste 10 weeks of wages on cloud costs.

I follow the "Make it work, Make it right, Make it fast" philosophy, so most of the time my first iteration won't be that perfect. But we've quality checks in place to measure and validate the performance and other non-functional requirements.

Create useless tools.

As a lazy person, I seldom use custom tools.

Add 400 hours of compilation/build time.

I always strive to use the most optimized and fast tooling for builds and integration. But there are some build steps that the organization enforces like SonarQube which we can't avoid. These tools increase build time, but they are very helpful.

Write pointless tests.

I've written pointless tests to pass the code coverage quality checks. One thing I learned in my career is that if we are planning to test our code, we should write code in such a way that will ease the testing process like provision to mock dependencies, etc. Adding unit tests to the already developed code base is a bit difficult.

Waste 400 hours on deployment.

I've not spent much time on the ops side, maximum environments I've worked are DEV, SIT, UAT, and PROD plus some sandboxes.

Lose 10 weeks of wages on unhappy customers.

It's always Prod/Customer issues over features for me.

Write worthless documentation.

I haven't written any worthless documentation, but I used to write minimal documentation. Nowadays I maintain a wiki and ADR for my project in addition to a well-documented code.

Trap 10 engineers in a futile skunkworks project.

Many times I got the opportunity to bootstrap a team to explore some innovative technologies, the latest being Metaverse. Since most of the time I was busy with my routine work, I never took it. I am glad that I saved a lot of my time and someone else's.

Add dependencies that demand 400 hours of maintenance.

I don't remember creating a dependency of this stature. I once used d3.js to create an organization chart in PowerBI widget. I had to do it because that widget wasn't available in PowerBI at that time (2018). It was up and running till I left the organization in late 2019 without any change after its initial release.

Delay pivoting.

I haven't worked in any startups, but I left my second organization because the product we were working on was failing. It was supposed to be used by internal users first before marketing it to other organizations. After one year into the project, I found that not even 10% of our internal users are using our product. I discussed this with my skip-level manager, and he assured me about the future but I wasn't convinced. The project was scrapped in six months after my departure.

Hire 10 0x engineers / Hire 5 -1x engineeers..

I did it once and burned my fingers. I'm not a fool to repeat it.

Prevent 10 -1x engineers from getting fired.

I haven't done this so far.

Incur 400 hours of bug triage.

My coding quality and standards gradually improved over time. To know my current level, please check my latest Github repos.