Respect the Journey

Frodo shows up in Mordor and flips the ring into the molten core of Mount Doom. He has no scars. His clothes are clean. There has been no suffering. Sam has plenty of elvish bread for the return home and it’s back to the Shire in a day or so. This is a completely different story than the one we know. It has the same outcome, but it’s entirely devoid the hard lessons of the journey that preceded it.

When we are new to a situation, it’s not always clear what journey the characters involved have been on. We can try to rally them to our cause, but if they have just gone through hell and back, the response to our pleas will certainly be different than if the team has been doing well.

There is nothing more annoying than to experience a great amount of toil and trouble, only to suffer fools at the end of the journey wondering “what took you so long” or “why the frown?” So, be empathetic to those who’ve just achieved something. It may be that it took every ounce of their strength and willpower.

It may be their Mordor.



I’m trying to trust more, but it’s hard. I see the failures around me as evidence that I continue to need to work to help others achieve success.

But the reality is, I fail as much as anyone. More often than I’d like to admit, the failings I observe are as much the result of my actions as those around me! What I need to do instead is to build trust. Or rather, I need to grant trust to those I love at home and to those I work among.

I can remember, when I was just 16 years old working at a local hardware store, the sporting goods clerk was trusted with the gun case. He was the elder clerk and was so heavily trusted to do his job and to care for the revolvers, pistols, and rifles, that he has been in that role for nearly a decade before I started working there.

Do you know what he did one night before going home for the night? He let me clean and clear the gun cases and put them in the safe for the night. Me, a 16 year old who had never shot a pistol. This was not supposed to happen for just anyone. You needed training. You needed to be older. To have experience. You needed…trust. Did I do anything to earn this trust? Not likely. But there I was doing my best to put these machines away without a single nick or knock and being more careful than the most ardent gun owner.

Trust can liberate. Affording trust can, ironically, be the trigger causing the trusted to actually be deserving of it.

I will strive to trust more and in so doing, to respect the intelligence and abilities of those around me.


All Stars

My son recently participated in an All Star tournament for his Little League. Watching him through the tournament, the confidence he built throughout the regular season was clearly abandoned for feelings of alienation and a general lack of passion.

When we feel the pressure of highly capable people around us, it can affect our mindset. We strive to be great in our given discipline yet when we achieve greatness and are subsequently thrust to the stage, we sometimes wither into our former selves.

Every game has an important, elevated “next level” stage like an All Star game in Little League or an executive leadership meeting for a new Director. It’s in these situations that you’ll inevitably notice that some of the players are not shaken by the heightened pressure but instead thrive on it. When others crumble as the game intensifies, these individuals exude a calmness under pressure which, when it becomes contagious enough, can spur on the team’s ability to succeed in spite of their nerves.

What, I wonder, causes some of us to break under pressure versus see the pressure as just another game to be played? Perhaps the only way to build this mindset is to have played those high pressure games enough to not be fazed by them.

Perhaps it’s on the leaders of great teams, then, to practice high pressure situations on the fields of greatness (real or simulated), in order to build comfort and coolness under pressure. If we can do that, maybe our entire team can be All Stars.


Five Ways UX Designers Can Build More Acceptance of Their Work

Have you ever attended a design review meeting — perhaps to review the results of a design sprint (see Jake Knapp) — where the team seemed to love the work, appreciated the research that went into the design decisions, and yet ultimately decided not to move forward with the proposed design? How frustrating. Don’t they know what this means to you!!!

I believe there a few key reasons why this happens and can offer a few tips and tricks that can help avoid this scenario.

1. Emphasize How the Deliverable Solves a Problem

Many creatives spend so much time focused on the results of their efforts that they forget to reiterate what the design actually does to solve a problem, capture an opportunity, or otherwise improve a product. When presenting your creative work, remember that your audience must first agree that the design was necessary in the first place so you have to make additional effort to remind them.

Put yourself in the shoes of the stakeholders who care deeply about the problem being solved (e.g. product managers, founders, customer advocates, etc.). If your presentation doesn’t resonate with a very real issue they can relate back to the customer, you will struggle to keep their attention much less get their approval or constructive feedback.

