Ask HN: What's a surprisingly useful tech skill that's underrated today?
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.
1. Giving a damn. The majority of people don’t care at all about the work being performed. You can easily distinguish yourself by simply caring about whatever it is you’re working on.
2. A natural consequence of the above: fully reading the documentation, be it man pages or the official technical reference for a given technology. It’s incredible how many people don’t read documentation. You can become one of the foremost experts in your company simply by reading the documentation from front to back. You will seem like a genius.
> Giving a damn.
This is an underrated skill. I agree, the bar is so low that even a little bit of care/user empathy will make you stand out.
> You can easily distinguish yourself by simply caring about whatever it is you’re working on.
Care about the business, not specifically the thing you’re doing.
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.
> There's been some kind of macho attitude dispersed wherein it's uncool to use good tooling
It's a part of a wider problem of "I don't know something and instead of learning I'm going to get angry".
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.
- writing thoroughly tested code that works and has minimal defects - being someone who is pleasant to work with and who shows interest in others - digging down into requirements and rooting out the real problem that needs a solution, actually solving that problem - individual 'tech skills' are just things you can look up on Google or read about in a book. I suspect the above are more important.
Server Management might be one. People seem to waste a lot of money for fancy cloud solution they don't actually need. And you said a little bash can solve do many problems
Absolutely. It’s wild how much gets spent on over-engineered cloud setups when something lightweight and a bit of Bash could do the job just fine. Server management done right is underrated—there’s a lot of value in simplicity and knowing exactly what’s running under the hood.
Have a deep understanding of your tools. And for a programmer, the top three are: the editor, the os shell, and your programming language tooling.
The question is what you mean by highly valuable. The sad truth is that in most workplaces many just coast along doing only what's necessary to not get fired. In which case doing your job more efficiently might draw negative attention (tall poppy syndrome).
Having said that, I think that having a good (both broad and deep) knowledge of the database schemas is invaluable for almost any information related role. Also, being able to manipulate large text very quickly (with vi/sed/awk, let's say), is useful for production emergency debugging on servers.
That’s a fair point, and I get where you're coming from. By “highly valuable,” I meant consistently making a meaningful impact—whether that’s through solving key problems, improving processes, or just being someone others can rely on. But yeah, you're right—sometimes doing more than the norm can backfire in certain environments. I guess the goal is to be valuable and strategic—knowing when to push and when to hold back depending on the culture.
Right, so when discussing a high productivity role, havig mastery of both the structure (such as a DB) and of the tools to investigate the structure (text manipulation, SQL querying) are key.
In my experience most developers like to skip knowing about the data.
Yeah, exactly—that deep understanding of both the structure and the tools makes all the difference. It’s surprising how often people overlook the data itself, even though it’s usually where the real insights (and problems) are hiding. Mastery there really separates someone who’s just coding from someone who’s solving.
I'd say carefully reading and understanding an error message before turning to google/ai
Knowing keyboard shortcuts of your chosen tools. Makes you so much faster and effective.
Using comm(1).
Vimium
[dead]