Being a Programmer Is More Than a Profession, It’s a Way of Life
By: Kesk - -
Tags: Programmers Life, Programmer, Software Engineering, Software Development, Problem Solving

Being a Programmer Is More Than a Profession, It’s a Way of Life

Solving problems and learning forever

Rubik cube image

If you’re a programmer, you’re a problem solver and not only issues related to programming but problems in general. Programming teaches you to think in a particular way and to always look for the best solution possible.

The main thing is not how many programming languages or frameworks you know, the important thing is your problem-solving skills and your ability to learn continuously.

It’s not a profession for everyone. If you want to be a programmer, you always have to be willing to spend time improving and learning new things. When you’re young, this is easy, but what will happen when we get older? This is something I always wonder. Are we willing to pay the price of still keeping up? I want to keep learning forever, I think it’s a good thing and that it will always keep me active, but time will tell.

In this article, I am going to write about the way of thinking that I have developed these years when it comes to solving software problems and finishing projects successfully.

Thinking like a programmer

So, What can you do when you encounter a problem?

Understand the problem

This step, although obvious, is not always done, especially when you start developing software.

I remember when I started programming and had problems to solve. Many times I made things without knowing very well what I had to do, so I ended up wasting a lot of time.

If you’re facing a complex problem, try to explain the problem to someone, and you will realize many times that you have not understood it correctly.

“If you can’t explain something in simple terms, you don’t understand it.” Richard Feynman.

You can try the following steps; it works for me:

If you were doing something else before, clear your mind before you start.

Close all browser tabs and unnecessary programs and leave only the essentials.

Write down your problem.

Talk to the client as much as you need. Receiving continuous feedback is usually one of the most important things to solve a problem correctly.

Doodle a diagram or build a scheme.

Look for the critical points of the problem.

Split, if necessary, the problem into little parts to make them easier to solve.

Search if exists a solution for it and search how others have solved similar problems, but understand it, not only copy && paste the answer.

Another handy thing that can help you is to use a rubber duck. You only need a rubber duck and debug the code by forcing yourself to explain it, line-by-line, to the duck. And I swear it works! Because when you force yourself to explain something, you realize whether you understand it or not.

Get on with it

Once we have understood the problem, we can move on to designing the solution.

For this you need:

Organize your thoughts and develop strategies to tackle the problem.

Write the steps to solve the problem.

Think about what do you need to solve the problem.

Choose the technology (Framework, language, Database) to solve the problem but don’t get too committed to it.

Is there a design pattern that solves the problem?

Is there a lib that solves the problem?

There are any special functional or safety requirements?

Be persistent and not give up. Many times you will find problems that seem impossible to solve, or you will spend several days looking for a solution, but in the end, you will always find a solution one way or another.

Test your solution

This may seem abrupt at first, but if it’s something you get used to, you’ll see it as something natural, and it will give you other views on the problem you’re trying to solve.

Resolving the problem

Once you have decided which language or framework to use and you are clear about what you want to solve, you can start implementing the solution.

Do you know Test-driven development or TDD? This is an excellent time to start with it.

Create a test case for the problem to solve, but don’t write code yet.

TDD:

Write some code to solve a part of the problem.

Run the test until the code past the test.

Refactor the code.

Run the test.

Repeat

The purpose of this method is to make the code clearer, simple, bug-free, and facilitate the refactor of the code at any moment.

Final steps

Extract conclusions.

Refactor, always refactor the solution.

Conclusion

Learn, learn always. Read about software and other technological things: Medium, for example, is a good place for it. Read books about the software or design principles but also books that have nothing to do with development.

Solving problems is the main skill of a programmer, and learn from each problem is essential if you want to progress quickly.

Many times the problems we encounter in the software world are very similar to real-life problems, and without you realizing it, you end up applying the same techniques to the rest of the real-life problems. Being practical and not getting complicated in the end is the best.

And be patient, sometimes in real life, I take engineering to the extreme and apply it to the people I am with, and this is not good ;)

Thank you very much for reading me, it makes me very excited because my passion for writing is combined with my passion for software engineering, and that makes me very happy. Also, if the things I’ve learned during my years developing software are useful for you, I can’t ask for more.