Skip to content

Posts from the ‘Developer’ Category

‘Twas The Night Before Hackday

A quick parody of a classic to celebrate the LinkedIn Hackday tomorrow (July 15th).  Apologies in advance for the inside jokes / names.  It may not make complete sense to those of you who are not LinkedIn employees.

Twas the night before Hackday, when all through LinkedIn
Not a person was stirring, not even Stegman.

The fridges were stocked with cans of Redbull

The cups were all stacked, the bins were all full.


The hackers were nestled with text editors,

The build was still stable, with normal errors.

iPhones were docked, and Droids were all sleeping,

And MacBooks were purring with power lights breathing.


All of a sudden the InGraphs start flashing,

The NOC is alerted; what is now crashing?

Henke & Kevin were quickly online,

What could be causing this kind of flatline?


Before the team could dive into root cause,

The problems had ended and everyone paused.

Elliot checked, and the metrics were fine

2011 would be over the line.


Suddenly a voice boomed from across the LinkedGym

There was no doubt: the Wizard of In!

He comes every month, for the same simple reason:

Hackday is coming, and it’s coding season


“Forget all your meetings, tell Outlook to shove it.

Hackday’s for coding, just try it, you’ll love it.

Inspire your colleagues, show what you wrote,

Win their applause, and count Twitter votes!”


The Wizard began to run even faster,

and shouting the names of past Hackday Masters,

“Go Crosa, go Ragade, go Efrat & Heuser. Go Gillick, go Jiong, go Blackburn &
Brikman.
Go John, go Matthew, go Shoup & Grishaver. Go Peter, Go Sam, Go Shannon &
Vikram.”

As he ran by the kitchen, he stopped for a second:

“I need a Coke Freestyle, this thing is just heaven.”

Quick as he came, he ran out the door,

“Happy Hackday to all, you are all h@x0rs”

Why LinkedIn Hackdays Work

Two weeks ago, we celebrated yet another great Hackday judging event at LinkedIn.  For the April 15th Hackday, over 50 employees submitted a combined total of 29 projects for the contest.  We saw incredible product concepts, developer tool innovations, internal corporate applications, and even a few ideas so good they’ll likely ship as products in the coming weeks.  At this point, it feels like every Hackday is better than the one before it.

Most of the engineers who work at LinkedIn have also worked at other great technology companies, and in the past year there has been an incredible swell of feedback from new and old employees alike that LinkedIn Hackdays have become something truly special.  Creating the LinkedIn Hackday has been an iterative, experimental process, so I thought it might be useful to capture some of the details on how LinkedIn Hackdays work, and more importantly, why we run them the way we do.

Origins

It’s funny to think about it now, but the original LinkedIn Hackday had an unlikely catalyst.  On December 14th, 2007 approximately 100+ LinkedIn employees moved into a brand new space on the first floor of 2029 Stierlin Court.  It was the first time that LinkedIn had designed a workspace from the ground-up, and it included a large number of LCD TV’s on the wall.  The goal was to immerse the product and engineering teams in real-time feedback and data from the LinkedIn community, and each of the TV’s was driven by small Mac Mini.

The “Pure Energy” contest kicked off right before Christmas, with a goal of using some of the seasonal downtime to produce cool, internal applications that we could effectively “hang on the wall”.  The prize?  Brand new iPhones for the winning team.  The only rules?  The application had to reflect real usage of LinkedIn, it had to run continuously (so it could be left up 24×7), it had to be designed for display on a 720P monitor (1366×768), and it had to run in either Safari or as a Mac OS X screensaver.

Five projects were submitted, and several became staples of our decoration in 2029 for all of 2008.  (Coincidentally, December 2007 was also the first time we pull the live Twitter search for “LinkedIn” up on the wall for everyone in Product & Engineering to see at all times through the day).  The winner of the “Pure Energy” contest, NewIn, still lives on in an upgraded form, in both the LinkedIn reception lobby as well as on LinkedIn Labs.

Key Ingredients

