The best piece of advice

"You have to read other's code to get the ideas how to write your code well."

At a time when you are starting a career as a software developer, you have a lot of concerns about how to write good code.

Everybody around you talking about complicated topics. SOLID and GRASP principles, Design Patterns, Object-Oriented design, Cohesion and Coupling, Domain-Driven Design, and the better or best way to solve problems.

Seems like everyone knows how to write the right code except you. Seems like only your solution can't embrace all the best software design principles and therefore isn't good enough. That only you can't remember all patterns and strictly follow them in your development. And only you can't get it right.

The good thing that all of this NOT TRUE!!! I've been there and know how things can get overly complicated when everybody wants to be a smart-ass and show off on the meeting or code-review. I name this process patterns-dribbling, and often it can ruin a constructive discussion in moments.

The best advice is to read other's code to see, in fact, what they're doing. To see that not all the code consists of solely design patterns composed in a state-of-the-art program or library. To see the trade-offs, mistakes, and compromises people are making in real-world programming.

That'll give you the courage and confidence to fight for your solution. That'll make you stand your ground and be able to explain what is the good and the bad in your code. Why do you make a trade-off, and what is the reason for a compromise. And I have to say that following the design patterns strictly may easily create unnecessary complexity in your code.

I do not hate patterns. But there are always the good and the bad parts.

The worst piece of advice

"You have to read other's code to get the ideas how to write your code well."

When you just starting out the carrier, you might or might not have a CS background. You could know the "Gang of Four" and Martin's Fowler books or haven't read a single page. Frankly, it doesn't matter much.

If you start reading the open-source libraries' code, it would be very complicated to understand where to look and what to see. The code might be much more complicated than you'd like it to be. Many parts of the code will be confusing. You won't be able to see clean design patterns as seen in books. There will be no more UML diagrams and no guidance.

You won't meet a single line in production code where class Dog extends Animal. Hotfixes, edge cases, patches, bugfixes, and real-world use-case scenarios can quickly transform the code into a mess. The experience of getting useful insights from such a code will be frustrating.

On the road to getting a senior developer, you will have your own experience with similar things. You will be familiar with production cases, you'll see a bunch of projects. You'd be comfortable working with any codebase. You will be able to see the good and bad parts of the code right away.

I wish that there were books that guide you through the real-world code. That highlights to you what's essential and what's not. That helps you to start reading the other's code as a breeze. Unfortunately, I do not know any such book to recommend. That's why I'm going to start reviewing different libraries. My goal is to expose and explain the best parts. I want to walk you through the design approaches and decisions taken. Hope this will help you to get a top-notch developer.

My advice is don't get frustrated if things don't make sense to you in the library code. Don't get frustrated if you can't grasp the new design pattern. You're not alone! You'll get it. You just need a bit more time. Everybody had the same battles while getting senior developers, tech leads, or architects. Everything will work out for you for sure!

Wish you the best of luck, Oleksii