←back to thread

Ask HN: What's a surprisingly useful tech skill that's underrated today?

30 points Userrr | 1 comments | 12 Apr 25 08:13 UTC | HN request time: 0.211s | source

We often talk about mastering popular languages, frameworks, and AI tools. But what about the less-hyped skills that quietly make you 10x more effective?

For example:

Knowing how to write a custom shell script that replaces a SaaS tool

Building internal tools with no-code + cron + GitHub Actions

Understanding how to optimize a slow SQL query line-by-line

Crafting a bash one-liner that saves you hours every week

Using the command line like a superpower

I'm curious: What are the most underrated but highly valuable tech skills you've learned that more people should know about?

Would love to hear stories, examples, or even niche tools you swear by. Bonus points if it’s something you only discovered by accident or necessity, not through a tutorial.

Show context
frou_dh ◴[12 Apr 25 11:40 UTC] No.43663534[source]▶
Being able to use the features of a debugger to understand a problem in a single run, as opposed to editing the code adding/removing print statements and (recompiling+)rerunning the program over and over again.

There's been some kind of macho attitude dispersed wherein it's uncool to use good tooling, so a lot of people don't even learn how to use debuggers properly.

replies(3): >>43664823 #>>43665103 #>>43670085 #
1. tompark ◴[12 Apr 25 15:16 UTC] No.43665103[source]▶
I agree that a debugger is a great tool; in particular, knowing how to set conditional breakpoints and how to read a stack trace allows you to do things that are nearly impossible in other ways. I can give a example story below, but first:

There's a larger point here that *debugging methodology* in general is a key skill that many programmers seem to overlook or take for granted, and even think they are good at it while making wasteful mistakes -- real Dunning-Kruger material here.

* I can't tell you the number of times I've seen developers get a hunch and waste too much time going down a rabbit hole, instead of devising a test to attempt to disprove the hypothesis before plowing into a huge code review and seeing ghosts in every shadow of the codebase.

* Print statements for debugging aren't necessarily always the wrong tool, but the mindset should be that they are code and can have bugs too. Good debug logging should be part of the code telemetry infrastructure, so you can toggle it on/off. If it's going to be written and deleted, then use a debugger instead.

Actually this post is getting long so I'll stop now, but I could go on for several paragraphs.

Oh wait, I promised a debugger story. One time I started a new job, they assigned me a bug that other developers had spent a lot of time on but never resolved. It was a random crash, in a game, that rarely happened in less than 12 hours of continuous runtime, typically after 18 hours. The crash occurred even when the game was idle with no player input. The crash stack trace was very different in many instances, so the failure was happening some time/distance after its cause. My first pass was to devise tests to eliminate subsystems: try to repro the crash after disabling all graphics/animation, another test that disabled all audio/input, etc. That led to narrowing it down to a problem with the music. Telemetry showed no memory leaks, it was not running out of heap. The music playback was in a thread, double-buffered. I added a bunch of conditional breakpoints that were based on assert-like conditionals. One of those caught the interrupt happening in between two statements that should have been in a critical section. Instead of using a mutex around the whole thing, I just switched the double buffer logic to a queue, which resolved the problem.