What Should We Learn From The left-pad-gate

Some thoughts on how engineers are building their projects

Rafael Guedes
Quid pro quo
4 min readMar 29, 2016

--

By now if you are an active — or at least well-informed — member of the Javascript community you know how a couple of lines removed from NPM has broken thousands of builds all around the world.

This event brought up some interesting and never-ending discussions as the never-ending feud between corporate x open-source worlds (yes I know corporations can go open-source). I have absolutely no interest on joining this minefield here. Rather, I would like to discuss how engineers are becoming less responsible for the code they choose to run their applications.

My first contact with code was writing static HTML websites back on high-school. I wasn't satisfied with those page builders. They surely were helpful and could deliver some layouts I couldn't do by myself but I didn't want my Pokemon fan-site to look exactly like that ordinary personal page that I found when I clicked on the "next" button on Geocities. I wanted more, I wanted to do my website. I wanted to look at that and — doesn't matter how amateur it would be— see a result of my own efforts.

So I learned PHP and got amused with the ability of building dynamic content. I could do what the hell I wanted. I had the power to make my pages as cool as my imagination and talents allowed them to be. I was finally writing code for real!

And — by the best/worst way possible — I have learned what was a SQL injection.

Back on the college days I was part of the Computer Science junior enterprise held on the campus. The projects we have worked on would be trivial for any junior engineer but for an inexperienced undergrad student they were real good opportunities to build something out of the academic projects and have an actual contact with what the market would expect — given all the limitations — from quality, deadline, price, support standpoints.

One of the discussions I clearly remember to actively be part of was if we should go or not with CMS solutions that were emerging at the time (Wordpress, Joomla, etc). The point for using them was that it would bring productivity. My point was: do we need it?

Why would an undergrad use an authentication library if he doesn't know under the hoods how to implement or how it works? Don't get me wrong, of course if we take this statement strictly one would need to know all the way to lower levels before building a project — although it would beneficial for everyone in an utopian world.

The main point around that discussion was: Were we de facto using our opportunity to learn how the heck code stuff or just turning ourselves into mere professional code copiers?

Fast forward to last week event and those two earlier episodes of my life got perfect linked to the chaos that removing some libraries has caused. Let's pick left-pad to start. It's a 17 line module (including blank lines).

module.exports = leftpad;

function leftpad (str, len, ch) {
str = String(str);

var i = -1;

if (!ch && ch !== 0) ch = ' ';

len = len - str.length;

while (++i < len) {
str = ch + str;
}

return str;
}

Now seriously, take 30 seconds to read this code and think about it. Seventeen lines of a code that you either have done for a job interview or on an academic class. And because you are lazy enough to write it you have put another 3rd party code as a dependency of your entire project.

Let's go to an extreme case. Look at isarray source code:

var toString = {}.toString;

module.exports = Array.isArray || function (arr) {
return toString.call(arr) == '[object Array]';
};

Simple enough, right? So, instead of dropping those lines directly into their projects, apparently a lot of people (almost 18 million downloads last month) decided to include it in their packages.

We are seriously creating a generation of software engineers oriented by how easy it is to google & npm a library that save us whatever amount of time by quickly adding a dependency on our package file. The easiness of writing npm install magic is hiding our ability, as software engineers, to think on solutions, to resolve problems, to create algorithms. That's the essence of what we do, how can we give it away without looking at its consequences?

By no means I am saying here "don't use NPM". It's a fantastic tool to share solutions and one of the major players that helped put Javascript community together, but it has been overused a lot.

Under the "let's go with a community-accepted solution" umbrella, developers are adding every possible kind of dependency to their projects, creating non-maintainable non-traceable beasts from a dependency management standpoint. Most of them are usually simple libraries that could be home-brewed and possibly optimized for the purposes it would serve. It's virtually impossible to keep up on how all those 72 dependencies (and their own dependencies, recursively) are being updated, maintained or even working as expected.

What happened to us that we don't take care of our projects and our code-base? Why we became so lazy that we can't even analyze if something is indeed dependent to our work?

Be proud of what you are doing but also be responsible for what you are doing. Treat your code with the same seriousness and reliability you do to the final product it is being written. You have the power to define how strong your foundation is, don't let it loose just because of a couple of hours you think you are saving.

Less isn't always more.

--

--

Rafael Guedes
Quid pro quo

engineer @google. former basketball all-star. tweets sobre programação, esportes, vida e tudo mais. meia portuguesa, half in english