Experts have built up enough knowledge and experience that they often intuitively know the correct way to do something, and it's hard for them to explain why. Meanwhile, novices need precise, step-by-step instructions for doing specific tasks. This is the fundamental difference between the two, and shades of this are seen in the Dreyfus Model of expertise.
Novices aren't sure what success looks like, so they need specific steps to accomplish a specific task.
They don't respond well to unexpected events and function best with "recipes" or decision trees that give context-free rules. The major limit here is you can only specify so much context, so rules only carry one so far.
Advanced beginners still can't troubleshoot too well, but start doing more work on their own. They often look up information fast to expand their knowledge, already knowing the basics. They begin forming principles but nothing too large in scale. The big picture still seems unimportant.
Troubleshooting and novel solutions happen more easily in this stage and can apply more expert advice. They know how to better recognize problems and will seek them out, and know what details to focus on. They're seen as "resourceful" but not often in leadership roles, and get along well with both mentoring novices and dealing with experts.
Proficient coders actively seek the big picture and dislike oversimplified tasks and info. They can also self-correct their poor performance, revising past approaches and learning from others' experiences. They know the contexts to apply larger rules of thumbs to solve problems, such as knowing what parts of a program to test, or applying design patterns. They can predict how things will go, and if things go differently they still know what changes to make.
Coders at this stage are finally a good fit for Agile methodology. Don't assume ones at earlier levels will be.
Experts (about 1% to 5% of the population, so not many) continually look for better methods and approaches. They intuitively know what info/experience to tap into and are often thought leaders. This reliance on context-dependent intuition lets them make the work look like magic, but also makes them bad at guiding less experienced coders.
Experts work best when let loose without rules, letting their intuition guide them. Restricting them is a bad idea.
Pay-scale or career ladder limits often drive a company's experts away. Avoid the knee-jerk urge to treat them like other employees if their expertise provides more value to the company since it's much worse to lose them.
The higher one gets on the model, the more self-doubt and awareness of lacking knowledge one tends to show. Moving up means being aware of what you don't know and seeking it out.
Mimicking the behavior and knowledge of those higher up also helps a lot. Learn by example.
Avoid relying too much on tools, frameworks, and formal methods to boost your expertise. They're tools, not actual measures of one's skill - acting like training wheels that may have false authority as "the only bike you'll need." Reality is always more complex and these nuances must be remembered. Keep these related tidbits in mind:
The tool won't always reflect reality, so don't get too attached to it
Value traits that can't be easily formalized, like problem-solving
Don't rely on or encourage herd behavior
Don't oversimplify complex situations. It's never "all you need to do is X" since context always adds complexity
Remember that objectivity without context doesn't exist
The more of a novice one is, the better they work with rules, considering all factors, and being a detached observer.
The more of an expert one is, the better they work with their intuition, applying relevant focus only, and being actively involved in the system.
Workplaces should also try to balance out these roles, not seeking to have all of one or the other. Experts looking at the whole forest need beginners focusing on the trees, and vice versa.