A Stack Story

Something remarkable has happened in our industry. I wouldn’t have thought it would even remotely been a possibility three years ago. But if you look at the facts, you really think about what has happened, the conclusion is inescapable:

I’m now a JavaScript developer.

This is weird.

More than a decade ago I started writing Ruby professionally. I loved Ruby, and still love it. I can solve pretty much all of my problems in Ruby, and I was content with that. I was never one of those polyglots that bounce around every six months on something new. Ruby was just a tool, and I never really cared much about tools. They just existed for me to use. And that was just fine.

I first started writing JavaScript almost two decades ago, and I got good at it. Well, not at JavaScript, but at copy and pasting snippets. First Dynamic HTML fireball cursors, and then jQuery plugins and approaches. But whatever, I was a Ruby developer, that was my game.

But I’ve been building my own company and I’ve found myself with an app that’s half Ruby, half JavaScript. And… I… like… it?

This got me to thinking. I mean, I don’t really care about Ruby, or JavaScript, or whatever language you use, or how you use it. But I started thinking a lot recently about the tools and stacks we choose, and how they impact our companies.

Companies

One odd thing that jumped out at me is that no one really chooses their company’s development stack.

Isn’t that weird? We have a gajillion blog posts and hot takes on which programming language is better, or faster, or hipper. But there’s only three times in the lifetime of a company where you make decisions on which stack to pick. The first and biggest is when the company is founded. Most reasonable technology companies will just coast on related technologies from whatever your founder initially picked. So tip number one: don’t work for shitty founders.

The second is when you’re spreading around the edges. You stand up a small service to do handle some small problem. And most importantly, that’s a small enough thing where you can write it in that Cool New Language you’ve been messing with, and no one will really get too mad at you. That’s really how you can build things at larger companies: just don’t mess with anything big, and hopefully no one will care enough about you long enough for you to innovate something dumb before they stop you.

The final, of course, is The Big Rewrite. You legitimately are running into problems with your tools and feel like starting from scratch will improve your life in measurable ways. I think this happens less regularly than most people think. You’re up against a lot of problems, though: you’ve already hired a lot of people who might have to change skill sets, and they’ll sometimes work against these big changes if it makes their own stature in the company less valuable. It also takes time to change everything over, too, and most companies are terrible at doing a big rewrite while at the same time pushing forward on new features and functionality.

These big platform changes don’t happen very often in reasonable tech companies, and usually not all at once.

But even though it might not happen often… it’s still worth being critical and thinking about what this impact means for us.

Technology leadership

I joined GitHub in 2010. Saw us go from nine people to 250 people, and now they’re closing in on 800 employees.

GitHub’s always been a leader in the Ruby community. And it’s been really interesting — in hindsight — thinking about taking a leadership position in a programming language. There were others, of course: Basecamp, Engine Yard, Shopify, Heroku, Square, and Stripe have all had big impacts in the Ruby world, but GitHub was the most obvious example of a “Ruby shop” to most people.

We benefited immeasurably from that depth into a particular technology. For one, we could hire anyone. Pretty sure for awhile there if you had vaguely heard of metaprogramming we would have thrown you a sack full of money, an option grant, and access to the main github/github repo.

That’s the benefit of being locked-in to a particular set of technology. Of being known for that technology.

And that’s the whole point of a startup: you feel like you have a perspective on the universe that’s obvious to you and non-obvious to everyone else. And if your bet wins, well, you really, really do well.

So being known for a language, framework, or whatever it is… getting really deep into a particular language… that’s good stuff if you’re right. We weren’t already right, though.

GitHub’s an interesting example to look at because it’s so heavily dogfooded. We could build a great product because we ran into those pains ourselves. But years ago those cracks had started to show in the product.

Take a look at it this way. GitHub internally, from the start, is primarily one giant Rails application. There was always a smaller constellation of microservices surrounding it, but most of the product work is going to be bottlenecked in that one repository.

Why is it so hard to do work across multiple repositories in GitHub? Because a lot of their product people only work in one repository every day.

