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">

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 ™.

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.

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

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.

PS: You should also follow me on twitter πŸ‘‰ here.
It's where I go to shoot the shit about programming.