Live data from Hacker News

Code is run more than read (2023)

olano.dev

11–20 of 110 posts

Re: Code is run more than read (2023)

#11
post #4

I like the final conclusion. And sadly I don't feel like anything changed for the better on this topic since 2023. I am afraid that without a major crash or revolution of some sort, user won't matter next to a sufficiently big biz. But time will tell.

I've found the users-first mentality degrading over the years at companies. It's a bit jarring too, since a lot of my early training was pretty user-centric.

I do have a feeling that the example of bigger players is carefully followed by many of the other companies, kind of as a cult of success. And that example for a long time has been rather lacking.

Re: Code is run more than read (2023)

#12

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

Re: Code is run more than read (2023)

#13

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

I would not call "you must leave the webpage open" a "working code" :)

This looks like an example of biobackend: defective IT compensated by humans

Your point is very sane, of course, shitty code was not invented now. But was it ever sold as a revolution ? Probably, too !

Re: Code is run more than read (2023)

#14

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

Except..there is never such reason. They can put the filter anywhere in the pipeline. Some even have it exactly where it should be: https://www.ifixit.com/Guide/2013+Subaru+Legacy+Oil+and+Oil+...

Re: Code is run more than read (2023)

#15

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

If it is a part with a regular maintenance schedule, it should be designed for maintainability.

Most maintainability conflicts come from packaging and design for assembly.

Efficiency more often comes into conflict with durability, and sometimes safety.

Re: Code is run more than read (2023)

#17

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

I’m no mechanical engineer, but I would assume those extreme tradeoffs occur more often when repairability is not prioritized from early iterations. I.e. “boss we’re 90% into the design cycle why are you bringing up the position of the oil filter now?”

There’s definitely a programming equivalent as well…

Re: Code is run more than read (2023)

#18

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

Which is great until you have to make changes to this kind of code, not to mention a massive refactoring.

It is completely possible that the path that got them to this point was the optimal path given their goals and knowledge at the time. And wildly enough, maybe it was even the optimal path with perfect knowledge of the future as well.

Re: Code is run more than read (2023)

#19

I've worked at some of the "top tier" finance firms over the years. It is absolutely astounding how much of them run on code that is: - very reliable aka it almost never breaks/fails - written in ways that makes you wonder what series of events led to such awful code For example: - A deployment system that used python to read and respond to raw HTTP requests. If you triggered a deployment, you had to leave the webpag…

Google “hospital server room”. Guess everywhere should just do the same thing with their server rooms, yeah? Works for hospitals, and look how much money the healthcare system makes! Why even pay an IT engineer, just plug in another wire bro.

Re: Code is run more than read (2023)

#20

And cars are driven more than worked on, but putting the oil filter inaccessibly in the middle of the engine block is still an unforgiveable sin.

What if there's an efficiency in engine design by placing the filter in the middle that leads to a +2mpg improvement for the driver? Or that it fails, on average, 22k miles later into it's life? Not all hard-to-repair-yourself designs are malicious...

Most cars sold in the US are not aerodynamic so it seems a couple of mpg isn't the focus anyway
Post reply on HN