Live data from Hacker News

How to be a -10x Engineer

taylor.town

321–330 of 514 posts

Re: How to be a -10x Engineer

#321

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

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

You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.

Re: How to be a -10x Engineer

#322

Earlier quoted context omitted.

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…

Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer. I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

There are more costs than onboarding costs.

Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.

Re: How to be a -10x Engineer

#323
post #101

Earlier quoted context omitted.

"Aaaand that's the container address orchestrator -- it's written in Haskell by that one guy a few years ago."

It reminds me of some Python threading monstrosity a guy wrote at my first job. He said something like "this is my own take at async".

To be fair to that guy, the Python standard library provides a multitude of incompatible takes at async already, none of which covers all common use cases. The newest take (asyncio) doesn't integrate with external event loops, so unlike similar libraries in C# and Kotlin, it doesn't work with GUI libraries, not even the one in the standard library (tkinter).

The third-party asyncio alternative Trio, on the other hand, has recently added "guest mode" [1] to plug in external event loops, so maybe that will become the one true way to do async.

[1] https://trio.readthedocs.io/en/stable/reference-lowlevel.htm...

Re: How to be a -10x Engineer

#324

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…

Negative 10x

Re: How to be a -10x Engineer

#325

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…

a 10x engineer might not exist. A -10x engineer (or more accurately: a 1/10x engineer) definitely does.

This article isn't about engineers that make your team better; it's about engineers that make your team worse.

Re: How to be a -10x Engineer

#326
post #129

Earlier quoted context omitted.

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

Ha. No.

Re: How to be a -10x Engineer

#327

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…

The original paper was actually x27 developer or something crazy like that. I think Brooks recast it as the x10 developer because x27 was too unbelievable.

Re: How to be a -10x Engineer

#328
post #74

> Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible. A lot of legacy software is like this. I wonder how many billions it costs the economy per year.

Its extremely hard to argue for debuggability. I always try to prioritize how easy is it to test the said feature and understand it. However, during reviews of other engineers PR, I am always met with criticism that there is no need. "Instead of localhost, this can be tested on staging" and etc.

Debuggability is a top factor for how long development will take. How is it hard to argue for?

Re: How to be a -10x Engineer

#329

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.

That just sounds like a developer who had worked on a similar project before, which would obviously look like some kind of genius vs those starting from scratch.

Re: How to be a -10x Engineer

#330

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.

You're gonna take heat for that position, but I'd support you, having been in the same position. Came to a team in a company that had a handful of services where folks had been "doing things" in an FP manner where it was entirely inappropriate (CRUD app, without going into details). The had wonderfully illegible, but functional, code that was lacking required basics like transaction management, yet were befuddled as to why certain integration tests or deployments were behaving unpredictably. Similar to your situation, the original decision makers were long gone by the time I arrived.

It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly:

1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.

Post reply on HN