> So making your code 100x faster saves you more than 100 servers.
Yeah, but "making your code 100x faster" might cost significantly more than just adding 100x servers.
As with most things, the only absolute rule is "it depends".
Yeah, but "making your code 100x faster" might cost significantly more than just adding 100x servers.
As with most things, the only absolute rule is "it depends".
We need a commitment from all the (supposedly) environmentally conscious SV companies to pick optimization if given a choice between making the software faster and just throwing more computers at it. That would be relevant and meaningful, not just the usual "our office AC isn't set as cold as possible, so we are green"
My comment was aimed more at the hypocrisy of claiming to be green and then skipping the obvious savings in optimizations.
As a policy, though, it makes sense - tax the environmental externalities appropriately to reflect the actual shared cost. If it’s still economic to add the servers once those costs are factored in, then you wouldn’t have any grounds to complain.
Just design the tax regime so that it is high usage users who are paying the high costs, and exclude any usage levels that would impact homes, small businesses, and "normal" acceptable uses.
I agree that tax policy is more complex than just "tax the shit out of it", but everytime a tax is proposed, there comes a group of people who argue that taxation is so complex that we can't possibly grok it. That is clearly not the case.
I guess only the very radical greens would want to stomach that backlash...
Moreover, there are other considerations. If you're spending too much time on optimization, the company may not survive... leading all the work done to potentially go to waste. What about the environmental impact of waste there?
Cost? No. But it certainly requires more talent.
Unfortunately, programming talent doesn't scale with cost at all. In that it's like a creative endeavor: you can hire 10000 "professional writers" if you want, but that won't get you another Shakespeare.
Which is why I find the "software engineer" moniker silly. Software isn't at all like engineering.
So in the end, it is more about attitude, not talent.
The bulk of the work, in my experience, is simpler than the programming part. It's just a culture/priority thing. Like how most of the industry used to not use source control. Now we do, we didn't need to add "talent" to get that done either.
Those computers were an order of magnitude slower. Yet many equivalent apps today run at about the same speed.
Performance is not being prioritized. And I suppose back then, devs had no choice given the resource constraints they had.
I've seen many times devs paying for larger databases instance without first even taking a few hours to try and optimize their queries.
...is a scotsman that doesn't exist.
Talented people usually cost a lot to optimize your code to be faster. And the more time they spend optimizing existing code, the less time they spend writing new code.
And faster code in existing places can unlock new business opportunities which can unlock more money.
From Wikipedia:
> When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_en...
There's a considerable debate about when and where this term was "invented", apparently with some oral histories placing it even into (late?) 1950s.
As for grandparent's comment, I think it was referring to the fact that the nature of the job is completely different. For example a large portion of a traditional engineer's job deals with fighting the natural world. A bolt may rust away and stop doing what it was doing until then. A source code line in the form of
a=a+7;
That's a forced metaphor as well, not actually an identical process. If "requirements change", that's not the same thing as a bolt rusting away. Surely the requirements for the rusting bolt didn't change, or the requirements for its "dependencies", i.e., the things it's attaching together.
> I've had to deal with some (functional) languages that don't allow you to change the the variable where some would allow that sort of modification just fine for your simple example.
I completely fail the relevance of that. Or maybe it is somewhat relevant, but in the completely opposite way, i.e., that this phenomenon does not even have an analogy in the physical world, thus underlining the vast differences between software engineering and classical engineering disciplines. (Likewise the dichotomy between a computational procedure and the process generated by said procedure, the latter being constrained in the way you describe, doesn't exist in traditional engineering either.)
It doesn’t matter if they’re a 10xer or a 1xer, their time always has a price tag.
American salaries sound great.
Project management methodologies like scrum are implementation level details, together with platform (user interface, programming language, database e.t.c). Software Engineering starts at the feasibility study, followed by detailed design, then comes the implementation phase. Most Software Engineering job posts only list implementation phase requirements, which I reckon has led to SE being misunderstood.
Servers can also go down, but the 100x faster code will remain the same.
Otherwise we would all be writing assembler.
Humans are way, way more expensive than servers in almost every case. Exceptions might be small pieces of code ran by millons of devices, but that's far from being the common case.
But I agree with the sentiment. In a code base where performance matters, that level of optimization would often be impractical.