Blog
Solving a problem can be done with different tools, knowledge, and practices. Depending on the complexity of that problem is how a software engineer decides how to proceed. For effective problem-solving, it is important to understand the problem from the beginning, thinking about the potential benefits and impacts of solving it, thus easily translating it into a solution.
The same with software development. Several steps need to be made during the problem-solving process before jumping into different layers of abstraction. Additionally, implementing the most suitable and feasible tools is vital to solving a particular problem.
Many problems software engineers face can be dealt with particular programming languages, existing tools, and APIs. Before starting, it’s important to choose the most suitable programming language with the right set of practices for that particular challenge. To solve problems, it is not enough to know a particular tool or a single practice. Being a Holistic, Agnostic & Specific software engineer is distinguished and highly-valued.
Holistic means being able to cover the complete steps in the problem-solving process. From the business problem or opportunity, to translating into the architectural pieces, to identifying where and when to optimize, and finally, executing and deploying the solution.
It starts with understanding why the problem is a problem, to whom it presents itself as a problem, and why it’s worth tackling it. This process helps empathize and clearly understand the dynamics around that problem; additionally, it helps to start thinking of great technical ways to approach the problem. Even when building the tech solution, the early involvement will be resonating why it is crucial to solve that problem.
Implementing technology can be done with several sets of paradigms and languages, depending on the problem. It is not enough to say you will solve all potential problems with a single language every time.
Every software engineer knows that there are programming languages made to solve specific purposes. 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.
To choose the right language, it is important to analyze what is needed within the tech solution, short and long-term, to make sense from a product, business, and market perspective. These decisions will impact the potential technical debt to be handled and administered in the product while growing.
It is not an easy task to be multilingual. Getting to know and being a pro with every new technology coming out in this rapid industry is impossible. However, there are ways to make it easier: talking to other colleagues, reading, exploring, testing. This speaks well about a curious software engineer, as part of the core value of the problem-solving process: curiosity to know how to solve this particular problem.
Being empathic while deploying technological solutions becomes a differentiator. This is due to the perspective and needs of 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 business objectives.
The trust relationship that can be created is powerful. A software engineer capable of jumping into different vocabularies and contexts may also be able to generate new paths and alternatives to the 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.
The combination of these characteristics are imperative for any software engineer and software teams executing technology to solve problems. Teams unable to implement a solution without constraints, understand the industry, and choose from all the available tools, will be limited and might not reach the best long-term potential solution.
Being holistic is though, more for a software developer. Being one myself, I typically wanted to be coding nonstop, in front of the terminal seeing how through that canvas you can create a solution for the problem. This is not enough to solve the entire problem. You need to grasp every aspect of the problem. Seeing the code implemented, allows you 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 that you know and be open to new trends or a group of cool kids working on a new fun project.
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. For this, there should be a homogeneous conversation, where the people involved can understand others' perspectives and have a strong opinion about the solution designed. There might be some dispute, but the most common language in the team should be the best choice.
Users and customers will be the most benefited from this combination—it is not outrageous to think about the economy 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 kinds of challenges the discipline demands today. Today, problems are harder to solve, so the approach should have a versatile intention and purpose behind it.
Looking for a holistic, agnostic and specific software development team? Let’s get in touch!
