How to become a 10x engineer

Short description

The concept of +10x engineers may be a myth, but -10x engineers do exist, and there are strategies to becoming one. These include wasting 400 development hours per week, resetting the work output of ten engineers, asking for unnecessary tasks, creating burnout/turnover, being ungrateful, instilling guilt and confusion, brainstorming ideas without making decisions, holding engineers hostage, wasting time on slow programs, adding extra communications, writing useless tools with no documentation, and implementing bad architecture and deployment strategies. The article also suggests hiring -1x engineers and preventing their dismissal, while delaying course changes and bug fixing.

How to become a 10x engineer

+10x engineers may be a myth, but -10x engineers do exist.

To become a -10x engineer, just waste 400 development hours per week. Combine this with the following strategies:

Reset the work output of ten engineers

Change requirements in the development process as long as possible. To avoid accusations, justify the demands from the beginning.

Cue 400 hours of hustle

Ask your team to complete tasks that


work For example, create presentations, charts and manage tickets. Create silly rituals.

Organize 400 hours of burnout/turnover

Be ungrateful. Instill guilt. Sow confusion. Be angry Get people to recycle.

Hold ten engineers hostage in a technical negotiation

Let the engineers brainstorm ideas. Encourage them to pursue sophistication at the expense of pragmatism. Make it so that no one has the power to make decisions.

Add 400 hours of extra communications

Meetings ruin calendars. To subtly waste other people’s time, write long messages/documents and send them out as much as possible. Welcome all thoughts and seek engagement.

Lose ten weeks’ wages on cloud services

Write slow programs. Avoid database indexes. Run single-threaded applications on 16-core machines. Choose exotic hardware with unusual RAM and GPU. Store data arbitrarily in RAM/disk. Do not squeeze anything. Don’t pay attention to the data structure.

Create useless tools

Decide that solutions are ready

not at all

suit you Write scripts that will be understood by only one person. If the script does something important, don’t create documentation.

Add 400 hours of compilation/assembly

Slow assemblies waste time and cause associated costs. As build time increases, developers are more likely to distract themselves from work. To ensure developer context switching, make the recompilation take at least 20 seconds. To achieve a similar result, you can write slow tests.

Write silly tests

Create dependencies on specific variables without testing internal functionality. Mock functions until there is no original code left. Add a little randomness to the tests, so that the success of their passing does not depend on any reasons.

Waste 400 development hours on bad architecture

Don’t put any effort into analyzing how the system structure will evolve over time. Or make your team obsessed with architectural solutions and have no time for hypothesis testing.

Waste 400 hours on deployment

Create as many environments as possible. Production and staging must be significantly different. Deploy unstable code using unstable build systems. Migrate databases frequently.

Lose ten weeks’ wages on unhappy customers

Do not repeatedly detect and fix serious bugs. Ignore security vulnerabilities.

Write useless documentation

Explain the personal message code. Write a wiki that no one uses.

Trap ten engineers in a silly experimental project.

Attract talented engineers and waste their potential. Underestimate the complexity of the project in the management’s own eyes; exaggerate its usefulness. Promise management that it’s “almost ready” until it’s folded.

Add dependencies requiring 400 support hours

Engineers study each library separately.

Delay changing course

Never admit failure. Drown your team in sunk costs. Ignore the 80/20 compromises that would make things better.

Hire ten 0x engineers

Lost profit can kill. Dead weight not only actively hurts the team, but also takes the places of people who could actively help.

Hire five -1x engineers

Don’t settle for dead weight. Actively hire engineers who cause disasters and refuse to learn.

Prevent the dismissal of a dozen -1x engineers

Don’t rock the boat. Don’t leave a paper trail of failure. Vote for bad development.

Add 400 hours of bug fixing

Write programs that cannot be debugged. Apply many layers of abstractions to everything. Write spaghetti code. Make everything sensitive to the initial conditions. Avoid pure functions. Feel free to use the dependency. When possible, say: “It works on my car.”

Related posts