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.

https://alexwennerberg.com/permacomputing.html

Comments URL: https://news.ycombinator.com/item?id=47759977

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47630699

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46791684

Points: 9

# Comments: 0

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!

Comments URL: https://news.ycombinator.com/item?id=46772966

Points: 79

# Comments: 53

Comments URL: https://news.ycombinator.com/item?id=46769188

Points: 249

# Comments: 152

Both are bad. Just use text.

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

> 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."

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)

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