Why do you think it took almost a decade for GitHub to add unlimited private repositories? Because every GitHubber already had free private repositories as an employment perk. They didn’t face the pain that others did.

Why do you think GitHub still doesn’t have deeper integrations with Docker? Because GitHub had written its own library with Puppet to handle development environments, and hardly anyone had used Docker in a professional context. GitLab, for example, came up a little later, and had a team with a broader, fresher background, and that helped lead them to build out a container registry inside the product.

None of this is to say that what GitHub is doing is bad, or good, or anything, really. They’re just tradeoffs. This goes back to an ancient discussion of do you want a lot of depth in one thing, or a lot of breadth across a lot of things?

And there’s a point you reach where you need to start looking at those tradeoffs you’re making and determine if the tradeoffs you made in the past are still valued the same today.

20% Time

Google’s 20% time is, as far as I can tell, bullshit, resulting in requiring 120% of your time. But the sentiment is still worth considering.

If you get away from the math of whatever percentage you’re talking about, what 20% time means is that the company is paying you to work on something that isn’t necessarily your job. It’s a forcing function to get more eyeballs on processes in the company that otherwise wouldn’t be able to justify changes, or a rewrite, or auxiliary services. It gets you explicitly thinking about bigger-picture questions that the company would otherwise not want to address.

I think that’s a powerful thing. If some new technology comes around that legitimately is a game changer, you need people with the experience to have used it in a professional context prior to adding it to your production stack. And you’re never going to have the ability to do that unless you’re uncomfortable enough to build this type of self-reflection into your own workflows. Because if you don’t, you’ll never get to it. There’s always more work to do. More work that needs to be done before you can rewrite this. More work that needs to be done before you can optimize this. More work, more work. Not enough time to dance around and experiment, so you can catch those order-of-magnitude jumps when they do pop up.

So this is how your company can build upon your existing stack, and level it up. Your old way of thinking might have worked in the past, but maybe it’s time for something new. It’s important to challenge yourself, to put yourself in a position of failing.

You

Some of you might have picked up that I’m not really talking about companies. I could give two shits about companies, really. I care about you. I care about me. I care about people. So this talk isn’t about companies. It’s about the people at those companies.

You should spend some time thinking about the tools you use. Not all the time, not even a lot of the time. But sometimes. Ask yourself if the values you held years ago still ring true today. They might, and that’s fine. They might not, and that’s fine. But sometimes you have to make that self-assessment of your own environment.

Sometimes it’s the opposite: you can have just as much problems from bouncing around between technologies too much. Sometimes you just need a home. Depth is just as important as breadth. But again, just thinking about these issues is the important part.

It’s easy to be jaded in this industry. It’s easy to become complacent.

Failing fast

The Fresh Prince himself, Will Smith, of all people, had this pretty good Instagram story this week. He talked a lot about failing fast, and failing forward. That you can’t really get ahead without fucking up, and embracing those fuckups. Part of that is understanding that complacency can be a killer. I wasn’t asking enough of myself, and as such, I found myself complacent. I’d go to the same conferences, see the same people, build the same apps. And again, that’s cool — it’s good to get deeper on concepts, just as much as it is to go broad on other concepts. But I wasn’t self-critical about myself enough to see the problems until I had incurred enough debt to where it was hard to unbury myself.

Again, no one really should care much about developer tools, not really. I’m not really trying to talk like switching to JavaScript holds the secret to happiness. I mean, the language doesn’t have static typing. But developer tools are a small part of life, and a big part of how we express our professional careers.

A lot of this just depends on identifying what you want out of your career. Are you focusing on upward mobility? Do you want to manage people? Do you want to be a senior engineer? A founder? An investor? I wish I would have asked these questions of myself a lot earlier. Because once you start asking these questions of yourself, you start making changes to make it to that result earlier.

Anyway, all of this is just a long winded way of saying: ask yourself questions, see where you’re at, and if you’re not happy with where you’re going, make some changes. I know way too many people who get complacent and then wonder why everything around them sucks.

So get ahead of the curve and start thinking about your Big Rewrite before you actually need it.