Comment by 0xFACEFEED
6 years ago
Good point. But isn't it the author's job to establish context? Otherwise what they're saying is typical "thought leader" platitude nonsense.
Here's another way of looking it. Shipping a product involves thousands of decisions and course corrections. Sometimes technical decisions like deciding on a build system or programming language. Other times product decisions like deciding to ship without user login and use an email "magic link" instead. And other times it involves building no product at all and just gathering some user feedback on the idea.
So if you look at it that way, "just build the product" is total nonsense no matter what context you're in. It's the ability to make good decisions that matters. What's a good decision? One that produces the results you're happy with (expected or not).
How do you make good decisions? Well, that's the hard part. The OP doesn't help at all. It's just fluff.
Example: You're working on a product idea. One of the core features is a DSL/language that the user types in a GUI to make some magical thing happen. Immediately you're faced with choices about your DSL/language. Should it be a subset/superset of another language? Should it be totally custom? Should you write your own parser? Should you use a parser generator? If you use a parser generator, how will you handle lax/incremental parsing?
If it were me I'd spend a couple weeks researching PL theory. In the process I might learn about the tradeoffs of choosing LL/LR/LALR grammars. Maybe I'll learn about state of the art grammar generators that'll save me weeks of coding and months (cumulatively) of debugging. Did I waste my time or did I just greatly improve my core product?
Another week later you're faced with decision of choosing a build system. Since your product will only ever run on AWS somewhere you write a simple Makefile and move forward. No point in diving deep into the likes of CMake/build2/etc if you don't have to. Could it bite you later? Maybe. If it does you'll deal with it.
Where does "just build the product" help here? Building the product is making these decisions thousands of times.
Oh boy, I'm ranting. I'll just press Reply now :P
>How do you make good decisions?
Good decisions come from wisdom. Wisdom comes from making bad decisions. Just make the decisions and learn from that. That's my interpretation of the post.
I sometimes do projects to learn new tools, and sometimes just to try to make something I want to play with. Sometimes it's good, sometimes it's not. But a couple of years later I might come back and revisit it with new knowledge and perspectives.
It's easy to get lost in the labyrinth of second-system syndrome and analysis paralysis and not really do the thing at all. Maybe better to do it with tech debt and sort it out later if it's worth it, and if not then learn from that. But still with a focus on the goals, not the means to get there.