Interview With Nicholas Zakas of Box


Having people you can learn from is an essential part of being a successful developer. No amount of reading will ever fully prepare you for the ever-changing web landscape, so being able to look to seasoned and experienced mentors is vital. Nicholas Zakas is one of those people that you can look to.

A leader in the JavaScript world and incredibly savvy in scalability and performance, Nicholas is one of those that helps define best practices through his vast experiences at companies like Yahoo! and Box. One of his most amazing attributes are his approachability and his desire to genuinely help push the web forward.

Let's get into our Q&A so you can learn a little more about this great developer.

Q Let's start with the usual. Could you give us a quick intro about yourself?

Certainly. I'm a software engineer who focuses on front-end web development. I love the web and knew very early on that I wanted to make that my career. That love has led me in many directions, including writing and speaking. At the moment I'm working at Box, taking on the challenge of helping the company scale.

Q You were a principal front-end engineer at Yahoo!. I think for most of us, it's hard to comprehend working at that scale. Can you tell us about the challenges you saw at Y! and how it has shaped your thinking since you've left?

Yahoo! was the most impactful professional experience of my life. Prior to that, I was a big fish in a small pond, and day one I realized I was now in an ocean. Solving problems normally and solving problems at scale require two different ways of thinking. At scale, there's never just "one more" thing. I remember one conversation in particular where someone wanted to make an extra Ajax request and I said no. His response was, "what's the big deal, it's just one more request?" I had to explain that one more request per user when there are millions of users means a dramatic increase in server load that we need to capacity plan for. I chuckled at that, because I was on the other side of that conversation when I first arrived at Yahoo!.

Everything I do has been affected by my experience at Yahoo!. I'm obsessed with scalability and the problems associated with it, and most of my work since then, both at Box and while consulting, has been in helping companies scale their web applications. My experience at Yahoo! made it so that I understand these issues from many angles, not just technical but also personnel-wise and organization-wise.

Q When I read your writings, you focus heavily on computer science principles. It's only in the last couple of years where I've seen an up-tick in that. Where do you see the bulk of the current generation of front-end developers heading in terms of embracing formalized CS principles in their work? Are they still lagging?

I think front-end developers are still lagging in having a solid amount of computer science knowledge. It's true that having a CS degree alone does not guarantee success as a front-end developer, but it certainly helps. I know several excellent FEs that are now going back and either taking computer science courses formally or trying to pick up more CS knowledge through reading and other means.

Web applications are so much more complicated than they were before, and understanding design patterns, abstraction, and architectural principles is becoming more and more important. Those who come into the industry without a good CS background will either be limited in their professional growth or will start picking up these CS principles some other way. I firmly believe that the best and the brightest are the ones who can bring CS principles back into the front-end. Whether that's through formal training or not, that knowledge becomes important to furthering your career.

Q Along those same lines, where do you see front-end devs lacking from a skills perspective? What are the things that they should be up on but aren't?

The biggest issue I see is lack of code organization. Part of the problem is that web technologies like CSS and JavaScript are mostly without built-in form. Whereas Java has packages and C++ has includes, web technologies don't give you a formal way of organizing your code. That leads to poor code organization and then poor architecture, because there are also not any built-in patterns.

Learning about design patterns, code organization, and architectural principles would benefit front-end engineers tremendously. Not just for their FE code, but also for the ability to participate meaningfully in conversations about other parts of their technology stack.

Q I've overheard conversations where the ECMAScript standards body is getting push back from a very vocal group which call themselves "practitioners" of the JavaScript language and are driving for more practical, real-world updates to JavaScript. Have you heard of this and if so, what's your take on this and the interaction between the traditional maintainers of JS and this new group?

Yes, there's definitely been an influx of practitioners getting involved in the standards committee. There's Rick Waldron and Yehuda Katz from the jQuery Foundation and Eric Ferraiuolo from the YUI team on TC39, people with real-world experience creating web applications and JavaScript libraries. There are also a lot of vocal people who participate on the es-discuss list regularly and who represent the practitioner view. Even I chime in from time to time when I feel like reality isn't quite intersecting with plans.

This communication between practitioners and those deciding the future direction of the technologies we use is imperative. Via es-discuss, TC39 members are generally responsive. I look at this relationship as being similar to the one between citizens and elected officials. If the citizens aren't telling the officials what's important to them, it's hard for the officials to know. Random people complaining about something here or there doesn't make someone think of it as important - it's when a critical mass all reach out and say, "yes, this is important" that change happens.

Q It seems that some of this may be founded considering the adoption of such DSLs as CoffeeScript, TypeScript and Dart which seem to bring flexibility and power to front-end devs. Is it a language issue or a developer expertise issue?

I feel like it's a developer expertise issue. What I see most frequently is people without much web development experience deciding that it's easy, so they're just going to hack something together. After all, JavaScript looks like many of the other C-based languages, and so they start writing it as if it were C or C++ or Java - then they get frustrated because the functionality they're used to doesn't exist...then they turn to things like CoffeeScript or Dart because it gives them back what they perceive to have lost.

