Hi, Habr!

I am Nikolai Krapivny, head of server-side development at Badoo.
')
Recently, we were a friendly team went to the Lead Dev conference in New York , dedicated to the management of development. Among the speakers were representatives of Google, IBM, Slack and other companies. According to the good tradition in our department, I want to share my impressions, thoughts, review of reports and some materials that I brought from the conference.

A year ago, I was at the Lead Dev conference in London, and she was not very impressed with me. The set of reports seemed far from the most powerful to me - there was a lot of “water” and speeches about anything. This year's schedule looked much more impressive, including a report from Michael Lopp, VP Engineering Slack, and author of the book Managing Humans , about which our colleague Dima Marushchenko yojick spoke extremely enthusiastically. In general, the schedule was intriguing, and in the absence of a large number of conferences on technical topics, it was decided to give Lead Dev another chance and at the same time to be honest, take the opportunity to visit New York. As a spoiler, I will say that this year I liked it much more (that's why I decided to write this report).

About the conference

The organizers, the London guys (or rather the girls) called White October, in addition to Lead Dev, organize several other IT conferences, mostly in England (for more information, see their website ). They do it well, because there are no questions at all to organize the conference: there is enough food / beer, Wi-Fi is working, the atmosphere is friendly and positive.

The conference was held in the very center of New York on Tuesday, April 24th. In my opinion, not the most convenient schedule, given that many participants in New York for a long time to fly and, in fact, need to fly for the sake of one day. Obviously, the calculation was on the American public, and, in general, it turned out this way - there were few people from Europe, and mostly they were the organizers who flew in from London. I didn’t meet any Russian speakers among the participants.

The schedule consisted of four blocks:

1. Big report (30-40 minutes).
   
2. Small report (10 minutes).
   
3. Another report for 30-40 minutes.
   
4. Lunch / Coffee break.
   

In fact, this is the best schedule I have ever seen - most of the small reports were frankly uninteresting, so I used the time allotted to them, fixing the main thoughts of the previous large reports. The organizers, I think, conceived these inserts, including for “running in” inexperienced speakers, which is probably also useful.

I remember that on the screen next to the slides were subtitles. I'm not sure that this was done exclusively for the hearing impaired (and this is great) - perhaps also for those who do not speak the language enough to take 100% of the information by ear (which is no less healthy).

Separately, I want to say about the speakers and the preparation of reports. All the big reports were just perfect: great slides, the speaker speaks clearly, clearly, heartily, no hitch and problems, listening is a pleasure. To be honest, there was even the impression that the speakers at the conference were professional speakers (which may not be so far from the truth).

About reports

- Revitalizing a cross-functional product organization, Deepa Subramaniam and Lara Hogan

Two girls are the founders of a company that advises in the areas of building processes and forming teams for other companies. They shared the basic principles of building the right culture and processes in the company. There was little for me in the report, but I found value for myself in a structured way of looking at what we already do. In short, according to the authors, success can be achieved if:

• Identify the stages of the development process and for each stage, determine three things: what documents should be created, what meetings are collected, what should be the result of the stage. Using the example of Badoo: at the idea stage, we form a PRD file, collect product engineers and engineers (kick-off meeting), the result is the task accepted by the engineers.
  
• Clearly delineate and delineate areas of responsibility: for the development process, it is hard to determine which piece who does (product scientist, designer, developer, analyst), paying particular attention to the complex points on which differences arise most often.
  
• Do not avoid unpleasant discussions. In general, there was a bit of “water” at this point, but the idea is that communication between the manager and the employee is extremely important (especially if this is a negative feedback), and if it is not available, everything is bad.
  
• Create a healthy microclimate in the company. Lara showed the achievements of the HR team from Etsy: how do they promote constructive and friendly communication at home? Liked, adopted.
  
• More corporate-wide communication channels. All hands, project launches, corporate news - all this becomes all the more important the bigger the company. It's hard not to agree.
  

Report slides are available here .

- Traps on the Path to Microservices, George Woskob, ThoughtWorks

The most honest report about microservices that I have ever heard! A comrade from ThoughtWorks (the very ThoughtWorks in which Martin Fowler works) initially boasted that he sawed more than one monolith and that he knew everything about microservices. And then walked through the "pain points" of the transition from the monolith to microservices. In short, the report can be formulated as follows: “They promised us a paradise with microservices, but in reality it turns out that it’s so often that it’s better to stay on the monolith.” For example, something like this, according to the author, looks like a typical process of switching to microservices:



Next was a story about the main obstacles that await those who still decide to move in the direction of microservices. According to the author, this is:

• underestimating the cost of the transition — perhaps many people don’t need to do this
  
• centralization (and both technical (a bunch of common code) and administrative: general releases, common decision points);
  
• neglect of the monolith - overingineering microservices.
  

In general, the report is valid, it is clear that the guy in the subject and does not feed any illusions.

I'm really looking forward to the video to recommend everyone to watch. And slides of the report are available here.

- The Critical Career Path Conversation, John Riviello, Comcast

I was always jealous of the guys who have the opportunity to stop at some life stage, think about what happened to them, and make a whole report out of it. In general, this report is a story about the career path “engineer - manager - engineer”. Yes, the speaker was a manager and decided to return to work as an engineer, and in the same company. It must be said that the case is infrequent and deserves at least respect.

