|
|
As one of the senior developers where I work, I am tasked with mentoring the junior members of the team. This is a part of my role I really enjoy, as I get to pass down my hard won knowledge and experience to the next generation of software developers. What I have found over the years is that they all seem to lack one vital ingredient. How to debug / diagnose a problem. I have seen many of them struggle to use the debugger, set breakpoints, step through code, use the F12 browser tools etc. Even those with First Class honours degrees have struggled with this.
I remember when doing my own degree (many years ago) we were taught these basic skills (using a Borland C++ IDE). Is this vital skill no longer being taught to new graduates? I feel this is a vital skill in any software developer's tool chest.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
It's even worse than that: debug-by-printing is often explicitly recommended.
|
|
|
|
|
It's the only cross platform and cross environment mode, and can be implemented in the release code itself to catch bugs.
It is not bad in itself, it's just a tool - also GDB sucks, the only decent debugger I used is VisualStudio, which is usable basically only on Windows platforms.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
It is bad. GDB is also bad. Tools can be bad, and often are.
I've heard that RemedyBG isn't bad, but I haven't tried it yet.
|
|
|
|
|
harold aptroot wrote: It's even worse than that: debug-by-printing is often explicitly recommended.
And why is that so bad?
I have found a lot of bugs just adding a couple of messageboxes / wprintf in places of the code
If you are programming things that might have a timing component, debugging alters the real world use case when you hit the stop points. Saving a couple of values there and printing them later on the screen doesn't screw your performance or timing relational so bad.
And as de2k88 said... you might use it always.
You can even "debug" the release version with it.
I think this is like the "goto"... it is not bad per se. But I can agree with you that it might get messy pretty fast.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
We should use both. Sometimes printing (really logging) is essential (e.g., async and parallel programming). In fact, one of my bugbears at various client sites is the lack of logging features.
Kevin
|
|
|
|
|
Debug by printing can be useful at times. That's the whole point of having log files. It shouldn't be the only tool in the box, but it shouldn't be completely discarded.
|
|
|
|
|
If you are building code to ship to customers, then in the field problem diagnosis is a fundamentally important thing. If something only fails in the field and you can't reproduce it, it can turn into a major circle-jerk (with you being the jerk in the circle.) Good logging, with variable threshold, is a key part of that.
And, since it's already there, it will serve you just as well during development as well. For me, I have a very powerful logging system that is supported throughout the entire code base, and the ability to log to a centralized log server. This has saved me more times than I can count. I mean, we all love being jerked in a circle, but sometimes you just don't have time for it.
Explorans limites defectum
|
|
|
|
|
Dominic Burford wrote: How to debug / diagnose a problem.
Trust me, this is not limited to junior developers.
Dominic Burford wrote: I remember when doing my own degree (many years ago) we were taught these basic skills (using a Borland C++ IDE).
I do not remember anything like that, but given it's been just 5 years since I got out of the university, I wouldn't be surprised if this was a trend some time ago.
I struggled with this for a while when I had just started, but now I feel comfortable enough to be in your position.
|
|
|
|
|
When I was at uni, you added punch cards to say
PRINT *, 'The value of I is ", i Assuming you had enough runs left: Our score for an assignment decreased by 10% for each run over three. 
When I moved into the "real world" and started working with embedded Z80 assembler, I had to write my own debugger to stop the process and display register / memory data in real time ...
Visual Studio has so many tools to make beginners life easier, and many of them have no idea that they even exist, much less that "debugging" is different from "fixing the compilation errors".
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's my favorite : "well, it compiles. Why doesn't run right?"
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It seems that problem solving at all is not a skill taught to anyone anywhere...
Actually - 'you have a problem' is considered rude to tell a student, as it implies the need to take responsibility, which totally uncommon these days (and to force it on someone is unforgivable)...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It seems that problem solving at all is not a skill taught to anyone anywhere..
Agreed.
And even more broadly, critical thinking skills simply aren't taught.
That's the nature of schooling being based upon multiple choice and t/f exams.
|
|
|
|
|
raddevus wrote: critical thinking skills simply aren't taught
You are wrong. I was taught to contradict everybody!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
megaadam wrote: I was taught to contradict everybody!
Here's your motto: I disagree, therefore I am! 
One always needs a sense of porpoise.
|
|
|
|
|
I wasn't taught anything related to debugging when I was at University. In fact, when I got my first job I had support tickets with the customer claiming something was happening. I fell into the trap of asking my team leader "X says this is happening, can you think of a reason why?"
It was only after being constantly told "Can you reproduce it? If so, have you debugged it to see why it's happening? If not, then we obviously need more information" that I really fully embraced debugging. It seems silly, but up until then I'd only worked on personal projects which were less complex and the bugs were self-explanatory so I only debugged rarely.
If they don't teach it in College/University then I don't have a problem with senior developers teaching more junior developers the values. We have a few developers at my current place who, while being really adept and forward-thinking, sometimes forget to debug and inspect. A gentle nudge every now and then gets them back on track.
But you're right, while there's plenty of material on building code taught at Uni, there doesn't seem to be much in the way of properly debugging and diagnosing code. And I don't think anything prepares students for those situations where a client or customer has made something up!
|
|
|
|
|
making stupid and glaring mistakes isn't taught either - but they're damn good at that.
so why the difference?
|
|
|
|
|
|
I don't think that lack of debugging knowledge is the issue, so much as an inability even to understand what steps to take in problem analysis. Look at some of the questions here and you can see that some so called developers do not really understand the code they may even have written themselves. I suspect there are far too many people following a career into IT because they think it pays well, rather than because they have an interest in problem analysis and finding solutions.
|
|
|
|
|
Richard MacCutchan wrote: I suspect there are far too many people following a career into IT because they think it pays well, rather than because they have an interest in problem analysis and finding solutions.
I would tend to agree. Many people coming into IT are career professionals rather than following a true passion for the industry.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
This is true for many careers. Many mechanics can't find problems in cars because they don't know how they work, they simply follow the company's instructions. So do many electricians.
If you know how the thing you made works, you also know where and what to look at to discover problems. If you don't, i.e. you copy-pasted code without minimal knowledge, you can know every single debugger function and still be useless as a bike to a fish.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: be useless as a bike to a fish.
Well...[^]
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Agreed. There is a big difference between being able to use debugging tools and being able to do problem solving.
Kinda like the super intelligent person who lacks common sense.
A course in OR (Operations Research) could help. Working with real time systems will really test those skills. 
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
"If you hear hooves, think of horses not zebras" is another of my favourites. Had one guy at a place I used to work always assumed every database issue was due to faults in the NAT firmware in the routers or maybe the network cards were dropping packets so needed updating. He'd spend his time researching new drivers etc etc, and when he still couldn't get it working I would take a look and nine times out of ten he had misspelled the server name in the connection string, or omitted the instance name or something like that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
