> 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.
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.
> 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!
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.
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.
sf, ca
[email protected]