From Beginner to junior Engineer
How my programming skills have changed since starting my career
From beginner to junior Engineer, It is a weird title I know. This article is the first in a series on learning about algorithms, data structures, productivity and programming languages.
Well, who am I?
I am a junior programmer working with a startup here in India. I have been trying to get my head around programming for around eight years now. But being in a startup, I have quickly realized how basic knowledge alone does not create great solutions. Initially, when learning how to program. I did not have to consider whether other people could read my code or even think about how optimized my solution was. If the code worked, don’t mess with it. That was my policy. Here are some of what I used to do and what changes I’ve made
Always commit to master like a boss 😎
To me, git was just a way of uploading my code to Github. So I never actually created an actual workflow around it. Whatever changes I made to the code, the only steps to commit it always followed these simple commands.
git add .
git commit -am "Made some changes"
git push origin master I know git master will be like, what is this fool doing. In my defense, at that time it was all I needed. I wasn’t doing open-source or sharing code with others. If you have never done this, then wow!
Ok, so what changes did I make?
- Whenever I plan to test something out or an experiment on one of my projects, I create a branch named “EXP-name-of-the-branch”. If I planned to add a feature, then the name would be “FT-name-of-branch”. This naming scheme helps me keep track of branches and even understand what each branch relates to quickly. Without this scheme, I would have just randomly named each branch. That later leads to hell as I try to find something specific.
- Always add a commit message. I do the same thing as with the branch naming scheme. WIP: <msg> for the work done till the commit point on that code. Ft: <msg> to indicate a completed feature. Bug: <msg> to show bug fixes. When merging the final code, I squash all the WIP and feature commit into one and always leave the bug commits as such. It helps me later find out where bug fixes are. Also, never do bug fixes on feature branches. Finally, once a feature is rolled out and not in active development then the feature branch is deleted.
- Don’t just git add everything. Always review your code and add only the correct files to the commit.
If the above seems too hard, keep two branches for your projects like a master and develop/staging. Even a little bit of organization goes a long way.
Write code like there is no tomorrow. (YOLO) 😎
When I made my first merge request to the project, the review I got was to refactor the code. Change the variable styling order your functions better. I was like! huh! what? 😶 .
Whenever I needed to write a function to the code, I would add it where ever I could find the space for it. Sometimes, above the function that called it, sometimes below or anywhere that I deemed worthy in the codebase (i know ). That worked for me “ctrl + click” always took me the function so, I never really worried about it. When you write code, you are writing a novel. You can either write it like one of those Goosebumps books where the reader chooses the next page to switch to from the bottom of the current page. You could also do it as any good novel would put it in a readable order, chapter by chapter in the exact order. Prefer the chapter by chapter order, This will help you and your team when reading the code. They won’t lose too much context as they read through the codebase. Later, when you are trying to figure out what you wrote. It makes so much more sense when the code is organized. Granted the goosebumps approach is good, but not everyone likes it. TLDR: always write code in a structured format.
When you see a bug apply a bandaid 🤕
So, going to bug fixes. Whenever I got an exception, the first thing to do would be to add a condition that said if null then return false or exit. This is what I refer to as a bandaid. Bandaids are a simple solution and do not take a lot of work to add. Most importantly, it solves the problem but, what if there were broken bones beneath. The bandaid might have stopped the bleeding but, the bones remain broken. (I know. not a good example but, it does make a lot of sense)
When you encounter any bug stop applying an if condition first traces back a little and find out what lead to the exception and which functions were responsible what happens if you leave this step out. I have written this little library function that reads the header of a file then returns a specific flag. Unknown to me the data bytes sent to my function were null. I added a simple fix returning zero in such a case but, the function call on the other end did a whole bunch of processing if the value was zero. Once the bug fix went online, we started getting weird errors and had to roll back the release. About an hour’s worth of debugging later found the problem. If I had just done it before, it could be solved much sooner. Situations like this always happen. The fix may work but at the same time creates unintended side effects down the line. TLDR: Never write the bug fix without determining the exact cause for the exception.
If If If If… 💭
If you end up adding a lot of if or conditionals to your program, you might want to recheck your logic a bit. Maybe some or all of these conditions could have been merged into a couple of base cases and avoid adding conditions that you know will never happen. I used to do this (basically, Started doing this when having big projects, just got scared of the idea of it crashing). Having too many conditionals is not good. Try to keep as much code out of a conditional this will make it easier to read code.
Write in your own personality 😋
Let’s say you are working with a previously existing project and start writing code in snake cases. Without a worry in the world, you commit the code. Later the senior pull you on to a call and starts explaining in detail how to format code. (not that this happened before). Yeah, we all have our personalities tabs, spaces, vim, emacs, { after the line or at the end of the line. The project and your team already have a defined style that works for everyone. Never write code that breaks it. Granted, renaming a variable is very easy. When people start committing individual style to the code, it becomes harder to navigate it. Always follow a common set of standards your team agrees on. Read the code or reach out to understand the coding standards and practices.
Write complicated code like a boss 💪🏼
Sometimes that imposter syndrome is in overdrive. We read or see some code that does something alien-like and tries to create something exactly like that. The only problem is we end up adding chaos to a simple problem. Trust me being a junior engineer everyone, has a bit of imposter syndrome. Simple should be handled as such. Yes, you can make it more complicated and then get your senior to reject the merge request, just don’t there is no reason to do so. Code is written to solve a problem, do not make it the problem.
I only believe in code 🧑💻
We all tend to jump on the computer first without even giving a thought to the problem. Don’t go around to implementing the solution as soon as you get a problem. Try to see how you could approach it even if the problem is simple. Five minutes is enough to think about the approach you want to implement, the data structure you want to use, and most importantly, is the solution right. I have once spent hours implementing this crazy algorithm to create a set of cache entries to get faster results. The problem was to compute some of the precache. It took more time than actually generating the output. The simplest solution I had overlooked was that I did not need to do that each time. I could compute the precache at build time and ship it to the user for just an additional cost of 5kb to the app. and loading that took less than 3ms. I spend the whole day trying out fast algorithms to create the entries on the user side and ignore other possible solutions. (where data structure played a role in this was the file was a trie ) Think twice before you code always.
One year into being a junior engineer, I am still not done learning. There is a lot I want to talk about yet still. This is where I plan to take this series. I plan to move up in my career and get better at thinking and implementing solutions. I plan to release 3 blog posts a month. if you want to follow my journey to being a better engineer follow me here on medium.