2. Demonstrate How the Design (and it’s Hypothesis) Has Been Validated by Actual Users

Research shows that people make decisions based on something called “ambiguity avoidance,” wherein the decision maker prefers an option having known and quantifiable risks over options with unknown or incalculable odds (see Ellsberg Paradox).

If a problem or improvement is hurtled through an idea-to-solution assembly line without being validated along the way — either by potential or actual users — then you have created a potential for stakeholders to choose a more quantifiable risk. In other words, they will prefer a solution to the problem having fewer unknown risks and which will very likely (and unfortunately) be a meager iteration of an existing solution.

If your design truly has the stuff your users’ dreams are made of, make it clear to everyone how you snatched those dreams from their minds and delivered it in your work. Show those A/B test results, the user research, the heatmaps of prototypes, and so on. It’s really, really critical to build trust and clarify that there are risks in this design, but that they are known.

3. Align the Design to the Long Term Strategy

There has perhaps never been a more strategically focused design effort than what is happening in 2018 with Tesla Motors. I would wager that the internal reaction at Tesla to the notion of an electric semi truck was less than exuberant. But consider this excerpt from the now famous Master Plan blog post:

The strategy of Tesla is to enter at the high end of the market, where customers are prepared to pay a premium, and then drive down market as fast as possible to higher unit volume and lower prices with each successive model.

When applying the strategy above, it’s clear that the Tesla Semi announcement was strategically brilliant. It is an expensive, premium product design in a niche area of their existing area of expertise: electric vehicles.

When you pitch your next design, consider how it aligns to the most broad and ambitious goals of your organization. You may find that it inspires commitment at the very highest levels of the organization.

4. Make it Easy to Enthusiastically Sell

Some design work is easy to love, but hard to sell with passion. The design may pluck all the right chords for the existing market, the test users, and even the overall strategy but if it’s absolute nightmare to talk about, build relationships from, and illustrate the vision, then you have failed.

So, how do you make your designs easier to sell? You need to anticipate what your sales prospects will ask the salesperson immediately after demoing your software. Imagine questions like:

  • This looks good, but what if we want to change the colors to more closely match the other apps we use?
  • How do I connect it to [application X] where most of my data is?
  • We have users who are remote a lot, can you show me the design on a phone…can I pull it up on my phone right now?
  • What if we only want [Feature A] and [Feature B], will you give me a price for not having [Feature C]?

If your design is not flexible, it will not give your sales team the enthusiasm they need to present it well. And remember…

“For every sale you miss because you’re too enthusiastic, you will miss a hundred because you’re not enthusiastic enough.”
 — Zig Ziglar

So remember: an enthusiastic salesperson is the ambitious designer’s best friend.

5. Consider How it Can Be Efficiently Built

Last but certainly not least, you must consider the complexity to build the design you are communicating. If your work is beautiful, but proposes an entirely new UX pattern set or uses untraditional metaphors, the engineers will struggle to scope, plan, and execute your work in a timely manner.

Since your design needs to be iterated on in the market (you know that, right?), it’s in your best interest to produce an artifact that can be built quickly without a lot of prodigious back and forth between product, design, and engineering.

A popular and emerging technique to achieve this is to design using existing HTML and CSS, in code, so that you can be certain that engineers can quickly pull from their grab bag of already built components. Do this and you will get amazing collaboration from the engineering team.

I hope you find this helpful in preparing you for that big demo, presentation, or design review. You have chance to make a great impression and get buy-in so don’t waste it!


Entrepreneurship = Taking Risks

entrepreneur |ˌäntrəprəˈnər| noun
a person who organizes and operates a business or businesses, taking on greater than normal financial risks in order to do so.

I am not an entrepreneur, but I know one when I see one — the risks they take define who they are.

Entrepreneurs have no other choice but to take their vision to the world. They invest everything they have into their ideas and the businesses they build to turn them into value. They bore their friends at dinner parties and exhaust their energy (and that of their families) to provide great service to their customers. They use their garages for product development because they can’t afford an office or lab.

Most of all, entrepreneurs take abnormal risks at the hope of outsize personal or social gains.

Before their ideas take hold, they are betting the proverbial farm on it’s success. If the idea fails, it’s back to square one, often without a plan B.

