Becoming a Master

I was talking the other day with a very senior engineer in the industry (yes, it was also a job interview, but we'll save that for another day) and he was expounding upon his company's laser-sharp focus on making complex technology simple for the user. His expertise is in front-ends, mine is in back-ends, but he gave examples about how hard it is to take all of this intricate code and architecture that we manipulate and mold into the simplest possible interface: so that the user knows exactly what to do to achieve their goals, without needing a manual or a guide. Every relevant operation (and only the relevant) is close at hand, and simple.

I replied with a counterexample from server engineering: take fail over, a situation in which one server has gone down and another needs to be brought back into operation as quickly as possible. In such crises, the system administrator needs the simplest method of getting a replacement system operational and fast. And if the replacement occurs automatically, without administrator involvement, that's the simplest method of all.

We as engineers evaluate each other incompletely, narrowly. We grant praise for finding a solution to a problem fast; for solving numerous, obscure puzzles; for the elegance of the code itself. Yet we fail to evaluate the solutions themselves through the eyes of the beneficiaries of our work: the users. Every system we build has a user, one who most likely is not an engineer. We make our decisions based on criteria that affect us, but not the user: have we delivered a solution that is easy for the next developer to maintain? Did we use a standard, correct algorithm? Even considerations about performance are driven more from the negative motivation of fear of eventual criticism, rather than a positive consideration of value to a user. Sometimes the most elegant code is also the most inefficient.

Software engineering suffer from the same schism that affects every other engineering discipline: form vs. function. As engineers we praise the functional solution, and miss half of the challenge: the aesthetic form. Will the user appreciate what we have built? Will the user benefit from what we have built? Have we hidden the guts of our machinery behind smooth surfaces of marble, or left them open, raw and exposed? Does our solution appear simple, intuitive?

Achieving simplicity in the midst of all the technological complexity we face is extraordinarily difficult. Simplicity in technology may be the archetypal example of form built on function as the goal of engineering. It requires a deep understanding not only of your problem domain, but also an absolutely thorough command of your toolset -- and the facility to expand or adapt that toolset as the situation requires. In short, in the art of engineering, creating the simple is the work of a true master.

Now I know what's next for me. I'm ready. I want to become a master.