Monthly Archives: August 2013

What Actually Motivates You At Your Job

Have you ever thought about what is the #1 important thing to you about your job?  It’s a difficult exercise, but try rank sorting the following:

  • Having a great boss
  • Getting paid well
  • Getting recognized by peers
  • Liking your coworkers
  • Making progress on your tasks
  • Work / life balance
  • Learning / Growth

Man, that is like, really hard.  I want them all.  Everyone always says that you quit your boss, so maybe then having a great boss should be #1?


I recently read a book that did a study of tens of thousands of employees (and had them keep journals) and did actual quantitative analysis of what made them happy in their job.  Really interesting stuff.

Turns out that the overwhelming thing that drove work fulfillment was GETTING SHIT DONE.  Well, more acutely and less profanely, making progress on meaningful work.  Doing a mundane task that had impact on a larger mission was still a positive event – and working on something cool/complex that wasn’t deemed important was not a positive event. Indeed bad relationships with coworkers or even bosses obviously negatively impacted work fulfillment, but it wasn’t as large of a factor as making (or not making) meaningful progress.

The book is called the Progress Principle, and it’s definitely worth a read.




Why is the Gaming Industry So Far Behind?

I’m one of the rare people who has split his career (and moved back and forth) between the web and gaming industries.  Having that experience has given me a different perspective, especially on how games are made.

The smartest people I have ever worked with in my career have been in the games. Despite that, game development seems in the dark ages compared to web development.

Fail Fast

My last project in gaming, RIFT, took five years to build, and more than $50mm in investment.  It did well – but what if it didn’t?  What if, right before launch, a different product came out that made ours obsolete?  What if we launched and people seriously just did not care?

To stem this risk, the web / mobile app industry gets *something* out as fast as possible and tries to learn if anyone cares about the product.  Because that risk is even sometimes too high, ‘Fake Doors’ were invented – just put up a website for a product that doesn’t even exist, and see if people take an action (like clicking a button) that would show interest.

The only game I can think of that launched early was Minecraft.  And hey, it did ok.


Once you get your product out there, either in 5 years or 5 months, you are flying blind unless you know what your users are doing.  Aside from Zynga, I don’t know of a large gaming company that is hard-core into understanding how the product is used at the finest level on a moment to moment basis.

In Squawk, and just about every other web and mobile app product, we track *everything *.  We are a small team and yet have custom nightly reports as well as have integrated many third party SDKs like Flurry, MixPanel, KISSMetrics, etc..  Even more importantly, this metric data tells us what to do next.

Also, I have never, ever, seen an A/B test written or implemented in the gaming industry.


On RIFT, we made a new build each day.  On a different gaming project that I was consulting on, they got a new build … once a week.  And that was somehow ok.  In the web space, a build is continuously created and deployed as fast as possible, often thousands of times in a month.  There are often more steps and asset crunching in the build process for games, I get that.  But often there isn’t the attitude that it needs to be faster, whereas it is obsessed over in the web space.

Seemingly every system in the gaming industry is written from scratch (Unity is bucking that trend), whereas a web project is more a big tapestry of open source works from other authors.  Why is that?

A correlated observation: others’ code in the web space is free, and in games it’s not.  Is it because a useful, shareable component in the gaming space is necessarily large and complex, and therefore takes so much of one’s time that you’d need to charge for it?


Did you ever notice that web companies don’t have QA people?  For RIFT, we had around 20.  That’s because in the web space people write tests for everything possible. There could be tens of thousands of tests in a mature product, run every time you compiled, checked in, or deployed.  We basically had none.  And these are the smartest people I’ve ever worked with.  And look, it was in my control to push this. Instead, we had a great QA team.

Especially because games are so complex, you’d think we would have tests.

People Management

I have never seen a more stark contrast between the two industries than when it comes to people.  The gaming industry is notorious for ass-in-chair management, and ‘crunching’.  As in:

We had to work 60 hour weeks for three straight months to make our ship date.  We were told we needed to have X all done, which really wasn’t reasonable. And then they added more stuff.  And then after all of that … launch was delayed.  We got a few days off to ‘recharge’, and then started crunching again.

Do employees at Facebook, Yahoo, Google, and Apple do that?  What about at all hot, A or B round funded start-ups?  Something tells me no.  I can’t think of a gaming company that wants to build a great culture – yet Mark Zuckerberg obsesses about it all the time.

Why oh why oh why????


Which Type of Engineer Are You?

Most of my best ideas come to me in the shower.  Why?  Because they haven’t invented a waterproof iPhone yet.  When that happens, I am pretty sure that I will truly be on content dripfeed 24/7, and my brain will shut off completely.

My realization a few days ago in the shower was that there are three types of software engineers…. only three!

Scientist: Scientists are really smart, and they love really interesting, hard problems.  Often the problems aren’t immediately critical to solve though.  Success for a scientist can be measured by how many patents one has.   Scientists aren’t always great implementers, polishers, or finishers.

Architect: Architects love to build systems.  The code will often be a work of art, have a lot of upfront design diagrams – and built to anticipate future needs.  A huge source of pride for an architect is when a new feature is asked for and the response can be ‘hey, our system was written in such a way that we can handle that easily’!  The downside is that this approach takes longer than expected, and occasionally if it takes really long, by the time it’s done, what has been built and what is needed are actually different.

Do-er: Do-ers love to get stuff done.  And they love lists. Nothing is more rewarding than working through the items on a list and checking them off.  It might not be the most interesting work, but it feels like progress is made.  Bigger picture thoughts, such as code cleanliness or architectural considerations, often go by the wayside.  Do-ers can be great, diligent finishers, but aren’t necessarily the best starters.

When I think through the entire engineering team that I worked with at my last company, I can bucket each person into one of these these three types.

Which type makes the most valuable engineer?

If had to design ‘the perfect engineer’ that had the perfect mix of traits for the type of work I’m involved in, I would say 85% do-er, 10% architect, and 5% scientist.  Does that mean that I think solving hard problems and building systems aren’t critical?  Nope, not all.  It’s just that I place a really big value on shipping and ‘getting shit done’.

So what type of engineer are you?  Or what is your perfect mix?  Why?