Starting your career as a developer can feel both exciting and overwhelming. With so much to learn, it can often feel like everyone else already knows what they’re doing. At Atomic Object, I’ve been lucky to be part of the Accelerator Program – a program for recent graduates that combines career development opportunities with real client work.
Some of the ideas below come from discussions in our Accelerator sessions; others are habits I developed back in college. I hope these tips offer a fresh perspective to help new developers accelerate their growth and confidence.
These five guidelines have helped me grow substantially in my first year and a half at Atomic. I call them tips rather than rules, because the reality is that it would be nearly impossible to follow them all the time. This sentiment aligns quite well with Tip #1.
Tip #1: Give Yourself Grace.
This one might sound like a softball to start with, but it’s foundational. If you’re reading this, you’re probably a junior developer, and chances are, you’ve experienced at least a little impostor syndrome. In a field that’s constantly evolving, it can sometimes feel like you’re barely keeping your head above water.
Giving yourself grace doesn’t mean slacking off when you’re overwhelmed. It means recognizing that growth takes time, mistakes are inevitable, and no one, not even senior developers, knows everything. Accepting this fact gives you the space to feel excited rather than intimidated by how much there is to learn. A positive attitude and willingness to take risks and fail is essential to growing as a developer.
Tip #2: Teach and Learn.
At Atomic, one of our core values is Teach and Learn. It encourages us to share knowledge freely and stay open to learning from others. I also like to apply this principle on a more personal level: teach others as a way to learn for yourself.
Back in school, one of the best ways I mastered difficult concepts was by explaining them to others, even when I wasn’t 100% confident in them. Teaching exposes the gaps in your understanding and helps you fill them in. Note, this method only works when you approach it with humility and a willingness to be wrong.
Implementing this in a workplace setting can be difficult to start, but ultimately pays off. If you’re nervous, you can start off by explaining a technical concept or an approach to a rubber duck (or other inanimate object). While the rubber duck method is common and well known, I want to emphasize that this is not just a tool that you should use once you’re stuck on an issue. Explain solutions and methods that seem simple or obvious – you might reveal gaps in your knowledge that can help you reach a higher level of understanding for these concepts.
Once you feel more confident, offer to lead “Knowledge Shares” (short presentations on nuanced code or features) on implementations you made for difficult problems. These can work well as group pull request reviews and also prevent knowledge silos. While your rubber duck can listen, it can’t ask questions. The questions your team asks will strengthen your understanding of a topic even more.
Tip #3: Never Commit Code You Don’t Understand.
This one goes hand-in-hand with Tip #2, and while it’s tough to follow, it has, in my opinion, the most significant return on investment.
Every developer eventually finds themselves in this situation:
You’ve been debugging for hours, maybe days. You’re frustrated, exhausted, and ready to move on. Finally, miraculously, you stumble upon a three-line fix from Stack Overflow or ChatGPT that resolves the problem. You commit it, open a PR, and breathe a sigh of relief.
Fast-forward three months, and someone asks the dreaded question:
“Hey, what does this code do?”
Nobody wants to be in that position without a solid answer. This is why I recommend doing your best to never commit code that you don’t understand, and more specifically, can’t explain to others (Remember, we learned in Tip #2 that teaching concepts to others often reveals gaps in our own knowledge that we wouldn’t have otherwise noticed). Fully understanding the random fix you’re adding to the repository can allow you to fix a similar issue even faster next time it crops up, or it may reveal that the solution you had was imperfect and prevent future headaches.
Tip #4: Ask Questions (But Try to Find an Answer First).
Starting on a new project, especially as a junior developer, can feel overwhelming. There’s simply so much you don’t know yet. Asking questions is crucial, even when it feels uncomfortable. Most teammates would much rather you ask early than silently guess and cause preventable issues later.
That said, there’s an art to asking good questions. You should avoid simply saying “My code doesn’t work the way I think it should, can you help me?”. Before reaching out, take time to explore possible answers on your own. Try a few approaches, take notes on what you’ve tried, and document each outcome. When you do ask for help, you’ll be able to say, “Here’s what I’ve tried and what I observed,” which makes it much easier for more experienced developers to help you. It also shows initiative and curiosity, which will serve you well down the line.
Tip #5: Say Yes!
This final tip comes with an important caveat: it assumes you work in a psychologically safe environment with coworkers who genuinely want to see you succeed. If that’s true for you (as it is for me), then my best advice is simple … say yes!
When new opportunities come your way, even ones that feel intimidating or “too soon”: say yes. Maybe it’s demoing your team’s recent work, spearheading the development of a new feature, or consulting with the client directly on a difficult issue. These moments can be nerve-wracking, but they’re also where the most growth happens.
Saying yes does two powerful things:
- It signals interest. Your teammates and managers can’t advocate for your growth if they don’t know you want those opportunities.
- It accelerates learning.Stepping outside your comfort zone helps you build confidence (and the skills to back it up) faster than passive learning.
Final Thoughts
As I mentioned earlier, these tips aren’t hard-and-fast rules. There will always be times when other priorities make it difficult to follow them. However, in my experience as a junior developer, following these principles has made a huge difference in my growth and confidence.
If you’re lucky enough to work somewhere that encourages professional development, lean into that. And if not, you can still apply these tips on your own – they’re meant to be universal habits that can help any new developer thrive.