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.

Recruiting: Where to Start

There is no more leveraged activity in building an effective software team than recruiting. The hours or days spent choosing people to add to the team will have a disproportionally large impact on your team’s effectiveness.

If you haven’t already read Joel Spolsky on hiring, you must. Now. The two big ideas I learned from Joel are still the most important ideas in all of my recruiting success…

Joel Big Idea #1

If you cannot answer the “Should we hire this candidate?” question with an enthusiastic “yes,” then it’s a no-hire. There are no “maybes.” The reasoning is simple—a mistaken hire is much more costly than a mistaken no-hire.

I find this principle easy to agree with but difficult to follow. Great developer are always hard to find. The pressure “be reasonable” and hire a maybe candidate has caused me ignore this principle. I’ve regretted it every time.

Joel Big Idea #2

There is a simple rule of thumb to hiring any developer on any team. You are looking for two things: the candidate…

  1. is smart, and
  2. gets things done.

Look at the following grid.


You would never intentionally hire Useless, but lets look at two easy hiring mistakes.

Tinkerer: Someone who is smart, but doesn’t get stuff done. This mistake is easy to make because he gives good answers to typical interview questions. However, once you hire him (or her) you find that nothing actually ships. Our industry is full of smart people who are content to learn and write code, but don’t want to commit to finishing something. They never have to deal with customers or operations or any of those messy details because they are always almost done.

Mess Maker: Someone who is not smart, but gets stuff done. This mistake is easy to make because he can tell you all about the projects he has completed. However, once you hire him, you will find that he leaves a trail of messy, fragile code behind him. You will spend more time trying to fix the messes than you gained by having him create them.

The effective developer is the one who is smart enough to appreciate the competing factors and trade-offs that come into play when creating software and is driven to see his solutions solving problems for actual users.

Identifying the smart developers who get things done is no easy task. I’ll have more to say about that in future posts.

TDD and the Power of Habit

“Champions don’t do extraordinary things. They do ordinary things, but they do them without thinking, too fast for the other team to react. They follow the habits they’ve learned.” –Tony Dungyimage

The quote above comes from The Power of Habit: Why We Do What We Do in Life and Business by Charles Duhigg. This book is a fascinating look at habits—what they are, how they form, how they affect us, and how can we choose our habits.

The Habit Loop

Most of us are barely aware of the habits that make up so much of what we do, but psychology and neuroscience researchers have made great progress in understanding how habits form.


At the core of this research is what Duhigg calls the habit loop. We usually have no trouble identifying the routine, which is what we think of as the habit itself. The value comes from identification of the two other elements of the habit loop.

The first insight comes in realizing that habits are driven by some kind of reward. The reward could be virtually anything–relief from boredom, sense of completion, etc.image As our behaviors result in the reward we seek repeatedly, our brains literally restructure themselves. Our brains move the instructions for performing the actions needed to invoke the reward to areas that can operate without our conscience thought. Our habits become become so deeply encoded that they become almost impossible to separate from who we are.

The second insight comes in recognizing that there are particular cues that trigger the routine in pursuit of the reward. Cues could be just about anything as well–a feeling of boredom, the sight of a particular object, the presence of a particular person, etc.  Identifying these cues are key to understanding and changing our habits, but you’ll have to read the book for that.

Keystone Habits

Studies have documented that families who habitually eat dinner together seem to raise children with better homework skills, higher grades, greater emotional control, and more confidence. Making your bed every morning is correlated with better productivity, a greater sense of well-being, and stronger skills at sticking with a budget. It’s not that a family meal or a tidy bed causes better grades or less frivolous spending. But somehow those initial shifts start chain reactions that help other good habits take hold. If you focus on changing or cultivating keystone habits, you can cause widespread shifts. However, identifying keystone habits is tricky. To find them, you have to know where to look. Detecting keystone habits means searching out certain characteristics. Keystone habits offer what is known within academic literature as “small wins.” They help other habits to flourish by creating new structures, and they establish cultures where change becomes contagious.

Keystone habits are the drivers that lead to other habits. For example, studies have shown that people who adopt the habit of regular exercise find that seemingly unrelated areas of their lives change for the better (being more productive at work, smoking less, being more patient with their kids, etc.).

Small Wins

Small wins are exactly what they sound like, and are part of how keystone habits create widespread changes. A huge body of research has shown that small wins have enormous power, an influence disproportionate to the accomplishments of the victories themselves. “Small wins are a steady application of a small advantage,” one Cornell professor wrote in 1984. “Once a small win has been accomplished, forces are set in motion that favor another small win.” Small wins fuel transformative changes by leveraging tiny advantages into patterns that convince people that bigger achievements are within reach.

Small wins are those sure steps in the right direction that separate high performers from everyone else.

TDD: Keystone Habit of Great Developers


The agile software movement centers around incremental and iterative steps with feedback mechanisms that allow for lots of small adjustments to bring the project to success. So, when I hear Duhigg talk about small wins, it resonates with what we’ve found in building software.

Test-Driven Development (TDD) is the most central of agile practices. It fits Duhigg’s definition of a keystone habit.

TDD and Small Wins

The demands on software developers get bigger and more more ambitious all the time. We presented with complex problems that we generally don’t know how to solve. It is easy to become overwhelmed by the magnitude and get bogged down trying to boil the ocean with code.

The discipline of TDD forces us to methodically break problems down into small chunks. Each passing test is a win and one small step closer to the system the customer needs.

The Cue is obvious: a customer needs a new feature.

The Routine is the well documented (but seldom practiced) red-green-refactor loop.

The Reward is the passing test and a thoroughly executed unit of responsibility completed.

The cycle continues, with small wins coming one after another until the feature is complete.

TDD as Keystone Habit

The TDD habit has many follow-on benefits beyond completed, tested software. Every time we write a test before we write the code, we remind ourselves of several truths:

  • If the software is worth creating, it is worth ensuring that it works.
  • Each unit of functionality must have a single responsibility and its dependencies must be loosely coupled.
  • Keeping the code clean is vital. Keeping it clean is made possible by the protection provided by a comprehensive suite of tests.
  • Writing only enough to make the test pass keeps our focus on the customer’s requirement and not a speculative future feature.

I’ve found a common idea emerging among the colleagues that I respect most: we would rather hire a developer that practices TDD and does not have experience in the primary programming language our shop uses than hire a developer with that programming language experience that does not practice TDD.

Language syntax and style is relatively easy to learn. TDD is a keystone habit of great software developers.

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.

First Who… Then What

One of the first things I’ve been occupied with on the new job is interview candidates for software development openings we have. In recent years, I’ve been drawn more and more to get involved in the hiring process. I believe there is no more critical, leveraged action you can take toward making a software company successful than finding and hiring the right people. Having the right people is more important than programming language, platform, or methodology. The best people will overcome poor technology choices. The wrong people will eventually fail no matter what technological advantages they have.

In Good to Great, Jim Collins lays out a principle he calls “First who… then what.”

Executives who ignited transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it. They said, in essence, “Look, I don’t really know where we should take this bus. But I know this much: If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great.”

To a large extent, I think it is the same way with software. Assemble a great team, then decide what to create. In the world of commercial software, it rarely works quite that way. There is almost always a product in mind before the team is assembled. So, it’s not feasible to get the right team, then decide what to build, but it is realistic to get the right team in place, then decide how to build it. The how is always what separates good software from bad anyway.

As I’ve been immersed back into the hiring mindset, I continue to be struck by how many people who make their living developing software are so weakly grounded in the fundamentals. More on that later…