We are so honored to share a fascinating interview with Nicholas C. Zakas, a front-end engineer, author, and speaker, with our readers. He is a Principal Architect at Box and has worked on and lead several projects with Yahoo! where he worked as a Front-end Tech lead for the Yahoo! homepage. Nicholas personally shares his first unsettling year at Yahoo! and the solutions he created to help overcome some serious obstacles. Along with his contribution to Box’s success in their early years of immense growth and his impacting, long-term fight with Lyme disease to which he ultimately contributes part his success as a high-performance engineer.
How did you first get your start at Yahoo!?
Initially, I was set to interview with Google in California. I figured while I was there I could meet up with other people in California. I sent an email to a couple people out there including Thomas Shaw, the creator of YUI, and had a good conversation about the state of the web. He eventually told me that if I was considering moving all the way across the country, that I should also interview with Yahoo! I flew back to interview with Yahoo! and Google, In both cases I had the same reaction. Both events produced a high level of anxiety. I am to this date a very nervous air traveler. This trip, in particular, was very anxiety provoking because I had also never traveled on my own before. I was so nervous before the flight I threw up. To calm myself down I kept telling myself “this is just an experience, go in and see how it goes. I don’t need both of these guys, but this is a good possibility. If I didn’t get the job that was fine.”
I ended up getting offers from both companies.
How did you transition from Yahoo! to where you are now?
At the time I took the path less traveled, I choose to go to Yahoo! instead of Google. A lot of people ask me why I choose Yahoo! over google. It was really a question of fit. I felt like I fit better at Yahoo! over Google. I could picture myself better.
Once at Yahoo! I felt like a fish out f water for about 9 months. I was working with people who are incredibly smart and solved problems on such a massive scale. I came from pretty small companies, 100 – 300 and I was at a company who had 10K people when I was there. Even the intern of the group I was working with. I felt like the intern knew more than I did. I had never worked with Linux before and the intern knew Linux and looked down on me like “you don’t know what you’re doing”. I was really overwhelmed and wasn’t sure if I was going to cut it. but I took it as a challenge, working on my Yahoo! was a really great introduction and there was a lot of smart people surrounding me from which I could ask questions.
After about a year and a half there I felt like I found my stride. I stepped up into more of a lead position where I was being told that I was building some really high quality stuff and was tasked to teach other how I do things so we can raise the level of quality across the board. I started thinking more of what it means to be a tech lead and a lead software engineer vs someone who just does what they are told. That sort of transitioned me into a larger role onto the Yahoo! homepage where we were rewriting it from scratch, in a way that was very framework focused so that we could launch Yahoo! home pages that were specific to different locals. We could have one in India, France, Japan, China in the appropriate language for that local.
It was pretty daunting at the time. It’s one of those things where the first thing you ask is “What is the team?” because you need more than just two people to wrap their brain around just an elaborate project. Knowing that you have a good team around you is key. Myself and other people who were working on My Yahoo!, ended up being chosen to work on the Yahoo! Homepage project because of the great job we did on My Yahoo!.
The problem was in order of magnitude larger because of the traffic, ad revenue, and the requirement that the homepage can never go down; no 500 errors, no 404, no server failed to respond, that is just not acceptable. Every second is bringing in money, which means every second it’s down it is losing money. We had to get very deep into the product requirement for each region.
There were a lot of interesting challenges technically. It’s one thing to design a homepage to work for the US. When you switch to a country like Japan, where the topography of the characters is much more compressed, you end up with having to solve for a lot of extra whitespace. We also had to account for languages that are written from right to left without requiring for a whole new homepage design. There was also my first bite of being a leader on a large team, my manager made it clear that the responsibility for the entire homepage fell on me. That meant having to organize people, resources and technology to make sure that the homepage was running as smooth as possible. Worked with a team of about 24 people distributed between USA, London, India, and Korea. I had to figure out how to get all of these people working on the same code base, while staying out of each other’s way because they were all working in different time zones. That I look back on as my crucible in term of how a lot of best practices were developed in my mind. It was really the lessons that I learned there that lead me to the position at Box.
What are you focusing on with Box, and what unique challenges do you face there?
What attracted me to Box was that I was looking for a new challenge. I quickly came to realize at Yahoo! that I was solving the same types of problems in the same space. I really wanted to do something where the solution to the problem wasn’t already known to me. I was introduced to Box through a friend who had worked there. I realized that they were in a very interesting position. Box was growing like crazy, and the processes and technology were not keeping up.
There is a scaling problem, not just technology wise but also process-wise, it seemed like there was some basic automation that was missing that could alleviate some of the stress about not being sure if their code was going to break something or not. I wasn’t entirely sure how i was going to fix everything but being able to help a rapidly growing company scale into a large company, a lot of people don’t get that kind of opportunity. I felt like I could make a significant difference to the company as a whole.
First was how do we automate a lot of manual processes, which was a problem that they started to work on before was there but there was a lot of things that were not being done like any sort of linting for JavaScript. Now we have a very robust linting system using ESLint that has our own plugable rules, now what we’re able to do, if we go through a post mortem of a product and discover that there is some JavaScript that was missing we just create a rule that will flag that from now on so we don’t encounter that same error again. We did a whole tooling upgrade where we have linting for CSS as well and improved the compression of images. Really optimizing our static asset pipeline by switching to UglifyJS which gave us better savings.
Also started digging into the process of how we communicate with one another. What I saw a lot of was complaining on code reviews about things where done. which isn’t bad, except you could get a lot of opposite opinions about how things should work because it really slows down the development products. One of the first things I did was get everybody together and decide on a style guide, then we were able to focus on higher level problems like, How code is structured? Is it structured well, will it lead to more bugs at the future?
After that I headed up a team called frontend frameworks and what we did was look at how we could start to create some decoupled pieces in our frontend. One of the complaints we heard a lot was “I’m afraid to make changes because when I do It tends to break something that is unrelated to what I’m working on, and we don’t find that, until a customer reports an error in productions.” And that’s a very bad situation to be in for an engineer. That was a top priority to solve, we have to give people confidence in the changes that they are making so that we will fix changes and they will fix bugs.In this case I knew that there was no possibility that we would be given time to rewrite the entire application. You rarely get to rewrite something from scratch that brings in a lot of revenue. IT just doesn’t happen. What you have to do is look for a path forward that you can do in an incremental way. We had to figure out a path, from the mess that we have now, to a pristine future knowing that you’re not going to get it all at once.
What we did was create a very small framework called T3, which is now open sourced. It’s primary goal was to create loosely coupled components that had very specific jobs; so that when you had to create something new you asked one question, Is this a behaviour, module, or a service? By limiting people’s choices, you give them confidence. Each of those component restrict and prevent you from negatively affecting your code or other people’s code. Essentially you are replacing small pieces of the application with T3 components without needing to rewrite everything with everything else continuing to work.
“We very slowly built up and continued to created Islands of sanity in an ocean of insanity, until eventually you had a giant island where people could function with a high level of confidence and get get to the point where they could write test without fear.”
I‘m not really trying to compete with ReactJS, AngularJS, or Backbone.JS. That was never the goal to get into a framework war or to convince that T3 was better. It was meant to help those who were in a similar situation to the one we were in, where you cannot afford to do a full rewrite; and you need something that can help you to organize your code and you need work alongside any other framework you already have, then T3 might be something that could help you make that transition to get to a better state.
What are you most excited about regarding new technologies that interest you?
The thing that I’m most excited about is how tooling has been improving by leaps and bounds for frontend engineers. I remember when I was first (in 2000) full time job doing web development if you had any sort of problem it was a nightmare trying to figure out what the problem was and how to prevent it in the future. Back then we put in alert statements everywhere in Javascript, to figure out where you code was going. In CSS you had to keep deleting things until you found what was causing you bad layout. It could literally take week to debug a typo! Because you didn’t have any insight to what was going on.
Looking at tools for front end engineers now is incredibly exciting! You have the Chrome DevTools, Firefox Developer Tools, even the new Microsoft Edge tools are incredible! You have things like Fiddler, a free debugging proxy, that lets you look really close at the HTDD that’s going in and out. There is a lot better linting tools, to toot my own horn, CSS Lint. There is a lot more in terms of testing, better automated testing solutions for JavaScript like Mocha, Tape and istanbul which gives you code coverage for JavaScript. I find myself relying on these tools do much now to give myself confidence that I have run enough tests. I rely on Webpack, module bundler and Browserify that make it easier to create JavaScript that can run on an brower and a server. I’m so excited about all this because the productivity gains we are getting out of our frontend engineers now and will continue to get as we move forward are really what I think is helping to push the web as a whole forward. The reason we are able to continue to evolve, and introduce new features to the web platform is because the tooling has gotten so good. It goes back to confidence, the better confidence that you can give engineers in what they are doing on a day to day basis, the more they will feel free to try new things, innovate, and fix old things. As a result you see the feedback loop becoming a lot tighter, even with ECMAScript 6 (ES6) which long time to finalize, you have tools like Babel (JavaScript compiler tool) that people started using and where able to give feedback into the process, in order to find problems, so when ES6 was finalized people wouldn’t run into those same issues.
Do you see potentially a book on some of these tools you use, to help other people learn tools before they need to know this?
IT’s been a thought. I’m working on a book on ECMAScript 6 that should come out next year, that’s where I’m focusing a lot of my energy. I did make a brief attempt at doing an overview of tooling in my book Maintainable JavaScript, which is really about working on a large JavaScript code base as a team, and what that entails. It talks about the importance of style guides, code conventions, as well as splitting out different types of functionality and loose coupling. These are all things that are really important when working in a team to be able to work in the same codebase without stepping on each other toes. In the last section of the book is actually on tooling and putting together a build process for JavaScript where I talk about linting and testing. Basically it was the javascript ecosystem at the time that I wrote the book and how to put a build process together using ANT, which nobody uses anymore, because now everybody is using Grunt, Gulp, or Broccoli the latest build tools that are out there.
It also showed me the difficulting for writing a book for tooling in JavaScript because of how rapidly that landscape changes. which is a general problem when writing about technology anyway. When writing one of my books, I was about to finish it then Chrome was released, which is an entirely new browser. so I had to stop the presses and go back and update the entire book for Chrome. It involves a lot of deep thinking to make sure the book is still relevant by the time the book hit the presses.
You’ve kept yourself busy with Yahoo!, Box, and writing books. I read on your blog that you have been fighting with Lyme disease, can you share some of the struggles you’ve had dealing with that along with work/life balance?
It’s definitely been a struggle for a long time. I first developed symptoms in 1998, they are primarily fatigue and flu like symptoms: nausea, headaches and body aches. When it initially hit me I was sick for about a year and nobody at the time knew what it was. I wasn’t diagnosed until about two years ago. I would feel relatively normal for about two or three months, and then I would relapse again feel very ill. It comes and goes as part of the disease process. For the beginning of my career I was living a normal live and had a lot of energy. At 22 years old if you took half of my energy away due to the disease I still had a lot of energy. At the beginning of my career I got into such a bad state I was forced to take short term disability for 12 weeks, That is really hard, at a young age 23/24 years old, for your ego go through something like that. I felt like I could still do everything I needed to do. It wasn’t until I got closer to 30, I really started struggling and was sick for an extended period of time.
Once I got through that, I took a job at Yahoo! moved out to California by myself. The stress of the move across the country to an area where I didn’t know anybody caused my health to get worse.
Being caught up in this new job where I was trying to learn and adapt to a large, new company. Really, I ended up struggling with depression for the first year. For every almost everyday of that first year, I would go home after work and just cry because it felt like too much and I didn’t know how to make anything better.
There was several conversation with my Mom where she would tell me “this is just too much” and I keep saying “No, I need to make it at least one year!” that was really important to me. After one year it did start to get a little easier, work started to calm down, I felt more confident and like I actually belonged. work became my haven, it was what was holding me together. I was spending a lot of time going to doctors getting test done, and not getting anything out of that while continuing to get sick. Work became something where I could focus my attention on and I actually had control over. I found going into work as something I would look forward to because I could occupy my mind with thoughts other than how tired or sick I felt.
That started to bleed into my non-work hours because I felt too sick to go out and do something, I would stay in and think about what I had learned recently that I could write about. Writing became a great escape for me. I spent a lot of time thinking about how to optimize the way that I work.
Given that I didn’t have the energy to do absolutely everything, what are the things that I should be spending my energy on?
In that way the lyme disease help me become a better engineer, In that I stopped focusing on low impact things and started focusing on the areas that would make a big difference. As it turns out those are the traits of a good engineer.
The difference between high-performance engineers and everyone else is that they choose to spend their time on things that have a bigger impact than the other engineers do.
Once I realized that it’s a typical occurrence when you have a scare resource. You are required to find better ways to use that resource. I ended up focusing a lot of my energy on more high impact things, more books, blogs, talks and ended burning myself out.
I went through a period where I worked for myself. When you work for yourself the days all blend together and there is no end to your work day. I had to limit myself with a 9-5 work day and I got into much better habits that way. It is important not just when you are struggling with an illness, it is important as a human being to focus on other things besides coding. That allowed me to have room other things I was interested in, I got into meditating, took cooking classes, pilates, Yoga. As it turned out that was really good because the past year and a half I was too weak to leave my house and had to be able to take better care of myself by cooking healthy food and doing little exercising as I could to stay active as that is part of the healing process. The people at Box would say “Wow you are producing so much!” I was really not working 40 hrs a week, instead working between 30 – 35 hours a week based on what I could physically do. When I was working I was focusing my energy on high impact tasks so that the results of my work where a lot bigger, versus just doing every random thing that came up.
looking back, I can’t say it has been fun having Lyme disease but by having these constraints on me has been the driver that has enabled my success. Without it I can’t say that I would have been able to find the work/life balance I need or the ability to ruthlessly prioritize the things that I needed to spend my energy on.
Nicholas C. Zakas blogs regularly at http://www.nczonline.net/ and can be followed on Twitter via @slicknet. He is the author of resourceful books in the development of best practices for progressive enhancement, accessibility, performance, scalability, and maintainability.
Check out Nicholas’ five-star rated books!
Maintainable JavaScript (O’Reilly, 2012), Professional JavaScript for Web Developers (Wrox, 2012), High Performance JavaScript (O’Reilly, 2010), and Professional Ajax (Wrox, 2007).
Leave a Reply