5 ms·
For many of us, running our code 1 billion times will cost less than a few minutes of a developer's time. Hell, I could spend $200 for a month of server time o
by smt88 3y ago
For many of us, running our code 1 billion times will cost less than a few minutes of a developer's time.
Hell, I could spend $200 for a month of server time on AWS and run a lot of my (web API) code 100 billion times.
Optimizing for human readers is always better until you're working on something that proves itself to be too slow to be economical anymore.
- krab 3y agoIn my experience, you need to care about latency. That affects user experience. It's quite hard to pay for better latency.
- groestl 3y agoYou do that by paying for better developers ;)
- rezonant 3y agoThat depends on the application and the use case, but good performance and good readability aren't mutually exclusive. Easy to read software might not always be the most performant, but it's far easier to improve performance in an easy to read codebase than it is to make a hard to read but performant codebase easier to read.
- krab 3y agoYeah, that's right. I just feel that latency is sometimes missing from the discussions re. developer efficiency vs paying more for compute.
- josephg 3y agoYep. Theres a huge experiential difference between something happening instantly and it happening in 200ms or so. Especially when typing or playing video games.
- krab 3y agoIt's everywhere. Next day delivery vs in a week. Streaming vs DVD rental. CI jobs. Notification about relevant news for stock traders. Switching files in editor. Jump to definition in IDE. Typing and videogames you mention have a very tight latency budget. If you don't fit in the budget for the specific task, your product features don't matter much.
- collyw 3y agoI see far more examples of per premature optimization (resulting in horrible code) than performance problems.
- bee_rider 3y agoThe universe puts a hard speed limit on latency, but will give you all the bandwidth you want. There’s something almost mystical about latency, we should be very prudent when spending it.
- smt88 3y agoI can often get better latency by throwing a few extra bucks at vertical scaling. Still cheaper than a few hours of dev time a month. Like I said, it works until it doesn't, and then you do have to optimize for performance to some extent.
- marcus_holmes 3y agoAlso, for my compiled code (in Go), the code that I write is not the code that the compiler generates. I can write simple code that's easy for {{me in 3 months}} to read and let the compiler do the fancy stuff to make it fast.
- kaba0 3y agoFor what it’s worth, Go might not be the best example here as its compiler does very little (hence the fast compile times). Some LLVM-based language would fit the bill better, like Rust, C (also true of the intel compiler and gcc), C++, etc.
- deleted 3y ago[deleted]
- hk__2 3y agoFrom the article: > When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc
- melagonster 3y agoSo op use this point turn back to support the opinion that readability is more important. the inference process in article is interesting, but title tempt us to debate about a less related topic. thanks for your comments let me finish reading.
- TeMPOraL 3y agoThe problem with "costs less than developer's time" math is that, usually, it's not you who's paying. Your users are, often in nonobvious ways, such as through higher electricity bills, reduced lifespan[0], lost opportunities, increased frustration, and more frequent hardware upgrades. (And most of your users don't have developer's salary, or developer's quality of life, so it hurts them that many times more.) -- [0] - Yes, wasting someone's time reduces QALY.
- gnuvince 3y agoI've been calling the thinking of the parent "trickle-down devonomics": that by making the code better for the user, the benefits will trickle down to the users. Obviously, as the name suggests, that never happens. Devs get the quality of life and users end up paying for our disregard.
- Capricorn2481 3y agoThis implies that if a developer works half as long on something, all of that money that would be spent on them is spread out amongst their users. Which makes absolutely no sense. Abstractions MIGHT make your code slower. But there's a reason we're not using assembly: Because the minor efficiency hit on the software doesn't match up with the bugs, the salary towards the experts, the compilation errors, etc. A VM is a pretty good tradeoff for users, not just devs.
- Certhas 3y agoThat's the response to the article I was expecting to read. This is a different article, though. Go ahead and read it, worth it!
- mch82 3y agoIt seems like the author agrees with you and picked a confusing title for the article. The article ends with a set of equations: user > ops > dev biz > ops > dev biz ≹ user The conclusion seems to be that code exists in service to the end-user and the business. The last equation (≹) is a neat way of describing that both end-user and the business are equally important to the existence of the code, even though their needs aren’t the same.
- Lutger 3y agoNeat summary. I think many developers experience the degree to which biz and user diverges as a source of problems: the more divergence, the more problems.
- kllrnohj 3y ago> picked a confusing title for the article Or they picked a title that would let you rapidly spot who didn't even skim the article.
- pindab0ter 3y agoOf all the functions a title could have, I feel this is not one of them. That would result in intentionally misleading titles.
- Xeamek 3y ago1million users waiting even a 1 second longer is about a month of single developers time. This sort of calculations you preach are inherently untrue, as they completely ignore that 1second times million. After all, nobody bothers economically evaluate just a single second. But it does account to much, when multiplied by the ammount of users. And when we multiply again, by the times a single user uses your software, and then again, by the time a users uses different software from other developers who also thought "it's only 1 second, nobody cares", we end up living in world where software usability gets lower and lower despite hardware getting faster and faster. We end up living in a world where literally weeks are wasted everyday, waiting for slow windows file explorer. If you'd want to evaluate that honestly, you would probably come to conclusion that microsoft should have a dedicated team, working for decade on nothing but explorer startup optimization, and it would still pay for it self. But they don't. Because at the end of the day, this whole "lets evaluate developers time working on given improvement" is just a cope and justification of being us lazy, that only pretends to be an objective argument so we can make ourself feels better
- bee_rider 3y agoIt seems like a false trade-off in the first place. The point of writing readable, maintainable code is that your team will be able to edit it later. Including adding performance enhancements. Another way of stating the relationship could be something like: You have fewer brain-cycles to apply to optimization than the combined sum of everyone who will ever read your code, if your code matters. But that is a mouthful and kind of negative.
- hot_gril 3y agoThis isn't what the article is about.
- arendtio 3y agoI think the headline is misleading in that regard. I think that having easy-to-run software is part of having a well-designed one. Just last week I heard about a software upgrade that would require a downtime of 5 days. The software has about 100 users and is mostly a flexible web application to collect basic information (nothing fancy). Imagine the cost this creates for the business compared to an upgrade that takes a few hours. So running the software includes more than just the server costs.