Who is the 1x engineer that all of these 10x, 100x, 1000x, -10x things are based off of?
Wait for the piece, somebody is probably writing that
How to be a -10x Engineer
381–390 of 514 posts
Re: How to be a -10x Engineer
#382Earlier quoted context omitted.
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…
And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wr…
I get what you're saying, but I don't good definitions are the problem.
Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over.
What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.
Re: How to be a -10x Engineer
#383Wait, was this NOT a belated April Fool's joke?
Re: How to be a -10x Engineer
#384Who is the 1x engineer that all of these 10x, 100x, 1000x, -10x things are based off of?
Some options:
1. (Sum of total output) / (Count of engineers)
2. CS grad with a "B" GPA, 3 years experience, 1 year on the team
3. 50th percentile of all engineers
4. <- Me (or whoever the reader is)
Re: How to be a -10x Engineer
#385Earlier quoted context omitted.
> "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it?" Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
"If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein* *I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.
Pretty sure that one is from Feynman.
Re: How to be a -10x Engineer
#386> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…
So is someone who can grok and refactor an inscrutable codebase a +10x engineer (since they fixed a -10x engineer's work) or ... something else?
Re: How to be a -10x Engineer
#387> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
Engineer who implements correct, comprehensible code but doesn't manage ticket statuses is more valuable than one who manages ticket statuses but scatters the codebase with technical debt and confusing abstractions/code. If "better communication" means spending an extra 10 hours with the latter dev to correct/re-teach them, then yes, communication is the problem. The most time I've lost at work is correcting/teaching engineers who eventually got let go due to low performance.
Re: How to be a -10x Engineer
#388Earlier quoted context omitted.
Yes, I agree with that. I'd say that changes to the running codebase would need (slightly) more formality than changes to the test codebase, but yes, if tests are a feature e.g. because they feed into regulatory output, then they should also be ticketed. I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.
2 minutes? That's barely enough time to load the Jira ticket creation page...
Hah! Hit create and the popup opens. Unless you have a load of plugins installed, in which case tell your IT department off.
Re: How to be a -10x Engineer
#389> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
1000%. A lot of this stuff seems like busy work to junior engineers and bad senior/staff engineers. But this is how you spend a few days to save months of wasted effort.
Re: How to be a -10x Engineer
#390Earlier quoted context omitted.
"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.
"Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct. Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths: 1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me. 2) If I embark on…
I've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable.
While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.