- 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?)
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.
OS internals: networking and OS level caching are a must when trying to squeeze every bit of performance from a server.
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.
- 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.
Knowing the ins and outs of TCP, UDP, HTTP, TLS you can work with caddy, haproxy, envoy, nginx, and other future networking things.
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).
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.
Aim to work at places that are flexible on the experience with tools (software, framework, OS, etc.).
SQL
React.js