"Software has really interesting economics where as the cost/feature decreases by a factor, say 1x, then the set of features that can be profitably worked on expands by like 10x." This is such counterintuitive insight that I admit I had not thought of until I read the comment, yet it's so true.
Finding time to work on a hobby project is among one of the hard things about doing one. What makes it harder is the context you lose between the time you work on it. And when it comes to a reasonably sized project -- anything bigger than something you could complete over a weekend, with some degree of complexity that requires some planning and system design -- losing the context that was once fresh in your head could also mean losing interests/passion and abandoning ship.
Since I only code in Svelte occasionally, one of the things that always gets me is how Svelte handles reactivity with stores.
I ran into what might be my first Svelte bug when working on the Big2 card game project. I remain a fan of Svelte, but nevertheless it's good to keep in mind that when you use a small framework, you're bound to run into actual bugs in the framework.
I open sourced the framework that powers this blog, and called it Miner. It's based on Sapper, the web app framework based on the Svelte UI framework.
One of the things I've thought about briefly over the past few years is what joining a company as a CTO (or a VPE) is like. My experience in tech has mostly been either working my way up within a company, or founding a startup as a technical cofounder and being a CTO that way.
Recently, Ellen shared the following article on engineering leadership with the group: The Engineer/Manager Pendulum. I found it really insightful and echoing a lot of thoughts I've had, but hadn't been able to articulate.