My approach to building large technical projects (2023)

Previously:

My approach to building large technical projects - https://news.ycombinator.com/item?id=36161397 - June 2023 (27 comments)

I feel there is a balance to strike with rushing to a demo. .. (maybe it's an implicit tension between the satisfaction of finishing a component and getting a demo)

I think this is where the choice of language makes a big difference. In Clojure, the difference between a "component" and a separate library/application is literally just adding a `deps.edn` file and then pointing to the directory from the parent project.

I think breaking the project in to small achievable goals is very sensible. But if you take the extra time to make the component stand on its own as a mini-lib .. it's very satisfying. For instance I had to write a "component" that would read some GeoJSON and segment it (it's took me a couple of days and was mostly a wrapped around GDAL or something). I could have hacked together a solution to rush to a demo - but instead I made a small little library out of it. When I was done with it, I had a sense of "I made a thing". To be clear.. it's still kind of ugly and I would be horrified if someone else tried to use it and submitted PRs.. but it's also not a coupled tangle of code in my larger codebase.

as he says "Build for yourself" - the library/application should only do what you need

By contrast, if I was working in C++ making an API and decoupled library would be such a chore that'd never bother

The most important aspect is that this all ends up not just much more satisfying at every step - but it makes your code incredibly decoupled and refactorable. The more you rush to a demo the more your code is coupled and hard to refactor.

One of the few people that has done consistently good open source projects, with very clean and clear vision of what the project should accomplish.

Would you say that testcases help here? I've been thinking about applying e2e tests on any bugs I find so I know they're fixed