5 Mistakes To Avoid As A Junior Software Engineer
You have survived the learning how to “code stage”, the “job seeking stage”, the horrible interviews and finally time to prove yourself.
Wait! how do you survive being a junior engineer and what mistakes to avoid?
1. Do Not Be Afraid To Ask Questions
Most junior engineers are afraid to ask questions, especially if they are new to the job.
We have all done this in our careers, you are the new kid, afraid of being labelled as “unqualified for the role” .
It’s worse if you are on probation as you don’t want to ruin your chance. Reality is everyone is open to help and answer your questions.
2. Poor Time Management
Don’t get me wrong I don’t mean that as a junior software engineer you are guilty for staring at the computer for hours, no I don’t mean that.
I mean spending hours on debugging minor UI issues than focusing on getting a function(s) to work.
We tend to avoid challenging tasks and resort to solving the easier ones, this is human nature but should not be software engineering nature.
The challenging tasks are what gets the program to work.
Say you struggle with getting your program to work then sleep on it, you might have luck the next day.
If you haven’t found the solution yet then its time to ask for help.
3. Not Understanding What is Expected Of You
This is quite simple, what is your job description? you should know this before you even apply or take on the job.
“Am I expected to specialize in something?”, “Should I know the algorithms?”, “how effective should I be in utilizing certain tools”.
Always know what is expected of you even before you join the company.
Ask what will be your day to day duties during the interview it’s a two way process of knowing each other.
4. Poor Documentation
I’m referring to code documentation such as your comments, these are helpful to you and others that might want to read your code.
But vague and unclear comments are a big mistake beginners practice,such as #TODO or #Important.
The #Important comment was particularly interesting to me.
Every time I see it, I analysed the code which worked fine, so what was so important?
I once asked the owner of the comment and code, what was so important in that code, he had forgotten.
Avoid vague documentation by all means.
5. Delaying Refactoring Code
Refactoring your code makes it cleaner and readable.
After a code review and you receive some suggestions on refactoring your code, your first thought will be, I’ll do it tomorrow, and when tomorrow arrives then it’s Monday.
You procrastinate until everything builds up and you will feel overwhelmed.
Now you still have to refactor your code, which has pilled up.
