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.

4 of 155 comments (clear)

  1. skills by pr0nbot · · Score: 5, Interesting

    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.

  2. What are you driving? by info6568 · · Score: 4, Interesting

    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.

  3. Re:Design by guruevi · · Score: 1, Interesting

    Design has nothing to do with code. A good coder can code any design as good or bad as it is. Designers should be programmers that are so good they can see the whole project but typically designers these days are the managerial types that have no idea what they want to begin with. They then outsource the design and get what they asked for, in those terms outsourcing to India is cheaper.

    The problem comes in when what they want is not aligned with what they say they need or are so dense in what they work up that it is a bundle of generic ideas that change interpretation every week, for that you need coders or at least a leading team that knows what the business needs and that's what makes for "good" coders. There are as much good coders in India as the US, that has to do with inherent talent of an individual. But if bottom of the barrel is all your company pays for, they get that in either country, just cheaper over there.

      An external company is tied to contracts and paperwork so design specifications can't just change without a lot of money changing hands every time, so in the end outsourcing will be cheaper because the shit ideas gets them just that. But in the long term as every change has to be paid for after the initial contract, they will spend increasing amounts until they either fail as a company or realize their mistake 5-10y down the line.

    Manufacturing companies already learned that. They outsourced to China and got their ideas stolen and their products counterfeited. I worked for one of those companies during the time they realized a factory in the same city had hired all their staff and their production facility was left abandoned. A lot of them already (especially smaller ones) are now reverting production back to the US. It was an expensive mistake for a lot of them, they lost their talent and some even failed. But there is a resurgence in my area of smaller production facilities now taking orders from the bigger companies they once worked for.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  4. It's not about the coding, it's about the job by rbrander · · Score: 3, Interesting

    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.