There is one remarkably simple trick you can learn in only a few minutes that will be useful for the rest of your future as a programmer. And there...
For further actions, you may consider blocking this person and/or reporting abuse
In addition to the tips above my contributions are:
Almost all programming environments support a real-time debugger, allowing you to step through every line of code in your application while monitoring the state. Way too few programmers know these tools exist, know how to use them, and then use them to find out what your program is actually doing and where it actually fails.
Debugging actually takes a long time. There is a famous quote.
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan
I find that more to the point.
Kernighan said that in 1979. I don't know if you've noticed, but software and tools have evolved a little bit since then.
It should not. However, I do see there are languages and environments, where setting up a debugger may be hard.
But most people are application developers and don't do embedded etc. Those folks should really only use a debugger if possible (yeah, parallel programming indeed is a prob here) because usually it's even faster than printing, gives a lot more info, you can usually change stuff in the process and you don't forget print statements which may find their way into a public release.
I am working mostly with .NET Core and starting to debug is a matter of pressing one single keyboard key. Writing a debug print statement is actually more effort to me.
"Famous quote" doesn't mean it's right. I know a lot of famous bullshit quotes.
And yes, of course you need a working brain to do effective debugging, but a debugger sure helps a lot. Especially when your application requires recompilation to add your print statements just hooking in the debugger and seeing what's going on is often a LOT faster.
I don't agree. I'm actually so much lazy I rarely use the debugger. That gives me a whole lot more time to work on other things instead. If you spend too much time on it you are not productive. You are just messing about.
And one more thing. This is not a
bullshit quotefrom the author of C as he definitely knows more about programming wisdom than anybody here combined.Or set security guards on the doors to stop the crime taking place. Use Design By Contract, and place preconditions at the start of methods and postconditions at the end. They will catch 95% of your bugs.
When I was in college, a prof once said, there is no engineer that knows everything, that never needs to consult a reference. Good engineers keep their references close at hand, and know when to consult them.
he then went on to detail a bunch of desk refs which are not salient to this article.
This was of course before Google was a thing. But I think the sentiment applies. A good engineer knows when to stop bashing their brains out on the keyboard and just look it up.
My Uncle once said, if it's built by people, people can fix it. Which is a deceptively simple sounding idea. But when you crack it open and start applying it is a gamechanger.
Does someone know the first who face a given problem?
I mean, the moment when you google something and "No records found".
It's SO rare to run into an originally new problem. 99.999% of the times it's probably a different manifestation of a problem somebody has faced before, so you just need to rethink and rephrase to get answers.
this is not always true. based on the tool you use (could be the language, framework or anything else) you could get face some wired situations no one else ever faced before.
last semester our parallel programming prof asked us to do the homework with multi-pascal and apparently it's community dose not exist (and he knew it). so, we had to figure out what to do without any help.
God it was hard
LONG LIVE console.log()
👍🏽