We all remember our first programming job and the challenges that came with it. Here is some helpful advice for junior programmers to heed to help advance their careers.
Do remember your first day of a programming job? Maybe it is your first job or 5th job. You will always remember the problems that you faced during your first day or even the first week.
You don’t know where your computer is. You don’t know who your immediate boss is yet because a higher-level boss or someone from HR has hired you before they send you to the appropriate department.
On the first day, I bet you were a little worried. Your tasks were not clear. You have to understand the codebase. There could be little documentation or no documentation available for you to use.
Whatever was the condition, I believe you have passed through the initial bumps in three or four weeks. Now you know who is your immediate boss, where your computer is, what technologies are in use, what the state of documentation is, and you begin to feel comfortable with the codebase.
Now starts the honeymoon period. Your boss will give you tasks — small tasks that are easier for you. This is your period where you start learning about your organization.
Sometimes, your boss will give you difficult tasks and for that you need help. In many organizations, your boss will assign you a mentor. If you have ever been assigned as a mentor, then you know that your mentor does not have time to spend with you. Your boss does not have time, and it looks like everyone on your team is very busy.
I don’t consider myself lucky, as I was given no mentor at all. I had to figure out most of the things myself. Let me admit that I have pulled my hair out at the beginning of my job. Feeling disgusted and under stress, I thought that I was in the wrong place:).
Anyways, during first 2 years, you are learning new things, like that awesome framework that everybody talks about. You are working on that framework and you have something to brag about with your friends.
After 1-2 years you start to realize that you know enough about the place. Enough about the technology that you are currently working on. You want to know where you are going with all this.
Up to now, you have been given small tasks that any new hire can do. Yes, it is true. Believe me or not, just go and just look at all the code you have written when you started.
Can you do the similar tasks that were given to you 1 or 2 years ago, forever?
What if you want to move up the ladder? You want to get promoted and become a senior architect if you choose to remain on the technology side of a business. Or perhaps you want to be Vice President or CEO if you want to move up in management roles. In both cases, you don’t want to be passed over.
What if there is a downsizing and you are first in line to be let go. Why? Because you are replaceable by a cheaper option or any existing developer can do your work. Put it simply and harshly, you are replaceable.
What if you want to move to another organization — your dream organization. That organization has the higher salary or it is another geographical location where you want to live. Your dream organization is more high-tech and you love that. But you cannot move there with a limited or specific skillset.
So what’s the answer to my question — now what? Now you have to prove your existence.
When you do this, you don’t have to worry about downsizing or letting go and you will be promoted automatically.
Well, there are roadblocks and you have to take care of them. The first roadblock for a junior developer is that nobody in the team has time.
Your mentors don’t have time. Your bosses and senior colleagues don’t have time. Sometimes you are also busy with a project and you don’t have time for your personal development.
Your seniors and mentors don’t have time because they are busy in doing ‘the important’ work. But they have time to tell you the tales of their success. Or they have time to show off. Don’t they?
They preach you why object-oriented design is important like a religion. But they don’t have time to sit with you for an hour or two and teach you a couple of things.
Secondly, you are shy and you don’t want to disturb anybody. This comment from a junior developer summarizes my point:
The solution is that you will have to learn the art of questioning and its approach.
Here is a small tip: don’t be shy. You have to gather the courage and asked the question. Don’t ask questions too often. Set a time with your seniors and mentors. Set a specific time to discuss a disturbing problem. A disturbing problem is something that is bothering you and you have done everything that you know but you are unable to solve it.
This will open up the gates of learning and believe me you will learn more quickly from mentors than learning yourself.
But he has taught all of his junior this stuff within 2 weeks. His junior started development on projects within 2 weeks instead of 6 months. Isn’t that fast?
See! You can collapse the timeline by learning from others. Their experience from real-life projects and their mistakes can become the guideline for you. When you learn from real life and real-world projects then you are way ahead of your peers. Here is one real-world software project example.
Once you become the necessity of your organization, then you can carve out time to work on additional skills. These additional skills will set you ahead of all your peers and you can move up the ladder not only in your organization, but also anywhere else in the world.
Don’t become someone who uses other people’s libraries or frameworks and writes only glue code to come up with the solution.
Look, I am not against frameworks or libraries. No, not at all. There are some higher level developers who have worked hard and encapsulated their knowledge in that little framework that you can download and use.
I want you to be like those higher level developers. What you need to do is develop transferable skills, skills through which you can develop your own API. One of those skills is object-oriented design. Another skill is problem-solving and algorithm design.
No matter how many frameworks are invented and die, you possess skills that can be used to create frameworks or understand frameworks faster than anyone else.
