7 Habits of Great Developers

Today, I’m gonna talk about the difference between developers and great developers.

The difference between those is not the age or the years of experience. Not even the intelligence.

Steve Jobs said that to master a topic, you must spend more than 10.000 hours on it.

Great developers are self-made. Great developers have habits that lead them to improve every time.

Here are 7 habits I see in great developers.

Start Thinking, Not Coding

When given a task, I always start by investigating how to do it.

I never start coding the solution. Because, at some point, there will be a dead-end that makes me start again. Or the solution I though didn’t cover all the features. Or it’s incompatible with the current architecture.

I start by looking at the database, and the impacts on the schema.

Or I look at the HTTP requests, and what will change.

What new information do I need?

Then, I figure out which services or layers are impacted. Do I have all the necessary? Do I need to inject or create more services?

Once I have all clear, I start coding.

All this process is the difference between engineers and coders.

Coders produce code.

Engineers create big and stable projects.

Test All What You Write

Pushing without testing is a very bad habit. But, I see a lot of people doing it.

It’s trusting blindly all what you do.

Good developers ensure that all their code works perfectly. Not only on their machine but also once deployed.

This eliminates a lot of discussions like “it worked on my machine” or “i didn’t expect the other service to work that way”.

All this is wasted time. Because 10 more minutes of testing ensures a good quality product.

Teach

The best way to learn is teaching.

Teaching is like testing the knowledge against the questions of other people.

It’s a way to organize all the knowledge and make sure I really understand what I know.

There are many ways to teach:

  • small groups of trainings
  • writing articles
  • creating a small project with what I’ve learned

Book Time To Learn

The development world is one of the most evolving ecosystems.

You need about 20 libraries or frameworks per project. Each one has its cycle of releases. Alternatives to those libraries are created every year.

If you take a break of one year, you are already out-dated.

Book 30 min or 1 hour each day to learn. Or book 2 hours per week at once.

Go outside the project you’re working on. Explore new technologies, new frameworks or new versions.

How to learn? Reading articles is not the best way. Reading articles it’s a way to discover new things. But the best way to learn is to practise.

Create a small project. Try new things. Investigate alternative architectures.

Getting out of the actual project allows you to gain a new perspective. I’ve solved many problems in my Java project while investigating new things with Python.

Why?

Because going with another language shows how to solve the problems in different ways.

Surround Yourself With Experts

In my first job, we were all trainees. After 4 years, I thought I knew everything. Nobody around me could teach me anything new. We all had the same knowledge.

In my second job, I had a great CTO. The first week I learned more with him than the 4 years in the previous company.

In my third job, I was surrounded by 5 developers who had more than 20 years of experience. Even just talking with them while eating is a rich experience.

Now, I have a great network. I chat with a lot of highly qualified people. Each one with different points of view and different experiences.

Subscribe To Tech Newsletters

Not everyone has the chance to be surrounded by great experts.

Another option is to subscribe to those experts who write content.

There are a lot of newsletters which show different use cases and personal experiences.

They explain how to think, how to work, and how to build big applications.

Here are some newsletters I’m subscribed:

  • Kent Beck
  • Refactoring
  • Gregor Ojstersek
  • Dr Heinz M. Kabutz

Read Books

The development world evolves very quickly. What’s the reason to buy a book which will be outdated when I finish it?

The tech books that really matter are those which talk about ways of working, and ways of thinking.

Those are (mostly) old books which are still true.

The difference between reading an article about TDD and reading a book about TDD is that you finish the article in less than 10 minutes. 10 minutes to handle a topic.

The next day, you will only remember that you read about the article.

The next week, you won’t even remember what the article was about.

While the book, repeats itself over 600 pages. During 600 pages you will see different visions of the same concept. You will see different ways to implement the concept.

To take even more advantage of a tech book, I use Google Keeps to take notes. I create one note per book. And add all the parts which seem interesting. And after each chapter, I take an action on my life. It could be applying a concept, testing it on a personal project, writing an article or teaching to make sure I really understood what I’ve read.

Here are some books I highly recommend:

  • Code Clean
  • Clean coder
  • Java Performance
  • Designing Data-Intensive Applications
  • Working Effectively with Legacy Code

Conclusion

That’s a lot of work.

Don’t try to do it all at once every day. Do a little each day. Create a habit.

Focus on small improvements.

By the end of the year, there will be a clear difference between one who try to be a great developer and another who watches all the series on Netflix.

My New ebook, How to Master Git With 20 Commands, is available now.

Leave a comment

A WordPress.com Website.