Start from the beginning with a solid foundation, in my opinion. Your initial team sets the tone for how you mean to go on from there. The personalities of your first ten people will set the personality of your company, whether you realize it or not, whether you mean it to or not. I think this is just how groups of people work, kind of a rule of thumb for how organizations grow. npm hired me early, and I have been in the Valley for a long time and seen both successes and failures. I've been lucky to be at the sidelines of some fantastic engineering teams. I was nobody and I did nothing much at General Magic , but the people I watched at work there went on to do gigantic things. But I've also seen stupid teams do stupid things, and I managed to learn from them too. So my contribution to npm has been to help steer the engineering side of the company in the direction I think is best-- which has upsides and downsides. I think there are perfectly wonderful people who would have a bad time at npm, and whom I would not judge for having a bad time. (For instance, if you don't thrive on the written word as a way to communicate with your colleagues, you're not going to be happy with the writing-mad culture at npm.) First and foremost, I hold that the humans who work on the software are more important than the software! We work to live; we do not live to work. The best work is done by well-rounded people who have interesting lives, who come to the office refreshed, who treat the humans around the well, who are in relaxed and happy places. I try to tell my colleagues how much I enjoy working with them every so often. (Dear colleagues, if I haven't said it to you recently, please hear it now. I enjoy working with you yes YOU.) Give this a shot with a colleague you enjoy working with! Tell them! Tell them why! I love writing software. I remain amazed and delighted that I can earn a living doing this thing that is so much fun. I want it to stay fun for me and for everybody around me. This simple desire drives a lot of what I do. I hope it rubs off.

So.... yarn can optionally flatten files, and this is sometimes what you want, particularly if you are targeting the browser. The default npm cli cannot do that, however, because it is designed to work with node module loader and solve node's specific problems, which are quite different. The intent of npm is to avoid dependency hell by dodging it, through the specifics of that loader-- you can have more than one copy of lodash! Your code gets the one that you specifically asked for! This is, you'll note, a tradeoff that is absolutely great for server-side javascript, which is where it was designed to be great. It's the wrong tradeoff for browser-side javascript, where having N copies of lodash is far too costly. So coping with dependency hell and selecting the one winning version of lodash is a different tradeoff, and one that is the correct one to make in that circumstance . In other words, I'm a-okay with a world where there are lots of tools that lay out packages on disk in lots of different ways, because the problems they're solving are different.

We are a test-mad company and this is kinda great. Though I have seen the seamy underbelly of bad tests (tests that freeze your implementation not your interface make for far more work than they ever save). But wow, the testing culture here is strong and it makes for a lot of confident deploys.

Premature optimization is the root of all evil, attributed to Tony Hoare (the person who invented quicksort) and popularized by Donald Knuth. Premature optimization is a trap we're prone to fall into just because of who we are as programmers. I'd characterize it as doing anything before you know you need to do it. pulling things apart into modules before you need to generalizing code before you need to making something really fast and hard to understand before you need to refactoring before you have a reason to acting before you have data to justify the action Be tidy, yes. Don't use this as an excuse not to lift up your loop invariants, for instance, because that's just not being sloppy. But definitely don't generalize something until you have a reason to generalize. (The rule of three is great here.)

Thank you! I like pangolins. They are absurd. <3

I feel very strongly that being on call should be boring . We have very little tolerance for repeated alerts, or for alerts that aren't meaningful. If we see something happening a lot, we fix it or make plans to fix it. Emergencies like, say, a database write primary going away on AWS, are things we can't schedule, but we can plan for them so coping with them is as unstressful as we can make it. We can also rehearse by doing replacements at unstressful moments. But the reality is that if everything explodes at 4am on a Tuesday morning when Europe is trying to get through its workday, I will be paged, and I will get out of bed, and I will join my team in fixing things. Not the whole team, because we'll keep as many people rested as we can. And anybody who's up with me fixing things will take the rest of the day off. I once witnessed first-hand a SAN wipe disaster that was made an order of magnitude worse by sleep-deprived management making well-meaning but stupid decisions because they were sleep-deprived. I have tried to set up processes that will help us avoid this trap at npm. I can't imagine a situation where we let somebody design a feature and nobody else knew how it worked. Code review ftw! Also design review up front. The reality is that some people are always more expert about some things than others, but we try to keep the "bus factor" for any single thing as high as possible. If you spread the knowledge, you spread the burden. No Heros, Please.

I just answered what I thought was the last question! But there are more!

I SAVED THE BEST QUESTION FOR LAST. We had an internal text file that listed a handful of npm expansions. It was early npm employee Zeke 's idea to turn it into a package we could take PRs on and integrate with our website. I asked the company for their favorite expansions, and here are their answers: no problem, meatbag (many of us love this one best: me, @isntitvacant, @maybekatz) now paging Maciej (Maciej is our late-night operations expert) no prescribed meaning (@maciejmalecki is very meta) Never Punch Manticores (@soldair thinks this is good advice) nonchalantly performs magic (@aeflash is our magician) nuǝW pǝuoᴉʇᴉsoԀ ʎlǝʌᴉʇɐƃǝN (@seldo thinks this is awesome) For a while all of the posts we made to npm's blog were legit npm expansions :) Also we all participated in the pumpkin expansions easter egg this Halloween. Did you notice it?

