This is a series of articles. You can read the previous one here.
I'm awesome lucky. When I got a trainee job, I knew absolutely nothing. Around sat people whose conversations frightened me. Any, now primitive, term left a void in the eyes, and people who went to rallies aroused admiration.
I still remember my first rally. I phoned with our American partner, who used to live in our city and, as it turned out, was a longtime friend and partner. We discussed the project, mockups, I was told to think about UX and the user, and that the idea would be a breakthrough, but we need to work quickly. I went out of there proud and pleased with myself. After 4 months, the project was closed because Instagram changed the policy of providing access to the API, and I was transferred to another project.
Unfortunately, I managed to survive everything described below only once, but this time it was my actions that, as it seems to me, led me to a certain level of awareness and understanding of how to teach young developers so that my mom was proud of you deservedly :)
This and 3 subsequent projects turned out to be key in my career, I spent about 3.5 years on them. But all of them were united by several integral parts.
And the first important part. I considered myself part of the project
The first thing that a june should do, and indeed anyone, is to become involved, but not in the code, but in the project, as an idea. In each project, I was looking for something that answered me the question “why is this?”, “What problem is the client trying to solve with this project?”. But June is the most important thing, because good habits must be developed from childhood.
The answer to this question leads to discussions about the target audience, about their patterns of behavior and about what can be really NOT IMPORTANT for the client and user, and what can be wrong.
Example: If you are doing something for accountants and choosing between "excel cells" and some new, but slightly uncomfortable "fancy selectors", choose the first if you have the opportunity. Do not care that fancy selectors seem comfortable and beautiful. You are testing their flight day, you are just used to them. But your user is used to the cells. You may not know something, but if neither the client nor the designer can explain why the game changers will complicate the system, then this question should at least be voiced.
1. To do what is really useful, you need to understand the user. And for this, you need to understand the project
The second important part. I considered my work not coding, but a process of continuous improvement. This is creativity
At one of the projects, I got to people who didn’t really worry about how to seem “non-toxic” in the sense that they now put into this word, that is, to be friendly, even where it is not necessary, here's a great article About hypocrisy. Non-toxic hypocrisy . And I thank them for that. I closed the pullrequests for several weeks and received 100-200 comments. When one went on vacation and someone else connected to the review, I had to rewrite the decision under the wishes of a new person. I was commented on by a code that just fell into scope in the dip. Someone experienced will now think that this is an awesomely destructive atmosphere. And I will say no. Because everyone explained, each decision, each + to the same error. And this led me to the fact that by sending the code to the request pool, I followed the rule of "clean up after yourself and a little around." And also to the more important thing, which, in fact, is the next level to the developed rule - "refactoring is a daily process . "
This approach quickly taught me to understand someone else's code, I mastered several refactoring techniques, and formed my own approach to writing tests.
2. Clean up after yourself and a little around
The third important part. Your task is completed only when it was accepted by the client
Here, it would seem, there is nothing to write, but dozens of people I know forgot about their tasks immediately after the opening of the pull request. Some of them did not even change the status in the task tracker. And the point here is not in discipline, but in the approach to work. Whether you have a testing department, a product that UAT does, automation and all this other joy, your job is to finish the job. Respond to comments, analyze changes in requirements and place them in a separate feature / modify them, explain the behavior, suggest and describe how to test. The code should not and cannot be the only artifact of your work. Anyone can write code, these are the simplest semantic constructions. You don’t want to be anyone, but you want to be a pro. And the pros are responsible for their work and bring it to the end.
3. Your task is completed only when the client accepted it.
The fourth important part. The cost of the bug can be reduced and this is what MUST bother you
This item follows from the previous one. About six months later, they told me about the cost of the bug.
Below is a graph, the numbers are exaggerated, but that is not the point.
Take a look at the item that goes AFTER development. Self-testing. This is what everyone should do and get used to from kindergarten. I was flooded with staging, do not rush to move the task into the testing column. Check it yourself, at least a happy path. Convince that everything is taken into account.
There are a few points.
- The first is mercantile. The tester will spend time on a knowingly idle feature, spend time describing the redgection or creating a new task, will he figure it out?
- The second is ethical. The tester changes the context, reads the task, creates an idea of ​​what exactly needs to be checked and what else it can affect, prepares the data that he will need for verification, and ... bang ... nothing works. Simple, corny, the button should be green, and it is red. Such a task, kmk - spit in the face of the one who checks it.
- The third is selfish. What you do forms your brand and authority within the team. If you share nonsense, do not expect to be taken seriously.
You can talk a lot about the cost of the bug, but not here. It’s important to remember
4. The cost of the bug can be reduced and this is what you SHOULD do after your code is in any working env other than development
The fifth important part. Try before you ask
We were all taught this at school, at home and everywhere. But few have learned the lesson.
Via est gressibile steps, as they say. Respect the time of your colleagues, do not come to them with questions, without even trying yourself. From the very beginning I asked the most stupid Google requests, and for the most part I found answers there, at least close to what I needed. I did not always know how to apply them. They did not always work. But I searched for these answers myself. And only then, with answers, went to the "elders".
This allowed me to shape the context and add specifics.
- People work at work, mostly they are busy with cognitively complex matters and do not want to delve into the essence of your task. If you have not tried anything, most likely you could not localize your problem, which means that your mentor will need more thought fuel in order to give you an answer.
- Having a set of failed solutions you further reduce the set of possible answers. This will allow you to quickly get an answer to your question or, more importantly, to find out about the nuances of the work of those solutions that you could not get.
5. Come only with questions that you already have incorrect answers
The sixth important part. I read the code of everything I used if it was available.
How to find out about the nuances? How to find examples without leaving the IDE? How not to be distracted by finding solutions to your problems, which, it seems, should be solved by this method? Right! Read the code. RubyMine / WebStorm / VSCode - they all can jump into code. Not all, but many can jump into library code. I will reveal the secret, but most of the documentation is generated by comments on methods. This means that you don’t have to google the documentation if you can jump to defenition and just read it in your editor. You will discover the WORLD OF NEW SYNTACISIS, SYNTACISIS libraries. This is the first bun. You will discover the nuances of the work of methods and functions - the second. You will understand that you will not lose focus and will not be distracted, because you remain in the code editor - the third. Is this not enough?
6. Pick the source code of what you work with
That’s enough, really. Yes, I didn’t read books, for 5 years I read only one and a half technical books, watched millions of videos on youtube, read a bunch of articles. But all this I began to understand and evaluate the impact on my work much later.
And when I was a June, I just worked hard to work, the rest I was taught by experienced comrades.
If you want to chat, write to @_golubev .
I gave this section the name work & dev fun (damentals) . Because work and development is fun. But you need to learn fundamental things. It doesn’t matter whether it’s a soft skill or a hard skill.
Everything described below is the experience that I have gained. It is limited to my understanding of things happening in IT. The processes that take place here. The decisions that are made. This understanding allowed me from Trainee to one of their leads in a full-stack direction. In parallel, create a department that specializes in technical development and monitoring the emotional state of employees, in order to make their work comfortable and provide them with a concrete understanding of what is expected of them in the company and the project.