12 Things Make You A Better Software Engineer

Xun Zhou, 19 September 2022

To be a good coder in software development means different approaches to different people. Everyone might find individual way to become the expert with specific knowledge and skills.

But success in a software development team as a good software engineer is not only about individual personal development, but also about growing up as community professional.

As a full-stack software engineer who’s worked in a variety of projects over the last 12 years, I would like to share these 12 tips which I feel have helped me become a better software engineer.

Tip 1: Be a craftsman and master the tools

Source: licenced image from https://stock.adobe.com/

A real good craftsman knows his instruments very well and knows exactly which tool will be the best choice for that work. He will not try to follow the trend. He might not spend too much time to try out the newest instrument. By contrast, they prefer to keep using the most handy instrument for the certain work util they become a true craftsman who masters the instrument and gets the certain work done perfectly.

As a software engineer, we are the person and especially the people who are skilled in a software craft. It doesn’t matter what we are focusing on: front-end or back-end. We will have a set of development tools, which we prefer to use for daily work. They might be code editors, IDEs, CLIs, applications, operating systems and so on.

So, find the time to choose the best one for the job at hand, then keep practicing until we master them like a craftsman. In practice, there is no one tool to rule them all, but we should be proficient in one powerful editor, which you prefer to use whenever possible.

Whichever we choose, we should think about it: a good editor should allow for easy manipulation, and can be configured and recovered by your favorite preferences.

You might have InteliJ IDEA as your major coding IDE. My suggestion is to find time and try to master the following things by using your IDE:

  • master the most common used hotkeys
  • master the best plugins
  • master/backup the basic configuration
  • master best practice to do refactoring
  • master the usage of testing and debugging

Tip 2: Know the rules

Source: licenced image from https://stock.adobe.com/

As a good software engineer, we need the fundamental knowledge about the essential programming rules, design patterns and software architectures. All of these will build the fundamental mindset, so that we can find a solid solution for most common problems.

In other hand, it will help us to understand the source code from the others, because we know the basic rules for problem-solving. I agree totally with my colleague Clemens’s view: “These patterns or rules might not always possible to apply them 100%, but tailoring them could help to find optimal solution for current problem.”

We can look at on the following things to build your team coding commitments and design guidelines:

Basic level

  • KISS (Keep It Simple & Stupid)
  • DRY (Don’t Repeat Yourself)
  • YAGNI (You Aren’t Gonna Need It)

Medium level

Advanced level

Tip 3: Pairing with more experienced software engineer

Source: licenced image from https://stock.adobe.com/

Pair-programming is the most efficient way to improve the coding skill in the short term. It is commonly used in a coding dojo session so that two developers can work together on one computer to design the code and tests. During this session, junior developers can pick up more skills from senior developers. And those unfamiliar with a process can be paired with someone who knows more about the process. It is always a good idea to start pair-programming, if we are going to work on a software project but have still no idea about the code base.

Tip 4: Less copy & pasting

Source: licenced image from https://stock.adobe.com/

Copy & pasting from Stack-Overflow!? Yes, we can do it. But remember “do less copy and pasting”, if you can.

There are different ways to avoid directly pasting the existing solution from the others. We try to write the tests to the code we want to use from somewhere else, or we can rename the variables based on current code context, or we can refactor the original code completely without changing the direction of that concept.

After doing so, the code will not be the original one, and we are going to own and master the code pieces in our business context.

Tip 5: Insist on reading & writing

Source: licenced image from https://stock.adobe.com/

As software engineer, we should insist on both reading and writing.

The more we read, the more comfortable we’ll feel augmenting someone else’s code or documentation. Whether you are a data engineer, frontend engineer, backend engineer, insist on reading daily will teach you tools and products different from your day-to-day work.

Here are some of the websites that I would like to recommend:

On the other hand, writing is one of best processes for self-learning. You might have lots of ideas and knowledge in your mind and try to write them on a blog or note and make them well-structured. Writing will help you to build the “flow state” in your mind and organise the structure of your knowledge.

