In my experience, it's easy to just learn on the job. Some basic points though: * Follow whatever formatting and style rules your workplace uses. It's religion

In my experience, it's easy to just learn on the job. Some basic points though: * Follow whatever formatting and style rules your workplace uses. It's religion and not worth getting into, as long as everyone uses the same style its a win. * Dev/stage/prod is also workplace specific. Just go with the flow and avoid time wasting arguments on these topics, it's not usually worth it. * Try to break your work into small commits. This is both easier to review and easier to estimate time on. * Architect your code so that you can add unit tests. Make sure all your commits have this. * Prefer longer simpler code to clever code, you're optimizing for newcomers to your code reading it. * When a one line comment explains it to you, you'll probably need a paragraph at least for someone outside the field to get started understanding it. * Think about how you'll respond to someone coming to you and saying "something something prod something something your code is buggy." How will you get enough information to determine if this is true, and to debug it when it is? Logging is one good tool here, so consider what you log carefully. Finally, don't be too surprised if you find people talk down to you. Unless you are in a FAANG company, which it sounds like you are not, developers can be very condescending towards academics (and people from other fields).