We’ve learned a lot in the past four years about how to make Hackdays successful at LinkedIn, but at a high level, there are ten key ingredients that make LinkedIn Hackdays work.

  1. For Engineers, By Engineers.  This may be obvious, but Hackdays are highly optimized events around engineering culture.  There may be a lot of opinions about what would be considered “fun” or “useful”, but for Hackdays, in the end, is designed for engineers.  This effects everything from the timing, the prizes, the venue and the communication around it.

  2. Spirit of Exploration.  Hackdays have an opinionated culture, and one of those opinions is that with software it is infinitely better to learn by actually doing, rather than reading / talking.  It’s part of why people go into engineering in the first place.  This is one of the reasons that we celebrate hacks that are purely to learn a new language, environment, algorithm, or architecture.  This is not just a fun thing to do – it’s an incredibly effective way to expose talented engineers to new technology, and more importantly, set a tone that we should always be learning.

  3. Independence.  Hackdays are a day of true self-determination.  At LinkedIn, we believe that small, cross-functional teams build the best software.  Teams do a great job looking at product metrics, customer requests, and innovative ideas from the team, and then prioritizing what to work on.  Hackdays are a day to break free, and work on whatever you personally find interesting.  If you have a great idea, this is the day to help make it a reality.

  4. Company-wide Event. Hackdays may be optimized for engineers, but everyone is invited and included.  Some of the best Hackday projects come from an engineer, web developer and product manager working together.  We’ve had entries from almost every function, and from multiple offices.  Most importantly, hackday projects are shared with the entire company on the intranet, and Hackday Judging is an event that everyone is encouraged to attend.  Winners are announced to the whole company.  It’s incredibly important to cement hackdays as a part of company culture, rather than something that lives within the engineering function.

  5. Executive Attention.  Believe it or not, it wasn’t until 2010 that we stumbled upon an obvious truth.  Executive attention matters.  Actions speak louder than words, and when executives make a point to attend, reference, and discuss hackday projects, it makes a huge difference to the entire organization.  At every LinkedIn Hackday Judging event, you’ll now find at least three of LinkedIn’s senior executives on the panel.

  6. It’s a Contest, but Loosely Enforced.  LinkedIn Hackdays are thrown on Fridays, with the submission date for projects due at 9am on the following Monday.  Teams are limited to five people, and projects have to be presented live for Hackday Judging to be considered for prizes.  Having rules for hackdays is a delicate balance – if you are too weak on enforcement, people lose faith in “the system”, and you’ll get discontent from the people who follow them.  However, too tight on the rules, and you break the independent spirit of the event.

  7. Hackday Judging, or Hackday Idol?  Hackday Judging has morphed over the years into an “American Idol” like event.  The hackdays themselves are relatively independent and quiet.  It’s the judging that is the main event.  Teams are given two minutes to demo their hacks.  The panel of celebrity judges is given a minute to asks questions, and then it’s on to the next project.  We serve lots of food & drink, and try to make it a fun event.  (Typically, I fill the role of Ryan Seacrest.  Yes, I know that my mom would be proud.)  There is a lot of laughing, a lot of cheering, and we try to make a good time for everyone.  Most people who attend leave the event incredibly inspired by what their co-workers come up with.  More importantly, once people attend, they tend to come back again (or better yet, enter their own projects.)  We now have everyone in the company help judge by tweeting out their favorite projects with the project name and a #inday hashtag.

  8. Lots of Prizes. We give prizes to every team that present a project at Hackday, typically a reasonably sized Apple gift card.  Winning teams get larger dollar amounts.  We have 5-6 regular categories, so there are always multiple winners.  Some times, we give additional prizes for stand out projects, but that’s up to the judges.  The reason for gift cards is logistics – giving out iPhones, iPods, Flip cameras, etc sounds like a great idea, but too often you get winners who already have one, or who don’t want one.  (The Apple bias bugs some people, but the truth is we’ve experimented with a wide variety of prizes, and people on average seem to really prefer these.  We did notice that our college interns preferred Amazon gift certificates, however…)

  9. Path to Production.  Some hackday projects are so impressive, there is a natural desire to shout “SHIP IT!”  In reality, however, hackday projects can vary significantly in their technical and product appropriateness for a large scale production environment.  At LinkedIn, we’ve now found multiple ways for people to share their hacks.  Some projects live on hosted on internal machines, and are used by employees.  Some of our best internal tools have come from previous hackdays.  Other projects are built over the LinkedIn Platform, and can be launched to end users on LinkedIn Labs.  Some projects are actually extensions of our production codebase, and actually become live site features.  (Example: The 2010 Year In Review email began as a Hackday Winner, as did the inline YouTube expansion in the LinkedIn feed.)

  10. Learn & Iterate.    We are big believers in continuous improvement, and I don’t think there has been a single hackday where we didn’t add some improvements.  We constantly try out new things, and stick with the ones that work, and shed the ones that don’t.  The pace of innovation has dramatically quickened as hackdays became more frequent, and as the company has grown larger.

