I wanted to get into development for a long time, but, as often happens, I didn't really believe in myself. I believed that my train was long gone, and the brains were no longer the ones to master this difficult profession. Fortunately, I was persuaded, moreover, they gave me a chance to prove myself and took an internship in the development department. It happened so casually and simply that at first I could not believe it. All the time it seemed to me that now everyone would finally understand that I was an ignoramus and wave their pen goodbye. But this did not happen, they continued to support me, and I tried my best not to let anyone down.
I am an intern in our backend department, which deals with tracking products, and at the same time I work in my own department of technical integration (for 6 months now). The main language in the team is Python . I taught him on my own to get an internship. Basically, of course, on manuals and videos on the Internet.
I had a small base - I wrote several training projects in C, but in general I cannot say that I was at least a somewhat experienced coder when I was accepted for an internship. From the height of this humble experience, I would like to tell you about a couple of things that I did not know or hardly knew at the start.
Teamwork with Git
When a person comes to his first internship, he imagines what Git is (otherwise he is unlikely to be taken at all), but he has little idea of how they work with him in a team. We all created an account on GitHub at one time and happily committed the first line of code to the master branch, feeling like real pros. So: this is not the best approach for large projects.
In team development, work with Git is carried out in accordance with the approved git-flow . For example, we have two branches: develop and master. Nobody, except the team lead, can upload code to the master branch, because the team must ensure that there is working code there that will not destroy the production when deployed. The responsibility for this will fall on the shoulders of the team lead, and no one wants to make the team lead angry.
To prevent such situations, there is a team review. Each developer works on a task in his own branch and at the end of the work puts a merge request in the develop branch. And the team lead already puts the merge request in the master branch and is responsible for the quality of the code to its owner. Thus, the purity of the code that ends up on the production is guaranteed, and the risks of pouring something that will ruin the work of the project are minimized.
Takeaway: If you want to better prepare for teamwork, read up on git-flow and start adding new commits to your pet project via branches.
Code architecture is important
When I came to the internship, I expected to be told what to do, given some small function or unit tests, and I would work on them under the supervision of the team.
However, everything turned out differently. No, no one instructed me to do something ultra-complicated, but I was assigned a mini-project (milestone) for monitoring (Python + Prometheus + Grafana ), which I had to do during my internship. Moreover, I myself had to think over the architecture, decompose the project into tasks and move it through the Kanban stages. It was exciting, but very correct. This approach allowed my curator and myself to clearly understand what my problems are and to start fixing them.
To be honest, my first decision was unsuccessful. And the second too. I did tasks that were too large, returned them to the backlog several times, built an unsuccessful architecture and could not take into account the nuances.
However, at the moment, most of the project has already been implemented, and I am becoming more and more aware of how my code affects the rest of the project. It's exciting. I read several articles on clean architecture, studied abstract classes, learned how to plan an interface first and only then start implementation. I can't say that I figured it all out, but I definitely understood the phrase "Any problem can be solved by introducing an additional level of abstraction, except for the problem of an excessive number of levels of abstraction." And I also learned how to correctly assess my strength (but this is not accurate).
: . , , . , Netflix, . , .
In our company, all services are launched in containers. Accordingly, each developer should understand how the same Docker works , how to write a simple Dockerfile, or raise their services through Docker Compose .
For a person who writes only for himself and on his computer, it is difficult to understand why containerization is needed. However, on large projects it is necessary to ensure that the code works regardless of the environment. A little later, when you figure out the basics, it will become obvious how convenient it is. You do not need to install dependencies in your environment, there is no need for a long and difficult project launch. You can run tests or separate pro and dev by just writing a couple of configurations once.
The same advice can include working with the IDE. Before starting the internship, I wrote all my programs exclusively in Emacs, but when I started working, I decided to switch to a more advanced tool, and in the end I did not regret it. In some places I still prefer to use the console (for example, it is more convenient to omit all containers through
docker stop $(docker ps -qa)), but otherwise I am grateful to the Git GUI and tips in PyCharm.
Conclusion: read about Docker. Try to run your code in a container. Try an IDE for your language and see what it can do for you.
Documentation and tests are just as important as code
My curator once said that tests are the second developer's documentation. And this is very true, because if the actual documentation is lacking, you can always go into tests and see what behavior is expected.
Before the internship, I used UnitTest and PyTest, but only as part of my training. And Mock , for example, did not use at all, because my projects were not so complex that it was necessary to replace data (well, or my tests were so bad).
I would recommend all novice developers to write tests for all the logic that occurs in the project. Even if you think the behavior is obvious, it's best to play it safe. After all, when another person writes a function that uses your code, there is a chance that he will not go into details and it is your failed test that will save the project from trouble.
And to further minimize risks, write clear documentation. In Admitad, a method or function without documentation will raise questions for review. Two weeks later, no one wants to waste time trying to figure out someone else's code again. It's just a matter of respect for colleagues.
In addition, I will say that we also annotate types in detail in Python, but if you write in a strongly typed language, this comment is not for you. (Using a linter like Flake8 helps a lot in this regard ).
Conclusion: Pay attention to tests and documentation. Start with a regular Git readme - describe how to run the project, what it does, and what you expect. Try writing tests for key methods and functions, or better yet, make Docker Compose that runs all tests.
What experience did you have?
To established developers, my advice may seem trivial and obvious. I understand you perfectly, but at first I was badly lacking in system knowledge. I am sure that many of those who mastered the profession on their own faced this problem.
Therefore, I encourage you to share the experiences and observations that you have learned after the first months (or years) in the industry. What advice would you give yourself at the start of your career? What skills would you recommend to develop? Both me and other self-taught people may need your tips, so feel free to leave comments.