I used to think that a good developer could work pretty much anywhere and do good work. If the developer is good, then they’ll of course be good anywhere.

I’ve learned in recent years that this is not actually the case. If a developer gets hired somewhere and fails to do good work, it’s not always because that developer is a bad developer. Sometimes it’s because the developer’s employer fails to provide an environment conducive to success.

What a bad environment looks like

Chaos

In my experience, one of the common characteristics of a bad developer environment is chaos. There’s no development methodology, there’s no issue tracking, there’s no intelligent long-term project planning. Everybody just kind of does stuff.

If a really experienced developer enters this sort of environment, they might be able to help introduce some order to the organization or at least keep their little corner of the world orderly in spite of everyone else. But someone who’s earlier in their career, even if they’re really smart, might not have the skills and experience to do that. I’ve talked with junior developers before who have worked in very chaotic organizations who just thought it was normal. It was all they had ever known and so they had nothing to compare it to.

Managers in these types of organizations might expect a certain level of productivity out of their developers, not realizing that their organization’s environment makes good productivity unlikely, and conclude that the fault lies with the developers. Sadly, the developers might share this conclusion, ignorant of the fact that the chaotic environment is responsible for most of the productivity shortcoming.

Vague expectations

Along with chaos typically come vague expectations. This can happen at a low or high level, or of course both.

As an example of a low-level vague expectation, a developer might get assigned a ticket that simply says “Ability to add products” with few or no other details. There’s no way to tell when the ticket is complete, or whether the work done matches the expectation.

As an example of a high-level vague expectation, a developer might get hired with a title that implies role X when, all along, his superiors expected him to fulfill role Y, but never explicitly stated this expectation until several months after he started. (This exact scenario happened to me once.)

When a developer isn’t told what’s expected of them, it’s really hard for them to be successful. If what the developer does matches what’s expected, it’s only by chance.

Poor technical practices

If you put a good developer on a team that uses poor development practices, it’s going to be hard for that developer to make a good contribution.

I’ve worked at places where they didn’t use version control or practice continuous deployment. Obviously these poor practices can cause a good developer to produce bad work.

Lack of education/culture of ignorance

Some developers are smart but lack knowledge. If care isn’t taken to educate these developers, they often won’t produce very good work.

Some organizations simply fail to provide education to their employees. Others actively discourage it. I once worked at a place where my boss denied a request of mine to buy some books with company money because “you can read that stuff online”.

What a good environment looks like

Order

The best places I’ve worked at have used some sort of development methodology. Usually that development methodology was “agile-ish”, some form of not-quite-by-the-book agile. Even agile done badly is better than no methodology at all though.

When requirements are thoroughly thought out and specified for the developers in great detail before the work is assigned, it makes the developer’s work much clearer. The developer doesn’t have to spend much energy on parsing ambiguities and can instead just focus on the actual implementation work.

Clear expectations

When assigning user stories to developers, I like to include a bulleted list of acceptance criteria in the description for each story. That way it’s trivially easy to tell whether a story is complete and correct. Just go down the list of acceptance criteria and see if each item matches.

The specificity of the requirements should be tailored to the experience level of the developer. Unless the developer is very senior, it’s often a good idea to include not only high-level requirements but also some guidance regarding things like database structure.

I also like to include a UI mockup of the feature along with the story, sometimes even if the story is trivial. Miscommunication is super easy and so it’s better to over-communicate than under-communicate. Visual communication often helps clear up ambiguities.

There are certain other high-level types of expectations I like to set as well. For example, on the team I lead, I’ve set certain expectations around when and how to refactor. (Refactoring is encouraged. We don’t mix refactoring with behavior changes. We perform refactorings right before or right after behavior changes.)

Good technical practices

Things can go so much more smoothly when the technical practices are good.

Where I work, it goes like this:

1. You’re assigned a small story with clear acceptance criteria
2. You work on the story, which could take a couple hours or as much as a day, typically not more
3. You open a PR which is reviewed 1 to 24 hours later (usually more like 1)
4. Your PR is merged and your work is immediately deployed and verified in production
5. You start again at step 1 with a new story

We’re able to move quickly like this because we have a solid test suite and we practice continuous delivery.

Things go much better when we work this way than if we were to try to assign them big projects that would only be verified, merged and deployed weeks or months after they were started.

Good education/culture of learning

When developers are told that their work output is the most important thing, and that “it doesn’t have to be perfect, it just has to work“, then the quality of the work output suffers.

I believe that developers can actually work faster when they’re allowed to take the time to learn how to do their work the right way rather than just cramming things in any old way. As Bob Martin has said, “the only way to go fast is to go well.”

Takeaways

A programmer’s ability to be successful is the product of the quality of the programmer and the quality of the programmer’s environment. I mean “product” in the mathematical sense. A programmer who is “90% good” who is put into an environment that is only “10% good” will produce work that’s only 90% * 10% = 9% good.

If you work with developers who aren’t producing good work, maybe it’s their fault, but maybe it’s the environment they’re in. And if you yourself feel like you’re not producing good work, it might be your fault or it might be that you’re in a bad environment. If you can find a better environment to put yourself in, you might find yourself able to do better work.