Common Issues & Questions

It would be impossible to capture all the common questions about hackdays here, but I thought it was worthwhile to capture a few persistent questions that we’ve debated in our process of creating LinkedIn Hackdays.

  • I have a great hackday idea – how do I find engineers to build it?
    This is a really well meaning question, typically from non-technical employees, who are excited about the idea of hackday, but lack the means to implement it themselves.   The most reliable way that people solve this problem is by talking about their idea broadly, and effectively evangelizing the idea of forming a hackday team around it.  In the past, we’ve tried throwing pre-hackday mixers, usually around a technical topic, to help people find teams, but it’s had at best mixed success.

  • I want people to build features for XYZ – how do we get people to do it?
    This question typically comes from a product manager, executive, or business owner who sees hackdays as a massive amount of valuable potential engineering effort for their area.  In this case, the short answer is that hackdays are about independence – the more you try to get people to do what you want, the more energy (and innovation) you sap from the system.  That being said, we’ve seen quite a bit of success where teams sponsor “special prizes” for a specific category on a given hackday.  Example: an iPad 2 for the project voted best “developer tool”.  This approach seems to provide the best balance of independence and incentive to generate the desired result.

  • How do we get all hackday projects live to site?
    This question assumes that the goal of all hackday projects should be to go live to site.  However, given the education and innovation mandate of hackday, there are actually quite a few projects that are not intended to go live to site, and that’s not a bad thing.  The way that we’ve handled this question is by providing both a variety of mechanisms for projects to “go live”, as well as prize categories for projects that are not based on being a “shippable” feature.

  • How can we spare a day from our priorities for a Hackday?
    In some ways, this is the big leap of faith.  For anyone who has attended any of the recent LinkedIn Hackdays, it’s hard to imagine this being considered seriously at this point.  However, at small companies, there are always more things to do than time to do them.  The decision to have hackdays is largely based on the belief that giving people time to learn by doing and to pursue independent ideas will pay off in multiples, not just in the projects themselves, but in the attitude and energy it brings to the company overall.  In some ways, you can view it as an HR benefit that also has a measurable positive impact on culture, internal technology, and product innovation.

  • How do we get people to participate?
    The ten ingredients above reflect the system that we’ve devised, but the truth is it took time for hackdays to build into a culture fixture at LinkedIn.  In 2008, we threw two hackdays, and had about half a dozen teams enter each.  However, as the company celebrated each hackday winner, we saw demand pick up.  We had a major breakthrough in participation when we launched the “Hackday Idol” format for judging in early 2010, and since then we’ve seen incredible growth in the number of participants and projects.

What’s Next?

I’ve got a few new innovations ready to roll out for the May 20th hackday.  Not to spoil the surprise, but we’ll be rolling out for the first time a new “Hackday Masters” designation and category, for people who have won at least three hackdays.

Hopefully, the Wizard of In will smile down on us, and as always reward those who seek to bend code to their will.

Personal Finance for Engineers

Last Friday, LinkedIn had it’s monthly “InDay”, an event where the company encourages employees to pursue research, ideas & interests outside of their day-to-day responsibilities. (This is the same day that I run the regular LinkedIn Hackdays for the company.) This month, the theme was “personal finance” as a brief nod to the ominous due date for income taxes in the United States.

