Stop Being a Junior  ## Metadata - Author: [[kentcdodds.com]] - Full Title: Stop Being a Junior - Category: #articles - Document Note: --- tags: - #career - #softwaredevelopment - #growthmindset Author: Kent C. Dodds Source: Blog (kentcdodds.com) Reference: https://kentcdodds.com/blog/stop-being-a-junior date created: 2025-08-22 00:00 --- # Title: Stop Being a Junior ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Kent C. Dodds, “Stop Being a Junior.” https://kentcdodds.com/blog/stop-being-a-junior ## 📝 Summary: The article argues that “junior” is a mindset and organizational perception more than a fixed time-based status. Because software moves quickly, developers who focus on a few technologies can reach impactful proficiency rapidly. Kent shares how he shed the junior label by pursuing higher-leverage work, seeking architectural responsibilities, speaking publicly, teaching internally, and making his growth goals explicit to managers. If internal perceptions remain fixed, changing companies can reset expectations. The call to action: stop identifying as a junior and start acting like the role you want—respectfully, collaboratively, and with awareness of experience gaps. ## 📖 Main Content: The piece reframes “junior” status from a tenure-based label to a behavior- and contribution-based identity. Key premises: - There’s no time requirement to stop being junior. - Tech’s rapid pace lets focused learners attain expertise quickly. - Experience brings pattern recognition and better constraint awareness, but also potential inflexibility. - To grow, emulate senior behaviors: volunteer for complex work, sit in on architectural conversations, study and propose improvements, teach colleagues, and communicate career goals early and often. - Visibility matters: talks, brown bags, and documented outcomes demonstrate senior-level impact. - If organizational perception is stuck, consider moving to an environment that aligns with your capabilities and aspirations. The author’s story illustrates this trajectory: moving from being seen as “the intern” to taking on architecture work after switching companies, delivering a successful tooling migration, and accelerating career growth. ### 🗒️ Notes - No fixed timeline to “not junior” - “There’s absolutely no time limit... Any number... is wrong.” - Seniority is about behaviors, impact, and learning pace—not years alone. - Fast-moving industry advantage - Rapid evolution allows focused learners to catch up quickly. - River analogy: once in the current, you can keep up with others even without “upstream” experience. - Nuanced view of experience - Strengths: faster learning through analogies to past tech; early problem detection; constraint awareness. - Risks: being set in ways; missing new features and tools; slower adoption of modern practices. - Adopt senior behaviors now - Ask to observe complex meetings; take notes; follow up with questions. - Study after meetings; come back with measured suggestions. - Balance enthusiasm with humility; seek mentors to fill experience gaps. - Become a force multiplier - Learn new tools and share via brown-bag sessions; if none exist, start them. - Speak at meetups; propose conference talks; showcase accomplishments. - Manage up with clarity - Tell your manager early about promotion goals; ask for expectations required to reach the next level. - Operate at the desired level before the title changes. - Organizational fit and perception - If stuck with the junior label despite impact, consider switching teams/companies. - The author’s switch yielded a 50% pay bump and architectural responsibilities; led a successful frontend tooling migration. - Mindset shift - “Instead of thinking about how to stop being one thing, think about how to start being something else.” - Aim higher; you’re capable of more than you think. ## 📖 References: - Kent C. Dodds, “Stop Being a Junior.” https://kentcdodds.com/blog/stop-being-a-junior ## 🗣️ Paraphrase: 1) Original idea: There’s no mandatory time period before you stop being junior. Paraphrase: The “junior” label isn’t earned off a calendar. Any rule that says you must log a set number of months or years before outgrowing it is mistaken—progress hinges on the value you deliver and how you operate, not on elapsed time. 2) Original idea: Emulate seniors and proactively engage in complex work; learn fast, contribute, teach. Paraphrase: Study how senior engineers behave and start doing those things: join higher-stakes conversations, learn the context, suggest improvements carefully, and share your findings with the team. Pair rapid learning with humility about your experience gaps, and you’ll quickly become an outsized contributor. ## 📰 Newsletter: Learning web development is a wild ride—good news: the river’s current is fast. Focus on a few tools, learn them deeply, and you can deliver senior-level value sooner than you think. Recent community highlights: internal brown-bag sessions are back (bring lunch, leave with deployable insights), and our local meetup CFPs are open—your story about migrating a legacy build or hardening an API could be the talk that lands your next role. New WordPress goodies include streamlined site health tools, performance-focused plugins, and contributor-friendly GitHub templates that make your first PR a breeze. If you’re growing your skills, try teaching what you’ve learned: write a post, record a short loom, or host a lightning talk. Want more? Check out practical guidance on dropping the “junior” mindset and stepping into higher-leverage work in “Stop Being a Junior” by Kent C. Dodds (great for goal-setting with your manager and planning your next talk). Keep shipping, keep sharing, and remember: the title follows the work. ## ✅ Action Items: Prompt for aligning articles with your role (Developer Advocate, OSS/WordPress, aspiring OSPO director): - Purpose: Analyze how each article informs open-source advocacy, contributor engagement, and education in WordPress, with transparency and inclusivity. - Prompt: “Given this article: 1) Map its core recommendations to: - Open-source contributor onboarding (first issues, mentorship, docs, brown-bags). - Sustaining funding and governance (how behaviors scale in community-led models; incentives). - Educational design (workshops, curricula, learning pathways for PHP/JS/HTML/CSS/Git/GitHub). 2) Identify actions I can pilot at GoDaddy and in the WordPress ecosystem: - Internal: brown-bag series, architecture roundtables, talk rehearsal groups, contribution sprints. - External: meetup talks, contributor days, CFP coaching, office hours, async learning hubs. 3) Define metrics of impact: - New contributor retention, PR throughput, review SLAs, mentorship matches, talk proposals, documentation updates, community satisfaction. 4) OSPO alignment: - Policy templates (goals conversations, growth rubrics), transparent career ladders, recognition programs for educators and maintainers, DEIB standards in programs. 5) Risks and mitigations: - Overconfidence without experience—pair with mentorship and staged responsibilities. - Burnout—timeboxing advocacy and teaching; manager buy-in; recognition frameworks. 6) Deliverables: - A 90-day plan merging advocacy + education: curriculum outlines, speaker pipeline, contribution playbooks, and funding proposals supporting maintainer time. Summarize how the article’s “act like the role you want” translates into community - Summary: Stop Being a Junior provides advice for junior developers who want to progress in their careers. The article challenges the idea that there is a set time limit for being a junior and emphasizes the importance of staying up-to-date with emerging technologies. The author encourages junior developers to take on more complex tasks, participate in meetings, and actively seek learning opportunities. They suggest volunteering for speaking engagements and sharing knowledge with colleagues through lunch meetings. The article concludes by emphasizing the importance of communicating goals to managers and operating at the level of the desired position to eventually achieve it. - URL: https://kentcdodds.com/blog/stop-being-a-junior?utm_source=substack&utm_medium=email   Are you a Junior developer? If you answered yes: How do you know? Is it because your title is "Junior Developer?" Is it because your co-workers get all the more **interesting work** and you're stuck with the more boring repetitive tasks and **simple bugs?** Or do you just not feel like you've not "done your time" yet to drop the "junior" moniker? Whatever the case may be, I want to tell you to stop being a junior. **Stop it now.** I've talked to lots of people who start their conversation with me by saying "I'm just getting started" or "I'm just a junior" to which I reply "that's great! Welcome to the software development world" only to find out they've been working as a software developer for over a year and a half already. This surprises me. And it happens so much that I decided to write this blog post about how to get yourself out of this eternal-junior situation and start making major positive movement in your career. First of all I think it's important to establish this first: There's absolutely no time limit on how long you have to be a developer before you are no longer a junior. Any number on that you may have heard is wrong. One of the things I love about this industry is the pace it moves: fast. With emerging technologies all the time and improvements to existing technology, it really doesn't take much time for a developer staying on top of these advancements in their area of interest to reach a level of familiarity that rivals those with decades of experience. I think of it like this. Imagine there's a river with a steady current. Riding on a tube down the river is like developing experience in software development. Instead of everyone starting at the beginning of the river, they start where everyone else is. It doesn't take long once you jump in to keep up with everyone else on the river, regardless of how long they've been doing it. Yes, you'll be lacking in experience upstream, but that doesn't change the experience you're having *now*. It's an imperfect analogy, I know, but I think it's instructive. Now of course, there's a lot to be said for people with decades of experience, and while most of it is positive, not all of it is! People with years of experience are more likely to be able to **learn new things faster** because often new things resemble old things (though not always!! "unlearning" is definitely a thing too). Experienced developers are also more likely to be able to **identify problems** in code long before they are problems because they've seen how things play out in the real world and they understand constraints better. That said, experienced engineers are also more likely to be hesitant to try newer tools and technologies and instead be **"set in their ways."** This can lead to them missing out on really terrific advancements in the ecosystem and tools. Experienced developers are also likely to miss important new features in languages and tools because they're just used to doing things a certain way. Anyway, my point is that because of the pace at which the software developer industry moves is so fast: Staying on top of a few chosen technologies allows anyone to become an expert in them rather quickly. And if that person can temper their enthusiasm with a realistic understanding of the impact of their lack of experience just a bit, they can make an enormously powerful impact to the company (if they're allowed to). I went to college and had internships while I was in school. This gave me awesome exposure to the field before I was officially looking for a full-time job. So by the time I graduated, I had already been working as a part-time software developer for a year and a half. When I graduated from BYU and joined as a full-time engineer, **I had trouble shaking off the "junior" moniker.** Even though all my experience up to that point had been part-time work while I was still in school, I felt like I knew my team's area of the codebase as well as anyone else and it didn't feel right to me that **I still got the lower priority tasks.** I saw some really big architectural level tasks going to the more experienced engineers and I wanted a piece of that. However, since I converted from student to full-time employee and everyone knew me as the student, **I always felt like people saw me as "the intern".** Maybe I could have been a little more assertive about my goals and hopes, but I just decided that the only way for me to get more responsibilities was to go to a new company where people had never seen me as "the intern" and would instead see me as a regular co-worker. So that's what I did. Just four months after converting to full-time, I was recruited away to my next company where I was given a massive pay bump (over 50% increase) and 20% of my time was devoted to architecture. It was phenomenal. Nobody ever saw me as a junior again. In fact, **I was just a step below architect** in a quarter-billion dollar organization **only 4 months** after graduating from university. And that played out extremely well for them. When I joined the company, they were wanting to do a major migration of their frontend tooling. I was instrumental in designing the migration path and it was a **smashing success.** Read my whole story in [2010s Decade in Review](https://kentcdodds.com/blog/2010s-decade-in-review). Instead of thinking about how to stop being one thing, think about how to start being something else. What do senior developers do in your company? Do that instead of the things junior developers do. That's it. Naturally the company likely trusts the seniors with more than they trust you and **you don't want to overstep,** but *volunteer to participate* in the more complicated tasks. Even if it's just "hey, can I come sit in on that meeting?" Take notes for yourself of anything you're unfamiliar with and ask about those things later. In future meetings you'll be able to contribute more and more with the knowledge you start to accumulate. Study things out a bit after the meeting and make suggestions. Beware of being over-bearing. Even though you can accumulate a lot of modern knowledge really fast, you should be sure to acknowledge that your experience limits the usefulness of that knowledge. So **be respectful** of your co-workers. But find the people who are willing to sit down with you and answer your questions to help fill in the gaps in your experience as you rapidly accumulate knowledge. Use that fast-paced technology to your advantage and learn about what's new and improved that developers at your company can take advantage of today. Then teach those concepts in "brown bag" lunch meetings (meetings where everyone brings a lunch and someone presents something often held weekly). If your company doesn't have brown bag lunch meetings scheduled, get them scheduled and present at them. Volunteer to speak at local **meetups.** A meetup talk is responsible for both my job change I talked about earlier as well as me getting invited to join Egghead.io as an instructor. Propose to speak at **conferences.** **Talk** about what you've accomplished to demonstrate you really are contributing at a level beyond their expectations of a junior. Make them think to themselves *"huh, this dev is only a junior and they did that? Maybe they're not really a junior after all."* **Make sure your manager understands** your **goals** and **intentions** as a developer. If you're hoping to ask for a promotion in the meeting where your manager tells you about whether you get a pay raise, you're asking way too late. They should know your goals much earlier than that and you can ask them what they expect you to be able to do to get to that level. I don't like the phrase "fake it 'til you make it," but the sentiment is here as well. The idea is you operate on the level of what you want to be as well as you possibly can, and **eventually it'll start feeling like you really are at that level.** I felt like I had to leave the company I was with to get up to the level I wanted to be. I probably could have managed it with the company I was already with if I had been more patient. I probably would have done that had I not been actively recruited out. That said, sometimes if you just can't shake the "junior" off your title, you may consider looking for another opportunity. I hope with this article to not diminish the amount of work it takes to gain experience and make impact in this industry. It's a lot of work. However, my primary goal is to help inspire some folks to set their sights higher. You're capable of more than you think. I promise. You don't have to be a junior anymore. It's time for an upgrade. Good luck!, Stop Being a Junior, kentcdodds.com, 01h5q48fgs6secbghxezk8yke9.