As a software engineer or developer, it’s important to build good habits. Especially if you're at the beginning of your career. Good habits speed you and your team up and help you write maintainable code.
Good Habits of a Software Engineer
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 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. This makes refactoring quick and easy.
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 you get my point. I often see engineers, from associate and senior levels, use 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, using ideal variable names, and creating nice abstractions. Then one day, the company decided a system from another team was gonna supersede our system. 😮 All my perfect code 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. 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 providing value to the business or customer you are working for.
Understand What You Are Building
Too many times I’ve seen experienced engineers start a task with the goal of finishing it as quickly as possible. This is a bad habit. But 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 achieves. Both the value it provides as well as how it fits in with the bigger picture. This is how you work your way to becoming a domain expert. Something that will greatly help you progress 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 engineers make abstractions during the initial design stage. This is generally a bad idea.
Abstractions hide complexity and we have different tools to hide them. In code, we have methods, functions, abstract classes, interfaces, and so on. 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 I and my team can re-use for the next website”.
The next week the client tells you they want the menu on the right instead of at the top. “Oh shoot, I spent so much time building the TopMenuWebsite component but now it’s worthless”.
A good rule of thumb is: don’t abstract until you have at least 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.
https://en.wikipedia.org/wiki/KISS_principle
I've seen codebases where the engineers were solving trivial problems with great complexity. 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 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 all countless times but I always try to learn something from them.
Connect with me on Twitter, LinkedIn, or GitHub
Originally published at prplcode.dev
Latest comments (5)
As someone who loves to chase shiny new things, this is what I must learn. Now I feel less urge to update my site that's functioning well from React 16 to 18, just because it's new.
Good and valid points. Only one small thing: The class of software you are referring to in point 1 is an IDE (Integrated Development Environment). "IntelliJ IDEA" is one specimen of an IDE and "IDEA" is a data analysis tool used mainly by tax auditors. Sorry for the nitpicking.
IDEA can also stand for Integrated Development Environment Application and that's how JetBrains how refer to their IDEs. But other than that, you are correct 🙂
Great points!! I'm still failing mostly about the first habit. Thanks for this Simon!
Knowing what to improve is an important step to improving -- keep at it! Any specific questions I'd be happy to help :)