Dismissal kit

• Knowledge of OOP and data structures;
• Java development experience for Android .;
• knowledge of the Android API, understanding of the architecture of Android;
• basic knowledge of HTTP, XML, JSON;
• experience with Git version control systems;
• experience with Android Studio, Gradle;
• experience with SQL databases;
• familiarity with the principles of Material Design;

Learned? Of course they did. This is one of the standard programmer resumes.

Personally, such a summary reminds me of one song , or rather one line of this song: “Zhiguli! Rides and is already good!

It also reminds advertising of the same Zhiguli, where the presence of ABS, rain and light sensors, etc. issued as a competitive advantage. Well, the famous slogan: "And this should be the car!".

And the programmer should be like this? If he wants to be like a Lada - massive, cheap and “as if not a machine programmer,” then yes.

But we are not so, so we will form and formulate our competitive advantage - a layoff package .



Dismissal kit- what remains with you when you change jobs. As Yuri Shevchuk sang, “This is what will remain after me. This is what I take with me. ”

The dismissal package is divided into parts:

1. solutions (finished or semi-finished products);
2. experience;
3. solved problems;
4. results achieved.

The division into parts, of course, conditional. Sometimes it is not clear what this or that element of the kit belongs to. Some guys still include a copy of the working base, but I personally do not recommend it.

So let's go in order.

Work for a future employer

I spoke this phrase at one of the conferences, and it caused a lot of different responses. Then there was no time to explain it in more detail, now corrected.

Working for a future employer is a basic principle on which to work with a dismissal kit.

At first glance, it seems that I propose to deceive the employer, engage in left-time job or sabotage.

This is not true. I propose a synergy that is beneficial both to you and your employer, and your future employer.

Consider an example.

You make a decision, something popular and popular - a dashboard that takes data from the corporate system and displays it on the web, via Google Charts or d3.

The current employer wants to see sales and cash flow. At least he told you so.

Nothing complicated. You can take requests for data to form arrays of the required dimension, and create a static js script using examples that the Google Charts or Recharts developers have carefully written. A static script needs to be built in somewhere, even on a TV in the director’s office, to set up a browser auto-update - that's all, you can make the employer happy.

Here you remember that you were going to change jobs. You never know, maybe in another city gathered to move. And you think - oh, but it would be nice to take a dashboard with you. The topic is popular, I'll show it straight at the interview on the smartphone, it's not 1C, the chart knows how to scale beautifully and roll over.

You have a question - what will a new employer want to see in a dashboard? Also sales and money? What if it will be retail, and you need an average check? Or will it be a distribution where TOC is implemented and they want to see the buffer status? What if it will be a php system, such as a bitrix, and then all requests will have to be rewritten.

Yeah, you think you need customization and isolation from a specific system. Let it be possible to make an arbitrary number of indicators that will be displayed on arbitrary dashboards.

Rested, done - beauty. You will come to a new job and immediately produce a wow effect.

But you quit. Transferred the case, told the new programmer about the dashboards and your other solutions, and left.

And then the changes began in your previous job. It took 10 more digits per dashboard. We acquired another company, accounting in the BP, there is also a need for a dashboard, for the period of automation according to the rules of the holding. We started the project on strategic changes - there is no way to do without a separate, large, beautiful dashboard - a strategic monitor.

All of the above is easily and quickly implemented by your dashboard, which remained at the same work. And at this time you are already making the new employer happy with the same dashboard.

Now we’ll stop and find out who has become happier:

1. You, because you got a head start and a competitive advantage in the interview;
2. Your new employer, because got either a ready-made solution or a proven idea that you quickly implemented (from memory);
   
   Now attention:
3. Your old employer, because Dashboard works fine without you, solving all new tasks in a short time, which means for little money;
4. And, oddly enough, new programmer, who came to work after you on the old job.

All the new numbers in the dashboard are already his results, albeit due to you. His results bring profit to him.

Total, 4 lucky ones. If you left the first version of the dashboard (with two requests and a static script), then only the old employer would be happy, and not for long. As soon as changes would begin for him, they would pair with a new programmer, curse you with the last words. One of the words would be "govnokoder".

Of course, you could also publish your dashboards on Git, then the number of lucky ones would increase significantly.

