After 4 years at a growth stage startup, joining a mega-corp like Google has been quite a change. Of course change is exactly why I decided to join such a behemoth – I’d worked at O(10), O(100) and O(1,000) person companies, I began to wonder what an O(10,000) person company might be like!

Decentralizing Everything

A traditional prioritization system begins with the CEO setting high-level goals, which trickle down the management chain, eventually to ICs. At some middle layer, the goals are turned into projects with measurable performance indicators. Members of the team are then judged by those indicators. There’s an assumption that the individual metrics are indicative of moving the needle on the company ones.

So far it seems like there is no middle layer at Google. In the Advertising division, we all have the same top-level metrics – 1) user experience and 2) revenue. Each of us comes up with our own projects and initiatives and goes for it. To frame it against a more common vocabulary, each IC has the responsibilities of a TL and managers perform in a more advisory function.

The expectation that each IC should come up with their own projects, design them, timeline, track and bring them to completion is a very high bar. Being able to code well is an expectation and isn’t really a differentiator since everyone can sling code around.

I’m still wrapping my head around this, it’s definitely the biggest change I’ve encountered. It’s only a month in, but as far as I can tell, I don’t have quarterly/annual goals. I’ve been encouraged to find things I’m passionate about and make a difference.

Automated processes
It’s shocking how automated everything, EVERYTHING is. I had an ‘aha!’ moment after requesting access to some files and receiving an email seconds later. It said, “Your request has been approved by our ML approver, which identifies low-risk grants.” Code style has also been automated – which allows feedback to be at a much higher level, since your code is guaranteed to have consistent spacing, capitalization, newlines, even typos are caught.

Dogfooding
This was super cool, having access to pre-release versions of YouTube, Android and pretty much every other product that Google has. It’s been awesome to see how the scale of employees at Google provides a huge value of high-quality testers who can provide high-quality feedback and reproduction steps for bugs.

Strangers everywhere
When I run into someone there is only a 5% chance I’ve met them before or know them. Day after day this is very strange to me! I used to know every single coworker, the name of their dog and their favorite type of drink.

For the purposes of this post I will define a startup as a company having these characteristics:

• The services which make up its “core products” are still changing
• Processes around human resources and the work itself are still evolving
• Teams frequently change in size / composition to adapt to new challenges

What I love most about this environment is that everything is negotiable. Titles mean little and a good idea can change the course of a ship bearing hundreds of people.

1. Take Initiative
Everything is your job. Dishes need washing? Support site has a typo? Interviewee looks lost? Step up. Training docs are poor? Finish your commitments and help the team.

2. Engage with the Business
Learn how the company earns money today and how is it hoping to tomorrow. Which products have high margins, which are loss-leaders? Learn about the customers and what they care about. How do the teams fit together and why were they created?

3. Have Positive Relationships
Be friends with your coworkers, care about them, know about their lives. Do this during work, after work and outside of work.

4. Attention is a finite resource
Whether it’s speaking in a 4 person meeting, asking for a code-review or blasting out an email – be aware of the time you’re asking others to spend on you. Make it worth their while and make it easy for them.

5. Plan for change and failure
Invest in making mistakes cheap to correct. When building new products/models specify its end-of-life. Creatively minimize upfront investment for unproven ideas.

6. Be time efficient and self-aware
Identify opportunities with disproportionate work-to-value ratios to make the most of your time. Catch yourself when you are spinning your wheels and ask for help.

7. Identify the movers and shakers
How do truly transformative ideas – like top-level strategic pivots – happen at your company? Find the thought-leaders within the company. These are the people with big ideas and the charisma to build consensus around them. These people are rarely on the exec board and are often more accessible than you may think.

Bonus material – helpful books

• The Charisma Myth – intro to leadership charisma and how to positively influence others
• Getting More – practical guide to negotiation skills and creating positive-sum situations
• The Lean Startup – de facto intro to agile startups and ideas around practical MVPs

Cooperative sounds good, right?

