Comment by tombert
6 years ago
You know, one of these posts pops up on HN every few months, and every time it kind of annoys me.
If I'm building a project for fun at home, then it's typically specifically to learn about a new thing (which I kind of assumed was the case for most people); either a new programming language, or a new editor, or a new library or two. If I short-circuit and "just build the product", then that is sort of negating the purpose of the project.
If I wanted to "just get something done", I probably wouldn't have done any projects in Haskell (back when it really sucked for tooling), I wouldn't have learned category theory, and I wouldn't have gotten any work in research.
This post isn’t for you. This is for the people that want to ship a product to paying customers and also want to learn a new technology doing it. In my (and what I’ve seen from others) experience, the programmer never ships the product because they’ve exhausted their time and energy on understanding the new technology, understanding the technology to do something they know how to do in other technology. The product never gets shipped and remains with the other projects that were never shipped.
Let's be honest even in our current technologies of choice the product rarely ships. But I get your point.
lol true.
1 reply →
> If I'm building a project for fun at home, then it's typically specifically to learn about a new thing (which I kind of assumed was the case for most people)
While I do sometimes get excited about learning a new technology, the most fun projects for me are where I already know all the tech required, and all the new ideas relate to whatever I'm building.
And I had assumed that would be the case for most people.
I see the differences between the two as:
1) Learning a new technology is kinda like reading a sci-fi short story to me: it's mostly about getting some interesting new idea, with the added benefit that it may apply favorably to my future work.
2) Building something new with known technology comes with the kind of unstilted, gratifying fun experienced when exercising well-developed skills in service of producing something. Often this comes with flow states; internalizing new concepts and practicing new techniques on the other hand are not ideal for this.
They both have their merits but to my mind, the second one is on another level, and I'd recommend to anyone using their fun projects only to learn knew things to try exercising their already established skills to build something they'd just like to see running, or to share with friends etc.
Edit: just to give an example: I had a lot of fun building this game where I learned no new technologies, and in fact had already built basically the same game 12 years prior (with different tech and far less knowledge). Instead I explored ideas related to the architecture that I thought might generalize, and enjoyed myself developing the algorithms and aesthetics that made the thing work: https://github.com/westoncb/under-game
It annoys me as well, and I think the intent is that "just build the product" is about avoiding shaving the yak.
Some of us poor bastards have to invent the stupid things that let people get things done, and it isn't exactly clear that the stupid thing is even good in the first place.
For instance, right now, I am in the process of inventing my own programming language. I've done this in the past with varying degrees of technical success, but it tends to get deep into the weeds of shaving the yak and polishing it up.
I'm have a hell of time to pull myself from the technically interesting problems to focus on the product that this language enables, and I find myself having to balance between fixing the language idioms and building the product.
Balance will be a key thing to focus on if I make this product a real thing for real customers... very challenging future ahead of myself.
> It annoys me as well, and I think the intent is that "just build the product" is about avoiding shaving the yak.
I think discussions in general on Hacker News, blogposts and Twitter is missing context. Everyone assumes that others context is the same that you yourself has. So posts like this make sense, if you're in "startup - lets find market fit - need growth - just build the damn thing" mode, which is probably the mode the author is, or the context would have been set in the blogpost.
In the comment you're replying to, the context is a "explore an idea and learn something new" with no intention on turning that very thing into a product that sells to people. Maybe that will happen, but it's not the intention.
In the end, two very different contexts, both valid, but they are both talking past each other. All the people using different social networks (HN included), usually miss the vital piece of context and just proclaim "You should do X, because of Y". Then people defend their context, because life is never "Always do X" and will never be.
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
1 reply →
You're so right, it really is talking past each other. That plus having the conversation in a way where we sort of pretend we aren't aware of the varying contexts.
What kinds of problems are you trying to solve that would make solving the (rather large) meta-problem of creating a /whole new programming language/, easier / more effective / more clear / more profitable - especially when compared with "just solving the problem with more established tooling"?
I don't ask this critically. I am genuinely curious. I wonder about this a lot; there are so many languages that solve the same problems in slightly-different ways, that I'm always curious as to the motivations behind creating another new language.
So, I have a particular domain where I hope to combine actors and data in a novel enough way. I'm not targeting 'general computation', and I'm defining a hopefully new market. It is very abstract at the moment, but I do intend to quit my job to pursue in 5 to 8 months.
1 reply →
The problem of them not being as good at creating a new programming language as they want to be.
So many amazing projects started as someone scratching an itch, often completely unrelated to the eventual product. And even if a project doesn't take off, if the goal was to get better at programming (and not marketing, project management, etc) it may be still be a success. Both forms of projecting have value. It all depends on personalities and where people are in their careers.
1 reply →
You're inventing a programming language? 1. That's awesome, seriously 2. What the hell real product are you working on that requires you to invent your own language lol?? I'm genuinely curious!
There will be posts in the future, but the problem space is related to actors and storage. I have to confine what is possible since there are a great number of ways to really mess up.
I see how you can find it annoying, but I have a friend that needs this advice (or a slap?).
He spends his energy lamenting over the "right" tools, to the point that he considers it a moral decision and part of his identity. He has trouble keeping work, because he's always looking for a company that uses the right tools instead of building the right thing. I'm sick of him lamenting "I could never work at [x] because they use java, and I never wanna see another NPE".
I personally constantly restart side projects, with different languages, or tools, or whatever because I read something about why {language, tool, whatever} is better than {what I was using}, so sometimes, it nice to remember that if its not a learning process.. it might just not matter :)
I've seen so many people fall into that trap. That's a really good description. It's kind of like a Starving Artist mentality/syndrome.
I think a lot of these posts aren't arguing "never build a side project to learn a new technology". I think they're arguing you should go into it eyes wide open, deciding if you're trying to learn new tech or build a side project. Because the first goal will interfere quite bit with the second goal. And more than a few devs have made the mistake of trying to start a new business on new tech and have blown their foot off.
Obviously this post is about getting things done for real projects, not working on a hobby or learning new things on the side.
Ironically, this kind of meta over-analysis is one of the major reasons why things don't get done.
The post is about people wanting to build a product (but who still find every excuse to stall), not for people who want to learn/tinker.