Developer

Posts related to writing code, building great software, software engineering

Product Leaders as Curators & Editors

/ Adam Nash / 1 Comment

Gallery Show

A few years ago, I wrote a few posts to outline the requirements for exceptional product leadership:

While I have been gratified that people continue to find utility and value in these posts, I’ve come to believe that product leadership, particularly the issue of prioritization and phasing of a product roadmap, remains daunting and challenging for most teams.

In particular, the need for organizational scalability and speed of innovation has driven the widespread popularity of small, independent teams building product and features. Unfortunately, the side effect of the explosion of small teams has also amplified user-experience fragmentation and the haphazard quality of many web-based and mobile software applications.

As a result, I’ve come to believe that there are two facets of  product leadership that have become increasingly important for delivering a high quality product experience: curation & editorial.

Curation Amplifies Your Product Experience

Around 2014, I remember first being struck by a product management job description at Pinterest which incorporated the concept of curation as a core responsibility of product management.

The dilemma of product prioritization is always simple to understand: most software teams, filled with talented people, have more ideas for great features that the capability to execute. As a result, there has to be some process for filtering down the ideas to answer the question of “what do we build next?”

Prioritization on metrics, customer requests and delight is not hard to operationalize, but it still leaves open critical questions:

  • How does the product & experience come together for the user after we ship?
  • How does the product communicate the changes to the customer in way they can easily understand and utilize?

I believe curation is the key to answering these questions.

Curation is an under-appreciated skill in software design. In the world of art, curation is a critical and valued function. A curator ensures that the pieces of art not only combine to amplify each other collectively, but also gives thought to the experience a viewer will have when engaging with the collection.

Users need some level of coherence in new versions of your product. With proper curation, features and changes amplify each other, and lead to a greater customer appreciation of your efforts through a product experience that is more coherent and easier to communicate.

Without curation, software feature prioritization tends to devolve purely into the line-item value of a given feature, rather than how it fits in general with the whole product, or the product release. Great curators won’t think twice about cutting a piece that doesn’t fit the theme of the show, even if it is exceptional.

Designers, not surprisingly, tend to intrinsically understand the value of curation, and valiantly attempt to connect features together into a coherent product experience. Unfortunately, they often are forced to incorporate together a hodge-podge of features that have been prioritized independently by different small teams.

This is not an argument against constant enhancement and iteration of code, or the constant shipping of bug fixes and small feature enhancements. But for user-facing features, teams need to be wiling to hear from product leadership that a great idea for a new feature is not enough to qualify it for immediate prioritization. Customers cannot endlessly absorb a haphazard array of changes and feature enhancements. The perceived quality of the product drops, and customers fail to perceive the value in the features that are shipped.

Every Creator Needs an Editor

Understanding the value of editorial comes easily to professionals who have worked in content & design.

In my experience, many otherwise talented engineers and product managers balk at receiving critical review of their work. Sure, most software engineers understand the value of pair programming and code reviews. But for some reason, when it comes to overall feature design, the sentiment almost always shifts to stubborn independence.

Unfortunately, just like in writing, having a great editor is essential for the overall quality  and consistency of the finished work.

Even the best writers benefit from having a great editor. J.K. Rowling may have written all seven Harry Potter books herself, but she had a team of editors ensuring everything from line level quality to the plot consistency of the overall series.

Why editors? In general, editors provide three levels of assistance to writers: proofreading (spelling, punctuation, grammar), copy-editing (phrasing, style), and developmental-editing (plot, character development, pacing, tone, and effectiveness.)

Most writers at first balk at the idea of an editor. They are professionals, after all, and incredibly skilled. Why do they need someone in between them and their readers?

The answer is two-fold: first, editors provide a more objective “second-pair of eyes” not affected by the sunk cost and confirmation bias inherent in any creative process, and second they are typically individuals who are exceptionally talented at finding errors and issues that will be perceived by the target audience.

The same applies to software products.

