Introduction

As a junior developer, when we think about training we usually focus on learning all the technologies and programming languages that exist. Indeed, we think that knowing as much technology as we can makes us more valuable on the employment market. Of course, it is not completely wrong as you will able to cover a wider spectrum of knowledge making you “available” for a lot of projects. Yet, in my experience, I would say that, this is not the smartest or most optimized choice.

My name is Dorian Frances, I am a Software Engineer at Symeo for almost a year now and I will explain to you, through my personal experience as a junior developer, why you should focus your training on learning good development and architecture design practices instead of technologies and programming languages.

Betting on your carrier

I told you that knowing a lot of technologies could be an advantage on the employment market and that is true. The question is: Is it worth spending that much time trying to learn all those programming languages theories instead of the fundamentals of clean architecture and clean code ? You learned 5 different technologies, that’s good, but will you use them in your projects ? Maybe or maybe not.

With code architecture, you don’t even need to ask. There is code design in every single project. When you were at school, before a test, did you prioritize learning potential questions or those that you were sure were in that test ?

Finally, profiles with good knowledge of architectural design are increasingly sought after. If the code that a developer produce do not fit great architectural conventions or code quality, it will need to be reviewed, slowing down the delivery of a project. Depending on the progress of the project, that could cost a lot of money and companies start to understand this.

A technical learning logic

By this title, I mean that it makes more sense to learn good architectural design practices before focusing on learning too much technologies and I’ll explain why.

First, by putting architecture design aside, you will pick up bad habits without even knowing it and that is natural. Even more if by misfortune, your first companies are not cautious about good practices. And you know how hard it is to forget our bad practices right ?

Also, do not forget that technologies and programming languages are tools. And like all tools, they should be used to serve a greater purpose: your project. You wont contradict me if I say that it is preferable to understand when and why we should use a tool before starting to use it, right ? How could we possibly know which tool to use in order to build a house if we do not know how this house will look like, the layout of the different rooms, its toughness ? IT projects are exactly the same, the architecture of your code is the layout and plans of your house, the technologies, your tools. You may be hired inside a company to take care and develop only one part of the code base but as a developer, you are responsible of the entire project.

👉 This is a fundamental key of a concept called agility.

Finally, you may ask yourself : “but what if I am being assigned a mission that requires the knowledge of a programming language that I don’t have” ? You are right, that can be unsettled. Yet, I’ll respond to you: once you understood the code architecture, the learning process of that programming language will be way more efficient. Indeed, you may not understand some part of the code but the simple act of understanding why this part of the code is here, you will know what it should do. And this, will help you out.

A business challenge

Nowadays, a good developer cannot ignore the close link existing between tech and business (at least if you want to be part of a promising project). Learning to understand quickly the structure of the code base will help you to assimilate the business of your company. Also, educating yourself to concept like Hexagonal Architecture or Domain Driven Development is an efficient way to learn how to spot features that need special attention.

👉 Disclaimer: all the code that a developer writes needs to be worked on but for features that do not bring significant gain, your company might as well invest in tools that has already been created for.

Arriving in a project with understanding of the entire architecture allows you to have a more enlightened vision on the decisions that are made and you will only be happier inside the company.

Personal experience

Before arriving to Symeo, I was on an internship as a software engineer inside a company not very cautious about architecture design and good development practices were not implemented. Therefore, each time I was trying to develop something, I ran into questions like: “Where should I put that code ?”, “How could I make this work without breaking everything ?”.

At this time, I didn’t even know tests existed. I was slowed down in my work by not knowing the key concepts of code design and architecture.

When I arrived at Symeo through another internship, my mentors taught me a lot about those concepts. They prepared a list of resources (videos and articles) talking about clean architecture, code quality, testing, craftmanship… We also did some sessions of pair programming which is an efficient way to learn as the feedback loop is very small !

Simultaneously, I was working with them on our first product, on the backend side, coded in Java. For your information, I had never coded in this programming language before, but as the code was well structured, well arranged, I could learn faster.

We then, changed our product (the backend was still coded in Java) and you know what ? It was not that hard to work on this new project. The business was not the same, neither were the issues and yet, the structure was not totally unknown to me ! Thus, the business might have changed, our way of working did not allowing us to deliver quickly.

Finally, we started another project which was coded in Typescript with NestJS as its framework and for me, back to an unknown programming language. Still, I was not completely lost as we continued to apply good architectural and code quality practices. It not only allowed me to learn the Typescript language, it also taught me how to use it well.

Conclusion

Trying to learn about a bunch of technologies and programming languages is not a bad things, on the contrary, it reflects your will to progress. I wrote this article from the point of view of a junior developer based on my experience. We only talk about priorities here. If you ask me, i would say that starting from general issues and going to the specific ones is the best and most optimized way to learn.