For fun, I volunteered to give a talk based on material that I’ve put together over the years called “Personal Finance for Engineers”

I cover the most obvious two questions up front:

  1. Why Personal Finance?  Personal finance is a bit of a passion of mine, and has been for almost twenty years.  It’s both amazing and shocking to me that you can attend some of the finest secondary schools and universities in this country, and still not get a basic grounding in personal finance.  More importantly, it happens to be an area with a huge signal-to-noise problem:  there is far more “bad” advice and content out there than good content.  And lastly, I believe that money matters are deeply important to the long term success and happiness of most people. (Let’s face it, money happens to be one of the top three causes of marital problems)
  2. Why Engineers?  The talk isn’t purely for engineers, per se, so this reflects a personal bias (I just empathize more with engineers more than other people).  That being said, engineers tend to make higher incomes earlier in life than most people, and thus face some of these questions earlier.  They also tend to have stock options, a fairly advanced financial instrument, as part of their standard compensation.  Probably most troubling, engineers also consider themselves exceptionally rational, which makes them more prone to human weaknesses when it comes to money.

It was very hard to decide how to condense personal finance into a 60 minute talk (I leave 30 minutes for advanced topics).  I decided to focus on five topics:

  • You Are Not Rational (Behavioral Finance)
  • Liquidity is Undervalued (Emergency Fund)
  • Cash Flow Matters (Spend less than you Earn)
  • The Magic of Compounding (Investment Returns & Debt Disasters)
  • Good Investing is Boring (Asset Allocation)

The deck is not perfect by any stretch, and I have a number of ideas on how to improve it.  There are some great topics / examples I missed, and there are some points that I could emphasize more.  I spend literally half the time on behavioral finance, which may or may not be the right balance.

The talk went extremely well.  We had well over 100 people attend, and stay through the full 90 minutes.  Surprisingly, I got more thank yous and follow up questions from this talk than any other that I’ve given at LinkedIn.  I’m strongly considering giving it again, perhaps at other venues, depending on the level of interest.

Let me know what you think.

Why T-Shirts Matter

During my tenure at LinkedIn, I’ve held a wide variety of roles and responsibilities within the company.  Some are fairly public (as described on my LinkedIn profile).  Others are the the type that you’d never find formally discussed, and yet would be no less true if you asked anyone who worked at the company.

In a rare combination of serendipity, passion, and empowerment, I personally ended up with one of those unspoken roles: the most prodigious producer of LinkedIn t-shirts.

2010 LinkedIn for Breast Cancer Awareness Shirt

At the recent Silicon Valley Comes to the UK trip, I had the chance to have a great conversation with Dave Hornik on why making t-shirts matter to high tech start-ups.   Believe it or not, I felt that this was a subject important enough to capture in a blog post.  (I’ll write a separate blog post on how to make truly great high tech t-shirts, which is a field of expertise unto itself.)

Why T-Shirts Matter

At a high level, understanding the typical culture at a high tech startup can be difficult for those who haven’t worked for one.  The best analogy I can think of is to put yourself back in time, to when you were between 8 – 12 years old.  Now, think carefully about the things that 8 – 12 year old boys like (at least, the geeky ones).  Video games.  Caffeine.  Scooters.  Toys.  Computers. Bean bag chairs.  Junk food.  This should help orient you, and brings you to the right frame of mind about t-shirts.

T-shirts are a part of that culture.  In part, t-shirts represent the ultimate middle finger to those unnamed sources of authority who wanted software engineers to dress like “Thomas Anderson” in the Matrix.  Software engineers want to be Neo, not John Anderson.

This leads us to the reasons why t-shirts matter:

Empowerment.  In some ways, engineers delight in having found a profession where their intellect and passion for technology have enabled them to earn a great living and work at a company where – yes, you guessed it – they can wear t-shirts to work.  Giving out t-shirts tells your employees, implicitly, that you get it.  You hire only the best, and the best can wear whatever they want.  It says you know that you value merit over appearance; a working prototype over an MBA.