In the report, the author colorfully dispelled the myths about managers (“becoming a manager is cool”, “managers have less work”, “being a manager is the same job as programming” and others) and described why he decided that it was not his . The first part about turning from an engineer into a manager was like; crucial points were described very precisely (delegation, difficulties in working with people, more long-term goals). The second part, about returning back to the engineers, did not like very much, the reference to the statistics “only N% of people can be managers” especially upset. Statisticians of the form “not only everyone can do this or that” do not really fit into my life concept “If you really want, you can fly into space,” so I can’t support the author. At the end, there was a slide with a list of books / sites that most helped the author in a managerial position - for which he thanks a lot, I saved myself for studying in the future:



Report slides are available here.

- Improving Reliability, Google, Liz Fong-Jones

A SRE girl report from Google on how they approach the resiliency of their applications. The topic is very cool, it is clear that Google is systematically approaching this issue and has developed a powerful enough direction. The report was an attempt to convey as much information as possible from the book Site Reliability Engineering in 30 minutes. It was noticeable that this time is very short for so many thoughts and ideas, and sometimes there was a desire to stop the speaker and ask for time to think about what was said. The fact that Andrei Gomenyuk AHDREN once read this book saved a little, therefore some basic ideas were familiar to me.

The main idea of ​​the report is built around the fact that all services should have key accessibility indicators (SLI, SLO, SLA, more about them here ), and for each of them the budget should be defined (how much can we afford to go beyond the indicators, for example, per month). As soon as the budget is exceeded, measures are taken / time is invested in preventing failures until the releases are frozen. I will not try to retell the book - I advise you to read it (I personally added it to my must-read list).

- The New Manager Death Spiral, Michael Lopp, Slack

This is the very report for which we went to the conference. However, he turned out to be more inspiring than practical from the practical point of view.

The main ideas: you need to delegate more, you need to help each other grow and develop, you need to learn, learn, and learn again. In general, for all the good against all the bad. If you do not do all the best, then the "death spiral" begins: like a snowball, everything accumulates and it gets worse and worse. In short, trust the staff, live in peace and harmony - and you will be happy. It is extremely difficult to argue with the author, therefore he came out after the report inspired and with a firm feeling that this world can still be saved. But since I don’t understand what exactly needs to be done for this, I just went to the next report.

- Bowerbirds of Technology: Google Scale, Sam Kitajima-Kimbrel, Nuna

Most of the report, the author conveyed to the listeners the following thought: no need to mindlessly do as cool guys from Google, Facebook, Amazon, etc. do. Be aware of the scale of your project and make the most effective decisions with this in mind. For example, if giants can afford to transfer everything to microservices, allocate each for a separate team or re-write their platform for the cloud, then small offices often do not need this: it would be nice to use what is, and not chase the giants. In principle, there is nothing more to say about the report. A sound idea, everything is as it is.

- The Continuous Culture, Kim van Wilgen, ANVA

In my opinion, the best report of the conference. Somewhere in the middle of the presentation, the speaker said that in their system there were ~ 2M lines of code in PHP and ~ 8M in COBOL. After that, it is simply impossible not to respect them. But, apart from the jokes, the report was about the basic principles allowing the organization to produce the product as quickly as possible. They are as follows:

• the most frequent releases of the finished functionality;
  
• maximum flexibility in planning, do not build product plans for the year ahead
  
• maximum manual automation;
  
• maximum autonomy of the administrative structure (rejection of single decision points that do not allow the company to scale);
  
• continuous learning (to get better every day, to stimulate the growth of the team);
  
• risk reduction through testing automation (testing pyramid and their view on it);
  
• fewer dependencies, less connectivity (smooth releases, canary builds, feature flags ).
  

I liked the report very much, probably because most of the voiced principles are very close to the culture of Badoo, and we try to do everything almost the same. In addition, the report once again proved: no matter what language you write (you can do well in COBOL) - there would be the right values ​​in your head.

Of the new interesting ideas, we liked the approach to our long-standing problem - the acceleration of a large number of slow functional tests. They divided the entire set of functional tests into three groups. The first were tests that check things that are critical for a business, tests that are currently being developed, and tests of the most unstable places in the code; This group of tests is started as soon as possible / more often. The second group included tests that are less critical from a business point of view and more stable parts of the code; they are launched at later stages of development. The third group includes functional tests, the loss of which for some time is permissible; they threw out this group altogether and replaced it with monitoring. I liked the idea, I would like to fasten it to our projects.

Report slides are available here.

Thumbs Up: How To Design Systems And Processes Teams Actually Follow. Jason Lengstorf, IBM

The last report, which I want to talk about. A bearded guy from IBM talked about things that he considers important for building the right processes in a team. The main thoughts are the following:

• Systemic problems need to be solved not with crutches, but with processes that prevent them in the future.
  
• The input processes should be convenient, like a suitcase on wheels (without wheels, as without processes, uncomfortable).
  
• Avoid single points of failure in a team - things that only one person knows / can do.
  
• The ideal system of putting a person into operation - he came and on the very first day began to bring benefits to the company. To her need to strive.
  

Separately, I would like to note the beautiful slides and a few cool metaphors that the author operated on. For example:

• The elegant name for bus factor (without a hint that someone will get hit by a bus) is Vacation tolerance.
  
• Model of an elephant and rider to form the right processes.
  
• Yak shaving - the process of solving problems that are not related to the solution of the problem (the dev does not work, the disk space is over, there is no test phone). And it needs to be minimized systemically.
  

And in addition to all this, the author has shared an interesting book . In general, a cool report, it was interesting to listen.

Report slides are available here.

findings

Liked the conference. I was pleased.

Special thanks for the company to our guys, it was also fun outside the conference. :)