ImposterSyndrome #JuniorDev #Feedback #CareerGrowth
Hey there, fellow junior dev feeling the imposter syndrome blues 🤦♂️ It’s tough when you’re not getting the feedback you need to build your confidence, right? But hey, you’re not alone!
Here are some tips for navigating imposter syndrome as a junior dev with one year of experience:
- Communicate: Don’t be afraid to ask for feedback from your tech lead! They might not realize you need more reassurance.
- Self-reflection: Take time to reflect on your accomplishments and strengths. You’re doing better than you think!
- Continuous Learning: Embrace opportunities to learn and grow, whether it’s through side projects, online courses, or tech meetups.
- Build network: Connect with other developers, attend industry events, and seek mentorship. It can be reassuring to know others have gone through similar experiences.
- Celebrate small wins: Give yourself credit for the progress you’ve made, no matter how small it may seem. 🎉
Remember, it’s okay to feel a lack of confidence sometimes – it’s all part of the learning process. Keep pushing forward and believe in yourself! You’ve got this! 🚀 #YouGotThis
Being scared over asking for feedback is going to hurt your career growth. You’re going to need to learn to ask for it sooner or later. Hopefully sooner, because you’re expected to not know much as a junior. Imagine being a senior and still being afraid of asking for feedback! Communication is too important in this field to have your anxiety get in the way. It damages your growth as an engineer too much, especially at the start.
Time. And talking to seniors learning that they were at where you are at one point in their career.
Also you literally can’t fuck yo as bad as the people at crowdstrike like you think you can
Study system design as much as possible and learn to take joy in critical feedback. It’s a gift to be given feedback that is actionable and helps you become better- every day you try and move one step in the right direction. The name of the game in this field is that you are wrong a lot of the time, you don’t know the right tools, you think you do, and then you find out that there was a better way, rinse and repeat. You keep learning, staying mentally flexible, and taking joy in being wrong and when you put in the hours you come out of it having hopefully built some cool stuff and being good at making choices about how to design better systems than you used to.
Read Think Again by Adam Grant
If you’re in therapy they probably don’t want to give any feedback and risk causing you a mental breakdown. You should be the one who initiates more feedback. Perhaps mention in standup that you wouldn’t mind some feedback or constructive criticism, you can handle it.
no feedback on PRs? sounds like a red flag.
You should learn to speak-up when required. Ask for feedback, especially during your quarterly check-ins and before formal reviews.
As regards Imposter syndrome, [that feeling will never leave you, even as you grow in the field](https://www.youtube.com/watch?v=OAhe887epU8&t=74s)
She sounds like an amazing tech lead.
There could be plenty of reasons that she’s not leaving reviews on your pull request. Potentially, they’re satisfactory and therefore she decided that you don’t actually need to change things.
I tend to take the position that these kind of discussions should be had proactively at the start of working on a card. If you get to the end of the card and you’re having to leave large pieces of review on a card, then that’s a failure of the team because it’s going to cause a bunch of rework.
At the same time, all of the code quality, formatting, tests and test coverage in our team should be defined in the actual build. Assuming yours is similar, if your build is passing, that means you’re past a whole set of bars before merging.
If she really is a good tech lead though, these are the kind of discussions that you should have directly with her. If your team is running a standard agile loop, you should also have a chance to bring up some of these kind of things at a retrospective.
The other problem with grading people and providing them feedback about how they’re going is everybody contributes differently to teams. So your path is not necessarily the same as somebody else’s path. So long as you’re contributing in a positive way to the team, you’re getting work done and learning, then there’s very little to expect of a junior beyond that.
My current junior, Alex, started with me with zero experience because he was in the middle of Ukraine in a war. He went from being very not functional for the first three months, to being partially functional for the next six months, to being finally in a position where he was starting to hit goals. Now, give or take 18 months in, he’s starting to become an MVP in the team.
His communication skills are becoming second to none. He’s becoming the person within the team that makes sure everybody’s on the same page, and we’re a fully remote team.
I often say this to juniors and mids, the difference between the levels is not fully in the hard skills. You need to have a baseline of hard skills. But the majority of the difference between a junior and a senior, aside from having seen things before, is the responsibility they take around the team, the project.
And that manifests in different ways. You can become the person that is absolutely making sure that the build is always passing and the code is not negatively impacting other people. You can be the team member that is making sure that the next junior along is becoming productive more quickly and is growing. You can become the person that is making sure that you are taking care of the product managers needs and being a very product focused engineer. You can become the deeply architectural engineer, though in my experience this tends to be slightly over represented. Or some combination of all of them. You can’t do everything though.
It really sounds like you’re doing fine. Imposter syndrome is so hard, and it isn’t isolated to people that are junior. I’ve definitely spent many hours of my career wondering how good an engineer I actually was. It’s impossible to know really. Nobody has the ability to measure this effectively. It’s highly dependent on the needs of the organization.
Somebody that has a deep passion for maintaining code is going to be valuable to an organisation that has legacy codebases. A gungho cowboy coder is going to be much more useful for a startup that desperately needs to find product market fit. Both would rank badly in the wrong situations.