With the possible exception of philosophers, programmers are the laziest bunch of people I know. It seems like everyone else I speak to has some sort of labor intensive profession.
Think about it, biologists do all those experiments ... giving a drug to hundreds of mice is can't be automated. Doctors have to physically inspect their patients, professors have to give the same lectures year after year, architects draw their plans in all perspectives manually and until recently did hatching by hand.
Looking at more run of the mill professions it gets even worse, marketers give the same pitch over and over, hairdressers do practically the same thing day after day, store clerks handle the same groceries for customers in the same manner all the time ... people in factories ...
You get the picture, the world is full of people doing practically the same thing day after day, hour after hour, for years on end, sometimes their whole lives.
Enter programmers, stage left.
Whenever we do the same thing twice in a row - we try to think of a way to automate the process. Whenever you write code doing the same thing, you start looking for a library. Whenever you start projects on a similar foot, you go look for a boilerplate.
Programmers' lives are devoted to eliminating repetivity.
Removing menial tasks from our workflows, making lives easier for everyone. It's a common joke that a programmer would rather spend a week making a bash script than copy paste the same file twice and be done with it in two minutes.
Hell, we even have the DRY (Don't Repeat Yourself) principle, which basically states that it's better to create a convoluted abstraction than to write different-but-very-similar code twice.
This of course leads to a lot of problems.
The average software project is so full of abstractions built on top of abstractions which are created on top of abstractions that it's become virtually impossible to know what's going on or even what your code is doing at all. Dizzying but invisible depth, touches upon this subject and is a really good short read.
On the other hand, laziness has proven itself as the driving force behind many of the most important scientific and engineering advances in history. It's much easier to use a wheel than to carry things around, it's a lot easier to use boats than it is to swim, hell, even dropping a single motherfucker of a bomb is a lot easier than dropping a thousand small bombs if you want to ruin a city for a few decades ...
So maybe it's not that programmers are lazy. Perhaps it's really engineers who are lazy and it just so happens that in this point in history programmers are the most obvious sort of engineer working the most madly towards a better and brighter future. Most other fields have already sort of stabilised and/or take longer to adapt to new tools.
An important question to ask here is: Are programmers naturally lazy? Are smart lazy people drawn to programming or is this a social effect? Does laziness stem from the best programming practices? Or do the best programming practices stem from laziness?
A comparison
Recently I had a nice opportunity to compare how an architecture major goes about her day and how a computer science major such as me goes about his day.
Most of the architect's life is filled with doing this or that labor intensive task as part of her homework. At any given time she is likely to be glueing some pieces of a model together, drawing the same object from fifty perspectives in autocad, or redrawing the same thing yet again in a 3D modeling software ... which then gets imported into photoshop to become really pretty.
It's a constant barrage. By my estimates she probably spends twice as much time on coursework than she does actually attending class. [** she said it's actually 5-times more] And to make matters worse, getting better at this stuff doesn't really speed up the process, it just means you know a few more keyboard shortcuts and make less mistakes when drawing.
Proficiency doesn't optimize the critical section at all.
Contrast that with me. When I'm not attending class I'm usually working on my own projects. Because I can, because there's plenty of time. When homework comes around, if it does, it can usually be dealt with in a matter of hours ... even the most critically insane projects they give us rarely take more than a week of concentrated work, two weeks at most.
Proficiency in coding doesn't mean typing faster (the equivalent of proficiency in architecture). It means thinking up solutions that are easier to implement, using tools that do half the work you're supposed to be doing and so on. Eventually, as judged by internet dick measuring contests, implementation is the irrelevant part because everyone can do it. If you've got a day, you implement something, if you've got more time you also make it pretty and modular and reusable and so on.
Basically you're done implementing the thing so quickly, most of your work is devoted to making the implementation prettier. But this isn't really important to the task at hand, you do it because you can.
It almost seems like when programmers get bored of even making their implementations prettier, they turn to creating tools to make the implementation pretty right off the bat.
And the cycle repeats itself.
The next guy will use that new tool to implement something even quicker, then begin polishing it until he eventually gets fed up and creates a new even better tool.
So ... hard work?
But to cycle back on my original point, how much does working hard even factor into programmers' productivity? What does this mean for all those startups working 13 hours a day to gain an edge on the competition? Is this even an edge worth considering?
Hard work might even have a negative effect on programmer productivity. It obscures optimizations behind "Oh, I can do this by hand, it will only take ten minutes" (it takes 20). And the next time a similar task rolls around you have to do it manually again and so on.
Most importantly, hard work makes you stupid. Being tired leads to bad decisions, even making too many decisions leads to bad decisions (decision fatigue) as many studies have shown. In fact, that might be the best use of all the abstractions we like producing - let someone else to most of the decisions so I can focus on only the critical ones.
But I still don't know if lazy people are drawn to programming, or does programming make them lazy ...
Continue reading about Programmers are fucking lazy
Semantically similar articles hand-picked by GPT-4
- The 10x programmer in you
- Why programmers work at night
- Everyone should learn [about] programming
- Why programmers work at night
- Software dev isn't just a logical process
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️