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.
Numerical Recipes in $LANGUAGE states it is written for scientist not coders because the difference is that scientists work on the next generation of problems on the last generation of computers (and hence need efficiency), while coders solve the last generation of problems on the next generation of computers (and thus make the code more elegant but less efficient).
Some drink at the fountain of knowledge. Others just gargle.
This is just a bunch of feel-good nonsense. While nobody sets out to write inefficient code, most of the code is inefficient due to reuse of generic libraries and lack of compiler optimizations. If you think you are different, then when was the last time you looked at your gcc compiler flags and do you know what each one of them does?
As an Operations Engineer, I'm also working on improving things. Automation to speed up deployments, monitoring to identify bottlenecks, etc. The bad part is when the provided tools don't give me that visibility so I can make improvements, I deploy my own tools (or write my own). It's probably less efficient but I can then work on improving the environment. My current audit script identifies some 34,000 things that can be improved across our environment.
[John]
Shit better not happen!
You did something and you can measure that what you did, actually did it.
It is not like throwing a price to a customer and then he buys it. Perhaps he would have done that anyway. When you did the coding, you know that what you did was the cause of the improvement.
I know I have sat down for many hours, so a process can run 1 second faster and it runs once per week day. That is just over 5 minutes per year.
There is no way to defend spending so much time on it, except for ego.
Don't fight for your country, if your country does not fight for you.
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.
- tm Jake, ca 1980
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.
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.
Depends - are you optimizing the code, or are you optimizing the algorithm?
Code is usually small gains, and modern compilers can claim most of the low-hanging fruit themselves.
Data structures can be much bigger gains in some contexts, as using hardware cache inefficiently for frequent operations can cost you an order of magnitude of performance.
The algorithm though - that can easily often make several orders of magnitude difference. That's where optimization and elegance can often really come together. Sometimes simplicity has to be sacrificed - but if you start thinking that way it's usually a warning sign that you need to revisit your assumptions.
Same thing with architecture in many ways - though with a bad architecture it's the programmers' time you're wasting rather than CPU time. And that's generally even worse.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
n/t
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You might consider sending your resume to Boeing?
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
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.
Garbage!
What gives coders pleasure is a combination of going home early, finding someone else to blame a bug on and getting stuff through acceptance testing.
As for wanting to improve efficiency? There is no evidence for this. Nearly 25 years ago we were enlightened by Wirth's Law which addressed the question why does software get slower more rapidly than hardware becomes faster? and nothing in the intervening quarter century has improved the matter.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Explain ruby, systemd, Docker, and lumberjack beards.
That's an interesting observation. I'll look for it.
I suppose I DO see it in programming tools, such as languages.
I do a lot of code review and mostly I see bad code and good code. Good code tends to be elegant and efficient. Bad code tends to be inelegant and inefficient. They tend to go hand-in-hand. Partly because mathematically they are sometimes correlated, and partly because those who write good code, write good code. I don't often see "good" as in "elegant" code that is also "bad" as is "inefficient".
I wonder though about whether programmers in general have that instinct, that desire, for efficiency, or if that's just the 10% who are particularly good at it. A lot of people do in fact write crap. Do they have a strong desire to do much better, but just don't know how to learn? I'm not sure. Maybe 30% of my teammates signed up for my last series of classes I taught, so those 30% indicate by their actions that they really want to improve.
* Talking about teaching classes sometimes makes people think I'm arrogant. I'm really, really bad at singing. Horrible. I can't play any video or board games. I can't draw for shit. I spend all my time learning about programming and designing information systems. I'm pretty good at that one thing.
The most efficient code in the world is useless if it is broke because it can't be maintained.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.