3 easy ways programmers earn their teams' trust

Foreword 

I'm a producer, and the following has been written from my perspective. The programmers that I trust completely follow the principles outlined below. That is not to say, this is the only way to earn respect as a developer. These are just a few trends I have noticed among respected senior developers.

This article is targeted more towards junior developers, programmers, software engineers, etc. It is likely the senior guys already understand most of these concepts. That is not to say more seasoned devs can't benefit from this article. In fact, this may serve as a useful teaching tool for the greener engineers you are trying to mold and grow. 

Why does this even matter?

Programmers can have it rough sometimes. Ok, that may be underselling it. Outside of your development bubble of fellow software engineers, it is highly likely that no one knows or understands what you do. Many of your producers, artists, and possibly designers think that you simply traded in your wand and robe for a mouse and keyboard, and therein lies the problem. 

All too often, these people rely on you to build a framework that supports their needs without understanding the depth or complexity of the task they have asked of you. There is a psychological term for this called the Dunning-Kruger Effect. In essence, it's this interesting phenomenon where someone who has very little understanding of something thinks they know far more about it than they really do. These people have never written a line of code in their life. Simultaneously, experts of the very same subject matter believe complex tasks or knowledge regarding that thing to be far simpler than it really is. These people have 10 years of applied knowledge under their belt. In between these two poles is what is referred to as "the valley of despair." This is where a great many of these green engineers live. Here are some helpful tips to make those living on each end have a little more faith in your ability. 

1: A.L.O.H.A.

Honestly, this acronym applies to everyone on the team. It stands for Ask, Listen, Observe, Help, Ask Again. This will do wonders for how accurately you implement requested features. Ask what the person wants, whether it's an artist, designer, or someone in marketing, you will run into someone that doesn't accurately convey what they want or how they want it. Then actually listen. Look up some reading on active listening and put that into practice in these moments. It can be difficult, and it can leave you exhausted (especially during a lengthy design review). That said, it is so very worth the little bit of effort it takes.

In between listening and observing, there will probably be some implementation time. Once a feature is in, observe how people interact with what you've built. We're in an age where a lot of devs are coding on a laptop, there's nothing that should keep you tied to your desk and not sitting next to someone while they play through what you've made. While you're sitting there, help them if they get stuck or want to test something specific. Then most importantly, ask again. "How can I make this better?" is always a great one if you aren't sure what to ask.

2: Mix backend and frontend work

Once upon a time I worked on a project where the dev team spent about three months building very important backend functionality that absolutely needed to be built. During that time, all of our technical artists decided to use that time to polish art assets by optimizing rigs and skeletons. Unfortunately, even though the work needed to be done, it wasn't visually demonstrable. The result was more than a few team members and executives thinking that nothing was getting done.

This could have easily been avoided if say, while a build was compiling a developer implemented the updated music files or plugged in the new font library that had been sitting for a week. The point is, break up your workload into buckets based on difficulty. While you spend a week or more grinding away on that complicated client-server issue, be sure to knock out some of the low hanging fruit that has been assigned to the sprint as well, especially if it is an asset swap and you already have the new art/audio. 

3: Explain everything using simple language

More than likely at some point during your career, you'll be asked to do something that is laughable. While I would urge you not to blatantly laugh at someone's proposal, some suggestions may simply be too outrageous to avoid doing so. The more important thing is that you take the time to explain why it is either A, impossible, or B, very costly. Avoid using developer specific language so that the content of what you say can be understood. Quite often you may need to move forward with a design decision that will take you several additional weeks to implement. When that happens, let everyone know why.

Your producer, scrum master, etc. will need to explain why the schedule has been bumped. If they can't understand how complex something is and are unable to explain it to the powers that be, you may end up crunching to get that feature done. If you find your producer asking lots of questions and taking tons of notes, but still not getting it, ask who they need to let know. You can even offer to accompany them to that meeting to offer the explanation and answer any questions that may arise. This also has the added benefit of having people higher up the ladder start to recognize you.