How to be a -10x Engineer • Hacker News Board

Re: How to be a -10x Engineer

#141

Post by rvba » Tue, Apr 04, 2023, 1:51 PM UTC

dividedbyzero wrote: post #3

This reads a lot like one of those WW2 low-risk sabotage manuals.

This looks like the behavior of management in a company where I worked.

The business was relatively 'boring' - core product would move slowly. But management kept hiring bad people and losing talent. At some point the ship started to slow down.

Those smart people quit to competitors and even some launched their own company that is growing fast.

No bad employee was ever fired, their tasks were just allocated to the few good ones. Who started to quit en masse.

Re: How to be a -10x Engineer

#142

Post by quacked » Tue, Apr 04, 2023, 1:53 PM UTC

dividedbyzero wrote: post #114

flumpcakes wrote: post #60

Earlier quoted context omitted.

Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to rem…

I mean, first we really need to align on which Jira components to add to that ticket of yours, because we use them to reflect the products that benefit from the change and you should get in touch with the Automated Horse Warehousing PO whether changing the hue on the "Apply Now" button on the About Us page impacts their Siemens automation codebase. Also, you didn't fill out the seven big free text fields with the pro…

I see you worked for both of the past two companies I worked for as well.

Re: How to be a -10x Engineer

#143

Post by swiftcoder » Tue, Apr 04, 2023, 1:53 PM UTC

rlpb wrote: post #129

swiftcoder wrote: post #62

Earlier quoted context omitted.

There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.

Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work. Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small p…

That really depends how short your management chain thinks the intervals are

Re: How to be a -10x Engineer

#144

Post by d23 » Tue, Apr 04, 2023, 1:53 PM UTC

d--b wrote: post #21

A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.

Why do you believe the traits and behaviors outlined in the article are mutually exclusive with being a jerk? In my experience, most of the toxic people I've worked with were toxic because they exhibited a number of these traits and were thus ineffective and using toxicity to compensate.

Re: How to be a -10x Engineer

#145

Post by dmix » Tue, Apr 04, 2023, 1:55 PM UTC

steveBK123 wrote: post #119

flippinburgers wrote: post #48

Earlier quoted context omitted.

I think there is a balance but yeah it isn't good if no record of "where we are" exists.

Yes but I think people overestimate how automatable this actually is. Where we are context depends on if the audience is - * The next developer to pick up the task where you left off * Your technical lead asking for update * Your manager needing an update for his manager * Product management wanting to know where we are on some feature * End users wanting to know when the bug fix / feature they asked for will be in t…

Are your tickets even designed/written for consumption by product/management?

Re: How to be a -10x Engineer

#146

Post by d--b » Tue, Apr 04, 2023, 1:56 PM UTC

BoneZone wrote: post #43

d--b wrote: post #21

A lot of toxic negativity in that post. Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk. https://www.inc.com/jessica-stillman/studies-being-a-jerk-is... Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.

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

#147

Post by jerf » Tue, Apr 04, 2023, 1:57 PM UTC

camjohnson26 wrote: post #108

jerf wrote: post #79

Earlier quoted context omitted.

It is not the responsibility of a person pointing out problems to also solve them. Granted, pointing out problems is generally much easier than solving them, and correspondingly less valuable. As I like to say, stand up, spin around, and point at something randomly. You're pointing at a problem of some sort. But that still does not incur a responsibility to someone pointing out a problem to also solve it. It's a popu…

No but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama. If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place. The problem with the article is even though it’s right it makes no attempt to explain why, and blames bad people for the problems instead of understanding…

"No but it is their job to understand it,"

No, it isn't their job to understand the problem before pointing it out either. That also does not stand up to scrutiny in the slightest.

If I call my township to report a big pothole, I am not required to submit an explanation of how the pothole came to be. This is a ludicrous standard only deployed when situationally convenient for someone, not an actual principle.

Again, the value of a problem report without an understanding may be less than one that has it, but there is no obligation to have an understanding or present one in order to talk about a problem at all.

Re: How to be a -10x Engineer

#148

Post by svachalek » Tue, Apr 04, 2023, 1:57 PM UTC

safety1st wrote: post #97

flumpcakes wrote: post #40

> 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…

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

Re: How to be a -10x Engineer

#149

Post by jameshart » Tue, Apr 04, 2023, 1:58 PM UTC

steveBK123 wrote: post #111

flumpcakes wrote: post #60

Earlier quoted context omitted.

Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to rem…

Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top. This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, upda…

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. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

It doesn’t have to be Jira backlog grooming, sure. But it has to happen.

If the developers aren’t spending their time doing this, who is?

Re: How to be a -10x Engineer

#150

Post by commandlinefan » Tue, Apr 04, 2023, 1:59 PM UTC

> Decide that existing solutions aren’t quite what you need

But

> Add dependencies that demand 400 hours of maintenance.

These suggestions conflict with each other - if you're one of these "don't ever write code if somebody wrote something somewhat similar" types, you're also the one adding terabytes of dependencies that have varying levels of documentation and stop being supported at arbitrary points in the future.