Apps

Could it be that some people just can't learn good debugging skills?


Justin James recently wrote about his quest for a senior developer. One of his requirements is excellent debugging skills, which is a topic that is near-and-dear to me because I'm currently working with somebody who has bad debugging skills. So bad, in fact, that I think it's ingrained, a genetic trait, because no matter how much time I spend with him he never seems to get any better at debugging.

The weird thing is when he has a clearly defined job, like "fix the bug by changing the way this package executes this loop," he can get it done without too much drama. In isolation, his technical skills seem to be okay, but it's finding that bug and identifying the fix where he seems to fall down. He spins his wheels grasping in all the wrong directions and eventually ends up asking one of the other engineers to help out.

I thought anybody could learn how to think about all the pieces of the system and know what might be broken and where to look. If you can program, you can learn how to think beyond just the one page of code to the whole system. But working with this guy has made me think that perhaps there are some people who just aren't wired for debugging.

He's not some junior programmer either -- he's been in this industry working as a software engineer at least a decade. Plenty long enough you would think that he would have picked up solid debugging skills.

And it's not like he doesn't want to learn. I can tell he's trying, and I know he wants to get better because he wants to impress the boss to get promoted. At least he spends time looking for the source of the bug whenever one comes up. But, inevitably, I hear him asking me over the cubicle wall if I have time to help him understand why his code isn't working the way he thinks it should.

Again, there's nothing wrong with the code he does end up producing. It's just that he spends an inordinate amount of time whenever some bug comes up because he doesn't seem to quite grok how all the pieces fit. When an Oracle package fails, is it the PL/SQL, something in the table data, or maybe the table structure itself? A trigger that's incorrectly updating a sequence? He knows about all those things, but he doesn't seem to be able to string them together into a plan for tracking down the bug. The little picture, the unit of code, he gets okay. It's the big picture, how his code interacts with everything else, that he isn't quite grasping.

I'm not going to give up -- I can't afford to. I need him to get better at this so I don't spend so much time helping him out. But I am honestly starting to think that maybe some people just aren't wired to learn this stuff.

112 comments
SanKulPune
SanKulPune

This great discussion reminds me of an incident (not so funny at that time) about 25 years ago. I created a macro in Lotus 123 (Excel was not born then) but found that it did not work. There was no IDE. So, I spent more than four exhausting hours looking for any possible error without any hint of success. Then suddenly I discovered that I was writing 'lable' (old spelling) instead of 'label'. It still keeps me revisiting in defferent forms. It has taught me so many lessons that I still have not been able to forget the incident. I use it example in my programming classes. - Sanjay Kulkarni, Pune.

etkinsd
etkinsd

Debugging is problem solving, and writing code is all about solving puzzles -- they are conjoined and inseparable. One's technical ability is therefore a reflection of both activities.

Absolutely
Absolutely

How would a [u]good[/u] programmer acquire debugging skills? :D

maartinswart696
maartinswart696

My two main functions at work are optimization of a product range as well as where and how it interfaces with other products (I am not a developer), and, advanced support, as in where the people that maintain the product and services get stuck i.e. fault finding. In my oppinion fault finding / debugging is not just about logical ordered thinking and the ability to do so (genetic?). What I find important is seeing the bigger picture, does he only work or focus on a small or limited piece of the product?; and, does he have a solid knowledge and understanding of what others might be doing (a good working knowledge of the big picture) in relation to what he is doing? And then lastly does he have a good working knowledge of the platforms or applications that his work has to interface with? In my experience people find it difficult to perform fault finding due to a too narrow focus on the problem, not seeing any behaviour not directly linked as a potential marker for error, coupled with not being strong enough in the necessary related areas.

BrooklynPennyPincher
BrooklynPennyPincher

Does the programmer get enough sleep? To debug, you have to have absorbed the system design. You can't absorb without sleep.

TonytheTiger
TonytheTiger

