Writing pseudocode is a good thing.
Just as it is not recommended that you dive into writing code before your analysis and design are done, so should you not dive into code before you have some sort of pseudocode in place. Unless of course you are writing trivial code.
Even if your design is all laid out before you, then there are many cases where pseudocode is a huge advantage.
Simply listing out the steps gives me a lot of clarity about the way forward. I will most likely find that I've discovered areas that were not thought of during design e.g. if X event takes place, or the application state changes to Y, then how do I handle it?
When I'm coding I am in a different mindset- purely focused on code. Side issues like these are unlikely to pop into my head. And worse, if I haven't worked out the steps, then I will most likely miss something.
Getting stuck on a code issue is very common- at that point, all you can think about is how to solve it/work around it. By the time you've achieved this, your train of thought is lost.
I still use paper and a pencil. Whether you prefer electronic pseudocode or hand written, is up to you but in my opinion, it is an invaluable practice.
I am amazed at the number of people who jump into code and flounder along the way and just refuse to write pseudocode like it's some demeaning activity. What is more amazing is the number of tech leads who prohibit it of their juniors-- saying things like "the client wants to see code". It is well worth the time investment- the bugs will definitely be less. And the amount of patching needed on that code will decrease.
So, it's not a "waste of time" or "an activity that only freshers do". Some of the best engineers I know write pseudocode. It would be worth getting into this habit to help you understand your problem, eliminate ambiguities, reduce bugs and above all, write cleaner code.