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:
| Purist | Pragmatist |
|---|---|
| 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!
Automation Panda 
4 comments