Conference Attendance - Checklist
This article appeared after drinking beer with friends in Akademgorodok - it became clear that it was better to transfer it to the text form, so as not to repeat a hundred times.
There are legends on the topic that the only meaning of the conference is to find a better job for the money of the current employer. Despite the external unethical, at least there is a sense. In reality, it is much worse: people come to konfu, and then they don’t know what to do, except for howling buns in the transition (especially if they are free). Let me tell you what to do to avoid wasting your own and other people's resources in vain.
The main problem of the developer is that skills, technologies, ideas - all this is constantly becoming outdated. Once upon a time dinosaurs lived on earth, and now they are not. You definitely do not want to be one of these dinosaurs. To do this, you need to focus on updating your own knowledge - this is important and given the highest priority. This is so important that you are ready to spend your and other people's money and time on it.
Human thinking is so arranged that it does not tolerate anything unnecessary. Isolation of the important and unimportant is one of the most striking and tough systems that allows you to think as efficiently as possible.
')
The book Moonwalking with Einstein told about a journalist with a phenomenally good memory, who never needed to write anything down on notes and dictaphones, including long interviews. He got this memory due to the fact that his brain considered all the events around him equally important, and equally worthy of memorization. This feature completely destroyed the life of this person. All his life he tried to focus on everything at once, and never achieved anything concrete.
The developers of the usual software are not like this journalist. We constantly want very specific, obvious things: interesting projects (and usually they know exactly what it means "more interesting", more opportunities, higher positions, more money - and all this as quickly as possible. This requires a specific focus on its tasks, discarding illusions and morals (in the sense, corporate bullshit of the type “it is a great honor to work in our company”).
The most central idea is that the very same focus should be maintained when visiting any information events.
Then I will try to show how you can update your knowledge using conferences (and other organized events) as a key point in this continuous updating of knowledge and skills.
Any fairly complex, extended in time action, must begin with a plan. The absence of a plan is also a plan, only a bad one. As we see, we have little choice: either we write the plan, or we write it for us. "The Duma is not a place for discussion."
Let's mark out some strong points:
Realize why you need a conference, determine the meaning. Set aside at least 2 minutes.
As one comrade said, “everyone comes for their own. Who wants to change jobs - for the offer, who wants to understand the technology - for advice, who has trouble in production - for recommendations of the best dog breeders. ”
You can use the "help of a friend" or the "hint of the hall" - the conference organizers in advertising materials will certainly tell you why it is needed. Anything to buy a ticket. But I strongly advise you to realize the meaning yourself, because it may not be .
Devopsera lucky, we search for the meaning is simple.
For example, there are people who can edit two lines of code for weeks trying to get some complicated formula to work out, or fix a complicated problem in the legacy system. We are constantly haunted by a boa:
If you are constantly haunted by scary monsters, you need to do something about it, right?
Every second wants to be a Docker god, easily twisting thousands of containers, and you burn and you are in hell.
Unfortunately, just having meaning is not enough.
(Warning: This part will be big, no time - you can safely skip)
Imagine a java developer starting to prepare for the next interview. What might his checklist look like?
As you can see, a notable portion of every borsch is added to “pure programming” dedicated to algorithms and hardware. How much to put bread? Maybe two more compotes and four days on Grafana?
The development manager has exactly the same problems. Instead of pieces of paper glued to the refrigerator, there will be multi-volumes of “architectural visions”, tasks and descriptions that need to be turned into something more intelligible.
There is one excellent example - which, by default, unfortunately, is understandable only to the gamers in modern online games. The term metagame is well known. I'll try to explain in a couple of words. As if there are core mechanics - the actual rules of the game, and meta mechanics - those effective methods of action that players come up with themselves. For example, in football, core mechanics are actually the rules of football, and meta is the choice of the optimal team composition, strategies and tactics of conduct on the field. In poker, core is the rules of poker (which are two times and misaligned), and meta is the rest of the game, the strategy of the player, hold the chips to the last table, do not risk and play tight, take the blinds preflop, and so on.
Usually, unbalanced games (for example, most modern moba) always have “dominant meta” - a set of highly effective ways of playing, which are very dependent on the specific characteristics of your characters, which change with each new update. Meta, which was popular last year, does not play at all today, despite the fact that the composition of the characters and their abilities have not changed much. Once Overwatch was always played 2-2-2, but now it’s gone. To learn how to play the same game, the same characters, but with a new meta, on a professional level, the player is required to invest effort, sometimes significant. It’s as if football rules changed every Sunday.
With technologies, about the same thing happens that in moba it is a continuous metagame over the same ideas, and often the same implementations. Do you have a bunch of technologies related to each other in relation to "all with all", having different weights in the menu of a complex lunch? Being a sysadmin, your core game rules include GNU / Linux and Monitoring. A Java programmer in 2017 will definitely meet on the path of Spring and Hibernate. Although it will be absolutely not the same Linux and Spring, which were in 2003 (about systemd and Spring Cloud can be commented in the comments). The same ideas of proper monitoring or organization of collections wander from year to year, from technology to technology, always the same - and always a little bit different. Sometimes you like them, sometimes you disagree with them in something - but you get to know them and move on.
But to adapt to all this is very difficult. Tried to subscribe to Gitkhab for all interesting projects and keep track of fresh commits? It is unreal. Well, except that you don’t really have much interest, or you’ve stumbled and are ready to spend all your work and free time on it The same applies to monitoring news sites, RSS feeds and mailing lists of projects, etc. Moreover, for a deep understanding of the metagame it is not enough just to read them - you need to analyze and experiment, try options. You may have to hire several architects who will do it instead of you, and pay them horse salaries for it? That was the sad part.
The pleasant part is that synchronization with meta can and should be done quite rarely. Say every six months.
And here is the perfect conference. The best specialists in their field come to them, who specially prepared for this report for months, selected a convenient form of serving for you, any dish will be eaten in an hour. All complex lunch is eaten in a day. Lunch menu, conference tracks - are notable gurus who know a lot about the question. After that, you have only half a year or a year to try to at least somehow keep up with the meta. Half a year - because then there will be the next conference. An elegant, convenient solution. Of course, there are also disadvantages - you have to spend energy to get into the plane and drag your carcass to the spot, but IMHO, on the whole, this minus is completely covered with pluses.
Therefore, the second tip would be: take the conference / meeting as a set of tasks to be completed in the next six months. As a kind of checklist or addition to backlog. All tasks are optional, but if you do not work out a sufficient number of topics, then you can seriously get stuck in the future. It is important that these are not some “ready-made solutions” of your problems (for this purpose there is StackOverflow), namely, a list of strategic tasks, trends.
As in any other project, we must have a very clear temporary structure. While there is no plan - you spend time on garbage. Anyone who is not rich enough to quietly spend time on nonsense should attend to the following:
Usually, the concept is divided at least into the following:
Obviously, “for yourself” the idea looks like “listen to report X, talk to Y personally, and get drunk on the afterparty.”
Just do not need to communicate this to the employer, because he is usually not so interested in what you know there, like what you are going to do with all this in a particular project. He can be formulated in a more specific way: “I am going to improve Y in draft X by using A, B, C, to which the conference is dedicated”. The explanation is desirable to come up with a capacious and pretentious, having tasted with your favorite headmaster.
It is always necessary to invent a concept for an employer, regardless of whether he pays for your tickets or not. Firstly, in any case, this is an advertisement for you personally (fuckers and rooks don't go to konfa, or at least that is the legend). Secondly, even if the employer does not see the benefits from such activities right now, in your experience, he can see this benefit, and next time everything will be completely different.
It's all ordinary:
About this nonsense you need to worry in time, because:
I saw a huge number of people who dried all polymers simply because they decided to issue papers "tomorrow morning." Start filling damn paper right now.
This is the most interesting point of the program.
Learning works best as follows:
Holivarny example:
The idea is crystal clear from school, I guess.
Konfa or mitap is very similar to this plan of the experiment. Only we experiment not with non-living objects or programs, but with speakers and their reports. There is a discussion area at decent conferences, so you can put the tests directly on the speaker.
Now, what happens when we come to konfu without preparing? There are no two fundamental points of the program: we are not familiar with the things we are discussing, and we have no idea what we are going to check. Epic Fail. It remains either to marvel at the incomprehensible things that are broadcast from the stage, or to eat buns in the transition.
In order not to be a fool before going somewhere, and generally agreeing to konfu, it is necessary to study its program and draw up a training plan.
Next, I copied from a recent article on the DevOops 2017 conference plan:
Check out how the perception of this list changes immediately, as you understand, that this is not just a list of something that men will push from the stage, but a list of things that you personally need to urgently get acquainted with in advance. He starts to look gigantic.
It is important that preliminary preparation should take some rather short time, for example, a total of one hour per day. Otherwise, the usual lazy developer (such as the author of this note) is frozen and stops preparing. The simple way is that you don’t need to study all of the above, but only one word from each item, this will greatly facilitate the task.
Now we classify the sources of information on which we will conduct preliminary training.
Just take any technology and start using it.
Use anywhere:
You do not need to spend a huge amount of time, it is enough to make a couple of working prototypes to hook on the main ideas. For example, in order to get Ansible and do something for them, it takes a few minutes, plus it can be immediately applied at work.
The method is good because, unlike all sorts of tutorials, it gives an understanding about the things that you personally need, and not the kind uncle who wrote the documentation on the site.
Now we all spend on social networks just an unforgivable amount of time. It is enough to open Habr or Facebook, and get stuck for the whole day. The way to use procrastination with benefit is to start reading technical blogs on the right topics.
To deceive your brain, so that it still considers it rest and procrastination, and not a new type of work, you can set some clear alarm clock: for example, we read about Ensibl for no more than 30 minutes, and then go back to work!
Now I will not litter here, describing the entire first page of Google on the “Docker Blog”, they are all interesting there. If you, the reader, have any favorite blogs, write about them in the comments!
Perhaps the topic of devops blogging should devote a separate post. Do you need it? Write in the comments.
I just want to note that the best materials are those that are marked in time. To make it clear what exactly the events, and in what order, occurred in the last year. Compare "as it was" and "as it became." Then look "as it became" at the conference and compare
Oddly enough, in 2017, the books still have not become obsolete. Unlike fragmentary tweets and posts in blozhikah, they represent a condensed and repeatedly proven wisdom, especially with regard to textbooks on fundamental technologies.
Some tips on using books:
There are a huge number of videos on YouTube that will help you quickly tune in the right way, for example, DockerCon 2017 . Especially cool are the videos of previous conferences: you can see “what was” and “what became”, how the attitude of the speakers on various issues changed from year to year.
Good recommendations have recently been published here in this recent article on Habré .
This could be the end, but the main thing is:
Separately about the records. If thoughts are not immediately recorded, then under the pressure of a powerful flow of information they are quickly forgotten. Voice recorders at such events often work poorly due to the acoustics of the halls and the speed of the voice recorder (you can buy a good voice recorder). For me personally, mind maps work best on a laptop. I like the paid Mindjet MindManager, but there are a bunch of free utilities (google: “best free mind mapping software 2017”). If we add this to the report slides (speakers usually post them on the Internet), a very good base is obtained.
Implementing anything from a conference is associated with several difficulties.
First, the conference materials are not quick fixes for personally solving your problems. Speakers are not your employees. It’s just not possible to copy a report and throw something at yourself. Therefore, we can treat the information received as trends, trends that need to be considered and worked out.
To have something to work out, you need to have:
Next comes the actual development of the topic. For example, if we first met Kubernetes at a conference, then we should not run and introduce it. It is worth exploring the topic comprehensively and take it as seriously as possible.
Secondly, usually the introduction of innovations depends not only on you, but also on the managers. Leaders often relate to conferences, and information received from them, without much joy. "Some kind of bullshit stuff." Changing this attitude is often helped by just a normal dialogue with a description of the emerging prospects.
Here you could write a manual for conducting presentations for the manual, but this is the topic of a separate article. I confine myself to the main thoughts.
The most important thing is how to apply the introduction of new technology. Usually, we, techies, just crush the interlocutor with intelligence. But if you are trying to convince the boss to test some completely new thing, that critical amount of knowledge may not yet exist. Then you can crush the interlocutor with common sense. Common sense should start with a type description:
Once again, since we did not receive specific quick fixes at the conference, but a snapshot of trends, we must thoroughly prepare before entering into such a dialogue.
Often the authorities get used to communication in the form of a slide show. You can count it, and just modify the slides from the conference, since there is a public link to them.
But slides for a huge konfa are being prepared for viewing from a large screen.
I usually recycle them like this:
It was a short checklist, which is worth considering before attending the conference. If you are
, , .
-, , , , .
.
There are legends on the topic that the only meaning of the conference is to find a better job for the money of the current employer. Despite the external unethical, at least there is a sense. In reality, it is much worse: people come to konfu, and then they don’t know what to do, except for howling buns in the transition (especially if they are free). Let me tell you what to do to avoid wasting your own and other people's resources in vain.
0. Goal setting
The main problem of the developer is that skills, technologies, ideas - all this is constantly becoming outdated. Once upon a time dinosaurs lived on earth, and now they are not. You definitely do not want to be one of these dinosaurs. To do this, you need to focus on updating your own knowledge - this is important and given the highest priority. This is so important that you are ready to spend your and other people's money and time on it.
Human thinking is so arranged that it does not tolerate anything unnecessary. Isolation of the important and unimportant is one of the most striking and tough systems that allows you to think as efficiently as possible.
')
The book Moonwalking with Einstein told about a journalist with a phenomenally good memory, who never needed to write anything down on notes and dictaphones, including long interviews. He got this memory due to the fact that his brain considered all the events around him equally important, and equally worthy of memorization. This feature completely destroyed the life of this person. All his life he tried to focus on everything at once, and never achieved anything concrete.
The developers of the usual software are not like this journalist. We constantly want very specific, obvious things: interesting projects (and usually they know exactly what it means "more interesting", more opportunities, higher positions, more money - and all this as quickly as possible. This requires a specific focus on its tasks, discarding illusions and morals (in the sense, corporate bullshit of the type “it is a great honor to work in our company”).
The most central idea is that the very same focus should be maintained when visiting any information events.
Then I will try to show how you can update your knowledge using conferences (and other organized events) as a key point in this continuous updating of knowledge and skills.
1. Plan
Any fairly complex, extended in time action, must begin with a plan. The absence of a plan is also a plan, only a bad one. As we see, we have little choice: either we write the plan, or we write it for us. "The Duma is not a place for discussion."
Let's mark out some strong points:
- Assumptions
- Milestones
- Specific Tasks
2. Assumptions
2.1 Assumption: the meaning exists
Realize why you need a conference, determine the meaning. Set aside at least 2 minutes.
As one comrade said, “everyone comes for their own. Who wants to change jobs - for the offer, who wants to understand the technology - for advice, who has trouble in production - for recommendations of the best dog breeders. ”
You can use the "help of a friend" or the "hint of the hall" - the conference organizers in advertising materials will certainly tell you why it is needed. Anything to buy a ticket. But I strongly advise you to realize the meaning yourself, because it may not be .
Devopsera lucky, we search for the meaning is simple.
For example, there are people who can edit two lines of code for weeks trying to get some complicated formula to work out, or fix a complicated problem in the legacy system. We are constantly haunted by a boa:
If you are constantly haunted by scary monsters, you need to do something about it, right?
Every second wants to be a Docker god, easily twisting thousands of containers, and you burn and you are in hell.
Unfortunately, just having meaning is not enough.
2.2 Assumption: noble sirs do not cook porridge
(Warning: This part will be big, no time - you can safely skip)
Imagine a java developer starting to prepare for the next interview. What might his checklist look like?
- Java Core, Collections, Concurrency (14d)
- Spring, Spring MVC (7d)
- Hibernate, SQL (7d)
- JS (Angular, React) (7d)
- Testing, TDD (2d)
- Building (Maven, Nexus) (1d)
- VCS (Git, Mercurial) (2d)
- Jenkins (1d)
- GNU / Linux Monitoring (2d)
As you can see, a notable portion of every borsch is added to “pure programming” dedicated to algorithms and hardware. How much to put bread? Maybe two more compotes and four days on Grafana?
The development manager has exactly the same problems. Instead of pieces of paper glued to the refrigerator, there will be multi-volumes of “architectural visions”, tasks and descriptions that need to be turned into something more intelligible.
There is one excellent example - which, by default, unfortunately, is understandable only to the gamers in modern online games. The term metagame is well known. I'll try to explain in a couple of words. As if there are core mechanics - the actual rules of the game, and meta mechanics - those effective methods of action that players come up with themselves. For example, in football, core mechanics are actually the rules of football, and meta is the choice of the optimal team composition, strategies and tactics of conduct on the field. In poker, core is the rules of poker (which are two times and misaligned), and meta is the rest of the game, the strategy of the player, hold the chips to the last table, do not risk and play tight, take the blinds preflop, and so on.
Usually, unbalanced games (for example, most modern moba) always have “dominant meta” - a set of highly effective ways of playing, which are very dependent on the specific characteristics of your characters, which change with each new update. Meta, which was popular last year, does not play at all today, despite the fact that the composition of the characters and their abilities have not changed much. Once Overwatch was always played 2-2-2, but now it’s gone. To learn how to play the same game, the same characters, but with a new meta, on a professional level, the player is required to invest effort, sometimes significant. It’s as if football rules changed every Sunday.
With technologies, about the same thing happens that in moba it is a continuous metagame over the same ideas, and often the same implementations. Do you have a bunch of technologies related to each other in relation to "all with all", having different weights in the menu of a complex lunch? Being a sysadmin, your core game rules include GNU / Linux and Monitoring. A Java programmer in 2017 will definitely meet on the path of Spring and Hibernate. Although it will be absolutely not the same Linux and Spring, which were in 2003 (about systemd and Spring Cloud can be commented in the comments). The same ideas of proper monitoring or organization of collections wander from year to year, from technology to technology, always the same - and always a little bit different. Sometimes you like them, sometimes you disagree with them in something - but you get to know them and move on.
But to adapt to all this is very difficult. Tried to subscribe to Gitkhab for all interesting projects and keep track of fresh commits? It is unreal. Well, except that you don’t really have much interest, or you’ve stumbled and are ready to spend all your work and free time on it The same applies to monitoring news sites, RSS feeds and mailing lists of projects, etc. Moreover, for a deep understanding of the metagame it is not enough just to read them - you need to analyze and experiment, try options. You may have to hire several architects who will do it instead of you, and pay them horse salaries for it? That was the sad part.
The pleasant part is that synchronization with meta can and should be done quite rarely. Say every six months.
And here is the perfect conference. The best specialists in their field come to them, who specially prepared for this report for months, selected a convenient form of serving for you, any dish will be eaten in an hour. All complex lunch is eaten in a day. Lunch menu, conference tracks - are notable gurus who know a lot about the question. After that, you have only half a year or a year to try to at least somehow keep up with the meta. Half a year - because then there will be the next conference. An elegant, convenient solution. Of course, there are also disadvantages - you have to spend energy to get into the plane and drag your carcass to the spot, but IMHO, on the whole, this minus is completely covered with pluses.
Therefore, the second tip would be: take the conference / meeting as a set of tasks to be completed in the next six months. As a kind of checklist or addition to backlog. All tasks are optional, but if you do not work out a sufficient number of topics, then you can seriously get stuck in the future. It is important that these are not some “ready-made solutions” of your problems (for this purpose there is StackOverflow), namely, a list of strategic tasks, trends.
3. Milestones
As in any other project, we must have a very clear temporary structure. While there is no plan - you spend time on garbage. Anyone who is not rich enough to quietly spend time on nonsense should attend to the following:
- Define a concept
- Provide resources (tickets, time, etc.)
- Conduct information training
- Participate in the conference
- Embed learned
- Go to the next iteration (six months or a year)
4. Tasks
4.1 Definition of the concept
Usually, the concept is divided at least into the following:
- For myself
- For employer
- For friends and others
Obviously, “for yourself” the idea looks like “listen to report X, talk to Y personally, and get drunk on the afterparty.”
Just do not need to communicate this to the employer, because he is usually not so interested in what you know there, like what you are going to do with all this in a particular project. He can be formulated in a more specific way: “I am going to improve Y in draft X by using A, B, C, to which the conference is dedicated”. The explanation is desirable to come up with a capacious and pretentious, having tasted with your favorite headmaster.
It is always necessary to invent a concept for an employer, regardless of whether he pays for your tickets or not. Firstly, in any case, this is an advertisement for you personally (fuckers and rooks don't go to konfa, or at least that is the legend). Secondly, even if the employer does not see the benefits from such activities right now, in your experience, he can see this benefit, and next time everything will be completely different.
4.2 Resource Provision
It's all ordinary:
- If you go to the company money
- Declare to management to be present
- Of necessity - to come up with an argument for persuasion.
- If you go for your money - buy tickets:
- The conference
- Aircraft
- Hotel / Hostel
About this nonsense you need to worry in time, because:
- Some conferences offer crazy discounts on pre-order tickets.
- Hotels and airplanes, if ordered in advance, can cost much less.
- Some companies need to state a budget for the year ahead. Or for a month.
If you do not tell the employer right now, then the train has left.
Also, employers do not like the sudden desire to highlight a good hotel. - Some companies are going to the conference only if you are not going to quit the next six months. If you are going to - you need to think about timing.
I saw a huge number of people who dried all polymers simply because they decided to issue papers "tomorrow morning." Start filling damn paper right now.
4.3 Information Preparation
This is the most interesting point of the program.
Learning works best as follows:
- For some time, intuitively study X
- Come up with a theory about X
- Make a guess how X should work
- Set up an experiment and find out how X actually works.
- Based on the difference between assumption and reality, adjust the theory
- Go to the next iteration of theory improvement.
Holivarny example:
- Use the windows server for a while, making the overall impression
- The theory is that Linux is much better than Windows as a file dump.
- Assumption: having made a file dump on Linux, we will not get the problems that were in Windows
- Experiment: we do file swapping on Linux and find that in some cases there are problems, and in some cases - no
- Correction: Linux is better than Windows as a file cleaner only in some cases.
- Next iteration: determining when it’s better and when it's worse
The idea is crystal clear from school, I guess.
Konfa or mitap is very similar to this plan of the experiment. Only we experiment not with non-living objects or programs, but with speakers and their reports. There is a discussion area at decent conferences, so you can put the tests directly on the speaker.
Now, what happens when we come to konfu without preparing? There are no two fundamental points of the program: we are not familiar with the things we are discussing, and we have no idea what we are going to check. Epic Fail. It remains either to marvel at the incomprehensible things that are broadcast from the stage, or to eat buns in the transition.
In order not to be a fool before going somewhere, and generally agreeing to konfu, it is necessary to study its program and draw up a training plan.
Next, I copied from a recent article on the DevOops 2017 conference plan:
- Containers, Orchestration (Docker, Kubernetes, Clusters, etc).
- Virtualization, Cloud Technologies (AWS, Azure, Heroku, and others).
- Monitoring and auditing applications (Prometeus, OkMeter, DataDog, BPF, Dynatrace, XRebel, Glimpse, Zipkin, OpenTrace and others).
- Continuous Delivery (Jenkins, TeamCity, Bamboo).
- Configuration Management (puppet, chef, ansible).
- Security (Vault, etc.)
- Debriefing on examples of large projects implementing DevOps: successful and failed.
Check out how the perception of this list changes immediately, as you understand, that this is not just a list of something that men will push from the stage, but a list of things that you personally need to urgently get acquainted with in advance. He starts to look gigantic.
It is important that preliminary preparation should take some rather short time, for example, a total of one hour per day. Otherwise, the usual lazy developer (such as the author of this note) is frozen and stops preparing. The simple way is that you don’t need to study all of the above, but only one word from each item, this will greatly facilitate the task.
Now we classify the sources of information on which we will conduct preliminary training.
4.3.1 Targeted use of something new
Just take any technology and start using it.
Use anywhere:
- Build a small test project
- Help a colleague or friend who already uses it in practice
- Use at work if possible
You do not need to spend a huge amount of time, it is enough to make a couple of working prototypes to hook on the main ideas. For example, in order to get Ansible and do something for them, it takes a few minutes, plus it can be immediately applied at work.
The method is good because, unlike all sorts of tutorials, it gives an understanding about the things that you personally need, and not the kind uncle who wrote the documentation on the site.
4.3.2 Blogs
Now we all spend on social networks just an unforgivable amount of time. It is enough to open Habr or Facebook, and get stuck for the whole day. The way to use procrastination with benefit is to start reading technical blogs on the right topics.
To deceive your brain, so that it still considers it rest and procrastination, and not a new type of work, you can set some clear alarm clock: for example, we read about Ensibl for no more than 30 minutes, and then go back to work!
Now I will not litter here, describing the entire first page of Google on the “Docker Blog”, they are all interesting there. If you, the reader, have any favorite blogs, write about them in the comments!
Perhaps the topic of devops blogging should devote a separate post. Do you need it? Write in the comments.
I just want to note that the best materials are those that are marked in time. To make it clear what exactly the events, and in what order, occurred in the last year. Compare "as it was" and "as it became." Then look "as it became" at the conference and compare
4.3.3 Books
Oddly enough, in 2017, the books still have not become obsolete. Unlike fragmentary tweets and posts in blozhikah, they represent a condensed and repeatedly proven wisdom, especially with regard to textbooks on fundamental technologies.
Some tips on using books:
- Do not read from cover to cover. See the table of contents, and read only what is interesting. The time to prepare for the conference is very limited, if you stick into one book with a length of 1500 pages, there is no time left for anything else.
- Do not be afraid that the current chapter is based on the previous one so that by skipping it, you will not understand anything. Usually - you will understand. The exceptions are, for example, books on algorithms and discrete.
- Read books on fundamental things. For everything else, there is documentation on the Internet and StackOverflow.
- If the book looks as if the author simply transferred the documentation from the official site of the project to paper - then you can not read in the oven.
4.3.4 Video
There are a huge number of videos on YouTube that will help you quickly tune in the right way, for example, DockerCon 2017 . Especially cool are the videos of previous conferences: you can see “what was” and “what became”, how the attitude of the speakers on various issues changed from year to year.
4.4 Participation in the conference
Good recommendations have recently been published here in this recent article on Habré .
This could be the end, but the main thing is:
- Determine in advance that you are going to listen.
(If there is nothing interesting, then you can not go to konfa) - If you are going to crowd from one company, you can be divided according to different reports.
Who will go where - also decide in advance - Take a notebook or smartphone with you to record interesting moments and thoughts.
- Be sure to catch the speaker in the discussion area. Do not be afraid to ask strange and uncomfortable questions.
- Think over the questions - where to eat and sleep. I do not write here, not small already
Separately about the records. If thoughts are not immediately recorded, then under the pressure of a powerful flow of information they are quickly forgotten. Voice recorders at such events often work poorly due to the acoustics of the halls and the speed of the voice recorder (you can buy a good voice recorder). For me personally, mind maps work best on a laptop. I like the paid Mindjet MindManager, but there are a bunch of free utilities (google: “best free mind mapping software 2017”). If we add this to the report slides (speakers usually post them on the Internet), a very good base is obtained.
4.5 Presentation and Implementation
Implementing anything from a conference is associated with several difficulties.
4.5.1 Quickfix vs trending topic
First, the conference materials are not quick fixes for personally solving your problems. Speakers are not your employees. It’s just not possible to copy a report and throw something at yourself. Therefore, we can treat the information received as trends, trends that need to be considered and worked out.
To have something to work out, you need to have:
- The memory of what happened at the conference
(at least, you should not drink too much alcohol during and after the conference, otherwise you will forget everything) - Records: notepad, tape recorder, maydmap, etc.
- Conference video recordings (they are not everywhere, and certainly not immediately)
Next comes the actual development of the topic. For example, if we first met Kubernetes at a conference, then we should not run and introduce it. It is worth exploring the topic comprehensively and take it as seriously as possible.
4.5.2 Presentation of the topic
Secondly, usually the introduction of innovations depends not only on you, but also on the managers. Leaders often relate to conferences, and information received from them, without much joy. "Some kind of bullshit stuff." Changing this attitude is often helped by just a normal dialogue with a description of the emerging prospects.
Here you could write a manual for conducting presentations for the manual, but this is the topic of a separate article. I confine myself to the main thoughts.
The most important thing is how to apply the introduction of new technology. Usually, we, techies, just crush the interlocutor with intelligence. But if you are trying to convince the boss to test some completely new thing, that critical amount of knowledge may not yet exist. Then you can crush the interlocutor with common sense. Common sense should start with a type description:
- Problem.
Need to pull some real problem from the current project. - Decision.
Here follows the name of your favorite technology with a brief comment.
You do not need to throw out all the depth of technical thought on a person, for the beginning it is necessary that the name of the technology should crash into memory and be settled there forever. - Conceptual description of the road to success.
For example, you say that in the presence of an additional two people and a week of time, we are introducing technology, and we get such a profit. Here you need to focus on the business aspects: money, time, a set of paid solutions, and so on. However, it is not necessary to load with concrete figures either, just hint at the general meaning. - Magic, thanks to which it all works.
Here you can turn around in the technical descriptions, however, without bending the stick. As soon as you notice that the chief's eyes and interest are extinguished, you need to immediately shut up and move on to other issues. - The conference!
To mention that all this magic has become available through participation in the conference.
This guarantees you paid tickets to the next conference :) - How we will present it to the customer.
, . , . - , , , , , , .
- , , (, -),
Once again, since we did not receive specific quick fixes at the conference, but a snapshot of trends, we must thoroughly prepare before entering into such a dialogue.
Often the authorities get used to communication in the form of a slide show. You can count it, and just modify the slides from the conference, since there is a public link to them.
But slides for a huge konfa are being prepared for viewing from a large screen.
I usually recycle them like this:
- Invert colors: dark gray backdrop, white font
- On the first page there should be some memorable logo (the logo of your project, or technology that you promote. It should directly burn into the brain of the beholder)
- All fonts convert to sans serif or something serious. No comics.
- Fewer long lists. Speakers write long lists of everything in the world, and you and your boss can discuss on the strength of 3-5 points. For the same reason, there should not be multi-level lists and other trash and intoxication.
- Throw pictures - memesiki and laughter with Boromir
- Charts and paycharts - leave. If not, add them.
- Special pont and chic - to make a printed version of the slides on good paper and really print them. The printer in the nearby bookstore, most likely, does not know how to print white on dark paper, so you have to google the appropriate printing house.
5. Conclusion
It was a short checklist, which is worth considering before attending the conference. If you are
- set a clear goal
- made a plan of the event
- defined the concept of how this event fits into the daily life of the team,
- -- ( — , , ),
- , , , ,
- ,
- ,
- ,
, , .
-, , , , .
.
Source: https://habr.com/ru/post/332126/
All Articles