April 26, 2016
From nczonline.net, with love.

The Least is the Most

Hi everyone,

Over the years, I've watched probably hundreds of software engineers at work, and as such, have come to identify certain patterns I see in the best of them. One of these patterns is solving a problem completely with the least amount of effort and the least amount of code. The best software engineers have a way of either figuring out the simplest way of solving a problem or reducing the problem into a state where the solution is easy.

On the other hand, I've seen struggling software engineers do the opposite: instead of doing the least amount of work necessary to get the job done, they go overboard. They believe that doing more works shows how smart and dedicated they are, even if their approach takes significantly longer than others. Some will even take relatively simple problems and complicate them or expand their scope to make the problem more interesting to solve.

At Yahoo, I once checked in on one of the front page teams to see why their work was taking longer than expected. What I found was that they had expanded the scope of the project far beyond the original charter. When I told them this, one of the engineers responded, "Well sure, but wouldn't it be cool if we solved this problem for all of Yahoo?" Yes, I told him, it would be cool -- but that wasn't the task. Solving the problem for the front page alone was a decent amount of work, but trying to take into account all of the needs of every team at Yahoo, gather case studies and stakeholders, was something the team wasn't staffed or scheduled to do. Once back on track, with the original, smaller scope, the project completed fairly rapidly.

I share this anecdote not to say that these engineers were dumb. In fact, quite the opposite: they were so smart that they wanted a more difficult problem to tackle. The willingness to take on difficult problems is a good trait, however, making simple problems more difficult in order to make it more interesting is not.

The software engineers that succeed tend to be the ones who narrowly define the scope of their work and deliver a solution with the least amount of work. That doesn't mean cutting corners, it means recognizing that whenever there's a simple way to solve a problem, that's the correct solution. This type of restraint allows you to finish work quickly and efficiently, meaning that your overall productivity improves. And generally speaking, when your productivity improves, so does your paycheck.

Be well.

JavaScript WeeklyI couldn't find a sponsor this week. Please consider a one-time or recurring donation to help support this newsletter.

Recommended Links

HTML5 Accessibility (site)
Understanding which web platform features are accessible is very important for creating accessible web applications. This site gives you all the information you need about browser accessibility support for the latest HTML features. The design is a bit dated, but a new, cleaner design is in the works.

DOM Listener: capture, passive, once (article)
You might not be aware, but there's been a change to the DOM addEventListener() method. The third argument can now be an object and allow you to specify "passive" (indicating that the event handler will never call preventDefault()) or "once" (indicating that the event handler should be called only once and then removed), in addition to "capture". This quick overview explains the changes and introduces a polyfill to mimic the new behavior.

Almost complete guide to flexbox without flexbox (article)
While flexbox has some level of support in most browsers now, there are still some edge cases and older browsers that do not support it. Never fear! This article shows you how to create flexbox-like layouts without using flexbox. The examples are explained in terms of flexbox behavior and is a great quiz to see if you can think outside of the flexbox.

Now Available for Preorder: Understanding ECMAScript 6

I've been working on my book, Understanding ECMAScript 6, for over two years. The content has been available for free online the entire time as I've written it. I'm happy to share that I'm almost done with the book and the print version is now available for preorder. While the content is the same as the online content, this print version is being fully copyedited, proofread, and tech edited to make sure everything is as clear as possible. ECMAScript 6 itself took four years to be finalized, and I've been updating this content for half that time. If you've enjoyed my previous books, I think you'll enjoy this one as well.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences