Want a free year on Tuts+ (worth $180)? Start an InMotion Hosting plan for $3.49/mo.
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.
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?
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.
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?
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.
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?
- The changing API landscape - make sure you know what's possible
- How to effectively use the ever-evolving development tools
- Standards efforts - understanding what's coming, what's not, and why
- Browser feedback channels - you should be using them
- Code organization and design patterns
Thank you Nicholas for taking the time to offer up this insight.