0) aaaaah I want to ship cipm so badly! This scratches an itch we have internally that is so very itchy. A brief explainer: cipm or npm ci is an installation tool design for CI and deployment environments. If you have a package-lock.json file in your project, cipm will install what is described in that file. It will ignore what's in package.json and make no attempt to respect what's in node_modules. It merely blasts the desired installation tree to disk as fast as it can. With a warm cache, this results in installation times on the order of milliseconds per package. (The only speed improvements we are aware of on this, right now, come from un-gzipping in advance. Or writing it in C or something to memory-map the file. The next wave of perf improvements will come in major algorithmic changes in the API that get the cache hot in the first place, I think.) Kat is working right now on integrating cipm inside of the main npm tool. I think we also need to get auth working for it, so there's some work yet before we get it out. But I'm hoping to ship it this year. This is sort of the culmination of plan that team has had for a while now of upending the model of how the npm cli does its work-- calculate a tree, record the calculation, trust the calculation, sync. After we ship that, we have The Problem of ES Modules. We already have some internal experimentation on what the hell to do about this mess. I have John-David Dalton's esm on my exploration list. I think it might be a bridge forward. Some handwavey statements: The server side of JS is largely irrelevant; the browser community is much larger & more actively creative. (Note that I say this even though I personally am a server-side js user, not a browser developer.) In 2 years, the majority of npm's registry will be ES6 modules. Nobody will remember this transitional pain.

I wrote a bit about this in another answer, but really it's a mess and I am never sure if I'm doing it right. We can't do everything we want to do. I can list a dozen projects off the top of my head that I know we'll need to work on eventually that we can't imagine tackling today. The paradox of hiring is this is always true, no matter how many people you have on your team. The more you hire, the more your imagination expands. The scope of work you can conceive expands. So it becomes a matter of balancing the urgent against the important. I rarely try to sell projects. If you're doing the right project, and the information that led you to make that decision is shared, usually people can understand the decision. When something's urgent, my team is usually the people who tell me about it, and I don't need to sell it to them. Or we've messed up by allowing a known tire fire to flare up into a user-visible problem. Sometimes I propose work and I get a huge wave of resistance-- this is a sign that I shouldn't even try to sell it because I'm just wrong. When the evidence is in favor of infrastructure work, the case is easy to make. (I'd bet that with infra work I'm more often telling my team to put it off than trying to sell them on doing it. Ugh, what a fate for a responsible engineer.) Product work usually qualifies as "important" but rarely urgent. It has the trump card of coming from our CEO and of being the work that makes us money. We're all aware that to keep this sparking fountain of javascript sending OSS high into the night air, we need income. Bandwidth and servers are not cheap. So again, the team doesn't need to be sold on it. They need to understand it, absolutely, and to understand why we think it's the right thing to do as opposed to something else. But I think everybody at a small company deserves to have that kind of understanding. It's required if you want to enjoy all the advantages of having smart people build things for you. They'll make great decisions if they own it.