Originally published on https://ali-ilman.com/blog/8-things-i-have-learned-after-2-years-of-work.
It has been two years since I started working as a software engineer. Prior to that, I had been an intern for 3 months at the company I've been working for. There's more to being a software engineer than just writing code and pushing to GitHub repositories.
In this article, I'll be sharing some of the things that have helped me become a better software engineer and a better person, tips that you can apply or serve as a base for you to achieve your goals, and things I only realise after I started working. 🧠
No matter how experienced you are, you will always end up browsing the web looking for a method name. And this is all right! No one knows everything, and no one remembers everything. What's important is that you understand what you're doing with the code. Through this, I realised that googling is a skill.
And yes, using StackOverflow isn't cheating. Don't be like me who thought it's cheating to use StackOverflow. 🤦♂️
There will be methods, classes and libraries you've never used or heard of. Imagine a feature where you can use a library called XYZ to aid the implementation, but you never heard of XYZ before. Start by going through the documentation and playing around with the library. Then, use it to implement the feature.
Is Ruby the main programming language that you use? Are you a React wizard? There are meetups for people who use or are curious about these technologies! You get to meet like-minded people and make new connections, you get to gain knowledge from talks. And if you've something to share, you can always get in touch with the organisers and tell them that you're interested in giving a talk. It's good to give back.
It's easy to feel excited to start working on a feature or a bug fix when it's ready to be implemented. This can be a misconception of what you should be doing as you're eager to get going. Instead, try to understand what needs to be done, and think how this can be implemented in the cleanest way possible.
Keep in mind that it's easy to overthink about keeping the code clean as there are many ways to implement something, so don't waste too much time on this. We could ask our teammates for their opinions, and there are always code reviews.
One of the things I've learned about code reviews is to not approach them aggressively. This can be in your choice of words and / or the intonation of your words. Remember, a code review isn't just for tidying up code. A code review is also a way for you and the author of the code to improve as engineers. Build each other up. 💪
A personal rule of mine is to not use GitHub's Request changes when submitting a review. I feel it can make the person who wrote the code feel less confident or make their suffering of imposter syndrome even worse.
There will be bug fixes, enhancements and features being implemented. Writing a descriptive pull request will give the reviewers the context of the pull request, which can result in effective improvements to the code.
One of the topics I've seen people talk about is whether you should code in your free time.
Can working on side projects in your free time help you become a better engineer? Yup. But should you be doing this? This is for you to decide. Only you know your body well. A good rest is important. And most importantly, don't forget to spend time with your loved ones.
Remember, always stay humble. It's easy to let your knowledge negatively control your behaviour. Use your knowledge to build up fellow engineers. 🙂 I encourage you to check out BuildUpDevs.
I hope this article has given you an idea of how it's like to work in the tech industry. Feel free to ask me questions!
Cheers for reading! 🤓
I share the life of a software engineer on Twitter, you might want to follow me. 😉