Especially if you're just starting in the industry, it's essential to develop good habits as a software engineer or developer. You, your team, and your code will be more maintainable if you have good habits.
Here are the best habits for software engineers.
Knowing Your Tools
We know how to use grep in our shell and write code in our editor. Our point goes beyond this. You need to become familiar with your tools to the point where you can use features that will speed up the process.
Let's examine an example!
We like IDEA's from JetBrains. Their products are IntelliJ, PyCharm, and WebStorm. The key bindings and features of these IDEA's are identical. Our goal has been to learn the most valuable shortcuts over the years. Refactoring becomes faster and easier.
Are you changing the name of a class? Just one shortcut. Making a method from code? No problem. Using debug mode is a quick fix.
Here's an example, but you see what We mean. In the UI, We often see engineers clicking buttons with their mice, associates, and senior engineers. Renaming variables is usually done by copy-pasting. IDEA is more than just a text editor; use it as a powerful tool!
Saving time is one thing, but you will also enjoy it!️
Try not to be perfect.
Our team's code was going to be perfect at the beginning of our career. The CSS classes would take hours to refactor, variable names to use, and abstractions to create. Our system was then replaced one day by a system developed by another team. 😮 All our perfect code became useless.
Since then, I've understood the value of a shipping code that's maintainable but not perfect. Providing value to the business or the customer can even justify a shipping code that's not maintainable. It's just a tool for solving real-life problems with code. You can ship a non-perfect code if the issue warrants that.
There is no point in accumulating tech debt. In a broken world, you just get used to it. You don't need to produce perfect code to be productive since your job is to deliver value for the business or customer for whom you work.
Understand what you intend to build.
Our experience is that experienced engineers rush to finish a project as quickly as possible. We do not recommend this practice. This might be perfect for engineers just starting in their careers! Writing code, feeling productive, and, most importantly, learning are essential.
However, experienced engineers should always know why a task is being assigned. That is, both its value and its importance to the overall picture. The process of becoming a domain expert proceeds in this manner. This is an essential step in your career development.
Stay Abstract, But Not Too Soon
It's good to be abstract. We love a great idea. Choosing the right abstraction can be difficult. Engineers have made way too many abstractions during the initial design stage. We recommend against this approach.
Abstractions hide complexity, and we have different tools to hide them. We have methods, functions, abstract classes, and interfaces in code, e.g., Now, why should you not abstract too early?
Consider this example: you're tasked with building a website with a menu at the top of the page. "Aha!" you say. "Let me save time by creating a TopMenuWebsite component that our team and We can re-use for the next website."
The client tells you they want the menu on the right instead of at the top the following week. "Oh shoot, We spent so much time building the TopMenuWebsite component, but now it's worthless."
If you're not sure how to abstract, you should have at least three examples. In this way, you will determine which parts can be abstracted and which ones cannot.
Be careful not to overengineer.
Most of our schooling has been spent studying compilers, math, and low-level languages. Does that mean We need to create complex software? No!
Do you know the KISS principle?
According to the KISS principle, most systems work best when kept simple rather than complicated; therefore, simplicity should be a fundamental goal when designing, and unnecessary complexity should be avoided. en.wikipedia.org/wiki/KISS_principle
We've seen codebases where the engineers solved trivial problems with great complexity—or took on too many issues for a single system. This is a classic trap that we all fall into sometimes.
Conclusion
These are our five favorite habits of an engineer who's in the start / mid of their career or someone who needs a reminder. Building good habits takes time, and you learn by making mistakes, so if you ever did any of these, don't feel bad. I've done them countless times, but We always try to learn something from them.
Information
