Great advice. I like the "talk to a rubber duck!" A long time ago, my project manager was literally my rubber duck. I would talk about a problem and she would just "hmm hmmm" me for 3 minutes until I say "and... oh! wait a sec" to see everything resolve.
Furthermore, I would add this: baby steps. Either when you develop or debug, doing one thing and then make sure it works as intended will save you a lot of trouble. Sometimes it is easier said than done, you don't need to do TTD per se (but it will help you a lot). It is especially true in embedded system development when you do not necessarily have access to a console or have enough storage for log files. (Debugging with gdb on an embedded system that is time critical can be in the range of the impossible).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great advice. I like the "talk to a rubber duck!" A long time ago, my project manager was literally my rubber duck. I would talk about a problem and she would just "hmm hmmm" me for 3 minutes until I say "and... oh! wait a sec" to see everything resolve.
Furthermore, I would add this: baby steps. Either when you develop or debug, doing one thing and then make sure it works as intended will save you a lot of trouble. Sometimes it is easier said than done, you don't need to do TTD per se (but it will help you a lot). It is especially true in embedded system development when you do not necessarily have access to a console or have enough storage for log files. (Debugging with gdb on an embedded system that is time critical can be in the range of the impossible).