The Data-Driven Resume

D3 is amazing. Once I saw a few demos I knew I had to learn it, but what should I build first? It’s always more fun to solve a real problem. It hit me that a truly visual, data-driven resume for developers is way overdue. I’d found my project.

You can see a working demo here and the source here. The rest of this post describes the basics of how it’s put together.

Starting with JSON Resume

I found a promising project called JSON Resume, which made a great starting point for an interactive, data-driven presentation of developer experience. This nifty project defines a standard JSON schema for the contents of a resume. It lets you define the content of your resume as a JSON document, then you can apply any kind of presentation to it. See a nice gallery here.

I added a section to each work experience entry for projects. Each project has a name, description, start and end dates, and arrays of roles, languages, and tools. This is the detail that enables all of the visualizations and interaction.


Pick a Theme

I liked the Kwan theme. I converted it from Node and Handlebars to AngularJS. This gave me a good starting point to build around.

Categorizing and Normalizing Project Dates

Before I build any of the charts, I had to iterate through all of the projects, sort chronologically, and allocate timespans to each language and tool. I then build the data structures each of the charts expects.

Roles over Time


To show the career timeline with the various roles typical developers play, I started with d3-timeline. I had to make only minor tweaks to adapt it from hours to years. These was a nice hover feature that I used to show the relevant project at each time point for each bar.

Area Charts

Skills/Languages Area Chart

Skills/Languages Area Chart

An area chart communicates the flow of skills acquisition over time. This shows more than the typical “X years of Y” table and shows how the experience was gained over time. I added filters so you can limit just to particular roles.

Future Enhancements

The layout and graphics could use a designer’s touch. I think libraries should be broken out from tools. We can probably make better use of project descriptions. There is room for enhancing the JSON Resume to describe more detail about the strengths of the developer and the kinds of teams and roles sought. I think this is just scratching the surface of how interactive graphics can tell the story of each developer’s experience and direction.

The code is on GitHub. Try it with your own resume.

Drive: The Peopleware of this Generation?

imageThe 70’s and 80’s had The Mythical Man-Month. The 90’s had Peopleware. These works helped software managers understand and communicate to non-software people the dynamics involved in effectively managing software teams. The management models that got cars and TVs built at ever cheaper costs didn’t work on software projects. Brooks, Lister, and DeMarco helped thoughtful software managers figure out how to best manage professionals who must bring a challenging combination of creativity and technical rigor to their work.   

In Drive: The Surprising Truth About What Motivates Us, Dan Pink provides the same kind or resource for a more general audience. He argues that the models for understanding human motivation that worked in the past are outdated and don’t apply to today’s knowledge workers.

Pink contrasts internal and external motivation. Our internal motivation is driven by three needs: autonomy, mastery, and purpose.

Autonomy: We need more than “buy in” or even independence. We crave true self-direction.  To provide meaningful autonomy to our teams, we need to give our people choice over:

  • Task – What they do
  • Time – When they do it
  • Team – Who they do it with
  • Technique – How they do it

Mastery: We are driven to grow, improve, and be increasingly capable of solving more and more complex problems.

  • Mastery is a mindset: It requires the capacity to see your abilities not as finite, but as infinitely improvable. Internally motivated people tend to have an incremental theory of intelligence, prize learning goals over performance goals, and welcome effort as a way to improve at something that matters.
  • Mastery is pain: It demands effort, grit and deliberate practice. The path to mastery – becoming ever better at something you care about – is a difficult process over a long period of time.
  • Mastery is asymptotic: It’s impossible to fully realize, which makes it simultaneously frustrating and alluring.

Purpose: The old models for understanding motivation assumed that we are primarily motivated by money. Today we see money as a necessary but not sufficient reward of our work.  We want to know that what we do makes a difference in the world.

Much of Drive is derivative of the research done in cognitive psychology and behavioral economics, but Pink brings it all together in an engaging and practical way that will allow managers to put these ideas into action. I highly recommend it to anyone who oversees the work of anyone else.

For a small taste of the ideas in the book, check out this presentation.

Attributes of a Good Team Room

As we look at new office space, I had to think about what we would want in new team rooms. Here is what I came up with, with the help of my team…

  • Four walls (ideally with at least one being glass or lots of windows)
    • high enough to provide a sound barrier
    • lots of white-board space
    • wall of offices or conference rooms is OK as long as the doors can be closed
  • At least 5 feet of desk space per person
  • Ability to run HDMI to a large, shared monitor (probably on a rolling stand)
  • 8 – 10 people per room (ideally with removable wall to combine two rooms)
  • Private space nearby
  • Manager’s office nearby

Who Needs Vision?


I admit it—I don’t like Successories, the pretty pictures with inspiring sayings that don the walls of corporate America. In fact, my first purchase to decorate my team’s new space was the poster-sized Demotivator Calendar from I (and virtually every good developer I’ve ever met) love these spoofs on the ever-present corporate décor.

