How to Become a Better Problem Solver With Software Development?

The new trend in the market now is that every software engineer has to be a great problem-solver, well, it’s not that new though, the difference is that some time ago we had to solve mostly code problems, now we have to solve all kinds of problems, therefore to become a better problem solver is a key skill to software development.

However, if we think about the problem-solver mindset, it’s one of the most valuable skills every software engineer can have. There will be uncommon problems in every project and the skill of analyzing and understanding the problem and being able to elaborate an optimized solution for it is something that brings great value to companies and projects.

But how to become a better problem-solver? There are many ways where we can achieve this, we can solve different problems and gain expertise and experience, and we can get exposure to a great variety of technologies, troubleshooting them to understand the tools that can be used to solve the specific problem.

The types of problems that might happen in a company are usually, code implementation related, bugs, automation scripts, infrastructure, performance, scalability, availability, technical debt, bad code, user access, culture, security, dirty data from the database, toxic people, and so on!

What action to take to be a better problem solver?

The basic action we can take to be a better problem solver in the above-mentioned areas is to at least know the fundamentals of each area and also had done some work with it beforehand. We can always study those areas outside of work and we don’t even need to put in a crazy amount of hours to get better at those topics. We need to know and practice enough in those areas so that our lives can be easier at work. It’s better to prepare ahead of time instead of getting prepared at work.

I really like the powerful warrior mantra:
The more you sweat in training, the less you bleed in battle.

The above quote is true in our software development career, the more we sweat in training, the less we will suffer at work or in battle. The great thing here is that we don’t need to put in crazy hours of study and practice, instead, we have to be strategic, and patient, hold on during frustrating times, and continue doing the work even though it’s hard. You can apply 5/10/25/45/60 minutes a day of strategic learning, which means that we should know enough until we are able to solve problems this is also known as deliberate practicing, all top performers use this technique, and you can make your research about that.

As mentioned above, when we are studying an unknown area we should get prepared to get frustrated because things won’t work at first but after some time of persistence, we can get it done and become better at those areas, those frustration times are vital for our growth, it’s the time our brains will create new neural connections. One important point is that we don’t need to go deep into the subject, otherwise we would easily spend around 5-10 years learning all those areas in depth.

What are the important skills of a problem-solver?

Debugging

Debugging is a great problem-solving ability, bugs sometimes are very tricky to be found, and debugging code will be usually the most efficient way to understand the problem. With microservices, things are more complicated, since most times microservices will invoke other microservices, it gets harder to debug, and doing that in the IDE is cumbersome, therefore, nowadays there are powerful data apps such as Prometheus, Datadog, and others which we can generate useful logs with traceability from what is happening in the code.

Security

Dealing with security is also very common in companies, so knowing a bit about OAuth, OpenId, JWT, SAML, certificates, HTTPS protocol will be a great help when having to deal with those problems. Only the action of creating a service with the mentioned security technologies will be a massive help to solve problems related to that because once we already did something with it we can think much faster of a solution, instead of having to understand what is the concept and only then test some code and then make mistakes, it’s better to do that before-hand.

Automation Scripts

In the cloud era, one of the most common kinds of work we will do is to create or maintain bash scripts, either on automation tools such as Jenkins or in cloud instances, for example, EC2 services from AWS. So understanding how bash scripts work is a crucial skill to develop, also knowing a bit of Linux will be a massive help, to understand how to grant access to Linux users, how to create an ssh connection between systems, and how to connect the dots, it’s very common to connect a bunch of systems together with credentials, security concepts, environment variables everywhere, so it’s very important to be sharp with bash scripts and Linux.

Another tool we will be using all the time is the vim editor, it’s a powerful text editor we can easily use on most Linux platforms, therefore expect to use this editor all the time, also remember to study and have some practice with this editor, otherwise, you will waste your time even to close a vim editor because it’s not an intuitive tool. You can also use nano but it’s not as powerful as vim.

Containers

More than 80% of companies nowadays are using containers, as consequence, it’s a must-have skill for every software engineer to know it well. By far the most popular container technology is Docker, it’s indeed a very powerful idea, Docker solves the ‘it works on my machine problem‘ since the idea of Docker is to completely isolate the application and make it run independently. It’s also very handy for local tests, so when we are running some tests it’s beautiful to use Docker and not have to install a bunch of applications on our machine, Docker is versatile and powerful.

Very commonly, companies will deploy their application using containers, so learning how to containerize a Java, Python, NodeJS, Scala, or Kotlin application is a really useful skill to have. Kubernetes is another popular container technology that is used to orchestrate containers in the cloud basically. It gained a lot of space in the market already, it’s nice to have the Kubernetes ability but not as necessary as Docker. Kubernetes is a little beast of complexity, along with it there are extra tools we can use, such as Helm, Argo CD.

Endpoints Invocation

Along with microservices or even monoliths, endpoints are everywhere, therefore understanding what are the HTTP methods, GET, DELETE, PUT, and PATCH is essential, not only that but understanding the HEADER types, cookies, and session concepts is also something that we will have to deal all the time.

In almost all applications we will use the famous HEADER, Authorization: Bearer JWTTokenHere, so knowing how a JWT token works and knowing why it’s important it’s something that will help you in your day-to-day work as a software engineer. Knowing how to debug endpoints with all the HTTP codes, for example, 200 is the OK status, 401 is the unauthorized status and so on, a useful and funny website to get familiar with the HTTP status is the http.cat website. In the Rest applications, we will be manipulating those HTTP codes all the time as well, then it’s important to know the most important ones.

Logs Depuration

With the monolith architecture, it’s very easy to debug, we just need to put the breakpoint and run the application in debug mode. However, with microservices, it’s very hard to debug because there will be usually many services interaction, there are a bunch of tools such as Prometheus, and Datadog to us to debug our microservices applications.

Observability

We also have to be aware of the new trendy acronymous created by Google, SLA (Service Level Agreement), SLI (Service Level Indicator), and SLO (Service Level Objective). Simply put, those acronymous are responsible for assuring availability and performance with numbers and reports to the application’s customer.

A brief explanation of those acronymous are:

• SLA or Service Level Agreement is a contract the service provider agrees with customers on service availability, performance, etc.
• SLO or Service Level Objective is a goal the service provider wants to reach in terms of availability, performance, etc.
• SLI or Service Level Indicator is a measurement the service provider uses for the goal so the provider can be transparent to customers.

The following link is an example from an SLA of the very famous GitHub website:
GitHub Enterprise Service Level Agreement

There is an extra useful explanation of what are those acronymous:
The Difference Between SLI SLO and SLA

Technical Debt and Bugs

Another very common problem in companies and projects is that they rushed to deliver business value and sacrifice code quality, as a consequence, there will be code atrocities, code with no standards, and code difficult to maintain. Usually, the work to solve technical debt problems is to refactor, optimize and make code more performant, and knowing Java in-depth, design patterns, SOLID principles, and clean code will be a great help to make the code more flexible and easier to maintain.

Architectural Decisions

When working with microservices we tend to have to solve architectural problems or decide on technology more often since there will be many projects in the cloud. Very often we have to choose a database, framework, programming language, cloud services, message brokers, and so on. By understanding the purpose of current technologies it’s possible to have a better decision on what technology to pick. Usually, software engineers will write a document exposing their ideas with the pros and cons of the technologies.

The mentioned topics are some of the common problems for software engineers and it’s important to have the problem-solver skill sharp so that we can solve a wide variety of problems in a company, therefore enabling developers to produce great value.

As always, stay constantly breaking your limits!