alexwennerberg

I do

I'm glad I stuck with SQLite. Governance is an important part of any open source project. SQLite has kept things narrow and focused, while DuckDB's philosophy is to do more and more, making it a general-purpose data science tool. I am old-fashioned in that I believe in the philosophy that software should "do one thing and do it well"

> Normal people overwhelmingly prefer AI design (and flattering, grandiose AI slop writing as well)

Everyone I have talked to universally hates AI design.

I don't have a problem with setting a few relevant flags for any new SQLite database. It's a good encouragement to familiarize yourself with the settings.

> Imagine you're a professional writer and it's your main source of income.

There are probably a few thousand of these in the entire United States. The market system heavily under-values writing as is, independent of piracy

> This is a common perspective on HN, but it's so jarring. Someone violates an open-source license and we grab our pitchforks. Someone pirates books and it's fine - really, the authors should be thanking us.

If the books were released under an open source license, there would be no problem here?

> But when you hit that wall, it is hard to stop and convince people to use different patterns and systems. I've seen so many tables go from "it will only be a few thousand rows" to suddenly several TB and then people are looking confused when performance and db admin tasks get really difficult.

It's much, much worse in my experience to have to develop for the opposite -- working on a system that was designed for an imagined "infinite" scale that in reality like 100GB and a few transactions a minute.

For any Bay Area folks, we have a permacomputing meetup. Planning on scheduling the next one, you can join the mailing list or RSS for updates

https://alexwennerberg.com/permacomputing.html

See you all there!

Large firms are extremely bureaucratic organizations largely isolated from the market by their monopolistic positions. Internal pressures rule over external ones, and thus, inefficiency abounds. AI undeniably is a productive tool, but large companies aren't really primarily concerned with productivity.

AI can produce elegant software but not on its own. It requires a human with taste to direct and guide it.

Odd. Hyphens used as though they were em-dashes, which I guess looks the same in a fixed-width font

> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.

This is perhaps what I find somewhat odd about Sean's writing. It sometimes reads to me like a scathing critique of the dysfunctional bureaucratic dynamics of big tech companies, but that isn't really his conclusion!

> Why are you sick of AI images, but you're not about stock images ?

Both are bad. Just use text.

The text reads suspiciously like AI too. I don't X -- I Y. Short paragraphs, lots of em-dashes.

> some people are happier in a high performance environment with employee churn, when it means having more talented coworkers

It means having coworkers who are constantly in competition with you for survival. It's a nightmare.

Lol thanks for reading my blog post! (Alex here) Your statement of my position:

> We live in a late-stage-capitalist hellscape, where large companies are run by aspiring robber barons who have no serious convictions beyond desiring power. All those companies want is for obedient engineering drones to churn out bad code fast, so they can goose the (largely fictional) stock price. Meanwhile, end-users are left holding the bag: paying more for worse software, being hassled by advertisements, and dealing with bugs that are unprofitable to fix. The only thing an ethical software engineer can do is to try and find some temporary niche where they can defy their bosses and do real, good engineering work, or to retire to a hobby farm and write elegant open-source software in their free time.

Let me re-state this in another way, which says functionally the same thing:

> Companies are hierarchical organizations where you sell your specialized labor for money. You should do what they expect of you in order to collect a paycheck, cultivate as enjoyable of a working environment as you can, then go home and enjoy the rest of your free time and your nice big tech salary.

Is this cynical? In some sense, sure, but I don't think it's inaccurate or even toxic, and I think it's probably how something like 90% of big tech employees operate. Sometimes your writing makes it seem like this is actually what you think. If your "objective description" of big tech companies were in service of this goal -- getting along better and not fighting the organization to preserve your own sanity and career -- I don't think people would take issue with it.

But you make the analogy of public service and seem in some sense to believe in values that are fundamentally at odds with these organizations. Is your position that, through successful maneuvering, and engineer can make a big tech organization serve the public in spite of internal political and economic pressures? This seems far more idealistic than what I believe. To quote Kurt Vonnegut, "We are what we pretend to be, so we must be careful about what we pretend to be."

This was an excellent explanation of a complex business problem, which would be made far more complex by splitting these out into separate services. Every single 'if' branch you describe could either be a line of code, or a service boundary, which has all the complexity you describe, in addition to the added complexity of:

a. managing an external API+schema for each service

b. managing changes to each service, for example, smooth rollout of a change that impacts behavior across two services

c. error handling on the client side

d. error handling on the server side

e. added latency+compute because a step is crossing a network, being serialized/de-serialized on both ends

f. presuming the services use different databases, performance is now completely shot if you have a new business problem that crosses service boundaries. In practice, this will mean doing a "join" by making some API call to one service and then another API call to another service

In your description of the problem, there is nothing that I would want to split out into a separate service. And to get back to the original problem, it makes it far easier to get all the logging context for a single problem in a single place (attach a request ID to the all logs and see immediately everything that happened as part of that request)

> Logs were designed for a different era. An era of monoliths, single servers, and problems you could reproduce locally. Today, a single user request might touch 15 services, 3 databases, 2 caches, and a message queue. Your logs are still acting like it's 2005.

If a user request is hitting that many things, in my view, that is a deeply broken architecture.

Thank you! I read this a long time ago and could never remember it, thinking it was Shopify that wrote it.

Does anyone have examples of organizations that have leveraged SQLite and written about their experience? I've read a lot of theory and benchmarks about it lately and it seems extremely impressive, but I'm wondering if anyone has written about pushing it to its limits "in production"

This isn't really what my article is about. I'm talking about workplace politics, ie, internal organizational corporate dynamics, not like, world politics.

I agree, "politics" exist in any human institution. The issue is when political maneuvering becomes the sole or primary role of a software engineer -- that is a symptom of dysfunction. The primary role of a software engineer should be software engineering.