As a software engineer, it’s important to build good habits

 ## As a software engineer, it’s important to build good habits As a software engineer or developer, especially if you are at the beginning of your career, it’s important to build good habits. Good habits speed you and your team up and help 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 know (master) your tools to the point where you are utilizing features that speed you up. Let’s look at an example! My favorite IDEAs come from JetBrains. They create IntelliJ, PyCharm, WebStorm, and more. These IDEAs have (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 At 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 at 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 website with a specific design. A menu at 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 website”. The next week the business or client tells you they want the menu on the right instead of at 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! Ever 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. en.wikipedia.org/wiki/KISS_principle Many times I’ve encountered codebases 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 favorite 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 them. Follow me on Twitter @prplcode ### Did you find this article valuable? Support Simon Egersand 🎈 by becoming a sponsor. Any amount is appreciated!