I’ve been trying to avoid simply reposting other people’s stuff here and rather generate more original content. However, some things, like this essay by Hitchell Hashimoto, I can’t help but write about.
My Approach to Building Large Technical Projects
This article illustrates the importance of having a process. This is critical at both a personal, team, and organizational level – at least when building complex systems. Projects we work on are too large to complete in one day or by one person, so a process that allows us to make incremental progress and stay motivated is critical.
Do you know your personal process? Is it documented? Are you willing to share it here?
Notable points:
I think this is an important tradeoff so I will repeat it: do not let perfection be an enemy of progress. Going further, do not let future improvements you know you’ll have to make stop you from moving on to the next thing. The goal is to get to a demo.
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.
Building a demo also provides you with invaluable product feedback. You can quickly intuit whether something feels good, even if it isn’t fully functional. These aren’t “minimum viable products”, because they really aren’t viable, but they’re good enough to provide an engineer some valuable self-reflection.
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.
We’ve also talked about this in 🎙️ Episode #20 -- The Power of the Demo.
build only what you need as you need it and adopt your software as quickly as possible.
I think that helps show how much of a personal process this is. Everyone I think needs to find some process to reinforce their motivation in a healthy way. I realized seeing results motivates me really strongly, I’ve built my work style around that, and it has worked well for me thus far.
Ironically, my preferred method of learning is to read reference material cover to cover, which is pretty much the exact opposite of the way I approach building something
This last point reminds me of The career-changing art of reading the docs.