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."
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.
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.
What makes "the greatest system" depends entirely on what "great" means. If it means "fitting into 500 bytes" or "1ms boot time", etc., then flexibility might be the very last thing that you want.
I've intentionally let the world pass me by, and spent my career learning how to optimize for time & space in several proven stable languages, rather than learn every new widget and buzzword. The drawback is that I'm a little slow when it comes to new tech. But the new shit is way easier to learn than what I've been torturing myself with over the years, and "youngsters" won't catch up to my skill without a decade of practice. And I've never had trouble landing a job.
The grandparent's sorting a list is actually a pretty good example. There are lots of library sort implementations that do a reasonable job over arbitrary data but you can often do a lot better with some knowledge about the data that you're sorting. If you know that you have a roughly even distribution between n ranges and it's cheap to test which of those n ranges your data are in, then you can do a (linear time) bucket sort and then use the off-the-shelf comparison sort to do n sub-sorts in parallel. The generic sorting code can't do this, because it doesn't have enough information: it just has a comparison operator defined on the data. If you understand the underlying concepts then you should know when you can beat a generic implementation with a domain-specific one. If you've had a bit of experience then you should know when it's not worth bothering.
I am TheRaven on Soylent News
The analogy I like to use when discussing the Art vs. Engineering paradigm in programming is architecture (the wood & steel building sort, not hardware chip instructions) design. Every architect, whether building a private home or an office complex, needs to know certain fundamental facts about the materials they use (load bearing capacity, for instance) and the choice of what materials are used is (typically) dictated by the intended purpose of a building. Brick and wood framing is pretty universal, but you don't generally see homes being built out of little more than tin siding and steel frames like factory warehouses, or giant glass walls like skyscrapers.
That part -- mating the materials with the intended purpose -- is the "art" in architecture. The "art" in programming (aside from some limited domains like UX or AI) is less immediately describable except by effect (e.g. "How quickly do new team members get up to speed?") but should be no less important to any project manager. I don't really think that programming has been around long enough for us to have our Frank Lloyd Wright moment, but that is no reason to ignore the "intangibles" and immeasurable aspects to quality code.
Do you like Japanese imports?