Characteristics of a Good Software Engineer
… or should I rather say: Product Engineer?
Nowadays, the Software Engineer title has many meanings. Depending on the type of the company you work for, roles you take every day or sometimes even the team you’re part of, different traits might be needed and expected.
One day I got into a discussion about the essence of a good Software Engineer. What qualities and skills should one pay attention to when planning their development?
As I’ve worked for multiple product companies, my view might be skewed towards a Product Engineer, but some characteristics are certainly common for all Software Engineers.
What are they? Let’s find out!
It all starts with…
Being an effective programmer
No matter the role, you probably need to do some coding or you’ve done it in the past. It’s crucial you do it well. So how to be effective when it comes to pure programming?
Picking the right technology
We’re currently overwhelmed with technology possibilities. This relates to high-level architecture, cloud providers, languages, and libraries and frameworks on the lower level. Picking the right tool for the job is crucial. Unfortunately, you can’t learn it from the books, as it usually comes with experience. IT can be full of momentary hype and it’s important to know how to assess the technology before using it. Is it mature enough? Is the community sufficient? Is it well-maintained? Does it deliver what’s needed at a given moment? Will it be a good fit in the future? After all, we’re engineers, so let’s not get influenced too easily and instead try to make decisions based on data.
Which leads us to…
Understanding the technology
Once you’ve made a choice, make sure to understand how the technology works. Don’t copy the code from a random tutorial without knowing what is roughly happening underneath and why. Read the docs, guides and examples, don’t be afraid to look into the code. Because a library or a framework solves some problems for you, it doesn’t mean you can ignore the inner workings altogether. This will ensure you use the technology the right way and might save you from unnecessary debugging in the future. The bigger the impact the technology has on your project, the more time you should spend investigating it.
Designing the solution before coding
Coding doesn’t make sense if you don’t code the right thing. Don’t be afraid to devote some time beforehand to design the solution on a whiteboard/paper/Miro board/scratch file. Discuss it with your teammates and other engineers. Even when a task seems simple, it’s better to get a thumbs-up before writing your first line of code than to refactor just after creating a pull request.
Planning the starting point
You can’t predict everything during the design. Some details emerge only when you start to code. In these cases, it pays off to start at the right spot — to validate your assumptions or make necessary discoveries faster. Focus first on the places you are not sure how to implement and ignore the trivial pieces. Don’t worry, your intuition will get better with experience.
After all, you don’t want to find out that the whole concept doesn’t work only after having finished your last part of coding.
At the same time, be flexible. Once you notice the solution you had in mind isn’t working, make sure to take a step back, reconsider, and possibly pivot (you can do it on various levels).
For all of the above, you need…
The right tooling
We’re getting paid for solutions, not typing characters on the keyboard. So make proper use of an IDE, accept all the helpful goods it offers, and use them! Install extra plugins and tools, learn the shortcuts, and spend time getting to know how to use the terminal. Set up your chair and a desk (your body will be grateful too). If you need some inspiration, check out some cool tools we use. Treat it as an investment — learning takes extra time in the beginning, but you get great returns soon enough.
Talking about learning…
Staying open-minded
Technology evolves faster and faster. We need to keep up. Don’t fix your mind on a single language or paradigm. Be open to new ideas and treat languages as tools — switch them when needed. The more technologies you discover and use, the easier it gets to pick up new ones.
So now you’re an awesome individual developer. Is this enough? For sure not. Let’s pick up your game, as another important aspect is…
Being a team player
Building a project is a team game. So focus on the outcome as a group, not as an individual.
Communication
Communicate often or even overcommunicate when working remotely. Don’t assume others know what you know. Use open channels and refrain from private messages. Bring context. Be open, precise and honest. Ask for help, share problems you encounter. Someone’s stuck for 2 days? Go and offer your help.
Adjusting a message to your audience
We’re often asked to present some problems or solutions to different audiences. Learn how to adjust your language so that everyone can understand you. We may have a different understanding of various concepts, so it’s important to set the stage and find a common language. It doesn’t work if during explaining a solution, you’re the only one grasping it. No matter how brilliant the solution is.
Writing clean code
This is a way of communicating with your colleagues too. That’s why everyone talks about it. Make sure others can understand your code and the meaning behind it. Think about the names and how you structure the code. Add some docs if needed to explain your intentions. You will probably thank in the future yourself too when reading the code after a few months.
Sharing the knowledge
You may have more experience than other people on the team. Help them grow. Suggest ideas and technologies. Explain why you would do some things another way.
In case you are less experienced or even just started, sharing a fresh perspective might be helpful as well! You still may come up with great solutions, so always speak up.
Have you recently learnt some interesting news? Share with others!
Ok, you’re performing great both as an individual and a team now. How do you know where to contribute most and make the skills the most useful?
At some point, it’s all about…
Understanding the business
Most businesses rely heavily on engineering. It doesn’t mean business people know how engineering works. It’s our responsibility to help them make proper decisions instead of blindly delivering features.
Knowing the context
It’s difficult to contribute without the proper project context. Get to know a product, a domain or a particular business case. Find out the reasons why someone invests money in it. What do they want to achieve? You don’t need to be an expert, but even basic knowledge helps a lot every day. As usual, don’t be afraid to ask (challenging) questions. Don’t think about technical details or implementation yet — sometimes solutions don’t need to be technical.
Defining the target audience
Make sure you know who will be the user of the functionality you’re about to code. Do you know all the requirements? Are there any edge cases nobody thought about? Does it really solve users’ problems? Will they know how to use it? Sometimes you may think “it’s not my job”, but more often than not you can contribute in some way and your input will be appreciated.
Managing the business risk
As one of the engineers delivering the feature, you should support Product Owner/Project Manager when it comes to the risks connected to it. Reflect on whether the feature brings intended value — taking into consideration needed effort. Maybe there are ways to achieve the same result in a shorter time. Maybe some actions can be done semi-manually just to verify a theory. Maybe DB updates are good enough for now instead of a full CMS, because content changes are so rare…
Are there any consequences connected with the feature — will it complicate things in the future? Can things spin out of control? Can it take twice as long as estimated? Are there any discoveries to be made first?
Is it the most important feature to implement right now? Possibly some non-functional requirements are more pressing. Or the order of the features matters and will speed up the overall delivery time?
Try to think that it’s truly your product, your money — and you want to spend it as wisely as possible.
I’m sure this is just a minor subset of characteristics a good Software Engineer needs to possess. As mentioned at the beginning, a lot depends on the context you work in. However, I believe that a fair mix of individual, soft and business skills should benefit in any situation and help you become a good Engineer👩💻.
What qualities have I missed? What qualities don’t you agree with? Share your thoughts in the comments.
