For junior engineers, it's mostly contextual. How to act on a team. How to communicate with engineers and non engineers alike. What your personal coding style i

For junior engineers, it's mostly contextual. How to act on a team. How to communicate with engineers and non engineers alike. What your personal coding style is. What you value as an engineer. How to take and give criticism. How to use common tools like git, a debugger, browser dev tools, etc. A big one: that it's usually a really good idea to say, "I don't know what that means." Being honest when you don't know what someone is talking about is probably the single biggest 'hack' a junior engineer can do to level up faster (provided they have a supportive team). A lot of junior engineers don't know what someone is telling them and end up burning a lot of time googling what could be taught in a few seconds. Any decent senior engineer will understand that you don't know very much and you're going to need to be taught. Exceptional engineers will be able to read you and see that you're confused and help you, but you can't count on having one of those on your team, so you'll have to let them know when you don't understand things. For more experienced engineers without formal training, by and large the biggest way I've seen they can level up is learning about data structures and algorithms and how the two concepts play with one another. We mostly deal with arrays and hashes in our day to day, but understanding graphs, stacks, queues, linked lists and being aware of more exotic but usable data structures like tries and bloom filters (for example) is a great way to round out your coding skills. Understanding the read and write time of certain data structures and the algorithms that go with them and how you can sometimes trade space for runtime efficiency (e.g. copy your array into a hash/dict/object that is keyed on what you're checking on for fast look ups in a loop) or vice versa will help you write better, more performant code with intent. Another big sleeper skill you can fill in is learning programming language design. It was a really tedious subject in school that I hated, but studying programming languages and how you take a C expression and turn it into an instruction the computer could understand introduced me to a ton of concepts. I don't necessarily directly use them regularly, but they inform my development style - tokenizing, grammars, context, tail recursion, scoping, etc. I'm really glad I spent the time to learn that subject, even though it was really hard at the time. The other thing I had the benefit of was a formal math education. I don't necessarily use calculus every day, but understanding the idea of a derivative or an integral is very useful in software engineering. A graph of metrics for instance - taking the derivative of a graph that changes frequently will tell you the rate of change - understanding how this works and why it's important helps you make smart decisions, and also gives you a seat at the table when you get into the upper levels of engineering.