My first 3 months as an entry-level junior software engineer
Today happens to be a little bit more than 3 months since I was hired as a junior software engineer at one of the most prestigious custom software companies in my town.
Those three months were super intense and I learned a ton of new things.
In this blog post, I am sharing some of my insights that might be interesting for other entry-level juniors or self-taught programmers, who are just about to start their new career in IT.
1. Start your code from the functionality and only then dress it with style
Since I am stronger on the visual side of development (CSS, to be precise), I instinctively started doing my tasks from the visual approach.
First, I made the layouts, then worked on styling everything, and… after I jumped on the actual functionality, I realized that I might have to re-do all the styling, as the components were modified, moved away or completely gone.
Make your code work, even if it looks ugly. And when it works, style it. It saves time.
2. Start coding only after you fully understand the problem and business requirements
…and even if you think you understand, constantly sync up and double-check with your colleagues.
There are few worse things than to be working on a completely different feature than the one you were expected to deliver.
It is not that you will have to re-do it (probably after work), but you would feel really bad.
The best way to check if you are doing what you are supposed to be doing is to split the task into a few smaller ones and sync up with your team or mentor after you are done with this little feature. And then move forward.
You will also get the feeling of completion (more often), which is motivating and rewarding.
3. Ask more questions and do that more often
During my job interview, I asked the squad lead, what makes the juniors fail in their trial period (usually the first three months).
He said that juniors normally want to be left alone. But for them (and for the whole team), it is better if they ask many questions and stay active.
I thought this will not happen to me, ever, this wish to be left alone, and I will be asking questions, not ashamed of things I do not know.
Looking backwards, I am sure I could have been asking more often. Only now, three months later, I understand the importance of asking, checking, syncing up, or double-checking.
It saves you and your team lots of time. Also, it will enable you to work faster and gather more experience in less time.
The other thing about asking questions instead of always trying to google out stuff on your own is that in many cases, especially if you are working on a large project with a huge team, is that — you cannot google it out.
It is simply impossible.
The complexity of the project, the libraries the team is using, perhaps some unconventional decisions could make the project so unique, it is a hundred times faster to ping your colleague than to drown in StackOverflow.
So, if you think you are already asking questions, ask three times more often, and you will get better results.
4. Keep studying. You haven’t reached your goal yet
The goal is not to be hired. The goal is to become a valuable team member. This does not happen on your first day at work, so keep studying as if you were before you got the job.
Identify the parts you suck at and make a plan on how to improve them.
This could be an extra course, Youtube tutorials, or simply a late-night coding session on CodePen.
My favorite courses are from www.scrimba.com, where I have currently enrolled in JS Bootcamp to deepen my JavaScript skills.
5. The QA engineers know it all
I do not know why and how, but I got this weird little idea that if I am a developer, I should address all my questions to other developers.
I remember myself staying up late in the office, trying to figure out if I haven’t broken anything on the project.
Then it suddenly struck me — QA will test it, so perhaps QA could give me a hand in explaining to me where the parts of my code could be used?
The parts I had no idea existed!
A junior QA engineer, sitting right next to me, was super nice to explain to me not only how the system works, but letting me see the system and the whole project from the user’s perspective.
This is a truly valuable approach since it allows me to better understand the tasks, imagine how the actual humans, non-developers, would use the system, and even sometimes have better ideas on how to make the system more comfortable to use.
QAs to me look like they are the gatekeepers of the castle, holding all the keys to each and every door, aware of many tiny little passages and secret corridors.
Now I contact QAs more often, I sync with them on the tasks and they help me with the additional requirements.
6. Own your learning process
Normally, in all well-established IT companies, you will be assigned a mentor. His job is to onboard you, and be the go-to person when you are stuck or you do not know where the business info lies, or where to look for the designs.
But hey, you do not have to rely only on him/her.
Find more people you can ask for help
Find about your colleagues’ best strengths.
Somebody is passionate about the Typescript? Ask him or her TS related questions.
Someone has solved a similar task before you? Go to him with your next question.
Examine PR’s of your colleagues
One of the best tips I received from my colleague, is to examine the PR’s of other team members.
Especially those PR’s, that you think you could have done by yourself, the ones you understand (more or less), or at least have an idea how you would have done it.
By examining them, you will see some good code written by more advanced developers, and this is how you could gather some more experience under your belt.
7. Master your IDE
Usually, IDE is something personal and companies do not have strict rules on which one to use.
Which is nice for more advanced developers, but could be a pain in the ass for the entry-level juniors.
IDE choices are very opinionated and this is the domain where developers lose their cool rational minds and get into the so-called IDE wars, resembling a lot of the religious wars between the Catholics and the Protestants.
Fires are lit, the armor is on. I have heard things like “Search does not work on VS Code” or “No senior developer uses IntelliJ”.
:)
Everyone had an opinion about the IDE I should use.
But let’s cool down and think about the real features/reasons you should take into account when choosing your IDE.
- you have to like it and feel comfy using it (a pure matter of taste).
- your IDE has to support the requirements for the project (linting/code formatting).
That is all.
Don’t let anyone fuck your brains about the IDE.
Pick the one which works best for you, and master it.
Learn the shortcuts
If you notice you are doing something which eventually starts to annoy you (like scrolling to the last edited place), this is a good sign that perhaps there were tons of programmers before you, who were experiencing the same awful feeling of having to scroll, and IDE developers fixed it.
So there must be a shortcut.
Don’t be lazy, find it and start using it right away.
Have you recently started your new career as a developer? Or are you an experienced engineer and you have a thing or two to share with juniors? Leave your thoughts in the comments below.
