Use a debugger

When things go awry and code does not behave as it's supposed to (actually how we think it's supposed to) we all have different ways to figure things out.

Many developers (junior or not) often rely on adding little bits of code to output the value of a variable or just a "hello" at specific places in the code base. When the code runs through it will output those values and messages into the console for the developer to see.

Although it might give you some idea about what's happening it will often take a lot of time and relies on a lot of assumptions about the code and what's happening.

What to do instead

One of the best pieces of advice I've received in the past was to learn how to use a debugger instead of using functions like "echo", "puts", "print" to print strings into the console.

The general idea is to put a breakpoint where you need to know how the application is. This breakpoint will get the program to stop in its tracks at that exact place and you will be able to check, in the console, the values of variables and move forward step by step in the execution of the application.

For rubyists I'd recommend you check pry or byebug tutorials such as this pry-byebug tutorial, or this more advanced pry-byebug intermediate tutorial.

Benefits

As mentioned before, relying on outputs of strings from specific places of the code base relies a lot on your idea of what part of the code the program is going through. In many cases, I have seen such assumptions to be wrong.

Relying on a breakpoint and the debugger instead will let you directly that the program is not going through that piece of code.

To do so you can either add the breakpoint very early in the tree and where you think the bug happens. You can also add breakpoints before each fork in the tree. That will let you verify variables involved in the conditions deciding which branch of the fork is used.

The use of a debugger will remove a lot of the fog surrounding a bug by giving you the ability to look at the context the program is running with in multiple places. You will rely less on assumptions and more on facts directly. This will make you faster at figuring out the real issue behind a bug and solving it properly.

Not just a command line tool

Nowadays editors such as MS Visualcode, JetBrains and all its derivatives, and others, have great integration with debugging tools for most languages. This means you don't always have to rely on the command line to run and direct the debugger. You can use the editor UI directly to do that.

Train your team

"How do you figure out what's wrong when you have a bug?" is one of my key questions when I do engineering assessments in teams.

Many teams have mixed answers to that question. It's ok. We are all learning all the time. Learning even the basics of the use of a debugger for the languages you use will bring lots of benefits.

Not only will your team find the actual bugs faster and more accurately but it will also teach them to be a bit more humble in their approach of bugs. All that will make your team more efficient, better teachers, and better at accepting when they are wrong.

You can find and recommend articles specific to debugging for your programming languages of choice easily over the web. You can also reach out to individuals in or out of your team and company to come pair with some of your team members to show them how to use a debugger.

This will be a small investment of one or two days for a team of 4-10 people and it will have massive impacts in the long run.