Life has been humming along; work has stabilized after a period of seismic activity; for all I knew we were doing things right. I could have happily gone on with my life, leading a culture of cooperation within my team, had I not scrolled past this interesting table by John Spencer:

I love this because as I read the left side, it mirrored my thought process of thinking “yea! Cooperation is sweet.” Immediately when I got to the first line of the Collaborative column, I was thinking “Ahh, but this is better!” Without saying anything negative, he shows us that you can run an organization either way, that you need both, but there is a distinction.

Continue reading Cooperative vs Collaborative →

This morning a question blossomed into my head, prompting me to check out an old game named Planeshift. It is an MMORPG that differentiates itself by asking players to roleplay in character and not break the illusion. They’ve developed a deep and colorful backstory – all taking place inside of a hollowed out stalactite! By elevating story-writing and art as equal importance to coding new features, they’ve built a wonderful alternate universe.

I decided that I’d like to come back to this game, which remains exactly as lovable as I remember 6 years ago when I volunteered 3d models, and contribute in a different way. Publicize it, share it, optimize their Customer Acquisition Funnel and build a pipeline of new players into the game. There are a few hurdles for them to overcome first and as a thought process I will list them out here.

Roadmap

Remove Barriers to Contribution:
Think about how quickly someone can go from hearing about the project, to seeing the code, to submitting a change to fix a typo or comment. This should be minutes.

Unfortunately with Planeshift it is weeks. This is problem is compounded by the fact that active development is happening in a private branch that potential contributors don’t even know exist. This is a big no-no for two reasons. First, it makes the project look dead to outsiders, and second it literally prevents first-time contributions.

Continue reading Roadmap for Planeshift’s Developer Community →

NYC AWS Pop-up Loft Pitch Event

Yesterday I had the pleasure of visiting Amazons Pop-up loft in SoHo, and listen to five startups pitch their ideas to a crowd of fellow engineers, entrepreneurs and VC investors. Each presentation had something unique to offer and many triggered interest from the crowd, but one of them in particular stood out.

Only one of them made me forget I was standing, forget my surroundings and get lost in the swirl of ideas and possibilities. It was Skopenow, a service which crawls the internet to compile profiles for people. Ultimately generating a report which is someones digital identity. They interestingly avoid the stickypoints of privacy litigation by not storing data themselves and instead aggregating it live from other companies and services.

Continue reading AWS Loft – Skopenow and Privacy →

This Tuesday I will be hosting my first office hours!

This is an opportunity for anyone in the world to have 15 minutes of time to chat about javascript, web development, or computer science in general.

I will gladly give you my ear, my time, and my best effort to help you figure it out.

There will be four Skype slots, on August 4th.

August 4th, 7:00 – 7:15pm EST — Booked
August 4th, 7:15 – 7:30pm EST — Booked
August 4th, 7:30 – 7:45pm EST
August 4th, 7:45 – 8:00pm EST

For more info, read my post here.

Optimizing File Size

I decided to tackle file size as a fun side project at the office. After our big refactor for JW7 we finally had a modular, clean(er) codebase – so now the fun begins. Let’s squeeze it down as small as possible!

With this kind of task it’s always best to set some goals, pluck the low-hanging fruit and then re-evaluate. Our current player size was 232 kb minified, and as a team we established a goal of reaching 200kb.

To identify targets for refactor, I enabled verbose reporting on WebPack. This causes the compiler to output the size of each module independently. I piped that into a file and deleted everything above and below the modules list.

The results

Continue reading Optimizing Webpack build size →

I want to take a moment to jot down a list of trials I didn’t see coming. They accumulated to the point that after 4 months, I wanted to quit. However it was too late, and I am -for better or worse- too impatient to use QWERTY.

Unexpected difficulties with Colemak

1. When computer boots, I need to type my password in QWERTY mode until app loads (true for mac and windows, not true for ubuntu)
2. I need to install software inside my virtual machines, as well as on the computer
3. How frequently I type on other peoples computers, especially when training new hires
4. After learning the keys, my muscle memory for timings would be slightly off
5. Key-bindings in video games (StarCraft 2) are demolished
6. Colemak isn’t necessarily the best, there are new trendy ones showing up daily

