August 16, 2016
From, with love.

Joining a New Team

Hi everyone,

Everyone joins a new development team at some point in their career, whether it's your first job out of school, switching to a new team at the same company, or moving to a new company. First impressions matter, and a bad first impression can have lasting negative effects on the team and your reputation, which is why your behavior when joining a new team is so important. It doesn't matter if you are joining as a tech lead or a junior engineer, there is a right way and a wrong way to join a new team. 

When I joined my Box, I was told my job was to "fix" the front-end. That was it, everything else I had to figure out on my own, including what the actual problems were and the priority of each. I was to join the already-existing client-side frameworks team who were already working on what they believed to be the best solution for fixing the front-end. I was joining as not just the tech lead of that team, but also of the entire web application. It would have been very easy for me to come in on day one and pointing out all of the problems I saw and start focusing work in another direction. But I didn't.

Doing that would have made me look like an outsider with no real idea about how things were done, and it would have been an accurate assessment. I didn't know anything about the application, the processes, the problems developers were having, or what the current solution was meant to address. Just like anyone joining a new team, I had a visceral initial reaction to what I was seeing (ugh, you use single quotes and tabs???), but I reminded myself that my reactions at that point were uninformed and also normal when being introduced to a new way of doing things. What did I do instead? I waited, asked questions, and learned.

Instead of declaring what I saw as wrong right away, I went and spoke with the other front-end engineers and asked them both what parts of the web application were good an what were their pain points. I did a deep dive with the client-side frameworks team on the solution they were designing and asked them about their transition plan and what problems they were trying to solve. I only offered my opinion when I was explicitly asked for it. And of course, I wrote and shipped code so I could get used to the processes and tools. 

When I finally started suggesting changes, including that we should start over from scratch on a new client-side framework, nearly two months had passed. In that time, I had earned the respect of the team and they were ready to listen to what I had to say. If I had tried to push through these changes earlier, there would have been resistance (and rightly so). But I was playing a long game. Those engineers were much more familiar with everything about the Box web application, and I had to earn their trust, ensuring that they knew I was there not to tear down what they had built, but rather, to help them improve upon it. 

So the next time you join a new team, keep this in mind: wait six weeks before complaining about anything. Different code styles, processes, and tools take a little while to adjust to.Give yourself the time to adjust and learn why things are the way they are.  No matter your position, don't act like the team's savior. Think of your job as adding to and improving what is already there, and after six weeks, you may find that things weren't as bad as you thought. There's no rush, this is a long game. 

Be well.


Exclusive Offer: Understanding ECMAScript 6

It took me over three years to write Understanding ECMAScript 6, first released as a self-published ebook. Now, Understanding ECMAScript 6 is being released as a print book within the next month. The book, published by No Starch Press, is professionally copyedited and laid out. As a newsletter subscriber, you would have received a special discount code to buy the print copy and ebook together for 35% off. Subscribe now

Recommended Links

Stuff I Wish I'd Known Sooner About Service Workers (article)
Service workers are one of the most exciting new browser technologies, and wish support expanding to Firefox and Edge, a lot of engineers are taking the time to explore service workers more closely. This brief article talks about some of the gotchas one engineer had while working with service workers for the first time.

Design Better Forms (article)
Something as simple as designing input forms is, in fact, not every simple at all. There have been entire books written and a lot of research conducted on which forms work best and why. If you're like me and don't have the time or energy to read through all of that research, then this article is a great overview of the most important points. Complete with screenshots, this article covers all of the most important topics in form design.

The Problem with CSS-in-JS, Circa Mid-2016 (article)
There has been a trend towards injecting CSS into JavaScript rather than writing traditional CSS stylesheets. The most towards component-based systems such as React has only amplified this trend, and approaches like CSS modules have codified it. But is CSS-in-JS all that it's cracked up to be? This article says no, it is not, and gives a practical example of how old-school CSS can solve a problem easily where newer techniques struggle.

Moment of Zen

"People should stop looking at open source projects as a free product, but as an investment they are expected to contribute to."
- Sashko Stubailo (on Twitter)

Recommended Book

When I first ended up in a leadership position, I was struggling. I found it difficult to get people to do what I wanted, and it was during that time that Nonviolent Communication came into my life. While the title sounds a little bit sappy, the techniques and tools presented in the book are so invaluable that I've read the book front-to-back three times (and keep it handy to look up specific situations as well). This one book, more than any other, transformed the way I looked at interacting with people and made an immediate positive impact on my work relationships. I started to see how I was being overly aggressive and unintentionally putting people on the defensive, short-circuiting relationships right from the start. With the help of Nonviolent Communication and some mentoring, I was able to positively affect my work and personal relationships very quickly, and I can't recommend it enough.

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...

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


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. 
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences