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 efficient duping, the best.
100% accurate
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?
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.
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!
Can you get these guys to work for Slack? That shit is probably the exact opposite of whatever bullshit this article is about.
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.
I will spend 4 hours coding something so I don't have to spend 10 minutes doing it manually more than once.
"Making things go faster is fun."
Have you read my blog lately?
If you look at it through a proper lens :)
... sometimes I like to do something unbelievably inefficient. Not for production code though.
In college a teacher gave us an assignment to reverse a linked list. I made it recursive. My teacher said: "It's inefficient and that will only works with small lists, you will get a stack overflow". I said "Who cares, it is pretty", Still got an A.
I have to disagree with this post- if you are optimizing for the sake of optimizing you are:
Wasting Coding Time to get functions that take 2us to run in 1.5us when other parts of the code are taking seconds.
Making Code LESS maintainable by increasing complexity of a lot of functions that don't matter for system performance.
Instead:
Implement code that is clear that you think is not horribly inefficient. Benchmark the entire system and optimize the parts that matter- bonus points for stress testing with larger then expected data sets.
-RSF
Sadly, the days of writing super-efficient code, taking time to eliminate extra steps, Taking the time to save those extra bits of memory, those days are all gone.
Today, the sad truth is, we are supposed to push out any code that 'works', fast. Project managers just want something that works now, who cares if it's elegant.
- 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.
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.
"lack of friction is an aesthetic joy, ". Come again ?
Efficiency is not unique to coding.
I don't even know how to code. I work in an accounting based field. I streamlined every single task I've ever performed for every single employer I've ever worked for.
I must be a fucking genius. Can I pat myself on the back, too?
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.
So if you only ever have to do it twice, then you just spent 4 hours, plus the time to run the code twice on completing a task that would have taken you twenty minutes.
How is that more efficient?
I do tend to try to optimize my code, but at the same time, I tend not to be particularly bothered by doing repetitive tasks by hand (or at least, much less than most people), so it does not seem to be caused by that in my case. Some repetitive things are pleasurable (e.g. raking leaves), & once you automate something, it either does not account for edge cases or grows into a giant nest of special cases, unless you have a very good model when writing the initial code.
I get satisfaction from writing smaller and simpler code.
If you start down the road of optimizing for speed, it newer stops..
MMX/SSE1/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AVX/AVX512/VPU/NEON/OpenCL/VULCAN....
You are no longer, investing your time into your code, but into a platform.
Only to find it had a "meltdown" or is broken in some way.
Smaller and simpler code, is also faster to port to another platform.
KISS
small research groups developing their own code would be much better served by learning effective techniques for using (say) MPI or data partitioning instead of trying to eke out gains of 3-4 cycles on their FFT algorithm.
So you are saying scientists would be much better off waiting for the next gen computer because then they can hit their problem with more resources rather than making their current computer extend a bit further to the next generation of problems Spoken like a true computer scientist! Nicely played.
He clearly isn't looking at the code I usually have to maintain.
I wrote some excel macros for my wife (Yes, she is real). Now, she can run a bunch of reports (just queries, nothing fancy) in 2 minutes. She used to spend 2 days just to run a full set of reports.
Some seem overly obsessed with machine speed. I know one coder who was so obsessed he made a mess out of the software because it was designed for speed over maintenance, and maintenance fell behind, making for spaghetti code that was even slower than it would have been. Penny-wise, pound foolish.
I like software stacks that can be tuned for shop conventions to remove repetitions grunt-work, but others don't seem to care much about that. Why I am I typing the field title and size in in 4 different places? Why do I have to redefine the schema copy (table structure) if I want one screen or report to show fields in a different order than the other one? Can't I just supply a list of fields to give their order and inclusion that reference the original for the other details?
Few other devs seem to care about this and similar factoring issues with general CRUD idioms, as if it's part of the job. Scaffolding helps when you start out (auto-generating based on the database), but often can't be used when later changing things because customizations have been added that would be overwritten. It's better to have reference-based abstraction than copy engines: A.K.A. auto-bloaters.
I'd rather have regular CRUD be easy so I can focus on domain logic instead of the grunt-work of marshaling rows and fields back and forth. Our stacks turned bicycle science into rocket science and as long as these guys get a paycheck, they don't care. I do care. Dammit Jim, I wanna be an analyst, not a pasta manager!
Table-ized A.I.
So if you only ever have to do it twice, then you just spent 4 hours, plus the time to run the code twice on completing a task that would have taken you twenty minutes.
It's faster in the abstract.
*I* understand.
P.S. Also over time you realize that even if that time it wasn't falser overall you probably learned something to make something similar faster later.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Angular. It's almost a case study in how to do everything the absolute worst way possible, break a programming language, and lock you out of writing any useful procedural code while requiring several megabytes of backend and a cult-like pseudointellectual non-procedural nonsense to display anything meaningful, while also managing to be unmaintainable as soon as any "code" is written. Anyone who claims to be a "coder" while using Angular can't be considered to have any serious coding ability or any knowledge of how decent software works.
I seem to only find this sentiment in developers after the code goes into production.
There's no thought given to the impact of not using a connection pool or not caching retrieved data or whether or not to overarchitect a complex solution with tons of layers for a relatively simple problem...
It's too bad devs aren't trained to consider runtime aspects of their code before they start developing it...
From the onset of our teen years, we strive to reduce friction where it would be leaving a chafing feeling.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
n/t
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Code should be written for the next developer to read and understand it.
Your cutting edge coding style, set of libraries and tools is a time bomb of maintenance work in 2 years.
Code written for the next reader, not for cuteness, not for creative writing assignment, not for an interlarded overstratification of layered gunk, not a large number of misappropriated patterns.
I'd expect to see these three etched in gold plate on the next moon probe:
- Use the guard clause, once you get past the guard clauses, business work can happen
- Use dictionary order when naming methods and variables and classes. Use "CustomerCreateAccount" and "CustomerDisableAccount" instead of "CreateCustomerAccount" and "DisableCustomerAccount" as the later 2 will get jumbled with all of the thousands of "Create..." methods in your large code base.
- Patterns used rarely and most everything is not a pattern
General problem is academics do not have significant non-academic experience living with an ultra large system for 5 years. Teaching cute naming schemes and architecture patterns === more productivity is a disservice.
..find pleasure in quantifying things and then trying to OCD-like remove anything 'inefficient"?
News at 11?
-Styopa
Most employers want their coders to use canned routines, because of turn over of personnel. The next guy to work on your code won't have the background to understand your hand written algorithms, especially when your code is shipped overseas to Asia. Heaven forbid you to write in Assembler for a boss to achieve a twenty-fold increase in speed.
Coders like mental masturbation, piles of unnecessary layers of cruft using libraries they don't understand, bogging a processor that could do billions of operations a second to doing less real work than one a decade ago in twice the amount of time...
A quick Web search did not turn up "sloppy vector" as a coding style.
I understand how locality of reference can make a big difference in processing speed. But is "sloppy vector" simply a description of attempting to optimize loops scanning through arrays for the vector-architecture supercomputers but doing it in a haphazard way? Or is it a term-of-art that I can read about someplace?
Thanks!
Where's the story titled "Managers' Primal Urge To Kill Efficiency -- Everywhere"?
You might consider sending your resume to Boeing?
Make it right. Make it fast. In that order.
...the biological father of invention.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
Big, slow and clunky. A giant on clay feet.
He sees an article with a low comment count and wracks his brain trying to come up with something that might just maybe get modded +5 funny.
I guess we all like getting modd'd up but on a website getting posts numbering in the low thousands why does he give a fuck?
He's either addicted to karma points or
He hopes one day he can bring his karma back up and start spamming slashdot with ad referrer links and plugs for his youtube channel.
If he is successful this could rake him in dozens of dollars a year, every year, for the remaining 15 years of his life so you can imagine he's not going to give up easily.
I thought it was no where, and had died out with the advent of near-unlimited computing power.
To quote someone on a Facebook group whom I told Windows 10 is incredibly inefficient and a ram hog. their reply was "Ram? Who cares about ram? What are you, poor?"
Seems that since the advent of really high power CPUs and GPUs efficiency of code and optimization has gone by the wayside. Something that is hanging on by a thread ever-so-slightly in console game development. Once consoles start to have the power of PCs then we will see the extinction of extremely efficient optimized code.
But yes, to a lot of us "true" coders who actually give a darn about what the post says, the post is true :)
- Alex
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
Not I (when & if possible/time permitting): I write all of my code, myself (leads to better understanding & avoidance of what you + others state).
APK
P.S.=> Sometimes though, when it's "on the job" & deadlines loom, you do have to use prebuilt lib/dll API (& you always do from the OS @ some point @ least)...apk
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.
All the code (written on napkins and the backs of coasters) is literally held together by bits of leftover rice and potatoes with post-its, scotch tape, and staples from the office supply cabinet.
Your primal urge may be "efficiency" to perform tasks which may be easily automated, but the rube goldberg machine making it happen isn't.
*cough* tesla *cough* *cough*
https://forums.somethingawful.com/showthread.php?threadid=3862643&userid=20544
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.
The best thing about this whole article is that my browser tab just reads "Coder's Primal Urge To Kill"
As the GP said, Coders bat clean-up on old problems.
You will have noticed how computers keep getting faster tanks to Moore's law and how the software keeps expanding to negate it's effect. Economists see computers everywhere but they never observe increased efficiency or worker productivity.
it's really just that it's stupid to do the same thing over and over again, especially when it can be automated. As a coder for 35 years by now, I always wonder how people can put up with manually executing mindless tasks, day in day out. Personally, I just can't stand to do the same thing even twice (can't be bother to remember all the details either!) and so I'll automate everything wherever I can. Seriously.
FreeBSD got CoC'ed by corporate progressive social just-us nazis. No more freedom. Therefore "Free"BSD is dead.
Fuck the READER. Me, myself, and I increased efficiency by 12% so me, myself, and I get a bonus/raise this quarter. The READER can go get his own fucking bonus.
Because in Java (note the comment about garbage collection), all object allocations go on the heap.
OK, OK, there is Escape Analysis where the runtime, if it so optimizes your code, will allocate on the stack an object from which no references "escape" the current context.
Good luck with that being a guarantee.
See subject: Something YOU aren't capable of & 100's of 1,000's worldwide like/use/praise it, not you OR you NON-EXISTENT work.
APK
P.S.=> Fact... apk
*I* understand.
I don't.
There are actually two lessons to be learned:
1) You would have learned a lesson on cost-effectiveness.
2) You would have been spending that time coding something else, where you probably still would have learned how to relate code between projects.
I'm not even a coder, and I see it all the time. Like most, our IT department is inundated with requests. Every request has to have an estimated time savings and an estimated time for development. If I estimate a one-off twenty minute time savings, and they estimate 4 hours of programming, I can assure you it will never get completed, no matter how much one may learn. Those same lessons can still be learned on more cost effective projects.
In my experience, unoptimized code tends to have negative scaling past peak performance. I deal with a lot of high concurrency systems that can run under saturating load for hours, and code that is poorly designed or written will cause the system to become less efficient and performance reduces at a super linear rate. Instead of backlog accumulating and run time scaling linearly with the amount of work, as the backlog gets larger, the time taken per unit of work increases.
Nearly everyone that I've dealt with cannot understand how each N% increase in work may cause a N^K% increase in run time, but only beyond a certain load. Prior to that tipping point, each N% increase in work results in a sub-linear increase in run-time.
I was tell these people till I'm blue in the face that certain aspects of the system needs to be further optimized, but empirical evidence shows the system is running fine and increases in load seem to make little difference in the run-time of work. But then that inflection point is hit and it all goes to hell in a hand-basket.
It's very similar to the whole running out of memory and going to swap. At 90% memory usage, everything still seems fine, at 95% things are getting slower, but 105% and people are starting to panic, at 130% the world is one big dumpster fire as nearly every 4th memory access results in going out to disk.