Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to be a -10x Engineer

taylor.town

Post reply on HN
Print view View original

341–350 of 514 posts

Re: How to be a -10x Engineer

#341

Post by __MatrixMan__ »

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?

I don't think it's too cynical overall.

I can't recall the quote verbatim, but somewhere in "The Glass Bead Game" a great teacher says that it's difficult to work with intelligence--you have to be lucky to identify it and then the best you can do is get out of its way. Stupidity, on the other hand is easy to identify and easy to correct on a case-by-case basis.

There's value in inverting a problem like you've done in the article. It might not be symmetrical. Things that might not have been obvious in the original become obvious in the inversion.

Re: How to be a -10x Engineer

#342

Post by nico »

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…

Everyone is different. The key is not forcing people into your own worldview.

Some people do better with documentation or tickets or code or meetings.

The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.

Re: How to be a -10x Engineer

#343

Post by JohnFen »

roncesvalles wrote: post #267
strken wrote: post #69

Earlier quoted context omitted.

I suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high. Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and co…

The problem is when engineers make presentations instead of writing documentation. The best presentations are when an engineer has written a long page of documentation and walks through it, interspersed with Alt+Tabs to demos of the documented stuff in action. Too many dysfunctional teams have a culture where engineers make a 1 hour presentation at the end of a multi-week project, upload the ppt and recording somewhe…

Yes. Presentations are summaries. There needs to be real documentation that they're summarizing.

Re: How to be a -10x Engineer

#344

Post by afterburner »

CTmystery wrote: post #271

> To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible. I transitioned from startups (for 10 years) to a large company (for 5 years). Part of that move was adjusting from a culture of no lengthy documents to a culture full of lengthy documents, and I would never want to go back. Having explicit documentation in writing, where folks can debate the merit of ideas is so…

I guess you're lucky enough to be in a large company where the majority of people actually read and properly understand what has been written. I've had plenty of experience with supposedly senior people fundamentally misunderstanding core concepts of the technical work.

Re: How to be a -10x Engineer

#345

Post by denton-scratch »

danaris wrote: post #265
denton-scratch wrote: post #200

Earlier quoted context omitted.

> Common examples include presentations, diagrams, and ticket management. Ticket management is stuff that needs doing, obviously. Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful. Presentations (with slide-decks) are for managers[0], not engineer…

> if something is so complicated it can only be understood with a picture, it's too complicated Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism. For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent.…

> to the anti-intellectualism in our society today, or to a culture of elitism.

It wasn't meant to be an absolute, it is just a rule of thumb, and for me. I expressed it that way for rhetorical purposes.

I don't think retreating to real language is anti-intellectual; but you may be right that it's elitist to mistrust stories told in pictures. Anti-intellectuals mistrust stories told in words.

Re: How to be a -10x Engineer

#346

Post by strangattractor »

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…

The only 10X engineers I have ever worked with were the ones that helped get 2X out of the five normally 1X engineers they worked with.

Re: How to be a -10x Engineer

#347

Post by swiftcoder »

ryandrake wrote: post #282
yamtaddle wrote: post #258

Earlier quoted context omitted.

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…

> If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.

That's what one has sev/incident response procedures for. Put everyone in the entire management chain on a conference call with execs/comms/legal for as long as it takes - and make damn sure the line manager is shielding the actual engineers from this process so they have time to fix the bug.

Re: How to be a -10x Engineer

#348

Post by debatem1 »

Herval_freire wrote: post #321
safety1st wrote: post #97

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

>Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability. Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that m…

> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month.

You've really never met this person? Feels like more or less everyone with real expertise should be able to do this in the right job.

Re: How to be a -10x Engineer

#349

Post by ptx »

danaris wrote: post #265
denton-scratch wrote: post #200

Earlier quoted context omitted.

> Common examples include presentations, diagrams, and ticket management. Ticket management is stuff that needs doing, obviously. Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful. Presentations (with slide-decks) are for managers[0], not engineer…

> if something is so complicated it can only be understood with a picture, it's too complicated Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism. For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent.…

It seems like a good rule of thumb though. Here's a diagram of the 11 different tools you need to study to create an installer with WiX, which takes literally thousands of lines of XML: https://documentation.help/WiX-Toolset/tools.html

By contrast, WiX# provides a complete code sample that specifies a complete installer in less than 20 lines, with no diagram necessary: https://github.com/oleg-shilo/wixsharp

Re: How to be a -10x Engineer

#350

Post by sharemywin »

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…

You both are providing a wonderful example of: "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 wrote the originally criticized code. "
Post reply on HN