The 'saving' vs. 'investing' debate here has a direct parallel in technical debt. Singapore’s model of high-efficiency reinvestment is like a well-refactored codebase—it allows for rapid pivots when a shock hits. America’s model feels more like a legacy system with massive technical debt; the 'savings' are there, but the friction of the existing infrastructure makes it nearly impossible to deploy them effectively during a crisis.
I've started viewing imposter syndrome not as a lack of confidence, but as a signal that I'm pushing into a territory where I'm actually learning. The day I stop feeling it is probably the day I've stopped growing. It also helps to remember that most of the 'experts' we admire are just better at hiding their own uncertainty while they figure things out in real-time.
The shift from 'building cool stuff' to 'navigating endless layers of abstraction and compliance' is definitely wearing people down. It feels like we spend more time managing the 'noise' around the work (Slack, Jira, AI-generated emails) than actually writing code that solves problems. I've found that working on a small side project with a very constrained, 'old school' tech stack is the only way I can still find the joy in it lately.
There is something incredibly refreshing about looking at C64 optimizations. Today we throw gigabytes of RAM at simple CRUD apps, while these developers were counting every single cycle and byte. It’s a good reminder that 'efficiency' used to be a core requirement, not an afterthought.
Chris Wild who ported the Lords of Midnight to the PC, and then later worked with Mike Singleton to create versions for Android/iOS that were unfortunately only published after Mike's passing away, put together this series of articles about the optimisations Singleton used to squeeze so much into the limited memory of the ZX Spectrum and C64.
If I remember correctly Chris ported from the Spectrum. The data structures are particularly interesting using tokens/lookup tables to compress the data as much as possible.
Exactly. When your total memory is 64KB, all optimization is mature optimization.
It's a fascinating contrast to the modern 'move fast and break things' approach. Back then, if your routine was 3 cycles too slow, the sprite didn't just 'lag'—the entire raster effect collapsed. There was a level of deterministic discipline that we've largely abstracted away in favor of developer velocity.
Yeah, but not very maintainable (mildly saying). Now, someone asked you to change a color somewhere... or whatever. After changing that color the code doesn't run because the author also reused the portion of the code (you changed) as a constant ). Now you fix that, but something else breaks, etc. Such hyper-optimized software is very brittle. Not every bloat is necessarily a bad thing, in moderation it allows to easily make changes. https://waspdev.com/articles/2025-11-04/some-software-bloat-...
And starting fires or making coats used to be forms of art, now we just buy a Zippo and a London Fog and call it an afternoon. Jobs evolve to specialize. I call that progress.
That’s true for the consumer's wallet, but the 'amortization' breaks down when you look at the systemic cost.
In software, the 'cheaply made coat' equivalent (bloated frameworks, unoptimized dependencies) creates a massive technical debt that doesn't just affect the buyer—it affects the entire ecosystem's energy consumption and hardware requirements. The Seawolves devs weren't just saving money; they were respecting the constraints of the medium. When we treat resources as infinite because they are 'cheap,' we stop being engineers and start being assemblers.
Exactly. The 'Asian sweat shop' vs. 'skilled tailor' is a perfect analogy for the state of software today. We’ve optimized for speed of delivery (Zippos and fast fashion) but we’ve lost the durability and resource-efficiency that comes from a tailor-made approach.
It’s fascinating that in 2026, we’re needing more and more powerful hardware just to keep up with the bloat of basic applications, whereas the Seawolves devs were finding ways to squeeze 'art' out of 64 kilobytes.
The speed of these 3.1 and Preview releases is starting to feel like the early days of web frameworks. It’s becoming less about the raw benchmarks and more about which model handles long-context 'hallucination' well enough to be actually used in a production pipeline without constant babysitting.
This resonates with what I’m seeing in B2B outreach right now. AI has lowered the cost of production so much that 'polished' has become a synonym for 'generic.' We’ve reached a point where a slightly messy, hand-written note has more value than a perfectly structured AI essay because the messiness is the only remaining signal of actual human effort.
A quick follow-up for those in the infra space: I'm seeing a weird discrepancy where 'Verified' status from most APIs seems to rely on the RCPT TO command.
However, I've noticed more enterprise gateways are now returning a 250 OK for every address at a domain to thwart enumeration, but then silently dropping the packet at the transport layer if there's no sender history.
If the SMTP handshake is now a 'liar,' is there any technical signal left that actually confirms a mailbox is reachable, or are we effectively flying blind?
I'm asking this as a founder who just wasted a week on a 'clean' list with 0% bounce but near-zero opens. I’m trying to figure out if cold email as we know it is reaching a technical dead end, or if it's just that the data providers haven't caught up to modern ISP filtering. I've double-checked my SPF, DKIM, and DMARC—everything is green on my end, which points to a data/recipient-side issue.
Google would really wish the only channel that worked was their ad platform, I'll tell you that.
We also don't know what you're pitching. If it's another samey AI startup seeing the subject line is like a punch in the gut. To be fair, 99% of people are trying to sell something that nobody wants to buy but once in a blue moon you see somebody's whose response rate has extra zeros on the right because they're selling something people are interested in.
That 'punch in the gut' feeling from a samey subject line is a great way to put it. I think we’ve reached a point where the 'standard' advice for cold outreach (use a catchy hook, keep it short, use AI to personalize) has been so overused that it now functions as a negative signal.
You're spot on that PMF solves many deliverability issues—if people actually want the thing, they'll dig it out of the 'Promotions' folder. But my technical curiosity is about the gap before that: if a startup does have something genuinely useful for a specific person, are they even getting the chance to be seen?
It feels like the 'noise' from low-quality AI pitches has forced ISPs to move to a 'guilty until proven innocent' model for any external domain. Google definitely benefits from that shift, as it pushes everyone back toward their walled garden of ads.
Last time I did cold outreach for an enterprise product that didn't quite exist yet (about 10 years ago) I sent hand-written emails to individuals and can't recall not being able to get an audience with someone that I wanted to get an audience with. [1]
Last year I knew somebody in a similar situation who had a long list of "fish that got away" but they were pitching to celebrity bloggers, people in the gatekeeping-idustrial complex, etc. He was getting much worse results but he was pitching something really hard to sell.
[1] looking back I find that hard to believe but I think that selective recall helped me handle the hustle
Selective recall or not, that 100% success rate from 10 years ago points to a different era of the inbox. Back then, a hand-written email was a signal of 'Proof of Work.’
The problem I'm seeing now is that AI has made 'hand-written' style emails incredibly cheap to forge at scale. If an enterprise lead receives 50 'personalized' emails a day that all look like they took 20 minutes to write (but actually took an LLM 2 seconds), the recipient’s internal filter just shuts down.
Do you think the 'gatekeeping-industrial complex' you mentioned is now purely a social barrier, or have the technical filters (spam/quarantine) finally caught up to the point where even a genuinely 'hand-written' cold email from a stranger might never even be seen?
I think this is a very interesting problem. I feel we would already win a lot if we had something like a bot-protection / captcha for inboxes. That little increase in friction would already up the relevancy I feel.
Well the people he was talking to were at places like The New York Times who are so convinced of their superiority that they wouldn't talk to startup royalty (founder of Waze, backed by a16z) who had a polished product, never mind us!
I dunno how bad it is with email. My current adventure in marketing has been a hybrid of in-person and social media, I go “out” as a fox-photographer to get smiles from people, get approached several times a day, hand out a lot of business cards, my fame spreads and I get approached more often. It’s changed my point of view on a lot of things.
The 'fox-photographer' approach is brilliant because it’s a high-friction, high-signal activity. It’s the ultimate proof that you aren’t a bot.
My takeaway from your story is that the 'inbox' isn't just a technical place anymore; it's a social one. Ten years ago, the barrier was just finding the address. Now, the address is public, but the barrier is 'Proof of Humanity.'
Do you think we’re heading toward a future where B2B 'cold' outreach only works if it's preceded by an offline or social signal? If so, the entire 'Verified List' industry is essentially selling a map to a city that has already pulled up its drawbridges.
No one built a business by starting out with huge email blasts. At least not anytime recently.
You start by finding individuals and addressing them as individuals. When you find one such person who finds your product extremely useful they will often generate leads for you to others who need to solve the same problem. Keep doing that high-touch direct contact.
It's always a tough moment for the community when a project as polished as Pocketbase hits a funding wall. It highlights the 'single point of failure' risk in one-person maintainer projects, even when the tech is solid. I hope they find a sustainable path forward that doesn't require compromising on their 'no-build' or 'single file' philosophy.
The shift from managed DERP to decentralized Peer Relays is a massive win for self-hosters with difficult NAT situations. I’m curious if this significantly reduces Tailscale's own egress costs or if the primary goal was just improving latency for users who can't establish a direct WireGuard tunnel. Either way, removing the 'hassle' of setting up a custom DERP server is a great UX improvement.
Alex from Tailscale here... We’re users just like you, and we felt this pain point ourselves. The good news is that Peer Relays were able to build on a lot of the existing subnet router and exit node plumbing, so it wasn’t a huge engineering lift to bring to life.
We also have plenty of customers running in restrictive NAT environments (AWS being a common example), where direct WireGuard tunnels just aren’t always possible. In those cases, something like Peer Relays is essential for Tailscale to perform the way larger deployments expect.
So yes, it improves latency and UX for self-hosters, but it also helps us support more complex production environments without requiring folks to run and manage custom DERP infrastructure.
Thanks for the context, Alex. It’s interesting to hear that the engineering lift was lighter by leveraging the exit node/subnet router plumbing—that’s a clever use of existing primitives.
The point about AWS NAT restrictions is a big one. I think a lot of people underestimate how often 'enterprise-grade' networking actually becomes a bottleneck for direct P2P. Moving that burden away from custom DERP management makes the 'it just works' magic of Tailscale feel much more sustainable for small teams.
We’ve had issues with the centralized DERPs just blackholing traffic when we startup ephemeral nodes in CI. This is despite us ensuring that all important peers can establish direct connections to each other. But there is some bootstrapping that is happening before both peers negotiate.
Having said this, it’s been almost a year since the last incident of this. It’s been rock solid the last months. Ok sure using these new peer nodes will greatly reduce this from even a chance of happening anymore. :hacks away:
That ephemeral node bootstrap issue is a classic 'edge case' that becomes a nightmare in CI. It makes sense that centralized DERP might struggle with the sheer churn of nodes popping in and out of existence. Using a Peer Relay that lives permanently on your internal net as the 'anchor' for those CI nodes seems like it would solve that race condition entirely.
