Slashdot Mirror
Coders' Primal Urge To Kill Inefficiency -- Everywhere (wired.com)
For software engineers, lack of friction is an aesthetic joy, an emotional high, the ideal existential state. It's what drives them, and what shapes our world. An excerpt from an upcoming book on coding, via Wired: The thrust of Silicon Valley is always to take human activity and shift it into metabolic overdrive. And maybe you've wondered, why the heck is that? Why do techies insist that things should be sped up, torqued, optimized? There's one obvious reason, of course: They do it because of the dictates of the market. Capitalism handsomely rewards anyone who can improve a process and squeeze some margin out. But with software, there's something else going on too. For coders, efficiency is more than just a tool for business. It's an existential state, an emotional driver.
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders' eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process. This passion for efficiency isn't unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity's "redeemer from despairing drudgery and burdensome labor," as Charles Hermany, an engineer himself, wrote in 1904.
[...] Many of today's programmers have their efficiency "aha" moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I've talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders' eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process. This passion for efficiency isn't unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity's "redeemer from despairing drudgery and burdensome labor," as Charles Hermany, an engineer himself, wrote in 1904.
[...] Many of today's programmers have their efficiency "aha" moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I've talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.
Very true. Most programmers aren't interested having a 100% efficient program at this point. But we are interested in automating tasks. The two things are independent, but the summary conflates the two. Probably written by a non-developer.
If you are looking at gcc flags to get overall optimization, you are doing it all wrong. You gain fractions from gcc optimizations. I've refactored code and gotten 1000X from silly stuff that people have done. gcc would have done nothing to make those problems go away.
Sometimes the primal urge to make everything more optimized can be a waste of time given the slight performance benefits. Especially when you've spent excessive amounts of time trying to squeeze out that last 1% of performance. Sometimes squeezing the last bit out of it isn't worth the time.
Sadly there are too few programmers who get that concept.
Exactly this. I've argued with a peer many times over making some odd error handling routine that is only called on a catastrophic failure more efficient. Well it takes too long or uses too much memory if you do it this way.... Over, Yea, but if it's ever called, this program is going to die a quick and complete death so why does it matter? Why are we wasting development time discussing this?
It's the same mentality that gets up in arms about how many spaces are used for indentation or if you use a line feed before your curly braces or not. Don't get me started on the "You have TABS in your file, instead of spaces! Or there are too many line feeds here" complaint. Why are we wasting time fixing this stuff after the code is working? Sure, bring it up so we can all agree to do all this the same way, but it's not worth wasting hours of the developers' time to "fix" stuff that isn't really broken.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I will spend 4 hours coding something so I don't have to spend 10 minutes doing it manually more than once.
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders" as if they are some kind of special life form. Do "carpenters" have a primal urge to "kill inefficiency" because they use power tools?
A very good point. I work in videogames, which obviously has, as an industry, a great interest in writing efficient code.
However, in code meant for tools, or even game code that's reasonably far off the critical path, I'll happily sacrifice efficiency in some complex code in order to make it more readable, because that's significantly more important for the those that may come after me who have to maintain it. For code that's in a critical path, only then will I spend the extra effort writing more optimal code. Optimal code sometimes has a price to pay both in the time spend writing it, but also maintaining it in the future.
There are occasions where more optimal code is also clearer and more elegant, but you have to have a reasonably comprehensive knowledge of both the language and the project you're working on to properly make this call.
Irony: Agile development has too much intertia to be abandoned now.
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch.
There's also get great pleasure in reducing the complexity of code. If I can make the code faster/more efficient and simpler at the same time then I have one of those oh yes, yes, yessss moments.
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders"
Yup. After all, the inefficient code that "coders" love to optimize had to come from somewhere. Where, if not from "coders"?
Someone had to do it.
For nearly all code you should write the simplest implementation, selecting ease of reading, security, and maintainability over speed. After your program is nearly done and you begin profiling then start optimizing. People are notoriously bad at guessing where bottlenecks will be and what causes them.
Coders hate inefficiency? Then who the hell has been programming all the shitty software we have to deal with every day? The software whose every iteration gets more and more bloated (Firefox, Office, etc)? Software which takes longer and longer to load each time a new version comes out, yet is no more useful than what was produced a decade ago? Why does it take 90 scripts to load one web page, including a simple picture?
Where are these mythical beings who want to kill inefficiency? Are they hanging out with Big Foot?
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower