Ask HN: What are the most underrated skills in tech?
29 comments
Self-directed learning and exploration. I find that a lot of people are unwilling or at the very least not used to actually trying to find answers on their own, writing experiments or just doing things that aren't directly assigned in detail. This isn't to say, "don't ask for help," so much as one should at least try to understand and find answers on their own as an initial effort. Set aside an amount of time to dig in, google, look at results, read documentation, etc. After some effort has been made, then ask as needed.
It can go the other way too... which are those that won't ask for help after exausting days of effort on what may/should be a simple answer.
Aside from this, but similar and related is the understanding of what you're using. The tools, system and projects. Too many times I'll see devs re-create something that's already in the box, or easily put into the box. This includes adding massive libraries to a given project (how many date-time libraries do you need). Take the time to look at the build scripts, docker files, and project dependencies list. More so, if you're using a UI component library, spend the hour or so familiarizing yourself with the example pages demonstrating the library so you at least know what's there.
It can go the other way too... which are those that won't ask for help after exausting days of effort on what may/should be a simple answer.
Aside from this, but similar and related is the understanding of what you're using. The tools, system and projects. Too many times I'll see devs re-create something that's already in the box, or easily put into the box. This includes adding massive libraries to a given project (how many date-time libraries do you need). Take the time to look at the build scripts, docker files, and project dependencies list. More so, if you're using a UI component library, spend the hour or so familiarizing yourself with the example pages demonstrating the library so you at least know what's there.
I agree with what you said. I fall into this trap from time to time. The most recent one occurred in yesterday. I was supposed to follow some tutorials to set up development in Windows using Visual Studio and a bunch of libraries (SDL2, gml, imgui, etc.). My first setup took about an hour and the sample project seemed to work when running in Debugger, but failed to start when clicked directly in File Explorer. I got so frustrated that I almost gave up. I did manage to muster some strength to start over, and fortunately this time it worked.
Situations like that reminded me how impatience I was, have been and am. What struck me most, is that back in the 70s and 80s, microcomputer developers (such as Romero, Carmack and others) usually did not have access to any tutorial or even books (unless one is lucky to live close to a university or a large public library). The best thing they had are the manuals and specifications, and they were free to shoot in their feet and figure out what might it be. Many people actually dropped out, but some of them persisted and managed to come out as the pioneers of the time.
At the age of 40+, I'm a bit ashamed that I'm not as persistent as them, when they were at their 20s and 30s back then. I'm thinking about getting some trainings or therapy sessions regarding my impatience.
Situations like that reminded me how impatience I was, have been and am. What struck me most, is that back in the 70s and 80s, microcomputer developers (such as Romero, Carmack and others) usually did not have access to any tutorial or even books (unless one is lucky to live close to a university or a large public library). The best thing they had are the manuals and specifications, and they were free to shoot in their feet and figure out what might it be. Many people actually dropped out, but some of them persisted and managed to come out as the pioneers of the time.
At the age of 40+, I'm a bit ashamed that I'm not as persistent as them, when they were at their 20s and 30s back then. I'm thinking about getting some trainings or therapy sessions regarding my impatience.
>> At the age of 40+, I'm a bit ashamed that I'm not as persistent as them, when they were at their 20s and 30s back then.
Don't be and be careful what you wish for.
From my perspective their behavior is borderline unhealthy and almost like a type of OCD but by sheer luck directed towards stuff that pays good. Especially Carmac and Romero are bad role models - their life is really good story to tell (both books reads very well) but not to live.
Don't be and be careful what you wish for.
From my perspective their behavior is borderline unhealthy and almost like a type of OCD but by sheer luck directed towards stuff that pays good. Especially Carmac and Romero are bad role models - their life is really good story to tell (both books reads very well) but not to live.
Thanks. I'm mostly concerned by my lack of persistence. I did read both of the books, and yeah, I don't want to live their childhoods, although my own childhood is not particularly interesting and inspiring.
Being able to patiently explain something to a layperson using simple words and short sentences, in a sympathetic non-condescending way.
The tech industry is in some kind of a communications complexity arms race spiral where normal people have no idea what any of us are talking about anymore. It created a prime feeding ground for charlatans who can sound smart for long enough before they move on to the next insanely awesome thing.
The tech industry is in some kind of a communications complexity arms race spiral where normal people have no idea what any of us are talking about anymore. It created a prime feeding ground for charlatans who can sound smart for long enough before they move on to the next insanely awesome thing.
When I was the sole IT guy, I had taken over from an Accountant who dabbled in programming/system administration. His approach was typical of the time... He'd say "What did you break this time?" In a joking but maybe not manner.
I never did that. I always assumed it was a hardware/software/training issue. My go-to introduction to how I viewed computers was
"You've got 2 folders open on the screen. You click and drag a file from one to the other, what's going to happen? -- There are 3 possible things that could happen, it might copy it, move it, or maybe make a shortcut. -- All based on rules I don't expect you to remember."
I'd explain about right-clicks, copy and paste, and a few other things... and they'd usually be good to go.
I understand that computers are a tool to get a job done, not an object of worship. I wish more people understood that in tech.
I never did that. I always assumed it was a hardware/software/training issue. My go-to introduction to how I viewed computers was
"You've got 2 folders open on the screen. You click and drag a file from one to the other, what's going to happen? -- There are 3 possible things that could happen, it might copy it, move it, or maybe make a shortcut. -- All based on rules I don't expect you to remember."
I'd explain about right-clicks, copy and paste, and a few other things... and they'd usually be good to go.
I understand that computers are a tool to get a job done, not an object of worship. I wish more people understood that in tech.
Following the KISS principle and making systems as simple as possible therefore easy and cheap to maintain and expand. Which can include, not necessarily using the latest most fashionable tech if it doesn't solve the Use Case better. In my many years of coding, I've found many otherwise highly intelligent capable people, seem to devote herculean mental effort to understanding unneccesarily complex systems and keeping many details in their heads that needn't be there if it was designed sensibly.
Similarly easy enough to replace/recreate if you truly need to change something as needs evolve. KISS tends to be a guiding principle for me above most other things.
Of course, there are some times where following a certain pattern is easier over time than other approaches that may mean more bugs over time. In particular, why I'm a fan of the render the current state state approach the likes of React/Svelt etc implement along with say Redux. It's slightly harder to grok, but you can avoid entire classes of bugs with judicious use.
Of course, there are some times where following a certain pattern is easier over time than other approaches that may mean more bugs over time. In particular, why I'm a fan of the render the current state state approach the likes of React/Svelt etc implement along with say Redux. It's slightly harder to grok, but you can avoid entire classes of bugs with judicious use.
Tech itself. The hard skill. A lot of people realize that soft skills are important, but IMHO they are now the mainstream now. Everyone, including new graduates, know that. But many people are ignoring the hard skills, or simply do not have the time to dive deep into it (we can practice soft skills in time slices, but cannot do that for hard skills).
Some obscure hard skills from top of head:
- Replicate what John Carmack did for Commander Keen in DOSBOX (or a more accurate emulator, or a physical computer) against the 80286 architecture.
- Write a complete 2D game engine, or a complete but simple 3D game engine.
- Write a complete compiler, with code generation for a real architecture instead of a VM, for a simple language, such as Minimum BASIC.
Disclaimer: This is just my personal opinion. I know these projects are probably of minimum value, but could be great learning projects. They either force you to certain resource constraints (like Project 1), or read specifications and manuals (like Project 3), or learn to structure and organize larger projects (like Project 2).
Some obscure hard skills from top of head:
- Replicate what John Carmack did for Commander Keen in DOSBOX (or a more accurate emulator, or a physical computer) against the 80286 architecture.
- Write a complete 2D game engine, or a complete but simple 3D game engine.
- Write a complete compiler, with code generation for a real architecture instead of a VM, for a simple language, such as Minimum BASIC.
Disclaimer: This is just my personal opinion. I know these projects are probably of minimum value, but could be great learning projects. They either force you to certain resource constraints (like Project 1), or read specifications and manuals (like Project 3), or learn to structure and organize larger projects (like Project 2).
I strongly support your idea, although few people do this now. This is the spirit that contemporary programmers lack.
Thanks! I'm trying my hand on the 2d game engine myself. But I do hope I'm debt free so I can dive into other deep topics too.
Having good taste - about code, about the tools you use, about what to build in the first place, about how you collaborate with people, about what’s worth spending time on and arguing about.
Communication and documentation? Most programmers I've met were pretty bad at both. Most people I've met who were good at both weren't programmers. It's hard to find that overlap.
Seconded. By far the single biggest problem in tech is the brain-to-brain transmission of technical information. It's hard, slow, and lossy. Nobody is perfect at it, but you can get better.
Nobody wants to write documentation, but it's so crucial for on-boarding new employees to have well-written (and even more important, up-to-date) documentation.
It's so frustrating to be unable to find information, and even when I do find it, it's outdated, and the only way I find out it's outdated is because I spend an hour+ trying to get something to work based on the instructions, and when I finally pop a question on Slack, I'm told "Oh, we haven't done it that way in a long time. Here's what you need to do..."
It's so frustrating to be unable to find information, and even when I do find it, it's outdated, and the only way I find out it's outdated is because I spend an hour+ trying to get something to work based on the instructions, and when I finally pop a question on Slack, I'm told "Oh, we haven't done it that way in a long time. Here's what you need to do..."
Competitive programming skill. Just right click any where on Win11 and see how slow the menu will pop up. 100 of thousands Microsoft employees and NONE of them can make thing work faster.
This is also noticeable in videogames.
If I open a menu and press a direction button 5 times (e.g. to move between menus) because my muscle memory has learned that the thing I want is at that position, then why tf is the game ignoring those 5 button presses just because there was some slow ass fade-in animation happening?
Looking at you, Monster Hunter World.
If I open a menu and press a direction button 5 times (e.g. to move between menus) because my muscle memory has learned that the thing I want is at that position, then why tf is the game ignoring those 5 button presses just because there was some slow ass fade-in animation happening?
Looking at you, Monster Hunter World.
CP just teaches some familiarity with DSA/algorithms, and there's much more to perf than DSA. Even assessing algorithmic performance requires real benchmarks and profiling, while the complexity analysis people do in CP disregards other factors like hardware, architecture, format, and other abstractions. Squeezing perf via DSA is much more easier/straightforward, people don't need to grind CP to learn that
Navigate to Computer\HKEY_CURRENT_USER\Control Panel\Desktop.
In the right-hand pane, look for "MenuShowDelay"
Change to 0 delay.
Doesn't that change the hover-over pop-up speed, like when you're selecting a sub menu item in a tree? Does it also affect the initial click?
I used to do that on every Windows installation. Then I eventually just gave up on Windows, lol.
I used to do that on every Windows installation. Then I eventually just gave up on Windows, lol.
Deep knowledge of transmission won me my current job. More specifically talking through a deep dive into the full duplex nature of WebSockets, how that’s executed below the API, and what that means compared to HTTP.
What got me far into all other job interviews last year were just basic communication skills. I mean speaking and writing compared to other candidates.
What got me far into all other job interviews last year were just basic communication skills. I mean speaking and writing compared to other candidates.
Being willing to touch third party code.
There was a situation where the higher ups wanted us to have a specific feature, and the literal only two available options were to either fork the SDK of a commercial SaaS, or to not have that feature at all. That SaaS's support team confirmed they weren't going to implement that in their SDK.
There were two dev teams involved in this, and every person from these two teams (except myself and another dev) were strongly against the fork, but didn't suggest any other option to have that feature, and of course not having this feature wasn't even an option, but then they didn't suggest any other way to achieve it.
It was like looking at third party code was heresy for them. Not best practice, antipattern, and other expressions like that were thrown around.
The amount of frustration from that whole thing is something I don't want to experience again if possible.
There was a situation where the higher ups wanted us to have a specific feature, and the literal only two available options were to either fork the SDK of a commercial SaaS, or to not have that feature at all. That SaaS's support team confirmed they weren't going to implement that in their SDK.
There were two dev teams involved in this, and every person from these two teams (except myself and another dev) were strongly against the fork, but didn't suggest any other option to have that feature, and of course not having this feature wasn't even an option, but then they didn't suggest any other way to achieve it.
It was like looking at third party code was heresy for them. Not best practice, antipattern, and other expressions like that were thrown around.
The amount of frustration from that whole thing is something I don't want to experience again if possible.
Intuition
Often you waste more time explaining and defending your approach you know is right than it takes to actually implement it.
Often you waste more time explaining and defending your approach you know is right than it takes to actually implement it.
Marketing. (Also known as "persuasion.")
Any activity that requires interaction between two or more people needs persuasion. Persuasion is like breathing: most people do it poorly without giving much thought, but there is a way to breath more effectively that can be learned and trained.
- Job interviews/resumes are just a form of persuasion.
- Hiring is just a form of persuasion.
- Meetings are often about persuasion.
- Not related to tech, but even dating/marriage requires persuasion in many forms.
Actually, a lot professional marketers don't fully understand persuasion themselves, even though it is their job.
Most people tend to think of marketing that focuses on the product/service being sold. This type of marketing uses a lot of "I, we, our product/company" in the copy.
But effective marketing focuses instead on the prospect, the end-user, where the most important word is "you."
Any activity that requires interaction between two or more people needs persuasion. Persuasion is like breathing: most people do it poorly without giving much thought, but there is a way to breath more effectively that can be learned and trained.
- Job interviews/resumes are just a form of persuasion.
- Hiring is just a form of persuasion.
- Meetings are often about persuasion.
- Not related to tech, but even dating/marriage requires persuasion in many forms.
Actually, a lot professional marketers don't fully understand persuasion themselves, even though it is their job.
Most people tend to think of marketing that focuses on the product/service being sold. This type of marketing uses a lot of "I, we, our product/company" in the copy.
But effective marketing focuses instead on the prospect, the end-user, where the most important word is "you."
Being able to write complex, reliable, and reasonably performant SQL queries should help land you a job more easily than say a thorough understanding of React. Despite all the SQL co-pilot AI out there, writing good SQL won't stop being an in demand skill.
I agree it is a very useful skill, and countless stuff ups I have seen have been caused by bad SQL (often ORM generated SQL). But I don't remember ever SQL being tested in any interview, where as coding skills in the language of choice e.g. C# being tested at great length. Is this for data science jobs?
Strange, it's one of the first questions I'd ask anyone during an interview, from analysts, to data scientists and even data engineers. Usually, something like, "describe what a SQL window function does, and provide an example of its usage".
Listening and understanding the customer
Data modelling (in databases but I guess that also translates to the application layer to some extent).
A good data model will allow you to get much further with a standard database without requiring horizontal scaling and complex caching solutions. Data models are often also painful and hard to change so good decisions made on the data level are worth their weight in gold if you ask me.
A little like building a good foundation for a house.
A good data model will allow you to get much further with a standard database without requiring horizontal scaling and complex caching solutions. Data models are often also painful and hard to change so good decisions made on the data level are worth their weight in gold if you ask me.
A little like building a good foundation for a house.
Networking. Just getting to know people and looking out for each other is incredibly valuable. It removes so much friction in business.
Debugging, using evidence, hypothesis, theories, experiments, and drawing conclusions based on what is observed. Seems to be a lost art.
Writing good, approachable documentation is still up there, I'm sure!
Being able to say no, or the equivalent without enraging the other party.
This is a very underrated skill. Being able to say "no," especially to a customer, is critical to not losing your sanity in short order.
writing end user software that actually works.
i.e predictable - works today as it did, yesterday - while being performant.
can recover from crushes.
works with the user, not against the user.
Faang companies with all leetcode interviews haven't shipped end user software that works look at android etc, + plenty of other companies.
and tools like React are not making things better.
i.e predictable - works today as it did, yesterday - while being performant.
can recover from crushes.
works with the user, not against the user.
Faang companies with all leetcode interviews haven't shipped end user software that works look at android etc, + plenty of other companies.
and tools like React are not making things better.
Being kind, being a good listener, being pleasant to work with, being an interesting conversationalist.
You're spending your life with your co-workers, don't be the guy who doesn't talk to anyone or competes. After 10 years in the industry I value friendship with my co-workers probably more than anything.
You're spending your life with your co-workers, don't be the guy who doesn't talk to anyone or competes. After 10 years in the industry I value friendship with my co-workers probably more than anything.
Effective Communication. there goes saying it is better to understand than to be understood. most of the time articulating details in effective is clearly most of the problems. Most of the time it is not technology thats challenging rather how we gather problem and solving them is real challenge. everything boils down to communication.
Respecting other professions.
By that, I mean getting over any mentality that accountant are simply bean counter, sales peoples are just talentless people riding on charisma, etc...
All those stupid tribal mentality will hinder the programmer's ability to think about the project holistically, and propose the right technical tradeoff.
I had the luck of working in a company that not only had very good dev team and CTO, but also a very smart CEO and non-tech teams. As a result the sales & business decision were done with technical possibilities (and limitations) in mind, while the technical choices were done with business problematic in mind. That was by far the best codebase I've seen, because there was a lot of smart, 'out-of-the-box thinking' kind of technical stuff in it where it mattered, and also lot of technical simplicity or even 'cowboy coding' when it also mattered.
I believe that there is a continuum where the most limiting thing you can do for your tech skills is to identify yourself with your technical stack. Don't be a 'Javascript programmer', or worse, a 'React programmer'. I fact try to not even think of yourself as a 'programmer', because that will push you into thinking that 'problem-solving' implies a programming exercise, of course only with your usual tools.
That's often the case, but the most elegant solution to a problem is to not even have a problem in the first place, and that requires programmers to think about the project and the objectives in a level possible only when thinking (or listening) in term of added value in the business, sales problematic, financing issues, legal issues, and so on. By working with those 'non-technical' teams, you can acquire by osmosis their way of thinking, and be able to argue technical issues way more efficiently, while also being able to cut corner when it makes sense.
Reading everything I've written above, you might be tempted to think that I see programming only as a mean to an end, and don't care about code quality. I do like "programming for programming sake", like reading SCIP, playing with data structures, looking up esolangs, or more pragmatically thinking deeply about the dataflow of an application and what are the most appropriate data structures.
What I don't like however, is when programming become self-masturbating in a way that are neither enlightening, nor impactful. I've once joined a company that was obsessive about linting, improving their CI/CD processes, and following 'best practices' in the most jarring way. Some devs even wanted to switch libraries for a newer one based on the number of Github stars. The business side of things was basically burning down due (in part) to a lack of appropriate features in the product, but it's wasn't really a problem as long as Typescript was configured to be as strict as possible, and linters too, that will surely means something about quality I guess. Somehow, the company folded 6 months after.
By that, I mean getting over any mentality that accountant are simply bean counter, sales peoples are just talentless people riding on charisma, etc...
All those stupid tribal mentality will hinder the programmer's ability to think about the project holistically, and propose the right technical tradeoff.
I had the luck of working in a company that not only had very good dev team and CTO, but also a very smart CEO and non-tech teams. As a result the sales & business decision were done with technical possibilities (and limitations) in mind, while the technical choices were done with business problematic in mind. That was by far the best codebase I've seen, because there was a lot of smart, 'out-of-the-box thinking' kind of technical stuff in it where it mattered, and also lot of technical simplicity or even 'cowboy coding' when it also mattered.
I believe that there is a continuum where the most limiting thing you can do for your tech skills is to identify yourself with your technical stack. Don't be a 'Javascript programmer', or worse, a 'React programmer'. I fact try to not even think of yourself as a 'programmer', because that will push you into thinking that 'problem-solving' implies a programming exercise, of course only with your usual tools.
That's often the case, but the most elegant solution to a problem is to not even have a problem in the first place, and that requires programmers to think about the project and the objectives in a level possible only when thinking (or listening) in term of added value in the business, sales problematic, financing issues, legal issues, and so on. By working with those 'non-technical' teams, you can acquire by osmosis their way of thinking, and be able to argue technical issues way more efficiently, while also being able to cut corner when it makes sense.
Reading everything I've written above, you might be tempted to think that I see programming only as a mean to an end, and don't care about code quality. I do like "programming for programming sake", like reading SCIP, playing with data structures, looking up esolangs, or more pragmatically thinking deeply about the dataflow of an application and what are the most appropriate data structures.
What I don't like however, is when programming become self-masturbating in a way that are neither enlightening, nor impactful. I've once joined a company that was obsessive about linting, improving their CI/CD processes, and following 'best practices' in the most jarring way. Some devs even wanted to switch libraries for a newer one based on the number of Github stars. The business side of things was basically burning down due (in part) to a lack of appropriate features in the product, but it's wasn't really a problem as long as Typescript was configured to be as strict as possible, and linters too, that will surely means something about quality I guess. Somehow, the company folded 6 months after.
Not being a dick
Flip side, being able to take constructive, even if harsh, criticism.
Not suggesting to be mean or cruel intentionally, but a comment about code or implementation is not a personal attack and shouldn't be taken as such.
Not suggesting to be mean or cruel intentionally, but a comment about code or implementation is not a personal attack and shouldn't be taken as such.
I remember proposing to a very green team that using pull requests, code reviews and some semblance of staging before committing to production was a good idea and the answer was, literally: "But I write perfect code". I was shocked into silence and had to walk away on that one.
Error handling and using the standard protocols for error reporting and logging
Related yesterday:
Ask HN: How do I figure out what skills are in demand?
https://news.ycombinator.com/item?id=40905649
Ask HN: How do I figure out what skills are in demand?
https://news.ycombinator.com/item?id=40905649
Communication.
Product sense, design thinking, understanding of the customer/market, knowing what to build.
Bits & Bytes
I’m curious to hear from the community about the skills that you think are currently underrated in the tech industry. We often hear about the importance of programming languages, frameworks, and data science, but what are some of the less talked about skills that have a big impact?
Whether it’s a soft skill, a niche technical expertise, or a particular approach to problem-solving, I’d love to learn about what you think makes a difference but doesn’t get enough attention.
Looking forward to your insights!