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

361–370 of 514 posts

Re: How to be a -10x Engineer

#361

Post by KronisLV »

I actually wrote an article a little bit like this one, a tongue in cheek piece called "The Unethical Developer's Guide to Personal Success": https://blog.kronis.dev/articles/the-unethical-developers-gu...

In short, software development should most of the time be treated as a group activity and you should consider how the output of your own work affects those around you. While you might not feel like documenting your decisions is a wise use of time, it could help others down the line. The same goes for choosing the simplest solution that works well vs going out and writing lots of "clever" code. Things like the ways how we communicate, how much nitpicking vs accepting "good enough" solutions all compount and have a pretty great effect on the output of others.

Re: How to be a -10x Engineer

#362

Post by ResearchCode »

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…

It's busy work if you do it more than 1 hour any given week. If you do it full-time, you're something like a -10x engineer.

Re: How to be a -10x Engineer

#363

Post by JohnFen »

convolvatron wrote: post #353
JohnFen wrote: post #313

Earlier quoted context omitted.

"Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct. Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths: 1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me. 2) If I embark on…

I find value in rewriting/refactoring it as a learning exercise. just take a quick pass. now you are in a really good position to talk about what the strengths and weaknesses are of the existing version.

Oh, yes, I agree with this. But I count this more as "research" than creating production code.

Re: How to be a -10x Engineer

#364

Post by varjag »

2OEH8eoCRo0 wrote: post #274
lispisok wrote: post #270

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

I thought so until I met one. He knew what our team lead wanted before he wanted it and would already have it done, along with all of his assigned work. He would take initiative and build tools that the whole team could use and be more effective with. He had a huge impact on me.

Seconded. I was lucky to work with one at my first job, which helped to calibrate expectations and set standards for myself.

Re: How to be a -10x Engineer

#365

Post by treeman79 »

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…

Had many times where I saved a company months of work by forcing a meeting to lock in UX requirements. Basically go through screen to screen on a whiteboard what should happen.

This almost always leads to major changes to the whiteboard during the meeting.

Had many times were I couldn’t get company to do this exercise. First time leadership sees UX is on completed project.

Team then spends months rewriting application. Everyone generally pissed.

Re: How to be a -10x Engineer

#367

Post by ResearchCode »

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…

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.

Re: How to be a -10x Engineer

#368

Post by steveBK123 »

swiftcoder wrote: post #340
jameshart wrote: post #275

Earlier quoted context omitted.

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working? It’s an option, I guess… let us know how it works out for you.

I mean... yeah. That's kind of how a lot of big enterprise projects with VP-level visibility get managed (I participated in versions of this at both Amazon and Facebook) Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout t…

Yeah, I think this level of planning has gotten lost in our recent fad of agileness.

Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there.

I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there".

Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc.

However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.

Re: How to be a -10x Engineer

#369

Post by lelanthran »

austin-cheney wrote: post #286
vbezhenar wrote: post #252

Earlier quoted context omitted.

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.

Uugggghhh… “maintainable way” is again super subjective. Normally when people say that what they really mean is in a way that fits a pattern familiar to them. If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastica…

> Uugggghhh… “maintainable way” is again super subjective.

It's not "super subjective" when something super niche like Haskell[1] is chosen.

There are pragmatic reasons to choose a tech stack, the biggest of which is "can we find people to maintain it?". If you cannot, then it's unmaintainable.

[1] That's the example that was chosen upthread.

Re: How to be a -10x Engineer

#370

Post by lelanthran »

whateveracct wrote: post #266
vbezhenar wrote: post #252

Earlier quoted context omitted.

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

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

Yeah, but if the stack was something common then it still wouldn't be as big a problem.

Post reply on HN