| This is something that can be difficult to learn even if you've been working in the industry (lord knows we've all seen awful practices at various companies in our career). This is probably not popular advice, but of all the places I've worked, Google seemed to have the highest standards for best practices I've seen. I recommend paying attention to Google's best practices, in their blogs, certification programs (like the google cloud developer cert), Coursera courses, product docs, codelabs, style guides, git code, etc. Obviously everything they do won't be a right fit for your company, but it's something to aim for. Enforce code style (be specific and use a linter), and write tests as you go. Try to keep bad code out of your repo before PRs can even be merged. I use Jenkins and git hooks to enforce this for the whole team. Draw up design docs and understand business needs before diving into projects and features. Understanding good architecture and operational principles will make you much more valuable as a developer than your peers. Read the Google SRE book, it's free. Also read http://highscalability.com/ articles and learn from other companies' triumphs and mistakes. Books about architecture include the micro services book by Sam Newman. You may not ultimately be responsible for making these decisions, but demonstrate your value by being able to understand and provide quality feedback to your tech leads and architects. Study and learn about project management techniques and craft/enforce your process. Not everything boils down to good code and architecture, if your development process sucks, everything else will definitely fall apart. Be able to spot the flaws in your organization and offer ways to improve their process and quality. By doing so, you will also improve your own. If you have a cloud provider and a support package, use it often. Most of what I know about best practices came from supporting Google Cloud customers, seeing what they were doing poorly, and working together to find better solutions. Be sure you're not just abstracting your API libraries, but your use of 3rd party libraries and services as well. You don't want to have to refactor all of your code just because you need to swap out one technology for another. If you're actually better than the rest of your team, you should be mentoring them. Teaching others is incredibly helpful at solidifying our own understanding of topics, and exposing the gaps in our knowledge. Read "The Phoenix Project". It probably applies more for the DevOps/SRE/Management side of things, but I think there are VERY important lessons to be learned for everyone in there. Highly recommended. |