[bob1029]

For me, a 10x engineer is about rate of value-add. Maybe its some of my manufacturing background, but I feel like the best engineers are constantly thinking about how they can increase the value of the product relative to customers (internal or external). These are the only things that really seem to matter at the end of the day.

Would you consider someone a 10x engineer if they can crank out a super-fancy backend service in 1 weekend that nobody wants to pay for or actually use? I know a lot of developers who occasionally fall into this trap (myself certainly not excluded). They can very enthusiastically produce output at the drop of a hat, but then we frequently have to put this output in the scrap bin and figure out how to recover the wasted time. This is why for most developers we have to have explicit design review sessions to make sure we are staying focused on the important value drivers. I have to make sure our work activities are well-scoped and broken down into small enough pieces to prevent elaborate trips into Alice's Wonderland.

Note that when I talk about value-add, that also includes paying off technical debt. Determining what debt to pay off is just as important as determining what new features to roll out. Determining how to balance debt vs feature development is one of the most arcane and dark magics. This is where the 10x thrives.

[kqr]

So much this. Quantifying the cost of delay and prioritising the things that have a high cost of delay over duration (CD3) in order to get the most value out the quickest (even if that turns out to be paying off technical debt where accrued interest is the cost of delay) is the hallmark of a fantastic engineer (and product owner, and salesperson, and ...).

I've been missing this opinion in virtually every productivity discussion on HN the last few weeks, at least, but could never be bothered to write the comment. Thank you for taking the time!

[amelius]

> Would you consider someone a 10x engineer if they can crank out a super-fancy backend service in 1 weekend that nobody wants to pay for or actually use?

They would perhaps be a 9x engineer, but that's still fine.

I don't think a 10x engineer, like most people, would want to be "optimized" at all costs.

And since you mentioned "1 weekend", I think that says it all. It's their spare time, and if they want to use it for coding, then that's their choice.

[bob1029]

I agree mostly with this. If someone is working on a side project then they are entitled to conduct that however they see fit. However, there should be zero expectations that this output can then magically translate into business value simply because it was undertaken.

Most software that is written is regrettably garbage in terms that business owners actually care about. If you want to do something hard & correct (aka valuable), that almost always means rigorous engineering/planning to make sure everything lines up.

We wouldn't expect a structural engineer to be able to employ one of their hobby designs for actual use, nor would we ever want to entertain that idea. I feel similar thoughts should apply to software engineering, which in some cases is also life safety critical.

[kqr]

> that almost always means rigorous engineering/planning to make sure everything lines up.

Trying to plan a software project up front is a great way to miss the mark and fail to deliver value.

Going with a "hold before tape before weld" mentality to prototyping and experimentation, we can get a lot of real-user data out of just putting something quickly out there and refining it as we receive feedback on it.

This approach is based on the fact that most of our good ideas aren't that good, so we optimise for the case where were wrong, and try to plan as little ahead as possible -- because any planning is based on imperfect information and requires speculative work that is likely to need to be thrown away.

In contrast to manufacturing where we need only to minimise work-in-progress, in development, we also need to minimise design-in-process -- also known as planning.

This is a way in which product development is different from manufacturing.

In manufacturing we can stamp our variability. In development variability is both desirable (it's how we innovate) and quite large, so we must obsess about maximising our use of feedback to guide our designs.

There's more on the perspective in Reinertsen's book on the Principles of Product Development Flow. I highly recommend it for anyone, but particularly someone who knows a bit about manufacturing but wants to effectively translate this knowledge to product development.

[goatinaboat]

Would you consider someone a 10x engineer if they can crank out a super-fancy backend service in 1 weekend that nobody wants to pay for or actually use?

In a competitive situation a person might be 10% better but win 10x as often as the next best person. This is often taken to mean they are 10x better however.