Swizec Teller - a geek with a hatswizec.com

    Why a coding AI like Github Copilot won't take your job

    It might. What's your job Friend?

    If you're in the "write code to exact specifications" business ... now's a good time to start leveling up. The AI's not ready yet.

    If you're in the "use engineering to solve fuzzy problems over time" business ... get excited! AI is on the cusp of automating the tedious part of your job ๐Ÿฅณ

    I wanted to try Github Copilot, an AI coder that Github launched recently, but I couldn't. Instead we'll use a story from history and a story from life.

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    "I'm just gonna sign up real quick and try out Github Copilot on stream"

    ... no I'm not. Glad I tried before the stream, how embarrassing would that be ๐Ÿ˜…
    Tweet media

    Mythical Man Month

    original Mythical Man Month cover
    original Mythical Man Month cover

    In his 1975 book Mythical Man Month, Brooks talks about surgical teams for programmers. His thesis is that programmers are an expensive resource on the critical path of a project.

    Being on the critical path means that you are responsible for how fast a project can go.

    Since you're critical, the best way to speed up a project is to use the theory of constraints and remove any and all obstacles in your way. Anything at all that isn't worth your time.

    In Brooks's time that included what he calls a surgical programming team:

    • programmer writes the code
    • typist types the code
    • code inputter puts code into computers
    • code runner runs the code and reports results
    • secretary deals with outside distractions

    Typist, code inputter, and code runner ... because running code is a waste of your time. Too slow.

    Sufficiently smart compilers

    Decades after the Mythical Man Month came the compiler wars. I don't know if they were wars, but "compiler wars" has a nice ring to it.

    Since the 80's our industry has been looking for a sufficiently smart compiler ๐Ÿ‘‰ "Can you stop optimizing your code and write for legibility?"

    This is a classic argument often pulled out in a LanguagePissingMatch. The gist is that the HighLevelLanguage H may be slower than the LowLevelLanguage L, but given a SufficientlySmartCompiler this would not be the case. Moreover, this hypothetical compiler could use the high-level information available in language H to perform optimizing transformations which are simply not possible in L, thereby making an optimally-compiled H even faster than an optimally-compiled L.

    Note that this kind of argument is only invalid as long as the SufficientlySmartCompiler is hypothetical. The very moment compilers appear that do exploit the high level information this argument is valid. Java is the best example - in the beginning it was slow - much slower than C - and SufficientlySmartCompiler was only used as an excuse. But then as Java became more popular, support for better compilers started to appear which did exploit information that was not available to C compilers: Real time profiles of code use; real time use of reference use. These make Java indeed AsFastAsCee (or faster) in a large area of applications

    I once had coffee with the guy who wrote an early JPEG library for C as his PhD thesis.

    Back then C was slow. You had to use hand-written assembly code in critical parts. A compiler couldn't possibly be smart enough to get it right.

    And then he wrote a working and fast JPEG compressor in pure C. Minds blown ๐Ÿคฏ

    I hope this wasn't a tall tale on his part.

    The thrust of his argument was: For years, you had to dip below C to a low level assembly language to carefully optimize your code. Until one day you didn't.

    The job evolves

    We now live in a world of sufficiently smart compilers, Moore's law, and high level languages.

    We focus on obvious code. Code that's quick to read and easy to understand. Compilers deal with the details.

    When's the last time you thought about register allocation? Never? In college? What about optimizing your data to avoid page faults? Or branch mis-prediction?

    Yeah me neither. Doesn't come up. Tools solve the details and we focus on solving problems.

    But 20 years ago that was the whole job. Interviews asked you to write a linked list or invert a binary tree because doing that by hand, optimally, was your whole job.

    And in Brooks's time, you could get a programming job as a "code inputter" ...

    With AI at your side, it's going to be easier than ever to own the outcome, not the work. In a way it's like hiring interns to help with the boring parts you've built a thousand times before.

    Cheers,
    ~Swizec

    PS: there are interesting issues with Github Copilot specifically. The current implementation has a high likelihood of overfitting its training data and performing a glorified copypaste. There's debate on whether that infringes copyright.

    [sparkjoy|ai-wont-take-your-job]

    Did you enjoy this article?

    Published on July 7th, 2021 in Opinion, AI, Mindset

    Learned something new?
    Want to become an expert?

    Here's how it works ๐Ÿ‘‡

    Leave your email and I'll send you thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Join Swizec's Newsletter

    And get thoughtful letters ๐Ÿ’Œ on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.

    "Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. ๐Ÿ‘Œ"

    ~ Ashish Kumar

    Join over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. โœŒ๏ธ

    Have a burning question that you think I can answer?ย I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    Ready to Stop copy pasting D3 examples and create data visualizations of your own? ย Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first ๐Ÿ’ฐ on the side with ServerlessReact.Dev

    Want to brush up on your modern JavaScript syntax?ย Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you areย โค๏ธ

    Created bySwizecwith โค๏ธ