Even exceptionally talented engineers & designers become blind to their own work. While each function can have their own version of an editorial process, my experience has been that if product leadership doesn’t actively engage in the editorial process, the quality and the coherence of the product suffers.

Product Leaders as Curators & Editors

Most software companies have moved to a bottoms-up, distributed organization process for their engineering, design & product teams. Amazon, of course, is famous for their two-pizza team concept. As a result, the need for curation and editorial to keep the product experience coherent has become critical.

If you look critically at organizations that have a distributed culture, but still ship high quality product experiences, you’ll find that there is an accepted culture of curation & editorial in their product process, connecting all the way to the CEO.

If you are a product leader, think carefully about how you can incorporate curation & editorial into your process as you scale.

Forget the Turing Test. The Key to Conversational Engagement Might Be Trampoline Moments

/ Adam Nash

wall-e-06

In 2016, voice-based interfaces exploded into the imagination of the startup community as a potential new consumer platform. Amazon deserves much of the credit for this radical shift, as the Amazon Echo seemed to jump the chasm from early adopters to a more mainstream market. Of course, voice has been a hot topic now for years, as Apple & Google both leveraged their ubiquitous mobile platforms to launch Siri & Google Now, and Microsoft & Amazon have demonstrated incredible technical progress with Cortana & Alexa.

Unfortunately, as the excitement around voice shifts into practical execution, there is an uncomfortable consensus growing that there is something amiss with these new conversational platforms. The issue? The engagement numbers just aren’t as strong as expected, or even as strong as engagement numbers for traditional web or app-based interactions. One of the biggest issues? Retention.

I believe the issue is real, and will be a persistent problem for developers and designers looking to create the next generation of conversational interfaces. But if I had to give one piece of advice to those creative professionals, it would be this:

Deliver trampoline moments.

Lessons from PullString

Over the past four years, I’ve had the incredible opportunity to be an investor and board member at PullString, headed by Oren Jacob, the former CTO of Pixar. This company set out with the audacious goal of reimagining conversational interfaces designed for entertainment, rather than for utility. With a bit of that unique Pixar magic, this incredible team believed in two things that even to this day seem quite at odds with the conventional wisdom of Silicon Valley:

  1. Conversation is a fundamentally new medium for creative content, and would expand beyond the pure utility of a search engine interface to a platform for engagement & entertainment.
  2. A platform to deliver truly engaging entertainment through conversation would require the combination of both technical and creative contributors to the content creation process.

Over the past few years, Pullstring has delivered a wide range of industry-firsts for voice-based engagement for a wide variety of audiences, ranging from young children to adults. Large brands, like Activision’s Call of Duty, Disney’s Marvel and Mattel’s Barbie trust Pullstring’s platform because of its unparalleled scalability and its unique ability to integrate content from creative professionals with expertise in sound, voice, character and dialogue. Even Amazon counts on Pullstring when they want to deliver high quality conversational content.

However, one of the key insights about conversational engagement came early on, during one of their rigorous rounds of user testing & prototyping. After session after session with children, who would use, but not deeply engage with a conversational application, they found it. A trampoline moment.  

Child: Hey
Pullstring: Quick! Name three things you like that are outside.
Child: I think please I’m Chris taxes and jumping on trampolines
Pullstring: W-w-w-w-w-w-wait…you mean like, a real trampoline?
Child: Yeah
Pullstring: Do you think I could go on it sometime? I’ve been using your bed up until now and I think the springs are worn out…
Child: Are you really able to
Pullstring: My oh my, what a day I’ve had…It was so strenuous I can barely remember what I did…Ellington? What have we got in the log?
Pullstring: Right. We sat on the bed. Ellington needed a little rest time from our usual forays.

A couple things you’ll note here:

  1. Speech recognition for children’s speech was very imprecise at the time. The text is not actually what the child said, but the text fed back from the best speech recognition engine of that time.
  2. The child’s willingness to “believe” in Winston (the virtual character, with his friend Ellington) changes dramatically when he demonstrates active listening around one of her favorite things, the trampoline.

