Going to give the advice I would have gave to my younger developer self: General: - Use a debugger. Stepping through code or existing code is an incredibly qu

Going to give the advice I would have gave to my younger developer self: General: - Use a debugger. Stepping through code or existing code is an incredibly quick way to grasp what is going on. - Exercise healthy paranoia. Expect your code paths to fail. How will you handle failures? - Code hygiene. Legibility of a codebase makes me respect it a lot more. I feel that I subconsciously handle it with more care when well written. - Interfaces. Whether your writing an API, a data access utility, etc. -- think about the design in your current and other contexts. - Language. Whatever language you work in Node, Ruby, Go, etc. know it and its quirks well. Backend specific: - Docker. It really changed the way I work. I think the learning curve can be a little steep, but once you're comfortable it leads to much more productive development that is ready for production. - Load testing. You should be able to identify potential bottlenecks in your application and decide whether they're worth fixing or not. - Observability. Think about how you will profile and gather metrics of your application when deployed. - DevOps. A lot of workplaces will expect their SE engineers to help with or even be DevOps. It's a big surface area, so I would focus on knowing the parts of the stack that make your application work (containers, databases, virtual networking) - Pushing work elsewhere. Sometimes you're going to run into a problem that can't be solved by code changes alone. A basic understanding of how to push workloads elsewhere like message queues / serverless functions and the patterns associated with them. For example, a user uploads an image to your server and you need to compress it.