How to grow from being junior
Expert insights from senior developers and recent juniors
In software development, a ‘junior’ is someone who does not have sufficient skill or confidence to handle professional tasks in full independence or with teams. As a junior, it can feel daunting to know how to contribute as much as possible to a task while learning as much possible from peers. Sometimes, the question of how a career will grow long-term, or how certain decisions will affect a junior’s long-term goals may seem overwhelming.
The members of TechMasters discussed effective ways to handle both uncertainty and stagnation in career development. Junior or otherwise, if you are eager to strengthen your software and people skills, then this guide is for you.
Attitude > Aptitude
Have a willingness to learn
Perseverance and openness to change can bring a lifetime of value. Don’t just be diligent with self-study, but also listen to others attentively, every time. When a task is presented to you, and there is a peer or mentor ready to assist, try keeping a balance between learning on your own and having someone else fill in the gaps you haven’t learned.
Probably the single biggest thing would be: try to do it yourself before asking questions, but don’t struggle for too long without help. “Too long” is very subjective and can be anywhere from 15 mins to a day, and really depends on what you’re working on.
Imagine you are assigned a task that involved researching and developing a solution for a client who was quoted for four hours. About forty minutes into the task, you find you have not even remotely grasped the issue that needs to be solved. At that point, it’s worth asking for help due to the time-sensitivity of the assigned task.
+1 to asking lots of questions. When you’re a junior (or when you first start a project), you can ask a lot of questions without any judgement on you. The longer you wait, the worse it becomes that you didn’t ask earlier.
— dion (from Slack)
When asking for help, go over your analysis of the problem and the steps you attempted while trying to solve it. Recounting your steps will help set the context to your peer who may be able to provide you with a more direct set of steps towards a solution, or you may even have a eureka moment when going over your analysis. We call it “rubber duck debugging.” 🍍
Be humble with your peers
Be prepared for criticism and accept it with dignity because no job is ever 100% done as a developer to absolute perfection.
Accepting criticism with dignity is particularly helpful when receiving feedback from a code review. Even when someone may seem underqualified to give opinions, set aside all cognitive biases. To simultaneously combat imposter syndrome and tense confrontations, know that no one can know everything. There will always be things you know that your peers do not know, and vice-versa.
It’s always a good idea to make healthy life choices to help reduce stress or apprehensive behaviors. Take short, frequent breaks throughout the day, and practice excellent sleep hygiene.
Be curious
Don’t be afraid to point out things that concern you. Any good team would value what their newest member could have observed that has a possibility of improving their workflow, tools, or attitudes. There is always something a seasoned employee would not be able to notice after all the time they spent developing tunnel vision. That is not to say all workflows are broken or embody cargo cult, but almost everything can be improved with the help of outside perspectives.
In more ways that can be expressed in this guide: the student becomes the teacher. Be sure to stay cool and humble at all times. Productivity soars when there are no inhibitions in yourself and all those around you.
Stay organized
Repetitive or complicated tasks can easily overwhelm someone’s short-term memory. I certainly face this issue every day. Try to keep notes or to-do lists either on physical paper or a virtual notepad, sort them by priority, and only focus on one task at a time. If something comes up, but is not immediately important, write it down and create a backlog that you can re-prioritize at your earliest convenience.
Read source code
As much as we all try writing good documentation, sometimes the documentation for open-source modules that your project consumes don’t make the most sense, and you need to look further into its source. Whether that is a result of high expectations from the module creator that lead to ineffective docs, or the consuming developer’s general lack of experience, reading the source code is vital.
During these moments of uncertainty, it should take no more than a few minutes to dive right into the source and see how those methods work. Reading and documenting source code is a vital skill that will carry developers throughout their careers.
Be a good open source citizen
Not limited to open source projects; think about your team, or ‘inner source.’ When consuming or building modules from public or internal sources, there are tried and true ways to improve code quality:
- If you used a tool or module that had incomplete docs, contribute back!
- Leave code better than you found it. Refactor methods for better human understanding, or add comments for code that is unavoidably nebulous
- Write self-documented code; for example, here is a guide on self-documenting JavaScript
- On forums such as Stack Overflow, upvote helpful responses or add comments if your situation differs, even slightly, as it could help someone else
If you have the luxury of time to contribute in any way, please do. Otherwise, when consuming help and other content, be sure to consume responsibly for your own sake:
Stack Overflow has lots of right answers, but also lots of wrong answers, lots of answers that are right for use cases that seem like yours but aren’t, and lots of answers which are close to right for you but which you need to know how to adapt or integrate correctly.
— jkaplowitz (from Slack)
Balance self-study and personal fulfillment
This is the part where balancing work and life comes into question. Do you consider development to be a job, a hobby, or a mixture of both? Any option is valid, and though writing code and designing during personal time will give you an edge in knowledge capital, it should not be considered obligatory if you have a reserved expectation of success. Moderate your self-study time as needed; know your priorities.
Juniors commonly benefit more from the time they put into self-study, attending local meetups, attending hackathons, and engaging in online communities. Meeting others and challenging oneself yields indispensable tools: a stronger network of people, a set of employable skills, and a more positive team-building demeanor.
Most importantly, look for opportunities to improve yourself while on the job. Your employer will benefit from the efficiencies and insights gained from experimentation, all while you’re being paid. It’s a win-win.
Try, and your wings will find you
Being a ‘successful’ junior could mean many different things depending on a person’s goals. It could mean becoming an intermediate or senior developer, finding the right tools or programming language to build a dream project, developing the right soft skills to get into leadership roles, and much more.
If you were in a junior role recently, what did you do to help grow your career? If you had some experience as a mentor, what advice would you offer junior developers today? Conversations like these and many more are happening all the time on TechMasters.chat. Join today!