You might think I enjoy mocking Successories because I believe the words they portray like Values, Vision, and Mission are meaningless corporate-speak meant to manipulate shallow-thinking cubical jockeys. If that is what you conclude from a “demotivator” on my wall, you would be dead-wrong. image

I despise Successories for just the opposite reason. I believe the concepts these pretty posters are meant to inspire employees with are vitally important–way too important to trivialize with a one-size-fits-all platitude and poster.

Over the years, I’ve seen so many leaders (in both the social and commercial sectors) that struggle with communicating concepts like values, vision, mission, and strategy. So, it’s no wonder that so many people have completely written off the words themselves. They now associate a word like vision with the vapid trivialization that is the meaningless poster. This is tragic.

What to Do About It

I have found that the confusion starts when we fail to define our terms. How does mission differ from vision, and is either really any different from strategy? What do we mean by values? If we cannot define the terms, we cannot think clearly about them, and we certainly cannot communicate them to our teams. We’re left simply resorting to something like “We are a company with an obligation to shareholders to make money. Bottom line: we need to make money.” While this is completely true, our people hear this as “We do anything for money.” We have some unpleasant names for people with this mission statement. No one wants to sign up for that. We must do better.

Defining Terms

Let’s start with some definitions…

Values articulate the core things we care about. Our values inspire our vision.

Vision is our picture of how the world could and should be. Our vision defines the end we strive for.

Mission is what we do every day. Mission is executable and it doesn’t change lightly.

Strategy lays out a plan for executing on our mission.

Goals are surfaced by our strategy.

Objectives are framed by our goals.

Tactics are driven by our objectives and determine how we spend our time and energy.

I see these concepts as layers of foundation, each one flowing from and building off of the lower layers. The lower layers are more abstract, simple, and unchanging. The upper layers are more concrete, detailed, and subject to changing circumstances.



I believe much of our values are universal. We all have a drive to leave our mark on the world, to give more than we take, and to be competent. Software people add to this a strong desire to create. We find it deeply satisfying to solve real problems with elegant models formed in our imaginations and elegantly crafted in code. I am sure it is the same rush a painter gets as he translates the scene in his mind onto canvas to the delight of his audience. He comes to love the smell of paint the same way we come to love the sight of clean code.


Vision is seeing what isn’t, but could be. Vision isn’t about what we do, it’s about how we want things to to be. Vision creates an anticipation of a better future. That anticipation motivates. It overcomes the apprehension that comes with change and drives us out of our comfort zone.


Having, believing, and communicating a compelling vision for my team is the most important thing I do as a leader. Everything else flows from it.

Lewis Carrol’s famous “If you don’t know where you are going, any road will get you there.” has become cliché, but only because it expresses “common sense” that we often miss.

My team creates solutions for service businesses with field workers, like HVAC install and repair, plumbing, pest control, cleaning services, and others. The work these companies do is critical to the quality of life we all enjoy. We believe the tools these people currently have to run these businesses could be so much better. We burn untold gallons of fossil fuels routing drivers inefficiently. So many hours are wasted annually because, not only are we scheduling, but the entire process is unpredictable.

Our vision is of a transformed service industry—quicker response times, tighter scheduling windows, more customers served, and less fuel consumed. In order for us to accomplish this, our solutions must be highly scalable and allow for high levels of developer productivity.


If values and vision answer the why question, mission answers the what question. My team’s mission is to deliver software solutions that bring about the transformation of field service business we envision. We can only accomplish this mission if we have simple yet scalable architectures and clean code.


If vision answers why and mission answers what, then strategy answers how. My team is executing on its mission through several high-level strategies.

  • We use iterative development cycles and the other agile techniques to ensure that we are always working on the highest value features for our market.
  • We are building a distributed system of event-driven services that each follow the Single Responsibility Principle so we can scale the application as well as the development team(s).
  • We are always striving to improve our skill in writing clean code.
  • We follow test-driven development to keep our designs clean and our code reliable.

Goals, objectives, and tactics each successively further flesh out the details of how we plan to make our vision a reality. Maybe more on those in another article.



Putting Successories on the wall is a substitute for vision like a Lunchables is a substitute for a fine steak dinner.


On Summer Internships


I had my first experience with hiring a summer intern this summer. It turned out to be a great experience, but I credit this to the fact that I work with a great team and our intern was a stellar young guy. I realized that I need to have a plan for future internships. First though, I need to clarify my philosophy of internships. In other words, I have to answer the question… Why have summer internships?

Future Hires

Summer interns make great hires. What better or more thorough interview process than working with someone for three months? Finding and eventually hiring great developers is reason enough to have an internship program.


