So, uh, everything is important, and every engineer must know everything then?

I mean, don't get me wrong, I do agree engineers should at least be aware of the existence of debuggers & profilers and what problems they can solve. It's just that not all the stuff you've said belongs in the "must know" category.

I don't think you'll need valgrind or query planning in web frontend tasks. Knowing them won't hurt though.

▲

h4ch1 5 days ago | parent | next [-]

I can tell you for a fact a lot of budding web developers don't even know a Javascript debugger exists, let alone something as complex/powerful as Valgrind.

All of these are useful skills in your toolkit that give you a way of reasoning about programs. Sure you can plop console.logs everywhere to figure out control/program flow but when you have a much more powerful tool specifically built for this purpose, wouldn't you, as an engineer, attempt to optimize your troubleshooting process?

▲

lock1 5 days ago | parent | next [-]

Yeah, it's quite sad, considering it's already built-in on all major browsers. And it's not even hard to open it, like a click away on devtools tab.

But I think promoting profilers is much more important than debuggers. Far too many people I know are too eager to jump on "optimization" just because some API is too slow without profiling it first.

▲

nananana9 5 days ago | parent | prev [-]

With native languages you'll almost always be using a compiler that can output debug symbols, and you can use the output of any compiler with (mostly) any debugger you want.

For JS in the browser, there's a often chain of transformations - TypeScript, Babel, template compilation, a bundler, a minifier - and each of these makes the browser debugger work worse -- and it's not that great to begin with, even on plain JS.

Add that to the fact that console.log actually prints objects in a structured form that you can click through and can call functions on them from the console, and you start to see why console.log() is the default choice.

	▲	h4ch1 5 days ago \| parent \| next [-]
		console.log works great. upto a point I work on maintaining a 3D rendering engine written completely in Typescript, along with using a custom, stripped down version of three.js that I rely on for primitives; and no amount of console.logging will help when you're trying to figure out exactly what's going wrong in a large rendering pipeline. I do use console.logs heavily in my work, but the debugger and profiler are instrumental in providing seamless devex. > TypeScript, Babel, template compilation, a bundler, a minifier During development you have access to source maps, devtools will bind breakpoints, show original typescript code and remap call stacks across bundlers. All modern browsers support mapped debugging, also wrt profiling it can also be symbol mapped to the original sources which makes minified builds diagnosable if you ship proper source maps, which during development you ideally should. -=- edit: additional info; I would also like to say console.log and debugging/profiling are not in a competition. both are useful in different contexts. for example I will always console.log a response from an API because I like having a nice nested representation that I can click through, I'll console.log objects, classes and everything to explore them in an easier way. this is also great for devex. I'll use the debugger when I want to pause execution at an intermediate step; for example see the result of my renderer before the postprocessing step kicks in, stop it and inspect shader code before its executed. it's pretty useful. As mentioned originally; these are TOOLS in your toolkit, you don't have to do a either/or between them.
	▲	yoz-y 5 days ago \| parent \| prev [-]
		Well. React and SSR does break debugger a lot but that’s one case. Other web frameworks are much better citizens and the debugger there is much nicer and faster than console logs.

▲

jasonjmcghee 5 days ago | parent | prev [-]

Understanding how to use these tools properly does not take very long. If you've never used them, spending an afternoon with each on real problems will probably change how you think.

If you don't already know which tool to use / how to diagnose the problem, you'll instead of banging your head against the wall, you'll think - "how do i figure out this thing - what is the right tool for this job"? and then you'll probably find it, and use it, because people are awesome and build incredibly useful free / open source software.

"try stuff until it works" is so common, and the experience needed to understand how to go about solving the problem is within reach.

Like especially with llms, "what's the right tool to use to solve problem x i'm having? this is what's going on. i'm on linux/macos, using python" or w/e