“It took me four years to paint like Raphael, but a lifetime to paint like a child.”
In coding terms, beginners have a kind of fearless creativity that we often lose as we become more disciplined.
Sometimes, the simplest solution, the “novice” solution, works.
Consider this perspective. I once came across a comment that read something like this (paraphrased): “If you’ve been in this line of work long enough, you may find that the best code by experienced programmers often looks like ‘novice code that simply works’, without unnecessary extras, and that blindly applying ‘best practices’ everywhere needs to chill.”
This observation resonated with me after my experience with my son. Maybe the code doesn’t have to be perfect at first. Maybe what junior devs need is the space to make it work their way, and only then make it better over time.
Teaching my son made me reflect on my own coding journey. I definitely wrote some cringe-worthy code in my early days (I’m pretty sure some of it lives on in a private repo, never to see the light of day). But those mistakes were learning experiences.
If my early mentors and the seniors had forced me to follow every best practice checklist from day one, I might have been overwhelmed and discouraged. Or even left the industry for long.
Guiding a young coder without overwhelming them takes patience. With my son, I chose to let him explore first. With junior devs, perhaps we should do the same: let them write that “ugly” code initially and use the experience as a springboard for teaching moments.
For leads and seniors, I believe that mentorship matters more than policing code style. Yes, we want juniors to learn the right habits. No one’s advocating for shipping sloppy code to production. But it’s all about timing and delivery.
Think of how you’d teach a kid. You wouldn’t start them on Shakespeare before they can enjoy a simple story, right? Similarly, dropping a 300-page “Clean Code” rulebook on a junior dev’s desk on week one might not be the most effective strategy.
Instead, encourage a culture where juniors feel safe to ask questions and even fail sometimes. When I see a junior developer struggling, I try to remember to be patient. Bombarding them with ten things they did “wrong” can crush their confidence.
I’ve learned to prioritize which best practice really matters for the task at hand and focus on that. For instance, if a piece of code works but isn’t optimal, I might let it slide for now and praise them for getting it working.
Later, in a code review, I’ll suggest improvements kindly. “This function works great. Good job! Now, let’s talk about how we might organize the code a bit more clearly. Maybe we can break this into smaller functions. What do you think?” By framing it as collaboration rather than criticism, we keep their morale up while still guiding them toward better patterns.
Every senior developer was once a newbie too, and it’s easy to forget that. Few wrote perfect software from the start. Most of us learned best practices gradually, often after feeling the pain of not following them.
A junior dev who writes a confusing piece of code and later struggles to fix a bug in it will likely be all ears when you then explain the value of clear naming or separation of concerns. They’ll have that “aha” moment because the lesson is tied to something they experienced.
I used to work with a senior who is now a CTO-level executive. He used to tell me this when I asked him for advice on writing better code; he said directly this: “Alvis, write it, ship it, and hate it. Find out why you hate it and why your teammate hates it. Now ask the right questions, understand the feedback, and then do things better this time.”
Many developers know the rules/principles (e.g., SOLID, DRY) but don’t really grasp the WHY until they see a real example. Our job as seniors is to provide those examples and guidance at the right time.
Another thing senior folks should guard against is turning best practices into dogma. Yes, we have standards for a reason, but we should always be open to discussion.
I’ve seen cases where a junior asks, “Why are we doing it this way?” and the answer is “Because that’s the best practice.” That ends the conversation, but it doesn’t teach them anything. Instead, take it as an opportunity: explain the reasoning or even admit if it’s just one way to do it out of many. You might say, “We do it this way because in the past we had problems with X, and this approach prevents that.” Such context is gold for a junior dev’s learning. It shows them that best practices aren’t arbitrary rules but solutions to real problems.
The role of a leader is part teacher, part cheerleader. Celebrate the small wins. Did your junior dev write their first feature that works? Celebrate the milestone enthusiastically.
There will be time to refine it, but their sense of accomplishment is fuel for their growth. When it comes time to refactor that feature to adhere to some best practice, do it with them, not for them, and not against them.
Pair programming and code reviews can be fantastic teaching tools if done in a positive spirit. Instead of “Your code is wrong because it doesn’t do X”, try “This is working well. One thing we often do in situations like this is X, because it helps with Y. Let’s refactor it together and see if you like the result.” This way, you’re not forcing a practice on them.
You’re demonstrating it and inviting them to see the benefit.
There’s a wonderful insight I once came across: some best practices exist basically to help average code be serviceable in a team environment. In other words, they’re safety nets. They matter more as projects scale and teams grow.
A lone beginner on a toy project doesn’t need the full weight of enterprise-level standards. So as a senior, it’s okay to adjust your expectations based on context.
Early on, optimize for learning and enthusiasm; the polish can come next.
What’s worth considering is that writing some tests is better than being scared off by a mandate to have 100% test coverage. Using some descriptive variable names is a win compared to being paralyzed by a 50-rule style guide.
Every best practice you know was learned over years. Don’t expect a junior to absorb them all in a month. Same as you wouldn’t expect your toddler to understand why he shouldn’t pee in his diapers. It takes many rounds of practice until he pees and flushes like a grown-up (though even adults sometimes forget to flush).
Teaching my young son to code ended up teaching me a lesson in return. I learned that whether it’s a child or a junior developer, people learn programming best when they are allowed to enjoy it first.
The craftsmanship can come later.
Best practices are, without a doubt, an important part of professional software development. They help teams write safer, cleaner, more maintainable code.
But there’s a time and place for everything.
Pushing every rule and standard on day one is like telling someone who’s just picked up a paintbrush to only use techniques from the old masters.
It might improve their “form”, but it could also make the experience so rigid and unenjoyable that they quit painting entirely.
If we want to cultivate the next generation of great developers, we need to let them write some “bad” code in the beginning.
Let them get a feel for making something work on their own.
Let them revel in the fact that they wrote a program that does something, even if the underlying code barely holds together. There is plenty of time to teach them how to improve it afterwards.
In fact, that’s when teaching best practices works best. After the newbie has struggled a bit and is looking for a better way. They’ll be hungry for that knowledge, rather than feeling like it’s being forced down their throat.
V
Become a subscriber receive the latest updates in your inbox.
Member discussion