from Hacker News

Ask HN: What are the most underrated skills in tech?

by alexliu518 on 7/9/24, 6:26 AM with 48 comments

• by tracker1 on 7/9/24, 3:33 PM

  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.

• by zkirill on 7/9/24, 10:34 AM

  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.

• by nickd2001 on 7/9/24, 11:37 AM

  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.

• by markus_zhang on 7/9/24, 3:54 PM

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

• by sk11001 on 7/9/24, 10:27 AM

  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.

• by solardev on 7/9/24, 9:04 AM

  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.

• by akasakahakada on 7/9/24, 11:24 AM

  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.

• by jf22 on 7/9/24, 12:14 PM

  Relaxing.

  Everyone is so uptight about everything.

  The risk is low, the pay is good, but people just want more and more and more.

• by austin-cheney on 7/9/24, 10:21 AM

  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.

• by quectophoton on 7/9/24, 5:32 PM

  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.

• by aristofun on 7/9/24, 9:05 AM

  Intuition

  Often you waste more time explaining and defending your approach you know is right than it takes to actually implement it.

• by Leftium on 7/9/24, 9:23 AM

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

• by Simon_ORourke on 7/9/24, 6:31 AM

  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.

• by ensocode on 7/9/24, 9:12 AM

  Listening and understanding the customer

• by Cwizard on 7/9/24, 2:35 PM

  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.

• by nicbou on 7/9/24, 9:30 AM

  Networking. Just getting to know people and looking out for each other is incredibly valuable. It removes so much friction in business.

• by whatnotests2 on 7/9/24, 6:55 AM

  Debugging, using evidence, hypothesis, theories, experiments, and drawing conclusions based on what is observed. Seems to be a lost art.

• by nunez on 7/9/24, 1:23 PM

  Writing good, approachable documentation is still up there, I'm sure!

• by fendy3002 on 7/9/24, 12:21 PM

  Being able to say no, or the equivalent without enraging the other party.

• by dzonga on 7/9/24, 5:10 PM

  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.

• by Desafinado on 7/9/24, 11:38 AM

  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.

• by yiamvino on 7/9/24, 6:27 PM

  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.

• by mablopoule on 7/9/24, 10:17 AM

  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 Lionga on 7/9/24, 8:55 AM

  Not being a dick

• by notaharvardmba on 7/9/24, 6:42 PM

  Error handling and using the standard protocols for error reporting and logging

• by ChrisArchitect on 7/9/24, 3:29 PM

  Related yesterday:

  Ask HN: How do I figure out what skills are in demand?

  https://news.ycombinator.com/item?id=40905649

• by lulznews on 7/9/24, 8:50 AM

  Communication.

• by pyb on 7/9/24, 5:36 PM

  Product sense, design thinking, understanding of the customer/market, knowing what to build.

• by rokisen157 on 7/10/24, 2:08 AM

  Bits & Bytes