|
"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.
|
|
|
|
|
I found that so .. straight-forward that I could not have imagined it is something that needs to be taught.
|
|
|
|
|
Me too, I only tend to debug my own code these days, the single step function is the one I use the most...
|
|
|
|
|
It's worse than that. The code the junior devs write is often so algorithmically and/or architecturally wrong that debugging won't actually solve the problem. Abstracting the problem, breaking the problem down into smaller problem sets, asserting on inputs, writing try-catch handlers, none of this taught. As a result, debugging something that is broken from the get-go is pointless.
And debugging existing code that hopefully someone with more experience wrote? Forget it. Simple syntax like null continuation, generics, lambda functions, LINQ, callbacks...it's all Greek to them because they were never exposed to real programming.
The mantra my mentee kept repeating over and over again was "oh my god, why didn't they teach us that in school???" 
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: And debugging existing code that hopefully someone with more experience wrote? Forget it. Simple syntax like null continuation, generics, lambda functions, LINQ, callbacks...it's all Greek to them because they were never exposed to real programming.
I have to regularly explain how the code works at both the architectural level, as well as the code level. This is to get them to understand the underpinning design decisions, as well as the detail of how the code itself works. Generics and LINQ were completely brand new to them. It took several sessions to get them to understand the problem that Generics solves, nevermind understanding the syntax behind it.
"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
|
|
|
|
|
or u could just hire guys who know how to debug ..
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I had to learn debugging / fault finding the hard way working in a support department. Not fun, but I learned a lot!
|
|
|
|
|
May I direct your attention to QA and the programming forums where you can easily evaluate for yourself if debugging skills are being taught or not.
In my humble opine, the answer to that is "#$@% NO".
Tell someone to use the debugger to see the values the code is using and they react like you've slapped them with a fish. They're not sure how to respond, either with being insulted or afraid of the debugger like it's some form of dark magic they're afraid to mess with.
|
|
|
|
|
From my college experience around 20 years ago, debugging was not taught, or maybe it was skimmed over enough that I never learned. At that time it was VS6 and I remember being amazed when I learned about breakpoints and F8 at my first job! 
As for problem solving, college was pretty weak there also. Assignments were mostly based on identical scenarios covered in the chapter...change a few variable names and get an A. There just wasn't much that required thinking outside the box.
That said, I also remember having to get creative to debug classic asp and javascript. The IDEs, languages and browsers have made web development so much easier than it used to be 20 years ago at least in terms of being able to debug. My 2 cents. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
From my article - Being a Programmer[^]
8) If you're writing code using Visual Studio, learn how to use the built-in debugger. In fact, don't settle for being a "decent" debugger. Strive to be a GREAT debugger, because that's probably where you'll spend 75% of your coding time - tracking down and fixing issues cause by not only yourself, but by others as well. Exercise due caution while debugging someone else's code. Be diligent, and explore all possible side effects that might be caused by fixing an issue. If your shop is truly SDLC-compliant, the testers will regression test a new release candidate, but you should not count on the tests being able to capture every little nuance. (Unit tests are only as thorough as the person writing them.)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
If graduates were taught how to use the VS2017 debugger, 6 months from now someone would complain why they weren't taught how to use the VS2019 debugger.
Well, this is a bad example because typically the debugger doesn't change all that drastically from one version to the next, but you understand where I'm headed with that. They should learn about the debugging process, rather than the specific of any given tool.
Indirectly related: When no debugger is available (eg, software is running on a customer's system and nobody has access to it)...do said developers have access to a great logging library, and know what to log and when? The importance of this particular aspect cannot be stressed enough. Knowing how to use a debugger won't get anyone very far if you can't reproduce a problem locally and can't install any debugging tool--and a log file is all you have at your disposal.
|
|
|
|
|
I agree, and that's why I suggested that understanding concepts such as setting breakpoints and stepping through code are vital skills (without making any mention of any particular IDE). I have't found a recent graduate yet who seemed to understand these skills. Even whilst writing vanilla code, you will still need to understand these skills when your own code fails to give the expected results. And they are definitely needed when fixing bugs and maintaining code.
In answer to your other questions, we use tools such as Azure Application Insights which does an incredible job of logging diagnostic information to enable us to debug production errors.
"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
|
|
|
|
|
Is setting breakpoints and stepping through code so difficult to master it's a "skill"?
|
|
|
|
|
Diagnosing and debugging are most certainly skills, and skills that seem to be in short supply amongst recent graduates. Certainly amongst the graduates I've been mentoring over the last few years.
"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
|
|
|
|
|
Dominic Burford wrote: 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?
Schools will provide nothing beyond what they promise in the curriculum, the rest is left for the student to research in their free time. Which hardly anyone does, ofc.
Hard to find a decent school that's worth what it is asking.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Remins me of a few years when I was working with a couple of EE engieers, 50% self-taught in programming, and I had to help them out debugging a lot of software. I impressed them a lot, pinpointing problems quite rapidly, and the they frequently asked me, like,
- How did you know how to set the breakpoint exactly there?
- I don't know... Well, it turned out well, didn't it?
- What made you look at that variable, just when it went crazy?
- Good as any, but when it changed, it put us on the track, didn't it?
I couldn't explain even to myself what were good breakpoint position, values to trace or whatever. It is just an instinct. You can't expect everybody to have that instinct.
Nowadays I have nobody looking over my shoulder, getting impressed. But if I did, I would have a hard time explaining my hows and whys of debugging. I didn't really learn it from anyone, it just came by experience. It came early to me, most of it during my studies. Maybe today's development environments do not give you the same kind of learning experiences as those we had when we submitted code batches on punched cards to the computer center. In my case, that ended after my freshman year, but even with interactive terminals, we retained this idea of the program residing down in our semi-unconciousness. as a breeding ground for whatever instinctive ideas about how to debug the programs.
I don't think today's students "internalize" the programs nearly as much as we did when I was that age.
|
|
|
|
|
You miss 100%[^]
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!
|
|
|
|
|
Said the sniper's wife ? 
|
|
|
|
|
Quiet study in fur can be distributed (10)
|
|
|
|
|
PROCESSING?
I doubt it, but it starts with "P" ("Pianissimo", or "Softly" in music) and can be distributed.
Just a wild guess as it's getting close to "Revert to previous setter" (i.e. me) time anyway ...
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!
|
|
|
|
|
Maybe Processable ( sable being the fur bit ) ? I don't like it though
Edit
Forget it it's too many letters
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
pkfox wrote: Edit
Forget it it's too many letters
Damn! I was thinking "Sable makes sense, but where does ROCES come in?"
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!
|
|
|
|
|
OK, if it's not "PROCESSING", then we surrender and I'm up tomorrow ...
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!
|
|
|
|
|
No idea - I agree it should begin with a P ( but you know what he's like ) quiet study could possibly be preference
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
S ABLE (fur)
P (quiet)
READ (study)
SPREADABLE (can be distributed)
Have fun tomorrow!
modified 13-May-19 8:42am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