While I don't think it's genetic, I think that the predisposition toward the basic traits (attention to detail, "sticktoitiveness", etc. are ingrained by a relatively young age... probably before age 5. Learning such a trait is possible after this age, but the person learning it will work much harder at using those traits than someone who was indoctrinated early.

jmarkhus
jmarkhus

unfortunately i got into this late but, maybe you should consider what kind of chap you have there. there are loads of people in this field who are just academically gifted and yet we all know that the genius in programming is having strong kungfu. what i am saying is there are those who know how and those who can. he can't but knows how. make him an admin :-)

RexWorld
RexWorld

Speaking of debugging, NASA could use somebody with really excellent debugging skills right about now. They're having serious problems with the steering computers on the Space Station: http://www.msnbc.msn.com/id/19228925/

BALTHOR
BALTHOR

Edited Message was edited by: beth.blakely@...

Wayne M.
Wayne M.

I think there are two different issues here. One is exposing a developer to the big picture of the application and two is being able to debug problems within that framework. To advance, a programmer must understand the intent of the application as a whole. If you are metnoring a junior staff member, have him sit in while decomposing tasks. Don't just break everything down and thenn give him a bite size chunk. Take the time to walk through the decomposition effort with him. It takes more time in the short term, but in the longer term he will be able to take on more of the task himself. Concerning debugging, the most valuable skill is the ability to reject a hypothesis and create a new one. It is usually very easy to come up with some idea why a failure occurred. Where I see many developers get stuck, however, is when that initial idea turns out to be wrong. At this point, some developers tend to get bogged down and just spend hours or days repeating the same test and getting the same results. It seems to be very difficult to back up and consider a different approach. I wish I knew how to teach the ability to generate a secondary hypothesis when the first one fails! First make sure the developer is exposed to the big picture; this will help in all aspects of his development. Second, when someone hits a dead-end, ask questions to try and get him to back up and look at alternate possible explanations.

Gary.Cooper
Gary.Cooper

I am a big fan of displays. When debugging in any language there are the display commands that will show values. This is always a big help, especially when placed in several strategic locations.

Justin James
Justin James

Some people are just not cut out for debugging! For example, take the following "bug" description: "memory usage keeps slowly going up, by a few MB a day. We need to restart the app server to bring it down, but it always keeps going up." OK, you have a memory leak. Unrelated problem: "after a while, the database connection pool refuses to create new connections, even though the number of users has been steady for days. Restarting the app server resolves the problem." A bad debugger calls these "unrelated", since the errors have nothing to do with each other. A good debugger says, "you are failing to properly release the connections back to the pool, which means that the garbage collector never picks them up. As a result, you are causing a memory leak and blowing out your connection pool." Great debuggers think laterally, and can see the underlying relationships between items that, on the surface, are not related. They also have a superb understanding of the app's architecture, so they know where the bug is likely to be. After all, if you do not know what code works with the database, how will you know where to look to make sure that the connections are being released? A great debugger with no knowledge of the app is worse at solving bugs than a decent one with a good understanding of the app. It may be that this engineer is experienced, but not very good. Or he may just not know this app so well. J.Ja

RexWorld
RexWorld

Have you worked with somebody who could program yet couldn't seem to pick up debugging skills? If so what was your technique for helping them learn debug skills?

Tony Hopkinson
Tony Hopkinson

solving, debugging especially other people's code is different sort of problem. Writing code is merely translation. Maintenance coding (debugging and enhancement) is the hardest of our tasks being able to write code won't help you. Knowing how you think you would have designed it won't help you, unless you are real lucky.

Locrian_Lyric
Locrian_Lyric

Two entirely different skillsets. writing code is like designing a building. debugging is looking for the flaws in the building.

rhomp2002
rhomp2002

While both are about solving, they use totally different skill sets IMNSHO. In the one you are doing puzzle solving on an abstract level. In the other what you re doing is taking on the personality and techniques of somebody else and figuring out how they would solve something. That needs a very different thought process. Being good at one has nothing to do with being good at the other.

Locrian_Lyric
Locrian_Lyric

You learn lots of debugging skills when maintaining someone else's code. 1)Cursing 2)More cursing 3)pounding on the desk. 4)learning just how ingenious idiots can be 5)every odd error the system can throw at you 6)how to use the debugger 7)that breakpoints are your FRIEND

Locrian_Lyric
Locrian_Lyric

the stations main computer keeps calling them "Dave"

oldheretic
oldheretic

This is an age old problem - this person's strength is detail and care (good programmer but narrow focus). A higher level view of the interactions needs a good understanding of cause and effect, and how to apply lessons generally - how to generalise. I saw this problem with some really bright people, who just didn't play around and wreck enough things when they were young (actually a learning process for this skill - if it is done out of curiosity not vandalism). The NLP body of knowledge theorises that we can learn, even when older (I certainly hope so). However, the process is slower. The key issue here is interaction of a module with the external modules. The help you are giving to understand these interactions is exactly right. I advise a short briefing from other team members, say once a week over a coffee, on how their systems contribute to the larger picture. It's refocussing on outcomes and understanding how other modules contribute. Formalise it as a learning circle, keep it simple, keep each session short and productivity will rise for every team within a couple of months. There is no silver bullet, but you have a motivated person who will be a valuable member of the team.

rhomp2002
rhomp2002

What I found was that oftentimes the project is divided up so that you only get a part of it at all. Without knowing how it all fits together you are in the dark at figuring out what is really happening. I ran into that in my last job. The whole thing was broken down and they all had their own turf. God forbid you looked at their turf. My piece was the final one which reported to the customers and I was dependent on the other pieces working correctly or I got the blame. I made it a point to see what each of the other pieces did and would track back until I found the problem, usually in one of the other pieces. Then I would go to them and suggest they take a look at thus and so to see if it was handled right.. If they balked I would take it up a rung. Eventually I ended up being a source for finding their bugs for them and we ended up with a much better product but the turf problems were horrendous. The other thing I found was that if I kept my own team fully informed with what was going on they worked better and produced better results. It was especially useful when I had a medical problem and was out for 6 weeks. Because I had kept them in the full picture of everything that was happening they were able to pick up the slack and keep to schedule. I was so proud of them for that. Had I not done that we would have stopped there or produced a product based on bad assumptions and then had to fix it later. It gave them the knowledge that they could indeed do the job and also kept up the reputation of the team as doing excellent work. Promotions for all were definitely in order and received.

RexWorld
RexWorld

Your advice about not breaking things down, bringing him into the loop sooner is good. I hadn't done it as much because he didn't seem to be getting it anyway, but I think you're right. It's a bit of a chicken-and-egg thing, I have to expose him to the big-picture sessions even if at first it's not doing him any good.

Locrian_Lyric
Locrian_Lyric

First rule I was taught as a debugger.... When you get stuck, get up, grab a cup of coffee, relax. By the time you get back to your desk, you'll have the answer.

DanLM
DanLM

But the fact that you have two separate issue's(memory/database pool) occurring at the same time over a period of days just slaps you along side the head and says... Hey, I'm related. Especially since both are fixed when a server restart occurs. Unless... chuckle, you are only privy to one of the problems. Which, you know does happen in any given shop. Tony mentioned he always starts at the end, and works backwards to find the problem. I do it the complete opposite. I start at the beginning, and check my data first... Then I walk it step by step watching both where code is being hit and the values of the variables. This way you do the process of elimination. Ie: data's correct at the beginning, made it through initialization, move my stop/watch statements further into the code where manimpuation starts to occur. Dan

gene_patrice
gene_patrice

My take on this is that debugging is just like many other things in life, the more you do it, the better at it you get. But even good debuggers with sharp focus on details can miss some details certain days.

dwain.erhart
dwain.erhart

An experienced code writer may not always grasp systems written in an unfamiliar forum. What I mean to say is that if the programmer had written C# code for a SQL environment and was used to how that package tied into his or her code, then moves to Oracle with a J-Initiator, Jrun, J2EE environment, maybe they will be a bit green in this environment. They need to make a connection from their past experience that will enable the "light" to come on in that environment. Often, it is a matter of taking a course or two in coding/debugging for that particular environment. Then, the pistons all function happily. Move one piece of the puzzle and there are often difficulties in understanding just how that particular scenario works. Tie in other users code and you may have what is simple to you, becomes a challenge for someone not indoctrinated in your methodology. I can speak from experience here. When we wrote code using MOTIF, (I know I am dating myself here) It was VASTLY different than my previous environment. Couple that with a different OS, it made for a difficult transition. (AIX - the programmers would store pieces of code in various places - few comments and nonsensical variable names.) When I wrote the modules from the ground up, I could troubleshoot relatively quickly - (after I got used to Unix and Motif). However, when my piece of the code relied on another's code, it took me a great deal of time to get past the learning curve. (I sometimes got so frustrated I found it easier to re-write the module I needed myself.) I had to work hard to overcome my "forget this - I will make my own code" attitude and swallow my pride to ask for help in debugging code. Yuck. My style was quite a bit different than some of the other programmers in my team. I remember MASSIVE frustration when trying to decode some of the stuff my colleagues wrote. After working there a while, using my own initiative and taking some training home on Motif an X-Windows, I could troubleshoot and fix problems as fast as anyone on my team. (I know - I do blather on here.) If this person is good at writing code, can come to a conclusion on their own code, find out what skills may be a bit porous and fill them in, you may end up with a top notch coder. If you cannot, you will definitely be able to lose the dead weight with a clear conscience.

mikewor
mikewor

My son has completed a java course (battling to find a job at the moment) so I've been doing more coaching to a point where I think he is an adequate beginner. He suffers from Aspergers syndrome (a form of autism) and battles with 'the big picture' - so he's fine working from reasonably detailed specs, but debugging is a hit and miss. I've taught my to incorporate the best 'defensive programming' practices so he now gets adequate information to help him debug. But it will be a nightmare to be a maintenance programmer trying to debug someone else's undocumented code.

onbliss
onbliss

But for the most part, the person needs to have the aptitude and skills to debug.

Big Ole Jack
Big Ole Jack

One must know how to "logically" break down a problem to come upon the solution. Also, troubleshooting requires a thorough understanding of the problem and an overall picture of the environment and secondary items that are directly or indirectly affected.

dragon
dragon

Back in the days... We actually had Programmers and Coders. Not everyone was "titled" a Programmer. Kindly do not take this as a bad thing, Coders are very useful in cranking out bulk code. If you leave the debugging to competed programmers the project will operate more efficiently. Now the question becomes, why they cannot realize that they are not debuggers and why do they have such problems to learn? Try http://PillageBeforeYouBurn.com/Incompetent.asp In 32 years of development and management, I've found no better explanation.

SnoopDoug
SnoopDoug

I always caution successful people to avoid the me-too syndrome. If I am a good debugger, and I got a degree in CS and blah, blah, blah, then it follows that anyone who aspires to become good at debugging also should follow that path (and have my idiosyncrasies). I suspect that certain personality types are more common in IT/programming--the "rain man" logical, unsociable nerd we have so commonly associated with geekdom. Common, but not necessary. I do believe that having a strong affinity for logical thinking is paramount, as well as a tendency toward methodical work. However, if you read Soul of the Machine, one of the great debugging moments is in an AHA inspiration. Anyone who has stared at "correct" code for days gets that point. I see no reason why certain techniques cannot be taught. Binary search is one (split the code in half and see if your data path is still correct. If so, the first 1/2 is correct, so work on the second 1/2. Otherwise the problem is in the first part. Instead of a bazillion print statements, use asserts. That way you do not clutter up your code with crap you may have to remove. I did not see any mention of tools. Stepping through source in a debugger can save mondo hours. Put a watch on a variable and continue. Another key issue is whether you wrote the code. The level of effort to debug someone else's code has to be at least 10X of debugging your own code. Note that if you do regular code reviews you can cut this factor to 2X. If you believe the axiom that maintenance takes more resources than the initial development effort, you see the reward. doug in Seattle

m4rk.gm4il
m4rk.gm4il

To have a larger view of his system, encourage him to make a flowchart diagram or UML of his large project. Starting from the large scope until you break it down into detail. That way, he can view the entire picture in one glance. Eventually, it will help him trace and fix the bug. you can download this free diagramming tool at: http://www.gnome.org/projects/dia/

john.ahlin
john.ahlin

Good debuging skills be taught AND learned. Here is the recipe that has worked for me. Define 'What is the problem' first! I know this sounds simplistic but this is the fundemental issue. Once a problem is adaquately defined - the answer - or at least the next step in solving the problem, becomes more evident. How well you can define the problem determines how quickly you can solve it. Let's use an automobile as an example. "My car won't start." is the problem. While there is a problem identified, car won't start, there is no immediately identifiable solution. More information is needed and more questions need to be asked. The skill in debugging is knowing what questions to ask. In the automobile situation questions such as: Have you had this problem before?, Is there gas in the car?, Do your headlights work?, Is there any noise when you turn the key? Has it been behaving badly lately? all lead to different potential solutions - any one of which may be the problem. When we present problems to developers, we tend to ignore the full 'what is happening' and simply say the application has a problem. When we present a poorly documented problem to a developer, they will instinctively dive into the code straight away and start hunting. We as managers, and debuggers, need to better identify the problem before we start working the solution.We need to present the Why's. Many problems can be solved simply by asking the right Why's. The best question - for me anyway - is to ask: 'How would I cause this problem intentionally?' If I can answer this question, I have a fairly good chance of going into the code and finding the right place to start. Want to make someone a great debugger? Teach them to ask the right questions! BTW - whenever possible - encourage your development team to interact on problems. The questions developers ask each other create a synergy of solutions that benefit all! Oftentimes, simply asking a question, presents an answer! One last comment, it is ALWAYS easier to debug your own code. Figuring out code written by someone else has a STEEP learning curve!

Locrian_Lyric
Locrian_Lyric

Is it learned or is it genetic???? I do think a large component of it is how your mind works... I think that a combination of meticulousness and creativity come into play. The meticulousness to attack the problem logically, and the creativity to step outside logic.

djl4fzw
djl4fzw

To me debugging is like cooking. Now I'm no chef. But I do know when something's missing. Sure I have personal tastes. No two spaghetti sauces are the same. But they're both spaghetti sauces. They do similar tasks. They basically have the same requirements. Debugging is similar. What's necessary for this program to run? Do we have the data? Do we have Access to the data? Do we have the connections to the data? It was running last week. Has there been a logical error? What are the basic necessary requirements? Granted too many chefs spoil the broth. That's why there must be a head chef. Chef determines the consistency of flavor. We call them managers. Start thinking about what's missing from the recipe. It helps think about the big picture. It helps focus on what we have vs. what we need to make it work.

Neon Samurai
Neon Samurai

Some are going to be abismal at it; no matter how much literature they read or training they have, they'll just never be great. Some will be average; they learn it, they become good at it. There's always someone worse than them and someone better at it. Some will be great; they learn it, they expand on what they've learned and they come up with mindblowing ideas based on that. Some will be naturals; they looked at the code, looked at the title of the book "how to debug" and just understood it without reading further. This is the genious level of skill in the same way that Mozart first sat infront of a keyboard and just inherently understood music. We'll all fall within those levels of skill someplace.

Locrian_Lyric
Locrian_Lyric

Best lesson I ever learned..... A friend of mine was having a problem with the termination of a scuzzy drive. He did everything right. Went to the company website, downloaded the specs, verified he was doing it right. Checked, double-checked and checked again.... It still didn't work. Then he deliberately hooked the blasted thing up wrong..... It worked. THAT is debugging. You assume NOTHING, including that the "right way" is indeed right.

Tony Hopkinson
Tony Hopkinson

Start at one end, trace back until it goes from right to wrong or vice versa. Look at why, define a fix, prove it is a fix, prove it doesn't break anything else. Pat self on back Rule Number 1. Assuming you know where the fault is, a very bad fault. I've seen people debug very successfully with poor techniques, but very good knowledge of the application, and to be fair a well designed one. As far as I can make it it's not taught in academia, there again much of it is common sense so that' not too surprising

Locrian_Lyric
Locrian_Lyric

I went to school with a guy who was an absolutely brilliant programmer. He finished all of his projects WEEKS before the rest of us. He seemed bulletproof until.... We got to a unit where the focus was on debugging. This guy was completely lost. He had never made the mistakes, so he didn't recognize them. Worse still, he didn't seem to have the talant to debug either. But that's fine. There are some people who are good at debugging and mediocre programmers, and vice versa.

JackOfAllTech
JackOfAllTech

I always get angry when I see those TV commercials that say "anyone can learn to be a programmer...." Yes, anyone can learn the syntax of a language enough to put some code together but NOT everyone can be a programmer. It's the same with debugging, you have to be able to think logically and multi-threaded-ly. Not everyone can look at a problem and gather 15 seemingly unrelated pieces of knowledge into a virtual jigsaw puzzle solution. People like us can fairly often work on something new, see the similarities to something else we worked on in the past and have one of those "light bulb" moments when we suddenly understand how to fix it. I personally love those moments.

mjd420nova
mjd420nova

Patience is a big part of it too, having to sort through hundreds and even thousands of lines of code can be trying, but attention to detail is what it takes. Looking at every colon, semi-colon etc without skipping any is where it will pay off. I also use a set of crib cards to help. Mostly close examination of results gives many clues as to where to look for missed pieces.

rhomp2002
rhomp2002

I think you are absolutely right. If the person who wrote the code originally does not think exactly as you do, then how you would have designed it will not help a bit. You have to figure out how they would have designed it based on your analysis of how they work. It gets even more fun if many hands have been involved in keeping it up to date as each one will have a hand in what is there to figure out. Personally that if my favorite thing to do in data processing. Much more of a challenge than just coding something.

Neon Samurai
Neon Samurai

I'd be willing to bet that someone who's spent twenty years assembling buildings would have a pretty good idea of what makes for stronger versus more brittle construction techniques. Programming is more of the assembly than architectural phase. You do bring an idea too mind though. Why not apply old Egyption law to programming. A professional who builds a house and has it fall is responsible for it; if the house collapsing kills someone, they suffer the same fate. I bet we'd see a whole whack of stronger code released if that law where modified to apply to programming.

Absolutely
Absolutely

I guess so. Debuggers & break points, indeed. As for 1-5, I relieve stress with exercise. I'm getting much thinner recently!

alaniane
alaniane

and then come back to the problem. I have even found bugs while driving home. I will get to thinking about a particular problem and then realize I need to try this or that out. Even a good night's sleep helps solve some problems.

royhayward
royhayward

Well, not only then, but from time to time I run into problems that I bang my head against with not results. I learned early in my career when I would bring the code to bed and be going thru it before sleep, that my mind would keep working while I slept. I then wake in the morning, or sometimes in the middle of the night and have come up with the solution. I have even had to tell my boss this on ocasion when she wants us to burn late hours. "This is one I can't solve while I'm awake. I will show you the solution in the morning." After I produced results, she now comes to me with problems that others have hit the wall on and asks me to sleep on them. (the problems that is.)

Justin James
Justin James

A cup of coffee, cigarette, sandwich, or even a shower is where and when most ideas of where to look occur. I am always cautious about the developer who spends the whole day at their desk without leaving. It makes me wonder, with all of the visible signs of "productivity" occuring, when they actually *think* about what they are doing. J.Ja

DanLM
DanLM

I'm talking application errors, not network or database errors. Database error's are a nightmare if you have corrupt tables. 1). fix them, 2). What app caused the errors. But an application in production that blows chunks on you is where you hope that standards are followed when it comes to exceptions. Because the person that wrote the application probably is not the one that will fix this error. And they will be walking into the logic cold. Thus, standards are important at this level for handling errors. It assists in identifying where the error actually occurred within the code. Hopefully some short description message describing the error. And also including some indication of what the data was that caused the error. Ie: Blew chunks on policy/patient/claim # in class calcMedPrice on invalid quantity. Again, this is where adherence to standards is so important. Exception handling should be consistent across all applications so that: 1). They are placed where they should be. 2). Information provided is always what is needed. Now, if you are getting incorrect results after the application has worked for a long period of time and it hasn't been changed. Your now in the easter egg hunt. What data caused the incorrect calculation. Who populates that data. Was it user input corruption or calculation corruption. If it was user input corruption, how did the data entry get verified at time of entry. How did it get past the verification. Ahh yes, I use to love production support when I was young and full of sh.. Wait, I'm still full of it. Just not young anymore. Dan

