For the longest time, I would attempt CodeWars exercises by sort of understanding the exercise and with no plan started coding. This lead to so much frustration and time spent just trying to make sense of stuff. Sometimes I did stumble upon the answer but let's be honest if I took the time to plan stuff less time would spend debugging.
Pseudocode is a simple set of instructions written in plain English (or whatever language you prefer) to logically approach a problem. Think of it more as a plan on what to do and not the solution. By writing each step down it will give you clues on how to approach the problem given the specifications and instead of going back and forth changing the code, you can code once and not worry about it again. A good way to track time spent on a problem is using the [pomodoro technique] (https://francescocirillo.com/pages/pomodoro-technique) and comparing how much time you spent approaching a problem with pseudocode and when not using it.
The best advantage of pseudocode like mentioned before is that you will have a clear perspective on the problem and spend less time trying to find a solution because you didn't understand the problem, to begin with. This will lead to cleaner code because you won't be writing solutions that are just to get a solution out and by having a plan you will pick how to get to a solution in a more elegant fashion. If you are working on a team your pseudocode may help you write the documentation for that feature you are working on killing two birds with one stone.
There are some disadvantages to pseudocode and one being that while is easy to read it does not provide an accurate map on how to write the solution. Most of the time you are going to go back and forth between writing pseudocode and writing actual code because maybe you didn't think of an edge case or your logic was flawed (at least this happens to me). Since pseudocode is unstructured it may lead to a logic step being missed or someone else not understanding exactly where you are coming from when you wrote it. Be mindful that you may understand whatever Frankenstein monster you created but your neighbor might not.
Don't worry because even if pseudocode is a rebel with no rules you can create some style rules yourself and maybe make your little monster friendlier to your neighbor making them aware of how it behaves. I found this [article] (https://blog.usejournal.com/how-to-write-pseudocode-a-beginners-guide-29956242698) very useful on writing good pseudocode and you can make it closer to your programming language if you wish. For me, comparisons should be with either
== or === instead of
=. It makes it less confusing and you can make new rules as you see fit maybe even make it team-wide.
If you don't like pseudocode that's fine. A lot of people don't like it too but there are alternatives because the point is to save time and have mental peace. One of the best alternatives out there is flowcharts because it will be a more descriptive way of writing the plan to solve the problem and requires fewer rules to have the everyone on the same page. Draw.io is a good resource to use if you want to start using flowcharts.
If you are writing production code or coding for fun pseudocode can help you achieve your goals faster with less frustration and even if you don't like it use alternatives to have the same outcome.