… or should I rather say: Product Engineer?
Nowadays, the title of software engineer has several meanings. Depending on the type of company you work for, the roles you perform on a day-to-day basis, or sometimes even the team you are part of, different traits may be needed and expected.
One day I got into a discussion about the essence of a good Software engineer. What qualities and skills should you pay attention to when planning your development?
As I have worked for several product companies, my view might be skewed towards a product engineer, but certain characteristics are certainly common to all software engineers.
What are they? Let’s find out!
It all starts with…
Whatever the role, you probably have to do some coding or you have done it in the past. It is crucial that you do it right. So how to be efficient when it comes to pure programming?
Choose the right technology
We are currently overwhelmed with technological possibilities. This relates to high-level architecture, cloud providers, lower-level languages, libraries, and frameworks. Choosing the right tool for the job is crucial. Unfortunately, you can’t learn it from books, as it usually comes with experience. IT can be full of momentary hype and it’s important to know how to evaluate technology before using it. Is it mature enough? Is the community enough? Is it well maintained? Does it provide what is needed at any given time? Will it be a good fit in the future? After all, we are engineers, so don’t get swayed too easily and try to make data-driven decisions instead.
Which brings us to…
Understand the technology
Once you’ve made your choice, make sure you understand how the technology works. Don’t copy code from a random tutorial without knowing what’s going on underneath and why. Read the documentation, guides and samples, don’t be afraid to look into the code. Just because a library or framework solves some problems for you, that doesn’t mean you can completely ignore the inner workings. This will ensure you use the technology in the right way and may save you unnecessary debugging in the future. The greater the impact of technology on your project, the more time you should spend studying it.
Design the solution before coding
Coding is meaningless if you don’t code the right thing. Don’t be afraid to spend some time beforehand to design the solution on a whiteboard/paper/Miro board/draft file. Discuss it with your teammates and other engineers. Even when a task seems simple, it’s better to have a thumbs up before writing your first line of code rather than refactoring right after creating a pull request.
Starting point planning
You can’t plan for everything in the design. Some details only appear when you start coding. In these cases, it pays to start in the right place – to validate your assumptions or make the necessary discoveries faster. Focus on where you are first not sure how to implement and ignore trivial parts. Don’t worry, your intuition will improve with experience.
After all, you don’t want to find out that the whole concept doesn’t work only after you finish your last bit of coding.
At the same time, be flexible. Once you notice that the solution you had in mind isn’t working, be sure to step back, reconsider, and possibly pivot (you can do this on different levels).
For all of the above, you need…
The right tool
We are paid for solutions, not for typing characters on the keyboard. So make good use of an IDE, accept all the useful goods it offers and use them! Install additional plugins and tools, learn shortcuts, and spend time learning how to use the terminal. Set up your chair and a desk (your body will thank you too). If you need inspiration, check out some cool tools we use. Treat it like an investment – it takes longer to learn in the beginning, but you get great returns fairly quickly.
Let’s talk about learning…
Stay open-minded
Technology is changing faster and faster. We have to keep up. Don’t fix your mind on one language or one paradigm. Be open to new ideas and see languages as tools – change them if necessary. The more technologies you discover and use, the easier it becomes to acquire new ones.
So now you’re an awesome individual developer. Is it enough? Certainly not. Let’s get back to your game, because another important aspect is…
Building a project is a team game. So focus on the result as a group, not as an individual.
Communication
Communicate often or even overcommunicate when working remotely. Don’t assume other people know what you know. Use open channels and avoid private messages. Provide context. Be open, specific and honest. Ask for help, share the problems you are having. Anyone stuck for 2 days? Go offer your help.
Adapt a message to your audience
We are often asked to present problems or solutions to different audiences. Learn to adjust your language so that everyone can understand you. We may have a different understanding of various concepts, so it is important to prepare the ground and find a common language. It doesn’t work if during the explanation of a solution, you are the only one to type it. It doesn’t matter how brilliant the solution is.
Write clean code
It is also a way to communicate with your colleagues. That’s why everyone talks about it. Make sure others can understand your code and what it means. Think about names and how you structure the code. Add some documents if necessary to explain your intentions. You will probably also thank yourself in the future by reading the code after a few months.
Share knowledge
You may have more experience than other team members. Help them grow. Propose ideas and technologies. Explain why you would do certain things differently.
If you are less experienced or just getting started, sharing a new perspective can also be helpful! You can always find good solutions, so always talk.
Have you recently heard any interesting news? Share with others!
Ok, you are doing well both as an individual and as a team now. How do you know where to contribute the most and make the skills most useful?
At some point, it’s about…
Most businesses rely heavily on engineering. That doesn’t mean business people know how engineering works. It is our responsibility to help them make the right decisions instead of blindly providing features.
Know the context
It’s hard to contribute without the proper project context. Get to know a particular product, area or business case. Find out why someone is investing 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 always, don’t be afraid to ask (difficult) questions. Don’t think about technical details or implementation yet – sometimes solutions don’t need to be technical.
Definition of target audience
Make sure you know who will be the user of the functionality you are about to code. Do you know all the requirements? Are there extreme cases that no one has thought of? Does it really solve user problems? Will they be able to use it? Sometimes you may think “that’s not my job”, but more often than not you can contribute in some way and your contribution will be appreciated.
Manage business risk
As one of the engineers delivering the feature, you need to support the Product Owner/Project Manager regarding the risks associated with it. Ask yourself if the feature provides the desired value, taking into account the effort required. Maybe there are ways to achieve the same result in less time. Maybe some actions can be done semi-manually just to verify a theory. Maybe database updates are enough for now instead of a full CMS because content changes are so rare…
Are there any functionality implications – will this complicate things in the future? Can things get out of hand? Can it take twice as long as expected? Are there discoveries to be made before?
Is this the most important feature to implement right now? Some non-functional requirements are perhaps more urgent. Or is the order of features important and will speed up the overall delivery time?
Try to think it’s really 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 that a good software engineer should have. As mentioned at the beginning, a lot depends on the context in which you are working. However, I believe that the right mix of individual, general and business skills should be beneficial in all situations and help you become a good engineer👩💻.
What qualities did I miss? What qualities do you disagree with? Share your opinion in the comments.
