Earlier quoted context omitted.
Step 16 skip step 16. step 17 Recognize that questioning the status quo is a critical part of progress and growth, and that "toxic negativity" is often a label applied to dissenting voices to silence them. step 18 Acknowledge that engineering, like any other field, can benefit from improvements in productivity and efficiency. step 19 However, also acknowledge that a singular focus on productivity can lead to shortcut…
Ah, step 42. Well done. I was wondering why all these steps were generally GOOD things to do instead of the BAD things that all the previous steps were (1-15). And I was wondering why they all sounded the same.
How to be a -10x Engineer
301–310 of 514 posts
Re: How to be a -10x Engineer
#302Earlier 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…
These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).
There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)
Re: How to be a -10x Engineer
#303Earlier quoted context omitted.
I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Bu…
> How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all. If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interle…
But in companies that are good at engineering management, you will often find:
- weekly planning sessions
- daily standups
- work ticketing and backlog systems (sometimes Atlassian ones!)
- prioritization discussions
So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy.
P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.
Re: How to be a -10x Engineer
#304A friend of mine accidentally wiped out over 100k hours of other researcher's computing operations the other day, does that make him a -100,000x engineer?
If that data would be wiped by a fire instead, would you call that fire a -100,000x a engineer? Accidents happen, the fault lies on whoever did not backup the data.
Re: How to be a -10x Engineer
#305Re: How to be a -10x Engineer
#306Earlier 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.
You should not rewrite something that works, only when you need to make larger changes, even if the guy who wrote the program is still there you might want to rewrite from scratch if the requirements change, like you now need to handle 100x more traffic and need to have something with better performance, or scaled out.
Re: How to be a -10x Engineer
#307Earlier quoted context omitted.
I disagree. For me this outlines the caveats and pitfalls of software development and management. There is real truth to some of the authors points showing real paths that emerge naturally. If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...
Am I saying that anyone who is critical is an asshole? Where? Seriously? I find that the article hides a deep aggressivity towards overall mediocrity behind a thin veil of office-space-like humour. And I think that aggressivity is contagious and so not a good thing to spread.
Re: How to be a -10x Engineer
#308Re: How to be a -10x Engineer
#309Re: How to be a -10x Engineer
#310> 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…