Slashdot Mirror
Why Learning To Code Won't Save Your Job (fastcompany.com)
Over the years, several governments and organizations have become increasingly focused on teaching kids how to code. It has given rise to startups such as Codecademy, KhanAcademy and Code.org that are making it easier and more affordable for many to learn how to program. Many believe that becoming literate in code is as essential as being educated in language, science, and math. But can this guarantee you a job? And can coding help you save that job? An anonymous reader cites an interesting article on Fast Company which sheds more light into this: Looking for job security in the knowledge economy? Just learn to code. At least, that's what we've been telling young professionals and mid-career workers alike who want to hack it in the modern workforce. Unfortunately, many have already learned the hard way that even the best coding chops have their limits. More and more, 'learn to code' is looking like bad advice. Anyone competent in languages such as Python, Java, or even Web coding like HTML and CSS, is currently in high demand by businesses that are still just gearing up for the digital marketplace. However, as coding becomes more commonplace, particularly in developing nations like India, we find a lot of that work is being assigned piecemeal by computerized services such as Upwork to low-paid workers in digital sweatshops. This trend is bound to increase.
Learning to code at school isn't just about gaining employability, any more than physical education is about becoming a professional athlete.
An understanding of how to write software will teach skills around how to approach complex problems (decomposition, logical thinking, planning, separation of responsibilities, etc), how to troubleshoot systems (not just IT systems but other workflows), how to identify opportunities for optimisation and automation, and so on.
Bad! Bad logic! No conclusion for you! The point of learning to code isn't to get a job coding. The point of learning to code is to be able to fluently speak the language of the workers of tomorrow. Those workers will be decidedly more metallic, simplistic, rational, and deterministic than today's workers. The person who can speak their language will be in the proper position to make the best use of their efforts.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
To code is like to know how to drive. It is important as a basic requirement in the digital era, but that's all.
Because there are many different types of drivers, the ones can control a bicycle, a motorcycle, a small economic car, a big family car, a construction truck, a tractor, a small ship, a big petroleum container, a plane, a space shuttle, etc.
So, it is right to know how to drive "well", but it is what happens after this basic knowledge what could or not to help you to have and to keep a job.
There is a very simple formula for getting and/or keeping a job:
problems_you_solve > problems_you_create
Keep this equation in balance by minimizing the right-hand-side (RHS) and maximizing the left-hand-side (LHS).
As an employee, you will inevitably create problems for your employer. Most notably you will expect to be paid. Other unavoidable problems include the onerous government paperwork that is required for each employee and the legal liability of keeping you as an employee. These problems are unavoidable. To help minimize the RHS, however, you should avoid creating unnecessary problems. This means being reliable, honest, and getting along with other employees and with customers.
There is only so much you can do to minimize the RHS of the formula. But there is no bound on maximizing the LHS.
These days, many employers think (rightly or wrongly) that they have programming problems that need solving. So if you are able to write code, then that might help increase the LHS of the equation. Note, however, that this only works if you are good enough of a programmer to actually solve real problems. Having completed a coding bootcamp, or having a diploma in computer-science, helps but does not guarantee that you can solve real problems. And that is the crux of the issue. Employers want problems to be solved. They don't really care about your credentials, they care about capabilities and your willingness to apply those capabilities to productive ends.
So, yes, the article is correct in pointing out that learning to code is not a magic recipe for making you more employable. To the extent that learning to code can help you become a better problem solver, then it is valuable. But if you emerge from boot-camp with no new problem solving skills then you have indeed wasted your time.
On the flip side, learning to code usually involves doing lots of problem-solving exercises. And the best way to become a better problem-solver is to practice solving problems. So learning to code may well make you more employable even if you never touch a computer again.
It comes down to focus: If your reason for learning to code just so that you can say that you have learned to code, then that is probably not going to help you are anybody else. But if you are learning to code as an exercise in improving your problem-solving skills, then that are likely to benefit both you and society.
It's generally more efficient for design and execution to happen close together. If coding moves to India, watch the design work follow shortly afterward.
On the other hand, most code is written to be used, not sold. We're a smallish financial institution, and we have an in-house software development group the gives us a key competitive advantage over the industry's behemoths. Putting developers in the same office as business users shortens development times, improves the quality of deliverables and increases flexibility.
If programmer productivity doubled, we'd probably hire more developers, not fewer, as the cost-benefit of various projects would improve.
Whatever the Twitterati say, we will continue to need a steady supply of high quality, intelligent, adaptable, proactive IT professionals for the foreseeable future.
Probably, because our Legislators, largely still ignorant about computer "innards" can't understand it. We need population-wide, overarching understanding of systems, and how to design them. Coding is just capturing design in code. I'm amazed at the number of people who think "feedback" is either your critique of their latest ill-formed idea, or the sound that speakers make when the sound gets into the microphone. They have no concept of how "feedback" is--in the language of systems design and cybernetics--a much broader concept. The notions of sequence, iteration, conditional execution, and formal definition of values are utterly beyond most of today's adults, but second nature to those of us who'd learned how to translate those system implementations into reliable code. Teaching coding is about giving kids a tool set, and an old car, and say, "Go to it, kid!" They don't understand what the transmission is for, or the principals behind a crankshaft, no matter how many times they unbolt parts, and bolt them back on. Sure, they know that you're supposed to used a "torque wrench," but they seldom understand the concept of "torque" and why it's important...which is why the "shade tree mechanic's" only wrench is a pipe wrench.
If our electorate is to understand governments, and businesses, and economies are systems, they need to understand what systems are, and how they work, and how they can go wrong. Teaching them coding is just rote learning, and it imparts a false sense of "understanding" what systems are all about.
I always figured teaching everyone to code was to enable a future where everyone earned money by hacking ATMs, the few people that could not learn to code would have jobs refilling ATMs.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
93% of communication is non-verbal(tonal 38% and body language 55%, which differs by culture) and 60% of knowledge cannot be communicated because it is too nuanced for natural language to handle. You can write all of the documentation you want, but you'll at best communicate 10%-50% of the 40% that you can communicate, and probably miss-communicate a larger portion if working with people from another culture. The best projects are analyzed, architected, designed, and coded by the same team who have domain expereience.
Which was exactly the point that I was trying to make. I suspect that offshoring of coding has reached its peak: it's impractical for very many projects.
I keep reading everything here commenting on the paradigm that your job becomes coding; that you're just in competition with generic coders in India or the IT department for that matter. It's all about "coding" as a specialty, as a job in itself.
That's the problem. That has to stop. It's hurting corporations terribly, keeping them from realizing the full benefits of personal computing.
We acquired personal computing technology, but corporations remained in a paradigm of corporate computing development, where the corporation develops all applications as a body corporate, using specialists to do all the coding. It was actually an *offense* in my old employer for non-programmers to program. People had tools taken away, accounts cancelled.
You don't learn to code so that you can become a coder; you learn to code so that you become an accountant, technician, engineer, salesman, secretary...who can code and script their job. How much more productive is an engineer who can do Excel VBA from one who only knows your basic spreadsheet formulas? How many more documents can a secretary manage who can put together a small, three-table database? She becomes the *key* secretary everybody goes to, the one who gets things done, the one who gets the promotion, is the last one fired.
It worked for me; I actually got a CompSci degree but only ever called myself an engineer; I was just an engineer who knew EXACTLY what he wanted from IT and could insist on it...or do it myself if they weren't agreeable (which tends to make them more agreeable). I only ever wrote bash, Perl, and SQL scripts, but automated vast amounts of my job with just that. Oh, yeah, and Excel VBA, of course, which probably doubled my engineering productivity. I taught every engineer who worked for me to do SQL and basic scripts and sent them off all able to automate basic tasks. I believe they all see themselves as more productive and employable for it.
3 days of coding at home or 3 weeks of coding in India yields the same result. This because people in India don't have a clue about why we in the western world do some things that are natural to us but unknown to them.
I want a snowflake to be displayed in the instrument cluster when it's between +4 degrees C and -4 degrees C. It's logical to anyone living where snow and ice appears every year. But to explain why that's wanted to someone in India can take a few hours.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Protectionism is hardly the answer. It would quickly lock you out of the international markets.
:)
Find a balance, yes, you need to reduce abuse of VISA programs. But you also have to recognize that a place like the Bay area would not exist if it weren't for the steady influx of talent from around the world.
When people can't get an H1B for San Francisco they end up in Toronto or London instead. Don't think there isn't a line of cities trying to become the next tech hub
Besides America needs to sell products aboard if you want any hope of growth. 318 Million people is a lot, but the EU is about 742M, India 1.2B, you need to be present on these markets. America most certainly already is, but protectionism would end that very quickly.
By the way protectionism is not a democratic socialist idea, it seems a bit more nationalistic to me... Liberal socialism is about providing people the basics (education, health care, roof-over-head, food, etc) to be successful (and try again when they fail). While still leaving them with as much freedom as possible.
Note: I'm not saying multinationals shouldn't be taxed harder, or that tax loop holes shouldn't be fixed, merely that doing so is not protectionism.