We all went through (or will go through) the stage when we seriously decided to get a job in IT, prepared for some time, read the information, dreamed of success, and finally got a job in the first company. It is unlikely that you will be able to experience the same emotions again, because this is the moment when you receive your first money for what you did for the last conditional six months for free. At this very moment, someone may prefer stability, and will remain in this company for a fairly long time.
This is the third article in a series of possible mistakes that developers can make early in their careers. From this it follows that now I will talk about why such a solution could turn into a problem in the future.
Past Articles
A rough outline of future articles:
Early burnout
The importance of learning a language, but not a framework
When you stop being a junior developer
If you are interested in one of these future topics more than the rest, write in the comments, I will try to release it as soon as possible.
Disclaimer : This article is not an absolute rule and your experience may vary.
Let's first define the initial conditions for the emergence of the problem, which I will describe below.
This is your first job
You have been working there for a long time (1 - 1.5 years +)
You work with the same lead / mentor
You are working on the same project with the same stack
To put it bluntly, you got a job, and in general nothing has changed much for you during the time you work here. The problem arises the moment you decide to change jobs.
What is the crux of the problem, you ask? The first job and an experienced mentor have an extremely strong impact on a person. You don’t have time to evaluate every requirement, you don’t have any particular preferences, you have complete confidence in the senior developer and that’s okay. At some point, you get so used to some rules (or lack of rules) that the entire process of working on a task is automatic.
, , , . , .
, - , ? - . - , . , . , , - , .
, , - , . , , , , . workflow , , .
workflow , . , , , . , , .
, , - , , . , , . , - , - , , .
- . IT, . , , . , , . - , , , .
, . , , . , , - .
,
, . , , , tab
enter
( shift + tab
IT ). , , , , .
,
husky, . , ci/cd, , , , , .
, husky , push
, , , push
, .
- , , , - .
, , , . , , .
- - . , "" - , , . , .
: Vue, , . RxJS ( Angular, ).
, RxJS Observable, Vue, / .. . , , . , . .
, TypeScript ( JS). TS, 2- Vue , . , , any
. , TS - , . , , , - , .
, , . - , -. , , . , - , .
, , . , , "", , . , , , , .
- -, . , , , , , , , , .
, - , . , , UI/UX , . , , , .
, ( ) , , . , , .
. , , / . 2- , .
, , , . , / , , , . , .
, . , , , .
- “ n ”, , , , .
, , . , , . , , , , - . , , .
, , , .
, . , ( 3 , ), , . , , , , , .
, , , , , . . , , - .
If you have recently changed and are faced with rejection and negativity due to the new rules, then try to assess objectively whether this is not a desire to return to the old familiar lands, and whether what you think is right will be right. for the whole team? If you think so, then try to substantiate your point of view with practical examples, but also consider the timing and benefits of such changes and whether these 2 metrics are proportionate.
In general, in this article I also wanted to talk about the skill of product release, but there is already a lot of text, so I will talk about it next time.