So, entrepreneurs must connect to people who can help them, burn the midnight oil researching their target market, and obsessively test the core hypotheses of their ideas. If it they didn’t do it, no one will.

I had a lunch recently with a local entrepreneur who personifies this definition. If his idea takes hold, it will potentially impact every small and medium business who cares about employee engagement. He has initial customers and is getting great feedback, but I can tell the business is a huge financial risk for him. It’s all consuming and all or nothing.

Conversely, I’ve also mentored individuals with tons of ideas but who are taking no risks to realize them. With these founders, in place of desperation and risk, there is a safety blanket of a 9–5 job. In place of a firm commitment to a vision there is an unproven belief that their idea is unique and original.

And a total lack of risk.

I want these founders to GET REAL. I want them to feel the urge to burn the candle at both ends in pursuit of their vision…and if the current vision isn’t good enough then I want them to pursue a vision that is. I want them to stick out their necks, borrow money from a wealthy Aunt, or somehow just put more skin in the game.

I get it. I was recently not willing to risk my own job security, cushy day job, and free time to build an AI-based stock recommendation platform with some casual business buddies. Without the same risk taking as my fellow founders, I didn’t have equal skin in the game and was not the team member I could be. My involvement started to look less and less like an entrepreneur — as defined above — and more like an advisor/employee.

So, if you are truly all-in on your business, then I suggest you take whatever risks you need to match what you expect to get out of the business. This tells everyone — most importantly yourself — that you are not messing around.

That you would risk it all.


What’s the Problem, Again?

4 Simple Rules for Avoiding Death Spiral Projects

At times in my career, I’ve found myself working on projects that I would describe as “going through the motions.” While these efforts often began with the best of intentions — “make the customer happy”, “rewrite our client/server software for the Web”, and so on — over time they became death spirals for one primary reason: I lost sight of the problem I was solving.

Wait, what was I working on?

By following a few simple rules about What, How, Why and When to solve a given problem, you can avoid the same fate.

What: Make Sure There’s a Problem

There is one fail-proof antidote to the poison of death-spiral projects. Do not let a day go by without asking yourself…

“What is the problem I’m working on?”

It seems obvious, but in my experience it’s rare for an entrepreneur or creative person to stop what she is doing and do a self check-in on what exactly is the problem being solved.

After coming up with an answer to this question, decide if the overall problem is big enough to justify continuing to put effort into solving it. Sometimes a problem can be solved with a quick and dirty approach rather than the big project you have planned on the horizon.

How: Make the Overall Problem Smaller

Now that you’ve got an important and large problem to solve, ironically, you need make it smaller by breaking it into chunks. Creative people often avoid taking the time to break down a problem into it’s sub-parts, favoring just getting started #mvp #hustle #killyourself.

But if you break a problem down, your mind can consider a more focused and doable solution from day to day, without having to consider massive boil-the-ocean solutions that are beyond your reach. I like to do this by just using indented bullet points in a text editor. Example:

Once you have a break down, choose the smallest and most achievable part of the problem to attack today. I love the feeling of solving a tiny little piece of what I know to be a larger problem every day. This is hard if you allow yourself to just jump into the big problem solving without following this rule.

Why: Make the Problem Matter to You

To me, solving problems with software or design is a personal matter. I get very immersed in a problem and always look to solve it very deeply. However, if the subject of the problem or the potential benefit don’t ultimately matter to me, I will allow the core issues to linger and my solution will be half-hearted.

Like Sisyphus rolling his stone up a hill, solutions provided by people who don’t care about the problems they solve are bound to roll back down the proverbial hill of needing to be solved again.

This guy is on the The Struggle Bus

The only consistent way I’ve found to avoid this scenario is to surround yourself in problem “sets” that speak to your skills and passions. For me, these are problems relating to building solid, scalable digital products efficiently. So, I surround myself with challenging businesses, customers, and engineers in the software space. I imagine that, while I might be good at solving problems as a nurse or a pilot or a teacher or a food critic, it is not what I am ultimately motivated to do and I would not excel.

When: Is the Problem Actually Solved? If So, STOP and Find Another One

