November 11, 2022 at 12:00 am
Comments posted to this topic are about the item Losing Skills Because of Automation
November 11, 2022 at 5:54 am
I don't believe that automation is the cause of a lack of skills. I rather think it's the other way around... Automation has become necessary due to a lack of skills. I also believe that the lack of skills has been caused by disillusioned people that have "grown" a lack of intellectual curiosity. They just want to do 9-to-5 and be done with the day.
If you don't think so, spend some time looking at the posts on this and other forums. I mean REALLY look into them.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2022 at 6:54 am
For me there are two main aspects to this.
The first one is that in computing the only constant is change. A skill that would give top pay in year 1 may not land any job in year 5. Devops automation is part of this.
People new to Devops should expect to need to learn new skills. It is part of having a career in computing. Ultimately, anyone who cannot cope with this needs to find a different career path - there will always be new skills to learn and old ones to discard. It is part of managing your own career and building your own brand.
Low code/no code is nothing new, and like other skills the individual approaches will come and go. Anyone remember JSP or CSP from 1980 mainframe days? Anyone still using any of it now?
The other aspect is that too often business will do almost anything to get and keep experienced staff except train them or pay them more. It is true that people are fungible but domain knowledge is not.
The best people to develop a new system are those already having domain knowledge of the business, it is normally more effective to add a layer of new skills (Devops or whatever) to an existing team than try to add a layer of domain knowledge to a collection of newbies who know the new skill.
Oldies such as me may lament that few younger staff know how to interpret a memory dump to find where the language interpreter/compiler got it wrong and be able to code a work-around to overcome it. The truth is that very few people need these skills, even if once a year they may be vital. For me it goes back to building your own brand. Some will see an opening into premium employment that includes these troubleshooting skills. Others will go down a different path that bring other skills to the business. A competent CTO will seek to have people with the skill mix the business needs.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
November 11, 2022 at 1:42 pm
Skills atrophy if not used.
Back in the days of the Model T you had to know how to hand-crank the car to start it. Knowing how to remove the cylinder heads to de-coke the pistons was almost an essential skill. Further back you had to know how to curry a horse, and all the vast array of skills of animal handling to survive.
When's the last time you needed to know how to shoe a horse? 🙂
Automation is no different. Our industry has a sadistic delight in reinventing the wheel. Some of it is good--remember the days of RPG and 80 column punch cards? Do you still know how to automate a keypunch machine? How about running a card sorter? Or wiring a board for a card interpreter?
But some of it is horrible. The way we have to cobble together systems that are actively hostile to interoperation is a constant pain that should not be. The constant deluge of new programming languages are largely ego projects by companies seeking monetary dominion and offer no real practical advantages. Sure, some are better suited to narrow application niches, but how many programming languages now exist? How many existed in the past that no one remembers?
How many people need to create Make files? How many need to know Cobol or RPG these days?
I can't remember how many languages and dialects of programming languages I've learned over the decades. The number certainly exceeds 50, probably approaching 100. How many am I currently using?
TWO. And one of them is for front-end development while the other is for the back end.
I'm a lone wolf programmer, a whole devops team in and of myself. Been that way most of my career. I learned a hard lesson in that time. When you have to do everything yourself you learn to pick and choose your battles. Given the choice of deep knowlege of a few languages and tools versus shallow knowledge about many tools and languages it's better to have deep knowledge on a few things when you don't have a team to spread the load.
In my experience automating the grunt work is a god-send. I don't have time to spend doing things a computer can (and should) do. Compilers being a prime example. Would you really want to have to compile a program from source to machine language by hand?
Didn't think so.... 🙂
November 11, 2022 at 4:01 pm
I've found that automation isn't the reason for decreased skills. Rather, I've found that automation is necessary because people simply don't have the skills and, apparently, have little interest in increasing those skills (look at the questions being asked on this and other forums if you have a doubt there).
That and the fact that people are barraged with "new and better ways" of doing the same thing but require different knowledge, syntax, and skills to do the same thing, frequently with less effectiveness especially since people don't have the time to become an expert on the current "shiny stone" because they know the next new "shiny stone" is going to negate any skills they may have acquired for the current "too-cool-for-school" and "gotta keep up with Jones' " rendition.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2022 at 11:21 am
I see automation as an excellent opportunity to focus on development and interesting stuff like problem-solving by automating routine work to free up time.
😎
November 17, 2022 at 3:07 pm
Interesting post, Steve.
I agree that modern environments with rich GUIs take away the need to learn "what's really happening". Sometimes that's fine. When I'm driving, I don't want to know what the carburetor is doing. Occasionally we do need to know.
In both medicine and software development, people fresh out of school know different, and in many cases, *better* techniques and practices than their more senior colleagues. What they're missing is the practical experience and humility that comes with having made mistakes enough times.
My father worked in Assembler on machines with 8K of memory (yes, K). I don't have that knowledge, but I also don't see how it could possibly help me to do my job today. Okay, that was a pointless digression, sorry.
The real difference today is that people like roger.plowman (lone wolf programmer) are becoming rarer. We specialize. I think that's a bigger loss of skills than the automation. Sometimes it takes a committee to get things done.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply