The Slippery Slope of Dev Demands
Big tech is listening to developer noise in their quest to be best. Unfortunately, this is starting to deteriorate the integrity of some programming languages.
To better understand this, consider the recent Chrome release, with a small but important change in their DevTools. Developers can redeclare a JavaScript const variable in the console. Take a moment to reflect on the definition of a const variable as MDN defines it:
Constants are block-scoped, much like variables declared using the
letkeyword. The value of a constant can't be changed through reassignment, and it can't be redeclared.
Why would Chrome intentionally defy the definition of a const this way? Here’s the use case specified in the DevTools writeup:
Users want to be able to copy-paste code into the DevTools console to see how it works or experiment, make small changes to the code, and repeat the process. If the code they copy-paste has a top-level const variable, then it currently throws a syntax error. This is frustrating as users then need to refresh the page, open a new tab, or remove const keywords to get around this.
The argument boils down to “users are frustrated”.
Is this really a problem?
Yes.
In this example, Chrome DevTools is catering to a community that wants to copy/paste. Developers copy/paste code into the console the same way they copy/paste code into their applications. In this case, developers will become frustrated when they copy/paste from DevTools into their own code, where redeclared consts aren’t allowed.
Copy/paste culture can be a good way to understand new code, but it doesn’t promote critical thinking. Far too many developers copy/paste code from StackOverflow, Github, and other sources without understanding what they’re doing. As a busy developer, it may seem nice to not have to think as much by copy/pasting, but that’s part of the reason why there is a shortage of qualified developers in the world (which I’ve written about before). In a nutshell, there is a shortage of experienced and creative tech talent — the world lacks “makers”.
While the Chrome DevTools change seems to be done with good intentions, it is really just adding another confusing quirk to the developer experience.
Sledgehammer Tooling
Developers always want one tool for every job. It’s human nature to want everything in one place, and have everything be “easy”. All-in-one and “easy” don’t scale well though.
Chrome DevTools is attempting to satiate everyone, but at what cost? Is promoting a “mostly-compliant” JavaScript environment really a good idea?
There are plenty of other tools for experimenting with JavaScript.
Alternative Approaches
In Google’s case of allowing const redeclaration, perhaps it would be better to provide educational resources for developers. The main use case driving this “feature” is people copy/pasting code from tutorials and other online educational sources. Perhaps educators should shoulder the responsibility for providing copy/paste code that works. Perhaps they should be educating their students about the difference between const, let, and var. In other words, educators shouldn’t be rewarded for peddling poor practices.
In the case of Google, a few UX tweaks could go a long ways.
Here’s how DevTools looks now:
Perhaps redeclaring a const could display a warning like “warning: redeclaring const is not a standards-compliant operation” instead of providing no feedback (which suggests success).
The Slippery Slope
It’s important for tech toolmakers to listen to their users, but tooling makers also have the responsibility to protect the integrity of the technology they enable.
Tooling developers, especially large ones, need to consider the impact of defying tech standards (no matter how small). When leaders contradict standards (especially those they help create), it creates confusion. If standards aren’t enforced, there isn’t much point in them at all.
It’s tough to balance user demands with technical integrity, especially when demands contradict the fundamental nature of a particular technology. With each feature, toolmakers need to ask themselves if they’re contributing to a slippery slope.
