DEV Community

Cover image for 5 Good Habits of a Software Engineer
Simon Egersand ๐ŸŽˆ
Simon Egersand ๐ŸŽˆ

Posted on • Updated on • Originally published at prplcode.dev

5 Good Habits of a Software Engineer

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

Top comments (5)

Collapse
 
rmcampos profile image
Ricardo Campos

Great points!! I'm still failing mostly about the first habit. Thanks for this Simon!

Collapse
 
simeg profile image
Simon Egersand ๐ŸŽˆ

Knowing what to improve is an important step to improving -- keep at it! Any specific questions I'd be happy to help :)

Collapse
 
annietaylorchen profile image
Annie Taylor Chen • Edited

Tech debt is not the end of the world. You get used to living in a broken world.

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.

Collapse
 
littlesmith profile image
Stefan Kleinschmidt

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.

Collapse
 
simeg profile image
Simon Egersand ๐ŸŽˆ

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 ๐Ÿ™‚