New Book Argues Automation Is Making Software Developers Less Capable 212
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."
This is true of anything. (Score:5, Insightful)
Wearing shoes prevents you from developing a thick layer of skin on the bottom of your feet.
Re: This is true of anything. (Score:4, Funny)
Also toilet paper instead of using poison oak
Re: (Score:2)
The key is preserving the choice to go barefoot. Tools give us more choice.
If you want to break through that glass ceiling the summary mentions, you can take up the fundamental skills on your own, at your own pace. MOOCs are a good place to start.
I think the goal should be Star Trek holodeck computers that you can program in natural language, with general statements. Maybe you choose a program in which you debug vacuum tubes by cleaning out the bugs in them, or whatever you want. Punchcards? Assembler? Your
Re: (Score:2)
Have you ever noticed how on Star Trek, when they really need to pull off some tricky, urgent bit of programming, they quit talking to the computer and start typing?
Re: (Score:2)
That's because Star Trek is a tv series, and as such follows the rules of drama rather than physics or logic. Having the characters randomly tap a touchscreen rather than speaking aloud lets the writers avoid specifying the details of the commands given, sparing the audience pointless technobabble and freeing the dialogue for drama.
And Self-Actualization is not the goal. (Score:2, Informative)
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.
Indi
Re:And Self-Actualization is not the goal. (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
Employer's have no incentive to care whether or not their employees are bored
That is just categorically wrong, in any industry. It's laughable in the software industry where getting and keeping employees is one of the biggest challenges.
You obviously don't work in the software industry. Employers not only tolerate all kinds of non productive things, they actively encourage them. Software engineers are treated like spoiled, geeky royalty.
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.
OK, now I know you don't work in software engineering. Or any engineering. Trying to convince our employer to do things that are less profitable b
Re: (Score:3)
You forget how many people have lost their jobs ot cheap er workers. You forget how many H1B visas are demanded by US tech companies because "they can;t find skilled staff" hours after firing a load of skilled employees.
See, programming is a new form of menial work. Why bother hiring me at huge salary when you can hire someone with a degree from a 3rd world country to click the right menu options in an IDE and cut and paste code they find on Google? The results are roughly the same, it sortof works, and tha
Re: (Score:2)
We automate in order to reduce the costs of development, so we can maximize profits.
That's like saying that we use machinery in order to maximize profits. I thought we were using machinery to maximize productivity to generate as much wealth with as many people possible so that people could have a house and a car and a computer, instead of just the house because everyone is busy juggling bricks and nobody has the time to build cars and computers. The same goes for programs; if there's a finite supply of developers but an essentially unlimited (or at least vast) space for potential useful pr
Re: (Score:2)
That's true, but... (Score:4, Insightful)
Farming equipment gave us farmers with weaker muscles and fatter bellies. However, it did give us more food.
Re:That's true, but... (Score:5, Insightful)
Farming equipment gave us farmers with weaker muscles and fatter bellies. However, it did give us more food.
This. That modern developers suck at assembler is a bad thing assumes there's a reason you'd want them doing assembler in the first place. If a farmer's tractor breaks down he doesn't get out and start shoveling, he calls for a tractor repairman which specializes in that sort of thing. If you call a low level library from a high level language and it crashes, check the documentation again. If you're still sure you're doing it right, the efficient thing to do might be to file a bug and let someone used to poking around in C/ASM take a look at it. It's specialization at work and it might not make sense for one person to know the whole stack top to bottom. Or at least that person would be a guru and companies aren't full of those.
It doesn't take poking around at the lowest level to find a hard problem. If you haven't had user requirements that make you feel like you're playing twister trying to fulfill all the requirements at once you can't have worked much on complex projects at all. And for each new round you have to hit another new requirement, screw the initial specification. Or when you realize the whole stack is built wrong for what their real requirements are and you have to unravel and reassemble it differently. Having modules and glue code might not be glamorous but when you're chasing a moving target being agile beats having built the greatest system nobody wants anymore.
Re:That's true, but... (Score:4, Insightful)
I don't have enough in-depth knowledge to know to what extent de-skilling is really happening
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
Re: (Score:3)
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I'll second that. I've been coding professionally for almost 20 years. Even done some assembly. Yes the tools are much better and more is automated, but the amount you need to know is only growing, and the expectations have never been higher. I don't think the automation is even keeping up actually. Making software is not getting easier.
Re: (Score:2)
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I disagree. Automation has definitely made a lot of things easier, but it's been offset by an increase in requirements. Autocomplete for APIs, for example, popping up a snippet of documentation when you're typing is essential on some of the APIs I work with today, with hundreds of classes each of which have dozens of methods - remembering the exact name of the one that you might use once a year is impossible (especially when it's code that Google people work on and so randomly do bulk refactoring runs ren
Re: (Score:2)
Ah that brings back memories - the IBM documentation bibles I had for OS2 programming were bliss. If I needed to know *anything*, I looked it up.
Today, its a combination of intellisense guesswork, google and trial-and-error coding :-(
I'd like to say that going back to the old days would be good, but we have too many languages, too much refactoring in APIs, too many 'cool new things'. No-one could go back to the concept of building on top of what is already there in a stable, mature manner (well, except the
Re: (Score:2)
but when you're chasing a moving target being agile beats having built the greatest system nobody wants anymore.
IF it's not flexible, then it's not the 'greatest system.'
Re: (Score:3, Interesting)
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 wha
Re: (Score:2)
and spent my career learning how to optimize for time & space in several proven stable languages,
Do you get paid for that? What languages?
Re: (Score:2)
Someone has to build the automation. So at the beginning at least, someone needs to understand the relationship between the automation results and the underlying, non-automated truth. To develop the automation software further, someone needs to know the fundamentals to be able to say if it's better or worse that the current version.
Are you saying that the skills needed to develop the software don't need to exist? Or that they will always exist? If we automate everything, in other words, who will fix you
Re: (Score:3)
Re: (Score:2)
I agree with the first half of your statement, but where did you get the idea that the percentage of self-taught developers is increasing? I was under the impression that it was decreasing, with the difference being taken up with people with diploma-mill (or Indian diploma-mill) pseudo-degrees.
Re: (Score:2)
Or worse, imagine that they do understand they have to fill the tractors with gasoline... but the tractors run on diesel. (And then they wonder why the tractor engine keeps blowing up.)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
With that change, does your argument still make sense?
Not all programmers need to be superhuman experts at assembly, but every single damn one of them needs to understand (for example) memory allocation.
Re: (Score:2)
Farm equipment is far more complex than in the old days, just like cars. "Fix it yourself" passed away a long time ago.
Re: (Score:3, Insightful)
Farming equipment gave us farmers with weaker muscles and fatter bellies. However, it did give us more food.
That is not really what TFA is talking about. Automation of farming has removed the labor, but not the knowledge. It has not caused farmers to forget how to farm.
A better example is aircraft automation. Some fly-by-wire systems automated the routine stuff, of controlling and stabilizing the aircraft, but would drop out to manual control if the situation went outside the programmed parameters. This led to the crash of Air France 296 [wikipedia.org] when the autopilot was disabled because of the low altitude during an ai
Re: (Score:2)
But that's just the point, some don't need to know what's going on underneath.
Look, Just because the programming model (that virtual picture in your head that represents what you are programming) is different between various programming languages, it doesn't mean it doesn't take skill to ply the programming craft. Who cares how to most efficiently sort some array if you depend upon a library to do the sorting for you? Maybe the data doesn't actually exist in the computer memory like you think? Usually a l
dev world vs medical world (Score:3)
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.
Re: (Score:2)
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.
Imagine you're out in the middle of nowhere with a life-threatening trauma wound and there is only one doctor available.
Re:That's true, but... (Score:5, Insightful)
There is functional requirements and non-functional requirements, both are important for the projects to be successful. I was on a team creating a moderately complex system. One of the programmers checked in a perfectly correct functional code but did not meet the performance requirement. The conversation went something like this.
Me: Your code works fine but I need it to be 5 times faster.
Coder: [Looking at me like I just turned green and grew horns] Can't we just up the hardware requirement.
Me: Sure, if you want our customers carrying around laptops the size of suitcases.
Coder: All I do, in the code, is call the library functions.
Me: The library function is totally inefficient for the algorithm you are trying to implement. You need to recode the function manually.
Coder: But how do I do that.
Me: You need to write it in OpenCL and use the GPU.
Coder: [Turns white as a ghost]
If you want your skills to be more than sorting a list or changing the color of the font, you have to know what is going on underneath.
Re:That's true, but... (Score:4, Interesting)
Re:That's true, but... (Score:4, Insightful)
That is not really what TFA is talking about. Automation of farming has removed the labor, but not the knowledge. It has not caused farmers to forget how to farm.
Automation of farming removed the knowledge of how to farm without the automation. Like another post said, when a tractor breaks down the farmer doesn't grab a shovel. He calls his mechanic. My dad is a farmer who is 64 years old, and even he doesn't remember how to farm like his grandfather did.
Re: (Score:2)
Kids are still taught algorithms and data structures, which exposes them to things like big O notation and why hash tables are really fast at lookups. They don't need to know assembly (or any specific language) to understand these logical concepts. Run time complexity like you describe is a high level concept, honestly!
It's not about shaving a few %'s off by optimizing in assembly - it's about choosing a hash tab
Re: (Score:2)
This led to the crash of Air France 296 [wikipedia.org] when the autopilot was disabled because of the low altitude during an air show flyover, and it turned out that the pilot didn't know how to fly the plane because he had relied on the computer far more than even he had realized.
Based on the linked page, your description seems somewhat inaccurate. Wikipedia states that after TOGA power was applied, the captain's attempt to pull up failed, because the flight computer overruled his decision to pitch up. It wasn't that the pilot didn't know how to fly the plane, but that he didn't understand how the - actually still active - flight computer would limit control surface movements near the aircraft's stall speed.
Of course, a pilot should be aware of any additional flight envelope limitat
Re: (Score:3)
Kids today often have no idea how computers even work, and sometimes have very dysfunctional mental models of what is going on.
And they gobble their food, talk back to their parents and tyrranize their teachers?
Back in MY day, all the kids cut their teeth on various forms of BASIC. We had about as much idea initially about what was going on underneath as kids these days do: i.e. none.
Some of us dug deeper just as kids these days will. Some of us started fooling with low level things like peek and poke on si
Re: (Score:2)
A better example is aircraft automation. Some fly-by-wire systems automated the routine stuff, of controlling and stabilizing the aircraft, but would drop out to manual control if the situation went outside the programmed parameters. This led to the crash of Air France 296 [wikipedia.org] when the autopilot was disabled because of the low altitude during an air show flyover, and it turned out that the pilot didn't know how to fly the plane because he had relied on the computer far more than even he had realized. When the computer shut down, the pilot was unable to perform the "low level" task of keeping the plane in controlled wing-level flight.
Not to be pedantic, but the linked article doesn't say that at all. The pilot and co-pilot both had 20+ years experience. In fact the Captain was an Air France test pilot and "he had been heavily involved in test flying the A320 type and had carried out manoeuvres beyond normal operational limitations". The crash investigation found that the cause was flying too low (30 feet, instead of the designated minimum 100 feet) and too slow (running the engines at Flight Idle - minimum thrust), and consequently n
Re: (Score:2)
Farming equipment is pretty standardized. Automation in software creation binds developers to a specific tool and what they learn is using that tool, not creating software. They turn into one-trick ponies.
Computers are making everyone's life easier (Score:5, Insightful)
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++.
Re:Computers are making everyone's life easier (Score:4, Insightful)
Theoretical computer scientists might be intelligent but in my experience they make bad programmers. Computer science professors are almost always really bad programmers. Good programmers are more artist than scientist. And you can't automate art.
Also, I don't know what automation is being referenced because I never met an IDE I didn't hate. And as far as build tools go, the whole automake, autoconf, libtool tool-chain is a bad joke. I wish that stuff were automated. But right now it all seems to be very manual to me.
Re: (Score:3)
Programming is far more Engineering than Art. The people that think it's Art are the uneducated ones reinventing the wheel.
I do agree with build tools though. Usually end up scripting those myself.
Re: (Score:3)
That really depends more on what you're programming and your work environment. If you're writing rocket control systems for nasa or the HUD for the Joint Strike Fighter then you will certainly be approaching it with more engineering skills than art skills. Conversely, if you're working on an indie game as a passion project, then likely you will utilise more art skills. Both approaches need to use the problem solving skills, but one gives the programmer more freedom to experiment and express themselves, and
Re: (Score:2)
If you feel it's just engineering, then maybe it's time for a change or perhaps some home project that reawakens the magic and art of programming for you again.
I don't think you understand the meaning of word engineering. Engineering and art are not mutually exclusive.
From a professional engineering perceptive what you are calling art is far closer to engineering than what you are calling engineering and once you start repeating processes without redesigning them you are no longer engineering at all.
Re: (Score:2)
Hey I want to drop by and thank you for your comment, it says everything I am going through right now, developing boring business apps and all that. I am in the process of going back to college to get a PhD working with AR and VR (maybe with the Unreal Engine) and hope I have the same experiences you had.
Re: (Score:2)
I think you'll love it. I've tried out Unreal Engine and it's a really great environment to develop with. It has a great toolkit and the code is really sweet looking and tidy. For me though, the look and power of CRYENGINE is worth the much higher pain and learning curve :D I've picked up an Oculus Rift DK2 kit and had a bit of a run around using that gear - it's like a little taste of the future. CRYENGINE doesn't support it yet, but there's talk they will in the future.
On a personal level, I really hope y
Re: (Score:2)
I was thinking of going with the Unreal because of Oculus support and I heard good things about the development environment (unfortunately Unreal SDK does not support my platform of choice, Linux, but I can live with that). One thing that I am afraid of is building in C++, I do not have extensive C++ experience and I am afraid of missing the easy of use of untyped languages too much. I program mainly in Javascript these days, but I do a lot of coding in Java too and I find it very unpleasant.
Thanks for the
Re: (Score:2)
I'm happy if I can put down my algorithm in a nice and eloquent way and have it work, but I don't call that art.
The "eloquence" (or lack thereof) is where the "art" is. I think it's apt to describe something in which subjective judgments of aesthetics as containing an element of art.
Re: (Score:3, Interesting)
Re: (Score:2)
Have you ever used Maven?
Also I hate all OSs I ever used as well...
Re: (Score:2)
If a programmer constructed things out of all sorts of middleware/frameworks and automation they did not understand, they are ill-equipped to handle unexpected consequences.
With closed-source libraries, sure. Otherwise, the past tense "did" is key. When something goes wrong with the (open-source) libraries I'm using, then I will come to understand what I previously did not. In the end I still come out saving time.
knowledge of how to build engines is a necessary part of his job to fix engines built by others.
This confuses knowing "how to build an engine" and "how an engine is built." A mechanic needs to know the latter, but not the former. Most auto mechanics are not also skilled metal workers - or, given today's car fabrication processes, roboticists.
Not just the skills (Score:2)
Why worry? (Score:2)
After all, like he said, "IT doesn't matter".
It's true, though. IDEs full of wizards and other magic make it look like less-capable (cheaper) people can do software. So that's what management hires.
Problem is, the IDEs can make a capable developer's job easier, but an incapable developer becomes utterly lost when the IDE falls short or breaks down.
Oh here we go again... (Score:5, Insightful)
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.
Re:Oh here we go again... (Score:5, Insightful)
The latter still requires the unique programming skills.
But they are different skills, and more powerful tools necessarily imply that what used to be highly skilled jobs are now not so skilled.
Automation isn't making programers dumber, it's allowing dumber people to be programmers, or dumber programmers to do harder things. It's been this way forever. 99% of programers working today couldn't have toggled firmware into a 6502 and made it run. Fortunately, they don't have to.
I'm old enough to have known programmers who still were kind of suspicious of these new-fangled "compilers", and I've actually programmed on punch cards, and collected data on a machine that booted from paper tape (there were no working tape punches left, so the lifetime of the machine was dependent on taking really good care of the few remaining tapes...)
All of that has gone away, and the skills programmers needed in those days have gone with it. That's a good thing, although it kind of sucks for people who put in thousands of hours honing skills that are now irrelevant.
Re: (Score:2)
Read the book.... Not the one the article is about but "The Mythical Man Month" by Fredrick P. Brooks, Jr. Specifically Chapter 16 (and 17 if you are lucky enough to get the 20'th anniversary edition.)
This book is 30 years old and STILL speaks truth about what software engineering really is. The book discussed in the above article is from some newbie who doesn't know computer history and has fallen for the color glossy sales literature from software tool vendors.
Re: (Score:2)
As cool as flipping a bunch of switches sounds, the smart programmers hand wrote their assembly code then entered it into the machine using a line editor into a BASIC programme that would assemble it into binary. There were two ways to get binary code into my old OSI C1P Challenger, one was to punch in a series of two digit numbers, which you would first have needed to hand assemble and convert to the binary operands using a table...the other was write an assembler and simply type it straight into the machi
Re: (Score:2)
"But they are different skills, and more powerful tools necessarily imply that what used to be highly skilled jobs are now not so skilled."
No it doesn't necessarily imply that, in fact, it doesn't imply that at all and it isn't true.
Systems have gotten more complex with more technologies and more moving parts than ever before. The complexity has simply moved from the underlying technologies being complex to the overall problem being complex.
Even the most basic non-trivial web applications now will often req
Re: (Score:2)
Today a lot of work that used to be custom programming is now done by software packages that require consultants to configure the tool instead of programmers. All the system analyst work is still required, but not nearly as many programmers (you still need some to configure the tool to do stuff it can not do out of the box). In total these tools require less people to perform the same job, but the result is never really customized specifically to the client (you need to adapt many of the requirements to the
Re: (Score:2)
I wonder if my The Mythical Man-Month book is still valid from the mid (19)90s.
Re: (Score:2)
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.
Exactly.
The key is the ability to break down complex problems, and model them somewhat in your head before you model them in tools. The tools change and improve, sure, but you will always need programmers.
Accidental vs Essential Complexity (Score:5, Informative)
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
time to forum a union (Score:2)
time to forum a union before your automated out of a job or are one of few people left likely pulling 60-80 hour weeks.
Re: (Score:2)
Or have robots form a union, then have management outsource the work to humans as a cheaper labor solution.
Bullshit (Score:3)
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.
Re: (Score:2)
Therefore yes: we're "less capable" because we can't keep up with their fads...
Part of expertise is knowing when to ignore fads. This may require faking it well enough to get along for a while.
What *is* the hard work. (Score:5, Interesting)
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.
Re: (Score:2)
Once a task has been automated to the point that a reliable mass market tool is available to do the work for you, what possible reason can there still be to do it by hand any more? We use computers precisely because they automate mundane tasks. Should we switch back to having women working old switchboards to make a phone call just so we can preserve that no longer needed skill? Should farmers plough their fields using oxen just so they retain a skill that's no longer relevant? Should programmers have to wr
Re: (Score:2)
Fair point. But one remaining reason to have done it yourself is to understand how the tool actually works behind the scenes. And that deeper understanding is generally what separates a master of the craft from dabblers.
Slightly different field, but, for instance, if you are doing any amount of real numerical programming, you real
by hand until you understand, so you can unfuck (Score:2)
> what possible reason can there still be to do it by hand any more?
My baby daughter will probably always have a smartphone / calculator with her when she grows up. She'll have a tool that can so arithmetic for her. Yet, I plan to teach her arithmetic with jelly beans, hands on, doing it manually, so that she UNDERSTANDS what multiplication is all about. Once she really understands it, she'll know when and how to use it. She can then use the calculator as a shortcut, but use it effectively.
I do the
Re: (Score:2)
Yet, I plan to teach her arithmetic with jelly beans, hands on, doing it manually, so that she UNDERSTANDS what multiplication is all about. Once she really understands it, she'll know when and how to use it. She can then use the calculator as a shortcut, but use it effectively.
There are a few questions to ask about this sort of teaching:
In the case of simple arithmetic, if you include the time of getting the phone out of your pocket, then the answer should be yes to all of them - it's just useful. The education system (in the UK, at least) unfortunately tries to take the same approach for things like calculus. You can understand how to so
The job never gets easier (Score:5, Insightful)
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.
Better tools isn't the problem... (Score:3)
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.
Re: (Score:3)
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.
At least one US doctor tried implementing something like a precursor to this [newyorker.com] and got some pretty interesting results.
I forgot how to use a slide rule ... (Score:3)
... but so what?
My calc tools elevate me way beyond that inaccurate analog piece of crap.
Re: (Score:2)
Few mathematicians know how to create Mathematica from scratch.
By that argument (Score:3)
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/ [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.
Testing (Score:5, Interesting)
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.
Re: (Score:2)
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.
Yup. Unit tests are great, unless they are used as an excuse for the programmer to turn his brain off. You can't test every case with unit tests, you still need to think.
Re: (Score:3)
I've found tests to be mostly useless when it comes to finding bugs, if you could think of the test you'd also make sure the code handles it. What they're invaluable for is testing regressions, so many times doing a seemingly innocent change would break things. Sadly I've found that for anything other than a one man project they are just positive proof, yes you broke something and not negative proof, no you didn't break anything. Just like comments you can never be sure they're really correct and complete,
Re: (Score:2)
THIS THIS THIS
As a software engineer (now half-suity) of twenty years, I am constantly frustrated by those newer to the profession who got caught up in the whole "Unit Tests are Sacrosanct" philosophy. I have worked with multiple engineers who value "testability" over "working".
Unit tests are convenient, a handy tool for prog
The problem is... (Score:3)
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.
Hand crafted, as in beer (Score:2)
Hand crafted code and makefiles will probably yield a superior result.
Studies showing the errors per thousands of lines of code in open-source vs proprietary software, time and time again, seems to support such an assertion.
Computers will never replace understanding (Score:2)
Remember Crystal Reports? This was a tool that came out in 1991, that was supposed to make it possible for ANYONE to create their own business reports. No programming know-how needed. Remember?
For the past three years, I ran a team that created customized Crystal Reports for customers...because they couldn't figure out how to create them for themselves. It wasn't so much that the tool was hard to use, but more that the customers had only a foggy idea of what they wanted their reports to show.
For example
Re: (Score:2, Interesting)
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 wor
sounds a lot like an argument I hear a lot (Score:2)
Re: (Score:2)
Re: (Score:2)
C is not going anywhere any time soon.
I think it's a myth that people aren't learning C. I interview a lot of devs, many just out of college. Most of them know C/C++. They may be more comfortable with Java/C#/whatever, but they at least know C++ syntax and understand the memory model, etc. It would make no sense for universities to ignore C/C++, if for no other reason than the huge amount of code out there in those languages that you may need to understand. Kids in CS these days are still writing their own compilers, toy OSs and memory managers
Re: (Score:2)
Re:Sad.... (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Kids These Days!
You are right! Mythical Man Month to the rescue!
There truly is NOTHING new under the sun... Trust me kids, we thought we where hot stuff too, we where just as wrong as this book's author is. Slightly different spin, but Chapter 16 and 17 still apply. If you don't know what I'm talking about, look it up on Google...
Re: (Score:2)
Cars make people worse at riding horses.
But you can wreak a car a LOT faster and easier than a horse.
Re: (Score:2)
I agree that jQuery has it's flaws, but it is also a godsend in many other ways. The company I'm currently working for writes web applications for K-12. Some of our customers are running XP with IE7, others are using iPads, Chromebooks, and everything in-between. While the majority of the client-side code is just in plain JavaScript, we've started incorporating some HTML5 functionality into our products recently, unfortunately some of the older browsers are a bit lacking in support. Often times jQuery will
Re: (Score:3)
Re: (Score:2)
I learned to program in Lisp -- specifically scheme, because that's what they taught at MIT. I spent many years working in K&R C. I belong to the generation that learned to do actually useful programming from The Unix Programming Environment [amazon.com] and Software Tools in C [amazon.com] -- God help me, I actually spent a year programming in Ratfor [wikipedia.org] targeting Fortran IV [wikipedia.org] as a back end.. I've used most of the major languages that have come down the pike since -- C++, Java, Python, PHP, blah blah blah.
Javascript feels an awful l
Re: (Score:2)
For the record, and not to your individual situation, the article is warning people away from having a business full of ignorant people.
You (not roman_mir specifically) can have lego-assembling window-lickers if that fits your bottom line. It is not necessary to require understanding from everyone.