Tip 6: Design the code with help of unit tests

Source: licenced image from https://stock.adobe.com/

TDD as design tool is the “advanced stuff”. TDD need to be practiced. Something like coding dojo can help a lot. The single most important bit of TDD is that the TDD processes are telling you how to improve your code design.

Some developers prefer to use the mocking to make their tests green. Is it really always a good idea? Indeed, such tests will never tell us about the problems with the dependencies and interactions in the code.

The better way is that we intentionally use mocking as the last choice and follow the TDD approach, if it is possible. Such original Intention will guide us to create smaller services with fewer dependencies, that are easier to be unit-tested.

Tip 7: Watch tech talks

Source: licenced image from https://stock.adobe.com/

The world is changing. And it changes faster than we have imagined. “Stay hungry and stay foolish”.

Watching tech talks or videos is another comfortable and efficient way to benefit from the others in the short term. We can have the different purposes or focus during watching the tech talks. For example:

  • Learn something new from new areas
  • Learn the technical concept that is presented
  • Learn the organisation of slides
  • Learn the presentation style
  • Learn how to interact with the audience

Tip 8: Keep sharing

Source: licenced image from https://stock.adobe.com/

Share your best practice, code snippets or packages in the community. Don’t own the code alone by yourself or within your team.

Maybe we have very strict security guidelines, and we are not able to share the source code directly. But we can still create the dummy application with similar use-case and share the same concept of that solution, then the sharing will not be limited due to the security issues.

Don’t be shame, just try, make it happen. Not only about code sharing. In fact, everything can be shared in my opinion:

  • Software bundles or packages
  • Code snippets for a solution
  • Tests
  • Configurations as best practice
  • Blog articles, documentations, guidelines
  • Online tools you built/found/tried
  • Your growing-up stories

Tip 9: Make side-projects

Source: licenced image from https://stock.adobe.com/

Do something different and make side-projects.

This point might be optional. It does depend strongly on our personalities and characters. Someone might prefer to just do one thing in his entire life, but do it extremely well; the others might think that it is too boring to do the same thing all the time and they would like to try something new.

My choice is to make frontend side-projects and have always my focus on backend.

So, decide by yourself.

Tip 10: Find a great mentor & Be a great mentor

Source: licenced image from https://stock.adobe.com/

A good mentor will tell you about your gaps and help you to build the bridges. We should have a mentor to guide us, so that we will have the maximal performance in the shortest time.

Being a mentor, you will have the deeper understanding on what you are teaching. It helps both parties if you are doing a mentoring well.

“Try to teach others and share your experience from beginning on. When you are a junior you can mentor students, when you have already some experiences you can mentor a junior.”

That was the recommendation from one of my mentors in a discussion on LinkedIn.

Tip 11: Learn to communicate well

Source: licenced image from https://stock.adobe.com/

Good Software engineer should share the value to the community steadily and we should communicate well. So, get out of the comfort zone and learn the skills for communication, presentation, moderation and leadership.

Tip 12: Think beyond the code

Source: licenced image from https://stock.adobe.com/

Designers care about the user experience, good styling, and product value. Yes, we do! We care about the good design and architecture, and the business value and the end-users.


Source: created by xun.zhou@mail.schwarz

This self-evaluation “12 things make you a better software engineer” should present a good picture of the importance and help us align them accordingly.

There are still two pillars that I want to highlight: “communicate well” and “find a great mentor”

“Communicate well” will help us to become a team player, and it is one of most important preconditions for the rest of other things.

“Find a great mentor” will help us to be adjusted during the personal development. We will make a lot of mistakes if we are putting into action. In this situation, a mentor as advisor will give us valuable suggestions to help us find the gap and build the solution for them.

If you are getting started as a software engineer, think about how you can practice some of 12 things in your daily work. However, if you are experienced software engineer, think about to give you the score for each, then find out where you could do better.

Not all problems have single solutions. It is just an inspiration. 😀

⚠️ All images used in this article are licenced for Schwarz IT from https://stock.adobe.com.