March 15, 2016
From nczonline.net, with love.

Defining the Problem

Hi everyone,

In the course of creating the new My Yahoo back in 2006, a product manager boldly proclaimed to the team that our users wanted resizable columns. This confused me because the previous version of My Yahoo didn't have resizable columns, and there had never been such a request. Once the meeting room had cleared, I asked to see the user comment about resizable columns.

What he showed me was people saying things like, "I want my old layout." The product manager had synthesized that information into a solution: resizable columns. But it wasn't that people wanted resizable columns, it was that the new My Yahoo changed the column layout (mostly the relative sizes of the columns) and long-time users just wanted a way to get their old layout. They didn't like being forced into a new layout because, for many, they had used the same layout for several years. So instead of resizable columns, we implemented the all of the original layouts so the new version could look like the old version. This was much less work than resizable columns would have been, and the user complaints went away.

I share this story because it highlights what is frequently a problem in the fast-moving software industry: jumping ahead to the solution without fully understanding the problem. We all do it, because we tend to measure progress by the amount of code being written. However, as the great basketball coach John Wooden once said, "don't confuse activity with achievement." Writing code isn't better than other activity if you're solving the wrong problem.

In many cases, the solution to a problem becomes apparent once the problem is properly defined. That's why I encourage software engineers to first stop and think about the problem before suggesting solutions. Are you sure you have enough information? Can you re-state the problem clearly without referencing a solution? Can you reproduce the problem? 

Spending time to clearly define a problem is a lot like sharpening an ax before cutting down a tree. You might think that you're not making progress while you're sharpening, but in reality, you are saving yourself a lot of work later on. In fact, the total time, sharpening and cutting, will be less than if you went straight to chopping with a dull ax. So take that extra time and clearly define the problem before writing any code. You'll find yourself being a lot more productive.

Be well.

-N
JavaScript WeeklySponsor: The O'Reilly OSCON Conference
Bringing together code, culture, & community. Save 20% with code NCZ20.

Recommended Links

WebAssembly May Go Live in Browsers This Year (article)
The development of WebAssembly has flown under the radar since it was first announced last year, but progress has been fast with experimental implementations for all major browsers. The expectation is that some time during 2016, WebAssembly support will be available in most browsers. This is definitely a technology to keep an eye on this year.

What's New in jQuery 3 (article)
It's hard to believe, but jQuery has been around for ten years and is still evolving. jQuery 3 brings with it a bunch of new features, including APIs that are better designed to work with ECMAScript 6. While some claim jQuery is dead, it can still be found in use on 75% of the top million websites in the world (see article for citation).

Don't use <picture> (most of the time) (article)
While the <picture> element has gotten a lot of the love for responsive images, many are unaware that in most cases, <picture> isn't the right solution to your responsive image problem. This article digs into the responsive images specification to show you the other features that may better suit your needs.

Reader Question

Why would a really smart young man or woman in college today go into computer technology when (1) there is so much foreign competition, even here in the U.S., (2) such competition tends to drive down industry sector salaries, and (3) there’s pressure to shed employees once they reach the grand old age of 40 or so
to make way for employees who are younger, cheaper, better educated, more motivated, and presumably smarter?


When I told my parents that I wanted to major in computer science, my mom asked me why. I told her, "because in the future, everything will be done with computers, so I'll always have a job." I still believe this to be true. According to the United States Bureau of Labor Statistics, demand for software engineering jobs is expected to grow 17-19% between 2014 and 2024. When you consider all the places software is needed today (phones, TVs, video games, cars, planes, Internet-connected devices like Nest and DropCam), it's unlikely that we'll see enough of a demand slowdown to negatively affect salaries anytime soon.

I can't speak to the pressure to eliminate employees older than 40. Many industries face this exact problem and I'm not sure what the solution is. That's to say, I don't think this is specific to software engineering, and I'm not informed well enough to comment.

Have a question you'd like answered? Just reply to this email.

Recently on NCZOnline

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

React and the economics of dynamic web interfaces
I've been doing web development since 2000, and in that time I've seen eras marked by libraries and frameworks come and go. The Ajax era began around the same time as the jQuery era began, the Backbone era began several years later, and the React era really began about two years ago. Each of these...

Feedback

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