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
I think it depends on the individual's capabilities. For example (I am not a dev) several years ago I decided it was time to learn a programming language. Because my PC and all work environments were Windows, I decided I should start with C# and WinForms. I created a new project in my Visual Studio Express and it went off and created all kinds of files and tree structures automatically. I then followed tutorials clicking things and designing my GUI app. But I didn't really understand. So the next day at work I asked some professional developers about all the various little files that got created.
It was an eye opener for me that many didn't actually know. They had a general idea (e.g. .cs files) but to them it was so irrelevant they just never bothered. I eventually gave up. Several years later I wrote some scripts in Powershell and my boss wanted a gui. So I went off and started learning about the WinForms class on MSDN. I can now looking back basically understand what I did back then. Because doing things in powershell I had to manually create each object by hand. Properties, events and methods made a lot more sense now.
Someone like me could only ever be a very mediocre programmer. But someone like me paired with a tool like Visual Studio can (for a time) pass for a higher level programmer without the underlying competence. You see the same stuff all through I.T. People who think they know what is going on, but actually everything they know is limited or framed by the more intelligent tool they used to solve the problem. Then they'll meet someone who actually 'gets' a few levels above or below their current position in 'the stack'. Those guys are truly competent. They use all kinds of tools, but the tools are shorthand for their existing knowledge, not a crutch for their ignorance. These 2 kinds of I.T worker will view this book differently.
It's not automation that's making us "less capable". It's the incessant expectation that we - (software) engineers - be senior, mono-maniacal, obsessive-compulsive, experts in whatever the bloody fad du jour is. That's because darn management and HR dolts have no clue how to assess an engineer, yet expect to make the decision.
Therefore yes: we're "less capable" because we can't keep up with their fads... go fuck yourself. Seriously.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
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.
The summary seems a bit misleading. The main thrust of page I saw what that the push to replace work with automation can have consequences at a certain level. Does decision making really work well in automation, or does it lead to problems? There's evidence in both camps. An example, some traders on Wall Street have complained about removing people from the process, they that really do add value at times. And sure, it's hard to imagine a human would issue a massive amount of bad orders, but a computer model with a bit of glitch might. But, is that enough to slow things down. Just one example of many.
In my mind, critical thinking does have value, and no, there is nothing in data science, machine learning, etc. that really comes even close to what humans can do in that area. There's a big debate in Medicine about following best practices and if just following algorithms would work better. Some note it would reduce unneeded tests and procedures. Others have noted that actually, doctors are much better at noting when something is going really wrong and that following a script could lead to unnecessary deaths that would be avoided by relying on clinical judgment. Is there is a need for better data? Sure, but can you really automate judgment? And what real value is there of taking the craft out of everything for humanity as a whole?
The problem is that some people don't think software engineering, programming, coding, whatever requires critical thinking, or that there is a craft or art to programming. And you can increasingly do it that way. Cut and paste, copy from the web, and when things don't work out, post on the web and hope somebody answers.
What is lost is somebody has to have the skills to figure out what is going wrong or that it can be done better. Where do those answers come from on the web after all? At some point, somebody has to know how to actually approach the problem from the fundamentals and solve it, and that's when all those things that we (okay, at least me and my schoolmates) studied in CS come into play.
I'm on a project and they are just throwing idea after idea to figure out a performance problem. Sure, it's tricky, but I realize, they have a huge blind spot. They don't know how to attach a low-level debugger to a process, to monitor OS resources, or even realize that you can debug something without sources. Sure, it's a Java enterprise application, so that's another layer of hard, but it can be done. Cripes, we had to debug core dumps. I'm glad (thrilled) that I don't have to do it anymore, but the skills that I learned doing it were invaluable.
A related aside. The problem is not better tools, it is not knowing there are better (or any) tools or that you can make better tools.
... but so what?
My calc tools elevate me way beyond that inaccurate analog piece of crap.
It little behooves the best of us to comment on the rest of us.
By that argument, we should have a serious shortage of mathematicians since the invention of the scientific calculator.
We should also have a lot of bookkeeppers and no accountants.
Automation reduces the "grunt work"; it does not remove the need to think. If your job can be accomplished purely through the "grunt work" done by something like http://msscodefactory.sourceforge.net/ without you having to do any customization work or handle any special cases that aren't automated, you were never a real programmer to begin with, and your project was a joke in the first place.
I do not fail; I succeed at finding out what does not work.
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.
In the dev world, we are required to do all things from R&D , BA, coding, testing, tech writing.
In the medical world, the ops table has 12 people each with minor specialization.
Imagine if there was one doctor doing the prep, drugs, cleaning, cutting, sewing up, the works.
Liberty freedom are no1, not dicks in suits.
that as time goes on, you end up using more and more complicated and advanced tools (oftentimes built out of a multitude of 3rd-party components that get sewn together like a sort of Frankenstein monster). As long as everything works properly everything is fine. But when they stop working for some reason, you have a problem. As a developer, the inner workings of the tools are by design pretty opaque, and yes in *theory* you can download the source and try and debug the thing yourself, but that's an incredibly poor use of ones time.
We automate in order to reduce the costs of development, so we can maximize profits.
That is the only reason. Employer's have no incentive to care whether or not their employees are bored. They don't pay their employees to like their work. They pay their employees to do their work. And if automation makes that cheaper, then full speed ahead! If automation means I can hire a stupider, and hence cheaper, class of laborer, then I win again! Concerns about the long-term cultural implications be damned.
Individual software developers might occasionally write a script that automates some tedious thing they frequently do. That is different, since it is employee-initiated and is an effort at avoiding boredom. The employer tolerates this behavior so long as the net effect is either neutral or positive in terms of productivity. The moment you, as an employee, start arguing that you should invest the employer's time in something that is less profitable but more interesting, you will be replaced.
Yeah, I miss the days when we coders worked closer to the metal, calling getelementid directly instead of using some high level abstraction like jquery.
So, when the tractor breaks, the farmer fixes the tractor.
Maybe when your grandpa was a farmer this was true, but today the farmer calls his mechanic. The proportion of farmers who can fix their own high tech equipment is likely not that different than the proportion of developers who can debug low level code.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Assembly? That's for you mollycoddled youngsters. You don't know how to really program until you've entered raw machine code via toggle switches on the front panel of a CPU you built yourself out of nothing but vacuum tubes and a spool of wire. And don't get me started on macro assemblers! You may as well be using COBOL if you need training wheels that big.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.