It has been almost one year since I joined the company as a Software Engineer after five years of being a tech founder of my startup.
It was a big life decision, and it was hard. Looking back, I do not regret deciding.
Working as a Software Engineer has been very humbling for me and I believe I have grown a lot professionally.
Life as a Founder
I am not new to taking non-orthodox decisions. Pursuing finance and commerce instead of engineering, never going to college, and dropping further studies. I made each decision to grab big once in lifetime opportunities, and I am happy that I took them.
I started my company when I should go to college. I was naïve, but I knew the best way I can learn is by doing.
Being a founder is the most fulfilling experience you will ever have. You have the complete freedom to do anything. I saw exponential growth in myself. It would have taken me many, many years to learn what I learnt in four years.
I made several products, built a team, and even tried fundraising. Failed, and tried again until I found success.
Guess what, I never found success. :) But, that didn’t stop me.
Why did I take a Software Engineer position?
In the search for success, I decided I need to go back to basics and learn from the people who have done it before me. I wanted to know where I was wrong, and what can I could improve.
It was extremely hard for me to accept the change I was going through. It was affecting me both financially and mentally.
Having learnt from my startup and getting exposure to a ton of technologies gave me an edge and I knew I can easily find a job in my city. But, I wanted a challenge, so I only looked for remote opportunities.
A unique attribute of remote jobs is that companies that hire remote engineers have very low acceptance criteria and you have to be the best in the world to get hired.
After a few months of searching, I got hired as a Software Engineer at Awellhealth.
A new perspective
Within a few days of working as a software engineer, I realised there is still so much to learn.
I cannot explain it in a paragraph, so I am breaking it down.
Constructive Feedback
Devs discussing together. (Not a picture from Awellhealth)
One drawback of being in the highest position in the company is that you rarely receive feedback.
This was a big change for me. The company I joined believes in giving constructive feedback and I started receiving feedback from the first week.
I welcomed whatever feedback I received and improved myself. Within a few months, I could see the change in myself and how much I have improved.
I learnt how to give feedback and question the status quo. I believe this is very important for a startup to grow faster.
Improve 1% every day as a programmer
Constructive feedback is one of the best reminders you can use to grow yourself by 1% every day.
Here are some mistakes you should avoid doing.
Do not make grammar mistakes in your English — Always reread your comments, variable names, messages you send to your coworkers, etc.
Do not explain WHAT or HOW your code does/works in comments — Comments should explain the WHY aspect of your code.
Do not assume the other person has all the information they need to help you — Make sure you provide all the contextual information to your coworker when you need help or want to explain what you are working on. When you need help, always start with facts.
Do not make assumptions when you are debugging code — This can hurt your and your coworker’s time if they are helping you. Always test your assumptions.
Do not jump to solutions — Do you understand the problem clearly? A good way to test that is to explain it to yourself. Can you do that? Most of the time, if you cannot explain the problem, you do not understand the problem.
Not reading programming books — There is a reason programming books exist every after decades of publishing. It is because these books contain a wealth of timeless knowledge. You will truly understand why different programming principles exist and how to use them correctly.
Not talking to myself — As a programmer, it is important to develop the ability to talk to yourself and question yourself. This can help you a long way before you reach out for help because if you are like me, you would have observed that your problems solve by themselves when you explain them to someone. All they needed to do was listen. :)
Not understanding the consequences of the change in the code — Always make sure you know every consequence of the change you are making. If you don’t, you will see customers complaining and you will not understand why.
Forgetting the conventions set by your company — Usually, your company will set some coding guidelines for the codebase you are working on. Create a checklist of such guidelines and make sure you follow them when you write and review your code.
Not reviewing my code — When you submit your work to be merged (PR), read every line of change you made and try to look at them with fresh eyes. This will help you fix silly mistakes in the code and also allow you to make sure you are following the guidelines set by your company.
Not reviewing my code after I fix review comments in PR — I found that most of the mistakes I make are when I submit my changes after solving a review comment. This happens because I would not read my PR again. Please, please read it again.
That’s it for now. Each one of these mistakes is a topic of its own and I will explain them another day. :D
