# How to be a -10x Engineer

+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.