Five frightening trends of modern development
Habit is a terrible power. It makes resist change, hinders development. But in IT, we love to be at the forefront of technology, we love challenges, we love to implement what spreads in other areas only after a few years.
We are ready for the new and we can’t wait for the future to come, and we will have to adapt to it. We can go forward to know only in what strontium.
Yegor Bugaenko knows what needs to be done now, and in 5–10 years to remain a sought-after programmer. His ideas, as always, may seem controversial. You do not need to unconditionally agree with them, but to think, for example, about the pet project once again does not hurt. And the fact that the programmer needs English is unlikely to have different opinions. But on the remaining points it will be interesting to know the opinion of the community in the comments.
')
Next comes the text version of Egor’s report on AppsConf , but it refers not only and not so much to mobile development, but to the industry as a whole. Egor Bugaenko is the founder of Zerocracy, the developer of Cactoos, Takes Framework, JCabi and other open source projects. He wrote a series of books “Elegant Objects”, runs a provocative blog and delivers thought-provoking reports such as this one.
I will begin with a story about how not so long ago I decided to start developing software for mobile devices and quickly encountered that I do not know how to do it. Therefore, I decided to ask for help from someone who would tell me how to create an application in a fully packaged form. That is, to make an application that will be available in the Apple Store.
I was wondering how to build the application in one package, that is, not just to draw some buttons on the screen, but to make exactly the whole application . Obviously, the code, for example, on Swift and the product in the mobile phone are two completely different things: the first is very small, and the second is very large and includes such questions:
How to arrange buttons on the screen is easy to read on the Internet. I needed a specialist, an expert who would help me build the entire pipeline. For me, as a programmer, this is more important than placing buttons on the screen.
I found such a specialist, but he told me: “Why do you think about this? Draw the application first. What is continuous integration? Wait a while with the Unit tests - make it work. What is the delivery pipeline? Why TestFlight - use the simulator ".
Surely, he is a good programmer, but in his mind, in my opinion, everything is turned upside down . He thinks the code is important, and the rest of the packaging is secondary. In my opinion, this is a big problem, and this is what I want to talk about.
For some reason, many developers believe that the code itself is important, and the build is what DevOps does — the engineer or someone else. Usually, when you come to the team, it is already done and configured. You get into a project where you write code, not knowing how everything ends up in production. I believe that the fact that programmers do not see the full build cycle, do not know how it works is a problem.
I write books on programming, and I know for myself that the book will turn out well, if you first make it beautiful . That is, I design the book before I write. First, I make a makefile that directly from the command line collects the entire book from files on LaTeX, I prepare texts, images, and a cover. I spend a lot of time and make it so that one team to collect the entire book in a PDF file. I pay great attention to how it will look, where there are some indents, which text blocks and the distance between them, how the pages will be numbered. When I like all this, I see that everything is beautifully assembled and everything in this product is complete, even if only one page is written, only then I start writing a book, and only then it gives me pleasure.
More often, programmers do the opposite: they write, run on the simulator, check the work. I believe that it is more correct to deploy first, then code .
I will give one more example. One novice developer volunteered to do an open source project with us. He chose Flutter, did the first iteration, launched it, said that everything was working great and cool, and offered to watch. We ask: “How to try something? Here is the iPhone - where to click? ”. To which he began to explain where to go, what to download is a long process.
It seemed inconvenient to us, and in the end he agreed that the application really should be put on TestFlight. After some time, he showed the application on TestFlight. I pushed the buttons and noticed some defects. I did not work with Flutter and didn’t really want to, but I wanted to quickly correct what I noticed. I asked how to do it, where and how to send a pull request. I open the repository, readme-file: "This is a cool app ... click download ...".
The instruction was complicated and incomprehensible, I again asked how to deploy all this on my computer. I wanted to simply modify someone else’s code, launch the simulator and send a pull request by simply pressing a few buttons on my computer. That guy left to describe it all, and never returned.
This situation illustrates that his qualities as a programmer are good - he was able to launch the application. But his qualities, as a person who sees the project entirely, leave much to be desired. As a result, the project lost not only me as a contributor, but also many others. This programmer did not get feedback from others, he worked as a loner.
In my opinion, now being alone is wrong . The market is moving towards more populated teams: there will be more people in them, they will more often come and go.
The newbie should get into an environment that is friendly to him from the point of view of the build - he should open the readme-file and in a few minutes understand how to make everything run on the simulator. What to click to check if everything is collected from the command line — not from complex IDEs that need to be configured a few more hours. It should be possible to write make / build / etc on the command line. After that, everything is collected and will print a green line - everything is ready - then pull request. This is the first thought that I want to share today.
Of course, you will say that you are not working alone, not as the sole founders of projects, not as CTO. You work in teams and you can’t just come in and say that now you’ll do Deploem, TestFlight, and you need to get CI right away. This is not your task, you will not be given time for it, etc.
Therefore, I recommend that you do your own pet projects — projects that you do at your leisure — in order to understand everything in its entirety.
A total of 20–30% of programmers have their own published application, but everyone should have it. If you consider yourself and want to be a popular programmer, I would recommend to make your mobile application and go through the entire cycle of its entry into the market: checks on the Apple Store, CI, packaging, and everything else. Make it open source so people can contribute and show you how it’s not working.
He is either not interested in his profession, or he doesn’t care, either he cannot, or he is afraid. It is a fear to see the whole cycle. We are afraid to look at the project as a product ready for the client. A client for us in many cases is another developer, as in my example I was a client of a developer on Flutter.
The second fear, in my opinion, is money.
On the Zerocracy platform, I work with a lot of programmers and noticed that they are very often afraid of money. They are accustomed to paying at the end of the month, and are quite painful when they are valued in money. Many cannot answer the simple question: “Do you know how much you can make a code for $ 100?”
Surely you know how much you want to earn per month. Imagine how much a full month of your life costs: an apartment, a car, regular payments, the usual degree of comfort and entertainment.
I think we will more and more work in temporarily assembled teams, where people come while they are needed, and then go on. The era of developers sitting in one place is leaving, because the company hired them many years ago, they just love this company, and therefore they are with it - no matter what technology the company uses.
I know examples of such projects that were first written in C ++ for many years, and then they realized that they needed to write in Java. And the same people, in the same office, for the same money, the investor switches, retrains for half a year and shakily begins to write in Java. This is an approach from the past. In my opinion, in the future, such approaches will cease to exist, because they will not make sense.
The market is becoming global , remote access to the labor market is becoming easier and simpler. A company located in Moscow will be uninteresting and unprofitable to retrain people, for example, from iOS to Android or from C ++ to Java. Simply hire new professionals who come as freelancers, complete the task and leave.
I think such a format of projects will be popular: temporary projects where freelancers converge, work out their tasks - one expert in this, another expert in that - and leave.
From programmers, this new time expects:
Many people are afraid to engage in the construction of resumes, afraid to sell themselves. As I have already said, I think that the summary must contain the pet project item.
Own projects will be the first indicator of value in the market , and not where you have been working on software that you inherited for 5 years in a row. You create a Pet project from scratch, and it doesn't matter what it is about, how complex it is or how many downloads it has on the Apple Store. Let it be 0 likes and 2 downloads, but this is a complete project that you created yourself.
To me, as an employer, such people are more valuable than those who have been sitting in the office for many years and have resumes with one or two employers. I find it hard to understand what to do with this person, how to evaluate him. I know that he wants me to take him for the whole month and be friends with him, regardless of the outcome. For me, this format is now unacceptable, for a large number of employers in the future it will also be uncomfortable.
Therefore, the recommendation - count the money, try to work under contracts . Maybe this is not entirely satisfactory for your employers, but try, being on full-time and sitting in the office, to look for some micro-projects in parallel for a part-time job. Not for the sake of money, but in order to understand whether you need the market as a freelancer or not, you need an expert or not. Or you only need your boss, who is afraid of losing you, because only you know how the project code works.
Look for alternatives, see, try, sell . At first you will not be bought, there will be problems - a lot of problems! But solving these problems, you will become a more demanded programmer of a higher level.
Unfortunately, not only the programmers themselves can not determine the price of the work, but also the customers. Sometimes I am offered to perform individual tasks as an expert. And often the customer who offers me a job does not understand how to evaluate me. Most often, people just want cheaper, for example $ 50, not $ 100 per hour. I understand that a person with such an approach still does not understand how much I’ll actually write in this hour. Then I agree and just multiply the number of hours by 2. As a result, I get as much as I wanted initially.
I know my real value and speed of work. Customers are not ready for amounts of $ 100–500 per hour, for them 20 is already a lot, since they are accustomed to the full-time employment format over time. That is, when a person receives money for the time that he allegedly spends on development.
I do not know about you, but I can not sit for 8 hours and write code. I am sure each of you will confirm that out of the 8 working hours that you are in the office or at your computer, you actually write the code much less. And they pay for these 8 hours, and the customer thinks that this is 8 hours of work. This is a double deception system: they are happy to be deceived, and we are deceiving them. Therefore, I use the multiplication factor. At least in 20 I will work, but then I will do 3 weeks what I’ll actually do in 2 hours.
Both customers and programmers are accustomed to informal communication.
Informal communication remains in the air, it is not recorded in the documentation, not tracked, it is difficult to return to it later, and it makes the project difficult to maintain. When the team changes, and as I said earlier, the team should change and will change more and more intensively, it becomes very important how clear the past communications in the project are.
If I come to a developing project, I want to understand what has been done over the past year not only in the form of code, but also to have some explanation for this code: why such a framework or algorithm was chosen, who have already expressed their opinion about this algorithm and was disagree. I want to see all this, and not to look in the office or chat for someone who will explain everything to me. I need the opportunity to read this directly in the repository or the ticket system.
Unfortunately, most programmers are led by customers. Of course, in the interests of the client to have the opportunity to informal communication with the developer. And we turn out to be rather weak and go with them, listen by phone, what should be done, we answer, we listen, we answer ... and then we go and do.
Then 2-3 weeks pass, and we no longer remember what we agreed on. The customer says that he didn’t want it, we are trying to prove that this is what he asked for, look for some mention in the chat - the catch of fleas begins.
I think the reason is in fear of ticketing systems. Many programmers with whom we work (for sure, this also concerns you) do not know how, do not like, do not want to formulate tasks in the form of a ticket - understandable and short.
It's easier for people to say: “Let's talk! We will hold a meeting, sit down together and decide everything. In 3 hours we will understand each other, and then I will go and encode it. I will remember what we agreed on and program everything. ” Forget nothing, meet again. And so we somehow stretch from the rally to the rally.
It is not right. We, as programmers, should convert any informal communication into tickets. We talked with the client (customer, product owner, other programmer), found out what needs to be changed - convert any communication into a tick limited by the framework of our system (Jira, GitHub, etc.), where we write: what does not work, how it is necessary to correct, why it is necessary to correct, what motivation, and then work on this ticket.
The inability of the programmer to structure the work in the tickets can speak about his unskilled skills. I believe that there are two types of development:
I often find myself working on the first scenario. I like programming, I turn on the computer in the morning - and I went. Then I stop - stop, let's break up into tasks, determine from which task we will move to.
In the second variant, each ticket ends with a pull request: here is the problem, its description, discussion in the area of ​​this problem, change in the code. Pull request sent, verified, accepted - the ticket is closed, you can proceed to the next.
Usually people work both ways. But for some reason, one of the main problems we are facing is that people simply do not know how to break the task down into smaller ones.
Some people mistakenly believe that incremental development necessarily means a task that is 2 weeks long, and that the ticket should end with a pull request of 5 thousand modified lines. This is not an incremental development. Incremental is a task for 0.5–2 hours, and at the end of a pull request from 50-100 lines of code. Continuous on the contrary - you work for a long, long time (days, weeks) and produce little.
That's why I say that good programmers write code, but the best write tickets. Writing code is easier than a good ticket - this is a good explanation of why this code needs to be done. Therefore, if you want to develop and raise your level, then focus on the ability to explain to another programmer what needs to be done and the ability to listen to the client or customer and translate his thoughts into tickets.
I will give an example from life. Recently we had a customer who, like many others, wanted to explain the essence of the project by telephone. He spoke on the phone with one of our architects several times. A week later, I discovered that, despite the fact that there is a discussion going on, maybe even some code is being written, there is only one ticket in the system. This is a mistake of the architect who received the flow of information and did not structure it. Then, if problems arise in the project, we will have nothing to answer to the dissatisfied client. We do not raise the logs of telephone conversations.
This is only an architect's mistake. The client does not need to know this. The client is a chaotic undisciplined creature, little understood in the development process. He should be like that. But our task is to be more disciplined , so write tickets, structure.
The next problem that I often encounter and I want to draw attention to is English. Many Russian-speaking developers ignore English, consider it something secondary and do not want to learn, or it is hard for them. In the IT sphere, there is a Russian-speaking community, with which, I think, we must fight with all our strength. Habr, as the pioneer of this community, does a disservice.
Of course, our native Russian language, and do not have to give it up. But in the area of ​​the same tickets, code, conferences, books that you read, I think it is necessary to switch to the only English format .
As I have already said, the development world is becoming global, there will be less and less programmers from Moscow - there will be just programmers, for example, on Swift, and the fact that you are from Moscow will be of little concern to anyone. Programmers will sell themselves all over the world via the Internet, and not through an interview in the office. One way or another, this market will come, even in 5-10-15 years, and you can just be out of the picture.
You think that it is easier to explain your compatriot in Russian. There is a mass of Telegram channels, which I also use, where they discuss technical problems in Russian. People like it - they enjoy it because the language is clear. They use slang terms, sometimes it is an explosive mixture of English terms in Russian transliteration and with inclinations that they become difficult to make out.
I think it only hurts. In the global market, you will be second-rate people if you do not understand technical English and are not ready to communicate in it.
To improve my level of English, I can recommend the following.
Read technical literature and watch videos in English only . The vast majority of books are English-speaking, do not read translated publications, they only harm.
Watch movies in English with subtitles . It helps to learn real English. I would not recommend going to the courses, in my opinion, this is just a waste of time. The training courses, in my opinion, give a dead language that is not used in real life. Watch a movie - there is real English. We include subtitles and watch only interesting movies. Do not watch films for the purpose of learning, choose those that you like, and learn from them.
Try to participate in professional chat rooms in English . Instead of joining Russian-speaking chat rooms in which you speak with compatriots and you feel comfortable, participate in chat rooms in English. So you yourself will pull up in English, although at first it will be difficult.
Last and most importantly - write in English . Keep Twitter, blog, Telegram-channel in English. At first no one will read you, because your English will be broken. But in the end you will seriously advance your professional level.
Now, in many ways, the world is changing and moving away from programmers who are well aware of algorithms and versed in mathematics, to those who know how to compose code, putting the components together. To understand how components work, you need to read about them, or talk to their developers, or send them a ticket, or get support in a chat - all this is in English.
English will be decisive in the market in 5-10 years. The cost of a specialist with poor English is 2 times lower because he cannot fit into the team, it is hard for him to understand the existing documentation.
So read, watch and write in English. Let it be broken - it's not so scary. For the first time, it is enough if you are simply understood, and gradually with practice it will get better and better.
I think that the world is now moving towards the open source code, and that in 10–15 years there will be only open source in general, with the exception of special projects (NASA or military).
Open source development has its own features. Write code, pack and upload - only half the battle. There are no programmer problems on the way: at first your code will not interest anyone, your pull requests will also be difficult to write and configure, you will not put likes and asterisks on GitHub, they will not use your product.
Becoming an open source developer is difficult. But if you simply use open source-code, then slow down your development, because in the future all products will be delivered with open source code, and you should become a participant in this market.
Companies will write less and less internal, proprietary code, and will increasingly use components. Even now, look at your application - how much code is taken from open source, and how much did you write yourself? Frames, libraries, packages, images - all of this is gathered together from various open sources.
I think we will become assemblers - assemblers, not coders. Coding, as such, will take less time and will be less needed. You will need the ability to assemble the end product from open source components. To do this, you need to be able to contact the open source community: not only take, but also give something, write tickets, send a pulll request, create your products.
For many years, about once a month I have been creating my open source library, posting a ready-made product to open access: a package, library, framework or documentation - something real. Now I have 2,300 followers on GitHub - that's pretty much, but this is the result of 6 years of work.
At first it was hard - I laid out the library, and the first asterisk appeared in a month. Now I am posting something, announcing, and after a few hours I already see a dozen asterisks. I went a long, really painful way.
In this community, no one respects anyone just for regalia. It will take time to gain trust and authority. A person whom no one knows, because he does not contribute to anything and does not give anything, but only uses and takes away, has no influence. The world environment does not know him - yes, he is known among 25 people in his company and several others outside of it whom he met at the conference, but the community does not know him.
In this case, I again have an example from practice. We launched a new project, and we needed to find several experts in a specific framework. You will not find such a person on an ad; this is not a full-time job, but just a few hours of consultation on the use of a specific framework. It seemed to us that the project architect would have no difficulty finding the right specialist.
However, the architect spread his hands - he did not know how to do it. His social connections, 20 followers on Twitter and 2 repositories on GitHub did not help solve the problem. But if he were an active open source developer, led a blog and shared his experiences on social networks, it would be easy for him to find an expert. It would be enough to use the power of your community.
Now is not 2000, but 2019. And in 2029 this will be a critical indicator of your professionalism. It doesn't matter what code you write, if you have few followers, you are simply not integrated into the environment and cannot help your project by attracting additional people.
We are ready for the new and we can’t wait for the future to come, and we will have to adapt to it. We can go forward to know only in what strontium.
Yegor Bugaenko knows what needs to be done now, and in 5–10 years to remain a sought-after programmer. His ideas, as always, may seem controversial. You do not need to unconditionally agree with them, but to think, for example, about the pet project once again does not hurt. And the fact that the programmer needs English is unlikely to have different opinions. But on the remaining points it will be interesting to know the opinion of the community in the comments.
')
Next comes the text version of Egor’s report on AppsConf , but it refers not only and not so much to mobile development, but to the industry as a whole. Egor Bugaenko is the founder of Zerocracy, the developer of Cactoos, Takes Framework, JCabi and other open source projects. He wrote a series of books “Elegant Objects”, runs a provocative blog and delivers thought-provoking reports such as this one.
I will begin with a story about how not so long ago I decided to start developing software for mobile devices and quickly encountered that I do not know how to do it. Therefore, I decided to ask for help from someone who would tell me how to create an application in a fully packaged form. That is, to make an application that will be available in the Apple Store.
I was wondering how to build the application in one package, that is, not just to draw some buttons on the screen, but to make exactly the whole application . Obviously, the code, for example, on Swift and the product in the mobile phone are two completely different things: the first is very small, and the second is very large and includes such questions:
- Unit tests;
- static analysis;
- Continuous integration;
- dependency management;
- Continuous delivery;
- Staging Environment;
- App Store App Process;
- the process of assembling defects from production, etc.
How to arrange buttons on the screen is easy to read on the Internet. I needed a specialist, an expert who would help me build the entire pipeline. For me, as a programmer, this is more important than placing buttons on the screen.
I found such a specialist, but he told me: “Why do you think about this? Draw the application first. What is continuous integration? Wait a while with the Unit tests - make it work. What is the delivery pipeline? Why TestFlight - use the simulator ".
Surely, he is a good programmer, but in his mind, in my opinion, everything is turned upside down . He thinks the code is important, and the rest of the packaging is secondary. In my opinion, this is a big problem, and this is what I want to talk about.
For some reason, many developers believe that the code itself is important, and the build is what DevOps does — the engineer or someone else. Usually, when you come to the team, it is already done and configured. You get into a project where you write code, not knowing how everything ends up in production. I believe that the fact that programmers do not see the full build cycle, do not know how it works is a problem.
First warm, then code
I write books on programming, and I know for myself that the book will turn out well, if you first make it beautiful . That is, I design the book before I write. First, I make a makefile that directly from the command line collects the entire book from files on LaTeX, I prepare texts, images, and a cover. I spend a lot of time and make it so that one team to collect the entire book in a PDF file. I pay great attention to how it will look, where there are some indents, which text blocks and the distance between them, how the pages will be numbered. When I like all this, I see that everything is beautifully assembled and everything in this product is complete, even if only one page is written, only then I start writing a book, and only then it gives me pleasure.
More often, programmers do the opposite: they write, run on the simulator, check the work. I believe that it is more correct to deploy first, then code .
I will give one more example. One novice developer volunteered to do an open source project with us. He chose Flutter, did the first iteration, launched it, said that everything was working great and cool, and offered to watch. We ask: “How to try something? Here is the iPhone - where to click? ”. To which he began to explain where to go, what to download is a long process.
It seemed inconvenient to us, and in the end he agreed that the application really should be put on TestFlight. After some time, he showed the application on TestFlight. I pushed the buttons and noticed some defects. I did not work with Flutter and didn’t really want to, but I wanted to quickly correct what I noticed. I asked how to do it, where and how to send a pull request. I open the repository, readme-file: "This is a cool app ... click download ...".
The instruction was complicated and incomprehensible, I again asked how to deploy all this on my computer. I wanted to simply modify someone else’s code, launch the simulator and send a pull request by simply pressing a few buttons on my computer. That guy left to describe it all, and never returned.
This situation illustrates that his qualities as a programmer are good - he was able to launch the application. But his qualities, as a person who sees the project entirely, leave much to be desired. As a result, the project lost not only me as a contributor, but also many others. This programmer did not get feedback from others, he worked as a loner.
In my opinion, now being alone is wrong . The market is moving towards more populated teams: there will be more people in them, they will more often come and go.
The dynamics of human resources is moving towards a higher turnover, so every person who comes to the project again must see it entirely - not just the code that runs on simulators.
The newbie should get into an environment that is friendly to him from the point of view of the build - he should open the readme-file and in a few minutes understand how to make everything run on the simulator. What to click to check if everything is collected from the command line — not from complex IDEs that need to be configured a few more hours. It should be possible to write make / build / etc on the command line. After that, everything is collected and will print a green line - everything is ready - then pull request. This is the first thought that I want to share today.
Of course, you will say that you are not working alone, not as the sole founders of projects, not as CTO. You work in teams and you can’t just come in and say that now you’ll do Deploem, TestFlight, and you need to get CI right away. This is not your task, you will not be given time for it, etc.
Therefore, I recommend that you do your own pet projects — projects that you do at your leisure — in order to understand everything in its entirety.
A total of 20–30% of programmers have their own published application, but everyone should have it. If you consider yourself and want to be a popular programmer, I would recommend to make your mobile application and go through the entire cycle of its entry into the market: checks on the Apple Store, CI, packaging, and everything else. Make it open source so people can contribute and show you how it’s not working.
See how you work with the market, try and understand what programmers you are. I think that the programmer who has no pet projects is bad.
He is either not interested in his profession, or he doesn’t care, either he cannot, or he is afraid. It is a fear to see the whole cycle. We are afraid to look at the project as a product ready for the client. A client for us in many cases is another developer, as in my example I was a client of a developer on Flutter.
The second fear, in my opinion, is money.
How much code will you write for $ 100?
On the Zerocracy platform, I work with a lot of programmers and noticed that they are very often afraid of money. They are accustomed to paying at the end of the month, and are quite painful when they are valued in money. Many cannot answer the simple question: “Do you know how much you can make a code for $ 100?”
Surely you know how much you want to earn per month. Imagine how much a full month of your life costs: an apartment, a car, regular payments, the usual degree of comfort and entertainment.
The time for full-time fixed-fee developers is running out.
I think we will more and more work in temporarily assembled teams, where people come while they are needed, and then go on. The era of developers sitting in one place is leaving, because the company hired them many years ago, they just love this company, and therefore they are with it - no matter what technology the company uses.
I know examples of such projects that were first written in C ++ for many years, and then they realized that they needed to write in Java. And the same people, in the same office, for the same money, the investor switches, retrains for half a year and shakily begins to write in Java. This is an approach from the past. In my opinion, in the future, such approaches will cease to exist, because they will not make sense.
The market is becoming global , remote access to the labor market is becoming easier and simpler. A company located in Moscow will be uninteresting and unprofitable to retrain people, for example, from iOS to Android or from C ++ to Java. Simply hire new professionals who come as freelancers, complete the task and leave.
I think such a format of projects will be popular: temporary projects where freelancers converge, work out their tasks - one expert in this, another expert in that - and leave.
From programmers, this new time expects:
- Ability to understand how much you are worth. That is, to give an estimate of how much your working hour costs, how much value you will create for it.
- Ability to work in temporary conditions.
- Skills to sell yourself, properly present. A freelance developer in the global market should have a “trade advantage” and price.
Many people are afraid to engage in the construction of resumes, afraid to sell themselves. As I have already said, I think that the summary must contain the pet project item.
Own projects will be the first indicator of value in the market , and not where you have been working on software that you inherited for 5 years in a row. You create a Pet project from scratch, and it doesn't matter what it is about, how complex it is or how many downloads it has on the Apple Store. Let it be 0 likes and 2 downloads, but this is a complete project that you created yourself.
To me, as an employer, such people are more valuable than those who have been sitting in the office for many years and have resumes with one or two employers. I find it hard to understand what to do with this person, how to evaluate him. I know that he wants me to take him for the whole month and be friends with him, regardless of the outcome. For me, this format is now unacceptable, for a large number of employers in the future it will also be uncomfortable.
Therefore, the recommendation - count the money, try to work under contracts . Maybe this is not entirely satisfactory for your employers, but try, being on full-time and sitting in the office, to look for some micro-projects in parallel for a part-time job. Not for the sake of money, but in order to understand whether you need the market as a freelancer or not, you need an expert or not. Or you only need your boss, who is afraid of losing you, because only you know how the project code works.
Look for alternatives, see, try, sell . At first you will not be bought, there will be problems - a lot of problems! But solving these problems, you will become a more demanded programmer of a higher level.
Unfortunately, not only the programmers themselves can not determine the price of the work, but also the customers. Sometimes I am offered to perform individual tasks as an expert. And often the customer who offers me a job does not understand how to evaluate me. Most often, people just want cheaper, for example $ 50, not $ 100 per hour. I understand that a person with such an approach still does not understand how much I’ll actually write in this hour. Then I agree and just multiply the number of hours by 2. As a result, I get as much as I wanted initially.
I know my real value and speed of work. Customers are not ready for amounts of $ 100–500 per hour, for them 20 is already a lot, since they are accustomed to the full-time employment format over time. That is, when a person receives money for the time that he allegedly spends on development.
I do not know about you, but I can not sit for 8 hours and write code. I am sure each of you will confirm that out of the 8 working hours that you are in the office or at your computer, you actually write the code much less. And they pay for these 8 hours, and the customer thinks that this is 8 hours of work. This is a double deception system: they are happy to be deceived, and we are deceiving them. Therefore, I use the multiplication factor. At least in 20 I will work, but then I will do 3 weeks what I’ll actually do in 2 hours.
Teach your customers and learn to count money yourself.
Good programmers write code, the best - tickets
Both customers and programmers are accustomed to informal communication.
Informal communication in the form of chats, phone calls, rallies, e-mail is a form of communication that destroys the project and only makes it worse for the customer and the programmer.
Informal communication remains in the air, it is not recorded in the documentation, not tracked, it is difficult to return to it later, and it makes the project difficult to maintain. When the team changes, and as I said earlier, the team should change and will change more and more intensively, it becomes very important how clear the past communications in the project are.
If I come to a developing project, I want to understand what has been done over the past year not only in the form of code, but also to have some explanation for this code: why such a framework or algorithm was chosen, who have already expressed their opinion about this algorithm and was disagree. I want to see all this, and not to look in the office or chat for someone who will explain everything to me. I need the opportunity to read this directly in the repository or the ticket system.
Unfortunately, most programmers are led by customers. Of course, in the interests of the client to have the opportunity to informal communication with the developer. And we turn out to be rather weak and go with them, listen by phone, what should be done, we answer, we listen, we answer ... and then we go and do.
Then 2-3 weeks pass, and we no longer remember what we agreed on. The customer says that he didn’t want it, we are trying to prove that this is what he asked for, look for some mention in the chat - the catch of fleas begins.
I think the reason is in fear of ticketing systems. Many programmers with whom we work (for sure, this also concerns you) do not know how, do not like, do not want to formulate tasks in the form of a ticket - understandable and short.
It's easier for people to say: “Let's talk! We will hold a meeting, sit down together and decide everything. In 3 hours we will understand each other, and then I will go and encode it. I will remember what we agreed on and program everything. ” Forget nothing, meet again. And so we somehow stretch from the rally to the rally.
It is not right. We, as programmers, should convert any informal communication into tickets. We talked with the client (customer, product owner, other programmer), found out what needs to be changed - convert any communication into a tick limited by the framework of our system (Jira, GitHub, etc.), where we write: what does not work, how it is necessary to correct, why it is necessary to correct, what motivation, and then work on this ticket.
The inability of the programmer to structure the work in the tickets can speak about his unskilled skills. I believe that there are two types of development:
- Continuous development - programming from 9 in the morning to 5 in the evening: I came, the computer turned on, I did something, I had lunch there, I also encoded it, the end of the day - well, tomorrow I will continue. That is, we program as long as there is energy, time, power.
- The incremental development is different: there is task number 13, I’ll do it to the end, and then I’ll see what the next task is. In this view, the task (ticket) will always be completed. But if there is no ticket, there is no formulated documented task, the project does not move - the code is not written, and no pull request appears.
I often find myself working on the first scenario. I like programming, I turn on the computer in the morning - and I went. Then I stop - stop, let's break up into tasks, determine from which task we will move to.
In the second variant, each ticket ends with a pull request: here is the problem, its description, discussion in the area of ​​this problem, change in the code. Pull request sent, verified, accepted - the ticket is closed, you can proceed to the next.
Usually people work both ways. But for some reason, one of the main problems we are facing is that people simply do not know how to break the task down into smaller ones.
Some people mistakenly believe that incremental development necessarily means a task that is 2 weeks long, and that the ticket should end with a pull request of 5 thousand modified lines. This is not an incremental development. Incremental is a task for 0.5–2 hours, and at the end of a pull request from 50-100 lines of code. Continuous on the contrary - you work for a long, long time (days, weeks) and produce little.
That's why I say that good programmers write code, but the best write tickets. Writing code is easier than a good ticket - this is a good explanation of why this code needs to be done. Therefore, if you want to develop and raise your level, then focus on the ability to explain to another programmer what needs to be done and the ability to listen to the client or customer and translate his thoughts into tickets.
I will give an example from life. Recently we had a customer who, like many others, wanted to explain the essence of the project by telephone. He spoke on the phone with one of our architects several times. A week later, I discovered that, despite the fact that there is a discussion going on, maybe even some code is being written, there is only one ticket in the system. This is a mistake of the architect who received the flow of information and did not structure it. Then, if problems arise in the project, we will have nothing to answer to the dissatisfied client. We do not raise the logs of telephone conversations.
This is only an architect's mistake. The client does not need to know this. The client is a chaotic undisciplined creature, little understood in the development process. He should be like that. But our task is to be more disciplined , so write tickets, structure.
What programming language to learn first? English!
The next problem that I often encounter and I want to draw attention to is English. Many Russian-speaking developers ignore English, consider it something secondary and do not want to learn, or it is hard for them. In the IT sphere, there is a Russian-speaking community, with which, I think, we must fight with all our strength. Habr, as the pioneer of this community, does a disservice.
Of course, our native Russian language, and do not have to give it up. But in the area of ​​the same tickets, code, conferences, books that you read, I think it is necessary to switch to the only English format .
As I have already said, the development world is becoming global, there will be less and less programmers from Moscow - there will be just programmers, for example, on Swift, and the fact that you are from Moscow will be of little concern to anyone. Programmers will sell themselves all over the world via the Internet, and not through an interview in the office. One way or another, this market will come, even in 5-10-15 years, and you can just be out of the picture.
You think that it is easier to explain your compatriot in Russian. There is a mass of Telegram channels, which I also use, where they discuss technical problems in Russian. People like it - they enjoy it because the language is clear. They use slang terms, sometimes it is an explosive mixture of English terms in Russian transliteration and with inclinations that they become difficult to make out.
I think it only hurts. In the global market, you will be second-rate people if you do not understand technical English and are not ready to communicate in it.
To improve my level of English, I can recommend the following.
Read technical literature and watch videos in English only . The vast majority of books are English-speaking, do not read translated publications, they only harm.
Watch movies in English with subtitles . It helps to learn real English. I would not recommend going to the courses, in my opinion, this is just a waste of time. The training courses, in my opinion, give a dead language that is not used in real life. Watch a movie - there is real English. We include subtitles and watch only interesting movies. Do not watch films for the purpose of learning, choose those that you like, and learn from them.
Try to participate in professional chat rooms in English . Instead of joining Russian-speaking chat rooms in which you speak with compatriots and you feel comfortable, participate in chat rooms in English. So you yourself will pull up in English, although at first it will be difficult.
Last and most importantly - write in English . Keep Twitter, blog, Telegram-channel in English. At first no one will read you, because your English will be broken. But in the end you will seriously advance your professional level.
Now, in many ways, the world is changing and moving away from programmers who are well aware of algorithms and versed in mathematics, to those who know how to compose code, putting the components together. To understand how components work, you need to read about them, or talk to their developers, or send them a ticket, or get support in a chat - all this is in English.
English will be decisive in the market in 5-10 years. The cost of a specialist with poor English is 2 times lower because he cannot fit into the team, it is hard for him to understand the existing documentation.
So read, watch and write in English. Let it be broken - it's not so scary. For the first time, it is enough if you are simply understood, and gradually with practice it will get better and better.
No followers on GitHub - you're not a real programmer
I think that the world is now moving towards the open source code, and that in 10–15 years there will be only open source in general, with the exception of special projects (NASA or military).
The rest of the code will be in an open format, it is inevitable.
Open source development has its own features. Write code, pack and upload - only half the battle. There are no programmer problems on the way: at first your code will not interest anyone, your pull requests will also be difficult to write and configure, you will not put likes and asterisks on GitHub, they will not use your product.
Becoming an open source developer is difficult. But if you simply use open source-code, then slow down your development, because in the future all products will be delivered with open source code, and you should become a participant in this market.
Companies will write less and less internal, proprietary code, and will increasingly use components. Even now, look at your application - how much code is taken from open source, and how much did you write yourself? Frames, libraries, packages, images - all of this is gathered together from various open sources.
I think we will become assemblers - assemblers, not coders. Coding, as such, will take less time and will be less needed. You will need the ability to assemble the end product from open source components. To do this, you need to be able to contact the open source community: not only take, but also give something, write tickets, send a pulll request, create your products.
For many years, about once a month I have been creating my open source library, posting a ready-made product to open access: a package, library, framework or documentation - something real. Now I have 2,300 followers on GitHub - that's pretty much, but this is the result of 6 years of work.
At first it was hard - I laid out the library, and the first asterisk appeared in a month. Now I am posting something, announcing, and after a few hours I already see a dozen asterisks. I went a long, really painful way.
In this community, no one respects anyone just for regalia. It will take time to gain trust and authority. A person whom no one knows, because he does not contribute to anything and does not give anything, but only uses and takes away, has no influence. The world environment does not know him - yes, he is known among 25 people in his company and several others outside of it whom he met at the conference, but the community does not know him.
In this case, I again have an example from practice. We launched a new project, and we needed to find several experts in a specific framework. You will not find such a person on an ad; this is not a full-time job, but just a few hours of consultation on the use of a specific framework. It seemed to us that the project architect would have no difficulty finding the right specialist.
However, the architect spread his hands - he did not know how to do it. His social connections, 20 followers on Twitter and 2 repositories on GitHub did not help solve the problem. But if he were an active open source developer, led a blog and shared his experiences on social networks, it would be easy for him to find an expert. It would be enough to use the power of your community.
If you have a small community around you are a bad developer.
Now is not 2000, but 2019. And in 2029 this will be a critical indicator of your professionalism. It doesn't matter what code you write, if you have few followers, you are simply not integrated into the environment and cannot help your project by attracting additional people.
Yegor Bugaenko has the broadest horizon, he can motivate him to develop in different directions. Egor has already spoken with us at DevOpsConf Russia about quality , which is supposedly not the main thing, at QualityConf about high-quality development in distributed teams. In September, at Saint TeamLead Conf , we will discuss with Egor the newly emerging topic of micromanagement.
Want to keep abreast of our ambitious plans and new publications - select the list and subscribe. We write only on the case.
Source: https://habr.com/ru/post/459446/
All Articles