Here are some things I wish I knew when I started out as a Software Engineer. My hope is that these 6 points help you succeed also.
Master your craft. As a Software Engineer, one of your priorities is to build with code. Be excellent at it by continuing to master your craft. Continue to expand your toolbox by learning new languages and frameworks. Not only does this improve your own knowledge, but you'll be able to understand what different tools are good at and how to apply them in new situations.
The best engineers don't just write great code, they build great products.
Writing code is the easy part. Before you start coding, make sure you're clear on what the goal is. Time should be spent analyzing the problem space, investigating the pros and cons of different approaches and designing what to build. Also, most software is built in teams so you'll have to work in a team. You'll have to work with product managers, designers and other disciplines. Learn how to turn concepts into requirements, communicate those requirements to others and then turn requirements into code. The best engineers don't just write great code, they build great products so in many ways, coding is the easy part.
Defining the problem and thinking through an appropriate solution is the real challenge.
Not every problem requires a technical solution. As an engineer, you'll have a tendency to want to fix every issue with more code. It was the case for me at the beginning. In my experience, there have been situations where just having a small amount of better documentation would resolve the issue. Keep in mind that writing more code is not always the best solution. Defining the problem and thinking through an appropriate solution is the real challenge.
Bring your own perspective. You have a unique set of experiences and knowledge. Bring that to the table. If you have an eye for UX, take steps to improve the user experience. If you see an accessibility issue in the product, call it out and work on a fix. Your users will thank you for it.
Write good bug reports. Define precisely what is wrong and what the expected outcome is. Verify these steps to ensure that you're giving clear steps to the person that will take a look at the issue. A tip a senior engineer once told me was to isolate the steps to reproduce the issue to the product in question entirely and if not entirely, as much as possible. The more you can remove doubt that the issue is actually to do with the product in question, the better. It helps keep the issue clear and also has the added benefit of avoiding the awkwardness when the issue is actually in your product!
Celebrate your wins. Not every day is perfect. Develop techniques to celebrate your wins. One technique I have for this is an email folder named "Thanks Derek". I place emails in this folder that contain encouragement, expressions of gratitude or praise. I read through this folder every so often. It's especially useful on days where a meeting didn't go so well, you get that pointed code review comment or there's that difficult technical problem you're struggling to solve. We've all been there.
Any other tips you'd give to new Software Engineers?