I wanted to get into development for a long time, but, as often happens, I didn’t really believe in my own strength, because I believed that my train had long gone, and the brains were no longer the ones to master this complex 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 almost did not know 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 has already put the merge request in the master branch and is responsible for the quality of the code before 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.
Output: 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 assigned me 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 to correctly assess my strength (but this is not accurate).
Output: be interested in the architecture of the code. It’s okay if you don’t understand right away, it’s a matter of context. Read how designed Netflix, or take a look at website Martin Fowler. Try designing a small system before you sit down to code.
Ability to work with the environment makes life easier
In our company, all services are launched in containers. Accordingly, every developer should understand how the same Dockerhow to write simple Dockerfile or raise your 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’m grateful Git GUI and tips in PyCharm.
Output: 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 my internship, I used UnitTest and PyTest, but only as part of my training. AND Mock, for example, did not use it 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. (In this regard, using a linter helps a lot, for example Flake8).
Output: 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 your 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.