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

181–190 of 514 posts

Re: How to be a -10x Engineer

#181

Post by mgkimsal »

svachalek wrote: post #148
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…

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, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks.

About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!"

This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that.

You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...

Re: How to be a -10x Engineer

#182

Post by fourseventy »

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…

I found the scrum master

Re: How to be a -10x Engineer

#183

Post by jrussino »

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…

I recently heard a quote that resonated with me: "If you want to go fast, go alone. If you want to go far, go together". I wonder if someone who treats these tasks as "non-work" is thinking of themselves as being more productive because they go faster than the folks around them, not considering that these other tasks that slow them down individually also help the team go farther in the long run...

Re: How to be a -10x Engineer

#184

Post by fourseventy »

commandlinefan wrote: post #155
docandrew wrote: post #65

Earlier quoted context omitted.

You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

> whether a ticket was “critical” or merely “high?” or truly a blocker Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.

Infinity blocker, infinity + 1 blocker

Re: How to be a -10x Engineer

#185

Post by m3kw9 »

postalrat wrote: post #121
m3kw9 wrote: post #112

Earlier quoted context omitted.

That’s not what he said about anyone critical is an ass, he’s say rather than -10x, worse for a company are assholes and they do exist

I can deal with assholes who get stuff done. Developers who are consistently making negative progress are harder to deal with. -10x developers can get the just by promising things people depend on but never deliver.

Usually is easier to deal with -10x devs than assholes because they are likely devious is not easy to handle. A crapy dev can be dealt with when you present their git commit to the manager/lead

Re: How to be a -10x Engineer

#186

Post by cratermoon »

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…

Yes but I've also been buried in presentations, diagrams, and ticket management that don't contribute to communication. That's doubly wasteful because not only is time wasted making all these artifacts, but even when produced they still don't improve understanding. Might as well have a chatbot write them, they couldn't be worse. Ticket management fails to keep anyone updated when it's just a performative way to make managers and execs believe they are seeing progress when in fact the ticket board is a fiction unrelated to real effort.

Re: How to be a -10x Engineer

#187

Post by swiftcoder »

theamk wrote: post #102
docandrew wrote: post #65

Earlier quoted context omitted.

You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

If ticket priority does not matter, then why do you care? Set them all to single priority and don't think about it. If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes: "You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?" When said this way, doesn't seem like "waste" to…

> If ticket priority does not matter, then why do you care?

Because when you have a ticket priority system, there is often someone external who cares deeply about ticket priority. And reporting requirements around ticket priority. And metrics about ticket priority over time.

If you've never been pulled into a meeting with Comms and Legal to discuss retoractively whether a (completed) ticket should have been labelled High or Severe... count yourself lucky

Re: How to be a -10x Engineer

#188

Post by mgkimsal »

robertlagrant wrote: post #81
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…

> I suspect that the presentations and diagrams which need to be made, are made. I don't think that's true. E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes. Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"

The whole "yeah, just have a conversation" thing bugs me a lot. I like talking, and having conversations. It's rarely enough. The information needs to be written down (or codified in tests or whatever). Future people won't have the luxury of a conversation with whoever originally wrote something. Conversations aren't indexable. Conversations lose nuance, memories fade or get jumbled. Have your conversation, then document/diagram it afterwards.

Re: How to be a -10x Engineer

#190

Post by eschneider »

Meetings are a huge opportunity to either value-add or value-subtract and a little planning can go a long way. Some pointers:

* Have an agenda and circulate it along with the invite. Let people know what you want to discuss so they can prepare. * Know what outcome you want from a meeting and let people know in the invite. Again, it lets them come prepared and even better, make pre-meeting suggestions. * Think about who needs to be involved. Do you really need everyone, or just one or two people. Again, agenda lets folks know if they can contribute or if someone else needs to be pulled in.

It's not that meetings are bad, but bad meetings waste lots of people's time. Good meetings save time.

Oh, and write down meeting minutes and publish results. The person you're recording this for is usually yourself. :>

Post reply on HN