# My Approach to Building Large Technical Projects  ## Metadata - Author: [[Mitchell Hashimoto]] - Full Title: My Approach to Building Large Technical Projects - Category: #articles - URL: https://mitchellh.com/writing/building-large-technical-projects ## Highlights - A method that works really well for me is to continuously see real results and to order my work based on that ([View Highlight](https://read.readwise.io/read/01h1ya4m46ksppdwhydjyh3pqs)) - For me, this is the hardest part and I can spend hours -- sometimes days -- waffling over the right starting point. ([View Highlight](https://read.readwise.io/read/01h1ya6aexzbtckpm86v9rvtay)) - For my terminal emulator, there were a number of large components that I knew would have to exist if I ever intended to finish this project: terminal parsing, running and managing a shell process, font rendering, grid rendering, input handling (keyboard/mouse), etc. There are hundreds of relatively large sub-projects on the path to "done." ([View Highlight](https://read.readwise.io/read/01h1ya6mmrtrf0h1hjq479xnzn)) - Instead, I try to think what a *realistic* project is where I can *see results as soon as possible*. Once you apply that filter, the number of viable sub-projects shrinks dramatically ([View Highlight](https://read.readwise.io/read/01h1ya7jheggbr1fz1gm8e8mwr)) - Note: I guess that’s one of the things that works well with the many little subprojects I use in [[GO GO GOLEMS]]. This also helps a lot with llm driven development - just kind of get an idea of the *rough shape* the project will take and find one that I can build in isolation and also physically see some sort of real results. ([View Highlight](https://read.readwise.io/read/01h1ya9z4fzd1r0mrpmpge0m4p)) - This is the phase where experience helps the most. Engineers with more experience are usually able to more effectively paint the picture of the rough shape a project will take ([View Highlight](https://read.readwise.io/read/01h1yaa1n95vy4xn9m17kp8gq2)) - Note: Critical insight, and this applies to llm driven development: decomposition, validation and knowledge of the pitfalls (which is related to the validation aspect). Similarly, knowledge of the solution space to quickly iterate and brainstorm . Validation also applies to being able to see results even with broken code, and thus be able to curate effectively and quickly . Experience also indicates which domains and cross pollinations to explore and try out - similarly can't see that work without writing a client along with a CLI or GUI. ([View Highlight](https://read.readwise.io/read/01h1yaakdwn8dqydmvpdg88k38)) - Note: This is why tasks that can be yamld it do nice for go go golems stuff, you can make the small visible and thus give it its right amount of fun and satisfaction - The best tool to get past this phase is automated testing (usually unit testing at this stage). Automated tests let you actually run some code and see it is working and also has the benefit of being good hygiene. ([View Highlight](https://read.readwise.io/read/01h1yacc7j07s1z9j5vj36rxnk)) - Note: That’s a good insight and warrants a ZK - Seeing the progression of "1 test passed", "4 tests passed," "13 tests passed" and so on is super exciting to me. I'm running some code I wrote *and it's working* ([View Highlight](https://read.readwise.io/read/01h1yadp31kc2s5nmghz2nst31)) - 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* ([View Highlight](https://read.readwise.io/read/01h1yb3c8p2abtz8fkg7wbn56y)) - Note: Building something that has to be built for real work to happen is kind of the ultimate demo. Also #zk entry - I think this is an important tradeoff so I will repeat it: **do not let perfection be an enemy of progress.** ([View Highlight](https://read.readwise.io/read/01h1yb66ccwp428k4s3thy2ywt)) - Note: You don’t know the proper abstraction until you build many things with it, see glazed middleware or parka handlers or the command abstraction - No matter what I'm working on, I try to build one or two demos per week intermixed with automated test feedback as explained in the previous section. ([View Highlight](https://read.readwise.io/read/01h1yb7fbcp9myw99zkwmv558x)) - Note: Im not sure if I do that this quickly, I guess it really depends on the definition of demo. I definitely close Tickets quickly or try to, except maybe when refactoring - 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. ([View Highlight](https://read.readwise.io/read/01h1yb9b11x3sf5wfm913x6fwb)) - Note: Very good insight. Link this to the concept of yeet code which might also warrant a blog post