My first 100 days as a software developer — what I have learned
104 days ago I joined slid as a software developer. This was my first job as a self taught developer yet to graduate from college and as you can imagine, it hasn’t entirely been a walk in the park.
Incase you were wondering, Slid is a smart video note-taking tool for online learners that makes it easy to takes notes from video lectures using screen shots.
There have been some really exciting and ironic moments, like when I made my first pull request but then it turned out to contain a bug — luckily it was caught and fixed before it got pushed to production.
There have also been times I have felt really confident about myself but also times I have felt like an imposter on the job.
In this article, I will talk about a few things I have learned during my first 100 days. I hope this might help anyone who is just starting out with their software development career.
1. Believe in yourself
When I completed one of my very first mini-projects at slid, it turned out it needed a bit of an enhancement before it could be deployed to production. The person in charge of quality assurance pointed out the problem and asked me to make some changes so naturally, I jumped right into it.
I was not sure how I would make it work and I did try everything — or atleast I thought so, but still come up short. I told one of my co-workers, who also happens to be my mentor that I thought I could not solve it. He replied that “You are the only one in the whole company who thinks you cannot solve it.” After this interaction, I went ahead and solved the problem within the next 15 minutes. I learned that if there was going to be someone in the room doubting your abilities, that person better not be you. When a company hires you, it is because they believe you are good enough to do the job — so do it with confidence.
I learned that if there was going to be someone in the room doubting your abilities, that person better not be you.
2. Be patient
It is really amazing that software ever works especially as it scales in size. There are like a million ways things could go wrong, and only one or two ways they could go right. So naturally, all software has issues that need to be fixed.
During my early days, my first instinct was to solve every problem the moment it was discovered. However, it turns out, there are more problems than you can solve in a lifetime. In a startup, the priority is to keep the product working and to test new hypotheses about the users and the market. If a bug or an issue does not bankrupt the company, it can always be solved later.
3. What is a startup
“A startup is a company that is confused about: What its product is. Who its customers are. How to make money.” ~ Dave McClure, 500 Startups.
Before I joined slid, I was a heavy user myself. So when I thought of users, I thought of myself, and when I thought of slid, I thought of the note-taking app I used to take my notes for my university online courses.
So, I was very surprised to learn that slid’s largest user demographic are retired middle-aged housewives who have had all their children finish college and are now engaging in lifelong education from videos on the internet. Because of this, part of our goal is to design an intuitive product that middle-aged none tech-savy people can use with ease. The university students of which I was a part only used slid during the semester and were not really our main customers. What surprised me even more, was that our primary position as far as what our product is, is that we do not know what our product is. Part of our job is to study user behavior and find out what our product is 😂. This one blew my mind.
…our primary position as far as what our product is, is that we did not know what our product is.
4. Ask for help
Chances are that the people already working at the company know more about the code base than you do. It is also very likely that they have already faced whatever problem it is that you are facing on your project. You will save yourself and the team a lot of time if you ask them for help about what you don't understand about the code instead of making assumptions.
It is also important to play to your strength. If someone is much better at say CSS than you are, ask them for some assistance on your project. It will help your working relationship with this person, and it will also help you improve this part of your skill set. You will thank me later xD.
5. Respect Others
This one happens to be our core value at slid. Respecting others is the only way to work with them. This is our primary position when interacting with other people in and outside the company.
We treat everyone as an adult, we respect everyone’s background and we respect everyone’s work. If you have an opinion or suggestion, you have to think of the most respectful and professional way to point it out.
This approach will never fail you in your professional career.
6. Find out what your role is
On your first job, it might be difficult to know or understand what your job is. This confusion is more likely in a startup environment where employees wear multiple hats to get the project moving.
I would advise you to help out as much as you can with the projects and problems that need solving at the company — since developers are actually engineers and engineers are paid to provide solutions. However, you should know what your role is, or at least what you want it to be. Do you want to work on the UI as a UI engineer or work on the functionality, performance, and efficiency as a front-end engineer? Knowing this will help you understand how best you can contribute to the team and it will also provide you with a sense of direction for your career growth progression.
It also means you won't get stuck if someone asked you to tell them what your job is at the company.
7. Think about other developers when you write code
“Programs must be written for people to read, and only incidentally for machines to execute.” — Harold Abelson
When you write code, make sure it is easy for other people on the team to understand it. Leave comments where you can and try not to use overly complicated patterns. You will spend the majority of your time debugging code written by yourself or other members- so it does not help if a lot of that time is spent just to understand what the code is doing.
There is definitely still a lot more to learn. These are just a few things I thought I should share about my working experience so far.
If you enjoyed this please feel free leave a comment or a clap. Cheers!!!
