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
Please re-read:
Brooks, F. P. , J. (1987). "No Silver Bullet—Essence and Accidents of Software Engineering". Computer 20 (4): 10. doi:10.1109/MC.1987.1663532
http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
Automation removes accidental complexity. /discussion
Automating stuff means I am more effective and I have more time to write /. comments and this is good because sometimes solving hard problems means I should just chill for a while, while the automation does the work. Automation doesn't make me less capable, but it does mean that I have 3 times the output of anyone else around me, making me more relaxed and generally easier going while people wonder how I do it.
Automation makes me smart lazy and achieving that is hard work.
My ism, it's full of beliefs.
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
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.
While I'm sitting here reading about other people bitching about abstraction libraries such as jQuery, my first thought was actually about testing processes.
Pretty much everywhere I look online, projects are FLOODED with automated testing tools to ensure their code works. And sure enough, every bug that I submit has an "automated test" that didn't test that particular condition. Developers are relying more upon these testing tools and less upon actually USING their own services they're developing to ensure they work properly.
A great example: a recent bug I had to file was brain dead simple. File opening ignored current working directory, so if you changed directories, the file open command would still assume you're in the base directory. Why wasn't this caught? All of their file handling automated testing routines ONLY checked absolute paths, none checked relative paths. On top of that, when they finally did add relative path testing after my bug report, they only added it as relative to the base path, and not testing against current working directory.
Now, let's think about this for a second. How long has the concept of changing directories been around? While most of us will go "oh, DUH!" to the bug mentioned above, newer developers may simply not be in that same mindset, because they're not actively traversing their filesystems themselves. The automated toolkits are doing all that work for them, leaving the developers less experienced in this area, and thus less forethought when building the next generation of tools to test these exact sorts of issues. It is a downward spiral.
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.