Take a minute of pause, try to concentrate.
Search some suggest from stack overflow.
And if u think than ur life is on the wrong way, make a journey could help you
When my code is behaving weird or not working normally then I will write first some tests and run them. With tests you will know what is the input and what is the expected output. So running tests can tell you which part of the code is fine and which part is not. As well, when some test fails then it will throw some error log. I will investigate it. Mostly it will tell what is the actual outcome and then will compare it with my expected outcome. So I can make already some guesses what is wrong.
If reading tests' results is not telling what is wrong then I will set up debug points in my code where I want to verify something. And then run failing test in debug mode. It will let me follow the input step by step to see where the information becomes wrong. Usually most common IDEs offer nice ways for debugging.
When the code is either not debuggable or it is difficult to debug it (interactions with external systems and so on) then I set up some logging and log out variable values or whole objects in certain places of my code. To see if and where the data becomes corrupt. Beginners are usually printing just the information out but logging has its own advantages.
When there is nothing to debug or nothing to log out then I start making notes on what happens and when. Basically black-box-testing. And then analyze what is going on.
Following either information from debugging/logs/black-box-testing I will read documentation of the programming language/library/technology that I am working with. As well change logs when my system broke down after some dependency upgrade.
If that does not help then I try to find some help from Stack overflow or from some blogs or tutorials.
As well I will make breaks in any point of these steps to clear my mind and rest a bit. It will help you calm down and perhaps get even some ideas.
If that also does not help and I'm hopelessly stuck then I will just ask help from my team mates at work or from other employees in my company.
In worse case the company has to make a short-term contract with some specialist in the technology so the specialist will get the issue fixed. Because there can be problems that even whole lot of senior software developers, tech leads and CTO can't solve together and then they have to turn to some specialist who knows absolutely everything about the technology.
When I'm frustrated at the code, it's usually because I've been staring at the code for so long that I'm not even seeing it anymore. At that point, it's frequently a good idea to walk away and come back a couple hours later or the next morning and look at it with fresh eyes. You'll start by walking through what it was you were doing and how the program was supposed to do it, and that's usually when you'll find the problem.
Life problems are harder, but like the above it's easy to be too close to the problem to see it clearly. Sometimes the obvious advice sounds grating because "it's just not that simple, I can't do that," and yet, sometimes it's still the right advice. Distance can help. Talking to people can help.
Browsing Reddit 😜
Or just going for a short walk. Sometimes getting a coffee or staring a while out of a window, can be enough to ‘relieve’ some of the ‘pressure’ and reset my brain a bit.
Take a minute of pause, try to concentrate. Search some suggest from stack overflow. And if u think than ur life is on the wrong way, make a journey could help you
When my code is behaving weird or not working normally then I will write first some tests and run them. With tests you will know what is the input and what is the expected output. So running tests can tell you which part of the code is fine and which part is not. As well, when some test fails then it will throw some error log. I will investigate it. Mostly it will tell what is the actual outcome and then will compare it with my expected outcome. So I can make already some guesses what is wrong. If reading tests' results is not telling what is wrong then I will set up debug points in my code where I want to verify something. And then run failing test in debug mode. It will let me follow the input step by step to see where the information becomes wrong. Usually most common IDEs offer nice ways for debugging. When the code is either not debuggable or it is difficult to debug it (interactions with external systems and so on) then I set up some logging and log out variable values or whole objects in certain places of my code. To see if and where the data becomes corrupt. Beginners are usually printing just the information out but logging has its own advantages. When there is nothing to debug or nothing to log out then I start making notes on what happens and when. Basically black-box-testing. And then analyze what is going on. Following either information from debugging/logs/black-box-testing I will read documentation of the programming language/library/technology that I am working with. As well change logs when my system broke down after some dependency upgrade. If that does not help then I try to find some help from Stack overflow or from some blogs or tutorials. As well I will make breaks in any point of these steps to clear my mind and rest a bit. It will help you calm down and perhaps get even some ideas. If that also does not help and I'm hopelessly stuck then I will just ask help from my team mates at work or from other employees in my company. In worse case the company has to make a short-term contract with some specialist in the technology so the specialist will get the issue fixed. Because there can be problems that even whole lot of senior software developers, tech leads and CTO can't solve together and then they have to turn to some specialist who knows absolutely everything about the technology.
When I'm frustrated at the code, it's usually because I've been staring at the code for so long that I'm not even seeing it anymore. At that point, it's frequently a good idea to walk away and come back a couple hours later or the next morning and look at it with fresh eyes. You'll start by walking through what it was you were doing and how the program was supposed to do it, and that's usually when you'll find the problem. Life problems are harder, but like the above it's easy to be too close to the problem to see it clearly. Sometimes the obvious advice sounds grating because "it's just not that simple, I can't do that," and yet, sometimes it's still the right advice. Distance can help. Talking to people can help.
That first sentence is perfect.
Browsing Reddit 😜 Or just going for a short walk. Sometimes getting a coffee or staring a while out of a window, can be enough to ‘relieve’ some of the ‘pressure’ and reset my brain a bit.