Ask HN: What's a surprisingly useful tech skill that's underrated today? | Hacker News Reader

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

31 pointsUserrr42 comments

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.

View on HN

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.

It's interesting how personal experience colors this view.

Personally I've had the odd colleague who didn't care, but they typically moved on, or got moved on, after a while.

But lots of people here have obviously experienced it, perhaps at multiple places, and so project that to "all companies".

I guess it does matter where you work, and perhaps numbering staff in thousands, or tens of thousands, means you end up with a lot of dross?

> 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.

If I may add to your second point, generating good documentation is also important. Of-course if you give a damn, this may flow naturally.

There was a great article posted here that basically said the difference between knowing nothing and being an “expert” is usually reading a single book on the subject.

Sounds like a prime example of Dunning-Kruger?

No the point was that most people don’t try to seriously learn things beyond what they immediately need to do their jobs. Anyone who takes the time to learn something beyond the surface level can become the authority on the subject in their environment.

Just to add: only give a damn about things that you really give a damn about.

Some people give a damn about everything, which is probably a sickness.

re: 2: read all the docs, but don't memorize them. When faced with a question it's often enough to remember there are docs about the topic at all. If you don't know it exists you won't know to look it up.

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".

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".

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.

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.

* 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?

More like a willingness to invent data about a thing as opposed to referencing data that is either immediately available or easily found. This often done out of convenience. That is probably fine in casual conversation, but many developers will just guess at performance, requirements, estimations, costs, dependency overhead, and so much more.

It’s a classic failure mode of the software engineer to decide to change something to be “faster,” before even checking to see if and when performance could become a problem.

I personally bucket this skill under napkin math and it is extremely good at guiding technical choices (YAGNI etc)

- 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.

Knowing keyboard shortcuts of your chosen tools. Makes you so much faster and effective.

1. Understanding the fundamentals deeply, so that it's "muscle memory". Everyone is trying to race and learn as much as they can. I think they'd get much farther by focusing more on the fundamentals of the technology they use and the whys of that technology.

2. Caring. A lot of people just plain don't care. This might not be their fault. It may be a compensation issue, I don't know, but it's pretty rare, in my experience.

I found it difficult to learn and understand the fundamentals if I don't really work on the aspects.

I have tried a couple of times to write side projects about interpreter and OS. They were all small projects so I managed to complete them before I burnt out (somehow I always burnt out from my side projects after 2-3 months and have to pause for another 3 months to get into something new). But I don't think the knowledge sticks with me.

I mean, maybe part of them did, but I just can't see why I'd use them in my work. It is sometimes very demoralizing to realize that I burnt out myself multiple times for nothing.

I think the most important thing, is to figure out how to get into a position without the knowledge to do it -- I know it sounds stupid, but many excellent developers managed to get that perk and learnt profoundly in just a few months than I did in my 7 years.

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.

Simplicity/clarity, whether in code, conversation, or otherwise. Too many technical people tend to obfuscate their speech, their code, and so on.

Lazy Optimization

Before solving a problem, learn to apply lazy optimization. Don't just follow your intuition or the standard process. First, observe from the upstream or downstream of the problem to see if there's a better solution. Sometimes, just making a few simple changes upstream or downstream can solve the problem cleanly and perfectly.

I'd say carefully reading and understanding an error message before turning to google/ai

Honestly? Social skills to deal with customers. It’s not glamorous, but knowing how to talk to users, ask the right questions, and translate their vague complaints into actionable feedback is massively underrated in tech. I’ve seen engineers spend days debugging the wrong thing simply because no one thought to clarify what the user meant. On the flip side, a quick empathetic conversation can uncover the real problem in five minutes. It’s a skill that’s rarely taught, but it turns support calls, bug reports, and even roadmap debates into something way more productive. Hugely valuable—especially if you’re building or supporting a product.

Knowing when to demand proper tooling (such as IAR for embedded ARM)

Structural editing and editor-REPL integration

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

Reply on news.ycombinator.com