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

371–380 of 514 posts

Re: How to be a -10x Engineer

#371

Post by steveBK123 »

ResearchCode wrote: post #367
crazygringo wrote: post #212

Earlier quoted context omitted.

> Putting the whole team in a room every week is just going to churn the plan constantly Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change. > inputs likely aren't changing with that frequency In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are l…

I don't think that's the case for most of the substantial software projects. The plan for the Linux kernel doesn't change each week (do they have "PMs"?). 15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%. Do as much of the planning as possible without a meeting.

Exactly. A real product driven company with a mature product isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.

How do people think Apple develops completely new product lines like the iPhone, iPad, watch, etc.

There's a lot more up front planning (and yes .. of course, course corrections) than a lot of agile advocates want to admit.

Most agile hyped up senior management I've met just use it as an excuse to be derelict in their ability to plan anything.

Re: How to be a -10x Engineer

#372

Post by edgyquant »

perceptronas wrote: post #138
mkl95 wrote: post #74

> Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible. A lot of legacy software is like this. I wonder how many billions it costs the economy per year.

Its extremely hard to argue for debuggability. I always try to prioritize how easy is it to test the said feature and understand it. However, during reviews of other engineers PR, I am always met with criticism that there is no need. "Instead of localhost, this can be tested on staging" and etc.

>Instead of localhost, this can be tested on stagin

No, it must pass a preview before being merged into staging

Re: How to be a -10x Engineer

#373

Post by wpietri »

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…

> 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 grill cooks a patty for you, puts some cheese on it, and assembles a burger. Then somebody else walks that burger to you. Except they get distracted after they've picked it up, so they end up walking to the back before coming up to give it to you.

Making the burger is value creating. You wouldn't want a raw patty, and you want it put together right. Walking the burger to you is necessary waste, in that moving the burger does not increase its value, but we have to do it to deliver value. The little stroll to the back is unnecessary waste in that you could receive the same value without it. Make sense?

With that framework, let's think about software. Ticket management is not a value-creating activity. If I do an extra hour of ticket management, that does not guarantee increased value. At best, it's necessary waste: I just can't figure out how to get you what you want without N hours of ticket management. But quite often it's unnecessary waste, labor performed for some purpose other than customer value. For example, a lot of planning activity is about making high-status people feel important. Or part of somebody's ongoing battle for increased status. Or the downstream consequence of previous unaddressed failures causing distrust.

So can ticket management be necessary waste? Sure. But it's often pure waste. I've done whole companies with no more ticket management than you get out of a bunch of index cards on the wall. [1] And we got there by relentlessly cutting the waste of heavier processes, something that a lot of companies won't even think about, much less attempt, because there productivity is relatively unimportant.

[1] e.g.: https://williampietri.com/writing/2015/the-big-board/

Re: How to be a -10x Engineer

#374

Post by lelanthran »

debatem1 wrote: post #348
Herval_freire wrote: post #321

Earlier quoted context omitted.

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

> You've really never met this person?

Nope. I've never met anyone who can complete in a month what it takes an average coder a year to complete.

Neither have you.

Re: How to be a -10x Engineer

#376

Post by ResearchCode »

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…

Do Linux kernel developers do that?

Re: How to be a -10x Engineer

#377

Post by nrclark »

rzzzt wrote: post #334
nrclark wrote: post #325

Earlier quoted context omitted.

a 10x engineer might not exist. A -10x engineer (or more accurately: a 1/10x engineer) definitely does. This article isn't about engineers that make your team better; it's about engineers that make your team worse.

The distinction is important: someone else already wrote that the -10× person will move you further away from the goalpost, while the 10⁻¹× counterpart is still moving towards it, only slower.

That's a good point. If your team has an 0.1x engineer, you'll still get to your goal eventually. If you have a -1x engineer, you might be going in the wrong direction to ever finish your project.

Re: How to be a -10x Engineer

#378

Post by nerdponx »

watwut wrote: post #220
nerdponx wrote: post #72

Earlier quoted context omitted.

I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.

These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories. >spending the time to prioritize my work before starting my work and/or discussing the same with my team And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no sp…

This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.

Re: How to be a -10x Engineer

#380

Post by nerdponx »

watwut wrote: post #246
robertlagrant wrote: post #233

Earlier quoted context omitted.

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.

It is a way to categorize tickets. It somehow influences what is going to be done next, but it is only one of many factors. One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.

People shouldn't be able to label their own bugs/features' severity or importance. They should be able to label it with severity or importance to them, and the team responsible should be allowed to triage accordingly.
Post reply on HN