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

Re: How to be a -10x Engineer

#251

Post by yamtaddle » Tue, Apr 04, 2023, 3:30 PM UTC

mgkimsal wrote: post #181

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

Holy tamole. Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except,…

I remember reading a blog post from a certain project management software startup bragging about their genius lead engineer who created this wonderful NIH frontend framework for them, how it worked, et c.

Having used the product (which would not-infrequently manage to make keyboard input lag by full seconds on strong hardware, ate hundreds of megabytes of ram and tons of processor cycles while idle—even worse than your average webshit "app") and putting 2 and 2 together, I'm pretty sure I could have written a list of things they'd failed to take into account, and reasons the results were so poor. It was a fun read thanks to all the details, like "oh, that's why this is so awful, I see exactly what's wrong now".

Re: How to be a -10x Engineer

#252

Post by vbezhenar » Tue, Apr 04, 2023, 3:33 PM UTC

whateveracct wrote: post #179

austin-cheney wrote: post #156

Earlier quoted context omitted.

Super subjective. The most common thing I see is developers compensating for this by never writing original code and then demonizing others who do when they cannot read it. By original code I don’t mean config files or glue for frameworks.

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.

Re: How to be a -10x Engineer

#253

Post by plorkyeran » Tue, Apr 04, 2023, 3:34 PM UTC

robertlagrant wrote: post #233

watwut wrote: post #222

Earlier quoted context omitted.

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.

The discussion over what priority label to put on a ticket has very rarely changed my opinion on what the actual importance of the ticket is, and I'm generally going to pick what to work on based on that, not based on the label.

Re: How to be a -10x Engineer

#254

Post by z3t4 » Tue, Apr 04, 2023, 3:43 PM UTC

pl90087 wrote: post #174

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…

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 kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.

Re: How to be a -10x Engineer

#255

Post by yuppie_scum » Tue, Apr 04, 2023, 3:45 PM UTC

As a manager, I’d rather have a 1x engineer who spends that x doing exactly what I want/need.

Re: How to be a -10x Engineer

#256

Post by michaelt » Tue, Apr 04, 2023, 3:48 PM UTC

robertlagrant wrote: post #237

mnd999 wrote: post #153

Earlier quoted context omitted.

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.

2 minutes? That's barely enough time to load the Jira ticket creation page...

Re: How to be a -10x Engineer

#257

Post by steveBK123 » Tue, Apr 04, 2023, 3:48 PM UTC

mgkimsal wrote: post #199

jameshart wrote: post #149

Earlier quoted context omitted.

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…

> Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then…

Yeah and the larger issue - putting 20 people in a room for 2 hours violates like every single management / efficiency / socio-political recommendation in the book.

The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.

Re: How to be a -10x Engineer

#258

Post by yamtaddle » Tue, Apr 04, 2023, 3:51 PM UTC

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…

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-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work.

Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.

Re: How to be a -10x Engineer

#259

Post by letitbeirie » Tue, Apr 04, 2023, 3:51 PM UTC

highwaylights wrote: post #244

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 D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it. And now we have problems A through E.

Oblig: https://xkcd.com/927/

Re: How to be a -10x Engineer

#260

Post by steveBK123 » Tue, Apr 04, 2023, 3:51 PM UTC

crazygringo wrote: post #212

swiftcoder wrote: post #178

Earlier quoted context omitted.

> Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway

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

So, in my example, we were having 2-3x/week 2-hour, full dev staff meetings.. without product in the room. He was a very busy man and could only grace us with his presence for 30 min every 2 weeks to basically sort the tickets we had spent 12 hours putting together and decide which he actually cared about.

Much could be accomplished more efficiently by getting product, management, and 1-2 seniors in a room for 30min to actually decide what/if plans have changed & cascade the changes accordingly.

99 times out of 100, the plan didn't change because something raised from the bottom, but because management has changed direction or users have asked for something new. Why subject 95% of the team to hour long monologues?