Frontend Church by Anton Medvedev

I will be fired #mindset #career #onboarding #psychology I have worked with dozens of students and often heard it in a variety of formulations: “I will not pass the trial period,"  “I am weaker than the rest of the team,” and many more variations. To be honest, I don't believe in it. In most cases, newbies work so hard that they are not in danger of even the slightest complaint from the manager. In the majority. Not in all cases. Okay, let's say that this really happens, as a rare exception. Even so, it will not be the fault or responsibility of a beginner in any of the cases. To prove this, I only need two questions. “Why did this happen? and “What happens next?” Why did this happen? The team is not satisfied with my skills This is the team's problem. Abilities are tested in interviews. If the interviewer did not prepare well and did not test your skills, this is the company's problem. Many of the skills, by the way, are very subjective, and the eternal debate “whether a programmer needs algorithms” has been proving this for years. The team is not satisfied with my productivity Productivity requirements are very subjective and vary from company to company. A specific developer can complete all tasks in one company in an hour a day and in another in ten; that's how big the difference is. I am not satisfied with the team, company, or project Then the dismissal will only be a plus. You won't have to burn out by forcing yourself to work in unpleasant conditions. Isn't it wonderful? What will happen next? The same thing No, that won't happen if you learn from your mistakes. You understand the rhythm of the company's work and the general mood after an hour of interviews. You know what HR's slippery phrases really mean. You know too much to step on the same rake a second time. I will have to look for another company Yes. And that's great. By brute force, you will be able to understand your own desires and find a company in which they will be satisfied a little more than completely. Overall If you get fired, that's the company's problem. And it is necessary to leave problematic companies as early as possible. You'll take it as a negative experience and become a better person. But, most likely, they won't fire you. Relax.

Seniority criterias #mindset #industry #career No one can say for sure what the difference is between junior, middle, and senior specialists. Ask a hundred IT specialists, and you will hear a hundred opinions. All descriptions will be ephemeral, the boundaries will be blurred, and the theme will remain holistic. The concepts of grades are so vague that almost any specialist can call himself a senior, and people around him will not doubt him; they will accept this self-assessment as a fact. But it will be possible to create an impression and deceive others only with fleeting contact. In fact, there are some distinctive properties. They manifest themselves in the long term; they are appreciated by teammates, managers, and even young, inexperienced students. And no, these are not the usual socially approved qualities like empathy and sociability; everything is a little more complicated here. Let's go through the list. Ability to navigate in chaos Based on his knowledge, senior is able to work at times when there is no accurate information about requirements and resources. Imagine the task: to make a CMS for everything at once, design on a napkin, the deadline is two months, and the team is two people. Now imagine a person for whom this task is difficult but still doable. Will you have any doubts about the height of his experience and skill? Flexibility and goal-setting Senior developer selects solutions to problems based on a variety of circumstances. For example, if deadlines are limited, he will not waste time following best practices. If not all the specialists in the team have the same skill set, he will not implement complex architectural approaches and force everyone to teach them. For him, all libraries, frameworks, approaches, paradigms, languages, and platforms are just tools. He has no preferences. There is only one task and thousands of ways to implement it; it remains to choose the most optimal one. Predictability and responsibility Everything is simple here. A cool specialist for business is a good investment. And this investment should be predictable. For his billions per month, the specialist meets the deadlines, knows how to manage risks and resources, and in general does not create risks for the product out of the blue. Any business needs a person who says, “I'll do it in two weeks” and does it in two weeks. Watchfulness Do you feel something in common between all the previous points? To know the progress of development in advance, you need to know the features of typical projects and the differences between them. To choose a solution for a situation, you need to know the solutions and the differences between them. To predict the progress of a task, you need to know the tasks and the differences between them. Watchfulness helps to know a lot and see the differences. And this is the key difference between a beginner and an experienced developer. Bad news. It will not be possible to find it in an extremely short time; there is no extremely short way here. Good news. It is also not necessary to go through dozens of projects, and you can squeeze out experience much faster than in half a lifetime in IT. I'll tell you exactly how later. Stay tuned.

Code will not be beautiful #frontend #business #codequality #mindset But it’s almost always applies to the frontend. By frontend, I mean not only the web, but also mobile and desktop applications. Because, let's be honest, the iOS and browser apps are sets of pages and screens, and the end user doesn't care what language they are written in. And now, after all the disclaimers, to the point. The frontend is the end point of development, it directly depends on business requirements. When a customer requests a product, it is the application that they want to see. Exactly what will accomplish the task. Not a set of endpoints, not layouts, not test cases, but the result, the final application. He kind of doesn't care about the implementation. And from this direct dependence grow the roots of the crooked strange code. If the requirements are unusual, then their implementation will be unusual. Questionable terminology, but I'll explain everything now. Ordinary applications differ from unusual ones in the entities and actions that can be performed with them. It is easy to work with texts and numbers, but not always with media and geodata. Viewing an entity is easy, editing is definitely more difficult. But it is for the frontend, on the backend, that everything is just a set of controllers and services, from the point of view of execution, almost identical. Real-life examples. A video editor cannot be made exactly as clean and simple as a list of articles. A flight map will clearly be a more complex task than a photo gallery. Etc. I have described the pattern, you understand the idea. And it seems that this should not be the case, that programming works on layers of abstractions, that there is a library or framework for any task. Yes, but there is a caveat. Business requirements are often too detailed to allow the use of off-the-shelf solutions. For example, all news sites simply publish texts, but sometimes articles consist only of text and previews, sometimes they contain media content, and even less often special materials have thematic design. In sum: it turns out that the best thing we can do in the face of volatile non-standard requirements is to use tons of libraries, but they will be strangely intertwined flowing abstractions. This is the "ugly" code. But that's how it should be. There is nothing catastrophic about this. Welcome to the frontend. It's going to be bad, but that's the way to go.

IT is an intermediate point in a career #career #lifestyle #mindset #timemanagement I entered IT on my own. For me, this is my favorite activity, earnings, and creativity. To put it a little more pathetically, fate and destiny. At the same time, I am well aware that the situation is different for most people. For example, almost all my students roll into IT for the sake of money, and I help them with this. But I must warn everyone who does the same: you will not be able to work in IT forever; this industry will become just an intermediate point for you. Any person has a lot of needs, and when one closes, another inevitably appears. There are many of these needs; you can immediately recall a dozen of them, from self-realization and manifestation of creative impulses to basic communication with people. And, without a choice, it is impossible to engage in activities that satisfy only one of them for a long time. And now back to IT. People come to do programming, design, and management solely for the sake of money, but they still need other things. And there is a conflict in the truest sense of the word—a mismatch of desires with possibilities. The activity begins to either bore or even annoy. I've been through this myself. I know people who have been through this or going through it right now. And the only solution to this problem that I have found is to prepare. To perceive working in IT as an intermediate point in your career. After employment, you will have to go into management, entrepreneurship, mentoring, or media sphere—somewhere, but leave. And it is worth preparing for this in advance. Do not burn IT money for entertainment, but invest in your own development. Do not strive for endless professional growth, but constantly look for new activities. And you definitely shouldn't hope for a simple, predictable path to IT for the rest of your life. To the question, “Who do you see yourself as in 5 years?” I began to respond with “a winemaker, a brewer, a playboy, a philanthropist.” Try the same way.

Not everyone can be a programmer #mindset #career #industry #psychology There will be no gatekeeping, only couch analytics mixed with personal experience. The work of a programmer is an intellectual activity (here could be your joke about frontend monkeys). De facto, this means that each task is unique, and there is no specific algorithm for solving it; it will have to be worked out. The context of the task adds additional complexity because it does not exist in a vacuum but in a project (fragile, delicate, and sensitive). That is, for the sake of each problem, you have to not only think with the brain inside your head but also dive into context. Okay, this is a property of all intellectual work; it can be applied, for example, to doctors, managers, and engineers (the classic ones who touch hardware with their hands). And something else is unique for a programmer. Continuous studying. The IT sphere is changing rapidly, which forces all the participants to move at the same pace. In other professions, there is also an opportunity to study advanced approaches and improve skills, but this is just possibility. And for a software engineer, there is no possibility; there is a necessity. It turns out that the programmer must constantly gain knowledge. And it's a great source of fresh, unfiltered stress. Not to give up on difficult tasks, not to stop professional development, not to abandon projects in such conditions—only stress tolerance will help. I consider this feature to be the only important and necessary one for a developer. There are other criteria, but there are always arguments against them. I've seen programmers without a degree (I see one in the mirror every day), without a mathematical mindset, without knowledge of algorithms, and without all this snobbish nonsense. But I have never seen a successful programmer get disappointed, lower his hands, and give up.

Relationships are unproductive #lifestyle #productivity A big statement, right? I hear it from many IT specialists, in different forms. In its expanded form, the opinion sounds like this: Relationships take too much time and effort. And it will be more profitable to spend these resources on career growth and professional development Above, we are talking about romantic relationships—about the most vulnerable, controversial, and infinitely deep topic for dialogue. That's the first thing that comes to mind when you say the word "relationship." But, roughly speaking, whether they are friendly or related, the essence does not change. It is irrational to waste time on loved ones. That's the idea. A mundane example. Most likely, you have had a situation where you have to spend several hours on one date, and this “several" is sometimes a frightening figure. So much that you don't really want to make the next date. Because it seems that it is better to spend a conditional six hours of work on a catastrophic number of useful things. Learn a new tool, complete a work task, write a post on a niche IT blog, and so on. But I have a few questions for people who think so sincerely. Do you really spend all your free time productively? To be honest, I don't believe that people with the opinion in the headline are able to spend literally every hour usefully. I don't believe that you can work with your head twelve hours a day and do it for weeks, months, or years. In my practice, no IT technician can stand more than six hours of work every day. We are all just people, and our resources are limited. It's hard to do anything about it. If you consider yourself a human being but are able to work 12 hours a day, write. I have to learn something from you. When you burn out, what will you have left? As I wrote in a previous article, you can't put everything into one activity. You can lose it for reasons beyond your control, and then there will be almost nothing left in life. You need to invest in your own mind and body, in several types of activities, and (surprise) in relationships with different people. Investment recommendation: do not invest in burnout. What are these successes for? Yes, you can become richer and more successful, but why? To invest the resources you receive and become even richer and more successful? But it has to have an end. There must come a time when it is worth living for pleasure in all its manifestations: delicious food, beautiful surroundings, favorite activities, and a whole infinity of sugary-sweet items. And the best people are around. Productivity takes too much time and effort. And it will be more profitable to spend some of these resources on enjoying life

Hiring junior dev is profitable, writing your own technology is not #fundamentals #industry #career These two takes are a little more connected than you think. Let me start from afar. I promise, everything will become clear in the end. The developer's technical knowledge is divided into three types: fundamental, applied, and project-level. Knowledge unit cannot always be strictly attributed to one of the types; this classification is not too strict or discrete. But it is quite enough to explain the thought. Fundamental knowledge: theoretical sciences, for example, computer science, mathematics, and algorithms. They are often used as a basis for further immersion in the field of development. Fundamental knowledge complements applied knowledge well, but it does not work on its own. Applied knowledge is the theory and practice of working with specific technologies. SQL, JS, React, Postman, Swagger, and Gitlab CI - there are tons of examples, not to list them all. But they can be applied in different ways, and here a third, non-obvious type of knowledge arises. Project knowledge. It's simple; they are tied to a specific project. Often, it's a command codestyle, local homemade technologies, or the nuances of starting an assembly, but in fact, these details are different everywhere. They cannot be found on the Internet and are only obtained with experience working for a specific company on a specific project. It is shown that this is not required to make SQL queries and add links. Project knowledge is the biggest pitfall affecting the value of a developer for a company. And all the initial takes are associated with them. Let's finally expand them. Onboarding junior developer is cheaper. Companies hire developers of different levels for different salaries, but they all have one thing in common: absolute zero project knowledge. Each developer needs to be taught how to work with a specific context, and the learning rate is about the same for an expert of any level. It turns out that during this onboarding, senior dev needs to be paid more, and all this time he is as unprofitable as possible for the company. Yes, after onboarding, the senior will be more useful. But in terms of the amount for a conditional year of work in the company, who will be more profitable? Junior is more useful in the current place than in the market. Junior, who has been working on the project for six months, still has modest applied knowledge but huge project knowledge. There are efforts invested in it that do not make it more expensive on the market. And the company can use it. The company can safely hire novice specialists in order to pay them below the market for a relatively long time. It sounds mercantile and disgusting. If anyone asks, it wasn't my idea; you won't prove anything; it's all capitalism. Internal technologies make onboarding longer and more expensive. That is why I am horrified every time I hear the phrase “we have our own framework in the company.” Yes, you did well; you did your best and wrote it. And now add a couple of months to each developer's onboarding, because no one knows this framework. There is still time to rewrite everything back to the React. These points are only a small part of the underestimation of project knowledge. Here I could mention the importance of internal documentation, about building processes, and about the influence of soft skills, but then the article would stretch into a book. The main idea is that companies often underestimate the impact of project knowledge on employees, on hiring, and on the final cost of the product. And if companies don't use it, we, developers, will do it. P.S. The idea of knowledge types belongs to Ilya Klimov, and in Feature-Sliced Design it is described more briefly and accurately.