It is clear that making the right dashboard will take more time than the wrong one. But, believe my experience, the difference is very small compared to the benefits for all participants.

And here we have pure synergy. Instead of 1 = 1, we get 1 = 4. And all because working for the current employer, worked for the future.

And the last, to completely dispel doubts. It doesn't matter where you work now, where you worked before and where you will work. Basically you:

• Or solve current problems;
• Or solve future problems.

Both current and future tasks are with both employers - both current and future. So, making the right dashboard, you solve the future tasks of both.

Or in a different way: you solve the future tasks of your current employer. Tasks that will arise before him when you are already in another company.

Do you understand?

Probably, this can be called "solve the problems of the past employer." It also sounds unpleasant, like “solving the tasks of a future employer”. The whole trouble is connected with the point of reference - where you are, and where both employers are left or right along the time axis.

But now you understand that this is just a pun that spoils everything. Past, current, future. It gives some emotional, evaluative shades.

If the game of words is discarded, it becomes simple and clear.You work for the future.

Solutions

Let's start with legal issues. Usually taking with you pieces of code, modules, and libraries is wrong. A piece of the program, sort of like, is the intellectual property of the company in which it was created.

Therefore, I recommend focusing on ideas and decision chips, knowing that you can reproduce a solution at any time.

But, of course, if there is a situation where the decision can be taken entirely without legal consequences, then it is a sin not to take advantage.

Then everything is simple. Solving any problem, keep in mind the following questions:

• How often such tasks arise for the current employer?
• How often will such tasks arise in the future for the current employer?
• How often such a problem arises from other companies?

If you see that the task is repeated or will be repeated, then try to solve it in the abstract. So that your decision will be useful both to the future employer and to your current employer when you leave him.

To correctly answer these questions, it is necessary not only to program. We need to look at what others are doing - companies, programmers, vendors. To be aware of the development directions of platforms, frameworks, the industry as a whole.

There is even such a science - trend management, the study of trends. So she can do.

We'll have to follow the dynamics of changes in your company. How often does the org. structure, managers, accountants and financiers / economists, products, markets, etc.

All this knowledge will help influence your decision - whether to make an instrument abstract and rejected, or this time enough $ p.cat.byId (“000002341”).

In my life I didn’t make a lot of rejected decisions - about 50. Therefore, my set of firing is rather poor. I understood its value not so long ago, as sometimes I regret.

Although even such modest baggage came in handy to me many times. For example, when changing jobs.

Working on my first job, in franc 1C, I did refine production planning for SCP, which then went into the typical configuration. So, if you have 1C UPP, there is my govnokod.

My next employer wanted to automate production planning, and it was my previous work that attracted his attention to me — he could just see my decisions. I don’t even have to go anywhere - he had UPP too, and there was my code there.

Working at this place, I did a “Cost Structure”. It was a small report that checked the cost chains in multi-site production for the presence of discontinuities — incorrect analytics when releasing costs. I posted this report to the 1C partner conference, and found an eerie interest in it, because there was no cost solution to the standard solution.

As a result, for several days, the report has become the same as now, and has sold several thousand copies.

The next employer considered cost exploding to be one of the main tasks - historically, the practice of analyzing the cost of sales in terms of final costs has developed. When I came to the interview, they already knew about the “Cost Structure” - one of the francs showed them an Excel file with a cost tree unloaded. It remains only to say that the cost structure I did.

At the next work circle closed. The company worked with the French, from which I started my career, and they naturally asked the French about my experience and solutions. Production planning was remembered, along with the “Cost Structure”, and here I am again easily getting a job. Here again I made an arbitrary allocation of costs.

Now I am programming in javascript. But some of the solutions from 1Cn past are so good in the sense of my idea that I will reproduce them in javascript so that they work in solutions on metadata.js. For example, the same universal scheduling mechanism, only it will no longer be an application solution, but a platform one — a customized accumulation register automatically recalculated in the background.

Is there any benefit in those companies where I left? Of course.

Production planning in company number 2 has evolved (not without my participation) into a smart inventory and procurement management system. There also remained a mechanism for allocating costs and calculating the planned cost, which, after a change in accounting policies, was quickly reconfigured and continued to bring benefits.