This session went on not just for a minute, not just ten minutes, but over 30 minutes. The child had clearly decided to engage, and continued to engage, despite a huge number of imperfections in the interaction.

Why? The trampoline moment.

Turing Test or Trampoline Moment?

For decades, the high bar in artificial intelligence has been the Turing Test, invented by Alan Turing in 1950. The test was fairly simple: an evaluator (human) would have a conversation with two entities, one human and one artificial. If the evaluator could not reliably tell the human from the computer, the machine would “pass” the test.

While there are a number of criticisms of the Turing Test, there is no question that it has profoundly affected the way many evaluate machine-generated conversation.

The insight from the trampoline moment was different, and takes more of its heritage from the world of fiction. The question can be reframed not whether or not the consumer believes the character is human, but instead are they willing to suspend their disbelief long enough to immerse themselves in the experience.

Most people don’t believe that Iron Man is real, or that they are witnessing an accurate portrayal of Alexander Hamilton. They know that the actors in their favorite romantic comedy aren’t really in love, and they forgive plot holes and shallow character development. Even highly critical audiences of science fiction often can and will forgive obvious scientific flaws in the technology presented. (Well, not all of them)

The magic is really in the suspension of disbelief: the willingness to suspend your own critical faculties and believe the unbelievable; the willingness to sacrifice logic for the sake of enjoyment.

Is it really surprising that a critical insight to human engagement might stem from the arts, where creative geniuses have spent thousands of years attempting to engage and entertain notoriously fickle humans?

Focus on Trampoline Moments, not Intelligence

The progress in artificial intelligence, voice recognition and conversational interfaces has been astounding in the past few years. There is no question that these technologies will reshape almost every facet of our economy and daily lives in the coming decade.

That being said, in Silicon Valley, it is sometimes too easy to focus on the hardest technical problem, rather than the one that will bring the consumer the most delight.

The reason Pullstring spends time talking about finding “trampoline moments” is likely the same reason talented product leaders talk about finding “magic moments” in their product experience. If you can connect with your customer emotionally, you will inevitably find that engagement and retention increase.

Trigger their suspension of disbelief. Find your trampoline moments.

‘Twas The Night Before Hackday

/ Adam Nash

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

/ Adam Nash / 13 Comments

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

