The post on “Beware of Developers Who Do Negative Work” was both enjoyed by many and highly criticized by many. I’m usually fine with criticism, but one point really stung.


A lot of the criticism denounced the idea that junior developers do negative work. They need mentoring and coaching, not to be frightened and have their insecurities targeted by callous bloggers such as myself.

The point stung for two reasons. The first is that it’s true. You should hire a junior developer with the proper expectation that they do need a lot of mentoring. They will also grow far more in their first 2 years than most other developers will in that same time frame. And it is a shame that while they become 5x to 10x more productive after those first two years, most will have to switch jobs in order to get more than a 10% raise.

More importantly, we all start out as junior developers. If you have no experience, then you are a junior developer. Title is irrelevant. By that definition, all developers start there and all developers need an opportunity to get that experience.

One of my most rewarding experiences was fighting to get one of my interns an offer for a full time position. He obviously made many mistakes during his internship, but he also did great work. My boss thought I was crazy when I gave him an ambitious first assignment. Yet, he nailed it because we worked through the problem together and he understood what he needed to do. He earned the offer we gave him. I couldn’t have been more proud.

The second reason that point stung: No where in the post about negative contributing developers did I mention junior developers.

No where.

In my experience, being junior does not correlate at all with making a negative contribution as a developer. Things that do correlate are:

• Wanting to appear to do a great job rather than actually doing a great job
• Trying to do as little work as possible without getting fired
• Focusing only on your own work and valuing your own time rather than thinking about the team as a whole
• Living in the comfort of what you know and “how things have always been done” rather than learning something new

To clarify that last point: I mentioned “outdated” practices in the last post. That doesn’t mean anyone who refuses to jump on the shiniest new thing is stuck in the past. I personally prefer technology that has been vetted by people I trust. But there are still developers out there who do not believe in source control.

Source control. A standard for at least 2 decades.

There are developers who believe everything needs to be built in house. In a world where we are flooded with great open source projects.

There are developers who still don’t understand why it’s important to decouple front end and back end code. Another common practice for decades.

This is not an attitude that light coaching can solve all the time. This is something that can take months of debate. In the case of overly influential developers, this can be months where the rest of your team suffers.

If you have never worked with these types of developers and don’t believe a word I am saying - that is awesome! We should all work towards a world where all developers have that same great experience.

For now, many of us have to deal with messy situations.

We join companies where a bad developer is favored by the CTO for some reason, or worse… is the CTO.

We join companies that revere a “hero” developer who has always done the seemingly impossible… by writing horrible code that no one else can work with. To non-technical managers, no one else looks like they know what they’re doing except for that “hero”.

We join companies with years of legacy code. Business needs often prevent an entire development team to just take off a year and rebuild everything to work with continuous deployment.

Software development is an extremely rewarding field to be in, but it also has some significant challenges. It can lead us to some dark places. Talking about the negative aspects in our field helps us cope. One developer I worked with said that it even raises morale.

If you think about it, that makes sense. Imagine these corporate situations that happen all too often:

Employee: “The company just reported disastrous earnings last quarter! Will our jobs be safe?”
Corporate representative: “The company is stronger than ever.”
Employee: “You just announced huge layoffs!”
Corporate representative: “We have improved our business synergies and efficiencies.”
Employee: “Our benefits just got cut!”
Corporate representative: “Your benefits have been changed and tailored to best serve you.”
Employee: “What just happened to our equity?”
Corporate representative: “We have entered into a partnership that will make our business stronger than ever.”
Employee: “But what about the equity we received?”
Corporate representative: “You are working for a great company with a great mission!”

Not every company is like this, but many are. They act like this in an attempt to keep morale high. Yet the positive tone is obviously fake. All it does is tell people that they can’t say anything negative. They can’t talk about the things that concern them. They can’t commiserate with their coworkers.

More importantly, we can’t fix things if we can’t talk about them.

Software development is hard, but we can work towards making it better.

To all those who liked the post, and especially those who emailed me their stories: I hope you can use it to make your own development life a little better. Maybe you now have the inspiration to have productive discussions with your managers about the topic. Or maybe you just found the post therapeutic to know you aren’t the only one who has to deal with those struggles. I’d be happy either way. I will continue to discuss all aspects of software development with anyone who will listen and I hope you will too. Sharing our experiences will help us all find the best path forward.

To the junior developers who found the last post terrifying: I’m sorry. I have forgotten what it’s like to just start out. I forgot what it felt like to worry about being fired after every bug during my first few years as a developer. I did not see how that post could have been misinterpreted, but now I do. I can be more cognizant of that in the future. And you should know that junior developers are not excluded from being considered great developers. All it takes is the desire to be better tomorrow than you are today.