A lot of press lately has been addressing the downsides of coder culture — for example, A. facebook / google / twitter’s latest press releases revealing that less than 20% their technical workforce is female; B. Tim Evko’s discussion on battling constant community pressure toward Information Overload; and C. a recent rant on the “If I have to explain this, you’re too stupid” mentality. These issues add up to a proliferation of barriers toward so-called “newbs” — people who want to enter the coding community.

Coders have hiring power and with it the ability to admit new code community members on their own terms. Often, although there are thousands of companies with code teams, those somewhat arbitrary terms can be eerily similar: “Would I want to have beers and shoot nerf guns with this person?” (one cause of “A”), “Is this person up on every single new library in every single possible language relevant to this job, as if their entire life had added up to this moment?” (“B”), or “Am I going to have to actually explain anything to this person, because if so….” (“C”).

One of the most challenging of these barriers is what I like to call the “Nothing a newb can do is good” mentality. Or, more specifically, “Nothing a newb can do impresses me, because I can find a hole in it.” To be fair, many sectors have this kind of snobbery — academia is famous for it. But because of the urgent need for new blood / ideas in the tech world, our lack of ability to reward new developers is a particularly profound example of shooting oneself in the foot.

To be fair, many, many coders enjoy teaching and mentoring. They are the people who volunteer their time to staff the open source repositories and lead tech meetup groups throughout the world. But even among this elite group of patient develoeprs, very, very few can look at a junior developer’s project with anything near genuine admiration. People love to play advisor, but few want to be an admirer.

Let me give an example — say a new coder had somehow, impossibly, in their first month of coding, created an app that would save the planet, plunging us into a permanent state of world peace and 100% clean energy. What’s the first thing that you as a senior developer would say to that person before seeing or testing their project? Let me guess — you’re thinking, “Is it responsive?”

To put this in perspective, someone who knew nothing about our world has entered it and learned ~5 completely foreign technologies (perhaps JavaScript, HTML5, CSS, NodeJS, MongoDB). They then taught themselves how to use EACH of these 5 technologies WITH the other 4, had a grand-slam idea, and typed from scratch said idea, thereby typing a novel’s worth of encoded words in 50-60 separate but intertwined files. Let’s not forget testing and debugging. This person did this FOR FREE. For fun.

Or, put another way, what if a friend had spent a month perfecting his roast veal, cooked you some, and was eager for your opinion. Do you really want your first reaction, before tasting it, to be, “I hope the wine in the veal sauce is authentic French Merlot!”

Of course, we’re hoping the junior developer will say, “YES! I learned how to build everything 100% responsively in my first month of coding. Plus, it’s all ADA compliant!!” But in the likely case that the developer doesn’t say that, we’ve made them feel about an inch tall in the amount of time it takes to change a channel. And now the conversation is over.

Seriously, is “Is it responsive?” really the first words you want to come out of your mouth, before you’ve even seen the product? Can you step back, suspend your criticism for just one second, and realize that someone has just completed a shit-ton of work?

It’s not about giving false praise — it’s about choosing a response that opens the conversation wider instead of shutting it down. What about, “How does it work?” What about, “Tell me more.” What about, “What features did you include?” Hell even, “Can I see?” would be a conversation-opening response.

I understand our community’s tendency toward the blase “Nothing you can do is good enough” response. It’s not just social awkwardness. To be a successful developer, you have to teach yourself to be relentless with your own code. No matter how great it is, the perfectionist in us always sees something more that could be done. Sometimes, we forget to turn that ruthless perfectionist off when we leave work in the evenings.

In the last two months, I built an app with a friend. It’s not rocket science. It’s not perfect. But it was a lot of work, and it’s beautiful, and it’s mine, and I am so proud of it.

It’s been tough to get useful feedback. Fellow coders start playing hardball the moment I mention it, as if building an idea meant I had drawn a target on my face. “DIRECT SKEPTICISM HERE.” One interview started and ended with, “What’s another way you could have built your email fetching?” Bam. We talked for another 10 minutes, but it’s pretty tough to come back from, “I don’t know” on your first interview question. And of course, all of the, “Does it do X?” (If I say no, does that mean you’re not going to try it?)

Is it really true that the only way we can take ourselves seriously as developers is to provide only skeptical feedback? Is 100% hole-poking feedback really an objective message?

The code community can keep acting nonplused. I’m going to keep developing, anyway. But wouldn’t it be nice if, just for that one moment…?