A universal tech code of conduct

Don’t make technical assumptions.
Don’t back-seat develop.
Don’t be a know-it-all.
Don’t sweat the non-software stuff.

These are the universal rules of the tech world. When followed, everyone benefits – junior developer to CTO.

Here’s why we need a tech code of conduct, and how each of these rules help create a positive programming environment with more collaborative spark, less snark.

Don’t make technical assumptions

Any tech team is likely to be filled with an eclectic range of skill levels, specialities and experience. Drew earned programming chops through formal education; Charlie hacked away at home to produce an employable portfolio.

And that’s fine. Welcome, even. A mixed team provides a great opportunity for developers to share knowledge and understanding. However, it also opens the opportunity to make (incorrect) tech assumptions about what a team member knows (or doesn’t). When this happens, communication can break down, and important questions go unasked.

Assuming someone knows something can also lead to embarrassment. For example, Drew asks a question, and Charlie makes a big show of surprise.

Drew: Why are these Laravel methods static?
Charlie: Wait, you don’t know how to work with Eloquent models?

This kind of attitude – centred around tech assumptions – can make your colleagues feel embarrassed or inadequate about not knowing something. In turn, this discourages them from asking future questions.

Don’t backseat develop

Development is all about problem solving — and collaboration is integral to solving problems. When you overhear a problem you can solve, it can be tempting to butt in and offer your solution. It’s helpful, right? Well, no. In fact, it’s the next rule in the tech code of conduct.

Backseat developing is when you interrupt conversations you aren’t part of to give advice you weren’t asked for.

Sam: I’m going for this WordPress theme…
Alex: WordPress? Why don’t you just build your own CMS?

Like backseat driving, backseat developing is often incredibly unhelpful. You don’t have all the information at hand, your advice can be incorrect, it disturbs other team members when shouted across the room, and it belittles the team members discussing the problem.

But sometimes your advice can be helpful. So, if you think there’s a problem you can help with, ask to join the conversation. Get all the information, and include your colleagues in finding the solution. Doing this shows that you respect other developers’ knowledge and points of view. After all, they might have a reason for doing something a certain way.

Don’t be a know-it-all

Whether it’s fact or opinion, being corrected can be infuriating and belittling in equal measure. When chatting with colleagues, then, it’s best to avoid unnecessary corrections, and choose your battles wisely.

Overly pedantic team members interrupt the flow of the conversation, distract from the main point, and steal the attention from the main speaker.

Pat: So, we’ve got this GIF for onboarding screen 1…
Lou: Erm, don’t you mean JIF?

Of course, sometimes it’s important that corrections are made to avoid confusion, misunderstanding or wasted time. So, if a colleague gets something wrong, question whether the error is relevant to the conversation before you correct them:

Could the mistake cause confusion if left uncorrected, or have they effectively gotten their meaning across?
Is the corrected fact directly related to their point, or is correcting them tangential to the conversation?

If the mistake could cause later confusion, and the point is directly related to the corrected information, then you have grounds to politely correct the speaker. Otherwise, don’t be an insufferable know-it-all.

Don’t sweat the non-software stuff

Tensions often run high on the dev floor, thanks to looming deadlines, ever-changing requirements and coding controversy. So, when things go wrong, stress can take over. Unfortunately, stress can make reactions become rash and defensive, as emotion drives responses rather than reason.

Emotionally charged responses often cause unnecessary conflicts. These conflicts then distract from the development problem at hand.

Jean: #&%£!
Jamie: $@!*%!

(Or something to that effect.) If it’s personal and non-product related, don’t bring it to the development discussion. If it is a direct dev problem – bad code, a bug, a security issue – then talk about it with a reasoned, respectful, and logical approach.

A techie’s code of conduct

The universal tech code of conduct is best used as a framework to help you keep life on the development floor as conflict free as possible. This isn’t always easy, and the list of directives could be endless. These four core points, however, form the foundation of a more collaborative tech team.

Note: we originally published this article here: https://dzone.com/articles/a-universal-tech-code-of-conduct