If you flip the script a bit, if people actually took a little bit of time to learn JavaScript before diving in, I'd hope there would be a greater appreciation for what a unique and dynamic language it is. Unfortunately, the "agile" and "rapid" development processes tend to encourage people not to stop and learn about what they're trying to do, but just get stuff done so as to keep up their velocity and deliver. When that happens, finding something that looks familiar makes far more sense than using something completely new.

Q One thing you really harp on is performance and trying to educate developers on optimizing their code. Alex Sexton wrote a great article that's along these lines, elaborating on roles that specifically target optimization. Is this the optimal route for companies to take or should every developer be as versed in the nuances of performance?

To me, this is too specific a specialization. As a front-end engineer, your job is to cross-cut concerns, including performance, maintainability, internationalization, accessibility, and more. To put it another way: if front-end engineers are not thinking about these things, then I'm not sure what they're thinking about. In my experience, the more you split off specializations, the harder it is to convince everyone that it's their responsibility as well. "Oh, the performance team will take care of that." "That? The accessibility team will worry about it." This isn't to say that you don't have people who happen to be more in tune with certain concerns, but I believe that you want everyone on the team to be thinking about all of these issues all the time.

Q You always seem to be on top of the cutting edge stuff, especially in terms of JavaScript. What's your process for staying in the loop on all the changes?

I do a lot of reading. My Twitter feed is made up primarily of human news aggregators that let me stay up-to-date with what's going on. I also do a lot of writing, which I find leads me to research areas I might not normally look at in an effort to explain things better. Lastly, I'm constantly experimenting, both on my own and at work, and looking at the real-world problems people are having to see if I can come up solutions.

Q Last question. If you had to list the top five things front-end developers should be in tune with, what would they be?

  1. The changing API landscape - make sure you know what's possible
  2. How to effectively use the ever-evolving development tools
  3. Standards efforts - understanding what's coming, what's not, and why
  4. Browser feedback channels - you should be using them
  5. Code organization and design patterns


Thank you Nicholas for taking the time to offer up this insight.

I urge our readers to follow Nicholas on Twitter and also check out his blog, where he posts some of the most frequently referenced articles in web development.

Related Posts
  • Code
    JavaScript & AJAX
    Testing in Node.jsNodejs testing chai retina preview
    A test driven development cycle simplifies the thought process of writing code, makes it easier, and quicker in the long run. But just writing tests is not enough by itself, knowing the kinds of tests to write and how to structure code to conform to this pattern is what it's all about. In this article we will take a look at building a small app in Node.js following a TDD pattern.Read More…
  • Code
    Interview With Jonathan SnookJonathan snook retina preview
    I've met many web developers over the years and the common theme is that they tend to specialize in a specific aspect of web development. They're either designers, JavaScript coders, server-side experts or perhaps a tiny bit of all of them. Rarely do I meet someone who is incredibly well-versed in the full-stack having an amazing design acumen and being able to take a vision and bring it to life, front to back. Jonathan Snook is one of those rare breeds and also an influencer in the web development world. His skills have made him a sought after speaker and writer and afforded great opportunities at companies like Yahoo! and Shopify. He's now venturing into product management and we catch up with him to see how that's going and his advice for anyone looking to jump into that role.Read More…
  • Code
    Interview With Elijah ManorElijah manor retina preview
    It's truly a unique and interesting experience to watch someone transcend from one community to another with little to no issues. In this case, we're talking about Elijah Manor who successfully worked to build his reputation in the open source community while still maintaining his strong presence in the Microsoft world. He has the best of both communities at his disposal, now able to leverage his cross-platform expertise into a new life-changing role with Pluralsight.Read More…
  • Code
    Interview With David WalshDavid walsh retina preview
    Have you ever meet a brash punk kid that annoys you to no end but he's so damn talented that you can't help but want to work with him? That's how I felt when I first met David Walsh several years ago. Since then, I've seen him mature into a respected and often quoted software developer and most recently, a new dad. He hasn't lost his snark and feistiness and he continues to hone his skills daily, often sharing his best tips on his awesome namesake blog.Read More…
  • Code
    What Are You Using?Preview 400
    We spend a lot of time following the thought leaders in web development, in many cases using the tools and libraries they've built, reading the posts they've written, articulating cool techniques they've learned, and in some cases, attending the defining conference for a specific language. But wouldn't it be great to learn what they focus on and what they use to build such awesomeness?Read More…
  • Code
    Tools & Tips
    IRC is Back: Here's Your Starter GuideIrc hd
    How of many of you remember Compuserve? What about Prodigy? I'm asking because, back in the good 'ole days, they were popular services that allowed you to communicate with other people from all over the world. In many cases, they offered complementary services, such as forums or classified services, not to mention a pretty appealing user interface (for the time).Read More…