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.
If giving a damn makes you stand out, it seems like that would indicate none of your peers or colleagues give a damn. Working at a place where you are the only person that gives a damn feels like torture.
I also wonder how much tangible value can be created by a group of incompetent people that care, compared to a group of skilled people that don't.
Well, the incompetent will find a way to make it work. Since management usually only cares about that, it will be fine. The competent who dont give a damn will basically result to vibe coding and receive similar results. Just with lower cost.
> 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.
This is the most useful tech skill as developers spend most of their time debugging code. On a different note, if we enable AI to not just write the code but able to use debugger to trace the error, then it would be much more useful.
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.
> 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".
Or "I shouldn't have to learn it, it should be obvious".
Many people won't learn the basics of many tools, and instead of learning them they will ask for one-liners so that "they don't lose their time".
- 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.
* Clarity by which you communicate in writing, such as emails. If you cannot do this you will never be put in charge in any kind of supervisory capacity.
* Task management, which is the ability to efficiently accomplish multiple small tasks without notes, reminders, or JIRA. It’s the notion of getting a bunch of shit done.
* Perceiving things in terms of facts. That means not guessing at measurements and not making assumptions. Most developers cannot do this. The inability to do this on any level is the most identifiable trait of Asperger’s.
* An ability to question the assumptions of others or even the modes of existing common practice. Most people generally cannot do this and it is this, not programming mastery, that makes for 10x developers.
* As for more technical things the ability to dive deeper and lower without leaving the current language or platform is what typically separates the masters from the commoners. These are the people who can solve problems others cannot, because the non masters are always more restricted by current conventions.
Could you please clarify this one with examples:
> Perceiving things in terms of facts.
What is an example of a developer being unable to perceive a thing in terms of facts? Inability to accept the specs of a library’s api?
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.
Knowing keyboard shortcuts of your chosen tools. Makes you so much faster and effective.
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.
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.
I'd say carefully reading and understanding an error message before turning to google/ai
Knowing when to demand proper tooling (such as IAR for embedded ARM)
Using comm(1).
Have you tried ‘combine’ from moreutils? I learned about it just the other day. Very convenient.
Looks pretty cool, thanks for the tip.
Vimium
[dead]