Reddit mentions of Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems

Python is a good choice primarily because of the culture around it of focusing on teaching new folks and documenting things for new folks. It is an excellent first language both because:

• It makes lots of things easy. You don’t have to worry about pointers and memory management for example.
  
  
• It makes things more explicit
  
  
• It has relatively few “gotchas” ^(but it does have some)
  
  
• It has a wide breadth of existing libraries so that you can get to the point of being able to write useful scripts fairly quickly
  
  The first key skill when you first start programming is that you are able to write a buggy program, run into an error that makes no fucking sense, and confidently break down that problem, figure out what went wrong, and fix it. Python provides better tools for doing that than many other languages. ^(look up pdb and py.test) once you are able to write and debug short programs, you can call yourself a programmer and then build on top of that foundation.
  
  A good starting point is this free book followed by this free book by the end of which you will be able to build a dynamic website in python.
  
  There are disadvantages to python. They mostly don’t matter as much when first starting out, but as you gain experience, you should expect to be annoyed by these trade-offs.
  
  
• Its explicitness comes at the cost of preventing you from doing some of the nice thigs ruby lets you do to make your code cleaner.
  
  
• By abstracting away memory management, it means you don’t learn memory management. Once you feel confident in yourself that you can write programs, its worth trying your hand at a lower-level language. I hear rust is nice.
  
  
• It doesn’t have the best functional programming abilities and functional programming can be quite powerful. If you find a class with really good pedagogy that teaches in racket or Haskell, its worth taking it. Kinda mind-blowing.

After the Pragmatic Programmer, Debugging.

As a starting out programmer, so much of your time is spent debugging, and this very short (can easily be read in day) book will probably cut that time in half if not more. I mean you can read it in 6 hours, and it could easily save a new programmer 100's of hours in a year.

I see the same problem on StackOverflow on a daily basis - someone posts a chunk of code and says "Help - my code is not working!". I keep a standard response to this on hand, as it's such a regular occurrence:

> Welcome to Stack Overflow! It sounds like you may need to learn how to use a debugger to step through your code. With a good debugger, you can execute your program line by line and see where it is deviating from what you expect. This is an essential tool if you are going to do any programming. Further reading: How to debug small programs.

But the broader problem of course is that colleges simply do not seem to teach students how to use a debugger, or debugging techniques (arguably more important), or even development tools in general. I think the excellent Agans book, Debugging should be required reading for every undergraduate programming course.

Another pet peeve is that students seem to be completely oblivious to the need to (a) enable compiler warnings and (b) take heed of such warnings.

For me, it depends on two things mainly: my current level of focus, and my understanding of the problem I'm trying to solve (actually, it would be better to state that as: my understanding of the solution to the problem).

