There’s an interesting progression I notice with a lot of my students as they move through their career arc.
Junior and early-career developers tend to write code that works but is a little less well structured. They repeat themselves a bit, or hard-code things that could be abstracted for easier reuse.
As they transition to mid-level developers, I find that code tends to get almost over-engineered. There’s a tendency to over-compensate for the spaghetti code of your early career by throwing lots of coding paradigms at it.
Would three lines of code get the job done? Of course! But when you wrap it in a
class that you instantiate with options and emit custom events, it looks more “professional,” right? It looks like the code that a more senior developer might write.
But as you approach that senior level, you often strip a lot of that out and write code that’s more direct again, because it’s often easier to maintain and reason about.
The more complex code still has a place. Sometimes, it’s necessary or useful.
But often, its not. Part of growing as a developer is learning when to add that complexity, and when to skip it for something more simple and direct.
If you or your team need help with that, get in touch.
In addition to writing code, I help teams level-up their junior developers, plan and create project roadmaps, and provide ongoing guidance through projects.