Slashdot Mirror
New Book Argues Automation Is Making Software Developers Less Capable
dcblogs writes: Nicholas Carr, who stirred up the tech world with his 2003 essay, IT Doesn't Matter in the Harvard Business Review, has published a new book, The Glass Cage, Automation and Us, that looks at the impact of automation of higher-level jobs. It examines the possibility that businesses are moving too quickly to automate white collar jobs. It also argues that the software profession's push to "to ease the strain of thinking is taking a toll on their own [developer] skills." In an interview, Carr was asked if software developers are becoming less capable. He said, "I think in many cases they are. Not in all cases. We see concerns — this is the kind of tricky balancing act that we always have to engage in when we automate — and the question is: Is the automation pushing people up to higher level of skills or is it turning them into machine operators or computer operators — people who end up de-skilled by the process and have less interesting work?
I certainly think we see it in software programming itself. If you can look to integrated development environments, other automated tools, to automate tasks that you have already mastered, and that have thus become routine to you that can free up your time, [that] frees up your mental energy to think about harder problems. On the other hand, if we use automation to simply replace hard work, and therefore prevent you from fully mastering various levels of skills, it can actually have the opposite effect. Instead of lifting you up, it can establish a ceiling above which your mastery can't go because you're simply not practicing the fundamental skills that are required as kind of a baseline to jump to the next level."
I certainly think we see it in software programming itself. If you can look to integrated development environments, other automated tools, to automate tasks that you have already mastered, and that have thus become routine to you that can free up your time, [that] frees up your mental energy to think about harder problems. On the other hand, if we use automation to simply replace hard work, and therefore prevent you from fully mastering various levels of skills, it can actually have the opposite effect. Instead of lifting you up, it can establish a ceiling above which your mastery can't go because you're simply not practicing the fundamental skills that are required as kind of a baseline to jump to the next level."
Wearing shoes prevents you from developing a thick layer of skin on the bottom of your feet.
Farming equipment gave us farmers with weaker muscles and fatter bellies. However, it did give us more food.
Why are programmers singled out? Arguably computer automation is helping everyone. Skills are only important to have if there is value in the skill. I don't think theoretical computer scientists are any less intelligent because they never program in C or C++.
Fredrick Brooks spoke to this idea way back in the 1970's and rightly concluded that programmers are going to be with us forever. The author of TFA needs to read and understand "The Mythical Man-Month" (2nd Edition) by Fredrick P. Brooks, mainly Chapter 16, but likely the whole book. This book should be REQUIRED READING for ANY computer related undergraduate degree program.
There is NO silver bullet. You will always need and have programmers. It was true 30 years ago and it's true now. We have not automated our way out of needing programers to ply their craft. Yes, we have "automated" a lot of logistics around computer operations, but this has ALWAYS been a low skill job. Back in the day they ran punch card readers and hung data tapes, none of which took too much knowledge of computers or programming. You needed a system programmer to make the system do anything different than what it did before. System programming was a highly skilled task.
The names and languages have changed, but you have "operators" and "system programers" still today. We call them Administrators and Programmers today. One operates the machines, loads software, manages backups and keeps paper in the printers, the other comes up with programs and systems that do new and unique things. The latter still requires the unique programming skills.
This author is wrong, and would have known had they done their reading.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Oh please... I'm an old guy who cut his teeth on "C" programs, but your attitude is just wrong.
Tools change, languages change, computers change, methods change, but programming remains the same under all the trappings. Who's a better programmer? One that does Java or one that hacks out Assembly? Neither. Yes the programing model changes and the tokens you use to manipulate this model changes, but I don't care what you code in or how familiar you might be with some past tool I've used, if you program, you use the same skills I used hacking out "C" even if you are using some language I've never heard of.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
You mean the automation tool, make?
Every time something gets easier when it comes to software development, people just push things further (as they should).
Thats why no matter how many versions of Internet Explorer we stop supporting, web development is still a pain in the ass. The moment people stop doing something hard, they just take all the time they saved, and tackle something else that all of a sudden become worth it (ie: supporting mobile operating systems, optimizing stuff with webgl if its available, whatever, you name it)
Things that went from "No way, we don't have time for this!" become standard, and the cycle continues. Every minute we save because a task is automated or redundant, is a minute someone spends doing something that was once impossible. And if that person works for a competitor, you now have to catch up.
Employer's have no incentive to care whether or not their employees are bored.
That may be true, but it has absolutely nothing to do with what OP was about.
What the book author seems to miss is that today, one good person with good development tools (not even necessarily an "IDE" as OP says), can do the work that 20 good people could do 16 years ago. And I know, because I am doing it now AND I was doing it then.
Example: when 2000 rolled around I worked for a programming company (and was VERY bored there, by the way, no matter how hard I worked). I wasn't a manager or receptionist; I coded all day.
Today, on a decent day, I can easily accomplish 20 times as much, because the languages and tools have improved. But that would not be possible if my tools were "dumbing me down".
Author might as well argue that typewriters were nirvana, and word processors made authors stupid.