Incentives.  Over the past decade, behavioral finance has taught us that people don’t value money rationally – it varies depending on form and context.  You can bring a $20 bottle of wine to your girlfriend’s parents’ house and be thought a gentleman.  Handing her Mom a $20 at the door isn’t looked on the same way.   Let me just tell you, free t-shirts evoke some sort of primal response at a high tech company.  I’ve often said that I would see less interest at a high tech company handing out $100 bills than handing out free t-shirts.  High tech companies are filled with benefits that cost hundreds of thousands of dollars per year, benefit a minority of employees, and are generally under-appreciated financially.  You’d be shocked at what a $200 per person per year budget for t-shirts will do for employee morale comparatively.

Tribal Cohesion. There are a lot of reasons why many institutions require employees to wear uniforms.  Common appearance can be a reminder that the person represents the company.  More importantly, common dress signals who is “part of the tribe” and belongs to the corporate family.  Uniforms are incompatible with the “empowerment” aspect of how people want to dress, but t-shirts can represent a form of “voluntary uniform” if produced in sufficient variety and quantity.   This effect can be had at a team level, when a t-shirt is made just to celebrate a new product, or at the company level.  It has a profound effect on new hires, as well, who desperately want “a shirt” so they can fit in.  It may sound subversive, but t-shirts can provide many of the same benefits of camaraderie and tribal cohesion that uniforms did, without the top-down oppression.

Tenure Based Seniority. High tech companies are largely meritocratic, and as they grow they tend to define roles based on skills & experience rather than “time at the company”.  However, there are positive aspects to rewarding those who have “bled for the company” over the years, and put their hearts and souls into building the business.  T-Shirts, in an innocuous way, implicitly do this by almost always becoming “limited editions”.  Want the t-shirt from the 2007 company picnic?  You had to be there to get one.  How about the shirt from the first intern program?   The launch of a game-changing new product?  Even shirts that are given out to the whole company will become rare at a company that’s growing rapidly.  In a socially acceptable way, t-shirts subtlely communicate a form of tenure that is warm, and yet structured.

Branding.  As discussed under “Tribal Cohesion”, people want to wear the brand of their tribe.  They will wear them out everywhere if you let them.  Let them.  While being careful not to interfere with the uniqueness of shirts given to employees, make shirts for your developers, your fans, your early adopters.  Long before they become vocal advocates for your brand, they will gladly showcase it if you let them.  This tends to work best in relatively inter-connected, dense, techy cultures like Silicon Valley, but you’d be surprised how far your reach might be.  Of course, this assumes that you make shirts that don’t suck, but we’ll cover that in the next blog post.

So How Do I Make Great Shirts?

It turns out that this is a lot harder than it appears.  Mario always tells me my blog posts are too long, so I’m going to save this topic for the next post…

iPhone 3.0 Event Next Week: March 17th

top

Got the graphic from CNET.  They have some details about the event:

Apple distributed invitations Thursday for a March 17 special event in Cupertino, Calif., to discuss the iPhone 3.0 software and a new software development kit.

Next Tuesday’s event will come a little more than a year after Apple unveiled the original SDK at the iPhone 2.0 software event, setting the stage for over 25,000 iPhone applications to make their way onto the App Store. Speculation about a new iPhone had mostly centered on new hardware features, rather than software upgrades, but it seems Apple has something up its sleeve.

Hoping to see OS-level support for some missing basics:

  • Clipboard (cut & paste)
  • Background processing (some form of mult-tasking where apps can receive updates even when they aren’t front-most)

I’m wondering if we’ll see any significant hardware enhancements or new models announced.  The iPhone currently drives developers to really focus on a single screen size… would be nice to see more robust handling for multiple sizes/shapes to give more flexibility to hardware in the future.  It’s not that you can’t make resolution-independent applications today – you can.   It’s just not encouraged or optimal.

MegaPhone?

Source Code That Allegedly Broke the Microsoft Zune

Thanks to Lawrence, Ryan, JSTN.

while (days > 365) {
    if (IsLeapYear(year)) {
        if (days > 366) {
            days -= 366;
            year += 1;
        }
    } else {
        days -= 365;
        year += 1;
    }
}

