Writes code that others can read.
Reads the Docs.
Updates the Docs.
- Writes docs littered with misused buzzwords (especially "leverage" and "platform") that are at best useless, and more often actively misleading.
- When not sure what to do, muddles through with the first nightmarish idea to come to mind, rather than taking a step back and trying to simplify or seeking prior art. No aesthetic sensibility, no innate revulsion to garbage code.
- Has no sense of how long things should take, and no problem spinning for 3 weeks on a half-day task they're delegated.
- Approves train-wreck pull requests.
- Executes every CR suggestion, even those that make things worse.
- Attempts a bad deploy 3 or 4 times before wondering why they are hitting the auto-rollback trigger; assumes something is wrong with the deployment system.
- After 30 seconds of shallow thought, writes off any production issue they're asked to debug (including emergency pages) as "must be network" or "must be database" and fires off a vague bug report to sit in somebody's queue for 6 months before being closed for insufficient detail while the fire continues to burn.
- Gracefully acknowledges design feedback, but goes with their original plan anyways. Or more likely, built the thing weeks before soliciting design approval and won't go back to change it.
- Very interested in getting promoted; not at all interested in technical depth, novelty, or quality.
> 10x engineers laptop screen background color is typically black (they always change defaults).
Now if we could try to hire this person in a startup, how much compensation should we give them to stop going else where?
More than your first seed round. /s
We got over measuring lines of code a long time ago. We should measure impact on the people around you and the culture you create.
This list looks a lot like 10x stuff to me.
How many units does an average engineer ... emit? I presume a 10x engineer will emit 10 times those units?
Yay, we can all go home now.
"magically" make the right architectural decisions, such that the project doesn't need a rewrite, when new requirements "appear".
use time effectively.
retain details about work around, land-mines, technical+functional/biz+ops requirements, frameworks in-use,
picks up new tech if required, removes tech if required...
talks to the right people to talk to about the right topics
try to stay out of politics but not disregard it...