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

Re: How to be a -10x Engineer

#231

Post by time0ut » Tue, Apr 04, 2023, 3:05 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.

I read the post, saw this comment, then re-read it again. I did not get the impression that author was trying to be negative. I think they were just trying to write in an "edgy" style. I've seen most of the things on the list happen (at least to a degree).

On the topic of contagious jerks, my experience has been that these people often suck at engineering.

For example, a few years ago, one of the product managers was super excited to recruit an engineer they had worked with before. The engineer was talked up. A real genius. Someone who would come in and do things right. He would lead a new sibling team working on a new product. I was excited. We could use the help as we were going through hyper-growth.

The engineer seemed smart, but had a very sarcastic and negative attitude. The existing architecture was garbage. Everyone's code was terrible. Even the choice of language was wrong. While he was respectful towards me and the work I had done, I saw him put down most of the people around him. I kept my distance and let him do his thing. It wasn't my place in the organization to interfere anyway.

The end result was he drove half his team to quit, delivered an absolute disaster of a system, and then left.

I've seen versions of this play out a few times. My experience has been that the smartest people are often the nicest because they are smart enough to recognize the value in lifting everyone. I know its not always the case and I have worked with difficult people who genuinely were incredible engineers as well, but they tend not to actively put everyone around them down.

Re: How to be a -10x Engineer

#232

Post by whateveracct » Tue, Apr 04, 2023, 3:10 PM UTC

Starlord2048 wrote: post #208

whateveracct wrote: post #179

Earlier quoted context omitted.

Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies. I've come to think it's the biggest existential risk t…

It seems as though the main issue here is not with FP itself, but with the politics and power dynamics within organizations.

Oh definitely, but sadly I think the culture and people involved in FP tend to be susceptible to politics. But I am in no way _blaming_ that or acting like FP should change. Those same cultures, values, and people are what make the various FP languages and communities out there great.

Re: How to be a -10x Engineer

#233

Post by robertlagrant » Tue, Apr 04, 2023, 3:10 PM UTC

watwut wrote: post #222

robertlagrant wrote: post #92

Earlier quoted context omitted.

> You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker? Calling "deciding on how to spend your time" a waste of time seems a misnomer.

But ... that person is not deciding how he will spend time. He is deciding which labels to put on ticket. What he will do is not directly related to that.

What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.

Re: How to be a -10x Engineer

#234

Post by Balgair » Tue, Apr 04, 2023, 3:13 PM UTC

Xeoncross wrote: post #172

senko wrote: post #166

Good list. Should be called "How to be a -10x Manager" though, since the majority of the bad decisions listed there are under the manager's purview. Reminds me of the CIA sabotage field manual: https://www.hsdl.org/c/abstract/?docid=750070 On another note, many of the items there are "create pointless X". It's actually a thin line between "important X" and "pointless X" and many people will disagree where it actually…

I've been surprised how many -10x Engineers exist, they have almost always moved into management.

The Gervais Principle in action

Re: How to be a -10x Engineer

#235

Post by [deleted] » Tue, Apr 04, 2023, 3:14 PM UTC

jameshart wrote: post #149

steveBK123 wrote: post #111

Earlier quoted context omitted.

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

[deleted]

Re: How to be a -10x Engineer

#236

Post by JohnMakin » Tue, Apr 04, 2023, 3:15 PM UTC

shagie wrote: post #191

svachalek wrote: post #148

Earlier quoted context omitted.

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

From a bit ago: We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 30 comments) > “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.” > And so our resident…

Thanks for reposting this. Sounds so eerily similar to my last principal that I wonder if it's the same guy, although I'm sure this is a common phenomenon.

Re: How to be a -10x Engineer

#237

Post by robertlagrant » Tue, Apr 04, 2023, 3:16 PM UTC

mnd999 wrote: post #153

robertlagrant wrote: post #90

Earlier quoted context omitted.

If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.

It depends. Maybe the 1 min fix is to add a missing test case for something that already works. Spending 20 mins creating a templated Jira for that is a waste of time imho, but it depends on what you do. In some places that have externally audited traceability requirements that would be necessary.

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.

Re: How to be a -10x Engineer

#238

Post by CM30 » Tue, Apr 04, 2023, 3:16 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.

What's more, the contagiousness aspect isn't the only issue here. Jerks tend to cause problems for organisations for other reasons too. Such as:

1. They scare away a lot of competent workers, since many smart and talented employees won't want to be stuck working alongside an asshole, regardless of how 'talented' they might be. And given that the best employees tend to have a plethora of options for where to work, and well... you can guess how that affects the talent remaining.

2. They discourage newer and less experienced employees from learning/improving, and instead encourage them to leave. But folks who aren't necessarily the most talented developers now can very much turn into such with the right environment and incentives, which these types of people don't provide.

There really aren't any benefits to keeping around jerks, and a whole lot more downsides than people think.

Re: How to be a -10x Engineer

#239

Post by atoav » Tue, Apr 04, 2023, 3:16 PM UTC

I think as engineers we have to realize a few things:

1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.

2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.

3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.

Re: How to be a -10x Engineer

#240

Post by gjadi » Tue, Apr 04, 2023, 3:17 PM UTC

mgkimsal wrote: post #188

robertlagrant wrote: post #81

Earlier quoted context omitted.

> I suspect that the presentations and diagrams which need to be made, are made. I don't think that's true. E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes. Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"

The whole "yeah, just have a conversation" thing bugs me a lot. I like talking, and having conversations. It's rarely enough. The information needs to be written down (or codified in tests or whatever). Future people won't have the luxury of a conversation with whoever originally wrote something. Conversations aren't indexable. Conversations lose nuance, memories fade or get jumbled. Have your conversation, then docu…

And it's like talking about code and coding. Once you start writing you find all^W a lot of assumptions/hypotheses you made implicitly or even flaws in your reasoning.

Writing is nature's way of letting you know how sloppy your thinking is.