Previously:

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

I have huge respect for Mitchell, it's impressive what he achieved.

I agree with all the points of this article and would like to add one: Have a quick feedback loop. For me, it's really motivating to be able to make a change and quickly see the results. Many problems just vanish or become tangible to solve when you playfully modify your source code and observe the effect.

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.

This is how agile should look like. Focused, iterative and always functional.

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.

For me just starting is the best way. So many people see a big project and get trapped in analysis paralysis.

>This is an area where I think experience actually hurts. I've seen senior engineers get bogged down building the perfect thing and by the time they get a demo, they realize it sucks. The implementation doesn't suck, but the product or feature itself actually sucks.

This resonates with me. Sometime i want to "turn off" my brain and write shitty code.

Back in the day, i made a lot of toy project. Sometime all the source code is in single file. No respect to modularity. But it was fun, and it worked. Now just try to finish a toy project seem much harder than ever.

Great read, but I was expecting something different based on the title.

This sounds like his approach working on personal projects. I'm really curious about large technical team projects though. What's the best approach to getting stuff done and making sure everyone is working towards the same goal etc.

After 15 years I have yet to see a technical project that hasn't run over budget, over time, under delivered or burnt people out.

I'm sure there are people out there with counter examples who know exactly how to deliver projects at a massive scale. Any links/suggested reading would be appreciated!

Really enjoy the post, thanks for sharing.

> My goal with the early sub-projects isn't to build a *finished* sub-component, it is to build a good enough sub-component so I can move on to the next thing on the path to a demo.

This is so enlightening. And I realized that to do this, one has to "skip" something. Other folks mention they ignore code modularity when doing this, I don't think I will do that, keeping code clean and reading/working in such a codebase actually make me satisfied and motivated. For me, I am going to "skip" algorithms, data strucuture and performance.

So the point here is probably, we should skip things, but if a thing motivates you, it should not skipped?

An interesting consideration is how the chosen modularization approach can impact onboarding time for new contributors. A well structured breakdown might not just aid initial development speed, but also reduce ramp up friction for future team members or external collaborators. This is an impartant factor often under-estimated in solo-driven projects.

//Decompose a large problem into smaller problems. Only solve the smaller problem enough to progress on a demo... ...then continue to iterate on more functionality. Make demos as frequently as you can. Prioritize functionality that enables you to adopt your own software Go back and iterate on each component as needed for future improvements//

So in essence we have: Empirical Process Control, Self-Organization, Collaboration, Value-Based Prioritization, Time-Boxing, and Iterative Development.

Is this just solo-SCRUM or am I missing something here?

For me the best demo is a test module lighting up all green.

How do make this into a sexy image for management. Sure, business logic is stubbed, but my carefully crafted strongly typed interfaces all mesh together! Imagine the future dividends!

This isn't an "everyone who struggles to finish projects or is a perfectionist has it" kind of post, but if this has been a long-term pattern for you, one that's caused real suffering, lost jobs or contracts, or kept you from finishing important work - please consider getting checked for ADHD. It took me 42 years to get diagnosed, and starting on stimulants genuinely changed my life and pretty much solved those issues for me.