Accelerate your software engineering career by reading code

Many developers often focus solely on writing code, neglecting the importance of being able to read code. How do I know? Because I was one of them!

The ability to read code is a crucial skill for every developer, as we often spend more time reading code than actually writing it. However, reading code is often more challenging than writing code. It requires piecing together the context from various parts and putting yourself in the shoes of the original code author. Fortunately, this skill can be learned. As a software engineer, you have plenty of opportunities to enhance this skill while performing your job:

Participating in code reviews
Debugging code that is outside of your area of ownership
Familiarizing yourself with the code of libraries that you depend on

And, there is also GitHub with thousands of repositories solving problems of all shapes and sizes. You are guaranteed to find something that will interest you and dive in.

Improving your ability to read code will unlock many benefits for you:

Getting up to speed when changing jobs or teams will be smoother and faster.
Code reviews will take less time.
Understanding bugs and fixing them correctly the first time will be easier.
Knowing how your dependencies work will help you come up with better designs.
Your debugging will be more effective, especially in cases where you can’t debug directly (e.g. missing debug symbols, decompiled code, etc.).

If you feel reading code is not your thing, think again. It might take some time to pick up this skill, but it will serve you for years.

Accelerate your software engineering career by writing good commit messages

“’Fixing a bug’ is a great commit message!” said no one.

Why? Because commit messages like this make our jobs frustrating.

Good commit messages on the other hand, make our jobs easier and save everyone time as they:

give more clarity to the diff author – if you, as the diff author, have a hard time writing a good commit message maybe your change is not ready for review?
help understand what the person who wrote the code was thinking which makes it much easier to grasp reasons why the code was written the way it was written and helps avoid introducing regressions
provide the context for code reviewers and as a result facilitate faster code reviews by lowering the barrier to entry for anyone willing to review the change
allow finding commits quicker

Note that this is not about making commit messages longer. Long commit messages are not necessarily good commit messages. Good commit messages are short but informative. In many cases a single line explaining what the change is about is sufficient. More complex changes, especially bug fixes, often require more context:

What exactly the change is about. This information is a must, and should be always included in the title.
Why you are making this change. What scenario it unblocks. What issue it fixes.
Short description of implementation details.
If fixing a bug, how to reproduce it.
How the change was tested – especially useful for any validation beyond unit tests
Links to related issues or tasks

You can find an expanded version of this post here: https://growingdev.substack.com/p/how-to-remove-unnecessary-friction

Accelerate your software engineering career by deleting code

While you were writing some new shiny features today, the following happened:

Someone accidentally disabled a feature flag gating the most important product feature that shipped years ago
Someone spent a day fixing tests not realizing the code being tested is only executed by these tests
Someone missed a deadline because the build system was building long forgotten libraries instead of the code they committed to ship

The common denominator for all these cases – dead code.

Aggressively cleaning code that is no longer needed or used can, and will make your team more effective because it reduces the overall complexity of the codebase. This, in turn, unlocks a lot of benefits:

bugs and mistakes are easier to avoid
new features can be delivered faster
less time is spent on (unneeded) maintenance

Deprecating rarely used features takes it to the next level.

Try it, and you may turn your team into a team of the proverbial “10x engineers”.

Accelerate your software engineering career by reviewing code

Reviewing code is often treated as a chore. This is sad because reviewing code is a great opportunity!

Code reviews help find bugs early
The earlier a bug is found the smaller the damage it can cause, and the cheaper it is to fix. Code reviews allow catching bugs very early in the process.
Code reviews allow influencing the design
Suboptimal design choices are hard to change once submitted. Code reviews make it possible to identify them early and discuss alternative solutions that could make the code simpler, more robust and easier to work with.
Code reviews help the team achieve its goals
Each diff contributes to achieving some goal. Reviewing code unblocks the team to move towards this goal.
Code reviews are a great learning opportunity
Diffs contain a wealth of knowledge. Whether it is an interesting language feature used by the author or an innovative idea proposed by a fellow reviewer, there is always something new to learn.
Code reviews give a chance to foster knowledge
Just as you can learn from others through diffs, others can learn from you. By suggesting alternative approaches, highlighting trade-offs or explaining language intricacies you can help other engineers grow.

But wait, there is more! In addition to all benefits listed above you can also be recognized for reviewing code. When I worked at Amazon my code reviews won me an award for demonstrating the “Insist on the Highest Standards” leadership principle and were one of the factors supporting my promotion.

Accelerate your software engineering career by sending small diffs

Every software developer gets carried away once in a while. There is this new cool, top requested feature and we want to code it quickly, so we disappear somewhere and, after a few weeks, we drop this huge diff (a.k.a. PR, CR) like a bomb. We are so proud of our work! Somehow, our team members do not share our level of excitement. Why is that?

Well, it turns out that huge diffs create a number of problems that make lives of both the author and his team harder:

Getting huge diffs reviewed is challenging
Finding someone willing to review a huge diff is difficult. Once this person is found, the progress depends on them finding a lot of time to properly review the changes.
Occasionally, a huge diff draws attention from multiple reviewers leaving tens of conflicting comments. Each new iteration addressing these comments only sparks more comments.
Keeping huge diffs up-to-date is hard
While a huge diff is being iterated on smaller diffs are merged daily. This may result in merge conflicts which take time to resolve, create risk of introducing bugs due to bad merges, and make it harder to understand what changed between iterations.
Huge diffs rarely receive good feedback
Understanding of a huge diff is hard and time consuming. Reviewers often focus on less relevant but easier to understand details. Sometimes they give up and just rubber stamp the diff without leaving any useful feedback. In either case, obvious issues can easily sneak into the product.
Huge diffs make it hard to pivot
Sometimes, someone finds an issue that forces changing direction. In case of a huge diff it means a lot of time was spent on writing code that now needs to be rewritten or thrown away.
Merging huge diffs may have significant negative impact
When a huge diff is finally merged, it often wreaks havoc across the team. Many ongoing changes have to be redone, the number of reported issues increases significantly, dashboards and alerts get broken, etc.

The alternative to huge diffs is splitting the work to smaller, more manageable chunks. Each chunk should be a logically complete piece of functionality that can be independently merged and brings the feature closer to completion. It may feel like more work but it is a much more effective approach:

code reviews are faster as small diffs take less time to review
different diffs can be reviewed by different people – there is no longer a bottleneck of a single reviewer
smaller diffs are easier to understand so they get better feedback
it is possible to work on the next diff while having one in review
changes are localized so the risk of merge conflicts is reduced
course correction, if necessary, is easier because there is not much code impacted

Getting used to splitting the work to smaller chunks can be hard at the beginning but once you get used to it, it will become natural and your productivity will soar!