Ask HN: What are long-lasting tech skills?
It seems like every day or week there's a new software, framework, OS or skill that tech workers need to know in order to stay relevant. What are some skills that can be learned and be perfected over many decades without having to reinvent myself all over again (akin to a journeyman's path to becoming a master)?
20 comments
A few that come to mind:
- Unix/Linux fundamentals (processes/threads, builtin commands, scripting, file system/permissions, basic system admin, etc.)
- SQL
- Writing & communicating technical topics (i.e. how do you distill complex technical concepts to the appropriate level of detail to have meaningful discussions with the target audience; applies to all technical topics and becomes more important as you advance in your career)
- Testing (unit/integration/e2d; but more conceptually, how do you gain confidence that your code does what it's intended to do?)
- Unix/Linux fundamentals (processes/threads, builtin commands, scripting, file system/permissions, basic system admin, etc.)
- SQL
- Writing & communicating technical topics (i.e. how do you distill complex technical concepts to the appropriate level of detail to have meaningful discussions with the target audience; applies to all technical topics and becomes more important as you advance in your career)
- Testing (unit/integration/e2d; but more conceptually, how do you gain confidence that your code does what it's intended to do?)
Definitely agree with all of them. I didn't work at places that valued testing until fairly recently and I'm absolutely shocked that I was able to get by as long as I did without it (plenty of incidents and bugs were involved though).
Every book I've read on software develop always hits on testing and I can't believe I ignored it for so long saying "but my code is hard to test". Then it's your code's fault. If you can't write tests because the code isn't structured to do so, that means your code has bad structure IMO (I'm sure there are situations where this is trickier but they're the minority). The amount of bugs I produce has dropped dramatically since I started writing tests for almost all my code. Seriously a career changing thing that was pretty obvious but I just ignored.
Every book I've read on software develop always hits on testing and I can't believe I ignored it for so long saying "but my code is hard to test". Then it's your code's fault. If you can't write tests because the code isn't structured to do so, that means your code has bad structure IMO (I'm sure there are situations where this is trickier but they're the minority). The amount of bugs I produce has dropped dramatically since I started writing tests for almost all my code. Seriously a career changing thing that was pretty obvious but I just ignored.
> "...communicating technical topics..."
So important and sets you apart from a developers who lack the ability to explain what they've done in terms of how a non-technical user/customer can understand.
So important and sets you apart from a developers who lack the ability to explain what they've done in terms of how a non-technical user/customer can understand.
I would make the first point more generic.
OS internals: networking and OS level caching are a must when trying to squeeze every bit of performance from a server.
OS internals: networking and OS level caching are a must when trying to squeeze every bit of performance from a server.
Here are a few that I can think of:
- Patterns - Separation of Concerns - Modularization - Source Control - Abstraction - Domain expertise - The ability to translate user requirements into tech - Tolerance for some degree of ambiguity - Debugging - Best practices in quality - Unit testing
I'm sure there are more and some people might disagree. The gist is that tech changes, but common practices, skill sets, and thought processes are long lasting.
- Patterns - Separation of Concerns - Modularization - Source Control - Abstraction - Domain expertise - The ability to translate user requirements into tech - Tolerance for some degree of ambiguity - Debugging - Best practices in quality - Unit testing
I'm sure there are more and some people might disagree. The gist is that tech changes, but common practices, skill sets, and thought processes are long lasting.
Problem solving, recognising that it's the client who pays your wage and "knowing the odds"... https://en.wikipedia.org/wiki/Pareto_principle
Become an expert in a domain, i.e. compilers, computer graphics, cybersecurity, bioinformatics, etc... Developer skills that age poorly are those for building CRUD apps.
Networking for me.
Knowing the ins and outs of TCP, UDP, HTTP, TLS you can work with caddy, haproxy, envoy, nginx, and other future networking things.
Knowing the ins and outs of TCP, UDP, HTTP, TLS you can work with caddy, haproxy, envoy, nginx, and other future networking things.
Caring is huge, but also hard to teach.
Self teaching.
Simple math (arithmetic, boolean algebra, strings, composite data types, bitwise operators, order of operations, infinite expression nesting, and of course functions).
Complexity avoidance.
Written communication.
Subconscious thinking (ie. solving problems on autopilot while doing something away from the computer).
Self teaching.
Simple math (arithmetic, boolean algebra, strings, composite data types, bitwise operators, order of operations, infinite expression nesting, and of course functions).
Complexity avoidance.
Written communication.
Subconscious thinking (ie. solving problems on autopilot while doing something away from the computer).
Knowing how to tell someone "no, I won't build that" and make them thank you for it.
Empathy, which is unfortunately but understandably pretty rare in tech. When the engineer lacks empathy for the end user, the human, we end up with terrible UX, unsatisfied specs & reqs, bad software in general.
Never blame the user, the customer - they are always right. If the user is repeatedly doing something "wrong", they're not wrong, the engineer/designer is wrong, and needs to readapt to the what the user sees as right.
Never blame the user, the customer - they are always right. If the user is repeatedly doing something "wrong", they're not wrong, the engineer/designer is wrong, and needs to readapt to the what the user sees as right.
Since you mention how fast things move, maybe spotting familiarities between tools and ideas behind them so you can kickstart your learning process
CS fundamentals like algorithmic complexity. This can also help in interviews where Leetcode-like format seems to be the norm.
Aim to work at places that are flexible on the experience with tools (software, framework, OS, etc.).
Aim to work at places that are flexible on the experience with tools (software, framework, OS, etc.).
Judgement. Decision making.
[deleted]
SQL, basic to medium networking concepts, Excel.
Algebra.
be able to build something people want using whatever tools
excel through 3 decades very helpful for routine
Linux systems / command line
SQL
React.js
SQL
React.js