The ability to endure some degree of suffering seems essential for building high quality products. Getting in front of the customer as often as possible and proving things end to end is very painful. But it provides the most feedback and gets you aligned quickly.
If you want an example of the polar opposite, the TDD idea seems to be a good fit. Unit tests are a perfect little universe that you can always control. All side effects and scary possibilities can be handwaved away under mocks. The psychological power of having control over everything is what draws so many toward the idea. A deterministic guarantee that the little circles will turn green when you press play every time is painless.
Failing tests are the most informative and you can only develop those by meaningful interaction with the customer's requirements. If you aren't constantly fighting a wave of red in your testing suite, it's likely you are too isolated from reality.
TIL that this (or rather, the lack of this) is why some pages show that annoying "do you want to resubmit your post" notification, but not others, and the name for it. Thank you!
It's amazing how often highly-polished web infrastructure gets put into the trash in pursuit of narrow objectives like avoiding a full page load. Very few applications actually benefit from being a single page. You tend to lose a lot more than you gain in terms of UX.
I feel like we already have enough abstractions in this space. Having any constraints at all in your tools is actually a good thing. PRs on top of ordinary git was a good step. This seems like one too many.
I honestly don't even get the PR addiction. Github has shaped devs workflows way too much. My best experience with git was when I realized that I can just have an blatantly simple workflow and explain it even to the junior-est dev in a few minutes. The reliance on github is somehow telling me that people stopped thinking about things they can actually control.
I don't understand the urgency around quantifying every aspect of the software process. Surely, we are in agreement that money in must at least equal money out if the company is to be viable? This is a simple quickbooks report, is it not?
Why don't we instead focus our energies on the customer and then work our way backward into the technology. There are a lot of ways to solve problems these days. But first you want to make sure you are solving the right problem. Whether or not your solution represents a "liability" or an "asset" is irrelevant if the customer doesn't even care about it.
Why don't we instead focus our energies on the user. For some very important software applications the customer is not the user. Let the sales department focus on the customer.
The hospital information system Millenium from Oracle was bought by two regions in south of Sweden for around 400 million USD. It turned out to be unusable for Swedish healthcare and had to be shut down after just three days. Actual users of the software (doctors and nurses) were not involved in the procurement.
I've got a dual path system to keep costs low and avoid TOS violations.
For general queries and investigation I will use whatever public/free model is available without being logged in. Not having a bunch of prior state stacked up all the time is a feature for me. This is essentially my google replacement.
For very specific technical work against code files, I use prepaid OAI tokens in VS copilot as a "custom" model (it's just gpt5.4).
I burn through maybe $30 worth of tokens per month with this approach. A big advantage of prepaying for the API tokens is that I can look at everything copilot is doing in my usage logs. If I use the precanned coding agent products, the prompts are all hidden in another layer of black box.
I'm with you on the ethical part, but everything is a spectrum. All the AI leadership are some shade of evil. There's no way the product would be effective if they weren't. I don't like that Sam Altman is a lunatic, but frankly they all are. I also recognize that these are massive companies filled with non shitty engineers who are actually responsible for a lot of the magic. Conflating one charlatan with the rest of it is a tragedy of nuance.
Yeah, but there's distinct difference between "risks their company because they refuse to help with killing little kids" and "happily helping with genocide".
This is mostly about thread communication. With SQLite you can guarantee no context switching. Postgres running on the same box gets you close but not all the way. It's still in a different process.
You hold them accountable.
Once upon a time we used to fire people from their jobs for doing things poorly. Perhaps we could return to something approximating this model.
reply