With these being noted, I still think it’s worth giving up QWERTY. For a new adopter I’d suggest viewing a few other alternatives as well, including the Workman, Norman and maybe others too.

One idea for the future that would make life a lot easier would be an app which detects your keyboard layout as you type and swaps them automatically. When my friend types “google.com” into my laptop, and the computer sees “tlltuk.c;m” it will figure it out and just swap back to QWERTY.

Like most engineers, I am a huge fan of lifehacks. Why not improve HOW we work? Well the latest experiment I tried was switching from the dated QWERTY keyboard layout to Colemak.

Context

When I switched to the Code Keyboard, I was very inclined to love it. I wanted to adore it, it was designed for me; it was beautiful, nerdy and well designed. Unfortunately over the first week the joints in my fingers began to ache- I believe due to the resistance of the cherry MX Clears. I wasn’t ready to give up on the keyboard so I did some research into reducing the strain of typing. It turns out QWERTY is known for being inefficient; lo and behold, there was a readymade solution in the form of overhauling the keyboard layout.

So I declared to the world that I was making the switch.

Why?

1. Hopefully eradicate finger pain
2. Improve my typing performance (speed, accuracy)
3. Be an early adopter of what I believe to be an important movement

I do expect to be making some sacrifices, such as

1. Decreased productivity during learning curve
2. Need to install software on my machines

The challenge

We were recently looking for a way within Backbone to elegantly handle event delegation from sub-models. For example a house has many rooms, and each room has one or more desks. In this case each stage is a model which owns and should be able to monitor changes to its children. For example, a house may want to monitor if there is a change to the ‘occupied’ attribute of any desks inside it. I was tasked with comparing two plugins which solve this problem: Backbone Relational andBackbone Associations.

1. The documentation – in my humble opinion the documentation should be responsible for three things. Describing the problem, describing the solution and explaining how it wants to be used. That’s it. Skim over it, try to see which assumptions they are making but come to your own conclusions. It’s tempting to look at all the nice features but that doesn’t mean you should jump on board.

2. Source Code – Read every line, and then don’t use a plugin that you couldn’t write yourself. If it doesn’t read smoothly and you find yourself questioning their decisions than you need to back away.

3. Favor the simpler solution – Brevity is elegance. Extra features are added complexity, and you want the bare minimum that works for you. Complexity will come over time as you start adding domain logic, which is why you want your building blocks to be as concise as possible.

4. Be wary of dependency chains – This hasn’t been a problem for most plugins I’ve viewed, however it isn’t uncommon in real applications.

5. Check out the community – is this something that’s up & coming (like angularJS today) or something on the decline (mootools). How often are non-primary developers contributing and how active is the owner? The facts are easily available on Github and give you a real sense of how the plugin will stand the test of time. You don’t want to be the last person on the bus, nor do you want to be the first. *BONUS*– Send a message to the developers and see if they respond.

Okay, but what about these backbone plugins?

1. The Relational documentation follows the format of underscoreJs.
2. Equal
3. Associations was much shorter / more elegant
4. Equal
5. At this point I already made up my mind, but I did shoot a message to dhurvey on Twitter and he responded within a day. Reliable guy!

The primary selling point for me was that it was a fourth of the size of Relational. It was significantly easier to read and was more specialized (it didn’t solve problems I don’t have like many-to-one relationships). Admittedly Relational had a larger user-base and it’s community was a bit stronger, I messaged it’s owner on twitter and got a response within a day. The rest was about the same. I knew I could re-write it if I needed to whereas I didn’t think I would want to re-write relational. Finally they had the same API which makes the transition between them easy if we change our minds later.

After realizing that I had a strong preference for Associations I prepared my argument. I stated the maintenance benefits of choosing a smaller solution, and I bragged about its code legibility, but what got everyone’s attention was when I mentioned its performance benefits. Backbone Associations was nearly twice as fast for very large objects as compared to Relational.