Tony Hopkinson
Tony Hopkinson

The end is where the problem first got noticed. Not always anywhere near and sometimes 'nothing to do with' the real fault. In a clean design, where the source is known you might be able to go forward til, it breaks Given application knowledge you can jump about a bit more. Like error is 'invalid value on form', but that value is in the database. As a PS if you get an error like that makes sure your form is pointing at the right data, as others have said assumptions will bite your ass. Memory type errors are a git, good coding practice and tools...

Justin James
Justin James

I essentially use one of the standard search algorithms (Quick Sort, if I remember my algorithms correctly) to find bugs. I start halfway through the code change, and check inputs & outputs. That tells me which direction to go in, so I go halfway up (or down) the chain, rinse and repeat until the source of bad data is found. It rarely takes long. For more bizarre items (the kind without line numbers or logging), that's when I need to start doing things like finding every reference to the offending call or variable or object. Fun. J.Ja

Locrian_Lyric
Locrian_Lyric

and I also like to try to make the bugs worse by throwing nonsense data at the problem and take it through multiple routes. I like the forward approach as well because at times when I've worked backwords, I find that a bug can actually be the result of multiple sources... By taking an approach similar to yours I can often catch the contributing errors more easily.

SnoopDougEDoug
SnoopDougEDoug

Good grief, talk about encouraging bad habits. Just hearing "cranking out bulk code" gives me shivers. I can just see the annual reviews: Jim added 10000 lines of code to our app Doug updated 100 lines of code Therefore, Jim gets a 10% raise and Doug gets squat. Did this leaving the debugging to competent programmers really work? Who the heck wants to only fix the screw ups of others? This is not the fun part of the job (for most). Talk about encouraging bad habits. Treating software development as cranking out product is nuts. I much prefer "you broke it, you fix it". I once worked with two other devs on a project. One, Nick, was excellent. The other, Jane, was terrible. Not only did she frequently check in code that did not even compile AND BROKE THE BUILD, but she would infuriatingly add log statements that were never removed from her code (we were working on a distributed app, so log statements were invaluable to trace a problem). The d*mned log files would grow so fast we would have to truncate them often. I finally got so frustrate with her lack of detail that I wrote my own logging class so I could log just my stuff. The real crusher was when I got a raise. I told them that Nick also deserved a raise and was happy to hear that he had also received the same raise. I was disappointed to find out that Jane had also received the same raise. doug