Company number 3 successfully used the cumulative cost structure calculation until it was sold.

Company number 4 uses all the solutions from my set of layoffs, and does not even think of abandoning them after my departure. The programmers who stayed there are slowly developing these solutions. All changes occurring in business processes (there are a lot of them) are easily and quickly made to customize solutions.

Of course, you can find a lot of similar examples from your practice, and certainly more interesting than mine. Abstract solutions are synergy.

Experience

With experience everything is clear - you need to earn it. The main thing, in my opinion, is to do it in a controlled and systematic way. Experience is even better than solutions, because there are no legal ways to take it from you.

Your employer and your boss, in general, do not care how and what experience you accumulate. You can be put on the same tasks that do not require the development of qualifications. Of course, there are the right bosses who control the accumulation of experience, but this is rare. Usually, everything is limited to a rare reference to courses that are usually of little use.

Therefore, you should take care of your own experience. And the main thing here is goals and measurability. According to the principles set forth in the article .

The most useful experience is the one that was obtained while solving problems. If you have done the integration of the site and KIS, then you can assume that you have gained some experience. If you use already configured integration, then you get much less experience. If the second time you do the integration of CIS with the site, then your experience increases. Etc.

Do you understand? The key is a composite: a practical solution of problems + their number.

To know exactly how and what experience is gained from me and my staff, I took a model from computer games.

There are games where the model of experience does not look like real life. For example, Fallout, with all due respect and unrestrained 20-year love for this series. There you simply accumulate experience points, and then spend them on developing those qualities that you deem necessary. This is a model that describes paid education. Gained money - went to courses, such as English or project management. This is not suitable for us, it is for sugary top managers.

More close to life is the model of accumulation of experience in Elder Scrolls. I am old, so I played in ES 3 Morrowind, and I will keep it in mind.

So, in Morrowind, you improve the characteristics that you use in practice. Waving a sword - the ability of a sword grows. Conjure - the ability of witchcraft increases. Etc. When I played, I had a high Acrobatics ability - exactly because I once was stuck in some mountains, there was no levitation potion, and I jumped a lot to get out of there. Jumps develop acrobatics.

At my last job I started such a system. In the system there were tasks, and I attached the “Competences” table to them, and at the same time - the qualifier of competencies. When a person solved a problem, I listed the competencies that were necessary to demonstrate in order to solve it. And put the degree of application of competence, in conditional percentages. As a result, statistics began to accumulate, and for each employee, charts appeared similar to those that we see in the profiles of some professional sites.

Then, considering myself a good boss, I began to diversify the competencies of my subordinates. If I see that one gained a lot of experience on the tasks of requests for alasql, then I stopped giving him such tasks, and gave them to those who have little such experience. Of course, without fanaticism - if the task is urgent, then it got the most experienced.

At conferences, I mentioned that I allocated up to 30% of the time for an employee to such “tasks for enhancing experience”. It is clear that the company is not a university. We need a balance between speed and experience, because without expansion of experience, speed will reach the ceiling and potential will be lost.

When you work in a team, experience diversification is important not only in terms of interchangeability. Of primary importance is the presence of interlocutors who will help in the discussion of the problem, brainstorming, making architectural and technical decisions. If only one person in the team sketches a topic, then there will be no one to talk to him.

One of the advantages of such a system is the ability to set goals and embed these goals in the system for selecting priorities and performers.

For example, we set the following goal: Piglet must score 50 conditional integration points - any tasks related to queries, caching short data packets, etc. The system for each new task automatically calculates to whom it is better to give it - the difference between the goal and the current position. And you sit and control how your goal is achieved.

To introduce and apply such a system is possible in one, for yourself. Of course, if you have a goal - to earn experience, in which you will be sure. The advantage of this approach is that you don’t need to ask anyone for permission — you can count your experience at least in a notebook, at least in an Excel file. So, probably, even better, because the file will always be with you - you can make the accumulation of experience through, not dependent on the specific employer.

Solved problems

On the one hand, this is such a trick to impress HR. On the other hand, an understanding of solved problems will help you focus on products all the time, not on the process.

I was the IT director, so I often went to interviews for a variety of people, not just IT staff - we had a system of cross-interviews.

