You may have the college degree that took years to earn or the coding bootcamp certification that took an expedited route, but that's only half the battle in the corporate world. Convincing a company that they need your skills in order to succeed is a tricky situation. It's not impossible though. But tricky.
We're all juniors at some point in our careers. I myself was a junior developer for years in the beginning, and only really felt confident in my ability to code after several years, jobs and promotions. And after spending a considerable amount of time around more senior and experienced developers.
But it's not easy. You can easily fall victim to things such as imposter syndrome. And in some cases, you might even get overwhelmed by the job and either get fired, or make a career change in an entirely different direction. It happens and I know several developers that have been victims of both.
So, here are a few of my best tips in order to succeed during those crucial first years. Starting with the most important in my opinion.
1. Ask really good questions
There's alot that you don't know about software development, regardless of your skill level. That includes both technical and non-technical things. Technical meaning actual coding implementations that you have never worked on before. And non-technical meaning best-practices, following security guidelines and coding with a team in mind.
The best way to learn all of this (or at least some of it), is to ask better questions to those that already have the answers.
Don't ask your friend that was in the same coding cohort as you. They know as much as you do at this point and probably have the same questions. Ask an experienced developer that you either work with or even reached out to in some capacity.
But don't just ask any questions. Ask better questions. Instead of asking "how do you do x, y and z?", it's better to ask "where can I learn more about x, y and z?". Most senior developers don't mind at all answering your questions, but if it becomes a recurring theme on a daily basis, then your level of skill might start to get questioned.
A huge part of being a developer, particularly in the corporate world, is doing your own research and finding your own solutions to complex situations.
Often times you might be working on something that no one else in your company has yet to tackle, and asking for assistance might be equated to asking somebody else to do that research for you.
And if you aren't yet surrounded by more senior developers, there are still plenty of online resources that you can leverage, such as Discord channels, forums and of course StackOverflow.
The better the questions that you end up asking, the better the answers that you will receive.
2. Learn to stand out
You're pretty much a junior until someone says otherwise. And if you keep doing junior things, then guess what? You are going to be treated like a junior until you do something to shift the perspective.
And often times, that means that you have to stand out in some way. And I don't mean in a loud and overly enthusiastic manner either.
I mean you have to do something that gets everyone's attention. You have to go where the action is at your job.
During my very first coding job, I always made it a point to attend every meeting (even optional ones) and to volunteer myself to work on the newer projects, even when I had no idea what either the meetings or the tasks were about.
And this was not an easy process. It took extra time from my schedule and it put me in situations where I would be tasked with complicated assignments with short deadlines. Because standing out comes with the added risk of looking bad in front of everyone essentially.
But leveraging step 1 above, I was able to ask better questions and to research as much as I needed in order to find better solutions.
Not only did the other senior developers begin to treat me differently (less explanations, more freedom to code), but I myself started to feel way more confident in my ability to tackle difficult problems.
And the more bold that you are, the more projects you will get assigned to.
3. Maintain side projects
Your coding side projects are more valuable than you think. Not only do they help add some bulk to your coding portfolio, but they also keep you actively coding day in and day out.
I've personally maintained side projects for over 10 years now, and while most of those projects don't exist anymore, they still helped in shaping my skills in some shape.
And some side-projects have grown to become actual products, such as this blog.
Because I decided to custom build this blog, it contains over 6 years of actively maintained code that I still update and refactor constantly.
When a new technology appears that I find myself interested in using, this blog is usually where it will get added.
During my early years as a programmer I was also able to showcase my projects during job interviews as well. If anything this allowed me to stand out above the crowd, as most interviewees mainly only have a resume to show.
And truth be told, it doesn't really matter what side projects you have. I always promote developers build something that they themselves are interested in ensuring that they will work on those projects for the long term.
4. Don't write "more" code, write "better" code
If often times run into young developers that try much too hard to write memory efficient and optimal algorithms for very simple things that don't require it.
They need to find a certain number in a collection of 5 items, and find themselves writing 2 dozen lines in order to do so. Because they think that the more complicated the code, the more technically proficient they are.
After 20 years of actively programming on a daily basis, I can safely say that "more code" does not at all equate to "better code". In fact, often times the opposite is true.
Because at the end of the day, you probably won't be the only person working on that codebase. And long, complex and convoluted code might make working on your particular code a disaster.
This means try and avoid using unknown and unmaintained libraries that you found online just because it's there. Doing so pretty much means that someone else later on will have to research that same library in order to learn how it works.
Writing "better" code in a corporate setting means writing code that can easily be read and understood, ensuring proper validation, keeping an eye on performance and overall just reducing the chance of error.
And this takes practice and it takes time.
I myself wrote a ton of code during my early years, only to find it later rewritten or completely erased by my senior lead.
While during that time I may have found it insulting that my super awesome recursive for-loop was all but a memory, I can now appreciate their efforts in helping to ensure a more stable codebase.
In conclusion
It takes time to become proficient at anything in our current world, particularly something as technical as programming. And that's the biggest takeaway from this article. If you're getting burned out and everything seems difficult, then odds are it probably is. But if you stick with it long enough, eventually you find the answer and slowly but surely you will evolve your skills beyond the junior title.