Ask HN: Which hard skills can I learn to become a better programmer?

Optimization: not everyone has a super fast computer and a super fast internet connection. Too much is wasted there.

You haven't mentioned which hard skills you've already mastered.

* Abstract reasoning - everything in programming is abstraction

* Critical thinking - is the first way you've thought of to solve something actually an optimal way? how could you improve it?

* Problem decomposition - solve large problems by breaking them down into smaller component problems

* Multiprocessing/multithreading and IPC - at some point one process/thread isn't enough

* Networking fundamentals - may not contribute directly to better programming per se but will for sure help with debugging/troubleshooting

How to sit down still and write lots of programs. How to sit down still and read lots of programs.

A lot of emphasis is put on programming "the code". What I find can simplify a lot of thought processes is to think of the overall action from the outside of the code. Often a system is transitioning from one persisted, consistent state to another persisted consistent state. Reasoning should begin from what needs to be applied to the persisted state at the lower level (e.g. SQL statements). The 'consistency' can be thought of in terms of invariants which must be upheld. Once you have those in mind, you only have to work out the 'plumbing' details of how the code is structured to get the job done.

Besides that learn the details about your infrastructure (what it can and can't do, datastores, networking) and your frameworks/libraries. Don't be afraid to go outside the frequently painted lines to do what's possible, not only what's been done before.

In terms of programming, it's good to learn other languages and formulations that let you think at a higher level. e.g. using map or reduce level processing or single assignment of variable values, immutable collections once constructed, etc simplifies code construction while avoiding common pitfalls like off-by-one errors, shared mutable references, or distributing a single piece of logic in different places. Pay a lot of attention to how to name things, lower level constructs should simply be what they do, higher level things go toward why they're being done. Separation of mechanism (lower implementation) and policy (higher level uses) fits naturally into structuring which is easy to work with and highly adaptable to new requirements.

Lastly don't refactor dogmatically. Choose what the factors are before redrawing the system/process along those seams. Deal with each factor once and avoid having to write, reason about, test factors in combination whenever possible.

I wouldn't consider any of these things as 'hard' (unless you meant technical), it only seems so because they are considered later (after being painted into a corner) rather than sooner.