I'm a quality hero, customer champion. Experienced software tester and newbie developer.
Okay, so I've actually been dabbling in code for a long time. I've just not gone very deep in any language .
If you think of what we didn't know yesterday, and then think about what we will know tomorrow. That "one way", may change and evolve over time.
To put it another way, it's difficult to determine if thing A really is the same as what you need, is it an identical use case? How well did it work out for others, or old you?
And what about room for innovation, maybe there is a more performance focused way to do A but with some compromises?
Summary: having an obvious way that is only deviated from for a good reason sounds sensible. Forsaking all possible alternatives upfront feels foolish.
I'm a quality hero, customer champion. Experienced software tester and newbie developer.
Okay, so I've actually been dabbling in code for a long time. I've just not gone very deep in any language .
If you think of what we didn't know yesterday, and then think about what we will know tomorrow. That "one way", may change and evolve over time.
To put it another way, it's difficult to determine if thing A really is the same as what you need, is it an identical use case? How well did it work out for others, or old you?
And what about room for innovation, maybe there is a more performance focused way to do A but with some compromises?
Summary: having an obvious way that is only deviated from for a good reason sounds sensible. Forsaking all possible alternatives upfront feels foolish.
An example might be, using half, or or even quarter precision floating point maths for GPGPU powered ML.
This wasn't the first only obvious way, but it is the newer innovative way.