rhomp2002
rhomp2002

I think when people have coded something and they are checking it out for a problem, they tend to overlook things because they know what they did. When I looked at what others did I would examine it more closely and oftentimes see the problem they had overlooked. As an example from COBOL days, I started working for a team with a new job. They had one program that was working sometimes and other times not. It was adding up columns of time expressed in 0.25 increments and usually worked well but on some pages it would be off by .05 or .10 or .15. They had all had a crack at it and in over 6 weeks nobody had figured out what was wrong. I asked to take a look at it even though I had never seen any of it at all. It took me 15 minutes to find and correct the problem in a program of 10K lines of COBOL code. The problem was that at one point they had the columns add into a counter with 1 decimal position which would drop the .05 from the .25. I changed it to 2 decimal positions and the program worked perfectly. They had all assumed that the definitions were correct and skimmed over them and I had figured out that at some point they were dropping the second decimal position. That is why I think it is easier to debug someone else's code, that is assuming you can put yourself in their logic, than it is to debug your own. You will tend to assume you did something because you normally do but if it is someone else you won't make that assumption.

Tony Hopkinson
Tony Hopkinson

In an event driven, OO, multi-threaded environment? Very few cases where a flowchart would be valuable and in 99% of them it would do little more than document the obvious.

rhomp2002
rhomp2002