On focus, sometimes I have a spec'd out system (so I know exactly what I am going to code, often I have good pseudo-code), and I can write 500 lines of code in a couple hours. Other times, I might have the same spec, and it would take me 5 days to write the same 500 lines. I find there are a lot of variables that contribute to my level of focus. I find that I focus much better after vacations, which is why vacations actually make me more productive. I focus much better when my body and mind are in a good state - physically fit, which is why exercising is so valuable, well-rested, sufficient nutrition, how happy I am. Spending a decent amount of time outside each day, even 15 minutes, makes a huge difference for me (could be vitamin-D production). Personally, I focus much better when I listen to music than when I don't (if it's non-vocal music, it drowns out external stimuli). I have two monitors at work, and if I want to get into serious coding, I never have a web browser open in my second monitor. I usually try to keep my IDE occupying both screens, and if I need textual information, I copy it into a blank document in my IDE. If I need to reference a paper, I print it out. Caffeine can give me a temporary boost in focus, but usually results in a longer period of poor-focus.

Sometimes I work on an open-ended problem, where the problem is simple, but the solution is completely unclear. Not "bugs" per-se, but research, often involving somewhat fuzzy math. I might spend 10 days manipulating 50 lines of code. Other times, when a bug crops up, I know exactly what the issue is and I can fix it immediately.

I've heard as a rule of thumb, a good programmer will generate 50 lines of completely correct code in a day. Not sure how true that is, and obviously "lines of code" is a varying metric, depending on language, coding style, and so on.

Others mention debugging as a major factor. This diminishes with experience and learning, although of course it never goes away completely. As you specialize in some domain, you learn techniques for debugging problems in that domain. One of the things I've gotten a lot better at over time is building test data inputs to illustrate bugs.

For debugging, I recommend reading this book. It may not be useful for exceptional, highly experienced programmers, but I've found that it has probably made me 2-4x more efficient at debugging, and it's a super-short read (took me maybe 6 hours, and I'm a really slow reader). The other thing that makes a huge difference is learning clean coding style. As my code has gotten cleaner, I've introduced considerably fewer bugs, and spent less time tracking down the bugs I have introduced. If you haven't already, I recommend learning functional programming and spending some time with literate programming (which is less well-known). Literate programming isn't really that fundamentally different, but it teaches you to think about your program as an expression (explanation, even) of ideas or concepts, and that causes you to write your programs as an expression of the underlying ideas, making them much more clear.

What I'm talking about is pretty basic knowledge. I'd suggest googling for it first and reading through that.

If you're using an IDE (seriously, use an IDE), look for debugging in <your IDE>. It should give you what you need. You should be able to stop execution at a given breakpoint, step into and over method calls, and inspect the values of object and expressions. Bonus points for learning how to "Run to the cursor position" instead of dropping breakpoints everywhere and for figuring out conditional breakpoints. It's more complicated, but being able to debug a remote application is also really useful for most web applications.

After that, if you want to get into more systematic debugging, I recommend looking at Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems

For SQL, again, read the basics and then play around with it in an SQL application. Honestly, for learning purposes, if you have it, MS Access is pretty good. MySQL is probably the most accessible free tool.

Learn how to get data, filter it, order it from a single table. Then how to use grouping and group level filtering with GROUP BY and HAVING. Then learn inner and outer joins.

That's going to put you way in front of most young devs.

If you want to really get into it, I recommend Joe Celko's SQL for Smarties, but that's kind of overkill.

I'd say there are at least two sides to debugging: technical knowledge and mindset/approach. In many situations, technical knowledge is less important than your approach. This is a great book on how to debug anything, because it focuses on the approach:https://www.amazon.com/Debugging-Indispensable-Software-Hardware-Problems/dp/0814474578/ref=as_li_ss_tl?ie=UTF8&qid=1473264988&sr=8-1&keywords=debugging&linkCode=sl1&tag=makithecompsi-20&linkId=fff719e6c1338a3b9f9d763d7f5830a2

A really brief summary: Understand the system, reproduce the error, and think of ways to methodically test your hypotheses of what's wrong.

For your situation, "understand the system" doesn't have to mean "understand the schematic". You can start with the basic blocks: physical construction, power supply, audio output, controls. The other posters have broken down what to look for in some of these cases.

For example, if you physically inspect the board and see a big blob of solder going across three different components, it's probably a waste of time to check whether the controls affect the output sound, because that blob of solder shouldn't be there. Next step, nothing works properly without proper power, so check the points where power is supposed to be supplied on the board and make sure the voltages are correct. Then, find the earliest point on the schematic where you should get an audio output (probably an oscillator out) and check that. And on and on.

To test audio outputs, an oscilloscope is super handy, but honestly I've done a ton of debugging with a small battery-powered speaker with a mono cable connected to it, probing test points in a circuit to see whether audio is present. However note that it IS possible to fry circuits with this approach by accidentally bridging traces, so be careful.

if they would get rid of the Oracle cert and the second SQL class(r u srs with literally writing out select and insert statements), not focus on teaching JavaFX for Software I and II(and add some heavier programming), add an assembly class( I do like how they cover AArch64 in the computer arch class though), add a "non OO language" class I would say WGU's CS program would match most other online CS programs from regionally accredited, non profit unis

adding a compiler class would make it exceptional among online CS degrees but would make the degree even harder

another class I took at my B&M is a debugging class (they assigned this book and I still quote it to this day), I think that would be really interesting to offer as well

​

as it stands I don't think it's as good as most decent B&Ms or most online CS degrees

​

source: 7 years of experience, was on last year of CS degree at good B&M

Book recommendation: Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems


Swift anecdote: I had a crash that only affected 32bit devices, because the code used Int, but ran out of bits in rare cases. The original code assumed that it was a int64. Changing the type from Int to Int64 fixed the problem. It was difficult to debug since the original bug report mentioned no device type, nor specific numbers that was causing problems. Gathering much more data helped identifying the problem.

Tell us more about your setup.

Debugging by Agans is great on debugging; my last company liked it so much they bought all the devs a copy, and I think that in turn was inspired by a course at the local university requiring the book.

Debugging.