|
These are the same people who can do a simple google search to resolve their programming problems but don't. It's usually something someone has already faced and asked about it on the internet.
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
|
In my opinion people that have seemingly no debugging skills and just dump their code and ask for the solution simply don't have what it takes to be developers, they just don't have the mindset. When you meet a problem if your first instinct is to ask for help rather than trying to dissect that problem then how can you possibly be a coder? Coding is all about problem solving and if you lack the drive and instinct to do that then you'll never succeed.
Also you'll find that the people that don't debug and just dump their code are also far more likely to just want you to fix their code. If you explain why their code doesn't work, or give them a hint at why it doesn't work, or suggest what they can look at to make it work then invariably the response is just "Could you update the code for me." Not only do these types not have the mindset to code, they don't actually want to learn either, so there is no point in helping them, you're just wasting your own time.
|
|
|
|
|
F-ES Sitecore wrote: so there is no point in helping them, you're just wasting your own time.
That's a self fulfilling prophecy, to an extent: if you don't try, you can't succeed; just like you can;t win a lottery unless you buy a ticket (which appears to go right over the head of many: Lottery fraud | Action Fraud[^]).
And besides: perhaps what they need is to be told what to do, and how to do it? If you have no idea that a tool (the debugger) and a skill (debugging, or even "thinking" in some cases) even exists, how can you expect them to use it? Converting just one from the Dark Side to join Luke, Leia, Han, and the Rebel Alliance could turn the whole war on stupidity!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
You just get a feel for who can be helped and who can't. I can predict with a very high success rate who is not going to respond to requests for more info, who is going to just re-iterate the problem, who is just going to respond "Can you show me the code". Most people need a very specific answer and unless you can provide that specific answer then you're usually wasting your time. Anyone who says they got an error but don't think the text of the error is important enough to include in the question, or the line the error happened, or anyone who thinks "doesn't work" is enough information for someone to help them simply doesn't have the coding mindset. They don't think like a coder and I'm not sure that's something you can teach.
In some respects the internet is widening the coding gap. It is now so easy just to give up at the first hurdle, dump your code somewhere and say "gimmie codez pls, its urgent", but what do people learn from others fixing their problems? Sometimes very little...give a man a fish and all that. Back when I was flipping switches on the front of a PDP-11 to input a program I had written on paper and converted to binary assembler instructions by hand there was no pdp11overflow to go on and say that my Polish notation "doesn't work", the only option you had was to learn debugging strategies.
|
|
|
|
|
Mostly yeah. Depressing though it is ... every now and then, one of 'em will surprise you.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If I only had back the hours I spend inputting the BIOS on my IMSAI 8080 using front panel switches...
|
|
|
|
|
F-ES Sitecore wrote: just dump their code and ask for the solution
The ones who dump their own code are mostly not beyond help.
The ones who dump someone else's code that they found somewhere on the internet, in an article that sounded vaguely-related to the problem they're trying to solve, but they don't have a clue what it does or how it works - they're the ones you need to watch out for. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Pete O'Hanlon wrote: So the question is, is this useful?
I saw that post you're referring to.
If you look at the quality of the posts like that and the level of effort, I'd have to say "No". Not because what you would provide isn't useful, but because the people posting those types of post aren't really looking to learn debugging... They're looking for the quick answer and some code they can paste.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Well, sure it should be useful.
But the main points I hope you'll cover are:
The primary debugger is your own brain. Often times after giving it a bit of a rest.
Logging progress is still very effective for console applications, but I have no idea whether or not it's useful for lesser applications.
A software debugger is a last resort, for really tough bugs and really tired brains.
|
|
|
|
|
PIEBALDconsult wrote: A software debugger is a last resort, for really tough bugs and really tired brains.
I find coffee a better solution... and if drinking the coffee yourself doesn't help then applying it directly into the computer can provide satisfaction - it'll learn them bugs something proper.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
PIEBALDconsult wrote: The primary debugger is your own brain.
And the secondary debugger is a rubber duck[^]. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well, one is never truly alone when one has a rubber duck.
modified 17-May-18 14:50pm.
|
|
|
|
|
PIEBALDconsult wrote: A software debugger is a last resort, for really tough bugs and really tired brains.
On the contrary! I run the debugger on 90% of the code I write, single stepping through each line to make sure I did it right. Of course I only do that once (unless there's a bug) but given the complexity of LINQ, lambda expressions, closures, and so forth, I find it well worth the effort.
I suppose unit testing could take the place of that, but then I'd have to single step through the unit test to make sure I'd written the test right! 
Which I actually do when I write unit tests.
|
|
|
|
|
Come on! We all know that debugging is dangerous... It may reveal the truth about your code!
Anyway - true programmers use the force
Pete O'Hanlon wrote: So the question is, is this useful?
Depends on who reads it - I would suspect that the average QA visitor do not read articles...
Pete O'Hanlon wrote: Is it only a minority that don't know how to debug or is this a wider issue that needs to be taught?
It seems to me (and have seen over a hundred summaries), that those Next-Big-Thing in 21 Days courses not even mentioning the possibility that a bug can get into your code...
Pete O'Hanlon wrote: am I wasting my time here?
No, despite the previous comments I believe it is a subject should have been taught seriously...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
The amusing thing is that that looks quite like one of my wrong versions of FizzBuzz when I wrote this. It's actually surprising the number of code examples I found on the web that didn't implement this very simple algorithm correctly.
So...
Pete O'Hanlon wrote: So the question is, is this useful?
Absolutely. The whole idea is that even with what looks like the second simplest of algorithms (Hello World) being the simplest) it's easy to get it wrong, and you need to know how to debug it when thinking about even something so simple actually fails.
Pete O'Hanlon wrote: Is it only a minority that don't know how to debug or is this a wider issue that needs to be taught?
I had a couple debugging session last week with a coworker, granted, a junior dev. What was interesting was that he was looking for the problem in all the wrong places. Before starting a debug session, one needs to ask "what exactly am I looking for and what are my initial guesses at where I might find it?" The "what" is not "where is it crashing" -- the exception tells you that, but the "why is it crashing and what are reasons I can come up with where I can go look?"
So often, I see people trying to understand why the line of code is failing or throwing an exception, not realizing that the line of code is working with data that some other function incorrectly created somewhere else in the process, that probably isn't even part of the function with the failing line.
Pete O'Hanlon wrote: If it's a minority of developers, then am I wasting my time here?
No, it's the majority. But you're still wasting your time because the majority doesn't even have the awareness that they're approach to debugging is totally wrong. That's what needs to be corrected, and that's where I'd start. With the article title "You do NOT know how to debug!" 
|
|
|
|
|
I have to agree with you. I can't recall the last time I helped a guy sort out a problem who actually knew how to debug and use the debugger effectively. Everyone I have had to deal with doesn't approach it the right way. That is, assuming my approach is the right way. Historically, it has worked very well for me.
The wildest experience I have ever had debugging code is when I was writing a debugger for a script language I wrote and I was trying to debug the interaction between the script code and my debugger. The script engine generated machine code on the fly so it was a bit difficult to see everything that was going on. The wild part was I had three debugging sessions going on - my debugger was attached to my script process and debugging it, I had a VC++ debugger attached to my script code debugging it, and another VC++ debugger was attached to my debugger and debugging it. That was a real head-scratcher. 
|
|
|
|
|
In my years of experience, this is definitely lacking in a lot of people I have encountered. Even lecturing at university, I found this to be one of the fundamental issues that prevented students from fully understanding control and data flow.
|
|
|
|
|
imho, a majority of posters on QA do not have a clue about how to debug.
I cannot generalize from that to make inferences about other programmers in the main/wild.
I do think that debugging skill is tied closely to mastery of the facilities the IDE offers, and that mastery requires some effort.
I suspect that many QA posters are at the low-end of some general measure of: motivation; eagerness to learn; willingness to work hard to get the "bigger picture." Their questions would never be tolerated on StackOverflow.
So, yes, I think articles from you on debugging would be great.
cheers Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
If you are going to write an article on debugging, make sure you include the original problem statement.
Many bugs are introduced by misinterpreting the "specs" or by having ambiguous specs.
Another approach might be to show multiple "answers" that all compile correctly, and then ask which of these best meets the spec. (Always have an option "D - none of the above")
Like a few people have pointed out, include scenarios where some other part of the program sets up a different part of the program for failure. Modern languages (C# and Java and even JavaScript) make it very easy to have multiple references to mutable objects where you were not expecting them. (It is only your private object until a reference "escapes" your scope)
|
|
|
|
|
You're assuming that the ones that didn't even try are waiting to learn.
On the other hand, when someone tells me I'm going to fail and I better learn to debug...
We were told to "desk check" before wasting (mainframe) "compiler time".
I always finished ahead of schedule ... but used the most machine time anyway.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Does the concept of crash helmets go right over your head?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Don't know, but I'm sure it'll have an impact.
/ravi
|
|
|
|
|
boom tish!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
