Last year I had a conversation with our Lead Dev with the main aim of hearing his story; no reviews or pull request here, just gist. It was very interesting to hear about his university days, how he managed school and coding, and so on. The proper title for this would have been a "letter to a JUNIOR engineer" lol... well I would just tell you some of the things he said and pass across my own two cents. Most times when you meet someone that has more experience in an industry where you work, some of the questions you always ask is how did you manage? how do I become like you? how do I move from here to there?. For me I knew I had to be more technical, before this meeting I had worked a bit in a codebase that he wrote; it was an API written in PHP without any framework 🤯 . I was marveled by the structure in the code; Design patterns, and Strategies plus how he managed to abstract and implement solutions for the problem at hand.

So when I asked him how he was able to organize and implement solutions in this very readable and efficient way. He replied simply: "read code". Yeah, it is that simple 😶

Watching videos and reading books is not enough. It is true that in videos and mostly in books you see a lot of these patterns and implementations but most times the author does not take care of all the cases or it is just very theoretical that you doubt if this is even usable.

However, reading other peoples code gives you the different views and implementations to solve problems and he also mentioned that frameworks are certified codebases (if there is anything like that), many of them are open-sourced and are written by experienced engineers so it is even easier for instance to read the laravel codebase and see how things were done, there is no better model than these.

In a book I read recently, "Software Developer Life: Career, Learning, Coding, Daily Life, Stories" by David Xiang he talks about having "code sense". He explained that this sixth sense comes with time, and it’s something we as software developers are constantly developing. It is the first impression you get when you look at a file. It’s the ability to spot bottlenecks and pinpoint vulnerabilities early. It’s being able to thoroughly fix a bug once and for all. It’s avoiding nonsensical dependencies, recognizing subtle side effects, and much, much more. This code sense originates from writing and reading a lot of code. The more code you write, the clearer it becomes and the more code sense you accumulate.

All code will always reflect the code writer’s commitment. How do you personally develop a baseline for this? You start by practicing this commitment yourself. We must care about the code we write—it is our craft.
There are two benefits here. First, your baseline as a  developer rises—you will write better code, faster. Second, you will  naturally recognize sloppy code and your code sense will strengthen.  Your attention to detail is what sets you apart - David Xiang

One other important thing we talked about is the controversial decision to stick with one language or to test out a lot of languages; well this depends but I would summarise the most relevant ideas. First, it is encouraged that as an engineer you have a language you are proficient in or in simple terms a language you are very comfortable writing. Furthermore, because no language is perfect, other languages allow you to see things from another perspective and could even be a good way to improve or learn new concepts that would better your technical skills.