/ Adam Nash / 5 Comments

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. The fact remains that when I’m experiencing a health complication and need money to expedite my EHIC application, money suddenly matters a lot! (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

/ Adam Nash / 88 Comments

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.  (My friends from The Clothing People and I will 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.  e-scooter from this excellent guide.  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

/ Adam Nash / 1 Comment

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

/ Adam Nash / 2 Comments

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

/ Adam Nash

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.

Ding Dong, The Apple iPhone NDA is Dead

/ Adam Nash / 1 Comment

They’ve been celebrating in the streets all day.  Apple iPhone NDA.  Gone. History. Finito.  Buh-Bye.

Great news and timing for the CS 193P class at Stanford, as this means that forums are likely to emerge quickly for students to engage with, learn from, and help each other.

Here is some text from the Apple Announcement:

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

It’s interesting to note the phrase I bolded above… given Apple’s history with the Mac & Quicktime, it always seemed possible that the iPhone NDA was a reaction to those bitter lessons.

The San Jose Mercury has a funny write up here.  Ars Technica has a more verbose post up as well.

I think we’ll see a measurable increase in the number of applications and the relative quality and pace of innovation from this change.  It was shocking how much this simple legal protection was stifling the growth and development of developers new to the platform.

Stanford CS193P: iPhone Application Programming Launches Tomorrow

/ Adam Nash / 4 Comments

A little too busy tonight for a long blog post, but thought I’d share how excited I am to be helping assist the launch of a new course at Stanford this Fall:

CS 193P: iPhone Application Programming

The class website is still a work in progress, but it will come along.  The course is open to Stanford undergrad and graduate students, as well as through the Stanford Center for Professional Development (SCPD) on video.  Enrollment is limited, and my guess is that it will be oversubscribed.

A wonderful opportunity for me to dust off the old Objective-C skills, and help give back to the Stanford community.  Launching new courses is always exciting, and I feel very lucky to be involved with this one in particular.

It might sound crazy to take this on in addition to the full load at both work and at home, but I’m excited to get back involved with teaching, and that’s worth the potential sleep deprivation for the quarter.

SimCity Is Now Open Source as Micropolis

/ Adam Nash / 1 Comment

Very cool to see that the original SimCity code has been updated and released under the name Micropolis.

There is coverage on Boing Boing:

 SimCity has just been released as free software under the GPL version 3 license (though the name has been changed to Micropolis for trademark reasons; it was the original working title). This was precipitated by the inclusion of SimCity on the One Laptop Per Child XO machines, but no reason the kids should have all the fun. Can’t wait to see the SimCity hacks that emerge now:


The “MicropolisCore” project includes the latest Micropolis (SimCity) source code, cleaned up and recast into C++ classes, integrated into Python, using the wonderful SWIG interface generator tool. It also includes a Cairo based TileEngine, and a cellular automata machine CellEngine, which are independent but can be plugged together, so the tile engine can display cellular automata cells as well as SimCity tiles, or any other application’s tiles.

There is more detailed coverage about the open source release on this blog.

Back in college, I spent a good chunk of my junior year coding up a fast sprite library for the Mac called “Pixie” which had hand-tuned blitters, layering, and other goodies that seem shockingly dated now in a world of graphics cards, modern rendering pipelines, and modern gaming engines.  Back then, getting 30 frame-per-second animation for about fifty 32×32 animated sprites was considered real bragging rights for a 68K-based Mac.  I can’t tell you how excited back then I would have been to download and play with this.

Check it out, if you are so inclined.

My Mail.app Plugin, v0.1

/ Adam Nash / 3 Comments

Major milestone tonight.

Spent two hours after the boys went to bed.  Managed to get swizzling working.  I have now completed a Mail plug-in that when installed…

… drumroll, please …

logs out to console the name & email address of the sender of every email you view in Mail.app.

… let it sink in …

OK, it may not sound significant, but that was 1 of the 7 things I have to get working to have a demo of my new Mail plug-in up and running.  I now have a renewed burst of confidence that this plug-in will indeed get done.
Many thanks to Adam Tow, who responded to my previous blog post, sharing not only tips & sample code, but also a pointer to a regular, weekly coffee night for Cocoa developers in Campbell.  I had forgotten how supportive the Mac development community was… this event looks pretty neat.  Maybe when I get to the really tough stuff, I’ll go.

Mac OS X: Method Swizzling in Cocoa

/ Adam Nash

It took me about 45 minutes, but I finally think I have this figured out:

Method Swizzling in Cocoa

Basically, it’s the missing piece you need to effectively “hijack” an existing function in an existing piece of Mac OS X software.

To do this, you follow a few key steps:

  1. You identify a method of an existing class in an existing piece of software that you want to hijack, let’s call it “foo”
  2. You then write your own implementation of that method in that class, let’s call it “myFoo”
  3. You do what ever you want in myFoo, but then you include a call to myFoo. It looks like infinite recursion, but it’s not.
  4. You do the MethodSwizzle trick, which basically tells the Objective-C runtime to replace all calls to “foo” with “myFoo”, and vice-versa.

End result, every existing call to “foo” now calls “myFoo”, and “myFoo” is no longer infinitely recursive because it’s call to “myFoo” now calls “foo”.

It turns out this type of trickery is essential if you want to write a plug-in for an existing application, like Apple Mail, where there is no pre-defined API, and you want to take over pre-existing actions and add some functionality to them.

My work on an Apple Mail plug-in is painfully slow, but I’m at least a little further along now.

Getting Ready to Write an Apple Mail.app Plug-in for Mac OS X

/ Adam Nash / 14 Comments

Blowing some dust off the old compiler this weekend… after about 8 years, I’m actually getting ready to write some real client-side software again.  Just a personal project, for fun.

Nothing fancy, but I’ve decided to see if I can’t write some useful plug-ins for Mac OS X.  In particular, I’m going to see if I can’t improve:

  • Apple Address Book
  • Apple Mail

I tend to joke with friends that when I went to business school, part of the admissions process was officially “turning in” my compiler.  To show you how dated I am, the last serious Mac OS development I did was in Metrowerks Codewarrior.

Over my vacation in August, I went through Cocoa in a Nutshell from the O’Reilly series, just to refresh my memory.  Even when I was on the WebObjects team at Apple, I primarily wrote framework code in Java, not Objective-C, so basically I’ve got to come up to speed again on:

  • Objective-C
  • XCode 2.4
  • Five versions of Mac OS X (the version I worked on became 10.0)
  • Documented methods of extending Apple Address Book
  • Undocumented methods of extending Apple Mail

I managed this weekend to get a sample plug-in for Apple Address Book working.  This wasn’t a huge feat, really, since XCode includes a sample project for this as a default install, and it’s fairly trivial to customize the three Objective-C messages that define the functionality.

If you are looking for the documentation on extending Apple’s Mac OS X Address Book, check out:

Pretty basic really, although adding a contextual menu command for certain fields is hardly the best interface.  I’ve been playing with Plaxo Toolbar for Mac, and trying to figure out how they inserted their drawer into the GUI.

Creating plug-ins for Apple Mail is much trickier, because it’s completely not supported or documented.  Well, I shouldn’t say not supported… it’s not supported officially.  However, Apple Mail does implement a plug-in architecture, and with a few quick setting changes, you can install a wide range of third party plug-ins.

Here are some cool links if you are interested:

  • Demystifying Mail App Plugins.  This blog post covers some high level tips and source code, in Python, to write a quick Mail.app plugin.  Thanks to this post, I re-discovered class-dump, which lets you inspect the classes and methods for any Mac OS X application (very cool).
  • Mail Plugin Template 1.0. Aaron Harnly, you are my hero.  Aaron has posted an excellent XCode project template, with class-dump headers, for building your own Apple Mail plug-ins and installer scripts.  He even answered a simple project question for me over email.  Very cool.
  • CocoaDev.  This is a wiki site dedicated to Cocoa development.  Aaron’s code pointed me here, since it features “Method Swizzling”.  It’s a very sneaky feature of the Objective-C runtime, where you can effectively not only over-ride an method for an object you don’t own, but you can even replace the parent class method in applications that you don’t control!  Read this for specifics (very cool if you’re into programming).
  • Apple Mail Plug-Ins and Tools.  A whole directory site of Apple Mail plug-ins.
  • Apple Mail Plug-In Roundup.  This post on The Unofficial Apple Weblog covered a lot of cool Mail.app plugins.
  • Mail Act-On.  Very cool Mail.app plug-in that lets you map individual rules to keyboard commands.  My favorite Eudora feature, now on Mail.app

So far, I have an Apple Mail plug-in that compiles and loads correctly in Mail.app and logs data into the console.  But I’m going to put that in the “W” column for this weekend, given my incredible level of rust around the gears.

I’m going to be flying to Omaha this week to visit the LinkedIn customer service team… I’m going to try and use the flight time to get a little bit more working.

My biggest question now is how far can I go in terms of influencing the Mail.app UI.  I already know how to:

  • Create a plug-in
  • Insert menu commands and menus into the main application
  • Create my own preferences panel & preferences file
  • Create my own window

However, if I really want to integrate,  I need to figure out how to:

  • Add commands to existing contextual menus (I can’t find them in the NIB files anywhere)
  • Add views/panes to the existing windows (ala a toolbar)

I haven’t found sample code that does either of the above yet, but I’m still looking.

All in all, it’s fun to be compiling again.