Skip to content
Swizec Teller - a geek with a hatswizec.com

Code completion is bad mmkay

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.

Did you enjoy this article?

Published on November 14th, 2014 in Uncategorized

Learned something new?
Want to become a high value JavaScript expert?

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

Start with an interactive cheatsheet 📖

Then get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career.

"Man, love your simple writing! Yours is the only email I open from marketers 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 10,000 engineers just like you already improving their JS 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 ❤️