Now my question: With experience, what do you think is important as a software developer. What is something that juniors are often not aware off. Something they don't know they don't know?
1. Break things down into small "complete" steps. Nope, smaller than that. Nope, you can still break that down. Test-Driven Development can help here, not by making sure you've got good test coverage, but by encouraging you to break down the solution into small, testable pieces.
2. When learning something new, don't copy-and-paste. Retype it if you have to, but at least understand _why_ that code will work, and maybe a bit about _how_ it will work. As you get more experienced, you can copy-and-paste, though you'll find you'll do that less anyway.
3. Related to 2 and the post about technical communication: learn how to concisely ask questions. The number of juniors (and seniors) asking questions, but failing to show the precise problem (or at least what they think the problem is), with enough code (but not everything!) to evaluate is...frustrating for those of us who want to help. Tell us what you tried, tell us what the errors are (precisely, i.e., here you want to copy-and-paste!), but do so with as few words as possible. This is _definitely_ a skill, so you'll get better as you do it more, so pay attention to the questions you get in response to your question. Reflect on whether that could've been included in your original question.
Are they? If you recursively try to answer the question "why", I'm certain you'll end up at some level of "because uhm, because uhm... Because I saw someone else do it that way and haven't given it much thought".
Conversations with beginners who know nothing to assume anything is a humbling experience. Some of questions they ask seem to cut right at your area of incompetence.
I see a vast number of posts on HN about React or some other web framework.
There’s more to software engineering than learning the latest flavor of how to render webpages.
Many projects don’t require the complexity of these frameworks and all the added middleware and layers upon layers of tooling.
These are bored people, who solve the same problems again and again, and invent new forms of complexity as if they’re undertaking the Gemini missions or Apollo missions.
It’s less about frameworks or specific tool chains. The biggest piece of advice I can offer you is to get out of your comfort zone, and learn to manage complexity and ambiguity.
This is what I didn’t know earlier in my career.
It’s not so much about quickly learning whatever new framework to once again solve the same problem people have been solving for decades. It is, however, about simplifying complexity, and thinking about how you or your team will support something in the future, will your solution be extensible as and when your product evolves, etc.
Work on projects where you solve problems that are hard to you. Work with more senior people whenever you can. Learn from them. Get comfortable with being out of your comfort zone.
But don’t burn yourself out. Drink water. Exercise. Don’t let your job become your identity.
Also, work on your communication - whether written form or verbal. Write clearly using full sentences. Be mindful that others may not have the context you have or don’t have the expertise you have in a specific. In fewer words, you want to convey a clear message.
Being able to communicate and break down complex topics will natural help you build influence and promote yourself in your career. The leaders will come to you for your judgement.
The key is to keep on asking this question about every project you work on. The world is made up of innumerable little complexities and the faster you reach out for guidance on each domain the better.