Alex Ptakhin

After finishing Kent Beck’s Extreme Programming recently, I was left with questions about how and why. I agree with the ideas in the book, but there’s always this “but” that seems to undo everything before it. I can read many research papers about individual or group work, yet the resistance remains. From school to university and into the early years of work, we’re taught to focus on individual work—individual effort combined with social interaction.

When I learned to drive, some of my teachers tended to repeat: “You are driving in the direction where you are looking.” But my other teachers told me it was incorrect. Yes, I will crash when my eyes are stuck on one object for a long time. But if my eyes don’t stick, I can drive almost 360 degrees from my view by changing the view angle constantly. I’m a slow driver.

When I scroll LinkedIn I’m definitely not ready to read carefully long reads. I opened one article with no images and no interaction. I couldn’t just start reading it. I wanted to scroll and consume it. I tried the exercise two more times, slowing down myself, and didn’t get through the first screen. I can complain a bit about the post-COVID health state, where reading any problematic reading is becoming especially tough.

My understanding of DORA was about the four key metrics (Deployment frequency, Lead time for changes, Time to restore service, and Change failure rate). I didn’t understand why it should be relevant to my work. Why should these metrics be my Northstar? They don’t give me much value. I got a better idea with the nice podcast Dave Farley with DORA research co-creator Nicole Forsgren. The initial motivation was to link technical capital to company financial capital.

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.

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.

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.

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.

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, manyP 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.

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