Holistic, Agnostic & Specific at solving problems
How these characteristics fit into the modern role of software engineering and elite software teams
Solving a problem can be done using different tools, knowledge, and a set of practices. Depending on the complexity of that problem, is how you will start to figure out how to solve it. The way it can be done is understanding the problem from the beginning, thinking in the potential benefits and impacts of solving that, and translating into a solution.
It happens the same with software development — you need to cover a wide range of steps in the problem-solving process, and you need to jump into different layers of abstraction, implementing the most suitable and feasible tools to accomplish the objective of that particular problem. Many problems a developer wants to solve can be done with particular programming languages, existing tools, and APIs. The one in charge of solving can decide what is the most suitable programming language, with the right set of practices for that particular challenge. To solve problems, it is not enough to say that you know a particular tool or single practice. Being Holistic, Agnostic & Specific at this moment of the software discipline is distinguished and highly-valued.
Holistic in the entire process
Holistic means coverage of the different steps on the problem-solving process. From the business problem or opportunity, translating into the architectural pieces, identifying where and when to optimize, executing and deploying the solution.
It comes from understanding why the problem I want to solve is really a problem,, to whom, and why it is worth tackling it. From the beginning, it helps to empathize and clearly understand the dynamics around that problem, and start thinking of great technical ways to approach the problem. Even when building the tech solution, the early involvement will be resonating and should be part of the thinking process to remember what is crucial to solving that problem.
Agnostic in technology implementation
The execution of the technology can be done in a different set of paradigms and languages, depending on the problem to be solved. It is not enough, again, to say you will solve all potential problems with a single language all the time.
Every programmer knows there are programming languages with a specific purpose; so there are general-purpose languages. But when it comes to choosing the right language, you will define which is the best one depending on the proper attributes to solve the problem: flexibility, manageability, maintainability, writability, resilience, and so on. What is needed in the tech solution in the short and long-term to make sense from a product, business and market perspective? Those decisions will impact the potential technical debt to be handled and administrated in the product while growing.
It is not an easy task to be a polyglot, touching every new technology appearing in this rapid industry. However, there are ways to shortcut the path: talking to other colleagues, reading, exploring, testing. This talks a lot about a curious engineer, as part of the core value of the problem-solving process: curiosity to know how to solve this particular problem.
Specific to the served industry
Using the same language and context as the business counterpart, understanding the dynamics of the industry where the software piece is going to be implemented. Being empathic while deploying technological solutions becomes a differentiator, since the perspective and needs from users, customers and the market itself, are considered as part of the problem-solving process. Also, the understanding of the business or organization implementing the solution makes the software engineer introduce elements to fit into the proper business objectives.
The trust environment that can be created is powerful. An engineer capable of jumping into different vocabularies and contexts may be proactive enough to generate other paths and alternatives to the subject problem. Being able to align to that industry context, will help to not only solve the problem in the present time but think about how to adequately grow that solution.
A merge of the above
The combination of these characteristics will be a definite mix for any software developer and any software team executing technology to solve problems. Those teams unable to implement a solution without any constrains in terms of the holistic process, understanding the industry where the solution is supposed to be used, and choosing from all the available tools, will be limited and might not reach the best long-term potential solution from all different angles.
Being holistic is though, more for a software developer. Being one myself I typically wanted to be all the time coding, in front of the terminal seeing how thru that canvas you will create a solution for the problem. This is not enough to solve the entire problem. You need to grasp every aspect of the problem, and being able to see it implemented to polish the solution and enhance the outcome.
Being agnostic is demanding, more in an industry that changes every single month or even every week: new practices, programming languages, frameworks, and tools. As an engineer, you need to be curious and passionate enough to forget (for a while) all your current knowledge and being open to reading about a new tendency or a group of avid cool kids working on a new fun project, and maybe you might think of joining them too—betting it will be the next most used (loved) programming language on the world.
Being specific requires empathy, and a high level of learnability to understand the factors involved in the industry where the solution to be built is supposed to be used.
Nonetheless, acquiring these capabilities both individually and collectively is powerful. There should be a homogeneous conversation, where the majority of people involved can understand the others' perspectives and have a strong opinion about the design of the solution. There might be some concentration of accountabilities, but the most common language the team can share the better.
Users and customers will be the most benefited from this combination—it is not exorbitant to think that the economy itself when you realize that we still fail as a discipline in building the right things, right. The silos and misunderstandings that those teams will be evading are crucial for productive and meaningful work, therefore all parties will see the progress and benefit.
Building software has never been easy. These are the kind of challenges the discipline demands today. Problems today are harder to solve, so the approach to them should have a versatile intention and purpose behind it.
