To give career advice to 20 million software developers, I first had to learn how to advise one teddy bear.

After the internet had finished giving me feedback on “How to Deal with Difficult People on Software Projects,” I had a few takeaways:

• My archetypes of challenging people applied to software teams around the world, including organizations in America, Europe, Russia, Australia, China, and Japan.
• My descriptions were freakishly, unnervingly, disturbingly accurate; to the point that people took my generic archetypes as fact.
• People either thought it was hilariously funny, tragically depressing, or both.
• People had strong emotional responses to self-identifying as one of the problematic people
• According to site traffic, people were sharing links to individual profiles quietly among friends and trusted colleagues at an alarming rate, notably “The Incompetent” and “The Diva.”
• While some people enjoyed it, others were disappointed in my “Are you a Dysfunctional Developer?” quiz.

The last bullet point was understandable, as I had spent years refining the archetypes, and about 4 hours on the quiz. The quiz was meant to be a source of entertainment, but many people took it as a tool for self-diagnosis – understandably so in hindsight.

Considering the overwhelmingly positive feedback I had received on the archetypes, the disappointment in the quiz bothered me. It wasn’t so much that people didn’t love it, but more than I had produced something that didn’t meet its full potential. I contemplated what to do for a few months and ultimately decided that if people wanted a tool for self-diagnosis then that what I was going to do – but I was going to do it right this time.

One of the first decisions I made was to get away from the idea of slotting someone into one of the problematic developer profiles or declaring they were not a problem. That approach had too much in common with the Myers-Briggs test, and I didn’t want to imply that all software developers fit neatly into standard buckets. I needed something that gave someone feedback on their approach to working on a team of software developers but didn’t pigeon-hole them. Since this was a quiz, it seemed intuitive to present the results as a scorecard of some kind. For the scorecard to be comprehensive, I was going to need a more extended quiz, but at this point, I didn’t know how much longer it was going to end up being.

My first challenge was to come up with the categories on the scorecard, which I wanted to tie back to the original difficult developer archetypes. My strategy was to define each of the individual attributes that made a developer challenging to work with such that the variability of characteristics would predict someone being one of the archetypes. What I came up with was a grid with the developer archetypes across the top, and the attributes along the side. After a few days of tweaking, I ended up with 14 characteristics:

1. Communication – How well you communicate
2. Teamwork – How well you work with a team
3. Curiosity – How much interest you have in learning new things
4. Initiative – How much you desire to start new things
5. Skill Level – How well you code
6. Attention to Detail – How well you understand and implement requirements
7. Business Focus – How much you care about the goals of the business
8. Deadline Focus – How much you care about deadlines
9. Estimate Accuracy – How accurate your estimates are
10. Productivity – How much work you produce per unit time
11. Criticality – How important you are to an organization
12. Marketability – How easily you can find a new job
13. Adaptability – How well you can adapt to a new environment
14. Risk Tolerance – How much you fear failure

Now I had what the scorecard would consist of, and I only had to come up with questions that assessed your level for each of the fourteen attributes.

But something was bugging me.

I hold the firm belief that you shouldn’t identify a problem without having a solution. If I was going to create something that determined someone had a problem, I needed to help them fix that problem. Unfortunately, the only way I knew how to fix these types of issues was through 1-on-1 coaching, and I couldn’t coach everyone who took the quiz.

…or could I?

A coaching session generally is the coach speaking with the person receiving the coaching listening. A good coach would base their coaching on what the person needed to hear, and I already would have their quiz results before I determined what coaching to give them. That meant that I could provide focused coaching without actually having met the person.

To replicate the experience of 1-on-1 coaching, I wanted to record audio of me speaking, and I got started writing a script to do a prototype recording to see how effective it might be.

It was horrible.

I sounded robotic, unenthusiastic, insincere, and generally not like myself. Reading from a script is decidedly not how I gave coaching in real life. When I gave coaching live I was imperfect: I had to search for the right words, and often made wild tangents with anecdotes and analogies of questionable relevance. Despite all of that, it was authentic. If I was going to do this, I had to find a way to do it live – just as if I was talking to someone.

Enter Bailey the Beargrammer.

I went out and found the most massive teddy bear that could fit comfortably in a chair, and named it Bailey. The alliteration of “Beargrammer” came naturally, and it stuck. I now had someone to talk to during coaching sessions, and a quick prototype recording proved to be vastly superior to the scripted version. I now had the challenge of figuring out what to say.

