Working in teams will naturally foster differences of opinion—and that’s a good thing. Diverse opinions help ensure all ideas are discussed, problem areas are identified, and the focus of the task at hand is in the right place.

However, things are a little different in the open source world. Open source contributors are passionate—they often give things their all and as such usually have their personalities ingrained in what the do. This happens in the outside world too, but there’s a tendency for contributors to be more passionate about something they’re doing in their hard-earned free time.

Working for an open source company adds its own twist to the mix: Trying to balance out the drive to do what management has asked, with the direction a project is heading. This can be a challenging environment, especially if the company is acting as a contributor to the project and not necessarily the owner.

In this article, I’m going to take a look at the different traits of people who contribute, what their aims are, and how to balance them out when reading all those comments on your pristine and obviously perfect pull requests. People may have a combination of several of these traits, but they’re usually centered around one. The trick is finding out what the person is aiming for and to see if that lines up with the project’s goals.

Genericist / Specialist

This trait is about how usable the project is in any given situation.

A genericist makes sure the project is usable in every situation. This is often accompanied by a very broad view of the scope. Any changes to code will often replace strings with variables, add layers of abstraction, or turn things into plugins—all in the name of making the project more customizable and generic. Though there is nothing wrong with this approach (trust me, I’m a genericist), it often leads to more complex code that takes longer to write and is harder to get right.

The specialist, on the other hand, is all about the specific use case. They will often state that the code doesn’t need to handle those use cases and will often hardcode in variables and tack things onto existing code without making it usable in other situations. Specialists will hone in on doing a specific task well, and in doing so often lead to the more optimized solution.

Balancing this trait when considering comments and pull requests isn’t easy. My experience has shown people will generally write more specifically and comment more generically. It isn’t often that people comment and say, “This code is too generic,” but they may say it’s too specific. Bottom line: think about the future of the project. The genericist wants the tool to be a swiss army knife. The specialist wants it to be a scalpel.

Perfectionist / Conceptualist

This trait is about how the project adheres to standards and practices. Take any task and give it to a group of people and you will get some who do it to a perfect standard, others who middle it, and another group that gets it done in ways you never imagined.

The perfectionist is going to quibble about syntax. They are going to tell you that this is the gosh-darn-rootin’-tootin’-only way of doing something. They will tell you that if you want to do it Right™, then you will do it their way. To be honest, they are usually right. They will also be the people who will look at your code and find the performance issues. Loops you are only running through three times (for crying out loud) will still be commented on as to how to make them six cycles faster. The perfectionist wants your code to be a thing of beauty. They love elegant, highly optimized, standards-compliant code.

The conceptualist, on the other hand, is far more keen on getting something that works into the code base. In the lifecycle of “Make it work, make it good, make it fast,” they are squarely at the “Make it work” phase and are not interested in making it adhere to every single complaint that the perfectionists’ built-in linter has to offer. Of course, the focus on getting something work rather than getting something that is beautifully succinct often leads to the conceptualist beating the perfectionist to the punch.

Balancing this trait can also be tricky—it depends on what the conceptualist is proposing. Sometimes time can be a big factor, and allowing code that isn’t up to the perfectionists’ standards isn’t necessarily a bad thing. Sometimes a quick fix is necessary. Sometimes proof-of-concept code is also a must and there isn’t the time or resource to make the solution perfect. Perfectionists can also drive conceptualists crazy, as their adherence to perfect coding guidelines can just seem like it gets in the way. However, when it comes to readability, 99 times out of 100 the perfectionists code will be far easier to read and maintain. Bottom line: think about the time constraints and whether you have the resources to make it better later on. The perfectionist wants the sharpest, straightest knife edge possible. The conceptualist isn’t afraid to use something that looks like a knife to get the job done.

Adventurist / Conventionalist

When it comes to solving problems, there are those who love to take it as an opportunity to try out new things. The adventurist is that person. The no-fear, future-thinking, raise-the-roof adventurist is always looking at using the latest technology, the newest syntax, and the fanciest documentation strategies you’ve ever seen. They want the project to move forward and be “with-it,” but there is also an innate desire that they have to move on beyond the boundaries and try new things. Why not? It’s hip! These adventurers will often propose using libraries that you’ve never heard of, like mustardandcheese or protactinum, all in the name of science. Of course, when it all goes wrong and the library isn’t mature, where do the fingers point? That’s right. I’m looking at you, adventurer.

The conventionalist, on the other hand, wants to stick with the tried and trusted robust technologies. It’s not that they’re boring, they just like the predictability of going with what they know. They want to be sure it’s going to work, and by using the same technology they used last year (or the year before that), they can assure this.

Balancing this trait is, yep, you guessed it: tricky. It’s all about how much time you can spend getting something to work and potentially cleaning up problems as new issues are discovered with the new library/tool/codebase. The adventurist will often tell you it’s a win-win, that nothing can go wrong. That’s when the conventionalist will start to shake with fear. Bottom line: do you have the time to spend learning the new technology? Does the rest of the team? Do the benefits that it brings outweigh that initial learning curve? The adventurist will want to use molybdenum steel alloys that no one has ever used before for the knife blade. The conventionalist will stick with the same materials they have been using for years.

Putting it all together

This article is not about boxing people. It’s not about making sure that people are classified in their little boxes and never move out of them. It’s certainly not about how to treat people. What has been presented are some mindsets common to people working in code-based environment. Heck, it’s even common in non-code-based environments. It’s been presented as a tool so that you can hopefully see the other side of the argument and understand where a person is coming from when they write the comments and code that they do.

A person is never going to be just one of these traits. They are always going to have a mixture. That mixture will also change depending on the project they are working on, the time they have, and their level of understanding. Personally, I’d call myself a pretty heavy genericist/perfectionist with a midway adventure/conventional attitude. Understanding your own traits can help you understand how others react to your code and comments as well as recognizing these traits in others.

In the open source world, these traits are often much more exaggerated. When people are putting their own time and effort into projects, they feel invested and really want to make their voice heard. So the next time you’re reviewing or writing the comments, try to put yourself in the shoes of each personality type to understand why things have been written the way they have. It’s all too easy to smack a conceptualist down with perfectionist views, or drive a conventionalist crazy by always suggesting adventurous ways. Be sensitive and balance all the viewpoints.