Alors, c'est parti...
Tu termines actuellement ta première année (et crois-moi, rien ne changera dans un an ou deux). Mais en même temps, tu n'as pratiquement aucune connaissance. Et même lorsque tu auras terminé l'université, tu pourras espérer un salaire de 250, maximum 300 dollars la première année. On aurait du mal à te qualifier de junior, car tu connais très peu de théorie et tu n'as pas de pratique.
Tu connaîtras mal la théorie pour quatre raisons :
- C'est un domaine très vaste, et il est impossible d'en apprendre la totalité dans le cadre d'un cours.
- On étudie souvent du matériel obsolète.
- Pendant les cours, tu es probablement sur les réseaux sociaux, tu discutes avec tes camarades et tu viens juste pour marquer ta présence. Tu ne comprends que 30 à 40 % de ce qui se passe, et même si le sujet est facile et que tu retiens 80 %, tu ne le confirmes pas par la pratique après les cours, en restant devant l'ordinateur pendant ton temps libre. Lors des travaux pratiques, par exemple, je jouais souvent à Counter-Strike en réseau (tout en parvenant à faire tant bien que mal les travaux pratiques nécessaires pour valider les modules).
- Pour étudier et assimiler des connaissances, il faut un état d'esprit idéal, un intérêt idéal et un environnement idéal. À 8-10 heures du matin, il est peu probable que ce soit le cas pour n'importe quel étudiant, et en conséquence, le matériel est mal assimilé. Assister à des cours à l'université et regarder le même cours le soir à la maison sur YouTube depuis le canapé, ce sont deux choses différentes.
Alors, en fin de compte, tu auras plus de 20-22 ans après l'université. Tu ne sauras rien et ne maîtriseras aucune compétence. Dans le meilleur des cas, tu trouveras un petit boulot pendant ta dernière année et tu pourras y acquérir un peu d'expérience.
Est-ce que tu passes tout ton temps libre à te promener, à regarder des séries et à organiser ta vie personnelle ? Si tu te diriges vers le domaine de l'informatique, ce mode de vie n'est certainement pas fait pour toi.
Je ne suis plus à l'université, je suis passé par le collège et l'université dans des spécialités IT, et j'ai une compréhension et une perception complètement différentes de tout cela. La première chose que je te dirai, c'est qu'on ne t'y apprendra rien, et j'ai donné four raisons convaincantes plus haut. La deuxième chose, c'est que si tu aimes vraiment ce domaine, tu dois t'habituer à travailler sur toi-même et à t'autoformer. T'autoformer toujours et chaque jour. Il est rare que je passe une journée sans regarder ou apprendre quelque chose de nouveau (parfois je le fais en tâche de fond au travail), mais le plus souvent pendant mon temps libre.
Je sors aussi me promener tous les jours, et j'ai aussi une life personnelle, du sport sous forme de jogging et de football, ainsi que d'autres intérêts, hobbies et voyages. Il suffit de planifier son temps. Parfois, il vaut la peine de faire des plans pour la semaine, mais de planifier de manière à ce que quelque chose puisse changer. Et le plus important, c'est de t'habituer à apprendre... toujours et presque chaque jour.
Les programmeurs sont généralement des gens paresseux... Il est préférable d'apprendre à partir de livres, mais comme je suis aussi paresseux, j'écoute des podcasts et je regarde YouTube (et maintenant j'ai déjà atteint une bonne compréhension de la programmation, et il est difficile pour moi de trouver quelque chose de valable et de nouveau sur YouTube, mais je trouve toujours et je regarde, et de temps en temps je lis des livres). Donc, habitue-toi à t'autoformer chaque jour. Tu peux choisir des podcasts sur la programmation qui te plaisent et écouter les nouveaux épisodes - de cette façon, tu seras au courant des derniers événements et technologies dans le monde de l'IT en général.
Ne t'attends pas à ce qu'après avoir soutenu ton diplôme, quelque chose change... Que tu deviennes plus intelligent et qu'une entreprise t'appelle immédiatement pour te proposer un emploi ne serait-ce qu'à 400 dollars. Imagine simplement que tu as obtenu ton diplôme hier et que tu dois avancer.
Maintenant, en première (ou deuxième, peu importe) année, il est très important de comprendre ce que tu veux faire dans ce domaine. Puisque tu as chose la programmation dans l'IT, et non le SEO, par exemple, ou le design, il y a plusieurs directions ici :
- Systèmes (écriture de systèmes d'exploitation, de pilotes, etc.) - c'est de la programmation bas niveau, qui est, selon moi, un peu ennuyeuse, mais aussi complexe.
- Développement de jeux - ici, pas besoin de commentaires... Il serait bien de connaître la physique.
- Développement web — ce n'est pas si compliqué, c& says;est assez intéressant, mais je peux dire qu'il faut connaître énormément de choses (bien que cela soit probablement vrai dans d'autres domaines aussi).
- Développement mobile — je ne dirais pas que c'est compliqué non plus (il y a plutôt une subdivision en deux domaines : Android ou iOS, bien qu'il y ait aussi d'autres petites niches). Dans le web, il y a aussi deux directions : backend et frontend.
- Développement d'applications — écrire des programmes pour ordinateurs portables et PC — est également ordinaire en termes de complexité et d'intérêt. C'est généralement par là que commencent les universités.
- Développement scientifique — quelque chose de spécifique, axé sur un profil étroit et la science : que ce soit la biologie, la chimie, les mathématiques, etc.
Les plus demandés, selon moi, sont le web, les applications mobiles et les applications logicielles. À tout moment, tu peux changer de direction. Mais si tu es senior en développement d'applications, cela ne signifie pas que, en passant au mobile, tu seras aussi senior là-bas. Ton niveau peut descendre à celui de mid pour quelques années (dans le meilleur des cas, un an), car c'est a tout autre domaine avec ses propres recettes.
Les programmeurs ont également leur propre classification par niveaux de compétence :
- Junior — ne sait généralement rien faire, fait beaucoup d'erreurs. Toutes les tâches après lui doivent être vérifiées et éventuellement corrigées. Sans expérience de travail ou avec très peu d'expérience.
- Middle — un programmeur assez bon, capable de résoudre des tâches moyennes et parfois difficiles (algorithmes). A une expérience de 1 à 2 ans. Il connaît déjà certaines choses et on peut lui faire confiance.
- Senior — un spécialiste très compétent, qui sait tout ou presque tout. Expérience de travail d'au moins 4 à 5 ans. Parfois, il peut falloir plus d'années pour atteindre ce niveau (cela dépend des qualités personnelles de la personne et peut-être du domaine).
Encore une fois, en ce qui concerne l'expérience et toutes ces classifications, c'est tout relatif. Un senior dans notre entreprise à Minsk pourrait être seulement un junior chez Google.
On peut également distinguer le team lead (appelons-le chef d'équipe :) ). Il répartit les tâches entre son équipe, vérifie tout et effectue également certaines têches difficiles. Toute la responsabilité des tâches de son éq&uipage repose sur lui. En général, ce sont des seniors, mais ils peuvent aussi être de très bons middles.
Il y a aussi les architectes logiciels — ce sont des personnes extrêmement intelligentes, également des seniors, voire au-dessus (je n'ai pas encore atteint cet état de zen, donc je ne peux pas le dire avec certitude :)). Tout dépend du degré d'expertise. Par exemple, pour concevoir correctement une architecture dans le web, il ne suffit pas d'être un senior backend ; il faut bien connaître le frontend aussi — ce qui en fait déjà un développeur full-stack.
Ne prête pas trop attention aux gens qui vont te dicter leurs technologies et langages de programmation, en disant que celui-ci est meilleur que celui-là... Tout dépend exclusivement des situations et des tâches. Sur le marché, il y a un top 5-10 des langages qui ne changent pas et ne perdent pas de position depuis environ 20-25 ans (parfois, ils échangent simplement leurs positions entre eux si quelque chose de nouveau sort en termes de fonctionnalités, de mises à jour ou, par exemple, de frameworks pour ces langages, mais tous ces langages continuent de se développer). Je mettrai en avant les langages suivants : C, C++, C#, Python, Java, JavaScript et PHP. Parmi les plus récents, on peut citer Go, peut-être aussi Rust. Et les langages de développement mobile, comme Kotlin ou Swift — ces deux derniers sont vraiment relativement nouveaux (probablement environ 4-5 ans qu'ils sont activement utilisés) — il y a une explication logique à cela, car le développement mobile est l'un des plus récents par rapport au web ou au développement d'applications, donc des langages et des directions claires se sont formés plus tard ici que n'importe où ailleurs.
En général, il faut comprendre que les langages peuvent être fonctionnels ou orientés objet (il existe d'autres paradigmes), et il faut comprendre qu'ils diffèrent entre eux à l'intérieur... De plus, il faut se rappeler comment ils fonctionnent : quelque part c'est un compilateur, quelque part un interpréteur (mais ce sont déjà des détails). C'est super quand un programmeur comprend au niveau de l'asynchronisme, des processus et des threads, mais cela vient aussi avec le temps.
Ne prête pas attention à ceux qui disent, par exemple, que PHP est un mauvais langage — c'est l'opinion de personnes qui montrent leur ignorance et leur méconnaissance de la programmation (cette blague est venue à cause des mauvais codeurs, du faible seuil d'entrée du langage, ce qui est plutôt un avantage qu'un inconvénient, et parce qu'avant PHP était vraiment mauvais... mais c'était en 2000, au maximum 2007-2010. Maintenant, il est très bon, et plus de 70% des projets web dans le monde fonctionnent dessus (backend). On peut dit la même chose de JavaScript (il y a même une blague sur une prostituée et JS). Je ne l'aime pas non plus, mais je l'utilise souvent. J'ai aussi entendu des critiques à l'égard de Java et Python... bien que je pense qu'on peut trouver des blagues sur n'importe quel langage. Donc, tout cela est purement une question de goût.
So, once you’ve decided on your direction, I’ll try to explain, using web technologies as an example, why it’s important to start learning programming as soon as possible and why you shouldn’t rely on educational institutions. To become a cool specialist, you need to have a good grasp of just a couple of programming languages. In addition to languages, you’ll need to know a variety of technologies, protocols, and some general things that are necessary not only for web development but for all programmers. I’m not even mentioning the fact that you need to know algorithms, and it’s highly advisable to understand mathematical disciplines (from higher mathematics and probability theory to discrete mathematics and mathematical modeling). However, answering the question of whether mathematics is needed for modern programmers (unless it’s a specific job), my answer would be “no, it’s not needed.” In 80% of cases, the work boils down to taking data from a database and displaying it on a view (on the screen, to put it simply). It doesn’t matter if it’s mobile, desktop, or web development. Or writing data to a database. What’s more important is to do it correctly, according to some architecture. I’ll compile a list that would be suitable even for a good full-stack developer in the web (and frontend or backend developers)... it’s quite a massive list. But it’s necessary to know it. So, here we go:
Frontend:
- HTML5 (keep an eye on what’s planned for version 6).
- CSS (ideally, have a look at the drafts). Use selectors correctly (note that CSS works from right to left, and so on).
- Know at least one CSS framework and understand how it works (Bootstrap is quite suitable).
- Be familiar with CSS preprocessors (Sass, Less, etc.) — know how they work and be able to use them.
- Understand the basics of SEO — this is essential (know how to use HTML5 tags, know that you can’t place block elements inside inline elements, where and in what quantity to use the h1-h6 tags, etc.).
- JavaScript (starting with ECMAScript 6) — you can spend a lot of time just studying this language in its pure form... and there are still many points to focus on:
- jQuery (a very cool library... but frameworks are better).
- Frameworks (React, Vue, Angular).
- npm — a package manager.
- Build tools (Gulp, Grunt, Webpack) — they’re also needed for SEO, to ensure the page only receives the necessary styles and scripts and nothing extra.
- Master Emmet.
- If regular scripts don’t suit you, study CoffeeScript or TypeScript, or something similar. Then, don’t forget to learn Babel or another JS compiler.
- Search engine APIs and ranking algorithms (this is more for SEO). (+ AMP, Turbo, Yandex Zen).
- Layout (valid, cross-browser, modern, responsive).
Backend (I’ll use PHP as an example):
- Pure PHP.
- Content management systems (I’ve worked with many, but I recommend WordPress).
- Frameworks (Laravel, Symfony, Yii, or any other). The first two are the most powerful.
- PSR — standards on how to write code correctly, where to place quotes, where to put spaces (tabs), how to name variables, and much more.
- REST — this, like point 4, is a way to program correctly and name methods appropriately.
- Security. I’m not sure how much attention is paid to security, say, in mobile applications, but in web development, it’s often a big issue. And that makes sense, because the web developer’s best debugger is the browser. With it, you can get a lot of information about the page, and if you install certain extensions, you can even perform some rather useful manipulations. Therefore, in web development, you need to know how to protect against at least SQL injections, XSS vulnerabilities, and cross-site request forgery (CSRF) — though those aren’t the only threats (you can also include DoS and DDoS — but that’s more related to server configuration).
- ORM systems (Doctrine is suitable) and PDO.
- Console (I use it almost every day).
- Server setup (at least the basics, know how the server works and what happens in the backend during requests).
- Docker (it would be good to look into cloud storage solutions and pre-configured “containers” for projects). You might also want to know what Kubernetes and OpenShift are. Sometimes, it’s easier to rely on the cloud than to deploy a large stack of technologies on your own.
- Composer.
- cURL.
- Protocols — this point should have been placed higher, between points 4 and 6. But I’m not going to rewrite anything. You need to know how they differ and how to work with HTTP, HTTPS, FTP, SSH, and a few others.
- Learn to use an IDE like PhpStorm or good text editors (with installed extensions) — this also applies to the frontend.
- Linux — most servers run on this operating system, so it’s highly recommended to know it.
In addition, you need to understand object-oriented programming (OOP). There are functional languages where you can write an entire startup without a single class. But PHP (like most modern languages) is object-oriented, so it’s important to understand OOP. The deeper your understanding, the better (classes, interfaces, traits). It’s also good to know different programming paradigms. You need to understand that the same code in the same language can be written differently depending on the paradigm. Your project should adhere to one paradigm. This also applies to variable naming conventions, meaning you need to choose between camelCase or snake_case.
It’s important to be familiar with design patterns — I must admit that when I studied this at university, I thought it was the most useless topic. And I must admit that it’s the most difficult (for me). Every pattern can be interpreted in different ways (just in web development, there are several implementations of a single pattern. If you take a desktop application or a mobile app, the implementation might be slightly different). In short, it’s a topic that might seem vague. But it’s extremely important.
SOLID — this is how you write code. And SOLID isn’t the only set of principles. Incidentally, REST and PSR (which I mentioned earlier) can also be considered as principles of good code writing.
Testing is essential, including scripts and unit tests in PHP. But that’s the ideal. Personally, I hardly write tests... even though they’re necessary. You need to understand that there are different types of tests: functional tests, acceptance tests, unit tests, etc.
You need to master Git, Mercurial, or any other version control system.
Don’t forget to work with data formats: JSON, XML, YAML.
Get into the habit of keeping up with updates for the programming languages and technologies you’re working with. Programming languages don’t usually get updated very often, but sometimes there can be fundamental changes.
When I was in school, I thought that the problem of big data and code optimization wouldn’t affect me or would only do so much later. In reality, that’s not the case. I’ve been working for a long time with data that amounts to several tens of thousands of records. While a basic understanding of databases and table normalization helps me on the backend (where issues rarely arise), on the frontend, it’s more frequent. Search engines are extremely demanding when it comes to code, both in terms of optimization and performance (especially performance). Here, you need to understand how to make everything load asynchronously or deferred. You may have a perfectly crafted semantic core, but what’s the point if there’s no optimization for page load speed — so that’s something you need to pay attention to as well.
Write code correctly so that over the years (or months), when modules get removed (or disabled), there’s no leftover code in the project. This can, for example, happen in the frontend with CSS and JS if the code isn’t organized properly. I call this kind of code “dead code.” It’s unnecessary, but search engines will find it and complain about it.
At the same time, I’ve barely touched on databases... that implies that you already know how to work with them. Which specific databases doesn’t matter.
You need to be familiar with architectural approaches and application architecture... again, it differs completely: web, mobile, and desktop applications. For example, take a large web project: the backend consists of three parts. One’s built on Symfony, the second on Laravel, and the third on pure PHP. The frontend, for instance, consists of two parts built with React and Vue. If you delve into any of these parts, there’s its own architecture and its own patterns — both large and small. You need to break large sections of code into layers (for example, wrap models in repositories and access repositories instead of models, use observers, etc.) — this makes the code elegant and the application modular and easily extensible. But at the same time, remember that the thinner the layer, the faster the application runs (for instance, don’t use ORM systems between the database and the language where plain PDO would suffice). Understanding all this comes with experience.
Another very important point: you should use frameworks (at least in large projects). Writing with frameworks is usually more complex than writing plain code. But frameworks offer several significant advantages:
- They accelerate the overall development of applications.
- They impose a certain style and philosophy that you’ll adhere to, which reduces the amount of bad code you write.
- There are many ready-made modules (for instance, for authentication), and you don’t have to worry about how they work under the hood (be it basic authentication, token-based, JWT, or something else).
- Security. As I mentioned earlier, security is a problem in web development that requires considerable time and effort. Frameworks often handle that for you.
There’s an opinion that a full-stack developer is always stuck at the middle level. I partially agree with this, and I dedicate a lot of my free time to learning and self-development so that this statement doesn’t apply to me and so that I can create good turnkey projects on both the frontend and backend — without errors and using something new and fresh.
I may have forgotten something, as it’s hard to keep it all in mind. Oh, and I’m not going to talk about English... the better, the better.
You don’t have to learn both areas right from the start; you can focus on one.
And remember: if you think the code you wrote last year is poor quality and that you could rewrite it better, it means you’re thinking in the right direction and evolving.
Now, I’ve described web development... I may have forgotten something... but believe me, this covers about 90% of what you need to know to be a good specialist. On top of that, studying all this can take years.
As you can see, I primarily use only two programming languages, but besides those, as I mentioned earlier, there are many other tools that are really necessary.
As for other areas of programming, I don’t think anything will change drastically... each has its own technologies and languages... but the principles and scope are roughly the same.
Not everything I study (especially if it’s something completely new or complex) is understandable to me from the first time... it often takes reading and reviewing several times to fully grasp how it works. So, don’t get discouraged if something isn’t clear at first. Much also depends on the source presenting the material (some authors and speakers explain it better than others).
Now you know what’s ahead, and there are only two options: take the document right now or start learning programming today.
There’s a lot of terminology here that’s extremely difficult to understand, even for a second or third-year student, but it’s all out there on the internet. Now you know where to start and what to study. This list can be considered a mosaic, where each item is just one piece of the puzzle, and as you master something from this list, the overall picture of web programming in your mind becomes a bit clearer and more accurate. Perhaps this confusing list will help point you in the right direction, but it already exists. When I first started learning all this, I had to scour the vastness of the internet and books for the smallest puzzle pieces through trial and error, filtering out a vast amount of unnecessary and repetitive information.
In conclusion, let’s outline the profession of a programmer.
Pros:
- A promising profession. A good specialist will never be out of work.
- High salary. But not right away.
- Working in IT keeps you in touch with the latest events in the field.
- Often, a more flexible schedule than in other industries. The possibility to work not only convenient hours but also remotely from other countries.
Cons:
- You need to know a lot. It’s necessary to constantly upgrade your knowledge and use up-to-date methodologies and approaches.
- English language skills are strongly recommended.
- Negative impact on health. It’s said that it can harm your eyesight. Programming is a sedentary lifestyle that needs to be balanced with sports or other active hobbies.
- High responsibility (for example, when working with banking and financial data).
- Sometimes, it’s difficult to find common ground with clients and managers.