I was in the business for over 40 years and my greatest strength was finding and fixing bugs. The method was first figure out what was the problem really, what could be causing the problem to happen. Then figure out at what point in the process that problem could occur. I would take it from the end where the problem was and track back until the error was not an error. I would then look to see if the input at that problem was really correct or if it was wrong. If it was right and you still had the problem later, then the problem was the code. If the input at that point was wrong then you had bad input. What I found was people tended to mis-identify the problem. They would think it was occurring where it showed up and not where it really happened. As a result they would fix it at the end of the process rather than where the problem actually was and end up with a process that had bandaids all over the place instead of one fix at one point in time. I think another part of the problem is being able to visualize what the users actually do. I have seen so many programmers who visualize the ideal situation in their minds and program that way. That is not what users do. Murphy was an optimist. Users will do whatever they can do and you can take that one to the bank. You need to be able to figure out what they might do or can do and plan for how to stop it or correct it. In debugging you have to figure what they just might have done rather than figure they did the correct thing. Most of the problems I solved for the users were not because of my changing the program but because I figured out what they did and pointed it out to them. Once they saw what happened when they did this, they stopped and the errors did too. I think that you can possibly teach people to debug to a degree but it still takes someone who, as Beth said above, is good at pattern recognition. You need to be able to see the pattern in what happened and then you also need to be able to visualize the whole system and where that pattern would fit within it. That requires people who can do both - visualize the whole system and still visualize the minute parts of it - at the same time. That is not something you can really teach completely. Some will be able to do it but most will not. Personally, although the industry does not seem to recognize it,I think that there should be parallel tracks for a career. There should be a new project track for those who are good at that and there should be a maintenance track for those who are good at that function. What I see is that newbies keep getting thrown into the maintenance function and then promoted to the new project function as if it were a reward for undergoing a penance. I would personally rather have just stayed in maintenance because I found it very rewarding. I love solving puzzles and problems and I find that there are just so many ways to do new things and that becomes boring. I guess it just depends on what kind of mind and attitude you have. Finding problems and fixing things interests me more than generating code.

Freebird54
Freebird54

is your enemy in debugging - it may well be where the bug came from in the first place! Dedugging can be as simple as flagging (using whatever language-specific tricks you have to) what calls are being made in what order - and seeing that section 123 is being called from part E, which should never happen..... (there is nothing in there that should ever change that value... :) )

Freebird54
Freebird54

by an old time Cobol programmer a simple way of tracking anything - and of creating most programs too! It starts off with ensuring you have Beginning Middle End of the program as a whole, and for any subprograms within it. You can even follow it through with 'modern' techniques. the Beginning includes all things that need to be done to set up operating conditions (includes creators, GUI setups whatever) The Middle does the work - even if the work is responding to the user. The End is the cleanup, including destructors and shutdowns. It is absolutely amazing how fast a program can write itself that way! And how easy it is to home in on a bug's 'home territory'. Sure cuts down on the amount of code you have to ponder...

SnoopDougEDoug
SnoopDougEDoug

There are very few of us who cannot improve our skill level in most of our activities. You imply that once average, always average. Perhaps, if you never work at it. I am a mediocre golfer. I know that if I want to get better I need to 1. Take lessons 2. Practice more 3. Play more. I am content being a mediocre golfer. Now if I am a developer and recognize that I do not have the level of debugging skill that I desire, I must push myself to get better. So how does one do that? How do you improve your debugging skills? I cannot recall any classes at the local schools with such a title. doug

shardeth-15902278
shardeth-15902278

but some, as you say, are naturals, it just 'clicks' for them, while others may have to invest more time and energy than is worth their while.

michael.clark
michael.clark

As a web development supervisor, with 15 years coding experience, I was totally caught off guard with how difficult debugging a distributed platform seemed to be for the developers. Some with 18 years experience (Cobol, c, Fortran you name it) had no clue once I got them. Was it the client, the server, the SQL server, The T-SQL, etc... Was I just that much smarter? What to do? Until I went back to my network experience days, and this older analyst Doug. Doug was methodical, he had a checklist for everything and he went through the list. Not only did he fix every issue ever thrown at him, he often found problems we didn't know we had. He was not necessarily fast, but when he said it was fixed, it was. So I built a set of basic diagrams, flows for debugging. Given my experience I set up starting points (what if this error comes up) and suggested ways to work through the problem. Junior programmers use it as a starting point, stepping through the process each time the same way, considering the issue at each step. Sounds stupid to have to do, but consider that?s how they also train EMT/paramedics to troubleshoot. Aside from the typical flow diagrams, I demand that they draw a ERD for the application, and detail the layers involved, and in a web application all the pages, what roles, and what relationships to each other. Not only is this sort of documentation helpful in general, a picture is worth a thousand words. The problem I see is people don't approach the problem methodically, they sort of scatter their attentions on what they think might be the issue, and walk right by the problem. While I train them I let them suffer a bit, rather than looking at their code, I make then present their code as a walk through. Make them present the problem methodically; often once they have to present the issue, the error becomes obvious. It also becomes obvious to me what they are missing in their troubleshooting protocol, so I can train them. I will ask questions, if this is the input and we know that the error is X, what is happening in the business layer? Make them answer that question. All to often we are in a hurry and simply solve it. Teaching programmers is tough, because a problem solved by me, is not learned by them. They have to step through the issue, with guidance at first but the suffering has to be on their side. Sometimes that means telling them check these items again (or for the first time) and when you?re done with that I will come back. OK, so you have a protocol for troubleshooting, you have documentation so the person can visually see how the system relates, and when they ask for help your doing a code walk through and asking questions rather than telling them. After the fact you need to ask them what they learned, and write that down so next time they can consider that as well, especially if it leads to the fix. Eventually the person will build a database of knowledge, and ironically not need it anymore. Enter the final problem, sometimes, you get a guy who solves his problems through others, he did it in school, he does it now. It?s a bad habit, he can, but he won't. Why if it?s easier to get you to solve the issue. Even so, unless he's truly using you the above protocol I use trains a developer to debug in about 3-4 months. By the way, I also have a game I use with my staff. Find a problem I cannot solve and I take you to lunch. No one has collected so far, but the issues are getting tougher as they learn to fix the simpler issues. They are on a bug hunt for the bug that will get them the lunch. good luck

Justin James
Justin James

Yeah, that's so true. If you did everything right once, then verified to ensure it is right, then obviously, "right" is "wrong", which leaves "wrong" to be right! J.Ja

Justin James
Justin James

Yeah, that's so true. If you did everything right once, then verified to ensure it is right, then obviously, "right" is "wrong", which leaves "wrong" to be right! J.Ja