Another strange observation I have made is that teams and creative individuals never seem to be satisfied with their solution. The recent emphasis on iterating on a solution over and over again has caused many to get stuck in a rut of perfecting a single problem, which they believe needs to be solved more accurately, efficiently, and with greater value generation.

Sure, iteration can be good, but in many cases there is too little time and too much competition to justify whiling away on a single problem. Just identify it, make a solution work, and move on!

With some simple rules in your mind as you go through the day, you’ll find your problem solving abilities will expand as you make more effective and efficient choices in what, how, why and when to solve the problems you are best suited for. Best of luck!

Management Uncategorized

Advice for the New Engineering Manager

When I first started leading software development teams, I was extremely naive about what it meant to be a manager. My father was a small businessman and lead his company and its employees with an unmistakable authority and command-and-control style. I was naturally influenced by this approach early in my career and applied it to some of my first teams. What a disaster! I’ve since learned this and many other lessons about what it means to lead engineers, developers, and product managers in their day-to-day work.

So, here are some opinions on engineering management I think could help the newly promoted.

Let Go, But Stay Current (or, Know Your Strengths)

There is a lot of content on the subject of whether engineering leads or managers should continue coding, architecting, and being an individual contributor. It’s very tempting for the new manager to believe she can continue to code. After all the source code is right there, still just one git commit -m 'Fixed typo' away from being improved upon. While I think the answer can vary based on the company, the team, and the product, I would argue it’s better to get out of the code for the most part.

I was never a particularly strong developer; often leaving tasks to the last minute, under-scoping work, struggling in the pre-Stack Overflow days to understand harder concepts, and so on. But I did learn that the most effective engineers are commonly on the most effective teams and so I instead began gravitating toward making sure teams around me were healthy. This often meant negotiating time to reduce technical debt (often of my own creation¯\_(ツ)_/¯), upgrading development systems and IDEs, and automating tasks like builds and releases. This became a strength overcoming any weaknesses in my coding ability and I began to take satisfaction in a team’s increased ability to perform without my direct contribution to the code.

So, while I believe the first thing to get right in your new role is to focus on the team’s health, I also believe it’s important to stay current on technology and programming methodologies being deployed by your team. As a manager, you will be asked to break ties all the time (or just shepherd conversations in one direction or another) and it’s best to know a thing or two about the current issues being considered. Don’t be the manager who defers tough decisions by bringing up the good ole’ days when you wrote that CORBA interface that made the company so much money in 2003. It’s irrelevant today and, anyway, your code probably had to be thrown out at some point.

Manage Your Team’s Mindset

Today’s workplace can be a stressful place. We seek to stay productive throughout the day, ever seeking the elusive “flow state.” Meanwhile, a successful software team is often an endless fountain of distraction. The more users adore your software, it seems, the faster and louder are their complaints about a bug you just shipped or how a feature misses the mark. What a catch 22! How can we achieve high levels of productivity when doing so causes more chances to be distracted?!?!?

My strategy: maximize mindfulness. The software team that can consistently drown out distractions, face urgent “fires” without slipping into endless firefighting, and find peace standing in the front of the mountain of work called “the backlog” is the team that has the correct mindset. Fostering a team’s healthy mindset is now a primary job for you as the engineering manager. They cannot do it on their own.

To encourage a healthy mindset on an engineering team:

  • Assure the team that there is always time to do things correctly, even if it has be a little later than today for the sake of shipping the current solution.
  • Foster a sense of reasonable compromise and give-and-take, even in the face of seemingly intractable trade-offs resulting from the first point.
  • Let engineers pick their own tools or build new ones if necessary.
  • Listen to their needs and observe #allthefeels. Effective engineers will solve problems right up to and including the point of exhaustion, frustration, and even rage. Don’t let it happen.
  • Coach engineers to strive for high quality on every line of code, but ensure they are comfortable shipping things before perfectionism kicks in.

A healthy mindset in an engineer is a precious gift, freeing up the manager to focus on the company’s goals, customer needs, and recruiting new engineers to the team.

Master The Ability to Connect The Work to the Mission, Vision, and Roadmap

