It's essentially the same advice given to writers. Read a lot and write a lot. If you can get access to review work by folks on other teams that do more codin

It's essentially the same advice given to writers. Read a lot and write a lot. If you can get access to review work by folks on other teams that do more coding, that would be a good start. From there, you need to allocate time to looking at changes closely. Don't just accept things at face value. Ask basic questions like "why is that there?" and "what does that really mean?" and hunt the answers down. Code consistency can mean many things, formatting and variable casing are the obvious things, but also things like how method names are constructed (e.g. when do you use "get" vs "fetch" as a prefix), are concepts named consistently (is "business hours" always spelled "business hours" adjusted for casing or is it called things like "hours" or "biz hrs" in some places. I look for three big things: * technical soundness - does the code do what it says it does? * ontological soundness - are the concepts used well defined with clear boundaries and do they play well with the conceptual framework of the rest of the application? * semantic soundness - is the meaning evident? does the code do what you'd expect? How hard is it to reason about what the code does when it is called? I view writing code as a primarily communicative activity. So, I evaluate it based on how well the ideas it embodies are structured and how well it communicates those ideas.