The journey of becoming better in any profession is tough. Mastering requires time, dedication, focus, and choosing the right learning directions.

In this post, I will describe the approach that I use in my journey to become a better software developer.

I want to be honest: this post doesn't contain any shortcuts or tricks. Because generally there are no shortcuts to success.

What's more important, you will understand the importance of choosing the right directions.

1. Shallow knowledge

Probably the most difficult stage of becoming a software developer is the beginning. If you've just graduated, you have about 5-10% of the knowledge required for writing real-world applications.

I was lucky to get a job while studying at the university. Anyways, a few years I struggled because of web development shallow knowledge. It allowed me to keep my job, have income, but nothing more.

Something wasn't right. I felt a lack of deep knowledge. But the idea that things were ok made me agree with the level of knowledge I had.

Somehow, everything went well enough until the team I was working with got a big web-based Java project (for a Romanian government agency). The application used Java on the server side, JavaScript libraries and HTML/CSS on the client side.

As usual, my team was productive at the beginning. But as time passed by, the functionality of the application grew, and the shallow knowledge of the whole team (including myself) started to manifest itself.

After about 1 year in the project, it was increasingly hard to add new features. The bugs were manifesting themselves too often. I remember myself hours and days just fixing bugs. Eventually, the project failed.

Not that I didn't want the project to succeed, it was the opposite. But I concluded that the shallow knowledge, lack of deliberate learning towards the programming language and tech stack are the source of the problems.

I decided to dig into Frontend.

2. I started digging

The first thing is to understand better the programming language you're using every day. In my case, it was JavaScript.

I didn't want to waste my time on superficial learning. I decided to dig as deep as I can.

A good book I found on JavaScript was "JavaScript: The Definitive Guide". It took me more than 6 months to dig into JavaScript specifics, try every code snippet, re-read multiple times the difficult parts.

I solidified more my knowledge using YDKJS series.

Then followed "CSS: The Missing Manual". CSS is known for its property for being hard to master. That's true!

While moving slowly in understanding JavaScript and Frontend stack, often I felt a huge relief. The concepts I've been struggling so much time in the past are now so easy to use.

Overall, did I get the results I wanted? Partially.

I knew how to use efficiently the programming language. I made lots of performance optimizations. I wrote better applications by applying my Frontend knowledge. But still... I was missing something important.

The problem manifests itself by increasing difficulty when adding new components to the application. I felt like I was thrown back to the beginning. It was a bit disappointing.

Turns out, if you dig too much into low level implementation details, you don't develop a vision of the whole picture. You cannot efficiently design functions, classes, and components that are well structured and loosely interact with each other.

Ok, I have to climb through the abstract principles of good system design.

3. I started climbing

Again, I've decided to read a detailed book on how to organize efficiently the system components.

The problem with abstract principles is that they are... too abstract. The brain cannot visualize them, cannot attach them to something material. You might read about a particular principle (e.g. Open/Closed Principle), but when exactly to use it within your application?

I've started my journey of climbing by reading "Clean Code" page by page. It provides a good grasp on how to structure your functions and classes, how to make them focused on a single task.

Then I've continued my journey by understanding coding recipes: the design patterns. I particularly enjoyed Pro JavaScript Design Patterns.

Again, it wasn't enough for me. The next book "Clean Architecture" wasn't easy. I didn't want to miss any detail, so I read the book page by page for about 1 year. At least for me, understanding the principles of clean architecture is hard.

I repeat the principles of good design (SOLID, DRY, SoC, etc) over and over again. Having them always circulating in my head while coding helps to identify the places to use them.

The next altitude I want to conquer is "Software Architecture in Practice" book and understanding Domain-Driven Design.

Step by step I work out the ability to see and fix structural problems before they get into the code. Or even if they get, refactor until I have better structuring. Slowly I master how to write better applications. I like this feeling.

What defines a good software? The software that is soft, i.e. easy to change, reuse and maintain. That's the main lesson I learned from climbing good design principles.

4. Conclusion

The journey of becoming a better software developer is long and challenging. There are no shortcuts. Who said is going to be easy?

Shallow knowledge lets you stay in your comfort zone. But the disappointment of writing crappy code is worse than the comfort zone pleasure.

To become a better developer, dig into learning the details of your tech stack. It makes you productive at a low level.

At the same time climb the abstract principles of good system design. They're harder to master, but they don't change often. Good design principles make you productive at a high level.

As long as you're striving to become better, digging and climbing never ends.

The books I've chosen for my journey might work for you or not. That's ok. Choose the ones that you like, and go for it. The sooner, the better!

What approach do you use to become a better software developer? Please write a comment below!