June 21, 2016
From nczonline.net, with love.

You Can't Do It Alone

Hi everyone,

Have you ever thought that your development team is doing too many things wrong? If only you were in charge and could make all the rules, everything would be great? And then you start daydreaming over a project you'd start on your own that would end up being beautiful and there would be barely any problems because things were done your way?

I admit, I have these thoughts frequently, and I expect many of you do too. It's normal to think, "if everyone just did what I said, everything would be great!" So let's say one day you have a great idea for a product and you start writing it yourself. Naturally, you'll use your favorite platform and programming language, and you'll use your own coding style (helpfully enforced through automation), write tests the way you want, and generally set things up so you're happy. And then, seemingly answering your dreams, the product becomes a huge success!

All of a sudden, you can't keep up with your customers. Your application needs to scale to handle more requests, you're getting bug reports and feature requests from customers. Before you know it, you're working 24 hours a day and 7 days a week, and you're burning out. Fortunately, your success has brought in a lot of extra money, so you decide to hire some people to help you out.

You hire two people and teach them how you want things done. They happily oblige for a while because they're excited about the opportunity. You ask them to check with you before making any big changes. More success, so you bring on more people and have the first two teach them what to do, all the while still checking in with you on big changes. Before you know it, your day is taken up with people asking permission to do things. Every few minutes, "is it okay to do this?" What's worse, morale is low because people feel like they can't do anything without checking with you first. That's very discouraging, especially when you take longer and longer to consider their requests (you have a big backlog of other requests to consider first). 

At that point, you have no choice but to start delegating parts of your job to others. You end up needing to push decision-making down to the front lines so things can keep moving. Yes, that means people will be doing things in ways that are different from yours, and you concede because it's going to make your life easier in the meantime. They change the coding style. They decide to switch programming languages. It's not the way you would do things. And then you start dreaming about a project you'd start on your own that would end up being beautiful and there would be barely any problems because things were done your way.

The lesson: things will never be 100% the way you'd prefer. Learning to accept that and trust your colleagues is the best way to succeed.

Be well.


P.S. I recently had to leave my job for health reasons. You can read about it on Medium.
JavaScript WeeklyDo you enjoy the newsletter?
You can help support it. Leave a tip or become a patron.

Recommended Links

Bringing seamless checkouts to the mobile web (video, 29 mins)
Coding credit card forms isn't a lot of fun, and though there are ways to reduce the pain (both for developers and users), wouldn't it be nice if you never had to create or use a credit card form again? The Web Payments API, currently in development, is try to do just that. This talk shows demos that the Chrome team is working on and testing giving you a preview of how payment processing is likely to work on the web.

Four types of leaks in your JavaScript code and how to get rid of them (article)
If you've spent any amount of time writing JavaScript, chances are you've also spent some time trying to hunt down memory leaks. The intricacies of garbage collection aren't well-understood by developers, and this article digs into the low-level details and explains problems that lead to memory leaks. This is one of the most extensive articles I've seen on the topic and well worth the read (it's a bit long).

Intersection Observers Explained (article)
Whether you like it or not, infinite scroll has become a favorite interface for today's web applications. However, the way we implement infinite scroll is inefficient and error-prone. In practice, it's always been tricky to know whether something is visible in the viewport or not, especially while someone is scrolling. Intersection observers are the solution to this problem, providing an API to specifically determine when certain elements are visible or otherwise intersect certain areas of the page.

Recommended Book

When I was healthier, I did a lot of public speaking. Speaking is a great experience, but definitely a bit strange, especially if you're an introvert like me. Confessions of a Public Speaker is a great overview of what it's like to give a lot of talks. The author talks about what makes good speakers, and how it's often hard to trust direct audience feedback. And of course, no book about public speaking is complete without covering when things go wrong. Overall, a great read for anyone who has ever, or might ever, give a talk.

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