6 ms·

The text resonates with me but there isn't much practical advice. What should I do as a normal developer working on normal business products? I try not to do

The text resonates with me but there isn't much practical advice. What should I do as a normal developer working on normal business products? I try not to do obviously slow and stupid stuff but it is not the main focus. It does mention it but just to reiterate: The business value of getting things out is larger than getting things right most of the time. The architecture are bloated micro-services, the infrastructure is overcomplicated, the response times are order of magnitude longer than they ought to be. But there is no time to care. The next shiny feature or integration or whole business case is waiting to be implemented and shipped. We cannot afford to spend time on improving things people don't complain about over things that bring more money. I guess that is where the disenchantment part comes in. Most companies are not in business of engineering stuff well if that is not what makes them money.

nine_k 4y ago
Developer's time is much more expensive than CPU's. So much more CPU's time is spent ("wasted") to save some amount of developer's time. This includes developer's s study time, that is, hiring less educated and experienced developers. In 1990s we had a similar effect: the CPU performance and RAM sizes grew so rapidly that "poorly written" and "bloated" software became "butter-smooth" and "lightweight" in a couple of years. Now we have the cloud instead, when spinning a dozen more instances or upgrading to a slightly more expensive plan gives the performance boost that solves many bottlenecks (much) cheaper than paying a team of 3 developers to spend 6 extra months to do things right. The endless CPU growth gravy train stopped in mid-2000s. I wonder when the endless cloud scaling train will slow down materially.
- bbbobbb 4y ago
  It's not just dev time vs cpu time. The thing the article mentions and what I was trying to echo is that software is slow and overcomplicated despite that. It would be unusable without fast hardware. But people are used to programs being slow and bloated. People and companies are rarely willing to pay premium for efficient programs. So here we are, gluing stuff together so that we're fast to market with every next feature while collectively wasting lifetimes as our apps load and perform basic actions. I am not even saying it's wrong. There are plenty of things I'd rather have now and slow than later/never and fast. Nor I am saying given the time I'm capable of making all our software significantly leaner and faster. I am just echoing the disenchantment and some frustrations.
  - camgunz 4y ago
    The other day I noticed (again) the shadows macOS draws around focused windows, and I thought to myself "if I could turn that off and get .003% battery life back, I would 100% do it". I would never have thought that if I hadn't used Linux (or another FOSS *NIX), where you can customize things down to modifying the code yourself. Hell I had a window manager for a while where the way to customize it was to edit the code and recompile it. That Alan Kay quote "...because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that Guitar Hero is the same as a real guitar" really summarizes the thing best I think, but the whole interview [0] really fills out the sentiment. People may or may not think they're "computing" or whatever, but there's a kind of tug of war between mindlessly shuffling around spreadsheets and slide decks and trying to create something that meaningfully improves peoples' lives. Blame whatever you want for this: - we don't factor in pollution externalities into costs, so Electron (and web) apps are commercially viable despite their high energy use - tech oligopolies do illegal things to squelch competition, so competing organizations are in a race to the bottom re: efficiency, dark patterns, addictive features (building "engagement"), etc.; see Writely (Google Docs) vs. MS Office, etc. - in capitalism you solve everything with money, and money washes away all sins, so all other concerns (efficiency, civil rights, etc.) are mooted - there's essentially no useful social safety net in the US, and one of the consequences of this is that we need full employment programs for the middle class, who subconsciously know this and put pressures on the market not to obsolete them (no need for humans to captain Excel around anymore), but to let them burrow more deeply into enterprises (make Excel more and more powerful and complicated such that only humans trained over years can use it). This is analogous to the dynamic medical companies face: treatments make you rich, cures make you bankrupt. [0]: https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-and-technology-now https://www.fastcompany.com/40435064/what-alan-kay-thinks-ab...
    - abecedarius 4y ago
      > we don't factor in pollution externalities into costs Suppose this is solved and it turns out your local electricity price literally doubles from $0.10/kW-hr to $0.20. Suppose your Electron app adds 10W to what you'd otherwise use, for 10 hours/day. Your power bill just went up by 1 cent per day, almost unnoticeable to an individual. I actually agree that to understand why the software ecosystem is screwed up in the ways it is, we should be looking for the economic/legal/otherwise systemic incentives driving the patterns. But that's different from "I can think of a way the world is bad according to my politics, that must be it."
- ratww 4y ago
  If developer time were really such a huge priority, we would also prioritise moving away from slow-ass compilers/transpilers, frameworks so slow that affect local development, slow IDEs and developer tools, slow CIs. And yet we don't, because inertia rules the industry.
svachalek 4y ago
In terms of engineering well, it's really more about doing the right thing at any cost than the wrong thing at optimal efficiency. In some sense we could say that rapid evolution of solutions is therefore focused on the right problem, much more so than navel-gazing on millisecond timers or big O estimates. Well, in an ideal world. In the actual world, we're using really inefficient software to direct someone to your driveway with a tank of gas because you didn't feel like stopping at a gas station. But I still feel like I had a point in there somewhere.
- bbbobbb 4y ago
  I don't disagree. It's just that there is rarely time to revisit and improve the right things that work. Often it's left as is (in this context inefficient) and the business moves to the next 'experiment'. The end result tend to be a portfolio of sluggish features.

nine_k 4y ago

Developer's time is much more expensive than CPU's. So much more CPU's time is spent ("wasted") to save some amount of developer's time. This includes developer's s study time, that is, hiring less educated and experienced developers. In 1990s we had a similar effect: the CPU performance and RAM sizes grew so rapidly that "poorly written" and "bloated" software became "butter-smooth" and "lightweight" in a couple of years. Now we have the cloud instead, when spinning a dozen more instances or upgrading to a slightly more expensive plan gives the performance boost that solves many bottlenecks (much) cheaper than paying a team of 3 developers to spend 6 extra months to do things right. The endless CPU growth gravy train stopped in mid-2000s. I wonder when the endless cloud scaling train will slow down materially.

bbbobbb 4y ago
It's not just dev time vs cpu time. The thing the article mentions and what I was trying to echo is that software is slow and overcomplicated despite that. It would be unusable without fast hardware. But people are used to programs being slow and bloated. People and companies are rarely willing to pay premium for efficient programs. So here we are, gluing stuff together so that we're fast to market with every next feature while collectively wasting lifetimes as our apps load and perform basic actions. I am not even saying it's wrong. There are plenty of things I'd rather have now and slow than later/never and fast. Nor I am saying given the time I'm capable of making all our software significantly leaner and faster. I am just echoing the disenchantment and some frustrations.
- camgunz 4y ago
  The other day I noticed (again) the shadows macOS draws around focused windows, and I thought to myself "if I could turn that off and get .003% battery life back, I would 100% do it". I would never have thought that if I hadn't used Linux (or another FOSS *NIX), where you can customize things down to modifying the code yourself. Hell I had a window manager for a while where the way to customize it was to edit the code and recompile it. That Alan Kay quote "...because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that Guitar Hero is the same as a real guitar" really summarizes the thing best I think, but the whole interview [0] really fills out the sentiment. People may or may not think they're "computing" or whatever, but there's a kind of tug of war between mindlessly shuffling around spreadsheets and slide decks and trying to create something that meaningfully improves peoples' lives. Blame whatever you want for this: - we don't factor in pollution externalities into costs, so Electron (and web) apps are commercially viable despite their high energy use - tech oligopolies do illegal things to squelch competition, so competing organizations are in a race to the bottom re: efficiency, dark patterns, addictive features (building "engagement"), etc.; see Writely (Google Docs) vs. MS Office, etc. - in capitalism you solve everything with money, and money washes away all sins, so all other concerns (efficiency, civil rights, etc.) are mooted - there's essentially no useful social safety net in the US, and one of the consequences of this is that we need full employment programs for the middle class, who subconsciously know this and put pressures on the market not to obsolete them (no need for humans to captain Excel around anymore), but to let them burrow more deeply into enterprises (make Excel more and more powerful and complicated such that only humans trained over years can use it). This is analogous to the dynamic medical companies face: treatments make you rich, cures make you bankrupt. [0]: https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-iphone-and-technology-now https://www.fastcompany.com/40435064/what-alan-kay-thinks-ab...
  - abecedarius 4y ago
    > we don't factor in pollution externalities into costs Suppose this is solved and it turns out your local electricity price literally doubles from $0.10/kW-hr to $0.20. Suppose your Electron app adds 10W to what you'd otherwise use, for 10 hours/day. Your power bill just went up by 1 cent per day, almost unnoticeable to an individual. I actually agree that to understand why the software ecosystem is screwed up in the ways it is, we should be looking for the economic/legal/otherwise systemic incentives driving the patterns. But that's different from "I can think of a way the world is bad according to my politics, that must be it."
ratww 4y ago
If developer time were really such a huge priority, we would also prioritise moving away from slow-ass compilers/transpilers, frameworks so slow that affect local development, slow IDEs and developer tools, slow CIs. And yet we don't, because inertia rules the industry.

svachalek 4y ago

In terms of engineering well, it's really more about doing the right thing at any cost than the wrong thing at optimal efficiency. In some sense we could say that rapid evolution of solutions is therefore focused on the right problem, much more so than navel-gazing on millisecond timers or big O estimates. Well, in an ideal world. In the actual world, we're using really inefficient software to direct someone to your driveway with a tank of gas because you didn't feel like stopping at a gas station. But I still feel like I had a point in there somewhere.

bbbobbb 4y ago
I don't disagree. It's just that there is rarely time to revisit and improve the right things that work. Often it's left as is (in this context inefficient) and the business moves to the next 'experiment'. The end result tend to be a portfolio of sluggish features.