Hacker News Reader

Comment by CoolCold | Hacker News Reader

From what I observe, developer prefer to stay in API abstractions than spending time on servers/other infrastructure. Partially I can understand their choice.

View on HN

What do you mean? The economics and decision-making are different between one-person companies through small and large organizations. When you have to know to to do everything, and fix anything, it is a problem when there is complexity, and you lack control. As organizations get larger, there is more value from abstractions and more leeway for their use.

In many ways it is a luxury to be able to use said abstractions and be able to open a ticket with someone else. Of course, a single-person startup could use the same tech, but it seriously impacts their costs and they don't have time to deal with the sprawl of abstractions.

I believe it’s the opposite? In a large org, you can have a dedicate team managing your servers. When you’re a one man business, you want to abstract as much as possible to focus on value proposition.

True. Although more often than not it's the opposite in my experience. Large organizations can afford to spend the money on GCP/aws/Azure and deploy thousands of services. They can also afford the money to hire infrastructure engineers to maintain such services. Also, in large companies everything needs to be implemented "the same way", so no matter if you want to deploy a tiny service or a huge one, you must do it the same way other services in the company are deployed.

Whereas when you are a one-man business, all you have is (free) time and prefer to spend as little money as possible while your business is not profitable. This means: walk away from dedicated databases, managed servers, huge aws bills, etc. You do everything "the old" way: rent a server (bare metal or cloud) and maintain it yourself.

In theory, a one-man business should "abstract as much as possible". In practice, it doesn't work out like this because you are responsible for everything about the business and it's easier to actually operate and maintain the relatively small number of bare-metal servers that run the business. Your advantage as a solo developer is that you can move fast at any time, and it's harder to do when you are encumbered with abstractions. That's not to say build versus buy isn't an evaluation that happens. There are strategic bets, maybe on analytics, or things that help, but aren't core to what you build.

This pattern plays out with many indie app developers as well, both now with iOS apps, and back in the day with Delphi shareware. The cost of taking a dependency on a 3rd party library turns out to be much higher for the solo developer than larger orgs. That's not to say they don't make bets, but they don't build the way that someone at a larger org would do because they have to maintain a higher degree of direct control.

Marco Arment (https://marco.org/) has elaborated a lot on this topic. You can also get a feel for the limits on the upper bounds of his developer experience. Many on HN are not willing to work at a low-level with such boring and dull technologies.

Reply on news.ycombinator.com