That’s cool. And you can’t not respect that. Duder is awesome and smart.

As for me, I’m staying with Node.js. We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere.

The problems that T.J. points out with Node.js are very similar to the problems we have in English, metaphorically speaking of course. Error handling is natively error prone, callbacks are harder than regular synchronous transactions, errors, errors, errors. We make grammar mistakes all the time in English, but for the most part, we all understand each other, and have known solutions to fix those mistakes.

Just for fun-sake, if JavaScript is English, then Go would be Hawaiian. Simple, small, effective, less error-prone, less well known, and on its own island. And for that matter, I guess that makes Java, German. I’ll stop.

Anyway, metaphors aside, and rather than tit for tat comparing the nooks and crannies of Go vs. Node — there are several other good reasons to continue using Node.js

Web Applications

With Node you can literally share your code between the front and back of a system. Website’s I’ve worked on such as Change.org, OpenLikes, even the one you’re reading this article on share utilities, models, views, testing libraries, even routing logic because of Node. This of course leads to more DRY applications, a principle of programming that is highly desired for maintainable applications.

Recruiting

Due to the mass popularity of JavaScript, everyone knows it — at least a little. Hiring for Go — I wouldn’t even know where to start. And as an aside, this is a personal problem, but nevertheless, a problem I can avoid by simply sticking with Node. Node and Go are roughly the same age, but JavaScript is 19 and moved out of the house. Programmers who have known JavaScript for years with zero Node experience can quickly get acclimated without hassle

