A short story about what IT looks like through the eyes of a junior developer. Friends! My name is Daniil, I'm 25 years old and I've been working as a programmer for 4 months without a higher education. I would like to share my thoughts, which may seem interesting to someone or help in our difficult life journey.
If you are at a crossroads and the IT industry attracts you, but at the same time, you feel that it is difficult for you to navigate the business, I want to tell you how it all looks approximately from the inside. To receive money for development, it is necessary to sell the developed product cap. With the massive development of the Internet, which has flooded the entire globe, the demand for software, as far as I can tell, will only grow. The requirements for monitoring the accounting of activities in various organizations are becoming more stringent, so the need to implement corporate software remains. The owner of enterprise "X" urgently needed to implement corporate software for accounting for goods/employees/whatever. He turns to an IT organization that is ready to sell it to him (if necessary, having previously developed it, there are many ready-made solutions). Next comes the process of all sorts of reservations and the planning of the application architecture. The team is trying to determine how they will develop the project, taking into account all the possible consequences and nuances. The database architecture is planned and created (sometimes chosen by the customer himself, sometimes it is not chosen from the most adequate point of view), the architecture of the application itself, as well as possible situations are thought out in advance. It is extremely important to lay down a competent project architecture, because due to a mistake or incorrectly made decisions, the project may one day come to a standstill. Further, a TOR (terms of reference) is drawn up, according to which work begins. Most programmers (in theory) should work strictly according to the TOR, because in case of conflict situations, they will first of all refer to it. When you work as a junior developer, you will most likely start working on an existing application and you will need to get to know it. To do this, there is a specification or "wiki" of the project, which describes its behavior in general, how it is possible to add new functionality, what technologies are used, in general - internal features. The developer works in conjunction with several people. This is his leader - PM, Project Manager, the head of the project. The manager is engaged in managerial work - allocates resources, people, sets priorities,
swearstalks with a representative of the customer, determines the further vector of movement for the team. The leader of a lesser rank, but no less important, is the team leader. This subtype combines the managerial and technical part of the work, managing a team of several people, working on something specific and without interrupting the coding process. TL will issue tasks to the developer, help (possibly) in difficult situations. Next comes the analyst. The task of the analyst is to interpret tasks from the TOR, or received from someone else, into a language understandable to the developer. He creates technical documentation / specification, where he describes the necessary information for the developer, and what exactly is required of him at this stage of development. It does not occur everywhere. I am not familiar with analysts on my project. And, of course, the tester. The developer, having created the functionality and, after debugging it, passes it to the tester so that he can examine the behavior of the program under various situations in order to find possible bugs, subsequently passing the code back. Now there are a huge number of frameworks and tools for testing, so serious programming knowledge is not required for this. The distribution of work is carried out using special internal services, for example - JIRA. It looks like a kind of "working social network", where each employee has an account, to which he receives tasks, where it is described - what is required of him, what deadlines must be met, what kind of work is this - a critical error, a bug or some improvement. There is a news feed, you can watch what is happening on the project now. You received assignments in JIRA, you received notifications about this, you opened it - you saw what was required, did the necessary, sent the task to "review" or "done" with a comment about the work done. All. In order for a large number of people to simultaneously work on one project and have an up-to-date version and the ability to quickly fix their work, there are version control systems (VCS). Centralized VCSs store the current version of the project, which an employee can download to himself (update, poll), make some changes in the code, and send them to the VCS (commit, push) so that other developers also receive the created changes. The project can develop in different directions - branches (branch), in order to have several variations of the finished solution at the moment. Usually, after the developer has completed some task, a so-called code-review is carried out with him - when a PM, a team leader or a more experienced employee starts to look - what he wrote there and whether everything will break if this commit is applied on the production server. If the project is up and running at the moment and there is no need to introduce new functionality, then the customer can continue to pay the organization for product support. If the user stumbles upon a bug or the program behaves in general not as it should, the customer's representative handles this and the problem is promptly (or not) eliminated. An example of a working hierarchy can be seen here: If the project is up and running at the moment and there is no need to introduce new functionality, then the customer can continue to pay the organization for product support. If the user stumbles upon a bug or the program behaves in general not as it should, the customer's representative handles this and the problem is promptly (or not) eliminated. An example of a working hierarchy can be seen here: If the project is up and running at the moment and there is no need to introduce new functionality, then the customer can continue to pay the organization for product support. If the user stumbles upon a bug or the program behaves in general not as it should, the customer's representative handles this and the problem is promptly (or not) eliminated. An example of a working hierarchy can be seen here:https://ru.wikipedia.org/wiki/Organizational_management_forms Summing up, I note that this work allows a person to be in demand anywhere in the world. Outsourcing services ("sale" by the company of the services of its employees for a certain time on a contractual basis) and outstaff ("sale" of employees to work elsewhere for a certain time on a contractual basis) allows everyone to exchange personnel on favorable terms. For staff - a great opportunity to travel and learn something new. What conclusions can I draw from this:
Programming is an exclusively practical science. The theory is designed to give only general recommendations, you have to come to most things with your own mind, so the skill decides everything.
The ability to have a relatively comfortable work schedule.
You should be more sensitive to your body. Sleeping well and eating right is the key to a healthy mind.
Consult more successful acquaintances/friends! Be interested in business, development, principles of work of a programmer from the inside. Research the market for job openings in your area beforehand. And do not communicate with people who do not believe in your success.
What is useful to know:
SQL. Necessarily. You will often need to work with the DBMS.
Javarush online internship is a must have. It's a really big plus for your portfolio, which explores things you'll come across in your first job. Of course, with a bunch of pitfalls. I'm starting to go through it, already working.
Now there is such a fashionable word - full stack developer. It is possible that you will have to write not only server code, but also client code. Therefore, knowledge of html, xml, css and other layout will be useful.
I got a job after the third interview. I was looking for a job on hh, companies are distrustful of people without education and experience, so the only way we can win is with skills. What pleased me was that everywhere there was a rather friendly atmosphere and polite people with whom it was pleasant to communicate. Quote in the topic "I have never seen a person who would go to 20 interviews and they did not take him anywhere." Well, a fly in the ointment, where without it? You will have to devote a lot of time to this, and here the factor will play - whether you like it in general or not, because coding without desire is like torture. It is desirable to develop somehow in addition to work in order to be competitive. In the appendage, I can add about the obvious consequences of a sedentary lifestyle. All of the above is purely subjective. Small remark:I want to say a big thank you to the people who write success stories, it really motivates! I also want to say thanks to the creator of codegym for the resource itself and for such a developed community where people are ready to help each other in achieving common results.
GO TO FULL VERSION