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.
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.
Some people give a damn about everything, which is probably a sickness.
Care about the business, not specifically the thing you’re doing.
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.
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.
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?
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.
It's a part of a wider problem of "I don't know something and instead of learning I'm going to get angry".
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".
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.
* 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.
> 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?
I personally bucket this skill under napkin math and it is extremely good at guiding technical choices (YAGNI etc)
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 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.
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.
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.
In my experience most developers like to skip knowing about the data.