Software architecture: what it is #architecture #fundamentals #hardskills After years of studying software architecture, I finally decided to figure out what it is. At least for myself. And I have some complaints. You see, the term “software architecture" has hundreds of definitions, equally true and false. This term is even too extensible; it relies on an unbearable number of other abstract definitions, and it is impossible to put it precisely. Moreover, it often means several other fields of knowledge: system design, software design, and, in fact, software architecture (I write in the original because translation difficulties hurt). Does it seem that there are enough difficulties with this thing? Okay, there's going to be another one. Developers confuse architecture as a science with a specific implementation. Because of this, the phrase “we have our own architecture on the project” can be heard as “we have our own mathematics in the store.” Okay, let's say I have hundreds of definition options. But I need to choose one, just so that I can continue to work with him and so that he gives me a basis for further judgments. And I chose the most practical and accurate one. Project architecture is a set of technical implementation rules adopted for the project And now I'm telling you why this word will sound like this to me, and in no other way. I will literally take apart every detail and its relevance in order to cut off all doubts at their root. The architecture of the project is tied to the project (not surprising). It may exist abstractly by itself as a science, but it is impossible to discuss it in such a context. Again, an example with more classical sciences: the phrase “let's use the laws of physics” without reference to the context means about nothing and gives about zero benefit. Architecture is a set of rules. It dictates how a project works, what kind of technical stack it has, and what templates technical solutions should be implemented according to. And all these rules must be consistent; otherwise, each of them becomes a situational decision. And a set of situational solutions will not create a constructive framework for team development, will not simplify the writing and searching of code for an individual engineer, and will not give absolutely anything useful. It's like a law that can be followed, or you can ignore it if you really want to. Architecture is about technical implementation, not the idea. It, like any technology, is a tool and has no right to dictate the business logic of the project. To the question “how to do it?” she will answer, and the question is “what should I do? We need to address it to someone else. The architecture is adopted by developers based on necessity and appropriateness. It can and should be changed on the fly to meet the needs of the project. By the way, a whole book has been written about this: “Evolutionary Architecture."  I recommend it. I mentioned what software architecture is, but I did not say the most important thing for a practicing engineer is what it gives and how to choose it. I'll touch on that too; I promise, I won't forget. Stay tuned.

The “fake” engineer is right #lifestyle #mindset #career #timemanagement Hi. I am Anton, and I have been programming since I was literally 10 years old. For me, programming is creativity, passion, and craft—all at once. I have worked with hundreds of technologies, watched hundreds of reports and articles, and even wrote a few myself. And, until recently, I considered myself a “real” engineer, and all others were "fake." Because I'm looking for a challenge, interest, and discovery in my work, and they're just money. It seemed to me that the title of "real" programmer gives me pride and success and that all problems will be solved for me. But I was wrong. Walking along this path, I jumped on a rake several times, filled myself with bruises, and made conclusions. I hope no one else will do this. You can't put everything into one activity. If there is nothing in my life but programming, then to lose it is to lose everything. This has already happened once. And it's hard for me to find the words to describe my condition at that moment. Depressed? Empty? Unpleasant, at least. I don't want to experience this anymore. It is difficult to create art if you do not consume information. Inspiration and the first impulse for writing a project can be anything, but this “anything” is most often in the real world. For example, if I want to write a planning application, I have to do planning. To want to write an engine for a game, I have to play games. To see the idea, I have to look around. Code is just a tool in the hands of business. The business buys my working hours so that I can complete the task and bring in even more money. Whether the task will be interesting or whether it will make me develop is a matter of chance. There is little space in this scheme to implement your own ideas. So it turns out that beautiful code and a creative approach do not make the product more expensive. The flow of interesting tasks is unstable. If you look inside the projects, 95% of them are the same. And even in special, unique projects, there are all-known details. The same backend, the same analytics, authorization, forms, buttons, and cards. For some reason, I hoped that in each task I would be able to find a challenge for an engineer and a space for creativity. But it turned out that sometimes I just have to do tasks. It turns out that many of my skills are simply not needed or have nowhere to apply them. Such “real” engineers are appreciated only by other “real” ones. They praise each other for their education, reports, backgrounds, approaches, or anything else rather than admitting that they have spent thousands of hours on useless things. Almost all the people around me think radically differently. They came to IT for the money, and they don't even trying to hide it. I sincerely admire how toughly and accurately one of my friends outlined the boundaries of his activity: “Programming is necessary for earning money; podcasts are for creativity; sports are for entertainment.” And he's probably right. The “fake” engineer is right.

