Hacker News Reader

Comment by dijit | Hacker News Reader

you know it’s funny, the first time I ever read a book about compiled languages- I think it might have even been K&R C… it talked about the fact that code is run significantly more often than it’s compiled, and read more often than it’s written. Thus we should optimise for runtime speed and afterwards readability.

Yet on hacker news, the exact opposite sentiment is true.

Employee hours are expensive, so optimise as much as you possibly can and push as much time onto the user as they will tolerate. Focus primarily on readability to the detriment of all other factors. Heck, even don’t bother compiling your program. Use an interpreter on the server.

Keep your local cost down, your remote cost up… after all remote cost are not your cost, especially if every company is doing the same thing.

It’s ironic that I could read a book and it be so wrong, yet that book is the foundation Bible for many people’s programming journey.

View on HN

Well, programming is a tool, right? There are clearly incorrect ways to program, but that doesn't mean there's one correct way to program - because it depends on what you're trying to make.

It's incorrect to make a bookshelf that can't hold the weight of books, but IKEA isn't incorrect to make a crappy-but-adequate bookshelf that will get given away when you move, and a master carpenter isn't incorrect to make an expensive-but-beautiful bookshelf that will be used for many decades.

A seed-stage startup trying to see if anyone cares about their product at all should probably accept it being 100x slower than it theoretically could be. And the Linux maintainers should be working hard to shave milliseconds.

I've been told it depends on management's goals.

If you are a startup (many HN readers are), employee hours are relatively expensive. The goal is to get a product out as fast as possible, and most of the time you fail at making a working product anyways. Meanwhile, you only have to spend money on servers once you have a successful product. Deferring the problem makes sense here.

On the other hand, I personally write code that'll be near guaranteed to run millions of times in some factory somewhere, and there's little benefit if I ship my code before the factory starts making stuff. I'll take the time to write high-performance and high-quality software because there's now a financial benefit to doing so.

But ultimately, it's my boss who gives me insight into what I should be doing. Not a book, because the book doesn't have context that [company] will lose tens of thousands of dollars every day that I don't fix [issue].

It feels like companies care a lot less about delivering quality.

Because quite often users buy products based on features and not quality of those features.

This is just the difference between rational design and capitalist design. Capital must externalize costs to achieve profits, but it's not a rational approach to system design. This appears everywhere in the economy as capitalist pressures override rationality.

Reply on news.ycombinator.com