There’s often more than one way to solve a problem. Engineers tend to be pretty opinionated about solutions, too. Whenever I see disagreements in design, I typically notice two competing stances: the pragmatist and the purist. Identifying these approaches helps to understand how others think and fosters healthier team collaboration.
A purist is one who focuses primarily on the correctness of a solution. They typically seek a systematic, comprehensive, and verifiable design. A pragmatist, however, favors practical, expedient solutions. They are okay with a solution so long as it works.
The table below gives some perspective on how these two perspectives may differ:
|Focus more on what is correct||Focus more on what is expedient|
|Spend more effort on design and the “big picture”||Spend more effort on implementation|
|Very picky in code review||Less picky in code review|
|Interested more in white-box code quality||Interested more in black-box code quality|
|Favors strong design patterns, even if they are complicated||Favors simpler design patterns, even if they have less-than-desirable consequences|
|Prefers to redesign than to hack||Prefers to hack than to redesign|
|Good at handling long-term problems||Good at handling short-term problems|
|Views software development as an art as well as an engineering practice||Views development primarily as an engineering practice|
|Aligns well with academia||Aligns well with business|
|In test automation, better for framework development||In test automation, better for test case development|
These descriptions are not absolute: many people fall somewhere between the poles of purist and pragmatist. However, most people tend to exhibit stronger tendencies in one direction.
Personally, I tend to be a purist. If I need to get a job done, I feel shameful if I cannot afford the time to do it fully properly. However, I often find myself working with pragmatists. That’s not a bad thing – I recognize the value in each perspective. There is much to learn from both sides!