Junior Dev to Junior Dev

"You better write your experience down, because you’re not going to be a junior dev for long.”

That was said to me during today’s retro. I have been at this company for six months and it never occurred to me that I won’t always be a junior developer…

During today’s retro, a junior developer brought up that there’s still a concern of getting themselves up to speed with the code base and domain.  The senior developers on the team asked what else they can do for us.  At this point, I realized the senior developers cannot do anything more for us. In fact, I started notice that I didn’t felt as “junior” anymore. Then it occurred to me that a senior developer can only get a junior dev so far, the rest is on the junior developer.  

 Here are some things that helped me get through these passed months.

1)     Don’t be afraid/embarrass of not knowing

The code base that I work in is huge. Working on a large enterprise product with so many moving parts and components is so difficult to grasp at once. What do I learn first? What do I tackle? What is going on?

These are some questions that swarmed in my mind and boggled me down. The weight of these questions started to get at me and made me doubt myself. I felt embarrassed. I felt like I shouldn’t even be working here. I felt like an imposter.

Stop!

I don’t know when I started to change my view on this, but not knowing something is an opportunity for growth that changed my attitude on the unknown. These questions that swarmed in my head are valid because it shows what weaknesses need to be worked on. There are times where I ask simple CS question.

“What does this operator mean?”

 The more questions asked, the more you’ll know.  One thing to be cautious about is interpreting a answer wrong. What I mean by that is in the beginning I used to Google the problem, see an answer on Stack Overflow, and then try to interpret it. It worked in the beginning but in the long run it actually hurt me. I found out that I was making the wrong assumptions when I was ingesting the answer. This behavior was actually a cover up for my embarrassment of not knowing something.  Nowadays, I will search for the answer and then double check with someone else to see if my understanding is correct.

If we want to think about this pragmatically, then think of like this: Not asking only hurts you as a developer and in turn the product.

2)     Write everything down

I keep a small pink journal with me all the time. In it, I have entries about scripts, problems, solution, topics, and books. Even if I don’t ever look at what I wrote again, writing down something validates and engrained physically what I have accomplished. This is especially useful for stand-ups.

3)     Find a mentor

There are plenty of senior developers on the team that I can go to ask questions. Other articles I read only make it seems a mentor is someone who will sit down and teach you about the code base. Unfortunately, sometime senior developers on our team are too busy to actually mentor so I came up a way utilize their time and still get stories done.  I became their rubber duck. The idea is that instead of being taught in lecture style, be a person that bounces ideas off or echo their thinking process.  Some phrases I use are:

“Can it be x?”

“We’re doing this because of…?”

“So we did X because of Y….”

This gives me insight on the reasoning why we’re doing this a certain way. Another benefit is that every wrong suggestion I gave, it informs me to what it isn’t. This will help me debug/use in the future.

4)     Give yourself time to improve

We have something called Research Day which basically allows the developer to research on their own on topics that might be beneficial to the team. Our team is lenient on how we use it. I used to program my own projects during this time. Eventually I started to focus more on our domain. I started to look at stories ahead of time and look at the code base with curious mind.

“How do we call a certain web services?”

I would do some digging on my own. Write down several questions and then relay those questions to a senior developer. Sometime the senior developers aren’t available to answer all my questions, so I would ask for recommendation for a textbook/book. This ensures that I don’t have any down time during research days.

5)     Self-reflect

Those self-improvement blogs can be applied in the workplace. I write down goals that I want to achieve then start forming questions around how I can achieve those goals. I also ask for other people’s opinion on what I can improve on because sometime I cannot see my own flaws. Being aware of one’s flaw and acknowledging them is the first step in improvement.

These are just a few things I have done. Please don’t hesitate to asked questions. Thanks for reading.