The catch: domain experts don't know what they don't know about shipping. The fix — vibecoders build it, dev team hardens it for production.
So I can't see the reason for the sarcasm. Different things.
The baker is happy and proud with what she could contribute to the worldwide bakers community and has made enough money that she and her family never need to worry again. There is just one problem: By now, she is getting old and none of her kids are interested in bakery or oven tech. She's also getting a steadily growing amount of offers to sell the rights to the brand.
Eventually, she caves and sells the brand and designs to BigOven. They promote her brand front and center and initially also use her design. But over time, BigOven replaces more and more parts with cheaper equivalents while keeping the overall look the same - until eventually, they replace the entire product with a stock design.
The bakers take a while to catch on (during which time BigOven makes a ton of additional money from the brand value) but eventually, the quality decline becomes impossible to ignore. Frustrated posts about corporate greed and enshittification make the rounds on the Italian forums.
"They don't make em like they used to" someone writes...
I’ve found that most people hate making tradeoffs. They don’t recognize that the things they do like don’t do everything.
So If you focus too much on a customer or worse an internal stakeholder who hasn’t designed or built things, it can became a Homer Simpson designing a car situation.
A wiser version of myself would have cut my losses after at most one year, or much sooner, especially after noticing the red flags. This is something I'm keeping in mind for my next gig.
i was definitely the another Engineer in my story.
In the article, the "smart" oven is only a speculation (maybe it works, and maybe someone will pay for it) and as such it is appropriate as a relatively low effort and low risk experiment on the part of an established oven maker (develop rudimentary automation and offer it as a very mildly disruptive feature at a modest price increase).
Which is a shame, because it makes those constructs less pleasant to read than they used to be. If you squint, and pretend AI doesn't exist (imagine!), then maybe you might be able to enjoy them again.
It is a little bit too long though.
If it didn't make more changes than you're aware of, then you should be aware that some features of your style are common amongst LLMs, and over-use of them will alienate some percentage of your audience (even if unfairly).
Key ones to look out for:
- Staccato prose: repeated runs of short sentences (e.g. "The founder nods. He gets it. He gets all of it.") - Negative pivots: anything with the structure of '!X; Y' (e.g. 'it’s not that nobody saw it: it’s that every week something jumped ahead of it')
These are valid linguistic features, but if you use them a lot, it sounds like AI writing, and people are wary of AI writing (because of the tidal wave of malicious, spamming & extractive actors using it). It will impact your audience.
I thought it might be intentional though? The first half reads very non-slop, and it just kind of inches its way in as the situation falls apart
These kinds of companies make hundreds of thousands or even millions a year. But it’s too small to hear about them.
Maybe we were saved by being acquired before hiring sales. Sai knew the problem & understood customers. He'd sometimes oversell a bit, but managed it: kept pulse of capacity for new development, would ask about how hard requested features were, would feel out customer intent & guide customer adapt to what was already there
When we had our pepepizza moment, there was an understanding that it wasn't going to work, took learnings of what would be involved there, but kept focus on improving what we already had
For kafka connector we had a design partner, I got to work with them directly. They wanted 30 microsecond message processing, so didn't want json. Original ask was flatbuffers. I decided to put message formatting into a scripting layer using gopher-lua. Spent a weekend getting flatbuffers working with lua (it was buggy, opened half a dozen PRs to flatbuffers repo which got ignored). It was clearly awful having to manage flatbuffer schema files & update scripts every time schema changed. But I had alternative already made: msgpack. Throughput needed work but addressed that by creating pool of lua interpreters
Overall I overworked myself (put my hands out of commission & spent months relearning how to type on split ergo colemak-dh), but I enjoyed the work. Team was very open with each other & when performance is your selling point there's an understanding that engineering quality needs to be maintained. Sure there were parts of the system I hated, & sometimes I'd try chip away at those
Hopefully that helps, hard to say the difference, but I really feel in my work that when customer has problem I'm part of conversation. Most recently there was talk of customer wanting cold data offloaded from postgres which is what inspired https://github.com/ClickHouse/pg_clickhouse/pull/298 where we get Postgres to do most the work
Raised problems trying to mix C++ into postgres extension, decided fix was to write clickhouse-c library to replace clickhouse-cpp, there was some doubt on team about value, but demonstrated value (https://github.com/ClickHouse/pg_clickhouse/pull/254) & I appreciate my colleagues not being afraid to change their mind
There's a level of trust where instead of being assigning tasks on a board I instead work on what I think is important based on information available. Nobody was asking for wal-rus, but I know my fleet
ClickHouse Cloud similarly took route of taking its time hiring sales. Better to have a small sales team that can work directly with engineering on quality leads than overwhelming everyone so that sales becomes the enemy. Guess the difference is agency. When engineering is involved in making commitments they're invested in delivering & there's push back so sales doesn't start hallucinating features