How to be a -10x Engineer

[aum]

 +10x engineers may be mythical, but -10x engineers exist.

 

To become a -10x engineer, simply waste 400 engineering hours per week. Combine the following strategies:

 

Nullify the output of 10 engineers.

Change requirements as far into development as possible. To avoid blame, obfuscate requirements from the start.

Create 400 hours of busywork.

Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. Create pointless rituals.

Create 400 hours of burnout/turnover.

Be thankless. Foist blame. Sow confusion. Get angry. Cause others to work overtime.

Hold 10 engineers hostage in a technical discussion.

Let engineers discuss ideas. Encourage them to pursue elegance over pragmatism. Ensure nobody has the authority to make any decisions.

Add 400 hours of communication overhead.

Meetings wreck calendars. To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement.

Waste 10 weeks of wages on cloud costs.

Write slow programs. Avoid DB indexes. Run single-threaded programs on 16-core machines. Opt for exotic hardware with fancy RAM and GPUs. Store data on RAM/disk liberally. Don’t compress anything. Pay no attention to data layouts.

Create useless tools.

Decide that existing solutions aren’t quite what you need. Write scripts that only one person understands. If the script does something important, avoid documentation.

Add 400 hours of compilation/build time.

Slow builds waste time and incur compound interest. As build times increase, developers are more likely to distract themselves. To ensure developers are context-switching, recompilation should take at least 20 seconds. You can also write slow tests for similar effect.

Write pointless tests.

Create dependencies on particular variables without testing the underlying functionality. Mock function calls until no original code runs. Introduce subtle randomness into your tests so that they succeed/fail without cause.

Waste 400 hours of engineering on bad architecture.

Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses.

Waste 400 hours on deployment.

Create as many environments as possible. Production and staging must differ wildly. Launch fragile code with fragile build systems. Migrate your databases frequently.

Lose 10 weeks of wages on unhappy customers.

Repeatedly fail to detect and address severe bugs. Pay no attention to security vulnerabilities.

Write worthless documentation.

Explain code in private messages. Write wikis that nobody uses.

Trap 10 engineers in a futile skunkworks project.

Attract bright engineers and waste their potential. Undersell the difficulty of the project to management; oversell the project’s usefulness. Tell management it’s “almost complete” until they scrap it.

Add dependencies that demand 400 hours of maintenance.

Engineers individually learn each library.

Delay pivoting.

Never admit failure. Drown your team in sunk-cost. Ignore 80/20 compromises that could improve your circumstances.

Hire 10 0x engineers.

Opportunity costs can kill. Dead-weights may not actively harm your team, but they sit in the chairs of people who could actively help.

Hire 5 -1x engineeers.

Don’t settle for dead-weight. Actively hire engineers who cause catastrophies and resist learning.

Prevent 10 -1x engineers from getting fired.

Don’t rock boats. Leave no paper trail of failures. Vouch for bad engineering.

Incur 400 hours of bug triage.

Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible.

 

Source