The structure of the scorecard gave me fourteen attributes, each of which could yield the quiz result of a high, medium, or low score. As the coaching was going to be based on someone’s quiz result, that meant I needed 42 recordings.

If was going to do 42 live audio recordings, I needed them to be short for me to get through them all. I figured I would shoot for an average of around 15 minutes, which meant I had to get straight to the point and cut out all of my usual anecdotes, metaphors, and wild tangents.

To keep the recordings focused, I decided that while I didn’t want a script, I did need at least topics. Focusing on three items seemed like as good a number as any, which meant that I would be speaking on 126 subjects in total.

Even with them being 15 minutes each, I was still signing up for producing 10.5 hours of audio. The final product ended up being 13 hours, as the average length of each recording ended up being around 20 minutes.

To produce the final 13 hours of content was far more time consuming and demanding that I could have ever anticipated:

• I would end up recording all three levels for a particular attribute in one session lasting about 3 hours.
• Immediately before recording, I would review the three topics I would be covering.
• I used a portable recorder and a collar microphone so that I could forget the fact that I was recording myself.
• I would setup Bailey in my living room.
• I would turn on the mic and start recording.
• Each coaching session needed to be 45 minutes of raw audio to end up with around 20 minutes of final audio.
• I would then spend around 4 hours per-recording editing, 168 grueling hours in total.
• During editing, I removed all of my bumbling and stumbling, to result in a crisp, compelling, concise treatment of the topics I was covering.

Once I was done the editing I was the proud owner of 13 hours of audio content spread across 42 mp3s. After listening to the final versions in their totality, it was clear that I was providing career advice in the form of podcasts, so that’s how I thought of them from that point forward.

I was exhausted, but it was time to come up with the questions for the new quiz, which I figured would be a breeze compared to the grueling editing process.

I was wrong.

I decided to come up with two questions for each of the three topics for each of the three levels for each of the fourteen attributes. To keep things simple, I decided to have people answer how strongly they agreed or disagreed with the characterization of a polarizing issue that software developers often face. That then resulted in the new quiz needing 252 statements for me to accurately assess which level of coaching you required based on your quiz scorecard.

Four days later, I had my 252 statements, and the quiz was complete.

I now had the 42 podcasts and the 252 statements for the quiz. All I needed now was a way to bring them together. For that, I decided to do a custom web app. The idea was for you to take the quiz and then based on your resulting scorecard, you would gain access to the appropriate career-advice podcasts.

Making it a web app would allow me to do neat things like being able to embed demo scorecards in each of the twelve original difficult developer profiles, as well as provide people who took the quiz with the ability to share their scorecards if they so desired. Since the goal was to help software developers improve, I called the product a “Developer Tune-Up,” but developertuneup.com/username wasn’t great for sharing scorecards. Fortunately, the new .dev domain names started to become available, and by paying extra to be in the earlier rounds of availability, as well purchasing it within the first 30 seconds of becoming available, I snagged scorecard.dev.

Around this time, my friends and family had an intervention. They were concerned that I was spending months (years, if you include the original archetypes) obsessively creating a comprehensive career-advice solution and wasn’t going to charge for it. After quite a bit of argument, we settled on charging for the app, but only pricing it as I would if it was an audiobook. Some wanted the full unlocking of your quiz results to cost hundreds of dollars, as it had the potential to help software developers make several tens of thousands of dollars more if they took my advice, but I was adamant that just about any software developer should be able afford it. As a further compromise, I promised that I would add the ability to for companies to buy developer tune-ups in bulk for their staff, which I did.

I’ll write about the process of developing the app at some point, but after 20 years of developing apps, it went as it always does: seems simple in the beginning, and only shows it’s real hidden complexity at the end. I only went 30% over time budget for development, which is way better than my 300% average.

Now that the Developer Tune-Up is complete, I couldn’t be more proud of the result. Everything I wanted it to be is in there with no compromises. The main question I am left with now is: how helpful it will be for a software developer’s career? I’ve been coaching software developers for the last ten years, and the feedback I’ve gotten from the people I have coached has always been positive. However, compared to the 20 million software developers worldwide, the people I have coached represent an extremely small percentage. If not for all the positive feedback on “How to Deal with Difficult People on Software Projects,” frankly, I would never have attempted the Developer Tune-Up. Still, the question remains: can I do for individual developers with Tune-Up what I did for teams with Difficult People? Early feedback from reviewers leaves me hopeful, but only time will tell.