Being able to prioritize building projects like this is a skill in itself, and I think it's a really important one.<p>People seem to chronically undervalue optimizing for shipping something. Mitchell does say "I don't talk about shipping", but shipping a demo for yourself is still shipping!<p>It doesn't matter how good you are if you can't stick at something for a long period of time. You're probably not going to be able to do the thing for long enough to generate big ROI.<p>Optimize for something usable. Go one step at a time. If you get discouraged or lose motivation it's game over, you gotta prevent that at all costs.
> 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.<p>The one caveat I'd add to this is to make sure to panic (throw an exception or assert false) at all unhandled edge cases in the good enough subcomponent. It's often easy to write conditionals for the happy path without a corresponding else for the unhappy path. You don't need to implement all branches initially, but you will likely be glad you added those panics, which have the bonus side effect of showing you exactly where the unhandled edge cases are, as you expand the sub-component to handle those edge cases.
Nice approach. It feels very similar to "tracer bullet" development (I think coined by the pragmatic programmer book), where you get something end-to-end as quickly as possible and then start iterating on the parts.
(<a href="https://www.swaroopch.com/tracer-bullet-development/" rel="nofollow">https://www.swaroopch.com/tracer-bullet-development/</a> explains it too)
This video on youtube is pretty cool on the subject of big projects:<p>How to Achieve Your Most Ambitious Goals | Stephen Duneier | TEDxTucson
<a href="https://www.youtube.com/watch?v=TQMbvJNRpLE">https://www.youtube.com/watch?v=TQMbvJNRpLE</a>
My work is nowhere near as impressive as Terraform, Consul and Packer. Hashicorp products show insight and vision. They get things done. So take my thoughts as I haven't done something as impressive as that.<p>I generally work on small technical side projects that are achievable and do something interesting or useful. Then I start another one in a different subject or problem but also useful by itself with the desire of plugging/joining them together. Because they're all interrelated. They're technical demonstrations, not products.<p>I play in IPython Notebook or replit with no goal of shipping something then I when I have something satisfying I move it to its own repository on GitHub, then I add features increasingly until I am satisfied I understand what I intended. This is not product thinking, it's building to understand something that you think is interesting or useful.<p>A few months ago on HN I wrote a comment talking about my dream to create a JIT Compiler - similar but much less serious than V8, JVM or the CLR. I also talked about a multithreaded runtime that can schedule lightweight threads similar to Golang or Erlang. I want to understand asynchrony, parallelism, coroutines, multithreading and locks enough to abstract them away from developers. My JIT compiler is incomplete: it can JIT compile MOV and ADD instructions and printf without parameter passing being done but not much else. When I feel inspired to work on the next piece of work on it, I'll keep working on it. At the moment I'm more interested in parallelism and asynchrony runtimes so my attention is there.<p>I've noticed that there is a task that we put off with the desire to come up with an elegant solution so we don't have to do it. Such as a refactoring or yak shaving to support something we need to support to do what we want to do.<p>I've been learning about delimited continuation passing and algebraic affects.<p>With some of the core counts on AWS you could process many requests in parallel and yield on IO so you could get some extremely impressive requests rates were the software well designed. I think 600,000 requests per second is top of the line for a single c++ server on the fortune TechEmpower benchmarks.<p>I want to make my own things and understand them well. I also want to learn other project's codebases and understand them well enough to work and think in them.<p>If you have a side project, I encourage you to work on it. I am always interested in people's writeups of their side projects.<p>There is so much work to do, it's not just 1 thing you need to learn and understand and think in (the programming language) there's a 1000 other tasks that need to be done to get anything shipped or useful for other people to use generally. The "getting past the recognising you have 1000 tasks to do for the first time" is really difficult in just working and forging ahead and getting stuff done. If only I could tackle all those 1000 tasks the same way I do the things I am good at, rather than not experienced or effective at.
Note he doesn't mention a user story. Large technical projects apparently let you ignore what the user wants, use cases, dependencies, stakeholders, design reviews, feature changes. Instead you just decide what you want and wait to see if the user wants it too.