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

Re: How to be a -10x Engineer

#281

Post by justin_oaks » Tue, Apr 04, 2023, 4:26 PM UTC

lispisok wrote: post #270

sigh . The 10x engineer has become tech's most toxic concepts and devs are its victims, yet we keep bringing it up constantly. Every time it's brought up it's a new variation that's either bad or good but always different than the original proposal of the BEST programmers are 10x more productive than the WORST developers from a paper in 1968. All that is come of it is devs arguing about a hypothetical programmer is a…

To be fair, you're the one bringing up the 10x engineer. The article only mentions it for the sake of contrasting it with -10x engineers: "+10x engineers may be mythical, but -10x engineers exist." And that's all that was said about it.

I agree that arguments for and against are tiring, so let's talk about the article instead!

I've definitely seen engineers who have been net negative in productivity. They've distracted me from my work, introduced bugs that have had severe effects on the production environment, and have produced code that had to be thrown away and completely rewritten.

Luckily, the items in the article aren't commonly seen all in one person, but they are great ways to lose productivity and negatively affect others in the company.

Re: How to be a -10x Engineer

#282

Post by ryandrake » Tue, Apr 04, 2023, 4:27 PM UTC

yamtaddle wrote: post #258

rlpb wrote: post #129

Earlier quoted context omitted.

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…

If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-t…

From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem.

Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!

Re: How to be a -10x Engineer

#283

Post by taink » Tue, Apr 04, 2023, 4:30 PM UTC

Don't forget your basic organization sabotage field manual: https://archive.org/details/SimpleSabotageFieldManualStrateg...

Re: How to be a -10x Engineer

#284

Post by NikolaNovak » Tue, Apr 04, 2023, 4:31 PM UTC

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…

FWIW :)

I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes.

Then one day when going over same slide for the 5th time with my boss and mentor, I realized:

* This slide will be seen by a person in power

* they will make a decision based upon that slide

* I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever

* But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision

* A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides

* therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision

As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-)

Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing.

Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!

Re: How to be a -10x Engineer

#285

Post by justin_oaks » Tue, Apr 04, 2023, 4:32 PM UTC

psychoslave wrote: post #241

ilyt wrote: post #171

Earlier quoted context omitted.

Step 15: Make absolutely sure your team and any prospective hire knows you will hire to fill quota vs get them the most competent co-workers, ensuring mediocrity.

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.

Re: How to be a -10x Engineer

#286

Post by austin-cheney » Tue, Apr 04, 2023, 4:33 PM UTC

vbezhenar wrote: post #252

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…

I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start. A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

Uugggghhh… “maintainable way” is again super subjective. Normally when people say that what they really mean is in a way that fits a pattern familiar to them.

If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastically over spend on finding and retaining developers that aren’t qualified to be there in the first place when really in most cases it’s just about trying to put text on a screen. These companies would save so much money finding people off the street, evaluating them against minimally required intelligence and just training them to read and write code in house.

Re: How to be a -10x Engineer

#287

Post by justin_oaks » Tue, Apr 04, 2023, 4:41 PM UTC

surprisetalk wrote: post #34

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.

Author here. I don't want to empower jerks. Anything particular I should change? Or is the structure of the essay too cynical overall?

The only thing you should change is your expectations.

No matter what is written, someone will find something wrong with it. Expect those people to show up and sometimes be very loud.

I appreciate your efforts to receive feedback. In this case, you'll find the majority of people aren't complaining, just a few are. So be happy that you wrote something that so many engage with!

The only thing worse than writing something that people are critical of is writing something that's completely ignored.

Re: How to be a -10x Engineer

#288

Post by jay_kyburz » Tue, Apr 04, 2023, 4:43 PM UTC

whateveracct wrote: post #266

vbezhenar wrote: post #252

Earlier quoted context omitted.

I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start. A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out. As I said, the team was fully functional, in production, low bug rate, generally happy. Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have l…

Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer.

I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

Re: How to be a -10x Engineer

#289

Post by Jolter » Tue, Apr 04, 2023, 4:43 PM UTC

lifeisstillgood wrote: post #49

>>> inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. Welcome all opinions and aim for engagement. Mostly spot on but I am not sure of this one - well written notes / emails about technical issues and some of the trade offs or desired outcomes are really useful - they actually help "align" people. Think more "Linus rant" than "CEO powerpoint" but the idea is there

Sharing those too widely is hugely counterproductive though. It will engage people who have no business with it. It’s what Yammer does to an organization — introduces all the disadvantages of Twitter with few of the benefits.

Re: How to be a -10x Engineer

#290

Post by aetherson » Tue, Apr 04, 2023, 4:44 PM UTC

z3t4 wrote: post #254

pl90087 wrote: post #174

Earlier quoted context omitted.

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…

The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any…

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