At the end of the summer, those interns will go back to school. That is where many of tomorrow’s great developers are hanging out. What better way to reach those future developers than to send students back to school having had a fantastic experience at your company?

Giving Back

A summer internship gives your developers an opportunity to have a positive influence on future developers. Even your most junior developers get to become mentors to an intern. Giving back in this way reinforces the value that software development is a profession and we are professionals. Taking the time to invest in the career of a young software developer is one way to separate professional developers from hackers.

Getting Work Done

I put this last because I think it is the least important of the list, but you just might find that that your interns do some really great work. My team was fortunate enough to have such a great young developer this summer that the work he contributed to was outstanding. Fresh perspective and ideas can be very valuable to a team.

Sprint Planning and Decision Fatigue

This article explores the physiological and psychological effects of fatigue brought on by making decisions. The fatigue that comes from making decision after decision immediately reminded me of my team’s Scrum sprint planning days.

The Scrum method breaks software development into iterative cycles called sprints. Our sprints were the highly typical two weeks in length. The idea is that two weeks is a short enough planning horizon that we can pull in enough work from the backlog to fill that time period. Then we demo what we’ve done to the various stakeholders in the company, adjust existing backlog priorities, plan another sprint, and on it goes.

Sprint planning day looked something like this…

9:00 Demos (any stories that haven’t been shown yet)

9:30 Close out the Previous Sprint (closing stories in VersionOne, splitting any unfinished stories, etc.)

10:00 Retrospective (look back over the prior sprint and identify things that worked well that we want to do more of, what didn’t work so well, and identify any impediments to progress)

10:45 Start Sprint Planning (Story Breakdown)

1:30 Finish Sprint Planning (Story Breakdown)

We often wouldn’t finish sprint planning until after 4:30. 

Story Breakdown

Sprint planning is the process of taking the high-level stories and breaking them down into tasks. We did this as a team; so, we had everyone’s input and everyone knew how we were going to go about implementing each story. This is vital to maintaining a team approach to building the product.

This story breakdown, however, is the hardest part of the whole sprint. We have to make decision after decision about how we are going to implement a feature…

Will there be a new database table? Will it be a variant of some existing feature or something new? Is there some new UI element that we haven’t tackled before? and so on.

Then for every decision, we have one more decision: how long do we think it will take.

I believe the hardest part is that we move from one decision to the next without actually doing anything. We are simply adding our decisions to the inventory to be acted on over the next two week. This makes the decision fatigue factor even greater.

By the time we got to 3:00 or 3:30 the team would often be so fatigued that we would start placing two tasks on each story: Plan it and Do it. During the sprint, if we came across a story with a “Do it” task, it was a safe bet that it was planned late in the day.


I can see two ways to reduce the decision fatigue that comes with Scrum planning day: 1) reduce the Sprint length, or 2) don’t do Scrum.

For most teams doing Scrum, I think shrinking the Sprint length to one week will reduce the planning day fatigue. Our team, for other reasons, switched to a Kanban continuous flow model. Under that model, we did the story breakdown as the queue of planned stories got low. It was never two weeks worth at one time, and we had fewer “Do it” tasks.

Split the Team or Split the Backlog?

Small software companies often find themselves trying to do too much with too little. This was certainly the case at Agentek. At one point earlier this year, we had a problem… We were not finished with the current release (call it release A), but we could not wait until it was finished to get a start on our next release (call it release B). There was too much unknown involved in release B. We had to get started on it. At the same time, we had just committed to ourselves that we would not leave our customers with anymore half-finished releases. What to do?

Our team had four fully dedicated developers, a tester, and me. We needed to dedicate 25% of our time to release B. The first option was to simply intersperse the backlog with stories from release A and release B…

Interspersed Backlog

Interspersed Backlog

There were two problems with the interspersed backlog. First, release A has a good bit of reactive work; so, the backlog is unpredictable and tends to consume the entire team’s attention. Second, since stories vary in actual effort to complete, we cannot really gauge or control what percentage of our capacity is applied to each effort.

The next idea, was to split the team and apply 25% of the people to release B….

Split the Team

Split the Team

This is the mathematically cleanest solution and the option that traditional software managers would probably pick every time. However, this option has major disadvantages…

  1. Only one developer will know anything about how release B was implemented.
  2. The many advantages of pairing are lost on both efforts because we have only one developer on release B and an odd number on release A.

This option really just throws the team-based approach to building software out the window; so, not an option for us.

Next thought was to create two separate backlogs….

Split the Backlog

Split the Backlog

This makes the problem we are trying to solve clearer, but we still have the problem of how do we stay united as a team, yet timebox each backlog.

The next step was to designate days of the week for servicing each backlog. To give the forward-looking release one fourth of our capacity, we dedicated one pair to that backlog for half of the week. To simplify things, and give it a little more than 25%, went ahead and gave it three full days instead of two and a half. So this is what things looked like…