This lesson applies to pretty much every role in a technology company, but the impact to an engineering team is compounded many times over. Specifically, the engineering manager must master connecting the company mission, vision, product strategy, and feature roadmap to his or her team’s day-to-day engineering efforts. When a team doesn’t understand why they’re working on something, it breeds conflict, distraction, busywork, and analysis paralysis.

“We all know that these functions must work together toward a common set of goals that involve a satisfied customer and a money-making product. The roadmap is a critical opportunity — frequently missed — to articulate those goals and rally everyone around them. Before you can establish specific goals, you need a vision, a product vision in particular that guides the direction, not only for the goal setting but also for all activity on the product.”

from Product Roadmapping by Evan Ryan; Michael Connors; Bruce McCarthy; C. Todd Lombardo

Like the crew of a ship in the middle of the ocean, a team constantly looks to the captain to tell them where they’re sailing and why. Like a remote island with the promise of treasure chests full of gold, a finished and successful software project should be something each team member desperately wants to attain. So, the engineering manager has to clarify what is so great about the software to be built, the brilliance of the roadmap, what a feature’s purpose is in the world, and how amazing it will be to finish the project.

There is a lot of overlap here with the Product Manager role, so common in startup technology companies. But I believe the engineering manager has a responsibility to make sure these connections are made whether the PM is succeeding in doing so or not.

Meetings Suck. You Will Now Create Them. So, You Suck. But It’s OK.

Dear New Engineering Manager,

Sorry, but your calendar is now officially f*cked.

The Gods of Management

Remember the days when you had long, uninterrupted blocks of time to just think about a software problem, design a solution, implement it, write tests first and iterate on the final solution? Yeah, those days are gone. But don’t make the mistake of thinking that your whole team has to suffer your newfound lack of whitespace on your calendar. Their time to dedicate to such things should be high, even as yours dwindles to zero.

For more useful and meaningful insights on this topic, just see Chapter 5 of Managing Humans by Michael Lopp. In fact, just read the whole book.

There are many different lessons that can be learned in the span of a management career, but perhaps the biggest thing to remember is that your new goal is really to build better engineers. By removing impediments like meetings, paying for expensive conferences, and coaching individuals through tough architectural challenges, you are not just helping them build a better software product, but also a better self.

“Management is the opportunity to help people become better people. Practiced that way, it’s a magnificent profession.”
– Clayton Christensen

So, welcome to management and soak in the inevitable fatigue, the constant stress, and, if you’re lucky, the chance to build a team that will do the greatest work of their lives.


Go Forth and Deploy

For many of us in software of a certain age, making changes to and releasing software has traditionally been a perilous activity. Customers had to be hand-held, release sequences carefully orchestrated, and contingencies planned in case of failure. And so, the best releases were done by the best release engineers (remember that title?)–typically release engineers who were most averse to risk. Thankfully, we now know there’s a better way.

Software today is now ideally deployed into cloud-based infrastructures, with little or no customer involvement, with no risk of downtime, and–most critically–completely automated. The risk of breakage is minimized as the duration of Agile iterations dwindles to zero, ensuring that when breakages occur, they can be mitigated in minutes. What was once a massively delicate and stress-filled activity, can be automated into oblivion and reduced to an afterthought. This is the realm of continuous deployment and delivery and it is outstanding.

As teams I’ve worked with over the years have taught me, there are some key considerations in ensuring that continuous delivery is achievable, while maintaining everyone’s sanity.

Careful Code Review

Changes made to the code have always needed peer review. But in an environment where, once a changed has the approval of peers and quality assurance, it is immediately shipped off to the customer, the importance of thorough code review increases dramatically. This is not to say that perfection is the goal (an all too common aim of naive, less experienced programmers), but rather that every change is evaluated for it’s quality and thoroughness relative to it’s potential for negative impact on the application.

Release in the Middle of the Day

If you are waiting until off-hours to release your code, it’s probably a sign that your deployment process is fragile and not correctly mitigating the risk of downtime. Fear that you will break the application at peak usage breeds an overall fear of any change, much less a complex and innovative one. This, of course, has exceptions and is subject to the idiosyncrasies of your industry, product, and customer needs. But as a general rule, the best time to release software is when everyone is ready to monitor and turn around any fixes.

Of course, there are ways to avoid the impact of breakages during peak usage altogether, such as rolling updates, Green/Blue deployments, canary releases, and even very new approaches like Houston.

