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.
"I'm just gonna sign up real quick and try out Github Copilot on stream"
— Swizec Teller (@Swizec) July 7, 2021
... no I'm not. Glad I tried before the stream, how embarrassing would that be 😅 pic.twitter.com/kmcE43z3j9
Mythical Man Month
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.
Continue reading about Why a coding AI like Github Copilot won't take your job
Semantically similar articles hand-picked by GPT-4
- Yes, AI will "take" your job. No, you won't mind
- Why you shouldn't use AI to write your tests
- What's more productive, a team or a talented soloist?
- What does "solve problems" even mean
- Programmers are fucking lazy
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 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. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
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 ❤️