1. Write code for production. Set up CI/CD, build tests, deploy to a package repository if it makes sense, etc. If you're building and maintaining an actual pr

1. Write code for production. Set up CI/CD, build tests, deploy to a package repository if it makes sense, etc. If you're building and maintaining an actual product, you get feedback that forces you to identify and solve problems. Writing real tests forces you to think about testing your code, solve problems in tests, make tests run quickly, etc. Ideally, you're working on a team, so you're also looking at the work that others do and critiquing it and they're critiquing you. You're looking for actionable critiques, "if you change X, you get Y," which should help you learn the idioms your peers use and an intuition for why one way of doing it is better. 2. Learn from your standard libraries. Generally your standard libraries are the best code you'll see. Popular open source libraries, especially ones that are de facto standard libraries, are a close second. Even when they aren't how you'd like to write your code, there's a lot of wisdom in the compromises they made. Read their decision making process, JCPs, PEPs, Go proposals, to find insights as to why the language does things one way or another. 3. Math > Docs >> Stack Overflow >>>> Tutorials You won't do math every day to implement things, but you're already comfortable with it, so practice expressing the math as cleanly as your language allows. The math of CS is way simpler until you get into AI or compiler theory, so it shouldn't be hard to find resources that explain it. The next stop that should address 95% of things you need is your language's documentation. Stack Overflow is okay for solving obscure problems, but rather than copypastaing a SO solution in your code, figure out what it does and why it works. And SO answers are routinely badly wrong or out of date. Most tutorials and blog posts out there are hot garbage. 4. Why is this better? That's the question you want in the back of your mind. As you're maintaining your old code (recall point 1) you should be looking at it and thinking, "I don't like how I did this." Then redo it, make it better, and think about what's better. How you structure code, how you name things, how you manage compatibility, all these are hard to quantify and explain. But the subtle pros and cons of different choices become really obvious (to you, at least) when you're refactoring and fixing your old code.