3 myths that are stopping you from becoming a great software engineer

I have interviewed quite a few software engineers in the past few years. I have observed a few habits again and again that I almost feel like it’s becoming a common thing among software engineer 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.

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

A software engineer should be able to analyze 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 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 please make sure you write test cases for high-level behavior 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 behavior of the product, you would know it before your customer tells you about it.

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 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 engineer, 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 coding 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, is 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 good to anyone.

Are there software engineering habits that you follow on a daily basis that you make the expert in your team/community? Please share in the comments.