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