How to Improve as a Developer Using 5 Simple Tips

5 Simple Tips to Help You Improve as a Developer

Tips that will stand the test of time (whatever the current hot framework is)

Do you sometimes feel exhausted and tired of learning new technical skills? Do you have the feeling that the moment you master something, you already have to switch to the next new thing? I do.

In this article, I will give you five simple tips to improve as a developer that will stand the test of time. These tips will help you through your entire career as a developer.

1. Think and Design Before Implementing

First, I come up with a rough sketch of a solution before I start implementing it. This could mean creating a design document or a sketch on a whiteboard.

Before I start with the implementation, I explain the design to one or more colleagues. This is useful in two ways: By telling it, it forces me to think it through; I also get helpful feedback.

As many teams are using Agile methods, I see more and more developers skipping design — they pick up a story and start implementing it right away.

Sure, they create a design in their head. But there’s great value in making that design explicit.

Remember, there’s no shame in creating a design story.

If I need to choose between two options when creating a design, I use the Easier to Change (ETC) principle from The Pragmatic Programmer:

A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing. So we believe in the ETC principle: Easier to Change. ETC. That’s it.

2. Split Your Stories into Small Tasks

When starting a new story, you should ask yourself, “How can I split this story into many smaller tasks.” This forces you to find the best strategy to implement it and reduces complexity.

It helps me when I assume that more developers are going to work together on this story.

Frequently, I see developers create a single task implementation. I don’t know why. Maybe they’re scared about the transparency it creates? With a single implementation task, nobody will see that you forgot something.

During the implementation, I always find that I forgot one or more tasks. But if you force yourself to do this every time you start a new story, you will become better at it.

You won’t forget to add the integration test task that you forgot the first time.

3. Ask For and Perform Brutally Honest Code Reviews

Just this week, it happened again.

I implemented a new class library. I thought well about the class names and methods. I had a good feeling. It all made perfect sense to me. The code was clear, and the unit tests succeeded. I submitted my pull request (PR).

When my colleague finished the pull request, we started discussing his remarks. To my surprise, he didn’t understand the class and method names.

You have to remember that when you implement something, the names you come up with are always clear to you. The only way you can confirm it is by showing it to someone else.

Code reviews are a great way to improve. When a co-worker reviews your code, you can learn from the feedback you receive. If you review someone else’s code, you can learn from the code and learn to provide feedback.

Code reviews have to be brutally honest. Don’t be afraid to create remarks if something is not obvious. Just treat other developers with respect.

4. Create a Quiet Work Environment

In the Netherlands, where I live, open offices are the standard floor plan for development companies.

Open offices are supposed to improve collaboration, communication, and productivity. Many research studies have shown that this is not the case. Instead of increasing interaction and collaboration, the opposite happens.

Another effect of the open office is the continuous stream of distractions. When you’re developing, you need to focus — any extra stimuli will reduce it. You can improve as a developer by removing distractions.

Ask your employer to install soundproof wall panels or install carpet. Failing that, ask your employer for noise-canceling headphones.

5. Don’t Focus on Programming Speed

It’s easy to say, “don’t focus on programming speed,” as everything in a modern development process is organized around moving tasks as fast as possible from “to do,” “in progress,” into “done.”

But instead of focussing on speed, you should focus on quality. If you focus on quality, speed will follow.

Or as Robert C. “Uncle Bob” Martin’s describes it in his article “vehement mediocrity”:

Novices believe that quality and velocity are inverse. They think that hacking is fast. They haven’t yet recognized what professional developers know all to well: that even a little bit of hacking is slower than no hacking at all.

Every time you yeild to the temptation to trade quality for speed, you slow down. Every time.

Conclusion

The previous five tips provide more value than learning another new framework or programming language will. The best thing is that they will stand the test of time and still be relevant tomorrow.

Thanks for reading!