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

Re: How to be a -10x Engineer

#261

Post by arcanemachiner » Tue, Apr 04, 2023, 3:55 PM UTC

cratermoon wrote: post #192

mgkimsal wrote: post #181

Earlier quoted context omitted.

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

> "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?" Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.

"If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein*

*I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.

Re: How to be a -10x Engineer

#262

Post by eecc » Tue, Apr 04, 2023, 3:59 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…

Heh, I was once walked through a live “code review” where all my code that used Java steam maps were replaced by this one dude with for loops in private methods. What a dress-down… pff, the project was canned a few months after I left. But I’m a consultant, no long term investments

Re: How to be a -10x Engineer

#263

Post by haweemwho » Tue, Apr 04, 2023, 3:59 PM UTC

letitbeirie wrote: post #259

highwaylights wrote: post #244

Earlier quoted context omitted.

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/

[flagged]

Re: How to be a -10x Engineer

#264

Post by steveBK123 » Tue, Apr 04, 2023, 4:01 PM UTC

plorkyeran wrote: post #245

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…

My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly mee…

What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you."

What else do you want us to do for 4-6 hours/week? Write poetry?

Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.

Re: How to be a -10x Engineer

#265

Post by danaris » Tue, Apr 04, 2023, 4:01 PM UTC

denton-scratch wrote: post #200

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…

> 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. Explaining complex things with a diagram can be an extremely effective method for making what might otherwise require a very high cognitive load much easier to process.

And for the second, if someone needs a diagram to understand something complex, it's not because they're stupid, and insisting that everything worth explaining can—and must—be explained in text only does them a disservice.

Re: How to be a -10x Engineer

#266

Post by whateveracct » Tue, Apr 04, 2023, 4:02 PM UTC

vbezhenar wrote: post #252

whateveracct wrote: post #179

Earlier quoted context omitted.

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.

The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out. As I said, the team was fully functional, in production, low bug rate, generally happy.

Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).

The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.

So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.

Re: How to be a -10x Engineer

#267

Post by roncesvalles » Tue, Apr 04, 2023, 4:06 PM UTC

strken wrote: post #69

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 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 somewhere and call it a wrap, without writing a word of searchable and version-controlled documentation.

Re: How to be a -10x Engineer

#268

Post by danaris » Tue, Apr 04, 2023, 4:06 PM UTC

watwut wrote: post #209

jrussino wrote: post #183

Earlier quoted context omitted.

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

Unless of course, they are not helping the team at all. Unless they are busywork we go through without ever looking at again or using it practically. Unless they are made to avoid making decision and then to avoid it again. The company I work for have quite a lot of all hands presentations with content relevant to like ... 5 people. While everyone else nods, sleeps, reads reddit, zooms out daydreaming. We have diagra…

It's always a balance. There is no universally-correct amount (or types) of meta-work to make a team function optimally.

For some teams, especially very small ones (and most especially if they're all volunteers), adding significant amounts of bookkeeping to their tasks is likely to be much more trouble than it's worth. (Though, again, even for some solo developers, the bookkeeping can be very valuable—it's all about the specifics of the projects and the ways different people operate.)

For other teams, not having the extra bookkeeping will mean that the people struggle to keep their tasks straight, or get abused by their managers, or have a variety of other problems.

The most important thing is to be reflecting on your and your team's work and processes, and being open to changes that might improve them.

Re: How to be a -10x Engineer

#269

Post by nyob » Tue, Apr 04, 2023, 4:08 PM UTC

ejb999 wrote: post #58

maayank wrote: post #38

"Explain code in private messages. Write wikis that nobody uses." What the reasonable alternative though? What's the happy medium?

>>Explain code in private messages. ...and this is the natural result of the 'no comments allowed in the code' nazi's that seem to permeate lots of organizations. For the life of me I could never understand that particular bandwagon. I for one love it when I go back into my code after a few years and a few well placed comments remind me why I did what I did last time I worked on it.

I would suggest you to read Clean Code by Robert C. Martin. There's a whole chapter about comments in the book.

Re: How to be a -10x Engineer

#270

Post by lispisok » Tue, Apr 04, 2023, 4:09 PM UTC

sigh. The 10x engineer has become tech's most toxic concepts and devs are its victims, yet we keep bringing it up constantly. Every time it's brought up it's a new variation that's either bad or good but always different than the original proposal of the BEST programmers are 10x more productive than the WORST developers from a paper in 1968. All that is come of it is devs arguing about a hypothetical programmer is and made management even more insufferable. The idea is only hurting you, quit bringing it up, when it is brought up point out it's a bad concept and move on.