3 Myths that are Stopping You from Becoming a Great Software Engineer

I have interviewed quite a few software engineers in the past years. I have observed some sets of similar habits in most of them again and again that I almost feel like it has become a common thing among software engineers these days. I am calling out few in this blog which I think, we as engineers, should see through and cultivate a healthy engineering ecosystem.

Secrets for Becoming a Great Software Engineer

I am sharing some common thinking practices of some software engineers and sharing my take and advices on the same as well, which might make you a better software engineer.

1. Big-O notations is theory and not applicable at what I do day to day

A software engineer should be able to analyse time and space complexity of code they write in terms of the size of the input. If you don't know this, you don't know how to improve it. This is not a theory that you studied in school, this is the basic tool for an engineer to understand how performant their code is. Next time, before you write / commit code, take a pause and think about this. If you already do this, make sure you encourage your team to do it as well.

2. We do not have time to write automated test cases and it helps us to ship faster

In the startup / building MVP world, I agree the value of unit tests can be argued to some extent, but please make sure you write test cases for high level behaviour of your feature (BDD). Doing this:

2.1 Helps you ship and make changes in the future to your product with confidence. If someone makes a change that accidentally alters the behaviour of the product, you would know it before your customer tells you about it and it will make you a better software engineer.

2.2 Reduce engineering effort to release a feature. Imagine you make a change, and have to execute all different combinations manually again and again. Ugh! The best software engineers are the ones that are often lazy and find ways to automate their tasks.

2.3 Helps you onboard new team members easily. Test cases serve as a way to document the feature. When a new team member joins the team, these test cases serve as a reference to understand the feature / product quickly.

As an experienced software engineer or as a fresher in the software engineering field, it is your responsibility to educate your team. Next time you are committing code, make sure you wrote test cases for your feature. Put that extra effort initially. The initial cost might be high but once you get into the habit, trust me, you will never go back to writing codes with writing test cases first.

Remember MVP is not about skipping best engineering practices so you can build a lot of features but rather build limited features but with care so your customer loves it.

3. I want to change my technology stack because I want to learn new things

I get this. As humans, we always want to feel challenged and learn new things. There is nothing wrong it. But take time to really really know it. Most of the time, what I see - people end up what I call is feature developer.

They know how to get things done but they lack the depth and deeper understanding of the language and platform, things - like memory management, concurrency issues, or really leveraging the best stack has to offer to solve problems. I have seen seasons Javascript engineer who still can't explain 'closure'. This is not cool.

Pick a stack. Become an expert. Put in the hard work. Write blogs to share your learnings. Don't change your stack constantly - it does not do good to anyone.

What’s the biggest thing you’re struggling with right now that we as a technology consulting company can help you with? Feel free to reach out to us at info@jalantechnologies.com. We hope our assistance will help!