As developers, we love talk of clean code and nice, friendly code bases. We lament if our higher-ups don’t share our vision of a codebase that resembles a sunny day in a grassy meadow with the birds singing in the trees. Who’s right in this situation? Everyone is probably right… and probably wrong.
Before I bore you with yet another “it depends”, let’s think about why there are different viewpoints on this issue. The obvious answer is that many times it’s a matter of context — people in the business might not do a good job of explaining why delivering results is so valuable to the business, and development teams might not do a good job of explaining why having clean, maintainable code is going to help them deliver better and faster results. I don’t think you need a blog post to tell you that.
I had a fascinating conversation over Thanksgiving about why it is that we have these disagreements. Turns out it’s not always just a matter of context, it also has to do with your personality.
There’s an assessment out there called the Strength Deployment Inventory (SDI). You can read about it if you want the details, but the gist of it is that there are 3 primary ways that we are motivated and deal with conflict, and we all have varying degrees of each motivation.
- Performance-oriented – you have concern for task accomplishment and organization of resources to achieve results
- People-oriented – you have concern for the protection, growth and welfare of others
- Process-oriented – you have concern for well-thought out approaches, order, individualism, and self-reliance
It’s possible that you have some or all of some of these traits. There’s no right or wrong here, but it’s really important to understand the way people think (and how you think compared to others).
For example, many managers are performance oriented, and that’s part of what draws them to that role. But many developers tend to be process oriented. Herein lies the seeds of conflict, unless we can try and understand where each side is coming from. Going back to my conversation that I was having, my extremely process-oriented brother-in-law said that even though he knew that sometimes he had a tendency to not be focused enough on results, it was very difficult for him to not write clean code or do a “good job”. Perhaps he needs to do a better job of seeing the importance of results, but I don’t think we should quickly dismiss this as a weakness.
It all comes down to what strengths you need on your team. If you’re developing a smartphone app for a startup, results are pretty much all that matters. But if I need to write a billing system, I want my brother-in-law on the team because we will take full advantage his process-oriented strengths and we need his level of rigor in order to ensure that costly bugs aren’t introduced.
This thought process is not often reflected in job listings that list years of experience and knowledge of various frameworks as job requirements. In reality, whether or not you can adequately explain what an Angular directive is probably very insignificant compared to other innate strengths of the candidate. In my mind, the ideal goal should be to find someone that has the specific strengths that you are looking for so that you can take advantage of the things they are naturally great at. Sure, knowledge of frameworks is important, but it’s much easier to teach someone a framework than it is to change the innate strengths and weaknesses of a person.
We should work really hard to become aware of our weaknesses and improve on them, don’t get me wrong. But if you want to harness the true power of a person, find out what their strengths are and cut them loose in an environment where they can take full advantage of those strengths.