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