This is not an uncontroversial subject so flexibility on execution here is necessary. Go with what the team is comfortable with, but also make decisions that build confidence in automated releases at any time of the day.

How Fast Can You Fix Your Mistakes

When continuously releasing software to production, there is an increased need to be alerted, automatically, when an issue has occurred. The human rigor typically applied to big-bang releases–such as manual canary testing, full regression test, and so on–may not be possible given the frequency of releases. As such, when a breakage does occur, it’s critical to have a systematic approach for detecting and redeploying changes (or rolling back, as last resort).

A common model for managing security incidents applies to continuous delivery, as well. This graphic illustrates a few key KPIs that should be kept in mind.


While this graphic is intended to describe responding to security incidents, I like to imagine the same metrics apply when the incident in question is a planned release of your software that goes wrong. By managing the time to detect a problem independently from the time to recovery, a team ensures the most effective reaction times in the case of a failed release.

Stop Penalizing Failure

It is not a matter of if, but when, a software release will go wrong. How the team reacts to this failure is a good indication of whether or not they are ready for continuous deployment. In my professional past, I have been very negative and punitive in my feedback when projects are not successfully deployed. Healthier cultures and mentorship have shown me that a team that can calmly and quickly correct problems on their own is much more desirable.

“If you want something new, you have to stop doing something old”
― Peter F. Drucker

Infrastructure as Code == 🔥

When your entire application can be reasoned about, there is a sense that the risk of any given code change can be more easily reasoned about as well. For instance, if the configuration of an application clearly denotes that a production Web server cluster is set to deploy as a “rolling update” with a minimum of six instances, then the deployment team knows what to expect as the rollout proceeds.

Continuously integrating, testing, and releasing your application to customers is exhilarating and liberating, as long as you manage the risks of something going wrong. If you can identify and eliminate or minimize these risks, the benefits to your developers and ops people are massive.

So go forth and deploy things! Or, more accurately, build robots to deploy things.


Breaking Down Git Activity of the Swift Programming Language

A Review of Activity on the Swift Github Repo

The following is a review of the Swift Programming Language recently open sourced by Apple using the gitstats utility and the freely available Github Activity charts.

The Vitals

Generated: 2015–12–14 21:34:08 (in 225 seconds)
Report Period: 2010–07–17 16:50:59 to 2015–12–14 21:12:49
Age: 1,978 days, 1,438 active days (72.70%)
Total Files: 9,744
Total Lines of Code: 1,045,060 (2,768,677 added, 1,723,617 removed)
Total Commits: 29,925 (average 20.8 commits per active day, 15.1 per all days)
Authors: 259 (average 115.5 commits per author)

Weekly Activity

Commits by Week for Past 32 Weeks, GitStats

Commits by Week for Past 52 Weeks, Github

Clearly, this is a very active project for Apple and it’s 259 contributors. With the exception of the typical lulls during July 4th, Thanksgiving, and Christmas holidays, the activity is pretty consistent week-to-week. In the past three weeks, the spike in commits is amazing to see. Apple must be thrilled with this activity, though a non-trivial amount of activity appears to be external contributors catching typos. Here’s a word cloud from titles of the past 7 days of merged commits:

Hour of the Day

Commits by Hour of the Day, Gitstats

Activity by Hour, Github

The daily pattern here is pretty typical of modern, distributed development teams, if maybe a little later in the afternoon than a typical company-supported project. It might be interesting to plot commits by hour to this to see if key hours of the day shifted over time.

Commits by Day of the Week

Whoa! Are there that many commits happening on the weekend? Of course this is influenced by late Friday night work trickling into Saturday morning, but I was surprised to see the Sunday activity being roughly 30% of the peak day (Thursday).

Month of the Year

As mentioned above, US holidays had an obvious productivity impact on the contributions to the Swift repository, with June and November being popular months to take vacations. That’s my theory, anyway. One wonders if the productivity of a given software project of this scale could be improved by hiring programmers in countries with inverse holiday patterns to US. 😉

Commits by Year

Commits over Time for Entire Report Period, Gitstats

Commits over Time since July 2010, Github