GoPadge
GoPadge

I was taught by some of Uncle Sam's electronic technicians to divide the work in half and check in the middle, if it works in the middle you know the error's further on. Continue weeding out half of what's left until you've reasonably isolated the issue to one area. Then begin your start to finish search. Of course that assumes you have a decent understanding of the logic flow and what results you expect at each testing point. In programming it is harder to divide the work in half, but judicial use of comments can take pieces of logic out of the loop while testing.

torchy
torchy

"...much of it is common sense so that' not too surprising." Yes, but unfortunately, there are some that lack this common sense. We just have to accept and live with that - like it or not. If in a team, the best way would be if the leader could recognise different strength and weaknesses in the members and utilise them where appropriate to draw the best out of them to help each other ? It's teamwork.

sjohnson175
sjohnson175

for the COBOL classes while in school. Some people just simply couldn't track down bugs or think in logical terms as to where a bug might originate. Love the "light bulb" analogy too. The problem is how do you put those sorts of moments on a schedule? The business world wants a production line. Not a craft shop.

bonniebeth
bonniebeth

I agree wholeheartedly with this response. When I tell people I program they say "oh you must be smart" and I tell them not neccessarily. I have known some stupid programmers through the years. I think troubleshooting is a genetic skill but one that can be learned to an extent. I don't consider myself the best of programmers. I'm not highly technical. But I am a good debugger. I have an imagination (I know how to think like an end user) and I'm a puzzle solver. And the two aid greatly in figuring out what could possiby be wrong. But I also believe that with enough experience anyone can be taught the basics of debugging - just like anyone can be taught the basics of programming.

RexWorld
RexWorld

Your point about attention to detail is good, I hadn't quite thought of it that way. But it definitely applies in this case--the guy I'm working with who has problems debugging is definitely not a detail-oriented person. You can see it in his coding style--he's quite inconsistent about stuff like indentation, capitalization, etc. To the point of being a bit sloppy. Nothing major but it is probably a telling sign like you say.

IAFarm2
IAFarm2

"You have to figure out how they would have designed it based on your analysis of how they work." IF the employers of the programmers do their jobs competently, they require that all lines of code be documented as they are written. If "the guys in deep carpet country" are just interested in getting applications out the door, regardless of the "maintainability" of those applications, that's when these kinds of problems arise.

Absolutely
Absolutely

You shoot your computer? That doesn't seem like a very marketable approach to programming ...

Locrian_Lyric
Locrian_Lyric

"Code as if whoever maintains your code is a violent psychopath who knows where you live"

Locrian_Lyric
Locrian_Lyric

as I posted above... I solved a problem on the way to the company picknick once..

Freebird54
Freebird54

to get a job where you can work from home a good percentage of the time! When you have the winning idea - you can see if it works right away....

SnoopDougEDoug
SnoopDougEDoug

And don't forget the value of just talking a colleague into sitting down while you explain the problem on a white board. In more than one instance I discovered the cause while explaining my problem to another. The absolute worst was when some idiot (moi) created two variables that were off by capitalization. (You VBers can stop laughing now). Nothing like finding you have index and Index in the same module! doug

Locrian_Lyric
Locrian_Lyric

that was bothering me all week, in my car, on the way to the company picknick the following saturday!

Locrian_Lyric
Locrian_Lyric

That's one of my best weapons... I send garbage through the system to see where it comes out. (of if it comes out in the rare event that the developer has included proper error handling) it makes it a good deal easier to spot where the process is faulting

alaniane
alaniane

With our app we have several reports that use a report generator that does not have a debugger for it. The errors generated are often times cryptic and you have to comment out macro functions to try to find which one is throwing the error to begin with. If they had added a simple debugger to the app, it would make life a lot easier.

Justin James
Justin James

The problem is when you see business rules like: If A then if b or c then Do something else if b and d then Do something else if g then Do something else if b or c then Do something else if b and d then Do something I know it is kind of hard to tell on the forum, the way they post it, but you have a block of logic repeated twice. As a result, change the business rule, and you need to change that logic in two places. Miss it in one spot, and you have a mess. And the worst is when the rule changes so the formerly identical block in different sub clauses now needs to fork to stay the same in some spots and change in others... J.Ja

Locrian_Lyric
Locrian_Lyric

I try never to layer my own logic... but if I come accross someone (usually an old-time C programmer) who loves those annoying shortcuts... A = B = C = D = 1 which are made worse if one of those is a reference to something else... Anyway, what I will do is break out the logic to it's components and comment out the original code 'A = B = C = D = 1 A = 1: B=1: C=1: D=1 rather than try to figure out where in the formula it's breaking.

Justin James
Justin James

Before I start stepping through the code, I like to set a breakpoint halfway through that chain, see where the input stops passing, or if a required call is not being made. Or worse, trying to debug complex logic, like four layer logic statements, and you really, REALLY would prefer to pretend that the problem might not be in there...

Locrian_Lyric
Locrian_Lyric

Those are the ones that keep me up at night.... and the worst of those are the ones that do 'nothing'. you click the button, no error, no output, no idea what just happened. then it's.... step...step...step through the code... see which function didn't return a value...

Tony Hopkinson
Tony Hopkinson

