I like this video I came across in which Kent Beck describes two styles of designers, lumpers and splitters. Ken describes himself as a splitter and I would also say I’m of the splitter style. I love splitting long complicated methods that do multiple things into smaller methods that do one thing. Other people want to have big giant functions and big giant classes where they can see things all at one glance.
Ken makes an interesting point that “…this is a legit difference in thinking styles. This is one where I’m not gonna say, strictly speaking, my way is better.”
I love this in the sense that I think it’s important to know what your preferences are, and also to accept that other people are going to have legitimate differences in their preferences. My experience is that if I notice that someone is programming with a lumper style. I’ll try my best to adapt to their style and not try to force them to adapt to mine – when I’m working on code that originated from them. I’ll also introduce my splitter style with the code that I’m creating and then try to gauge their reaction to it. I don’t think these are insurmountable differences, that the other party can’t accommodate but it is worth it to be aware of these differences and to be willing to adapt to them.
Explicit and Implicit
I think that the lumper/splitter distinction is related to the explicit/implicit distinction. I’ve noticed that some have a style that is based on writing explicit code that very visibly indicates what is happening. There’s an emphasis on making sure that the code is very specifically described.
Implicit coding can sometimes be described as “magic” or “clever” code. It’s code that does something that isn’t immediately obvious. It’s code that is more concise and doesn’t spell out every detail. It’s code that relies on the reader to make some inferences about what is happening.
I think this is also a legitimate difference in thinking styles and this one I think is more contentious. I think that some people are very in the explicit camp and are less likely to be able to bend over to the implicit side than vice versa. The implicit side will get frustrated with the extra verbosity that explicitness usually necessitates.
Being a Rails programmer who likes Rails, I think indicates that I’m more on the implicit side. I’ve noticed some Rails developers are very much on the explicit side, and they tend to try to avoid using Rails magic. I think the data mapper vs active record debate is a good example of this. Data mapper is more explicit and active record is more implicit.
Similarity vs Differences Perception
Another distinction I’ve noticed is that some people are more likely to see the similarities between things, and some people are more likely to see the differences between things. I think the people who see similarities are more common and I would place myself in this category. People who see differences are more likely to be able to see the distinctions between things and that has benefits in terms of being able to spot bugs and to be able to see the nuances of when a design might not be working. I’ve noticed that people who are sensitive to differences make the best code reviewers. If you get the sense that someone on your team has these qualities they are probably capable of doing some important tasks better than others.
Conclusion
I think it’s important to be aware of these differences in thinking styles and to be willing to adapt to them. There’s no one right way to be, and it’s important to be able to work with people who have different preferences than you. It’s of course dangerous to think that people can be put into neat categories, and even more dangerous to think you are capable of doing the categorizing, but sometimes people are aware of these things in themselves and are open to trying strategies that maximize their unique strengths.