I worked as a professional developer for over 10 years, under different positions, coding in different languages, as an architect and technical leader and yet when it comes to being a good developer there are a few things I always need to keep reminding myself.

Today I thought about sharing these tips with you, so you can learn from my experience, and maybe, even integrate them into your routine as a developer. The same way I ask you to be open to my suggestions, I'm open to yours, so please let me know what are the things that you do which makes you a great developer.

1. Code for your future self

Some people say code as if others are trying to read and understand your code, and it's a great piece of advice, however, because I've been there, when I'm writing code I like to think of my future self, maybe a year from now, coming back to this new function and having to work on it.
Let me explain what I mean by this, a few years back I had the pleasure of working on a complicated piece of software which required me to code a library to handle the rendering of very complicated and dynamic structures. Without any doubt, I embrace myself into the task, and thousands of lines of code later it was a marvel. The library ended up being at the core of the application, it was heavily everywhere throughout the application, and boy I was happy with it. However it was time for me to move on to a new team, and delegate the app to another team.

2 years later after the transition, I received a call, turns out the app team needed to do some major redesigns into the library and they were stuck, so they asked for my help. After checking out the code again, first I felt a bit nostalgic having to work with it, with a sense of pride in how far the project went. However after some time into the code, I started to realize why they called me, there was no chance, someone else could fix this, you know why? Because not even I could.

I hated that guy, how could he do that? how could he think it was so easy back then when everything was fresh? I don't know... And thus I learned my lesson, at the time I was not very experienced, and I took many shortcuts in documentation and design.
Learn from my story, and code for your future self, document as if you have to go through it all over again, using clear names, don't make overly complicated functions, you know all of it, don't forget in the rush of getting features out.

Every block which is not clear curs a debt to the code, and sooner or later, that debt is paid!

2. Let your commits tell the story

There are 3 types of developers in this world when it comes to commit messages and we will explore them all:

• Too lazy to explain what I did
• Messages are just personal and no one should read them
• No PR goes through until you fix that message

Too lazy to explain what I did

Let's start with the first type. Most of us I believe fall into this category, for different reasons we commit in a rush, or we are simply annoyed by it, so when we are prompt to enter the message we do the typical "WIP", "Changed something", "asdf", etc.

Why is it so hard to write a few lines telling what we did? I'll never know.... and believe me, "some fixes" is probably one of my favorite commit messages. If you follow into this category, please do me, your team, and yourself a favor, spend an extra 2 minutes and do it properly. It won't kill your performance, it won't hurt you.... it will just make your git history tell a story.

Messages are just personal and no one should read them

Another type is not really lazy, he/she just doesn't care, and why would they? "Commit messages are for me and no one should read them..." I've heard that many times, and if that's the case and that's what the team is going for that's fine, just do me a favor, squash your commits when you merge, and put a decent message then. If your personal commit history is not relevant, erase it from this planet as soon as your code is merged.

No PR goes through until you fix that message

And, there's the other extreme, and I've been there myself as well. When you jump from being too lazy, to realize how important commit messages are, you tend to overdo it, though I personally think is better, don't get too sentimental if someone doesn't follow everything exactly as you wanted. As long as the messages are clear enough it should be fine.

Find your balance, make meaningful contributions to your code, and let your history tell the story, it's important, anyone entering your team would benefit from it, and even yourself in some circumstances.

If you are interested, I've my own commit messages system I like to implement wherever I go: https://gist.github.com/bajcmartinez/cc5a165f0ab8d0e9422dfd84eb375cd6

3. Go the extra mile, but no more

There's the phrase, "Aim for the moon, if you miss, you may hit a star.", and some people do that to projects. We get the requirements to build a form to sign up to our newsletter (we just need email input and a submit button), but in our heads, we follow a process which goes something like this:

1. We need to validate the email
2. We need a function to validate the email
3. But maybe they ask us to add a name later, so let's generalize the validations with RegEx
4. Maybe RegEx is not enough, let's build a full validation library
5. ....

Been there? Sometimes what we are asked for is simple, and yes, engineer it right, just don't overdo it! You can make your code very hard to understand, not to mention the amount of work that you need to do ahead of time for requirements that may never come. Be smart about it, abstract when it makes sense, but keep your code focused on what you need.

4. Document & test your code

I'm sorry to be the one telling you this, but documenting your code is important, maybe boring, but very important. I'm not saying you should write a whole document of everything you plan to change in advance, but do the small things, use proper variable names, comment your code, write down the basic steps to install and run your code, etc.
Also make sure you test your code, start a culture for at least maintaining test coverage. If you add code, make sure it's tested. Testing could be a full section here, but for many is as annoying as documenting so I've decided to merge them together.

Remember, document and test your code, it will pay off as new people join your team, as time goes by without you working on it. It's one of those things you should just do it.

5. Never stop learning

In our environment the only constant is change, and thus we should change to keep up. To change we need to keep learning new things, new frameworks, methodologies, algorithms, techniques, etc.

Always be reading blogs, books, articles, or watch videos, participate in webminars, or trainings, no matter what your method is... keep on learning and practicing, it's the only way you will become better at anything, especially coding.

Conclusions

On your day to day remember the things that make you a better developer. You can use my list or make your own, whichever it is, practice your list every day, and grow your development skills. Introduce these practices to your team, agree on what's the best for your needs, and just do it!

Remember my steps:

1. Code for your future self
2. Let your commits tell the story
3. Go the extra mile, but no more
4. Document & test your code
5. Never stop learning

Thanks for reading!

Article originally published here