There is this great article about how Kotaku made a post about clever tricks used by game developers and how a number of developers criticized it. Why bother making a post explaining something so basic? Who cares? Apparently lots of people did. What one person considers basic is actually quite clever and interesting to another. Why would anyone want to mock a person’s curiosity? Everyone starts off not knowing much and getting that knowledge usually requires having someone willing to explain.

More importantly, it is nonsensical to expect people to understand how difficult certain things are while criticizing any attempt to explain it to them.

This happens outside of game development as well.

I’ve met a lot of software developers who have a similar attitude. They would prefer that everyone blindly trust their judgment. Developers are the smartest after all! Explaining the reasoning behind technical decisions simply takes too much of their infinitely valuable time.

And then there are the people who view developers as nothing more than grunts to implement their grand vision. “Just build what I tell you! I don’t care about the details.”

Both of these attitudes result in teams that work poorly.

I used to have that harmful developer attitude towards others. It is easy to fall into that sense of tribalism. The “us vs them” mentality is an addicting one to have. In many ways it’s even fun to complain about “them”.

Eventually I realized that my behavior was causing my coworkers distress. Strangely enough, I considered them friends outside of work hours. Due to guilt, I decided to start treating them like friends during work hours. If they had a question or needed an explanation, I took the time to provide the best answer I could. It didn’t matter if it took an hour of my time when I had work to do. It was worth it for my friends. They also took the time to return the favor.

What started out as the desire to be helpful ended up being an extremely effective team dynamic. By communicating the way a real team should communicate, we ended up understanding each other a lot more. The decisions we had to make were made quicker because we had each other to help remove uncertainty around those decisions. There was no internal debate on how other people would react if X was done. It was easier to just have a conversation with those other people.

Not only were those decisions made quicker, they were better decisions. We came up with ideas that none of us would have thought of if we had all stayed in our own professional and tribal bubbles.

The time it took to explain things wasn’t wasted time. It was an upfront investment in being able to work more efficiently later.

One of the reasons I built professorbeekums.com was to help folks make that investment. The lessons provided will help everyone who works with a developer learn about how software development works. That knowledge serves as a strong foundation for communicating and working effectively with developers.