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.

10 of 181 comments (clear)

  1. Ha... exactly backwards by goombah99 · · Score: 4, Interesting

    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.
    1. Re:Ha... exactly backwards by coats · · Score: 4, Interesting
      Not my experience with environmental modelers. In particular, they have weaknesses with respect to (1) algorithms; and (2) how the implementation interacts with the hardware. Generally, it is coded in a "sloppy vector" style tailored for the limitations of 1980's vector supercomputers.
      • Case in point # 1: in the mid-90s, recognizing that emissions modeling is a linear operator problem instead of a data processing problem not only made the code much more elegant, it also reduced the run-time from 11 supercomputer-hours to 163 Sparc-2 seconds.
      • Case in point # 2: a little recoding to respect how memory access patterns interact with microprocessor based systems reduces the run-time of (my custom of) the WRF meteorology model by 40%
      • Case in point # 3: restructuring the microphysics and the vertical-mixing codes in WRF and in CMAQ from "sloppy vector" style to "vertical-column style" reduces the scratch-variable memory usage for a typical case from about 500 KB (larger than L2 caches) to about 4KB (much smaller than L1, on almost anything), the number of lines of code by 30%, and the execution time by a factor of 8.
      --
      "My opinions are my own, and I've got *lots* of them!"
    2. Re:Ha... exactly backwards by lgw · · Score: 4, Interesting

      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).

      You have a narrow idea of "efficiency". You're thinking about CPU-time, which matters so rarely these days. Good software professionals optimize for human-time, writing code that's easy to support and maintain. That's "efficiency" that will bring a smile. Nothing better than a code review that's "all red", that is, removes a ton of pointless lines of code from a legacy system.

      --
      Socialism: a lie told by totalitarians and believed by fools.
  2. Re:Feel-good nonsense by Anonymous Coward · · Score: 5, Insightful

    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.

  3. FACT by phishybongwaters · · Score: 4, Insightful

    I will spend 4 hours coding something so I don't have to spend 10 minutes doing it manually more than once.

    1. Re:FACT by dromgodis · · Score: 4, Informative
  4. Re:Feel-good nonsense by tomhath · · Score: 4, Insightful

    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?

  5. Re:Feel-good nonsense by Dutch+Gun · · Score: 5, Insightful

    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.
  6. Re:Feel-good nonsense by skids · · Score: 4, Insightful

    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"?

  7. Huh? by smooth+wombat · · Score: 5, Insightful

    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