And I noticed that HR divides people into two categories - process oriented and result oriented.

They divide first by resume, then during the interview, paying attention to the wording. If the wording sounds like “automated sales”, then this is a process. If it sounds like “created and launched an automated sales system”, then this is the result.

"Processors" usually do not favor. This is not good, not bad - just like that.

Therefore, it is better to write a summary through the prism of solved problems, and not the process of their implementation.

But, now you understand - to write solved problems, we need solved problems. To be honest with ourselves, we all know that programmers do not always solve problems. Engaged in solving problems - yes. Decide - no. We have already spoken about how the task in the process is completely forgotten . By the way, a good example of how tasks are not forgotten can be seen in the portfolio of the Artemy Lebedev Studio - there is a task written in each project that they solved. I don’t presume to say that they directly solve problems in a qualitative manner, but Lebedev himself calls it a competitive advantage of his studio.



By the way, in each project they still have employees who made it. This is gorgeous - a layoff package is freely available forever. Enough to give a link. It is clear that this is the specifics of web development, but not all studios and web-makers write the names of the people who made the project.

Back to us. Since we work for a future employer, it is important to understand and be able to formulate the task that you are solving. Just imagine - in a year, or two, or a month you will have to tell you what the task was before you, how you solved it, and whether you decided at all.

In fact, you need to become an observer, a journalist, a biographer or a manager of yourself - choose a word you like. One half of you is working hard, the second is watching, remembering (or, better, writing) and preparing your tasks to be sold to the next employer. Marks the chips, the difficulties and how you overcome them, what technologies you have mastered on the road, how you implemented them, how you accompanied and eliminated obstacles.

Each solved task - clear, formulated, and preferably abstract - fills up your dismissal kit.

Results achieved

It so happens that you do not set a specific task, and set vague. For example, they say "improve system performance," and not "reduce transaction commitments by half." Or they say “to increase the efficiency of problem solving by programmers”, and not “to reduce the time for execution of requests by 30%.

When a figure sounds in the wording, this is a task, and it should be treated as written in the previous section. When the numbers are not there, you will have to measure it so that there is something to write in the dismissal kit.

For example, you are engaged in performance. The recording time of documents in the system. I am sure that you will succeed - you will reduce the time of recording documents. What then say a future employer? "I have reduced the time for writing documents." What do you hear in response? How much reduced. How much was, how much has become, how much was carried.

To answer these questions, it is enough to measure. Still not having started the task, put the measurement system as objective as possible, because the measurement system is part of the solution. You will surely be asked "how was it measured?". Well, proceed to the solution.

When you reach the required level, remember the numbers, first and last. And even better - save the graph of the change in numbers over time, marking on it the key events - your actions to change the numbers.

I have done this many times, and this is very, very! - helps. First, it helps in the process, because you understand where you are and where you are going. You can evaluate your progress and the effectiveness of your actions. Secondly, it is useful for the current employer - he gets a better and more understandable result. The measurement system, which itself becomes a product, will be used after you leave, and the employer will have one coordinate system for the end-to-end analysis of the same indicators.

Third, and most importantly, it will help you in your next job. Especially if you manage to express your numbers in the coordinate system of the new company. And it is not difficult. The same time of recording documents - it is measured everywhere in milliseconds.

Total

It might seem to you that a layoff is a kind of cumulative resume. On the one, visible side, this is true.

But the point is not what you can show , but what you really have in your baggage. This is a kind of product, the result of the investment of their time in each employer.

This is a synergistic use of time spent.

You can just sit and get a salary, or what is your motivation system. At the entrance to the company and exit from it, in the bottom line, you just aged. If you managed to save some money or something worth buying, then it is still not bad. If not, they didn’t save money, and they didn’t increase their assets, and they didn’t have enough experience, and they didn’t create any solutions, they didn’t solve the tasks, and didn’t achieve results, then this is very sad.

It sounds trite, but I have seen a lot of programmers who do not change at all when moving from one place to another. Consciously looking for work on which you need to solve familiar problems . It is clear that in the short term so safer. But what about the long term?

If you work for a future employer, then your baggage, your value, your set of dismissal is constantly growing. This is the right investment.