As a software engineer or developer, especially if you are in the beginning of your career, itās important to build good habits. Good habits speed you and your team up and helps you write maintainable code.
Know Your Tools
At first thought this might seem obvious. āDuh, obviously I know how to write code in my editor and use grep in my shellā. My point goes beyond this. What I mean is that you should really (master) know your tools to the point where you are utilising features that speed you up.
Letās look at an example!
My favourite IDEAs comes from JetBrains. They create IntelliJ, PyCharm, WebStorm and more. These IDEAs has (pretty much) the same features and key bindings. Over the years Iāve dedicated time to learning the most useful shortcuts and this makes refactoring really quick.
Rename a class? One shortcut. Extract code to a method? One shortcut. Run test in debug mode. One shortcut.
This is a simple example but I think you get my point. I often see engineers, from associate and senior level, using their mouse to click buttons in the UI or copy-paste when renaming a variable. Donāt treat your IDEA as a simple text editor; use it as the powerful tool it is!
Not only will you save time but you will also feel awesome āļø
Donāt Strive For Perfection
In the beginning of my career I wanted all the code in my teamās system to be perfect. Iād spend hours refactoring CSS classes, thinking about variable names and creating nice abstractions. Then one day, it was decided the system was gonna be superseded by another system from a different team š® All my perfect code just became useless.
Since then Iāve come to understand the value of shipping code thatās maintainable but not perfect. You might even ship code thatās not maintainable if it provides value to the business or customer. The code you write is simply a tool to solve real life problems and if the problem warrants it, you should be OK with shipping non-perfect code.
Tech debt is not the end of the world. You get used to living in a broken world, and thatās fine, because your work is not about producing perfect code but to provide value to the business or customer you are working for.
Understand What You Are Building
Too many times Iāve seen experienced engineers I work with jump on a task with the goal of finishing it as quick as possible. This is a bad habit. On the other hand, for engineers in the beginning of their career this might be exactly what they need ā they need to write code, feel productive and most importantly learn.
Experienced engineers though should always understand what the task they want to do achieves, both the value it provides as well as how it fits in with the bigger picture. This is how you learn about the domain to eventually become a domain expert that will greatly help you in progressing in your career.
Abstract, But Not Too Early
Abstractions are great. Everyone loves a good abstraction! But choosing a good abstraction is difficult. Far too many times Iāve seen fellow engineers make abstractions during the design stage, and this is not a good idea.
Abstractions hide complexity and we have different tools to hide them. In code we have methods, functions, abstract classes, interfaces etc. Now why should you not abstract too early?
Consider this: youāre tasked with building a web site with a specific design. A menu in the top of the page, for example. āAha!ā you say, āLet me save myself and my colleagues time by creating an TopMenuWebsite component we can re-use for the next web siteā.
The next week the business or client tells you they want the menu on the right instead of in the top. āOh shoot, I just spent so much time building the TopMenuWebsite component but now itās worthlessā.
Yes, this is a simple example, but you get the point.
A good rule of thumb is: donāt abstract until you have three examples. This will give you a good understanding of what parts can be abstracted and which parts can not.
Donāt Over-Engineer
Iām an engineer ā Iāve spent years in school learning about compilers, math and low-level languages. That means I must create complex software, right? No!
Every heard of the KISS principle?
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore,Ā simplicityĀ should be a key goal inĀ design, and unnecessary complexity should be avoided.
Many times Iāve encountered code bases where the engineers were trying to achieve greatness solving trivial problems. Or taking on too many problems for a single system. This is a classic trap that we all fall into sometimes.
Conclusion
These are my five favourite habits of an engineer thatās in the start / mid of their career or just 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 all countless times but I always try to learn something from it.
Follow me on Twitter @prplcode
Originally published here.