after having a bug demonstrated, when you are sure you fixed it. :D Look at the code no fix, blame gremlins. Need a psychic IDE. :(

Tony Hopkinson
Tony Hopkinson

as a specific diagramatic convention with implicit linearity. A few scribbles to help you think through something are fine, but I've never seen any documentation convention which didn't impose it's own inherrent structure on what is being described, exactly the last thing you need when debugging.

alaniane
alaniane

Sometimes just diagramming the functions used will help spot the bug. Even in an event driven environment, you can use a flowchart to map the process. The key is to get the person to draw out what is taking place. When I flowchart out the processes, I don't worry too much about adhering to the standards for UML or flowcharts. I'm only trying to picture what the program is supposed to do. Then I have a reference for what to check and why.

alaniane
alaniane

It also pays to make sure that the bug is with the code to begin with. Before tackling a bug, I also try to find out how the user got the bug. Sometimes, the bug lies with how the user uses the program and not with the program logic itself.

KK Aw
KK Aw

First, I think is important that when debugging, the person mentally accept that there is a bug. I have seen people struggling because of this. Next, I think in terms of inputs, process and outputs. After I find which process is involved, I check the outputs. If they are correct, than I move to the next process. If they are wrong, I check the inputs. If the inputs are correct, then it must be the current process process. Otherwise, I move to the prior process. and repeat the debugging process.

Locrian_Lyric
Locrian_Lyric

I have Asperger's syndrome and I am an intuitive programmer/debugger. I belong to several autistic groups and more than half of us are in IT.

graeme.m.ross
graeme.m.ross

I have been in this industry for 25 years (10 of which as a university lecturer in the late 80's and early 90's) and over this time I have made several observations. 1. In university I taught classes of 60, of which in a good year there would be 5 natural programmers, the rest could be taught to program but would never really understand what they were doing. (I was considered to be a good lecturer with good pass rates, this observation was verified year after year for almost ten years) 2. Most students could be taught to debug at the level of inserting print statements in simple programs, however throw a debugger at them and they were swiftly lost. 3. Good programmers have a way of looking at the world that is not completely normal (it is slightly autistic). This way of looking at the world can be taught but it can only come naturally to very few. Bye the way if your programmer is too autistic then they are worse than useless because they are unable to communicate with the rest of the world. Good programmers are almost invariably good debuggers, they understand what their program is doing and where it can possibly go wrong. 4. Most computer science graduates will swiftly get themselves promoted beyond the "simple" programming tasks, to jobs like "Project Manager", not because this is a natural progression, but because they are never comfortable with the programming tasks. 5. The good programmer will tend to get promoted to system analyst/design types roles but will still keep themselves deeply routed in the actual coding tasks. Coding is a skill which if you don't use it you lose it! If you lose it you cannot design properly! In conclusion I suspect that less than 10% of students who do computer science degrees actually become and stay programmers for significant percentages of their careers. The rest move on to other easier (and more compliant with their ways of thinking) jobs.

shardeth-15902278
shardeth-15902278

I did say ...most.. and ...virtually... Certainly certain attributes, characteristics and talent, can give a person an advantage. On the other hand, were I to decide I wanted to become a great basketball player, and invested ALL my time for... say... the next 30 years (assuming I didn't age ;) ), training, I probably could become pretty great at it, certainly better than mediocre. But then I never claimed 'sanity' as a talent of mine...

Neon Samurai
Neon Samurai

Yeah, we do balance out each other well. I wouldn't complain if she had even the smallest amount of interest in tech toys but she also wouldn't complain if I spent less time mucking with the machines.

$dunk$
$dunk$

[i]I still have this notion that most anyone could become great at virtually anything, IF they dedicated enough time[/i] Your theory is easily disproved with one example. Do you honestly believe that most anyone could become a great professional basketball player, if they only spent enough dedicated time? If you are a sane person your answer would have to be no. Given that, it is the same for pretty much all skills. Some people are great because they work at it and they are born with the talent. Others may be able to become mediocre, if they are lucky, no matter how much time is spent because they just aren't born with the talent.

Locrian_Lyric
Locrian_Lyric

I can use myself as an example. I have Asperger's Syndrome. I am a GREAT debugger because I have an ingrained ability to recognize patterns. I am, however, a complete and total lost cause when it comes to physical prowess. I jokingly tell people that I had to work my way up to 'clumsy'.

shardeth-15902278
shardeth-15902278

I still have this notion that most anyone could become great at virtually anything, IF they dedicated enough time (keeping in mind that there is not an infinite quantity of time alloted to us). But, as you point out, why bother? It would make no logical sense to work so hard at something we don't enjoy, just to become 'great' at it for the sake of becoming great. Much better rather to invest time discovering our 'talents' and expanding on those. And what is really cool is when people can recognize their strengths/weaknesses, and synergize with others who have s different skillset (such as you and your wife do, I imagine). -okay, probably time for me to shuddup.

Neon Samurai
Neon Samurai

These are not the people who would go into computer science in the first place but there is likely to always be a small group that just can't develop a specific skill. In the case of my Wife: If she's adding and subtracting financial amounts then she's a wiz. Percentage calculations all done on the fly without a second thought. - If it's money. The moment she thinks about those same figures and calculations as anything but monetary values, things become complicated. Now, her literacy is through the roof. Writing, she just gets. Most essays written the night before due dates all through school returned usually with a 90% or close to it. She read long before she started school and was going through books studied at the University level while the rest of the English class stumbled through A Farewell to Arms. In my own case: Grammar and spelling make no sense to me. Even when the make since, I managed to get it wrong. Well, they make sense and I've not given up on bettering my grammar and spelling but it's the skill I just can't get. The content is fine but the actual character presentation of that content; I do my best. As for anything computer related; I just get it. I may have to ponder a little to fully understand a concept but for the most part, it just makes sense.

Tony Hopkinson
Tony Hopkinson

However as well as LLs comment that you may not be looking at the entire bug (symptom fixing). I use my intuition but I don't rely on it. It might give me some ideas on where to make my first test. But I do test, I don't assume. There's nothing more guaranteed to set my teeth on edge more than someone who bounces about through code learning that what they thought was the bug, wasn't. Intuition, could be I changed that yesterday. I have a vague memory of a wee bodge I did around that to get something out of the door, to being recently familiar with the code. I'm right more times than I'm wrong, intuition isn't a guess, it's a clue from your subconcious. Clues aren't solutions though, they just help.

Locrian_Lyric
Locrian_Lyric

intuition is analogous to seeing a leak in a radiator hose, then checking the rest of the hoses, the water pump, the radiator and then the gasket, because a care, like a program, is part of a system. Just because you've found one problem and fixed it doesn't mean your problems are solved.

SnoopDougEDoug
SnoopDougEDoug

Intuition is typically used by people who randomly poke around trying to fix bugs. I equate it to what is called "scope and grope" in hardware repair. It is also analogous to fixing a bad spark plug in a car by first replacing all four tires, then the motor. When I ran a motorcycle service department, my first question to the customer was "What is it doing or not doing?" Without a systematic, logical approach to debugging, you are just applying random chance to fixing the problem. So what happens if you get stuck and have to ask for help? My first questions to you would be "What have you tried so far?" and "What have you concluded could NOT be the problem, and how did you come to that conclusion?" Hearing that you randomly poked print statements or assert into the source would not give me a warm and fuzzy feeling. doug

alaniane
alaniane

Intuition can also bite you. I think a good mix between intuition and a sound methodology helps me debug. Sometimes, I have a feeling where the bug is; however, I will still develop a methodology for proving that feeling. Some of the biggest errors I have made have occurred when I didn't counterbalance my intuition. Generally, after looking at the problem, I will try to think of where the problem could be occurring. Then I will run the program at some point before that area and check the results. If the results are valid then I proceed until I get invalid results. When I debugging a distributed application, I try to first estimate which parts are likely to cause the bug. I then methodically validate that the other parts are giving valid results. Then I proceed to check the suspect parts.

Locrian_Lyric
Locrian_Lyric

I'm very intuitive, and I usually use my intuition first, then follow up with a more methodical approach if that fials.

$dunk$
$dunk$

I agree that, even the best do approach debugging methodically. However, that methodology might not be clear to them (because they naturally do it) and more importantly, that methodology may only work for them. So don't think that simply writing down a methodology will allow someone to learn to become successful at it. What works for one person doesn't necessarily work for others. Also, while being methodical has its' advantages, nothing beats intuition, talent and skill!

Dr_Zinj
Dr_Zinj

Both these individuals appear to be useless drags on your company. When they object to asking questions to define a problem, it's a clear indication that they aren't interested in solving the problem themselves. i.e. they don't want to do the job. They brought problems to you for you to solve for them. Again, they weren't interested in doing their work. Harsh as it may sound, at the point you got called on the carpet for trying to lead them to discovering how to do the work themselves was the point you needed to decide whether you should still be working there. Best thing to do would be to jump over the head of the person calling you on the carpet, and explain the that person what the problem is, what you're proposed solution would be, and request resolution. If and when it didn't happen, cite that to the CEO as to why you're leaving the company.

Dr_Zinj
Dr_Zinj

You hit the nail on the head there Michael. Debugging is all about methodology. Yes, you can do shortcuts if you are really familiar with the language and are good at pattern recognition; but even the best approach problems methodically.

C_Tharp
C_Tharp

this teaching technique has gotten me into hot water. I approach the teaching of programming and debugging techniques just as you describe, explain, then ask questions that when answered will lead the student to the solution. This process has worked well for me throughout my career. That is until I had students who did not respond. When staff changed at our small company, I was tasked with teaching them how to do the work. In the beginning, I explained everything without expecting them to know anything. I provided entity relationship and data flow diagrams which were later referenced. As they took over the work, I shifted to testing their knowledge and basing my instruction on their answers. Of course, if they had not been taught something, I started with explanations. When they brought a problem to me I would start with basic questions needed to define and resolve it. This provided information that anyone would need, including me, and it should illustrate to the students how to approach a problem of this nature. Next, the questions would probe their knowledge and use of the information so that I could understand what guidance they needed. The technique worked for two staff, one a programmer and one with only a meager understanding of programming. Then, I had a new supervisor followed by a junior programmer who were learning the company systems from scratch. Both were suppose to be programmers. The problem arose immediately. They objected to questions, even the questions that were necessary to define the problem. They took offense to questions that were purely objective. When they brought a problem to me, they wanted to be told exactly what to do to resolve it. They did not want to know anything more. They refused to reference the diagrams. I was called on the carpet for responding to questions with questions. Eventually, I was forbid from asking the junior programmer any questions. So, I was left with resolving all problems myself. They learned nothing and the problems never stopped coming to me. I needed them to learn so that they could take some of my load and let me move on to other work. There was every incentive for me to teach them as best I could. Unfortunately, the obstacles were unsurmountable. My point in telling this tale is that it does not work with everyone and can even put the teacher in a bad position. The teacher must decide early if their teaching techniques will work for the student. If not, use another technique or bow out of the job.

ian
ian

Agree entirely - each time you find which "side" of your split the problem is you reduce the area you have to look by a factor of two. It doesnm't take long to isolate individual components, be they code or hardware. In a more general sense, the problem is that people aren't taught pure logic. Debugging is a matter not of exhaustively (and exhaustingly) going through line after line of code but of identifying exactly what the problem is, then isolating the parts of the program that could be causing it, then inserting comments / extra code to explicitly test them. I recommend "Zen and the Art of Motorcycle Maintenance" to all my programmers......

SnoopDougEDoug
SnoopDougEDoug

(Present company excluded, of course). I seem to recall reading recently that it is a common human frailty, especially among the incompetent ones, to grossly overestimate your abilities (I'm not referring to CindyPsych if anyone thinks I am). So it wouldn't surprise me if the poster found that the dev in question felt he had above average debugging skills. That is key to "fixing" the problem. The first step is to admit you have a problem. I will own up to not being the best developer on earth, or even among the best. Fixing bugs takes a special mind set. Detail oriented--but still able to see the big picture, persistent--but still willing to ask for help after a suitable amount of effort, logical, among others. I think the worst trait is impatience. Without patience, frustration is assured. Once you get frustrated, you are doomed. And don't forget you have to be able to tell your boss "I have no idea how long it is going to take to fix this bug". (They love that, by the way, NOT!). You also have to be able to look them in the eye and tell them that you have been at the keyboard for 16 hours straight and are going home to sleep. Fixing a bug when you are tired is often the best way to create two bugs from one. doug

CindyPsych
CindyPsych

I heartily agree. I am an excellent troubleshooter and debugger. I can help people who have much more experience than I do and who are far better then I am at programming. I believe it's a talent for pattern recognition or something like that. I happen to be good at taking lots of input and recognizing the one that doesn't belong, even if I'm not familiar with the data being analyzed. And I can imagine that a particular person's debugging skills might improve with experience but if they just don't have that "talent" they may never have it.

Locrian_Lyric
Locrian_Lyric

sometimes it's a big red flag that management has given you 3 months to complete 9 months worth of work. When you're under the gun, neatness is always the first casualty. Mind you, I'm a maintenance coder, and have to clean up the messes, but I place the blame where it belongs.

LyleTaylor
LyleTaylor

Whether or not something like Hungarian notation is used is irrelevant (I personally can't stand it). What's more important is consistency - self-consistency and consistency with other code written at the organization. Sloppy, inconsistent code is a big red flag...

SnoopDougEDoug
SnoopDougEDoug

Hungarian notation is insanely wrong! Any half-a$$ed editor will show you the data type. The more important value of a variable is using a name that conveys the intent of the data within. And don't get me started on magic numbers. Nothing like trying to figure out what 2 signifies in if ( value < 2 ) (I saw this in a banking app where the previous developer wanted to make sure the application had at least two years of the user's work history. I took me hours to trace down the meaning and change is to a const MIN_WORK_HISTORY_YEARS). In a former career I managed the service department in a motorcycle shop. You can tell a lot about a mechanic just by how they treat their tools and how their work space looks. Sloppy bench with dirty tools usually means a "quick-and-dirty" wrench. A clean bench, organized toolbox usually means a good wrench. I suspect much is also true of a good developer. Organization and attention to detail are usually ingrained. I also suspect that we are often our own worse enemy. In our effort to help another dev, we are enabling their weak debugging skills. I suggest the next time this dev has to debug something, leave him to his task. Insist he do it on his own. That's not to say if he asks a pointed question that you should not answer. However, if it appears he is just trying to foist the work off onto another, tell he that no one has time to help and he is just going to have to do it himself. doug in Seattle

david.c.brown
david.c.brown

I have seen some programmers who cannot seem to tie their shoes correctly, but can produce quality code consistently. But, I can see the concern here as with your point.

Locrian_Lyric
Locrian_Lyric

The band Van Halen would include in their contracts, a rider stating that a bowl of M&Ms be placed in their dressing room with all of one color removed (brown?) The purpose of this was to have a very clear indicator as to whether the contract had been reviewed carefully, as they had very specific structural and electrical requirments. If the bowl of M&Ms had the wrong color in it, they would without exception find other serious, and potentially dangerous problems elsewhere...

Justin James
Justin James

... is why stuff like Hungarian notation is insanely important. If someone cannot adhere to a simple standard captilatization, would you want them writing your code? I sure wouldn't. Let's put it another way. If you went to the mechanic, and he kept losing his pen while writing up the work ticket, wouldn't you be a be concerned that a bolt or two might not find their way back into the car? J.Ja

Editor's Picks