We should be more ambitious with the software we build

This statement stood out to me. > I have a similar thought about "there's no reason for software to be slow" BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize, perf-wise, for all the use cases you should care about, nor will be maintainable upon future changes. LLMs have hardened hundreds of apps where I work. Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so. Ofc, if you have: - Functional tests - you'll be able to see it in the execution times of specific APIs - Stress testing - performance profiling is the most important output artifact

More than ambitious, I can now build things I had no time for but had the idea and architecture in place since long. A cool side project for me recently has been to allow reading more than books on my Kobo reader. I built an SDK and apps that allows e-ink apps with sandboxing and permissions model, auto-updates, shared capabilities etc. to be built for Kobo https://github.com/BandarLabs/Cobalt

We should be more diverse with the software we build. Any prompt jockey can make a faster ripgrep. The spec is "faster ripgrep". What is the one thing that only you can specify, where your competitive advantage is maximized? Find that thing and pursue it with all your energy!

I think it's worth remembering that outside of our bubble the quality of software is pretty bad. I had a Hitachi heat pump (not recommended) installed earlier this year, and the software is pretty disappointing. It mostly works, but there are so many undocumented features and hard coded values that should be a configuration option but are not. For example when the heat pump reaches the target temperature it shuts off, then after 3 minutes switches on again. To prevent short cycling, I'd like to decrease the time between runs (so increase the 3 minutes) but that can't be changed. Somebody decided that 3 minutes is the correct value for everybody and that's it. I bought a €400 interface box (basically just a serial to IP interface, I guess $20 of hardware tops) to try and improve it. The €8000 heat pump doesn't come with WiFi or ethernet out of the box, you need to buy an accessory for that. It's not made by Hitachi, but it's an officially recommended accessory. One of what feature I wanted it for - which is advertised in their marketing materials - doesn't work. I emailed them, and they said it's probably because the display I have is a newer revision and doesn't allow access to the setting I need to turn on. And without turning that setting on I can't use the feature as advertised. They said I should email Hitachi and talk to them instead as it's not their part that's the issue. I look forward to the world where all software is either open source, or at least reverse engineerable to the point where you no longer have nonsense like this.

With every new model I've been attempting to build something that takes at least 1 month and really pushes the model. So far I've done: - Python interpreter in Rust (fail): https://github.com/BlueBlazin/pyrs - Low-poly Google Earth like engine (success): https://github.com/BlueBlazin/lowpolyearth - Codebase -> 2d infinite-zoom visualization (success): https://github.com/BlueBlazin/blockviz I have never understood or liked all the obsession with one-shot builds.