5 Lessons I Learned in 7 Years as a Software Developer

Typed Languages are better than Dynamic Languages

Statically typed languages are better performant than dynamically typed languages. Even if you take the example of JavaScript & TypeScript, TypeScript is a superior alternative even if it has a learning curve where you have to write types and perform checks. When you are working with medium to large size projects and especially when working with teams, it will be beneficial to have a type system in place.

Even with Golang, C++, the more types you have in place, the more rigid your codebase can be. As beginners, we really enjoy dynamically typed languages, but when you get used to typed languages, they enforce discipline to the codebase.

Don't try to solve a solved problem

It's okay to understand how to solve a problem to its core, but it's not a good idea to always develop everything from scratch for your application. JavaScript or Python have a lot of libraries that make writing code much easier and efficient. They also help us easily maintain our code to avoid a hassle and a lot of refactoring in the future. When the code base grows, this is applicable to cloud architecture or any other place where there are good alternatives for you, so you should probably avoid building it from scratch.

An open-source project or library will undoubtedly exist that will be very simple than you could have thought for the solution you are trying to create. Some developers might have already encountered the problem you might try to solve. They would have solved it in a very simple and efficient manner.

So never try to reinvent the wheel, especially when you are working in a startup and have specific deadlines. You also save a lot of time by using the pre-built libraries, which later you can spend the saved time to work on increasing the performance of adding new features to your app.

Clever code is a sign of bad code

People who write clever or mysterious code which most people can't understand is a bad code, and a person is a bad programmer because you never want your code to be mysterious. You always wish fellow developers to read and understand your code to help you refine the process, and it will also be easy for refactoring in future versions.

It's not always good to use the awful amount of shortcuts. This may reduce your time to code but affect your colleagues who have to review and make changes to your code.

The most important thing here would be not to use single-character variables while working on your companies codebase or any other project that you are working on. This will wreak havoc for all your colleagues who are working on the project. These shortcuts and single-character variables are efficient when you are doing competitive coding as it saves you some seconds. Still, when it comes to development, this is a terrible practice.

RDBMS v/s NoSQL

If you are trying to build real-world or moderately complex applications, you'll realize that there are many relations between the data you are storing.

So when you have relational data, RDBMS is best suited to manage the relational data. The most common RDBMS which are in use are MySQL, PostgreSQL. SQL database manages and performs better than NoSQL database when it comes to relational data. SQL databases can easily map the data. You can fetch the data easily with a single SQL query.

When it comes to NoSQL, they also can have relations, but the relations seem fake because you have to perform a second query or aggregations to perform a lookup. So NoSQL works best if the data is not relational. When it comes to building real-world applications, most of the data you get will be relational, so it's really important to understand a SQL Database. Apart from relational data, there could be some exceptions where you only capture specific limited data that can be documented without any relations. You can use NoSQL, which won't affect your database performance.

There is usually No right way to do a certain thing

There is usually no right way to make your application. It could be a simple function to return two numbers or multiple ways you could do that. It depends on what you choose. This point will overrule all the above points. As a developer, you will discover that there are many ways in which we could do something, and we have not imagined that.

All the best practices together are not the best practices

When you are trying to follow a list of best practices while building your project, you are doing it the wrong way. Because many best practices can't go along together, that means you cannot use two similar best practices while defining the same function. If done, this may also break your code in many other ways. So it's vital to stick with the bare minimum practices as possible.

You can watch the YouTube video here.