An Introduction
Hello!
I’m John, and I’m mildly obsessed with how software (and hardware) gets built.
At $dayjob, I do safety critical embedded firmware and software. I like to think I’m a full stack developer - in the past I’ve worked on embedded bootloaders (in a car near you), Ruby on Rails webapps (back when server side rendering was cool), Next.js static sites (now, when server side rendering is again cool), React Naive iOS apps (I don’t have anything snarky to say here), and Android ROMs (back in my “I’m only going to run code I’ve built myself” punk phase) along with various bits of test, infrastructure, and glue code.
Though all of these, I notice one thing - building reliable software is HARD. The tug of war between new features and stability. Speed vs correctness. Process vs trust (in both people and systems). And this all doubles (or more) when you toss hardware into the mix.
It’s easy to spout platitudes: I’ve written plenty of “visionary manifestos” myself about the correct ™️ way to do software (and hardware) development. Hopefully this isn’t that.
I think how products get built - the nitty gritty day to day of managing people, changes, and expectations - is a fascinating topic, and I hope to explore this in public with y’all. [Editors note: This is extra funny because he has no subscribers yet.] Looking at the state of the art to whats missing, best practices versus how it actually works in a real organization. I think there’s value in summarizing, and narrating this space, in the hopes of educating and inspiring others to build the next generation of really cool shit.
In my dreams, the future is bright - continuously integrated hardware and software, enabling humanity to build faster and further than ever before. (Literally, I think robots produced in-situ in the asteroid belt would be sick.) Hopefully, I can get you on board, and we can build the future together.
- John
Sent from my iPhone