So how do we get everyone on our teams to that place?

How do we help others get out of the dark, frustrating place that is the local minima of suckiness that is the expert beginner, past the stars, and into the cloud?

And, how can we help ourselves become better developers?

There are three things that I’ve noticed in my own career that developers need to become better:

• the room to make mistakes
• repeated exposure to best practices
• understanding how to ask good questions, or learning how to learn

we now call it psychological safety.

The simple story is that, in a good, productive software environment, you have the room to mess up. The apocryphal story about how this works is the one where the junior developer breaks production, costing the company thousands of dollars. After he sees this, he starts putting everything on his desk in a box. The CEO comes up to him and says, “Where are you going?” “I just cost the company so much money, I figured I was fired.” “We just paid thousands of dollars to train you. Why would we let you go?”

Bill, who was working on (ostensibly) a missile defense system, with instructions written in machine code. He got to a point where he thought he figured it out and asked Marilyn to review his code.

Code review was still in the nascent stages in those days, and Weinberg writes, “His value system, when it came to programming, dictated that secretive, possessive programming was bad and that open, shared programming was good. Errors that might be found in code he had written were simply facts to be exposed to investigation with an eye to future improvement, not attacks on his person. “

Marilyn found 17 bugs in the 13 lines of code. Instead of fuming, Bill’s reaction was to go around and tell everyone how impossible this code was, and how hilarious it was that she had found 17 bugs. While he was doing that, a few people joined in, for at this point, it was a game, and found a few more bugs. A scenario that could have ended with Bill accusing Marilyn of blocking him or of Bill hiding his code because he thought others would think he was a bad developer ended up much better because things were out in the open.

They also promote people who value all of these skills: patience, mentorship, and people who demand technical excellence while acknowledging what it takes to get there. Who you promote will tell your org chart how you want the organization to look, so it’s important to spotlight people who share these values and set the tone for the organization.

There is a way, though, to tell who those people are in your organization, and to try to work with them if at all possible. Good senior developers ask lots of questions to get to the root of problems, and usually they ask them publicly so others can find out the answer. Good senior developers figure out how complicated systems work . Good senior developers carefully review PRs and give feedback, and they also answer questions . chances are you know who the good people in your organization are, because, if you have a question, they’re the first person you think about when asking for help.

Learning how to ask the right questions at the right time is one of the fundamental skills of being a developer. Formulating the right question takes a lot of time, a lot of trial and effort, and a lot of tinkering with different solutions until the question even makes sense.

This is why an environment where it’s ok to ask stupid questions is important. One of the best ways I’ve seen of dealing with this is having a #dumbquestions channel on Slack. Another is having the Good Senior People ask seemingly simple questions in meetings to empower others.