Split the Backlog and the Week

Split the Backlog and the Week

We rotated the release B pair so that there would always be one person that worked on that last week for continuity and one new person.

In our first retrospective after we finished release A (and moved onto release B fulltime), the team was convinced of a few things:

  1. One team working on two releases at once is hard.
  2. Keeping the team together was really important.
  3. Splitting the backlogs and the week turned out to be a great way to do both at the same time.

DDD Anti-Pattern #2: Not Getting the Whole Team Educated on DDD Early Enough

The two challenges that drew me to Agentek in late 2008 were interrelated in the same way that the proverbial chicken and egg are. We had to build a complex, composite, occasionally connected, enterprise mobility application to replace the prior practice of custom, one-off solutions. At the same time, we had to bring the existing development group up to speed on current software techniques, practices, patterns, and processes.

I couldn’t hold off on designing and building the new product until everyone had gotten the DDD religion. In reality, I don’t think I would have done that even if I had the luxury of that kind of time. Concepts like DDD are best learned by doing them with someone who has done it before. Reading books and hearing presentations can get you excited about them, but only doing them helps you actually learn them.

As I prepared for the first meetings with the domain experts (folks from across the organization who had implemented multiple custom solutions and had a good sense of the domain of our new product), I sent out a copy of Domain Driven Design Quickly. I wanted to give them as much of an idea of what I was after as possible up front, but it mostly came down to me explaining it as we were doing it.

We had some great sessions. The white board photos we made in those early days formed a remarkably useful and resilient core of the domain model that is still reflected in the product today. We hashed out much of the [soon to be] ubiquitous language, and we all had a vision of what the new product would be.

Shortly after this, we hired a big DDD advocate (I’m still amazed at our good fortune in finding him. They are rare now, even more so in 2009). With Jarrel and me on the development team, we spread the DDD mindset organically as we built out the product. This seemed like a good and pragmatic approach.

In late 2010/early 2011, the entire development organization went through the blue book, chapter by chapter, discussing the pros and cons of Evans’ approach, where we’ve been effective, and where we haven’t.

What I learned was loud and clear: We would have had a better product and stayed out of the technological weeds much better if we had formally gone through the DDD material in 2009 instead of 2011. I underestimated how much more effective the team would have been if we took the time to build a common foundation of the DDD concepts. It didn’t mean we had to hold anything up. I just should have made it a priority earlier. I wont make that mistake again.

Misconceptions about Team Rooms and Open Floor Plans

I see this far too often. Well-meaning software organizations embracing agile software development tear down the walls in order to open up the space and allow easier collaboration. This sounds great, and it’s cheap. An easy win, right? Not if it’s done without some care and thought.

Premise 1: Irrelevant conversations are distractions.

Human beings are trained to pick other human beings’ voices out of the background noise and pay attention to them. There is little that is more distracting to concentration than hearing a conversation that has nothing to do with what you are working on.

Premise 2: A team is a group of people working toward a common goal.

If a team is really acting as a team, there is nothing that one subset of the team could be working on that is irrelevant to the rest of the team.

Imagine Team Green working in an open team room, paired at stations with one monitor and dual mice and keyboards…

Team Room

Let’s say that pair number 1 is having a conversation…

Team Room One Conversation

That conversation is heard by all other members of the team. Because Team Green is a team, the fact that the whole team can hear it is a good thing. I cannot count how many times I have seen this…

Pair #1 overhears pair #2 getting stuck on some problem that sounds familiar. Pair #1 stops and gets involved in what pair #2 is doing. The four people discuss the problem and solve it, based largely on some previous experience that someone on pair #1 had. If one pair had not overheard the other pair struggling, they might have wasted a whole day (or at least until the next stand-up).

Now imagine Team Green is really busy and all working and talking…

Team Room Communication Saturation

I first heard this situations referred to as communication saturation by Jeff Sutherland, but I think he got it from Jim Coplien. Here we have everyone able to hear every other conversation. If a stranger were to come upon this team area, it would sound like noise. But to a high-performing agile software team, it is completely natural because every conversation is related to furthering the goal for this iteration.

Now imagine we have a collaborative, high-performing Team Blue…

Team Room Blue 

Team Blue is enjoying the same open space benefit that Team Green is. Now imagine we take our open-spaces-are-good momentum and co-locate Team Green and Team Blue…


Now we have green conversations in the blue team area and green conversations in the blue area. This is not good. We now have noise distracting both teams.

If the blue conversations are as useful to the green team as green conversations, then you are not doing team based development.

There are two possible remedies: create more space between the teams, put up acoustically meaningful walls, or both.

Team Room Noise Fix Walls

The bottom line: open spaces and shared conversations are good only within a team, not between teams.