Everybody loves code completion. You type three characters instead of ten and save some time.
Like, almost a second.
Being glued to a keyboard most of your life means you can type at some 100 words per minute. With the average English word's length of 5.1 characters, this gives you 8.5 characters a second
That's pretty fast. If you're a gamer, you're even faster. Hundreds of actions per second.
Maaaaaaybe code completion adds up to minutes a day. But you're spending most of your time thinking about and reading code, not typing. You are not a typist.
But fine, code completion is cool. Except when it wastes massive amounts of time.
On Sunday I was adding some JavaScript to a webpage using an Emacs mode that does simple code completion. When you write </ it fills out the rest.
<scrpt src="/js/some.js"></scrpt>
<script type="text/javascript">
do_something();
</script>
Refresh the page. Nothing happens.
Hmm ... right.
Add an alert into some.js to make sure it loads. Nothing.
Huh path is correct, I can see my code in the generated HTML. But it's not working.
20 minutes pass.
Idiot! script not scrpt!
Change tag, file loads. YES!
But the code in functions doesn't execute. The more alerts and console.logs I added, the more confused I was. No matter what I tried, code didn't execute. It was all there and there were no JavaScript errors.
It just did not want to work.
After an hour of this nonsense I was ready to throw my computer out the window and pick up gardening. Fuck everything.
Ugh, the stupid close tag! <script> and </scrpt> don't match so obviously the browser eats that whole embedded script tag.
I am an idiot and I should feel bad. This was a stupid thing, but it wasted a lot of time and the code completion trained me never to think about closing tags.
But this was silly. A much bigger code completion fuck up happened on a different project last week.
Without giving too much detail, another programmer on the team implemented some new widgets and in a different part of the codebase I had to decide if a particular element was a widget or not.
Something like having a class widget_this or widget_that.
And then there was wdiget_that_too.
Wdiget. A typo. Honest mistake, happens all the time. But code completion replicated the typo all over the place.
He didn't even realise there was a typo because, hey, code completion. It's automagically doing the right thing is it not?
Cleaning that up was a nuisance. But find&replace did the job.
Except where it was now a data problem. We're saving that stuff to a database and aren't using proper enumerators. Tech stack doesn't make it easy and strings are Good Enough (tm).
Now I suddenly can't reliably make the problem go away. It could have made it into any of the production databases, god knows when the typo will go away on customer facing deployments, and I sure as hell don't want to go through all the objects in all the mongo databases to fix the data.
I resort to a if (something == 'widget' || something == 'wdiget') and sob tears of despair.
Eventually I will move on, but the codebase will not. That ugly if clause is going to be there forever. Every time somebody finds it, they will look into it, waste half an hour to an hour, decide the problem cannot be fixed reliably and leave it alone for the next schmuck to stumble into.
Hours will be wasted for the lifetime of the project because some guy was too lazy to type 5 extra characters.
Continue reading about Code completion is bad mmkay
Semantically similar articles hand-picked by GPT-4
- Coders, protect your hands; you won't like coding without em
- Simple trick that lets you code twice as fast
- What you do while waiting
- I added linting to a 3-year old project. You can totally guess what happened next.
- Write sitting down, edit standing up
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 ❤️