Live data from Hacker News

How to be a -10x Engineer

taylor.town

441–450 of 514 posts

Re: How to be a -10x Engineer

#441

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

These examples imo are often sources of added fluff to process. The goal of the presentation is to get the point across. Unfortunately, I see too many people make these terrible powerpoints, where its clear they spent too much time making the template sexy and not enough time considering what content the content is. My favorite powerpoints are the ones where people use the default white background and text, and just put up a single figure per slide and describe them versus talking off bullet points with a bunch of junk imagery. If I am reading a sentence on your slide, I am incapable of listening what is coming out of your mouth at the same time. Basically, the slide deck should only take you as much time to make as pasting your figures over to it.

Re: How to be a -10x Engineer

#442
I'm nodding along to this list because I've been consulting with a large government department that has dozens of programmers with the effective output of maybe... two? Three at the most.

They tick just about every item on that list. Staggering inefficiencies everywhere, duplicated work, duplicated codebases, etc, etc...

The worst thing about these problems is that they compound, often exponentially or at least quadratically. Slow builds mean bug fixes take longer. Longer bug fix times means they can't all be fixed to meet deadlines. That means that they now have to be prioritised, which incurs management overheads and shuffling things around in spreadsheets. This then delays things further, which means even critical requirements (security!) get dropped on the floor.

The inevitable consequence is that things are constantly breaking in production, and everyone spends half their time fighting fires. Fires that were marked as a "low-priority" smell of smoke six months ago.

Productive staff see the writing on the wall, quit, leaving only the unproductive staff that "couldn't get a job elsewhere".

The snowball builds rapidly from here into an avalanche of badness.

Re: How to be a -10x Engineer

#443
"Introduce subtle randomness into your tests so that they succeed/fail without cause."

That reminds me I have one of these in the wild. Hope to resolve it one day...

Re: How to be a -10x Engineer

#444

Earlier quoted context omitted.

Engineer who implements correct, comprehensible code but doesn't manage ticket statuses is more valuable than one who manages ticket statuses but scatters the codebase with technical debt and confusing abstractions/code. If "better communication" means spending an extra 10 hours with the latter dev to correct/re-teach them, then yes, communication is the problem. The most time I've lost at work is correcting/teaching…

I don't really think the first part of your comment is true, at least not in my experience. All other stakeholders would prefer someone that updates their tickets and communicates what they are doing effectively, even if they produce absolute garbage, bug ridden software. I've personally only ever seen someone removed from a team for having poor technical skills once and it was under pretty extreme circumstances. Whi…

Without going into anything identifying, what exactly were those circumstances? I'm imagining something like this happening, but at the same time I can't help but think if its a technical skill issue, handing them a book on the relevant technology and telling them studying this book is their job for the next two weeks would be better than trying to roll the dice again, put out a new job ad, interview, vet, rehire, and hope they aren't somehow just as technically incompetent as the original engineer.

Re: How to be a -10x Engineer

#445

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

> Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable

The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers.

As in the following style:

    class D {
        public A foo(B b, C c ) {
            D d = b.x( c );
            return new A(d.f(1));
        }
    }

Now imagine this for several hundred thousand lines. Zero comments. Massive functions.

You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch.

He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.

Re: How to be a -10x Engineer

#446

Earlier quoted context omitted.

> Ticket management is not busy work, it's a necessity for everyone to keep updated. Yes and no. If I oversimplify one of the important Lean points, you can divide activity into 3 buckets: 1) value-creating, 2) necessary waste, 3) pure waste. It's important here that "value" is always measured from the customer perspective. For example, imagine a hamburger joint. You have ordered a cheeseburger. The person at the gri…

If the ticket is a direct conduit to the customer, I think you could argue that ticket management in the form of asking clarifying questions so that you build the right thing (or fix the right bug) is creating value?

People argue all sorts of things here. People argue that building large specs so as to get approval of the grand poobahs to fund the project to build the thing is creating value. But the easy rule of thumb is "If you do more X, does a customer receive more value?"

Another way to look at it: If I put the customer at the bottom of a well and the only way to communicate is by cranking notes up and down in a bucket, does turning the crank constitute a value increase? Mainly I think it's focusing on the wrong thing. Why is the customer in the well? Maybe we should let them out. Maybe if we have a question about how they work or what's good for them, we should visit them and study them as they work and then maybe ask them a question or two. And then, most importantly, ship something and see if it really does make things better.

So no, even in that narrow and unfortunate case, that is not creating value. It is at best necessary waste. Building the thing and giving to them, if it turns out to be valuable, is creating value (probably with some waste mixed in). The fact that communication is through a constrained and stilted channel is just a sign there's pure waste in the necessary waste that we can try to remove.

Re: How to be a -10x Engineer

#447
I had some of my code handed over to a subcontractor once. My boss found a design issue in code review that caused me some initial blowback but I pulled out commit logs and the correct code I wrote had been changed on purpose to be "less naive" by someone at the sub. They broke the code in precisely the way my implementation was meant to guard against. They went out of business soon after that incident.

Re: How to be a -10x Engineer

#448

> 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, these things are all part of being a team of 1x engineers rather than a team of .5x engineers. If you have a single 10x (and I've worked with some) then it's not important but those guys have their own issues.

Re: How to be a -10x Engineer

#449
Some curious and easily distractible engineers have trouble making progress, but generally don’t cause harm. They basically work sideways to the direction of best effect.

However if there are two of them, their product is negative.

Or perhaps I am perceiving a dysfunctional pattern that really isn’t there.

Yet, even if they are imaginary, their impact is real.

Re: How to be a -10x Engineer

#450
As a platform team leader that caters to other engineers within the organisation, extensive documentation is what enabled me and my team to be productive.

I answer almost all questions posed to me with a simple have you read this (confluence link )

Post reply on HN