Alex Ptakhin

I’m sure busy calendars open vast opportunities to choose one things over the others. The more people in our department, the busier our calendar, the more valuable we are in terms of power to the company. It’s inappropriate if anyone can see our free calendar and book a meeting for us to discuss something urgent. 15 minutes on Tuesday at 7:45 p.m. in two weeks sounds fine. It’s easier to add more processes. When there is no slack time, it’s much easier to conduct meetings without agendas and facilitate the decision-making process to continue in two weeks. Remember, there is no space in the current week because of meetings. We are also late to one meeting because of the others, and there is no time for lunch. It’s tough work!

Words about Scrum Loud titles about how Scrum ruined Agile cause boredom or disgust. But in the environment of satirical folklore of ScrumButs, ZombieScrums, and ScreamGuides, we can observe the negative side of the framework. Let’s try to go step by step about the good and bad parts of Scrum. Scrum is often called an “Agile framework” or “methodology”, which is wrong. It’s the list of values, roles and meetings. The values don’t match the original Agile’s. As referenced in Scrum Guide: “Scrum is a lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems”. There is no word Agile on the page. Even if Scrum founders don’t consider it Agile, we can accept it the same way. What is even more destructive than the applied Scrum wrongly in the wrong place is many imprecise interpretations around it.

How We Should and Should Not Hire Why is hiring so difficult for leaders? Well, there are many moving parts. Also, the decision comes with long-term implications. We can’t predict how new members will interact with the rest of the team — especially under ever-changing circumstances. Introducing a new member is a significant addition to a small team that will consume ample resources before we start to see any benefits. Hiring a good developer and onboarding them can each take several months. Ultimately, every hire (or firing, in the worst-case scenario) requires a considerable amount of financial and motivational resources. So let’s take a step back. Can we avoid hiring someone altogether? Instead, we could dedicate those resources to optimizing internal processes or the product hypothesis flow in order to decrease the team’s development load.

I have subjective experience from my career path, but familiar with every company – from startup and middle-sized to big tech companies. From linear managers to C-level executives, all are stressed with hectic calendars and overloaded with calls and meetings. Even worse, often, there is lots of work because a company sometimes decides “much work” as a solution to multiple problems: how people interact with each other, and how the value is pushed from development to client. But the problem couldn’t be determined without feedback from outside. We can’t find and solve problems in the company’s system, that we bring together without new knowledge in this area. And we also often lack appropriate feedback. We will make the situation only worse if we will follow solving only consequences issues.

My goal: bring the idea of basic rules about systems. And nudge to think about the decision effects. Audience: senior engineers, engineering managers, and product/project managers. There are many overcomplications in the Tech industry regarding how to work well. There are too many “new” concepts, many bestseller books, many conferences and many talks with some “new” ideas. We think we missing something we run into it trying to implement things without going deeper into some basis. Let’s talk about the basis. I draw some context: I am talking about not-so-small not-so-big teams focused on one product or project. A group of people should at least have a goal to be named a team e.g. for commercial: earn more money in the long-term. For non-commercial: make people happier. Let’s little generalize our team word.

Дисклеймер: ниже заметки субъективных ключевых мест с краткостью записи для себя, оригинал видео рекомендуется к просмотру. Оригинал обсуждения здесь: https://www.youtube.com/watch?v=IDj3x__YZgE Зачем код ревью Соответствует ли код требованиям в ТЗ Побочные эффекты. Проблемы в других функциях Читаемость. Странные именования Консистентность общему стилю Оптимальность Чистота Повторное использование существующего кода. Агрессивно DRY Соответствие архитектурного изменения Проверка сценариев тестирования Плюсы: Уменьшение числа дефектов и увеличение качества кода Совместное владение кодом и бест практик Проблемы Дорого. Отрицательная обратная связь. Система регулируемая ошибками. Очень дорого. На финальном этапе исправляем ошибки, которые были в начале. Этапы проверки субъективные. Иллюзия что есть качество. Люди выдергиваются из процесса разработки на комментарии. Пример большие 2-3 недели разработки. От 70-150 комментариев субъективизма. Человек может сказать спасибо что изнасиловали на код ревью, полезно. Человека затюкивают. Нарушение непрерывности решения задач. Time to market повышается.

Симптомы. Один из подпроцессов в поде кубернетса просто вис и не логировал данные. Заходим в поду. Чтобы понять про процессы: $ top top - 19:00:06 up 22 days, 10:42, 0 users, load average: 0.79, 0.89, 1.11 Tasks: 13 total, 1 running, 7 sleeping, 0 stopped, 5 zombie %Cpu(s): 1.2 us, 1.4 sy, 0.0 ni, 95.0 id, 2.1 wa, 0.2 hi, 0.1 si, 0.1 st MiB Mem : 32165.3 total, 14305.0 free, 3202.7 used, 14657.6 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 28626.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9 root 20 0 167064 73724 8364 S 3.0 0.2 141:45.52 python 1 root 20 0 381020 53148 13248 S 0.0 0.2 26:46.39 python 780 root 20 0 381020 43252 3324 S 0.