August 30, 2016
From, with love.

For the Good of the Team

Hi everyone,

I was working on the Yahoo homepage team when the iPad was first released. It took us all by surprise and we weren't sure how to react. We were in the middle of a major rewrite, so there weren't a lot of free cycles to focus on it. However, I had free time on my hands and so I set out to determine the best path forward. This included running out to the Palo Alto Apple Store to buy an iPad directly, and then proposing that we create a tablet-specific experience for the homepage. My manager was happy to agree.

You see, I had fallen into one of the trickiest times of being a tech lead: by necessity, I had to delegate most tasks that came to me. I was used to passing off interesting work to someone more junior because it would be better for them to get the experience than for me to do something I was already familiar with. As such, I had more free time than I'd had at any prior point in my career. I was a bit bored and wanted something new and interesting to work on, and creating a new tablet experience for the homepage seemed like just the thing to keep me busy.

The next week my manager pulled me aside. There were a couple of team members feeling disinterested in their work, and when he asked them what they would be interested in they both replied the tablet homepage. He had decided that it would be better for them to work on the tablet homepage and I could stay on as their mentor to provide guidance (because it was my idea). My heart sank. The project I had dreamed up specifically to not delegate was now forcefully being delegated to other people. I begrudgingly said of course, I'm happy to do whatever is best for the team.

This is an aspect of teamwork that often goes unmentioned: being a part of a team means that sometimes you end up not getting your way because it's better for the team that you don't. Working together means not only supporting and collaborating with others, it also means sometimes accepting personal disappointment for the team's benefit. In my case, I was unlikely to leave the company whereas the other two engineers who took over were. They were valuable members of the team and we wanted to keep them happy and engaged, and so I took one for the team and let them have the project.

As those who've followed me for a while know, I frequently cite my time at Yahoo as the best period of my career. That doesn't mean there weren't disappointments along the way or things that I wish went differently. Yes, I wish I could have worked on the tablet homepage myself, but ultimately choosing not to complain about it led to earning a lot more respect from management and the team in general. I take a lot of pride in being a good team player, and ultimately, being a good team player will get you more career opportunities than any one project.

Be well.

This newsletter is subscriber supported!
There are many ways to support it: Leave a tipbecome a patron, or buy a book.

Recommended Links

Demythstifying Web Components (article)
You've probably heard of web components, but like many front-end engineers, it's likely you don't know many of the specifics. That's partly because web components have been in development for years and still haven't made it to all browsers (also, there was a major rewrite during that time). Still, web components are an important upcoming technology that you should make an effort to understand. This article tackles frequently-repeated web component myths in a concise (and incredibly blunt) manner.

Test on the Right Mobile Devices (article)
If you're building a web application, it can be hard to know which of the seemingly endless number of devices you should be testing on. How many mobile devices get you good coverage? Which tablets make sense to test? How many different operating systems should you care about? This easy-to-use guide provides advice on where to focus your testing attention based on the size of your audience.

The Cost of Small Modules (article)
There's been a movement to create ever-smaller JavaScript modules; some modules contain just a single function. Is that a good idea? It turns out that what you buy in organization you may end up paying for in download size and execution time. This in-depth article explores how small modules can affect your page's performance based on the tools you use.

Moment of Zen

"The hardest problem in computer science is fighting the urge to solve a different, more interesting problem than the one at hand."
- Nick Lockwood (on Twitter)

Recommended Book

It seems like software engineers are always obsessed with building the biggest, most successful thing in the world. Living in Silicon Valley, I hear this a lot: you either want to conquer the world or else you're not trying hard enough. But there is a middle ground, and Small Giants explores that middle ground beautifully by following companies that chose to stay small. These companies decided that they'd like to do one thing really well instead of spreading themselves too thin or growing to a size where quality would suffer. This book is a great reminder that you can be happy and successful without conquering the world.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...

Books I've Written


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences