7 Biggest coding blunders that every software engineer must avoid

There are a few frequent mistakes that we see all new software engineers make the majority of the time. Many recent grads find it difficult to make the shift. Hopefully, this article will give you some insight into what to look for as a new software engineer.

There are a few frequent mistakes that we see all new software engineers make the majority of the time. Many recent grads find it difficult to make the shift. Hopefully, this article will give you some insight into what to look for as a new software engineer.

1. Building the next big thing

So you recently graduated from college and want to construct the next great thing with your freshly acquired programming abilities.

However, most of the time, that drive comes from passion rather than experience, which isn’t always a negative thing; passion may lead to amazing things, but you’ll almost always need experience to pull it off.

Real-world projects are far more complex than a simple three-tier structure, especially when a scalable, distributed, and fault-tolerant system is required. As a newbie, it’s advisable to start with simple “components” and progressively increase your experience until you’re able to develop something from start to finish.

Rather than trying to develop Facebook, start with something simple like tic-tac-toe, which is small enough to implement properly in a short amount of time. It might be a straightforward console application. However, it will allow you to become more familiar with data structures and even game algorithms such as Min-max.

Begin by creating a simple two-person game in which you only handle the game state, then add some supervised learning so that a player can compete with AI. If you finish that, you could turn it into a web game with some UI features.

Then add user management, which allows users to save their game state online and resume it on any device later. Then expand it to become an online multiplayer platform where people can be matched depending on their skills.

As you go through this process with different projects, you’ll improve not only your fundamentals, but also your ability to think through your projects and how to combine multiple components to create an end product, which will help you become a better designer who thinks through problems before jumping into code!

2. Jumping into the codes too quick

As a new engineer, you’re eager to code, and it’s natural to associate your responsibility, and to some extent, your abilities, with the amount of code you write.

If you’re the type who jumps right into coding the first idea or solution that comes to mind, you’ll waste a lot of time. Avoid the urge to code and instead consider other ways to test your own assumptions.

Yes, part of this comes with practice, but it’s a good idea to start early. Too often, I see inexperienced software engineers jump right into coding something, work on it for a few days, and then realise they don’t even understand the problem.

3. Trying to code everything from scratch

This is related to the previous point, in which new software engineers are so eager to code that they want to start from the beginning. Building something on your own is an excellent approach to gain knowledge in a subject you’re interested in.

However, in terms of practicality, you should try to make the most of your time. And one great way to do that is writing less repeated code and re-use as much as possible. And libraries are a fantastic place to start.

You must also consider factors like privacy, maintainability, and package size. But it comes with time and practice. The basic concept is to think about reusing rather than writing from scratch so that you can spend your time addressing the problem rather than reinventing the wheel.

4. Being a means to an end coder

You locate a solution in a post on a site like stackoverflow.com, copy-paste it, then move on without understanding how they solved it or why you couldn’t. You remedied the immediate issue, but not the underlying issue.

As a result, you’ll become the type of engineer who solves issues in a hacky, patched-up way without really comprehending the inner workings of your own solution.

This is quite risky, since it may lead to a slew of bugs in your projects down the road, as well as severe technical debt for whoever ends up fixing your patched-up code.

Don’t be a “stack overflow developer.” It’s fine to hunt for answers online, but once you do, make sure you thoroughly grasp how it works and that you’ve filled up any holes in your own knowledge that got you to this point!

5. Not writing test

Colleges do not focus a sufficient amount of attention on testing. However, you will almost certainly not be able to check in your code without test cases in your work. Test cases are sometimes written as an afterthought by inexperienced engineers.

Any class you design should be self-contained, mockable, and have a single responsibility to be really tested. When your classes follow these guidelines, your tests will just need to simulate the intended behaviour rather than the complete dependency chain.

As a result, while building code, it’s a good practice to start with a skeleton (only classes and stubs) and then construct test cases for the intended behaviour.

You’ll be able to create fully tested code while also creating a manageable and expandable codebase with no hidden dependencies.

6. Not reading enough

Reading other people’s code, rapidly comprehending it, and being able to debug it is a talent in and of itself! So get started now, since you’ll be doing a lot of this in your profession, and reading other people’s code might be more difficult than developing your own.

As you advance in your career, the ultimate aim is to be able to not just comprehend a codebase that has been worked on by several developers, but also to rapidly grasp the overall picture and identify places where you can improve.

Going to open source projects and reading the code there to attempt to grasp what is going on is a wonderful method to develop this ability early on. Even better if you can see some flaws and submit a pull request to fix them!

7. Trying to learn too many things at once

Young developers have a serious case of FOMO these days, since they want to stay up-to-date on the current trend in Software Engineering.

So concentrate on a few things and master them. Don’t stress about keeping up with the latest trends; you’ll have plenty of time in your employment to do so.

Another thing FOMO causes individuals to do is to watch videos after tutorials on various technologies. You’ve probably heard of “tutorial hell,” when you follow tutorials and gain the false sense of confidence that you can construct anything when, in reality, you’ve learned nothing.

If you could construct Twitter in three hours, you’d be the world’s smartest and quickest engineer. Building a Twitter-like user interface with a simple API and a Firebase-like backend is NOT a Twitter clone.

In three hours, you’d be hard pushed to hand-draw only the data flow diagram required in Twitter, much alone create a complete clone. So, please do yourself a favour and stop following these instructions and instead devote your time to studying how services like Twitter truly work behind the scenes.

Furthermore, bouncing from one technology to the next never allows you to study something thoroughly. So devote some effort to solidifying your principles in a single stack. It will not only improve your engineering skills but will also provide you with a platform that will allow you to learn other languages and frameworks much more quickly!

For more such content, visit: https://bit.ly/2XkTP0P

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store