Note-to-self as a Junior Developer
Tags: beginners, webdev, codenewbie, career
Published: 2020-05-28 05:42:31

I recently marked my half-year point as a Frontend Developer at [Commerce.js](https://commercejs.com/). It sure is a strange milestone as it definitely felt like its been longer than the 6-month whirlwind period. It's unquestionable that I have soaked up more new knowledge in the last half a year than I have in my last few professional years. Not only do I get to work on a kickass tool and platform in the thriving eComm space, I get to do that with some of the brightest and most standout people who continually encourage and motivate me to be on my A-game. After all, aren't we all in this industry to be lifelong learners?

While working and learning in the last several months, I have built up a habit of consolidating notes and key reminders to myself working as a junior in the ever-changing tech industry.

Alas, below are some notes I hope to continue to drill in my head and hope that they might help others starting out in the industry as well! 

### 1. Don't be afraid of sounding like a total newb.

![You must be new here GIF](https://media.giphy.com/media/11pQizRLu1JP0c/giphy.gif)

We all started somewhere, even those senior 10x engineers who boggle your mind. You might feel like you're lost in the jungle of programming jargons, those technical terms that sound like they come with superpowers, and those metaphors that have become synonymous in all your meetings (I'm looking at you, *low-hanging fruit*). You'll catch on in time and eventually that language will become second-natured.

### 2. Ask questions, LOTS OF THEM.
When your colleagues tell you to always reach out when you're blocked or have any questions, THEY MEAN IT! Mind you, one of the most important skills to have as a programmer is problem-solving. Always, always try your very best with your current abilities and knowledge to solve a problem at hand. Break down the issue and try to tackle it in bite sizes, and make sure to note down the methods you've tried. Once you feel like you have exhausted your efforts after getting to page 3 of Google search results, then reach out to your colleagues and be mindful of their time. With clear and concise context, explain your blocker and if possible make sure they can reproduce the issue. The most effective times I've been able to tackle an issue with a teammate was through pair programming.

### 3. Adding to the above point, note down every issue you come across and store them away as assets of knowledge.

![Bugs GIF](https://media.giphy.com/media/oSUtmrhRz5te0/giphy.gif)

What is the difference between a senior engineer and a junior? The senior engineer has been exposed to and has solved thousands more bugs than a junior has. **Bugs** are good, **bugs** are your friends. They allow you to uncover the inner workings of a program. They allow you to do extensive research and try different solutions. They allow you to understand the architecture of your code and project. Note down issues you come across, the solutions you've tried and the solutions that worked. Keep these notes as they eventually develop into a track record of what you have learned.


### 4. Get close and comfortable with version control.
I really can't stress this enough. You simply just cannot build software with a team of people without a version control system (Git). I have compiled together a list of Git commands cheatsheet that I will put up in another post. A simple search on Google will result in the most commonly used list of Git commands. There are definitely going to be a ton of merge conflicts, rebase nightmares, and getting stuck in the world of VIM, for you to start getting comfortable.

### 5. Try not to code blindly.

![Squinting GIF](https://media.giphy.com/media/j1hBoSUlOD9fMGKw5n/giphy.gif)
Working in software in an agile team, you may feel as though cycle work moves fast. There's a lot of implementation and a lot of trying to code up and push out a feature. As a junior, you may feel as though you're constantly playing catch up with time. Trying to contribute to cycle work while learning all at the same time. This is where theoretical concepts and applied learning cross over. Code is almost always recycled and refactored. Open-sourced libraries, modules and plugins are largely used in modern day applications. Those are all essentially reusing code. Try to understand, at least at a high-level of all the moving parts. When you're reusing resolved logged issues that have proved to work, be sure to try to dissect and understand the code. Reference documentations of the tools that you're using as much as possible and all the while read up on programming concepts.

### 6. Feeling like new knowledge is not easily retained.
As with anything new, it takes time before a habit is built, before information becomes knowledge. It may take 10 times for you to get comfortable with a task or it might take 50 times. What seems to come easy to others might not necessarily come easy to you. But try to remember that is not an implication that it won't all eventually click. 

### 7. Your newness is one of the most important values.
Being new is what's driving your curiosity, your willpower, your ambitions, your hunger. So never ever lose those. When you're starting out, you may feel as though it is a huge hurdle to overcome, but you see, it is not something you overcome. It is a long-haul journey where you're constantly in a space where you might not know enough. This is always going to the perfect space to be in because it is the very indication that you're never going to stop learning.

---

And there you have it, there are definitely more points than the boiled down list above which I will continue to add to! All the points are simply just my 2-cents and what I've learned thus far. Would love to hear how all your experiences have been when you started out, or what advice you would give your junior-self?