Live data from Hacker News

The Efficiency-Destroying Magic of Tidying Up

florentcrivello.com

191–196 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#191
post #136
post #70

Earlier quoted context omitted.

I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitud…

> It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. If most of my income derived from being an owner of a company, I would care deeply about this problem. Since it doesn't, its really no sweat off my back, either way. > It keeps us from getting better at our jobs, from keeping u…

> Since it doesn't, its really no sweat off my back, either way.

Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.

Re: The Efficiency-Destroying Magic of Tidying Up

#192

Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that cr…

The more I code, the more I like messiness. By that I don't mean bad code. I mean code where all techniques in and out of books are used together.

For example, a mix of exception and error returns, direct access to class members combined with accessors, etc... I like to see best practice rules being broken when there is a good reason for that.

Rule of the thumb: good code is short code. If your "tidying up" makes the code longer, then it is probably better to leave it as it is. What you are going to do is most likely add useless layers of abstraction or try make it abide by some made-up rule that shouldn't apply here.

As for "efficient" code. Most efficient code I see is actually quite good and readable. The worst code I see usually gives no fucks to efficiency. At least premature optimizers show some love to their code.

Re: The Efficiency-Destroying Magic of Tidying Up

#193
post #23

Clutter and tidying is simply a time debit/credit ledger. If you had unlimited time, you would tidy and organize everything in real time . However, we don't have unlimited time and so we borrow time from the future by leaving things slightly messy. The behavior to avoid, as in money ledgers, is not using the ledger but never paying it back.

You gain back some efficiency by cleaning up all in one go at a later time! Think of trips to the sink with the dirty dishes.

Re: The Efficiency-Destroying Magic of Tidying Up

#194
post #181

Earlier quoted context omitted.

> Here, I propose Scott’s Law: never put order in a system before you understand the structure underneath its chaos. Previously formulated as Chesterton's Fence [0], among others. There's definitely a blind spot in software for the general principle that you should understand a thing well before you decide to remove it. Anyone want to propose some theories on why disregard for an extant body of work tends to plague s…

Because we suffer from the attitude that we don't have to understand a thing, as, say, reading the article might lead to, before attempting to correct it. ;)

It wasn't really intended as a correction -- more just an addition -- but I didn't feel like clarifying just to save a few imaginary internet points. Apologies to anyone who interpreted as attempting to correct an article I didn't even read. :)

Re: The Efficiency-Destroying Magic of Tidying Up

#195
post #67

this reminds me of that time blowhard Richard Dawkins disected an animal (can't remember which) and proceeded to bang on about how stupid the vagus nerve is, wandering all over the place as it does for no apparent reason. People used to say the same of the appendix and adenoids; that they're pointless vestiges, the blindness of evolution, contingent structures. Dawkins said obviously the nerve should simply connect d…

He said it would have been stupid had someone designed it that way but given that it evolved it made perfect sense why it was the way it was.

he said it was understandable why it was the way it was but implied that it "would be better" if it went directly - his tone was scoffing

Re: The Efficiency-Destroying Magic of Tidying Up

#196
post #136

Earlier quoted context omitted.

> It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. If most of my income derived from being an owner of a company, I would care deeply about this problem. Since it doesn't, its really no sweat off my back, either way. > It keeps us from getting better at our jobs, from keeping u…

> Since it doesn't, its really no sweat off my back, either way. Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.

Do you think so? If you do, and you hire people, you should seriously consider not thinking in that way.

Any manager who can put two and two together should be well aware that the impact that an average IC has on the success of a failing company that's bigger than 100 people is near-zero.

It's just pedigree snobbery, to look at a resume, and go: "Oh, well, he worked for losers, he must be a loser, reject."

Post reply on HN