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 in my shell”. My point goes beyond this. What I mean is that you should (master) know your tools to the point where you are utilising features that speed you up. grep really 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? . Extract code to a method? . Run test in debug mode. . One shortcut One shortcut 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 component we can re-use for the next web site”. TopMenuWebsite 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 component but now it’s worthless”. TopMenuWebsite Yes, this is a simple example, but you get the point. : 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. A good rule of thumb is 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, should be a key goal in , and unnecessary complexity should be avoided. simplicity design https://en.wikipedia.org/wiki/KISS_principle 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

Twitter

2022 - HackerNoon Contributor of the Year - Future Of Work

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Productivity

2022 - HackerNoon Contributor of the Year - Software Engineering

2022 - Remote Work Warrior

2022 - Software Developer of the Year

Super Career Strategist of 2022

Support Me on Coil

Portfolio

Nominated for 2022 - HackerNoon Contributor of the Year - Productivity

Nominated for 2022 - Remote Work Warrior

Nominated for Super Career Strategist of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Email

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Nominated for 2022 - HackerNoon Contributor of the Year - Future Of Work

Sr. Software Engineer @ Spotify

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Habits Every Software Engineer Should Imbibe

Habits Every Software Engineer Should Imbibe

Too Long; Didn't Read

Company Mentioned

Simon Egersand 🎈

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Habits Every Software Engineer Should Imbibe

Too Long; Didn't Read

Company Mentioned

Simon Egersand 🎈

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES