In the Spotlight - Nicholas C. Zakas

I was doing an interview yesterday here at Yahoo! and we had come to the point where you typically allow the candidate to ask some questions. I have to say that most of the time I'm pretty disappointed with the questions I get. I like to hear questions that indicate a certain sense of passion about working for Yahoo!. Yesterday's candidate I think asked me the best question I've heard yet: "What would you say makes a good front end engineer?" That's a question that I think deserves some discussion outside of the confines of that interview room.

To begin, front end engineers need to know HTML, CSS, and JavaScript. You can't be good in just one or two of these, you really need to know all three. That doesn't mean that you need to be an expert in all of them, but it does mean you need to be able to complete most tasks using these languages without stopping to ask someone for help.

A good front end engineer needs to be able to pick things up quickly. The technologies powering the Web aren't standing still, people. I'd go so far as to say things are changing on almost a daily basis and it's up to you to keep up with these changes. There are always new techniques and paradigms to consider and digest as part of your discipline; you cannot just rest on what you know today. The Web of tomorrow will be drastically different from the Web of today and it's your job to understand what that difference means to your web application.

There are many parts of computer science that are exactly as described: science. The front end is not a science, it's an art. An artist knows not just the tools of the trade but also when to use them. The solution to a problem in one situation may not work in another. On the front end of web applications, there's often many solutions to the same problem. None of them are wrong, but some are more appropriate than others. A good front end engineer knows when to use a particular solution and when to consider other alternatives.

A good front end engineer needs to be able to communicate effectively due to the parties involved with the job. At any given time, a front end engineer answers to at least four customers:

1. Product Managers - these are the folks responsible for the direction of the application. They have a vision of what the application should offer to users and (hopefully) how to make money off of that model. Oftentimes, they will be pushing for more features.
2. User Interface Designers - these are the people responsible for the visual design and interaction model of the application. Their concern is what will make sense to the user, consistency of interaction, and overall usability. They are most of asking for slicker user interfaces that can be challenging to create.
3. Engineering Management - the group that actually builds and maintains the application. In engineering, the primary concerns are uptime (keeping the application available), performance, and deadlines. The push from engineering is usually to try to keep things as simple as possible and not introduce failure points while making changes.
4. End Users - the primary consumer of the application. Though there's often not direct interaction with end users, their feedback is crucial; an application is worthless without people who want to use it. End users typically ask for things that would help them personally as well as things that are available from competitors.

So who do front end engineers care the most about? The answer is all four. A good front end engineer needs to know how to balance the wants and desires of all four groups in order to come up with an optimal solution. Communication is important because front end engineers are at the vertex of communication from these four groups. This may mean that a cool new feature needs to be scaled down because it will affect front end performance or it could mean pushing back on a design would negatively impact the accessibility of the application. As a front end engineer, you need to understand where each group is coming from and be able to suggest solutions that are acceptable by all parties. A good front end engineer is an ambassador, of sorts, and needs to have that mentality on a day-to-day basis.

One of the most important things I tell new front end engineers is not to simply agree to do tasks without first reviewing them. You must always understand what is being asked of you, not just in the form of a bug saying "this isn't working right," but also understanding what the intention of the functionality or design really is. A task to "add a button" doesn't always mean you end up adding a button. It may mean you go back to the product manager and ask what the button is for, and then maybe go to the user interface designer to determine if a button really is the right interaction approach. It's this communication that is vital to being a good front end engineer.

In many ways, I think being a front end engineer is one of the most complicated jobs in computer science. Most traditional programming concepts don't apply and there's a lot of soft science being applied to numerous technologies for usage on numerous platforms. The technical expertise necessary to be a good front end engineer is a vast and complicated terrain made more complex due to the parties you're ultimately responsible to serve. Technical expertise may get you in the door as a front end engineer, but it's your application of that expertise and your ability to work with others that makes you good.

There's a common misconception out there that I'm part of the YUI team. Well, I'm not (I work on My Yahoo!), but that didn't stop me from submitting some code to be included in the 2.3.0 release (details). I've been secretly working on this little creation for the past few months and now that the release is here, I can finally talk about it.

The 2.3.0 release of YUI is the first to include my unit testing framework, unimaginatively named YUI Test. The basic idea was to create a super simple way to write unit tests for JavaScript. I really like unit testing, but found most of the JavaScript options to take too much time to get up and running. With YUI Test, you can include a couple of files and quickly write and run a test case. There's tons of assertions geared towards common JavaScript data types and the default failure messages are helpful enough such that you don't really need to provide custom ones (though that is an option).

I'll be talking more about YUI Test in the coming weeks and months, but for now, check out the documentation and I hope you enjoy the wonderful world of unit testing.

One of the biggest maintainability problems in any language has to be the correct and consistent naming of variables, classes, and methods. In most languages, keywords can't be used as identifiers, so there's always a warning if you attempt to do something dumb. JavaScript has keywords and reserved words that can't be used as identifiers, but there's also a number of host objects that exist and can be overridden without any warning.

So, quite simply, here's a list of variables names you should never use because they are host objects in JavaScript and should never be redeclared:

• self - I see this a lot when setting a pointer to the this object, such as: var self = this;. Oftentimes, this is how developers are keeping a reference to an object for use inside of a closure. The problem is that self is already in use as another pointer to the window object. Don't redefine self as something other than what it is as it could confuse others looking at your code. (proof)
• top - This one is most often used in combination with a variable named left to determine or set element coordinates. Once again, the problem is that top is a host object, it points to the outermost window object and is most useful when used from within a frame. (proof)
• location - I'm surprised, but I have seen variables with this name. This is a host object containing information about the page that is currently loaded. (proof)

Again, these are variables names that should never be used. When people expect variables with particular names to behave a certain way, it's always dangerous to change their behavior. You might as well just start redefining methods on the window object.

Way back in March, Yahoo! held its internal Front End Engineering Summit at the Sunnyvale campus (my base of operations). At the Summit, I gave a presentation on what I like to call Maintainable JavaScript. The good news is that it was videotaped and is now available over at the YUI Blog.

The idea behind Maintainable JavaScript is that there are many ways to write code, but in an enterprise environment your priority should be on maintainability (versus strictly performance or adherence to particular programming paradigms). The talk describes things you can do to make your code more maintainable as well as things you should avoid; I hope you enjoy this talk.

Stephen Chapman, the JavaScript guide, has posted a great review of Professional Ajax, 2nd Edition. From his review:

A book for the programmer with a good knowledge of Javascript, XML, and at least one server side language wanting to combine these skills to produce client/server web applications. Provided that you have a sufficient understanding of programming to follow the examples, this book will introduce you to the real future of client/server interaction on the web as well as providing you with some of the tools that will make implementing this type of interaction much easier. A must have book for anyone wanting to use Ajax.

Hopefully, this is the first of many good reviews. Speaking of which, if you're someone with a high-traffic, tech-related web site (or someone who contributes to one such as Slashdot), drop me a line if you'd like to review the book. Reviews on Amazon are also appreciated.