Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Right. That's what's impressive. They built the right tools, presumably during previous projects. The tools they built were useful enough to enable future work.

You may not know what tools you will need in the future but when you need a new tool you can build it in a way that it is reusable.

In other words a good tool solves an abstract problem. I don't need an Ikea-Bergmund-chair-leg-attacher. I need a screwdriver.

Once you have a toolbox full of these basic tools you are better prepared to tackle those future projects.



While you are technically correct and I agree completely, I think your emphasis on abstraction might lead to higher (or at least more variable) cycle times rather than lower.

It sounds like you're suggesting that one spends, say, 80 % of one's creativity coming up with general, abstract problems to tool for, and then 20 % of the creativity on finding ways to apply general tools. That absolutely works, I think, if you're fine with high variability in the time you spend between each release.

What I tried to suggest is that instead you spend 40 % of your creativity on finding abstract problems to tool for, and the other 60 % of your creativity in finding ways to apply your distinctly less general tools to new situations, despite their lack of generality.

What concerns me about the high-abstraction route is that people, in my experience, have a tendency to over-abstract. To try to predict every future use case ahead of time, instead of accepting their ignorance and building for ease of change.

That is why I want to emphasise modding non-general tools rather than future-proofing tools at the design stage. Because you can't know at the design stage in which direction future innovation will go.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: