Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Efficiency-Destroying Magic of Tidying Up

florentcrivello.com

Post reply on HN
Print view View original

131–140 of 196 posts

Re: The Efficiency-Destroying Magic of Tidying Up

#131

Post by dimino »

uulu wrote: post #78
pizzaparty2 wrote: post #53

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…

Strange, how did you come to the conclusion that this is a defense of "crap code"? For one thing - crappy code is most often less efficient than elegant code.

The example of the child being asked to clean his room reminds me a great deal of a bad engineer being asked to clean up his code.

Re: The Efficiency-Destroying Magic of Tidying Up

#132

Post by porknubbins »

dsfyu404ed wrote: post #118
TeMPOraL wrote: post #106

Earlier quoted context omitted.

> as long as they're not deliberately impeded by a computer But I meant exactly that - at least from the stories I hear (I don't own a new enough car), half of the breakage in modern cars seems to require interfacing with the computer to at least clear an error flag. I once helped a guy with a software project, and learned that he's operating a workshop fixing a specific car brand. He showed me the device he uses to…

If you don't want to do complex diagnostics that kind of stuff is unnecessary for the overwhelming majority of repairs on the overwhelming majority of vehicles. I think you're bother over estimating the complexity of modern vehicles and under estimating the simplicity of old ones. Back in the carburetor days people were complaining about vacuum line spaghetti to run the emissions system. People always complain about…

As someone who had only ever done oil/battery change level auto work this was surprisingly exactly my experience replacing a bad knock sensor in my truck. OBD tells you the problem (a sensor is out of voltage range) and youtube tells you how to fix it step by step. At one point my family saw the intake manifold on the floor and thought the car was never going to run again, but its really just plugging or unplugging things from a big computer now. If you can write software you can do (most) auto work.

Re: The Efficiency-Destroying Magic of Tidying Up

#133

Post by vkou »

smabie wrote: post #101
vkou wrote: post #62

Earlier quoted context omitted.

I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.

So would you work the rest of your life before retirement to dig a hole and then fill it up again, over and over. Let’s say you get to make 10x whatever you are earning now. Oh, and, the manager is a nice guy, he gives you lemonade and stuff on breaks.

Sure.

Most people do exactly that for a living. I don't let my 9-5 define my life. It means I'll retire in two years, and be able to work for a cause that I deeply care about - or, better yet, for myself.

A better thought experiment is to ask yourself how many of your co-workers will come in tomorrow, if all your code became the most beautiful code ever written, with rainbows, and unicorns... but on the flipside, that they stopped receiving paycheques.

Re: The Efficiency-Destroying Magic of Tidying Up

#134

Post by ineedasername »

I just started playing Opus Magnum and so this article resonated with me. In playing, I've found myself throwing out all optimization on the three metrics used: component cost, speed, and size.

Instead, I've been designing for aesthetics, for symmetry or clean lines or linear solutions. When I've given in to the desire to chase the metrics, the results have been much messier in appearance.

Re: The Efficiency-Destroying Magic of Tidying Up

#135

Post by [deleted] »

wpietri wrote: post #70
vkou wrote: post #62

Earlier quoted context omitted.

I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.

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…

[deleted]

Re: The Efficiency-Destroying Magic of Tidying Up

#136

Post by vkou »

wpietri wrote: post #70
vkou wrote: post #62

Earlier quoted context omitted.

I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.

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 up with new technologies and new approaches.

In my experience, tech churn is one of the top reasons for why code has gone to shit. "It's been three years since the last re-write, let's rebuild the product again, in a framework that nobody here knows how to use!"

On the bright side, both the re-write, and the cleanup of the resulting mess means steady employment.

Re: The Efficiency-Destroying Magic of Tidying Up

#137

Post by Forge36 »

pizzaparty2 wrote: post #53

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…

I'm a big fan of design two systems. If timelines permit, ship the second, else ship the first. The first code will almost always be crap code because it takes designing the system to better see how the system should have been designed.

Problems arise when the first system gets left in place for too long. It starts to grow developers sometimes whole teams arise, and many people ask why, but are too afraid to touch it

Re: The Efficiency-Destroying Magic of Tidying Up

#138

Post by zzo38computer »

Chaos is not necessarily so bad, and order is not necessarily so good. Many people thing it is and they are wrong. I think even Principia Discordia mention such thing, isn't it?

And yet, many people today don't like C and assembly language, and hate "goto" and some other stuff like that, but I think that it is good.

(Also I do not always clean the stuff, because where it is, I know where it is and do not have to move it again when using it again.)

Re: The Efficiency-Destroying Magic of Tidying Up

#139

Post by taneq »

BurningFrog wrote: post #86
pizzaparty2 wrote: post #58

Earlier quoted context omitted.

I agree, beautiful code is often the other extreme. Plus it's often only beautiful to the person that wrote it.

Maybe by aiming for "simple", you can as a side effect eventually achieve "beautiful". I suspect aiming for beauty gives you neither.

Depends on what you think is beautiful. I've seen code that was beautifully simple, and 'beautiful' code that was unnecessary, impenetrable wank.

Re: The Efficiency-Destroying Magic of Tidying Up

#140

Post by specialist »

FooHentai wrote: post #112
m0zg wrote: post #94

I strongly disagree with this. Software should not be written to suit the machine. Software should be written to accommodate the weakest link: humans who are going to need to figure it out 6 months from now when its current programmer departs for the greener pastures. If there's no rhyme or reason to it, it fossilizes immediately and costs a lot of money to rewrite (often into another fossil). So whatever effort you…

Yep. What this article skips over is maintainability in all of the things it discusses, and in most cases also flexibility. The optimization it praises only has single focus (operational efficiency), whereas if you take into account all of the aspects of the things in question, suddenly you see that the way things are are usually a solid compromise between the aspects it's really optimizing for. That includes human i…

Ditto testability. For most messy code I’ve cleaned up, no one could say if it worked correctly. (Spoiler: no.)
Post reply on HN