Coffee, cookies and health ensurance #career #job #office #remote “tea, coffee, cookies and snacks in the office” “basketball court, massage room, bike parking” “health insurance, gym, English lessons” “go-go dancer in the open space and bartender in the coffee shop” When a company tries to lure you with such profits, two thoughts arise. First, this is imposed bullshit; I don't need it. Second, more profits are better; they give me it, and I take it. Both of them are extremes, and the truth, as always, is in the middle. This is my humble opinion. But that doesn't mean that my opinion is true. In short, I'll explain everything now. It is beneficial for the company to remove all blocking factors from the employee so that he can spend working hours as efficiently as possible. It is beneficial for the company that a productive, efficient worker does not get distracted by going to the nearest cafe, does not leave early for training, and arrives at the office at what is convenient for him, just in time. With this construct, I do not understand why developers, designers, and managers need corporate tariffs for training services, sports clubs, and other activities outside the office. Here, the take “give me the money, then I'll decide where to spend it” works one hundred percent. Yes, a contract with service providers can be beneficial to everyone if these services are used. And if not? And what if I'm not going to go to conferences, buy courses on JQuery, and increase my lips at the expense of the company? Working remotely even negates the remaining profits by transferring time management responsibility entirely to the employee. It makes no sense for a remote developer to offer anything at all except a salary. Dev will decide when and which fitness club he goes to and which blends of coffee he needs to survive the fifth call of the day. It sounds like for most employees, bonuses from companies are not needed at all, but no, there are critical and necessary factors. For example, to organize a workplace at a remote job, it would be nice to give good working devices or at least discounts on their purchase. For example, those who want to separate their work and personal space can pay for coworking with the help of their company. For example, it would be quite logical to pay for the software necessary for work. But, unfortunately, I do not always find this. But there is always coffee and cookies. tldr. Devices and payment for coworking are must-haves. Gyms and courses are not needed; it's better to give money. Redbull will be useful in the office; a dancer is unlikely.

So-called code standards #frontend #industry I've heard the phrase “we use tool X because it's an industry standard” dozens of times, but I found about zero sense in it. An absurd example: using a monitor and keyboard to write code is standard, but the question is exactly how. I come to a conference to discuss all these “standards” and find out that in one company they draw on monitors with a marker, and in another they use keyboards as a back massager. It feels like this. A realistic example: I worked on three projects, and everywhere I was told that React was used in them. Only in one was it used as a regular SPA framework; in another it wrapped work with canvas and complex 3D graphics; and in the third it was dragged in to layout letters (yes, this also happens; he is horrified). And what does this “industry standard” give me? What's the irony All front-end development tools are configurable, and their configuration could be the standard. But plus or minus, each company considers it its duty to write its own configuration. Your own assembly pipeline, your own codestyle, and your own utility libraries. There are cases when developers have tuned React and Node according to their needs. Probably because they can, I didn't find any other motivation. Why is it bad The reason for this is that the standards ensure program-to-program compatibility. This is not very much about frontend and product development, but, for example, imagine a world without USB, HTTP, and XML. It's not working out very well, is it? There are two reasons: standards ensure that people are compatible with projects. The developer moves to a new project, and if familiar standards are used there, it can be useful from the very first day. Do not be onboarded for a week; do not close the first task in a month; just sit down and fulfill business orders. Good news There are standards, even on the frontend. For example, GraphQL, Angular, and FSD are hard to cook in their own way, and they don't need to. A brief conclusion The presence of a tool in the technical library is not yet a standard; you should not brag about it. This information does not give anything. A keyboard with a horizontal Enter is standard; this is not discussed.

Channel created