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

401–410 of 514 posts

Re: How to be a -10x Engineer

#401

Post by jltsiren »

nico wrote: post #342
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…

Everyone is different. The key is not forcing people into your own worldview. Some people do better with documentation or tickets or code or meetings. The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.

Everyone is different, but it doesn't matter that much.

When you have a small team, you can often organize the work the way people prefer. Then you'll find that people who can be incredibly productive under ideal circumstances are actually quite common.

But as the organization grows, you have to focus more on the process and the structure. Individual productivity doesn't matter if you can't channel that productivity to advance the organization's goals. You rely increasingly on people who can work productively within the system. People who thrive in a wide range of environments, even when they would prefer having things organized in a different way.

Re: How to be a -10x Engineer

#402

Post by JohnFen »

whstl wrote: post #390
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've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable. While I agree with #1, that "offensive" code is offensive for a reason (no time, no experienc…

Your examples are excellent reasons to do a rewrite. Rewriting code is not always the wrong decision. But in the main, when it seems that a rewrite is warranted, it's a good idea to think long, hard, and objectively about why it seems like a good idea.

> With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.

You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite.

I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change.

The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision.

> bad code is often due to accidental complexity, often brought in by the programmers themselves.

Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.

Re: How to be a -10x Engineer

#403

Post by 908B64B197 »

Herval_freire wrote: post #321
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…

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

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

I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.

I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.

There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.

> 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 most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.

That's thinking in terms of bricklaying. 10x, like Carmack or Woz for example, bring completely new ideas and paradigm shifts. Think of the engineering happening at Xerox PARC for instance.

[0] https://blog.pragmaticengineer.com/software-engineering-sala...

[1] http://danluu.com/bimodal-compensation/

[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...

Re: How to be a -10x Engineer

#404

Post by meshaneian »

JohnFen wrote: post #313
aetherson wrote: post #290

Earlier quoted context omitted.

"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.

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

"The engineer(s) that wrote the offensive code were almost certainly not idiots."

Bold statement, but closer to accurate than the first impression.

Re: How to be a -10x Engineer

#405

Post by com »

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’m a big fan of putting more time and effort into communication.

I just think that there’s an incredible set of decreasing returns after about 30 minutes into building any diagram or presentation, for most people and most use cases.

That’s why quick whiteboard or lucidchart or Miro sketches are so powerful - and are designed to communicate in the moment! - and most PowerPoints, swimlane diagrams etc which have tens or hundreds of hours of work are like polished turds.

Very few diagrams or presentations show history and almost none are ever updated to show the status of things today. Which means that they just cause confusion. Generally, someone starts again and creates something with new blind spots and which takes about as much time again to create, and is out of date before others see it.

Drawing and presenting is mostly interesting if the people who are present for the drawing or description process can go forth and explain, draw or present it in their own words or images, and therefore communication has been achieved; this seems to be very uncommon in most drawing and presentation-heavy environments I’ve been in though.

Re: How to be a -10x Engineer

#406

Post by bstpierre »

ryandrake wrote: post #277
JoeAltmaier wrote: post #250

Earlier quoted context omitted.

Absolute priority quickly becomes washed out - everything gets shoved to one end of the range. A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this: We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "pro…

I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.

Re: How to be a -10x Engineer

#407

Post by surement »

nailer wrote: post #15

- Add cool new tech to projects you're working on with ten other people. Ensure only one other person knows. - Name all your variables 'data'. - Copy and paste everywhere. People will think they've fixed a bug, and they have, but you've got seven slightly different copies of the function that needed fixing and now there's six left. - Take a project that's using one of those 'prettier' 'black' style tools to avoid bik…

> Name all your variables 'data'.

Name a class "Entity" and make everything else derive from it. Write code that can't be deleted, ever.

Re: How to be a -10x Engineer

#408

Post by hsbauauvhabzb »

yamtaddle wrote: post #251
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,…

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

I think referring to office 365 as a ‘software startup’ is a fairly long stretch, so I may have come to an incorrect conclusion but the rest is a fairly accurate description of o365 in my experience.

Re: How to be a -10x Engineer

#409

Post by bstpierre »

wpietri wrote: post #373
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 gri…

If the ticket is a direct conduit to the customer, I think you could argue that ticket management in the form of asking clarifying questions so that you build the right thing (or fix the right bug) is creating value?

Re: How to be a -10x Engineer

#410

Post by watwut »

camjohnson26 wrote: post #296
watwut wrote: post #228

Earlier quoted context omitted.

>No but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama Frankly, this sounds exactly like toxic management where people are not allowed to raise issues which then blames everybody but themselves for consequential infectivity. > If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in…

Taking the bare minimum of time to understand a problem before complaining about it isn’t toxic, it’s human decency that respects other people’s time. If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs. I don’t think you’re saying that you couldn’t explain why the light not working is a problem. No one said you have to know how to fix it.

Except that, demanding that people have solution, which is what parent did and "taking the bare minimum of time to understand a problem" are two massively different standards. The original article definitely clears the "taking bare minimum time to understand a problem" standard. Neither parent nor you are content.

> If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs.

Obvious difference is that article did not complained about trivial issues. It complained about very real issues that waste massive amount of time.

> I don’t think you’re saying that you couldn’t explain why the light not working is a problem.

Adding "I do not see without light" is completely unnecessary when complaining about broken switch. There is zero need for it. Similarly, it is no mystery why issues in article are problems.

If you are unclear about why any of listed issues is a problem or disagree, you could have made that claim. But, neither parent nor you claimed not understanding that. All you want is to prevent people from talking about these issues.

Post reply on HN