For non-programmers out there, this is what we like to call in technical terms “an infinite loop”. This code block will never finish running because on Day 366, the loop keeps checking to see if the day is greater than 365 (it is), and then checks to see if it’s a Leap Year (it is), and then checks to see if it is greater than 366 (it isn’t). So it does nothing, and then starts all over.

Perfect way to lock up your Zune every four years on the last day of the leap year.

Not sure if this is the actual code snippet or not, but a fun exercise. I could actually see this being on an introduction to programming test at some point.

My favorite quote about this fiasco (from the San Jose Mercury News):

“I’ve never heard of a consumer electronic device fail en masse like this,” said Matt Rosoff, an analyst with Directions on Microsoft, a Seattle-based research firm that focuses on the software giant.

Does anyone doubt that “Microsoft Zune” has become the “Ford Pinto” of consumer electronics?

New Dutch Architecture Five (5) Euro Coin, Programmed in Python

Yes, I said Python.

First, special hat tip to Mario Sundar for finding this lead.  Mario is not a coin collector, but he reads my blog often enough to know that I have a special interest in coins.  This one is a beauty, since it combines creative visualization with a unique engineering tale.

Here is the coin design:

dutch_coin_design

Here is a brief description, from the Dutch Mint website, on the coin design:

A new 5 euro commemorative coin pays tribute to the history of Dutch architecture. Both our historical architecture as well as our innovative conceptual architecture and modern design are popular across the globe.

The Architecture five-euro coin was designed by artist Stani Michiels (b. 1973). The design on the obverse of the coin pays tribute to the history of Dutch architecture, with the portrait of Queen Beatrix being distinctively constructed using the names of important architects from Dutch history. The artist used the internet as a popularity-meter to determine the names’ order of appearance.

The reverse of the Architecture five-euro coin draws attention to the striking fact that many Dutch architects have also included publishing books on architecture in their professional activities. To illustrate this phenomenon, recent books on architecture rise up from the sides of the coin like buildings. Through their careful placement they combine to outline the Netherlands, while birds’ silhouettes suggest the capitals of all the provinces.

This blog post, however, from the designer, is where the real beauty lies.  It’s too long to reproduce here, but it goes into significant depth about the design inspiration, concepts, and visualization at work.  If you have a background in design, you will appreciate it.

Here is the summary from the post, and I think you’ll see why this contest winner gets substantial geek cred, as he goes into detail about the technology used in the coin design:

The whole design was done for 100% with free software. The biggest part consists of custom software in Python, of course within the SPE editor. For the visual power I used PIL and pyCairo. From time to time also Gimp, Inkscape and Phatch helped quite a bit. All the developing and processing was done on GNU/Linux machines which were running Ubuntu/Debian. In the end I had to collaborate closely on location together with the technicians of the Royal Dutch Mint (coin factory). So all the last bits were done on my Asus Eee PC. (I am still wondering why Asus doesn’t offer Ubuntu on its netbooks.) The Eee laptop took a bit longer (30 seconds instead of 3 seconds to generate a whole coin), but did the job just fine. For looking up the number of hits on the internet, I rediscovered Yahoo, which provides a much better api for automatic querying than its competitors. Of course the jury judged only the design and not the software used as others used Maya, Illustrator, …

And the winner is…
I am proud to announce that I won the competition! So soon 350.000 Dutch people will use the fruits of free software. I would have loved to release the coin under the GPL, which could maybe solve the financial crisis. However for obvious reasons I was not allowed to do that. There will be also special editions for collectors which can be bought world wide: a massive silver edition for € 30,95 and a massive gold edition for € 194,95. They will be probably sold out quickly as these are real collectors items. The coin is released in all Dutch post offices to the public the same day as the Intrepid Ibex: 30th October 2008.

You can purchase the coin here at the Royal Dutch Mint.  They seem to still have the gold version available, but no sign of the silver version.  Maybe it sold out?  If you find it, please comment here with a link.

Follow

Get every new post delivered to your Inbox.

Join 12,891 other followers