[Stratoscope]

If I were teaching someone Python, or pretty much any programming language, the first place I would start is the debugger. I would have them write a program as simple as this:

  x = 1
  print(x)
  y = 2
  print(x, y)

And then instead of just running it, I'd have them step through the code, line by line, and observe both the console output and the debugger variable display.

Some developers seem to think that using a debugger is a sign of weakness, or that it leads you to write bad code. I see it differently: the debugger is one of the best tools not only for debugging, but also to help you understand a complex codebase that you are jumping into.

[LrnByTeach]

> If I were teaching someone Python, or pretty much any programming language, the first place I would start is the debugger.

Totally agree.

In the first week of programming, students should be allowed only use the debugger (no direct runs) in every course/collage around the world. I saw firsthand how many courses/collages students struggle with logic because debugging was never introduced, and they were unaware of how to step through each line.

Another mistake that new programmers make is writing 30 lines of code and then run and lost why bugs occurring. As a rule of thumb, they should debug/run the program every 7 new lines of code.

[fbdab103]

Perhaps it was just my education, but my CS classes had almost zero real-world guidance on how to do anything. Maybe a one pager on how to install the development environment. No IDE workshops, source code control, project layout guidance, etc. Perhaps the non-theoretical aspects are distasteful to professors (astronomers and telescopes or something)?

I was a print-line debugger for years.

[zikzak]

I end up helping developers when they get stuck all the time and it is really amazing to me how many people get to the "senior developer" point in their career with very little understanding of how to use SQL tracing (e.g. MS SQL server) and IDE debugging.

Even the concept of the "print line" debugging into a lot file seems kind of foreign to them sometimes.

They instead rely on running the code, changing something, running it again, etc.

I am a big fan of reading through the code. That is almost always enough for me to find the issue and point it out to them assuming I understand the input and output context well enough. But if that doesn't work, add a debug point and fire it up. Not using a debugger seems like a massive waste of time in a situation like this. So much so that I have started asking "did you debug this" or "have you watched this happen in a debugger" before I will help out much. If they say "no" because they don't know how, I will teach them to do so.

[bornfreddy]

> ...of how to use SQL tracing (e.g. MS SQL server)...

Never met this term before - IIUC, SQL tracing is MS-specific? If I may ask, in what kind of situations would you use it?

[zikzak]

Yes, I think it might be SQL specific but you can normally do this in any transnational db I have worked with (I am old, I don't use GraphQL or NoSQL dbs very often, if at all).

Basically, it is just a journal of all queries (really ANYTHING going on in the db but for developers it is useful to limit to queries) and typically filtered by database and by keyword (e.g. table or stored procedure name).

You can set up a trace to track long-running queries on a production server (DBA might do this) or on a dev server a developer might use it to capture SQL run from their code (e.g. a complex stored procedure with a lot of input params) so you don't have to try to assemble the SQL using a debugger, for example.

A good example might be "I am doing everything right in code, but the data set is coming back empty" so you profile it and realize the SQL is being called with an empty string and not a null, or whatever. When reviewing the code you thought "it will be a null". That kind of thing.

[mkoryak]

> Some developers seem to think that using a debugger is a sign of weakness

Really? I have never encountered that in the last 18 years in any of the 8 or 9 places I've worked.

I've worked with many know-it-alls who both knew it all and didn't. With arrogant and humble developers. No one ever said that.

[Stratoscope]

You are right, it is uncommon. But here are some examples:

https://news.ycombinator.com/item?id=29387515

(See the last reply in that thread.)

https://news.ycombinator.com/item?id=19829435

https://www.javacodegeeks.com/2013/05/debuggers-are-for-lose...

[mkoryak]

Wow ok.

I should consider myself lucky

[wjholden]

John Carmack had some interesting comments on debuggers (as opposed to "print debugging") in his recent interview with Lex Friedman. This was probably the most valuable thing I got out of their talk, because I myself use print debugging often. The main reason why I did this is that I use a lot of different languages (Julia, Go, JavaScript, Python, and so on) and it usually isn't worth it to me to learn a new and big IDE to small projects.

[DwnVoteHoneyPot]

what did he say?

[fbdab103]

Not GP, but I assume this[0] is the talk. Clocking in at five hours, you might have to dedicate some time to it. The timestamps on the show indicate programming is discussed somewhere between the 10 and 51 minute marks.

[0]: https://lexfridman.com/john-carmack/

[mettamage]

Haha, it feels I could’ve written this comment. I learned programming at uni from a blackboard :’)