Twitter / billwscott: 2 new hires this week (diff ...

2 new hires this week (diff teams in my org), got acclimated to code base and checked in first commit in < 4 hrs. In 2011 this took weeks.

Right tool for the job

Like all things, it depends. If it’s a complex intelligence algorithm that requires high concurrency — sure, something besides Node can be fine… as a service… that I can call from Node. As far as measuring concurrency and speed between Go and Node, it would the equivalent of comparing whether a for loop performs better going backwards or forward. These kind of microbenchmarks don’t appeal to me. When choosing a programming language or framework or library, always consider the ROI for your product and how effective you’ll be between your users, your team, and yourself.

The Moral

I don’t want this to be a very long retrospective — So, similar to TJ’s advice — there are lots of awesome solutions out there; pick one you will do well in and will ultimately make your users, company, and yourself happy.

This is a story about a reconstruction project I worked on at Twitter Inc.

I like to think (to a degree) that this was an idea that myself, and a colleague of mine (Vítor Lourenço) came up with during the years’ end of 2009. The company (Twitter) asked all the employees to come up with an idea to be next years big thing. And so we came up with a list…

The Backstory

At the time (October 2009), I was working on a marginal feature of the website that allowed business accounts to allow other accounts to tweet on its behalf. Aka: multi-account switching. Lots of small-businesses wanted this, but it was terribly boring to work on. I was pairing with a Pivot (all these guys are awesome) written in an application stack (Ruby on Rails) of which I barely understood. So to be honest, I did hardly any work for about three months (or at least it felt like it).

Simultaneously, Vitor was off designing… pretty much everything across Twitter, kind-of like being a Design fairy for anything that required something to look good. Nevermind that matter, we always remained friends and would chat together during lunches and breaks despite working on completely different projects.

Then… at the end of the year, we made up an ambitious project for 2010 just for kicks. In summary, we wanted to rebuild Twitter.com. In other words; Get rid of everything and start over. We even called it Phoenix (the bird of re-birth). Twitter loved bird names, so it seemed fitting. (Much) Later when the project actually occurred, the name Phoenix was chosen, but not because we thought of it. It was just a coincidence.

We went on to make a list on a piece of paper (God I wish we saved that) noting all the features it would have so that we could put it in the idea box. Yep, there was a real-life meat-space idea box with a slot to drop in your piece of paper for the execs to read. And as silly as it was, people did it.

Anyway, back to this piece of paper, having recently jumped ship (April 2009) from Google (Gmail) I knew there was a hundred things we could do better based on the existing (shit) website. Here is a rough recollection of what that list looked lit

- it should look like an app, not a website
- infinite scrolling

- keyboard shortcuts
- tweet from anywhere
- drafts
- autocomplete
- faster
- prettier
- photos!
- quicker access to all data (mentions, searches, lists, messages)

After we made this list, and I could be mistaken, I think we literally just left it on a random desk and never put it into the idea box. It seemed like such a pipe dream and it was too easy to get demotivated from the daunting task of yet another company doing yet another redesign.

The year ended and I moved off my project, and was headed back to the web team in January to work on… maintenance.

@Anywhere

January came, and during some arbitrary work hour, in the hallway, COO Dick Costollo pulls me aside and informs of this thing he wants me to build called @anywhere. Sounded cool. Big. Impactful. And JavaScript heavy. To familiarize folks who don’t know what this is. It was like Twitters version of the Facebook Connect Platform. Which took those (smart) dudes the better part of a year to build.

Ok. So…

I couldn’t work on it just myself. So I asked Platform Director Ryan Sarver if I can bring along my friend Russ D’Sa, an extremely talented and dedicated Engineer. We hacked together on the project for maybe two weeks, throwing around ideas, making API prototypes for cross-domain communication through iframes.

We then learned from our product team that Twitter wants to launch this in two months! It was a solid wtf moment.

So we asked for another Engineer, Dan Webb, and we got him and Todd Kloots. Cool.

The next two months were insane. Our wives and girlfriends have since forgiven us, but we launched on-time.

Asynchronously

Another project was on the rise known as Galapagos. It was a supposed effort to give Twitter a facelift. Nothing of a re-architecture, just some changes to HTML & CSS. Our designers, Doug Bowman, Zhanna Shamis, and Vitor were all putting together mockups. but no one was building them.

The Week Before

After completing the @Anywhere project, we were left with a completely client-side API to all of Twitters resources, including authentication.

Just to pontificate on this for a second, you know all those people that say “Twitter can’t be that hard to build. I can build Twitter in a weekend.” And of course, the proper Engineering response is, “No. No you can’t.” Like all software, problems are much harder at scale.

Well, we changed that, for JavaScript developers. Now, you can build Twitter in a weekend.

And that’s just what we did.

The Demo

Vitor and I put together this Galapagos mockup, and turned it into real-life, in a good course of a day. Then demo’d it to the entire company.

If I recall, I don’t actually remember much applause. Just awkward confusion. It sort of reminds me of the time my wife and I took our 1 year old son to a 3D movie for the first time. He just sort-of sat there, in shock. Nothing made any sense. And in the end, he was scared. So we had to leave the theater.

Luckily, Ev understood. So he pulled Russ and I off the project, and asked us to lead the frontend effort for this new Phoenix Project.

Phoenix

Four months. Seven Engineers. Three Designers. Two researchers. One PM (Kevin Cheng). And Ev. You can read about that here.

We implemented all the things we talked about, including the ingenuity of adding embedded media (Ev’s idea). It was otherwise known as the D.P. (details pane) that featured white-listed content like YouTube videos, Flickr photos, Google Maps, Etsy items, etc.

What did I learn?

Nothing nobody hasn’t heard before. But it was good to experience them first hand. And in no particular order…

You can build anything you want if you are driven, dedicated, and smart enough.

You’ll work faster, and better when you work on things you care about.

You will slouch, drag your feet, and work much slower when you’re forced into positions that aren’t right for you.

You will build a lot of shit, but it’s okay to ship it and iterate.

The product

It was much, much better. And people loved that. Even though it was the same product, it was much faster, and it gave our users much more power to use Twitter in a meaningful and useful way. And in most eyes, it was seen as one of the most successful redesigned / re-architected products this last decade. Why? People hate change. But for whatever reason, the people welcomed it with open arms. A few of us were even offered sexual favors from our users to get access to #newtwitter.

Thanks for listening.

Dan and Kristin celebrate an hour after the launch (photo by Dan Pupius) was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.

Jean attempts to reproduce a test-case (photo by Dan Pupius) was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sho files another bug (photo by Dan Pupius) was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Decider makes a call (photo by Dan Pupius) was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.

Team is heads down finding last minute bugs (photo by Dan Pupius) was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.

It was said that Dan couldn’t laugh. was originally published in Launch Day on Medium, where people are continuing the conversation by highlighting and responding to this story.