There are often multiple ways to resolve a problem. Engineers tend to be pretty opinionated about solutions, too. There are disagreements in design. Generally, the two competing stances are the pragmatist and the purist. Identifying these approaches enables understanding how others assume and foster more healthy team collaboration.
At the heart of the historical development of computing is the age-old philosophical impasse between purist and pragmatist approaches to technology, which is particularly pronounced in software due to its seeming near-Platonic ineffability.
Satirically, not even in the world of business, the social environment known for its rather pragmatic cosmic view of these zones is immune to this debate. Software program developers, managers, and data scientists have been skilled at one factor or another, the tension between individuals fostering a methodology or style and people who tend to pick an eclectic method.
The famous debate
There is no philosophical undercurrent to these concepts because they are self-explanatory. By purists, we suggest traditionalists or human beings who have a nicely-defined worldview and whose values and behaviors reflect that world as intently as viable. Imagine a software developer who is a hardcore proponent of an agile or waterfall methodology, unwilling to compromise on their ideas.
Pragmatists, on the other hand, are people who have a bendy worldview. They are much less interested in following a way and are extra focused on the outcome. If we had to describe their core ideas in one sentence, it might be “whatever works.”
But the reality is seldom so smooth and easily defined as opposed to considering this distinction as an aspect of a coin. It is greater apt to think of it in terms of a continuum. Most of us are not hardcore purists or pragmatists. We have got a chunk of both.
Some of us like the shape of methodologies, while others experience the liberty and creativity of a more incredible freeform approach. Regardless of the case, most of us are more than inclined to compromise given the proper context. Unfortunately, this is no longer the case, which is why we will face a dead end once in a while.
When considering methods
It is assumed that when the journey as a software developer begins, the team usually becomes stumped on the first project because they might have a problem that is not smooth to model with an item-oriented technique. So there is more than one solution, which requires a piece of imperative programming, but the thoughts got down because that was not a part of the employer’s style.
It must not even be a programming paradigm. Waterfall or agile proponents may be as inflexible in their positions as this business enterprise changed with its software program development method.
There is a myriad of motives for why this happens. Some corporations have invested so much effort and time closer to knowing a particular technique that they locate themselves making use of it for the whole thing, even though the method was never initially designed with that intention.
Humans are creatures of culture and habit; societies are constructed on the inspiration of rituals. And with this, it is implied that civilizations own family gadgets, consisting of organizations.
An organization’s identification is described in part with the aid of its practices and traditions. Frameworks and methodologies offer a common language shared between all individuals. Suppose those are semantic shortcuts—ways for us to fast proportion information with folks sharing our reference frame.
While we act outdoor that worldview, communique becomes more complex, it is harder to get the point across, and we run the risk of breaking styles or disconnecting from the network altogether.
Pragmatic software developer
A software developer builds their project on the idea of pure pragmatism; if it works, it goes. We should consider that we will not be around all time to write code, particularly for others. As such, our work cannot be distinctive. It has to speak cause; it requires a structure that others can observe. Sadly, that is just now not possible.
Pragmatists are not masters of chaos; they consider that finding the solution to a problem is more significant than respecting hard and fast-defined norms or traditions that might be constraining.
Possibly the most prominent example of pragmatic developers is individuals who practice hybrid methodologies, blending the structure of the waterfall method with the fast shipping and user involvement of agile traditions. Senior developers are more liable to experimentation and rely less on traditional techniques.
See how most individuals who work with Clojure (a Java-based, totally functional programming language) are senior developers bored with working with object-oriented programming.
Final Thought
As it is known already that contrary forces are not counterproductive; however, as a substitute, after they locate the proper stability, they enhance each other.
Pragmatism and Purism are not opposites; they feel that one approach does not avert or invalidate the opposite. Sticking to your techniques builds shape, and attempting new solutions pushes your limits.
Conclusively, understanding the cost of every method and promoting a lifestyle that values both is, in our opinion, an excellent feasible way to foster a flexible organization with a robust core that can adapt while keeping its essence.
