Other developers are not like me. This is something I have to tell myself regularly. I’m reminded of this by the simple numbers for Wordpress usage. 16.3% of websites are powered by Wordpress and it accounts for 54% or the CMS market. While we can argue how these numbers are measured we can’t argue that A LOT of websites are built on technology often railed on in tech blogs.

I find this even more interesting when it comes to creating development tools, documenting methods, and advocating use of the new hotness. All too often this happens in the bubble of people who think like us and do thinkings in a similar manner. We wonder why others struggle with what we are suggesting. We wonder why something isn’t catching on. Sometimes we even write off these other developers as incompetent because they suggest using some piece of technology we’ve grown to despise. None the less, they keep trucking along, thinkings change slowly, some camps move further apart, and may good ideas go stale.

Part of the equation we often miss is that other developers are different and how those differences matter. They have different needs. Their customers have different needs. The list of tasks they have to do for their job is different. The priorities they have are different. Understanding these differences can help us make better all around products and move the Internet in a better direction in a healthier manner.

Differences of Note

After talking to a lot of developers in many different circles I’ve found a few differences that are worth noting and understanding. They provide us with some keys into others making it easier to explain things or even know what to explain.

• The specialist vs. the generalist - A simple case is someone who only works on JavaScript compared to someone who writes JavaScript along with PHP, dealing with deployments, working with clients, managing others, or any number of other tasks. The JavaScript developer is going to dig into the nuance of patterns, play with different techniques, quote Crockford, and be really into it. The generalist will likely just want to touch enough JavaScript to get the task in front of them done.
• The 501-ish developer vs. the I live for this developer - Some developers just want to get their tasks done quickly, easily, and meeting the needs in front of them. At the end of the day they disconnect from developing and go do something else. There are other developers who don’t disconnect. Their hobby is what they do for work. In their off hours they are doing other development practices. It’s not just a job, it’s a passion.
• I love change vs. I avoid change. Some developers love change. Sometimes they even like to stir the pot to inspire change. Others what to stay with what’s been tried and true for them. There are a lot of reasons that cause this. For example, someone may want to avoid change because they don’t have time to learn all the new stuff while meeting the needs or their clients of project. Someone else may love change because they are easily bored and change keeps them interested.

Just looking at these three dimensions we can see we have developers that can range from generalists who don’t develop outside working hours and don’t like to change their development practices all the way through specialists who live for this stuff and are always changing what they are doing. That’s quite a range.

Where Things Can Go Terribly Wrong

I’ve watched stuff go wrong time and time again. Frustrations start to show up. And people wonder why it didn’t work. Unfortunately, technical problems are usually the easy ones to solve.

Let me give you an example of something gone terribly wrong. Imagine a JavaScript developer on a team of non-JavaScript developers. The JavaScript developer does a lot of the front end development while the others do back end development, APIs, deployments, and the other parts of the stack. Some of these developers do some front end work. To get better overall JavaScript would it be better to teach them all the intricacies of front end development or to make it easier for them to know very little about front end development but output good end products through the use of documentation and helpers.

I’ve seen and been told that the rest of the team should learn the latest patterns. That it’s in their best interests. Trying to make non-JavaScript developers into JavaScript developers in addition to what ever else they have to do can prove to be fairly in-effective at best and piss people off at worst.

Picking Your Goal

With such a wide range of developers it can be important to pick your goal. Looking at the this case is the goal to make the rest of the team write better JavaScript or to make the output JavaScript be more performant, better to manage, or something else? This is important because you need to take the goal and mix it in with a good dose of the difference in a group of people to come up with a productive path forward.

In the open source world this can be harder to do. Continuing this example, imagine a handful of JavaScript developers get together and want to make a change to a product. They think like JavaScript developers and make the change they want to see. It gets released and then the complaining begins from all the people not like that first group that envisioned and built it.

Making It Easier On Yourself

Failure you can learn from has lead me to a number of tips and tricks that help me with these occasions come up.

1. Learn about the others affected by what you’re doing. I prefer having a beer or coffee with some others in the affected group and talking frankly about the subject. Learn what they think and why. How it impacts them.
2. Make it easier on others. Once you understand their needs, questions, and problem write documentation they would want to read. Present on it. Do a video demo. Alter the concept to make it easier for them. Provide a helper library. Or, if the idea isn’t going to be helpful consider scrapping it and sharing why. Or, making it pluggable so you and they can both co-exist.
3. Plan for the hard stuff. Making technology changes is often the easy part. The hard part is working with others, explaining yourself, answering support questions, and all the not-as-fun-as-technology stuff. Plan for it. That may mean getting others to do the dirty work or setting different expectations.
4. Be kind to others. Being a dick does not help others accept what your doing or help them want to follow you in the future. Treating others with respect and kindness goes a long way.

The next time you want to make or support something that’s a change consider the implications to those actions. They may be more than meets the eye and there may be some things you can do to set yourself up for success.

Note: If you think any example here is about you it’s not. Many examples have influenced me but none of those are directly reflected in an example.