This is clearly a healthy and active project within Apple. What’s interesting to consider is how the language activity since mid-2014 flattened to ~175–200 commits per week. This might be an indicator that “there’s only so much to be done” or that there was a specific constraint being invoked by Apple to control the amount of change, which would be a curious hypothesis considering that they have more talented and capable C++ and Swift programmers than any organization in the world.

Commits by Timezone

Commits by Timezone of Contributor

Safe to assume here that most of the contributors to Swift do so from Cupertino. This will now likely shift over time as contributors not based in California begin to contribute to the platform.

Top Authors

Chris Lattner is clearly “Neo” to the Swift Language’s “Matrix”. Other names in this list are all key Apple engineers including Doug Gregor, Joe Groff, Dmitri Hrybenko, Jordan Rose, Michael Gottesman, Dave Abrahams, John McCall, Nadav Rotem, and Mark Lacey.

Lines of Code by Author

Commits by Author

The best visualizations for contributors comes on the Github Contributors summary page.

Commits by Domain

Nothing surprising here with 97% of commits coming from Apple employees.

Lines of Code Over Time

Just your typical 1M+ line of code project growing smoothly over time. What will be really interesting will be to see whether open sourcing the application will result in a commensurate increase in the number of lines of code or if the size code will be kept in check.

Number of Files Over Time

Again, a fairly smooth growth curve, save for the bump in December 2014 which appears to be massive activity from Doug Gregor relating to Clang Importer.

Language Mix

The Swift Programming Language consists almost entirely of C++ and Swift, which consists primarily of code in the test folder.


That’s it! I love reviewing code bases using gitstats and the charts in Github (which are getting better and better, BTW) and was curious to break down Swift. I hope you thought this was interesting…


Evolution of the Zappos Product Page

We’ve come a long way in how we present products to our customers since the early days of the Internet. Let’s dust off and see what’s changed…


Zappos Product Page — Circa 2003

We’ll focus on circa March 2003 (or thereabouts). One of the things that stands out to me is how, arguably, e-commerce product page design has failed to evolve significantly from the basic template of 2003. Of particular note: the layout of the product images relative to the “buy box” (above and to the left), the next and previous image carousel metaphor, the Add to Cart button placement, and position of product descriptions relative to other elements on the page. Many e-commerce sites remain stuck in this paradigm.

Nostalgically, the screen from 2003 reminds me of the struggles web designers (myself included, albeit in B2B space) had in those days, including:

  • “Maybe a back button on the page will keep people from hitting Back in the browser too easily and leaving the site!”
  • “What if they scroll down and don’t see the Back to Browsing button we added at the top??? Let’s put another one at the bottom!”
  • “Internet Explorer 6.0 only supports standard <select> elements, so we have to design the variant pickers using that!”
  • “Oh, and the Size picker needs to filter the Color picker to ensure availability, so yes the page has to refresh”
  • <table><tr><td>We’re in table-based layout hell</td></tr></table>

Remember thinking this way? I sure do.


Twelve years later the 2015 is aesthetically quite different, though similar in a number of ways. Product Page in 2015
  • We no longer feel the need to cram everything “above the fold”. While Nielsen’s original usability studies were pivotal in guiding our desktop-centric designs in the past, the user experience community (including Nielsen) has acknowledged that scrolling is here to stay due as much to the shift to mobile as anything else.
  • Calls to Action, in particular the Add to Cart button, are extremely easy to find and target.
  • The new “Tell a Friend” feature is the obligatory social network button bar…and it’s arguably no more effective than the old feature was
  • Brand imagery (see “paul green” logo in each example) is less prominent than the more important elements of Price, Customer Reviews/Rating, and Product Recommendations.
  • Whereas the 2003 example provided tools (e.g. “Search for a Brand”, “Browse More Styles…”) for finding more products, the 2015 is more proactive and uses the now table-stakes recommendation engine approach to proactively suggest similar items.
  • While we have a better handle on the use of white space, we seemingly remain constricted to table- or grid-based layouts.


While Zappos is just a single entry in the vast library of historical product pages that can be referenced, I think it represents an interesting contrast between the past and present that is common in many e-commerce designs.

What, one wonders, are some other comparisons with the past worth making?