Last year, at BoxWorks, we previewed an all new Box webapp experience that is beautifully designed and optimized for functionality. Often, design is only associated with the way that something looks, but it’s really about the way an entire system preforms. I was reminded of this recently, after visiting the SF Pen Show.

At the show, we met a Japanese couple who were making wood pens. They were made from beautiful wood and were very simple, with clean lines and every detail well thought out. These pens were not particularly spectacular, but the attention to detail that went into them was immediately apparent, and they write better than anything I’ve ever used. …

I want to talk about scale. It’s an important topic, and it’s likely that most of the problems growing engineering organizations will face are going to be related to scale in some way.

Usually when we discuss engineering scale, we discuss architecture or database design. This kind of scale is important, but there are other kinds of scale that matter too. One of the most valuable things any engineer can do is think about scale.

So, what does scale mean, and how can you work on it? I think there are three different kinds of scale to pay attention to: the scale of the organization (how well communication works), the scale of the product (how well the features work), and the scale of the technology (which is a function of how fast we can build new things per unit of effort, at a given level of quality). …

Programming, by definition, is complicated. Programs are literally the most complex structures we know how to create. And that’s what code is for, building complicated things. Even though we have many decades of experience and lots of best practices as an industry, there are seldom perfectly clear answers to sufficiently complex problems (a category that includes most programming problems). Often, on a personal level, taste or comfort with a particular technique comes into play.

At the beginning of last week, there were three complex, ongoing technical disagreements in my organization. The details aren’t important, but the pattern itself is. The first step to becoming more enlightened as an engineer is understanding that this pattern exists at all. It may be perfectly clear to you that the right way to do something is with a particular technique or language that you learned in school to be the “right way,” and that makes it hard to understand why anyone would see it any other way. Being aware that there are often (almost always) other legitimate perspectives is the first step towards being a better engineer, both because you now have an opportunity to better work with someone else and because you might learn from that new perspective and expand your toolkit. …


Sam Schillace

Founder of Upstartle/Writely, eng director for Google Docs, Google Apps. Winemaker. VP of engineering at Box.

Get the Medium app