Dan Donahue bio photo

Dan Donahue

Musician. Traveler. Programmer.

LinkedIn Github Stackoverflow

Once upon a time, there was a developer who had recently graduated college. He was a confident and charismatic young lad who liked to think about and attempt to solve challenging problems. He was te type of go-getter that companies love. And he was on a team of senior developers who were mentoring him. It was a perfect situation. But it fell apart.

The young, confident developer emphatically refused to be seen as a junior developer. He refused to take advice of the older, experienced developers around him. His confidence outweighed his competence. And eventually, he spoke to his manager and requested to be taken off this team and placed on a team by himself. The request was granted.

On this new team-of-one, the young developer was given a greenfield project. He wrote it all by himself and was quite proud of it.

A few months later, he decided he wanted to join another existing team and he was granted his request. The project he worked on in isolation was handed off to a different set of developers to maintain.

The new maintainers of this codebase quickly raised red flags about the code quality. Their morale dropped because they were being handed a mess and were asked to clean it up. Further, clients using the code sent the young developer an email saying "there are a lot of problems with this software and we need them fixed." His response? "I no longer work on that project. Please get in touch with the new maintainers about these problems."

The office hears about this morass and the proposed solution is to have all of the developers come up with a process that stops this from happening again. Now morale amongst ALL the developers is down...

------------------

Situations like this are not uncommon. My goal is to elaborate on where I see mistakes were made that could've prevented, or minimized the damage, of this situation.

I see two categories of mistakes or intervention opportunities. The first category revolve around the actions of the junior developer.

Having confidence outweigh your level of expertise is quite a common scenario for young developers. I know I was guilty of that. It's so normal that I'd almost consider NOT adding this to the list of problems. But it is the problem. The actions are the symptoms. Casting aside the guidance of your mentors and actively looking to get away from them - those are symptoms of the problem. They're often subconcious acts to remove people who are challenging your view of yourself. But I cannot stress enough how important being challenged is to your personal growth. You learn as much from your mistakes as you do your successes. I know, from experience, that the way I went from "thinking I know it all" to "realizing I don't know anything" is by having long, empassioned discussions/disagreements with my mentors. These are the people who challenged my assumptions and forced me to think. They hold a special place in my heart for guiding me through the early part of my career.

The second mistake the junior developer made is a lack of professionalism. When he passed the buck in his response to the client, that shows a lack of responsibility. There are no two ways about it. There are a lot of lessons to be learned from maintaining and fixing code that you wrote. Lessons that books don't teach - lessons that come only from experience. To shirk away from those lessons makes you prone to repeat them again.

The other category of mistakes are on the management side. In most cases, they complement or enable the developers' mistakes. It may not be immediately apparent, but this class of mistakes may actually be more dangerous. As a manager, you are responsible for those you manage. You are doing a disservice to them by putting them in a situation to fail.

Right out of the gate, I think it's fair to say that the manager should've thought harder about granting the young developer's request to start his own team. As a manager, you need to both understand the role of mentorship to bring young developers up to speed and also you need to have a fair assessment of whom the experienced developers are in the office who are both able and willing to mentor. It could be possible that the group that was mentoring the young developer weren't working with him or her in a way that was suitable to the way the junior developer learns. That's fine. In that case, I'd move the junior developer to a group with experienced developers who could try different tactics. But giving the young developer that much freedom was really just providing him/her with enough rope to hang themself.

In fact, take experience out of the picture. It's dangerous to have an "army of one" - a developer working on a piece of software in isolation. Think about the old "hit by a bus" scenario. If this developer quits, or worse, all the knowledge of that codebase goes with them. There are also reams and reams of evidence which conclude that extra sets of eyes on code will uncover more bugs earlier and results in cleaner code being written. So really - allowing ANYONE to code without some sort of oversight is a recipe for disaster.

The manager also failed in making sure there was a handoff strategy when this project was moved from the young developer's plate to the new team. This is the figurative part of "hit by a bus" without the literal part. Some new team is going to get code they don't understand and be under pressure to make sense of it. What happens when it doesn't meet their standards? How confident can they be about adding or changing a feature when they can't fully comprehend why a feature is in its current state? They have no idea about the assumptions in the software, why certain decisions were made. They're in the dark. It puts them in a position where they can't feel comfortable changing code they're supposed to maintain.

Lastly, I think the lack of swift action by the manager when the young developer shirked responsibility in his email to the client was a HUGE mistake. This is a teaching moment lost. By not acting, it can subconciously reinforce the idea of not being accountable for the code a developer writes. That's a slippery slope.

One last point. I've made a point in other blog posts that I'm not a fan of hierarchy at work. And yet, I've made a whole category of "management" errors in this post. So I just want to clarify - in lieu of managers, all these points would be the responsibility of ALL of the other developers to hold themselves and each other accountable. It's less class structure, more socialism :)

This probably isn't an exhaustive list. I would love to hear more opinions in the comments as to what problems you see, how you'd address them, etc. If you take issue with any of mine, I'd love to discuss that as well.