3 ms·

Could someone explain to me why so many people on here fetishize scale? Scale is a constraint on a problem, and it affects the solution you come up with. I don'

by ksk 10y ago

Could someone explain to me why so many people on here fetishize scale? Scale is a constraint on a problem, and it affects the solution you come up with. I don't understand why solving problems around that constraint is considered cooler than solving problems around other constraints like uptime, performance, memory cost, etc. Does "Our API serves 234 million requests" hold more cachet than "Our medical device firmware runs 24/7 without crashing and takes up 12 MB of RAM"?

gervase 10y ago
This is just a guess, but I suspect that "scale" also generally correlates positively with compensation. A medical device company with 50 employees just doesn't have the same resources as a company with 1M+ users, for example. Following from that, compensation is one of the easiest ways to measure professional "success", which is why large, highly-compensated companies are commonly viewed as the pinnacle of software engineering. Whether that's a fair or accurate assessment is a different question.
- ritchiea 10y ago
  Scale is also scarce. There are few companies operating at Google or Facebook or Amazon scale. You can't just create a product at scale if you want to gain the experience of scaling a product, you have to be working somewhere that grows tremendously.
framebit 10y ago
Scale is something of a measure of popularity. If our API serves 234 million requests per day, then presumably we're running something pretty popular and widely known. Because of the democratization of "big data" and the (relatively) recent uptick in large internet services, serious scale is an engineering challenge that a few have been tackling for awhile, but many are facing for the first time. Think any company that has recently realized their data needs are bigger than what Excel can handle.
tenpoundhammer 10y ago
In my experience it's a fun problem to solve. An engineer gets to design complex architectural solutions, acquire hardware, work with various database solutions, and generally work on larger problem domain than the problems you mentioned. Uptime, performance, and memory are all very important problems but you rarely get to venture outside of the current code base when solving those problems.
closeparen 10y ago
> uptime, performance, memory cost, etc. The joy I get from writing software comes from creating and using good abstractions. When optimizing for these things, you have to hang up all the fun toys, bring memory bookeeping to the forefront of the codebase, and abstain from nice language features / write things in obtuse ways to squeeze out performance. I'd much rather solve distributed systems problems with channels and futures and maps at my disposal, than make a C program even less readable for 5% more performance. Just taste, I guess. Distributed systems are a more interesting problem domain, to me, than throwing away all the nice stuff that's built for us and writing hand-tuned use-case-specific reimplementations. I'm sure both can be (and have been) taken too far.

by ksk 10y ago

gervase 10y ago

This is just a guess, but I suspect that "scale" also generally correlates positively with compensation. A medical device company with 50 employees just doesn't have the same resources as a company with 1M+ users, for example. Following from that, compensation is one of the easiest ways to measure professional "success", which is why large, highly-compensated companies are commonly viewed as the pinnacle of software engineering. Whether that's a fair or accurate assessment is a different question.

ritchiea 10y ago
Scale is also scarce. There are few companies operating at Google or Facebook or Amazon scale. You can't just create a product at scale if you want to gain the experience of scaling a product, you have to be working somewhere that grows tremendously.

framebit 10y ago

Scale is something of a measure of popularity. If our API serves 234 million requests per day, then presumably we're running something pretty popular and widely known. Because of the democratization of "big data" and the (relatively) recent uptick in large internet services, serious scale is an engineering challenge that a few have been tackling for awhile, but many are facing for the first time. Think any company that has recently realized their data needs are bigger than what Excel can handle.

tenpoundhammer 10y ago

In my experience it's a fun problem to solve. An engineer gets to design complex architectural solutions, acquire hardware, work with various database solutions, and generally work on larger problem domain than the problems you mentioned. Uptime, performance, and memory are all very important problems but you rarely get to venture outside of the current code base when solving those problems.

closeparen 10y ago

> uptime, performance, memory cost, etc. The joy I get from writing software comes from creating and using good abstractions. When optimizing for these things, you have to hang up all the fun toys, bring memory bookeeping to the forefront of the codebase, and abstain from nice language features / write things in obtuse ways to squeeze out performance. I'd much rather solve distributed systems problems with channels and futures and maps at my disposal, than make a C program even less readable for 5% more performance. Just taste, I guess. Distributed systems are a more interesting problem domain, to me, than throwing away all the nice stuff that's built for us and writing hand-tuned use-case-specific reimplementations. I'm sure both can be (and have been) taken too far.