Uncheck the struggle box

Jan 28

Next week will be 6 months since I moved to the west coast—the San Francisco Bay area. It’s been eye-opening to see the differences, big and small. It’s got me thinking about the path of Web development since I started almost 20 years ago.

The apps at my current job are single-page interface apps where Node and Rails provide the API to the service layer and Backbone, ExtJS, and Marionette provide the user interface. This technology stack is very typical these days, right? Typical to the point that if you don’t speak at least half of those, or equivalents like Ember and Django, most of the companies around here look at you funny.

As a thought experiment: imagine trying to explain that tech stack to a Web developer circa 1995. Or, I’ll make it a bit easier, how about 2000?

Changing Architecture

If you had come to me in 1995 and tried to convince me that there would be a need to differentiate between a Web server (Apache, nginx) and an Application server (Passenger, Espresso), I probably would have laughed at you and accused you of overcomplicating things. Even as late as 2005, I probably would have said “that’s what load balancing and reverse proxy servers are for”. Those crazy Java propellerheads with their servlet containers were just overengineering things as usual, right?

Developing a front-end app? What in the world is that? JavaScript was cute and all, but there was no way you’d build entire apps in it. Data modeling in JS instead of plain old JS objects? Why would you do that when that one page would just be navigated away from when the user clicked anything?

You might have been able to convince me that MVC was the way to go for Web apps. In 1995 I was writing apps in C/C++ as Apache modules and ISAPI DLLs. It sucked eggs, and I would have been ecstatic to take up anything to make it less of a pain.

Changing Attitudes

Had you shown me a Rails app I would have laughed at you. Convention over configuration? Just put this class file here, name it in this specific way, and include this specifically-named instance method, and poof you’ve got an app? No real Web developer would ever give up that much control. That’s just a toy, right? For kids?

DevOps? Developer Operations? You mean network admins, right? They’re the guys who think I should just put a bunch of files on a network share, or Lotus Notes.

If you asked each of the Web developers on you team if they could telnet to port 80 and type out a legitimate HTTP GET request and get a working response, how many would be able to? What about a POST request? No cheating with curl or wget—you have to do it by hand. But is that even a valuable entry-level skill anymore, what with Firebug, Web Inspector, Charles, Privoxy, etc?

And how long do you think it will be before there are more teams with devs who only know front-end or only back-end than there are who know both?

Changing Priorities

In 1995 (and 2000) the most important attribute you could have as a Web developer, as I asserted while interviewing countless applicants, was an extremely wide breadth of knowledge. You needed to know everything about every aspect of the Web. If you didn’t know it you needed to be able to figure it out, or know where to go for help to figure it out. I didn’t have a need for someone who only knew CSS, or only knew JavaScript, or only knew a server-side language, or only knew this one particular framework. I said over and over again that Web development was different than any other kind of development because we hadn’t stratified to the extent that all those jobs were different people.

In case the writing on the wall isn’t obvious: that stratification has already happened.

You might be working for a company where you’re the one Web person, but if so you’re a dinosaur. An artifact. An endangered species. You just haven’t accepted it yet.

Fifteen or twenty years ago, we needed generalists because the Web was still being invented and you had to be able to cover all the bases. The specialists were those idiots writing IE-only VBScript apps that would only work in that one version of that one browser on that one operating system. But if we hired a generalist we could train them up on the particular combination of technologies we could afford, cultivating them into specialists over years of experience.

It’s probably news to many of the East-coasters, but this has completely flipped on the West coast. The companies out here don’t care about generalists. Generalists can’t help them with this one specific tech stack that has already been chosen. Why train a generalist, when you can get a specialist who is good right now? When you replace your tech stack you can replace your obsolete specialist with a shiny new one—it’s not like there’s a shortage of Web people anymore.

Changing Rick

This year will be 20 years since I got my first email address and wrote my first HTML page. Next year will be 20 years since I got my first paid Web work.

I admit I am struggling with how I fit into today’s Web development world. I struggle against specialization. I’ve got too much perspective to think that tying myself to one stack could ever be sane. And who wants to settle on one thing, anyway?

At the same time I struggle for differentiation. I’m not a kid who’s fresh out of college but has been developing Rails apps for 4 years. I’ve been doing Rails for 6 months—I’m not going to know the perfect collection of Gems for this particular project, but I’m also not going to freak out when someone asks if we can switch out technologies in our stack. (And I wrote my first computer program before that kid was born, dammit!)

I see that I am on the cusp of becoming a dinosaur. It would be very easy for me to wave my hand at the changes in the industry, find some small shop where I can hole up, and do what I can to keep my job how it’s always been. It would be a complete lie, struggling against reality itself, but I could do it.

The scary part is that such a decision isn’t made all at once, but in degrees. I can say that I won’t do it and still find myself inching toward it year after year. Historical inertia is an addiction, just like any other: we want things to go back to how they were when they were good and easy. The best I can do is to keep running—learning and keeping up.

To misquote Kay:

Twenty years ago I knew exactly what I was doing on the Web.
Today I know how much the Web has changed.
Imagine what I’ll know tomorrow.