“Adding manpower to a late software project makes it later.”

Brooks’s Law

Sooner or later every developer learns about Brook’s Law, for me it was later, but still better than never. After the encounter and countless references to the book on the internet, I decided to read it for myself and see what it’s all about.

The original book came out in 1975 and the latest revision in 1995. I think it is important to set expectations right, and accept that the author wrote a lot from that perspective – good old days when the industry still debated “if-else block” vs “goto statement”. In addition, the book isn’t an easy read, lot of technologies/terminologies aren’t familiar to me and that made it harder to follow. However I don’t think any of that should be a showstopper, I say: “push through”!

Opinions are like assholes – everyone got one and I’m no different. However I’m really struggling to express my thoughts on this book. On one hand the book is quite insightful, on the other hand, for the lack of better word – irrelevant. On one hand human behaviour didn’t significantly change since 1975, on the other hand business did. Let me give you an example from my personal experience: 45 years after the book has been published, managers still think that adding new developers to meet a three-month deadline is a solution. Never mind that a good developer typically needs more than three months to even get up to speed on our projects. However, adaptation of scrum (or alike) methodologies and business acceptance of small value-adding iterations has changed the way developers schedule and deliver code. There is no more hiding, in every sprint something of a value must be developed, demoed and shipped.

I can grumble, agree and disagree with the author on several points, but I think it is meaningless and unfair. I think the book should be taken for what it is, and not some sort of a guide from the days long gone to the present generation. Nevertheless, perhaps some people must read it for the sake of not solving the same old problems, the same old way, that never worked anyhow. Perhaps everyone should read it and understand that not all IT problems uniquely belong to IT industry and an answer is readily available just outside of it. Perhaps I should stop rambling and admit: may be the book didn’t impress me as much as I hoped it would but at least I don’t feel any regrets spending my time with it.

In a nutshell:
-: Not an easy read if you aren’t familiar with terminology and technology of the past
-: Some irrelevant concepts
+: A lot of insight into software industry, some still hold true
+: Interesting references and opinions
+: Enjoyable, with certain expectations
=: I don’t think this book should be atop a reading list. However if you are curious and have time, I wholeheartedly recommend it. Don’t set any expectations, remember the book originated in 1975 and enjoy the essay.

Title: The Mythical Man-Month: Essays on Software Engineering
Author: Frederick Brooks
Cover:

Notes & Quotes from the book, I couldn’t help myself but to take:

“Solutions to many IT problems already exist in other industries, but IT pro feel and act as those don’t apply.”

“Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

“Self-Documenting Programs – a basic principle of data processing teaches the folly of trying to maintain independent files in synchronism. It is far better to combine them into one file with each record containing all the information both files held concerning a given key. Yet our practice in programming documentation violates our own teaching. We typically attempt to maintain a machine-readable form of a program and an independent set of human-readable documentation, consisting of prose and flow charts. The results in fact confirm our teachings about the folly of separate files. Program documentation is notoriously poor, and its maintenance is worse. Changes made in the program do not promptly, accurately, and invariably appear in the paper.”

“Long before any code exists, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity. As Vyssotsky says, the developers themselves cannot do this: “They won’t tell you they don’t understand it; they will happily invent their way through the gaps and obscurities.””

“Day-by-day schedule slippage is harder to recognize, harder to prevent, and harder to make up than calamities. The first step in controlling a big project on a tight schedule is to have a schedule, made up of milestones and dates for them. Milestones must be concrete, specific, measurable events defined with knife-edge sharpness. A programmer will rarely lie about milestone progress, if the milestone is so sharp he can’t deceive himself.”

“Cosgrove advocates treating all plans, milestones, and schedules as tentative, so as to facilitate change. This goes much too far— the common failing of programming groups today is too little management control, not too much.”

“Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there needs to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task”

“The basic fallacy of the waterfall model is that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds. Another way of saying it is that the waterfall model assumes the mistakes will all be in the realization, and thus that their repair can be smoothly interspersed with component and system testing.”

“The first step is to accept the fact of change as a way of life, rather than an untoward and annoying exception. Cosgrove has perceptively pointed out that the programmer delivers satisfaction of a user need rather than any tangible product. And both the actual need and the user’s perception of that need will change as programs are built, tested, and used.”

“First, the man with strong management talent and strong technical talent is rarely found. Thinkers are rare; doers are rarer; and thinker-doers are rarest.”

“The job done least well by project managers is to utilize the technical genius who is not strong on management talent.”

“In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done.”

“In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done.”

“Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers.”

“But false scheduling to match the patron’s desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers”

“The fate of WIMP: Obsolescence. Despite its excellencies, I expect the WIMP interface to be a historical relic in a generation. Pointing will still be the way to express nouns as we command our machines; speech is surely the right way to express the verbs. Tools such as Voice Navigator for the Mac and Dragon for the PC already provide this capability.”

“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them”

“The bearing of a child takes nine months, no matter how many women are assigned.”

Frederick Brooks

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

О книге

Ах, Мартин Фолер, каждый программист хотя бы один раз слышал его имя. По какой-то ещё не осознанной причине, я всегда ассоциирую Мартина со своеобразным духовным лидером разработчиков и архитекторов. Его выступления всегда заставляют задуматься. На этой неделе я с грустью дочитал его книгу по теме рефакторинга. С грустью? Я очень, очень медленно шел по последним 30 страницам книги, переодически останавливаясь, откладывая «на потом». Что-то внутри меня не хотело заканчивать эту книгу – хотелось чтобы приключение продолжалось. Но все хорошее когда-либо заканчивается, а значит пора подвести итог.

Заметок и мыслей собралось у меня много и поэтому начну с конца: книга хорошая – стоит времени и денег! Я лично считаю, что мне стоило прочитать эту книгу на пару лет раньше – возможно, это помогло бы мне с некоторыми неправильными представлениями о разработке и рефакторинге. У книги есть 2-е редакции, первая базирована на языке Java, а вторая на Javascript. Я прочитал вторую редакцию и, хотя мой “боевой” язык программирования Java, мне очень понравились приведённые в книге примеры и идеи на Javascript-е. Стоит отметить – я НЕ фанат Javascript-а по многим причинам, однако после Java, это как доза беспечной свободы и креатива – делай что хочешь, как хочешь, даже если тебя это впоследствии убьет. Также, по словам автора, он изменил пару советов во второй редакции, так как за прошедшее время некоторые традиции в программировании изменились, однако большинство советов остались прежними. Книга делится на две части: первые 100 страниц – история о разработке софта, почему и как рефактор является неотъемлемой частью разработки и дизайна. Вторая часть (300 страниц) – “бесконечные” техники рефакторинга из одной структуры кода в другую и наоборот, с объяснениями и хорошо разобранными примерами. В итоге, я считаю, что книга подойдет разработчикам с разными уровнями опыта, но возможно не начинающим! Как ни странно (сарказм), но автор очень сильно опирается на тесты, поэтому желательно усвоить тематику заранее, а также быть хотя бы немного знакомым с TDD, не зря со-автором книги является Кент Бэк.

Итого:
+: Простое и доступное изложение
+: Детально описанные примеры
+: Набор методик с объяснениями
+: Для всех разработчиков, за исключением начинающих
+: Отличные наставления
=: Хорошая, доступная, полезная книга – стоит вкладывать деньги и время.

Название: Refactoring: Improving the Design of Existing Code
Авторы: Martin Fowler & Kent Beck
Обложки:

Разработка и жизненный опыт

Я не люблю мешать свой жизненней опыт с обзором книги, однако в редких моментах оно того стоит. Тут я хочу обсудить некоторые советы/заметки из книги и поделиться опытом, для того чтобы другие программисты не ступали туда, где побывали уже все – поверьте оно того не стоит.

Не рефактор

“If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring.”

“Если кто-то сказал что код был сломан пару дней, потому что они делали рефакторинг, можете быть уверены, это был не рефакторинг”.

Довольно рано в моей карьере я лично повстречался с таким феноменом. Один программист уходил в “рефакторинг” не на пару дней, а на неделю или две. После этого фичи ломались, новый код невозможно было смерджить и наступал хаос. Как минимум ещё неделю программисты ходили с перьями, бубнами, барабанами на шее, зачитывая мантры, танцуя вокруг огня в попытке воскресить этого Франкенштейна. Со стороны все это выглядело жутко, так как сроки горели, софт работал плохо и менеджмент смотрел на нас как на врагов народа, мечтая о плетке и кандалах.

Вытекающие последствия: менеджмент думает что вся команда не компетентна (даже если хаос сеет один программист) и на то есть причины. Доверие к команде падает и соответственно программистов начинают слушать все меньше и меньше. Далее менеджмент начинает придумывать процесс, который в теории должен предотвратить такой хаос. Слово рефакторинг считается нецензурным и употребление его разрешается только в особых и согласованных случаях. В итоге, на первых парах все отлично, фичи добавляются, софт работает, хаос остановлен. Однако код начинает медленно деградировать, так как никто не хочет/может рефакторить. Спустя некоторое время, добавление фич начинает замедляться и разработка начинает занимать все больше и больше времени.

Много

“The whole purpose of refactoring to me is to program faster, producing more value with less effort”. “Refactoring is always done to make the code easier to understand and cheaper to modify.”

“Для меня, вся цель рефакторинга – программировать быстрее, создавая больше ценности с меньшим усилием”.
“Рефакторинг всегда делается для того, чтобы код было легче понимать и дешевле модифицировать”.

Некоторые программисты думают, что писать много кода это хорошо. Если мы забудем про память и другие ресурсы компьютера и отдельно посмотрим на “много кода”, то в теории ничего плохого в этом нет. Проблемы начинаются в тот момент, когда код нужно изменять, допустим, для новой фичи. Первая проблема: нужно много читать, вторая проблема: много понимать, третья проблема: много менять. Все эти занятия выливаются во “много времени” и как итог “много денег”.

Теоретически, проблему можно решить на корню – писать минимальный и чистый код, однако реальность диктует свои правила. Когда первый раз решаешь проблему, то редко получается с первого раза. Вариаций на “первый раз” может быть много: новая платформа, новая библиотека, отсутствие опыта, незнание домена и так далее. Реалистичное решение проблемы – постоянный рефакторинг: начал работать над кодом; прочитал; понял; посмотри, что можно исправить (очень часто, исправить можно много чего). Добавил код, пройдись ещё раз, посмотри, если ты понимаешь что-то лучше теперь, чем изначально, исправь – сделай проще.

Энтузиасты

“To really operate in an agile way, a team has to be capable and enthusiastic refactorers – and for that, many aspects of their process have to align with making refactoring a regular part of their work.”

“Чтобы по настоящему работать в agile, команда должна состоять из способных и полных энтузиазма «рефакторов» – а для этого много аспектов рабочего процесса должно выстраиваться так, чтобы рефакторинг был частью повседневной работы.”

К большому сожалению опыта с этим у меня нет. Для меня рефакторинг это часть моего личного процесса разработки. Перед тем как я пишу код, я читаю много кода, пытаясь понять что происходит и как оно работает. Пока я это делаю, я также рефакторю код по мере возможности и ценности. Потом я добавляю новую фичу и опять читаю, смотрю, думаю и рефакторю код по мере возможности и ценности. Такой режим работы возможен потому что:
⁃Я практикую TDD
⁃Большинство команды или практикует TDD или пишет хорошие тесты (советую книгу)
⁃ Там, где тестов нет или они плохие, я делаю рефакторинг исключительно автоматизированными средствами IDE.

Теперь большинство команды смотрит очень вяло на рефакторинг и обходят его стороной по возможности. Это происходит по нескольким причинам. Первая: способности и знания самих программистов у нас довольно тусклые. Вторая: культура компании такова – если ты все делаешь быстро (даже тяп-ляп и в продакшен), то ты герой и лавры тебе, а потом хоть потоп – это кто-нибудь другой разгребет. Третья: долгое время старшие программисты и архитекторы не давали рефакторить, даже банальные и простые вещи, ссылаясь на качество наших программистов. В итоге, когда я начал мой рефактор-путь, меня много критиковали, вставляли палки в колеса и так далее. Но я выжил и по меньшей мере сейчас никто ничего мне не говорит, даже если я изменил очень много кода. Но тут важное “но” – я никогда не оставляю код в сломанном состоянии и очень редко добавляю баги по причине рефакторинга. Баги в основном прокрадываются там, где плохие тести или их нет.

Методические рекомендации

“Here’s a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyways. The third time you do something similar, you refactor.“

“Вот методические рекомендации от Дона Робертса: Когда ты первый раз что-то делаешь, то просто сделай. Когда ты делаешь что-то похожее второй раз, поморщись и сделай дубликат кода. Когда ты делаешь похожее третий раз, то делай рефакторинг”.

Отличная рекомендация, которой следует пользоваться, так как порой в порыве энтузиазма, хочется рефакторить при первом же появлении дубликата кода. Но частенько бывает так, что тратишь много времени на рефакторинг, а в итоге овчинка выделки не стоит. Нюх на рефакторинг приходит с опытом и практикой, поэтому стоит быть терпеливым, практиковаться и не забывать эту простую и эффективную рекомендацию.

Оптимизация цикла

Я всегда придерживался аксиомы: дубликат кода – всемирное зло, которое должно быть найдено и уничтожено. Часто, когда обрабатываешь массив данных, используешь for-loop (цикл), в котором находятся “правила” изменения данных. Если правил много, то кода в цикле получается тоже много. Читать такой код занимает время и можно было бы все упростить, если сделать несколько циклов и выполнять разные правила в разных циклах по мере необходимости. Однако такой подход значит, что по массиву надо будет проходить несколько раз – в свою очередь большая “О” будет расти, а это как мы знаем из обучения в университете – зло!

Мартин на это смотрит в точности наоборот! Приоритет должен отдаваться не количеству подобных циклов, а чистоте и легкости понимания кода. Автор считает, что лучше иметь чистый код в цикле и пусть с дубликатами, чем один цикл, но без дубликатов. Объяснений тут несколько, первое: компиляторы умные и могут оптимизировать код, второе: проблемы производительности редко приходят из обработки данных в памяти, третье: если нужно оптимизировать производительность кода, то это куда легче сделать с простым кодом, чем со сложным.

Для меня это был немного сложный разворот, однако, немного подумав о своем личном опыте, я понял что это действительно так. Частенько все вкладывается в один цикл на “благо ради”, а потом код в цикле разрастается и в определенный роковой момент, кто-то по необходимости добавляет звонок на внешний ресурс (база данных, сервис или файлик). Если система начинает тормозить и нужно оптимизировать, то это превращается в кошмарный сон, так как нужно рефакторить все и сразу.

Когда хочется написать комментарий

“When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.”

“Когда чувствуешь, что нужно написать комментарий, сперва попробуй отрефакторить код таким образом, чтобы комментарий стал излишним”

Честно говоря, я даже не помню когда последний раз писал комментарии на код. Мартин не первый человек который обсуждает эту тему, на мой взгляд тематика лучше разобрана в книге дядюшки Боба – Чистый код.

Не будьте великим программистом

Statement Kent Beck often makes about himself: “I’m not a great programmer; I’m just a good programmer with great habits.”

Кен Бек часто говорит о себе: “Я не великий программист, я просто хороший программист с отличными привычками”.

Из личного опыта мне довелось поработать с великим программистом и опыт довольно интересный. С одной стороны “писькомер” с другой “Дартаньян”. Для этого великого программиста ВСЁ было крайне просто: написать сложный код; пропустить тесты, потому-что “код тривиальный”; оптимизировать до того как надо. С одной стороны я выучил много чего, работая с ним, с другой я видел ошибки, которые он делал и он не хотел даже выслушивать доводы. Великий программист ушел, его код остался и до сих пор его дизайн поражает воображение, так как там черт ногу сломит, программисты обходят его код стороной!

Тут я хочу дать пару советов программистам. Учитесь, всегда учитесь, практикуйтесь, читайте книги, блоги и документацию! Не изобретайте колесо там где оно уже давно есть. Практикуйтесь писать чистый, понятный код – помните простота сестра таланта. Изучите разные техники, включая TDD, оно всегда поможет. Заприте свое эго под большой замок, оно никому не нужно и в итоге будет только мешать. Взращивайте отличные привычки и знания.

Что говорить менеджеру о рефакторе

“What do I tell my manager about refactoring? Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!”

“Что говорить менеджеру о рефакторинге? Конечно, многие менеджеры и клиенты не имеют технических знаний о том как хороший код влияет на продуктивность. В таких случаях я даю свой спорный совет: Не говорите!”

Этот совет я слышу не первый раз и не от одного человека. Много раз, когда я ходил на семинары, эта тема всплывала и ответ был одним и тем же. Если вы находитесь в таком положении, то я поддерживаю совет – делайте что надо и не нужно никому ничего говорить. Однако помните выше описанные советы и методики – это очень важно! Так же прочитайте эту книгу, она вам очень поможет.

Теперь хочу поделиться опытом альтернативного пути развития событий. Такой путь обычно происходит в не шибко умной команде с бесхребетным тимлодом, которого больше интересуют политические игры, чем технологии. В какой-то момент, рефакторинг попадет на горизонт и будет расценен как что-то мифически-полезное, но опасное и будет принят на вооружение как оружие массового поражения. Другими словами рефакторинг включат в официальный процесс работы и будут применять только там, где нужно изменить “все”. Из личного опыта такое заканчивается по двум сценариям. Первый сценарий: пишутся рефактор-карты и кладутся в бэклог, где они долго бродят, протухают и в итоге выкидываются. Второй сценарий: выделяется неделя или две на рефакторинг какого-нибудь Титаника. И тут в зависимости от программиста: или переставляются стулья на палубе или происходит такой кап-ремонт, что в последствии принимается решение такого больше не делать, подписывая договор с менеджментом об ограничении использования оружия массового поражения.

Тесты

“I’m sure you have heard many times that you cannot prove that a program has no bugs by testing. That’s true, but it does not affect the ability of testing to speed up programming.“

“Я уверен что вы слышали много раз, что нельзя доказать что в программе нет багов через тестирование. И это правда, однако это не значит что тесты не помогают вам программировать быстрее.”

“Don’t let the fear that testing can’t catch all bugs stop you writing tests that catch most bugs”

“Не позволяйте страху остановить себя от написания тестов которые поймают большинство багов, лишь потому что тесты не поймают все баги”

“A suite of test is a powerful big detector that decapitates the time it takes to find bugs”

“Набор тестов это очень мощный детектор, который позволяет сократить время поиска багов”

Я лично фанат TDD и почти всегда пишу тесты. Теперь стоит отметить, что я не фанатик и понимаю, что не всегда и не везде нужно писать тесты, однако по большинству я их всегда пишу. К такому состоянию я пришел из личного опыта написания кода и считаю что тесты действительно помогают писать код быстрее и допускать меньше ошибок. Если взять один момент из моего опыта, то тесты спасли меня когда я в аварийном режиме разрабатывал патч для прода, работал по 12 часов в день и если бы не тесты, я бы не успел закончить во время. Так же стоит отметить что на протяжении почти 2-х лет, код работал четко и без ошибок или багов. Позже код был удален, так как больше не был востребован.

Pull Request

“The common pull request model, where a reviewer looks at code without the original author, doesn’t work too well. It’s better to have the original author of the code present because the author can provide context on the code and fully appreciate the reviewers’ intentions for their changes. I’ve had my best experience with this by sitting one-on-one with the original author, going through the code and refactoring as we go. The logical conclusion of this style is ‘pair programming’: continuous code review embedded within the process of programming.”

“Обще принятая модель пул реквестов, где рецензент просматривает код без автора, не работает особо хорошо. Намного лучше сидеть с автором кода, который может предоставить контекст к изменениям и обьяснить, почему были приняты те или иные решения. Из моего опыта лучше всего сидеть вместе с автором, разбирая код и делая рефакторинг на лету. Логическое завершение такого стиля работы называется: “парное программирование”, где процесс рецензии происходит по ходу разработки.”

У меня на работе пул реквест модель является де-факто. К большому сожалению, все косяки этой модели выходят на лицо, когда невозможно понять почему именно так было сделано. Сидеть с автором редкая реальность, а парное программирование запретная практика. Менеджмент считает, что это бесполезная трата денег. Я лично считаю, что это большая ошибка, так как когда работаешь парно (а с этим опыт у меня есть), то код разрабатывается быстрее. Так же довольно легко передается опыт и ремесло. Например: если новый джун. программист работает один, то зачастую это потерянное время. Он делает много ошибок или не может сделать сам вообще ничего. В итоге после нескольких дней, ему все равно приходится работать с другим программистом. Если подсчитать, было бы быстрее и дешевле сразу так сделать. Когда два опытных программиста работают вместе, то получается быстрее, проще и чище.

Однако у парного программирования есть и свои косяки. Одна большая проблема – это личность человека. Не все могут работать в паре, может кто-то жуткий интроверт и ему очень тяжело. Так же если в команде нет способа избавиться от непригодного программиста (допустим он не хочет учиться и/или не умеет программировать, а такое тоже бывает), тогда парная работа превращается в один работает, а другой спит! У нас на работе такое явление частое, а команда ничего по этому поводу сделать не может. Менеджмент по непонятным причинам не увольняет таких чудо-работников, а дает бесконечные вторые шансы. В таких ситуациях программисты начинают отказываться работать парно и по понятным причинам, в итоге результат на лицо.

Переименуй

“Renaming is not just an exercise in changing names. When you can’t think of a good name for something, it’s often a sign of a deeper design malaise. Puzzling over a tricky name has often led us to significant simplifications to our code.”

“Переименование это не просто изменение имени. Когда ты не можешь придумать хорошее имя для чего-либо, часто это знак более глубокой проблемы. Долгое размышление над замысловатым именем, часто приводило к существенному упрощению кода.”

Как говориться в программировании есть две сложные задачи: придумывать названия и кэширование. Интересно, сколько существует вариаций этой шутки? Я даже не знаю сколько раз я повторял выше описанное своим программистам. Когда я перешел в новую команду и посмотрел на их тесты, то вздрогнул. Спустя пару месяцев я ввел обязательную методику по названию тестов (если интересно, пишите я раскажу) и ещё 8 месяцев объяснял почему и как, не раз объясняя, если тест не соответсвует названию, то тест слишком сложный – разбейте на несколько отдельных тестов. Уже на данный момент все идет по маслу, битв больше нет, тесты плюс/минус в хорошем состоянии. Невероятно как маленькие изменения в названии ведут к большим изменениям в коде и работе.

Запомните это

“I was just as surprised myself when Kent Beck showed me how to do this in a hotel room in Detroit two decades ago. The key to effective refactoring is recognizing that you go faster when you take tiny steps, the code is never broken, and you can compose those small steps into substantial changes. Remember that – and the rest is silence.”

“Я был очень удивлен, когда 20 лет назад Кен Бэк показал мне как это делается в комнате гостиницы в Детройте. Ключ к эффективному рефакторингу – это осознание что ты программируешь быстрее когда делаешь маленькие изменения, код никогда не ломается и ты можешь составлять маленькие изменения в большие. Запомни это, а остальное тишина.”

Думаю, весь цимис успеха заключается именно в маленьких шагах. Зачастую мы думаем что это муторно, излишне и медленно. Однако если цель и задача в том чтобы сделать что-то хорошо и четко, то самый быстрый способ это делать работу маленькими фокусированными шагами. Возможно такой подход идет в разрез с общепринятой идеологией, но для меня он работает и работает хорошо.

Я советую вам попробовать этот подход на себе, главный трюк – разбить работу на маленькие шаги. Стратегий много и описывать их не буду, однако оставить с пустыми руками тоже не могу – посмотрите на “Как это решить”.


Эта книга валялась у меня некоторое время. С одной стороны она всегда была на горизонте и даже хотелось за нее взяться, с другой не была приоритетом — всегда находилось что-то более важное или полезное. Однако под конец 2019 года, я в очередной раз потерпел неудачу с очередной диетой. И тут стоит заметить, с весом я страдаю всю свою жизнь и скорее всего именно это в конечном итоге подтолкнуло меня к прочтению книги. Но почему именно этой книги? Дисклеймер: потому что мне нравится автор: Penn Jillette. Много лет назад я был поклонником “Penn & Teller: Bullshit!” шоу и мне нравился ход мысли и шутки.

Пора поговорить о книге, она о диете и лучше чем все остальные? Нет! Она не лучше, скажу даже больше, в плане объяснения “как оно все работает”, книга скорее парит в районе нуля. Там очень мало рецептов (питания), мало физиологических и научных объяснений. Из этой книги вы не узнаете ничего полезного о протеинах, кетонах и какой-либо релевантной научной информации. Стоп, а книга вообще о диете? Нет! Книга о том как Пенн сбросил более 100 фунтов веса и приключениях по пути.

Пенн предоставляет редкий замещающий опыт борьбы с лишним весом. Больше терпеть не могу и скажу: я редко читаю книги просто для наслаждения, но эта книга вызвала во мне большое количество удовольствия и не от самой истории (её можно суммировать в 9 минут), а именно от замещающего опыта, где автор очень детально описывает свой ход мыслей, идеи и опыт. Конечно не стоит забывать об интересных и забавных побочных историях, которые в конечном счете вливаются в действия героя.

С практической точки зрения, книга служит как забавная история и/или как навигационный маяк. Однако и в том и другом случае есть “но”. В плане маяка, книга служит больше как вдохновение и потенциальное направление, однако изучать и копать придется самим (диетологом у Пенна был Ray Cronise). В плане забавной истории, стоит учесть специфическое чувство юмора автора и язык 18+. Я полагаю, что не всем придется по вкусу язык и шутки Пенна.

Итого:
+: Простое и доступное изложение
+: Замещающий опыт
+: Вдохновительная история
+: Интересная перспектива на Американскую диету
+: Шутки и язык (очень субъективно)
=: Книга написана хорошо и мне очень понравилась. Думаю, прочитаю ещё раз, но позже. Её стоит читать, если вы хотите интересную реальную историю, ищите вдохновение или начальную точку для вашего личного покорения веса, а если ищите факты, науку и диетические рецепты, то не стоит — там их почти нет.

Название: Presto!: How I Made Over 100 Pounds Disappear and Other Magical Tales
Авторы: Penn Jillette
Обложки:


Недавно я просмотрел довольно интересную презентацию на тему руководства группой разработчиков программного обеспечения от Роя Ошерова. Презентация мне очень понравилась и в догонку я решил прочитать его книгу, на ту же тему. Из предыдущего опыта с автором я ждал многого.

Рулить группой программистов довольно интересное занятие, в особенности в ситуации, когда компания в лице менеджмента марширует под лозунгом Аджайла и самоорганизующейся команды, а на месте у руководителя нет полномочий принимать решения, плюс он завален всеми техническими проблемами. Как говорится: “денег нет, но вы держитесь”. Многие программисты и менеджеры ошибочно считают, что руководитель команды является основным программистом – цели и задача которого чинить косяки, помогать всем и без посторонней помощи допиливать релиз. Как ни странно, но такое я наблюдал как в своей компании, так и на интервью в другой компании, где вопрос ставился ребром: “сроки горят, денег нет, вариантов не осталось, ты руководитель, что будешь делать?”.

Автор обьясняет, что задача руководителя состоит в том, чтобы вырастить команду и как итог получить ту самую мифическую “самоорганизующуюся команду”. В команде должна быть дисциплина, ответственность и умение решать свои проблемы. Как же руководитель должен это все сделать, в описанной выше ситуации? В книге рассматриваются 3 состоянии команды: хаос, рост и само-управление. На каждой стадии руководитель играет разную роль и динамика команды меняется. Интересная заметка: как узнать если ваша команда находится на стадии хаоса? Задайте один вопрос: у команды есть “лишнее” время (на учебу и эксперименты)? Если нет, то вы в стадии хаоса.

Изначально руководитель занимает роль диктатора, цель и задача которого: ограничить количество и установить границу в плане доставляемой работы, тем самым получить время для развития команды. На этой стадии диктатор принимает все технические решения, даже если команда этого не хочет, например “мы используем гит для хранения и версионности кода”. Режим диктатора ни в коей мере не должен быть постоянным и служит исключительно одной цели – выбраться из хаоса. Стадия хаоса является самой сложной по многочисленным причинам. Первая причина психологическая: руководитель себя чувствует комфортно, работая героем: “я лично починил косяк в продакшене, все меня любят, начальство ценит и какой всплеск адреналина”, вообщем “я Дартаньян, а все пи…”

Вторая причина практическая: руководителю нужно выбить ресурсы – время, вызвав на ковер бизнес/начальство. Тут прийдется торговаться, бороться и говорить “нет”. Это занятие опасное для карьеры – она может быстро прерваться. Однако, если у команды нет времени думать, учиться и пробовать, то команда так и останется в стадии хаоса.

Следующая стадия – рост. В этой стадии руководитель занимает роль наставника, он должен проводить много времени с командой, как обучая, так и подталкивая индивидуальных членов команды к росту. Цель и задача этой стадии в том, чтобы команда не нуждалась в руководителе. Автор приводит много интересных тактик для роста. Одна важная тактика: когда член команды приходит с проблемой (технической или социальной), внимательно выслушав, руководитель должен задать один вопрос: “Что ты будешь по этому поводу делать?”. Автор отмечает, что вопрос может показать человеку грубым и отталкивающим, однако это заставляет “пациента” думать и решать свои собственные проблемы. Тут важно отметить, руководитель не должен оставить все на самотек, однако он не должен все время решать все проблемы – трюк в том, чтобы подтолкнуть человека к решению своих собственных проблем. Интересная заметка: если вы боитесь, беспокоитесь, не уверены, чувствуете себя не комфортно – это значит что вы учитесь! Вы вышли из зоны комфорта и попали в новое русло. Данная стадия нужна для того, чтобы все члены команды научились решать свои проблемы, научились учиться и выходить из зоны комфорта.

Не менее важный момент стадии роста это дисциплина! Нет не армейская, а дисциплина по доставке обещанного. Если команда не доставляет обещанные фичи бизнесу, то жизнь станет крайне сложной и вполне может вернуться на стадию хаоса. В этом плане, автор рекомендует использовать командный язык: “я доделаю фичу к 18:00 сегодня”, “я вышлю спецификацию после встречи сегодня в 13:00” и так далее. Теперь все программисты знают, что многие вещи не возможно доставить в определенный срок – например починить баг. Может баг простой, а может засосать на очень долго. С этого ракурса нужно использовать технику тайм-боксинга (ограничения по времени) и сказать: “я буду работать над этим багом 2 дня”. Если по истечению времени баг все ещё не отремонтирован, то можно остановиться и пересмотреть решения, как технические, так и ресурсные – добавить время, добавить программиста, перенести проблему на следующий релиз и тому подобное.

Последняя стадия – самоуправление. В этой стадии руководитель занимает пассивную роль – переставая на прямую управлять командой и отдавая бразды правления команде. Руководитель фокусируется на ограничениях вокруг команды, помогая из вне. Насколько я понимаю, эта та самая стадия, которая описывается в книгах по скраму (scrum), где нет руководителя.

Книга весьма интересная, но короткая – всего 200 страниц! Автор правильно подобрал название: “Заметки… “, а не «Полное руководство…». Также стоит отметить, что в книге есть опечатки и кривое форматирование. Как говорил Даниэль Суарэз: у вас есть все возможное время, когда вы пишете свою первую книгу, а после этого нужно укладываться в рамки. Не уходя от критики, книга разбита на две части: заметки от самого автора и вторая половина: гости. Вторая половина книги устроена простым принципом: один гость, одна глава. Хотя бывает, что один и тот же гость пишет две главы. Каждая глава большое напоминает быстрый рецепт к “выздоровлению” и местами отдает рекламой другого материала. Справедливости ради, некоторые темы достойны отдельной книги, но все же, возможно стоило сфокусировать, добавить авторов и расширить материал – хотя это спорный момент.

Итого:
+: Простое и доступное изложение
+: Детальное обсуждение проблем и решений
+: Чувствуется аутентичный опыт автора
+: Хороший возврат по затратам (ROI)
-: Книга короткая и хотелось бы больше сценариев по управлению командой
=: Книга хорошая и будет полезна многим программистам, в особенности тем, кто уже или собирается стать главой/руководителем команды разработчиков. Я советую посмотреть семинар, если вам он показался полезным то вперёд за книгой. Бэкап копия семинара

Название: Notes to software team leader
Авторы: Roy Osherove
Обложки:



Я подобрал эту книгу, так как много раз о ней слышал, да и Рой Ошеров хорошо отзывался. Я считаю себя здоровым скептиком, однако после первой главы я двинул в сторону глубокого скептицизма. Мне лично не пришлась по вкусу подача: все проблемы можно решить если купить книгу, прочитать её, практиковать ремесло, стать мастером влияния, получить докторскую, найти проблему, получить бюджет и наконец решать проблему до победного конца! Это не первая книга, которая на протяжении пары глав «сама себя продаёт». В одних книгах запугивают — аля: «ты пропадёшь без этого» или «не упусти возможности», а тут «все можно исправить — проблема не в силе воли, а проблема в умении».

Однако книга все же интересная и тут я не говорю «верьте всему написанному», я говорю «дайте шанс». Книга содержит довольно много полезных советов, подкрепленных историями и примерами. В центре всей концепции лежит шесть основных принципов влияния:

  • Личные мотивации
  • Личные способности
  • Социальные мотивации
  • Социальные способности
  • Структурные мотивации
  • Структурные способности

Авторы объясняют, что суть любого поведения всегда сводится к выше описанным факторам. Чтобы стать “властелином влияния” нужно овладеть всеми шестью принципами. Однако, не всегда нужно использовать все принципы, изначально нужно понять какие принципы поведения являются основными и какие принципы помогут это исправить. Чем сложнее проблема, тем больше принципов влияния нужно использовать одновременно!

На персональном уровне авторы отбрасывают идею воли (одним дано, другим нет) и утверждают, что само-контролю можно научиться, используя нехитрые трюки. Например: если вам очень хочется шоколадку, то можно отвлечь свое сознание мыслями о другом или играми. В таком же ключе можно бороться с раздражением и яростью, если чувствуете что «надвигается» тут же забросьте свой мозг какой-нибудь интеллектуальной задачей, да по-сложнее. Люди часто занимаются «не натуральными» занятиями — тем, что им не свойственно (например, чистка зубов), трюк в том чтобы сделать это занятие желаемым. В этом ракурсе человеку нужно ответить только на два вопроса: стоит ли оно того? И могу ли это сделать? Если ответ «да» на оба вопроса, то человек будет это делать!

Интересный и не маловажный (из личного опыта) путь изменения сознания как одного так и группы людей это викарный опыт. Викарный опыт применяется там, где вы хотите поменять поведение, но вы не можете заставить/убедить человека попробовать что-то самому и/или с помощью помощника. Вместо этого вы можете детально продемонстрировать видео записи или в живую как что-то делается или происходит. Таким образом зритель может получить опыт, при этом сам ничего не трогая.

На социальном уровне “игра” переходит на следующий уровень. Как ни странно, но люди — социальные животные и, соответственно, восприимчивы к соц. давлению, поэтому считаются с мнением лидеров / уважаемых в обществе людей. Один из подходов — найти лидеров и внедрять изменения через них — “если лидер так делает, то…”. Так же можно использовать групповую ответственность — все помогают и отвечают друг за друга, однако тут нужно убедиться в возможности открытого и безопасного обсуждения. Если ты видишь проблему, то она моментально должна быть вынесена на обозрение — никакого кода молчания! Так же не стоит забывать о простом методе “пряника и кнута”, но с ним нужно быть очень тактичным и острожным. Потенциальная проблема с “пряником” заключается в том, что она может привить неправильное поведение, например: раздаем “пряники” за перевыполнение плана — штампуем больше, качество меньше и в итоге компания несет убытки. Момент с кнутом: если не готов хлестать, то не угрожай. Люди очень быстро “схватывают” ваше бессилия и это может привести к пониженной продуктивности с вытекающими последствиями. Тут мне вспоминается книга: “Сначала надо нарушить все права”

Структурный уровень один из моих любимых по одной простой причине — чисто инженерский подход, который может легко пережить поколения! Многие советы приходят из мира массового производства, как в книге “14 принципов Тойоты”. Если сделать правильную архитектуру и/или устройства, то люди будут использовать их без какой-либо задней мысли, следуя заданному поведению. Тут поделюсь личным опытом: когда на работе решили повышать качество кода и установили автоматическую систему анализа, то люди резко стали смотреть на ошибки и исправлять найденое. И тут отмечу — да, система не идеальная, и знающие программисты легко могут “танцевать” вокруг неё! Однако стоит обратить внимание на 3 очень важных фактора:

  • Никому не хочется много танцевать, проще смириться и писать код по-лучше.
  • Система анализа предоставляет результаты в простой и доступной всем форме — очень легко найти и понять на что она жалуется.
  • Все программисты просматривают код друг друга.

По отдельности каждый фактор не несет большой пользы, однако взятые вместе, предоставляют эффективное устройство для нахождения и исправления ошибок.

Итого:
+: Простое и доступное изложение
+: Примеры и байки
+: Обсуждение каждого принципа
+: Много пересечений с уже пройденными материалами, плюс к доверию?
-: Книга коротка относительно материала – создается ощущение, что нужно “докупить” опыт на отдельных семинарах
=: Материал довольно интересный и, если у вас есть время, то рекомендую для общего развития. Я считаю, книга будет полезна тем кто находиться в позиции, где можно и нужно что-то менять.

Название: Influencer – the new science of leading change
Авторы: Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan, Al Switzler
Обложки:


Победи банк – канадский путеводитель к простому инвестированию.

Как ни странно, но за все надо платить. После рождения ребёнка, моя жена узнала, что канадское государство дарует деньги на высшее образование ребёнка. Формула достаточно простая: открываешь специальный образовательный банковский счёт на имя ребёнка и кладёшь туда деньги.  В свою очередь государство за каждые вложенные $2 доллара, вкладывает $1 с лимитом в районе $1300 в год. Однако держать деньги без какого-либо инвестирования довольно плохое решение, так как инфляция берет своё, а вдобавок, скажем $30000-$40000 для 4-х летнего университетского образования – маловато! Что делать? Инвестировать!

Я никогда не интересовался инвестициями, так как нечего было инвестировать – «все есть, а денег нет.». Однако ребёнок подтолкнул в правильную сторону и моя жена взялась за работу. Она прочитала книгу, изучила разные варианты инвестирования и сказал: вот книга, ты ее читаешь!

Скажу прямо, книга довольно шокирующая, так как раскрывает одну важную тему: комиссии больших банков на ваши инвестиции! Например, такой сценарий: вы работаете, откладываете, вкладываете в пенсионный фонд, проходит 30 лет, а вы узнаете что 40% вашего капитала ушли на оплату всяких банковских комиссий. Бред! Как такое может быть? Автор книги раскрывает секреты мастерства канадских банков: «…. иииии денег нет!»

Книга не глубокая, все банально и просто – автор упрощает все для читателя со средним образованием в 9 классов, обходя стороной теоретические темы! С одной стороны такой подход мне не нравится, с другой стороны это простой путеводитель по инвестированию – другого не обещали! Я лично считаю, что книга является отличным стартовым местом – разложены разные пути инвестирования, а так же предоставлено достаточно информации чтобы копать дальше самим.

Итого:
+: Легко читается
+: Все просто и наглядно
+: Раскрывает глаза на “мир”
+: Достаточно информации чтобы жить и не париться
-: Автор затрагивает тему налогообложения, но абсолютно поверхностно
=: Рано или поздно нам всем нужно откладывать деньги на пенсию. Автор написал хорошую, простую книгу для всех и, возможно, она спасет ваши накопления от комиссий больших банков.

Название: Beat the Bank: The Canadian Guide to Simply Successful Investing
Авторы: Larry Bates
Обложки:

Quotes from the book:

The stock market is a device for transferring money from the impatient to the patient. — Warren Buffet

There is nothing so passionate as a vested interest disguised as an intellectual conviction. — Frank Herbert, Author

Freedom is realizing you have a choice. — T. F. Hodge, Author


Жизнь – это игра, а в любой игре герой отправляется в путешествие, чтобы преодолеть трудности и победить финального босса. Последние 4 года я находился в таком путешествии, с само-назначенным квестом: тестирование кода.

Шаблоны тестирования в xUnit стала последней книгой для меня и иронично самой сложной. Эту книгу я отыскал на Амазоне и решил: «она большая и, наверное, содержит много материала, о котором я никогда не слышал». В реальности мой рационал не мог быть дальше от правды. Книга действительно содержит много информации и однозначно полезной, однако у книги есть несколько фундаментальных проблем, которые в совокупности сводят коэффициент полезного действия фактически к нулю. Но, пойдём по порядку.

Первая проблема – длина книги! Она слишком большая! Книгу стоило разбить на две отдельные книги: первые 300 страниц – все что нужно знать, вторые 500 страниц ещё раз и с глубокими примерами и добавочными мыслями. Если бы я писал книгу, то однозначно бы сжал ее до 350 страниц и на этом концерт был бы закончен.

Вторая проблема – механизм доставки! Все сухо, с определениями, повторами и со странной структурой. Автор жутко напоминает профессора, который готов бубнить что-то 3 часа подряд, не взирая на аудиторию или её отсутствие. В какой-то момент (после 350-ой страницы) я реально стал задумываться, если автору платят по количеству слов в книге. Я предположу одно: возможно когда книга такая длинная, то сложно следить за изложением мыслей и структурой. Однако пишут же хорошие и очень длинные книги по фантастике?!?!?

Третья проблема – время! Когда пишешь о шаблонах, то можно не вдаваться в технологические детали. Вместо этого можно давать примеры, разбирать проблемы, вести анализ и обсуждать решения, включая философские подходы. Таким образом можно обойти большинство проблем связанных со устареванием материала. Однако автор посчитал, что лучше всего сделать и то и другое, с результатом на лицо.

Четвёртая проблема – реклама! После половины книги можно легко догадаться, что автор является большим поклонником книги Мартина Фалера – Рефкторинг, на книге даже стоит печать от Мартина. Но как можно на протяжении всей книги вставлять рекламные отсылки: “и тут мы используем рефактор технику от Мартина… чтобы отрефакторить тест…”? Обычно в книгах упоминают и делают ссылки либо при первом использовании, либо в начале или конце книги. Однако делать это на протяжении всей книги и фактически в каждой главе, причем ссылаясь на одну и туже технику (по большинству) это уже бесстыдная пиар компания и уместно задать вопрос: а цель автора состоит в том, чтобы убедить читателя купить ещё одну книгу?

Тут стоит остановиться и переключиться на позитив. Книга действительно содержит все возможные шаблоны, большинство которых я использую или обхожу стороной по тем или иным соображениям. Некоторые шаблоны весьма резво обсуждались в команде, а о некоторых я даже не знал. Лично мне понравились обсуждения шаблонов, так как интересно сопоставить личный опыт и опыт автора, даже если мы не всегда сходились во мнении. И тут надо признаться: автор действительно постарался собрать все в одно и вполне возможно эта книга является полным собранием всех возможных вариаций по тестированию.

Финальные мысли: книга в принципе хорошая, однако советовать её всем не могу! Книга прийдется по вкусу тем кто уже знаком с темой и хочет по максимуму выжать все что можно. Однако давать её программистам для улучшения навыков, того не стоит! Есть куда более полезные книги: Разработка через тестирование по примерам и Искусство модульного тестирования с примерами C# не говоря о блогах и других ресурсах. Автор мог бы сделать шикарный материал, если бы убрал все выше описанные недостатки и сфокусировался на рецептах.

Интересный момент с путешествиями, когда я отправлялся, то видел конец моего пути, но, достигнув финальной точки, я понял что хочу продолжать. Мой квест по тестированию закончен, и эта книга стала кульминаций.

Итого:
+: Огромное количество информации по тестированию
-: Слишком длинная
-: Изложение довольно сухое
-: Много повторений и рекламы другой книги
-: Излишний фокус на фрейворки по тестированию ( которые уже устарели )
=: Книга для тех кто хочет выучить тему вдоль и поперек. Однако рекомендовать её программистам я бы не стал – слишком низкий возврат по инвестициям. Есть куда более полезные книги для практического применения, не говоря о блогах и других ресурсах!

Название: xUnit Test Patterns: Refactoring Test Code
Авторы: Gerard Meszaros
Обложки:


Легко рационализировать как Форд/ДжиМ/Крайслер стали огромными и успешными мировыми авто-производителями — Америка богата ресурсами, стабильна и никогда не была в полной разрухе. Однако не легко понять как Тойота, будучи в стране с очень ограниченными ресурсами и пост-военном хаосе, смогла стать успешным и крупнейшим мировым авто-производителем. Книга «14 принципов Тойоты» раскрывает секреты успеха.

Я решил прочитать эту книгу полгода назад – в то время я собирался в путешествие и думал прослушать книгу в дороге. Однако этого не произошло, но книгу я все же решил пройти, так как любая идея может легко изменить то как мы работаем, живем и решаем проблемы! И тут отмечу, эта книга изменила мой подход к решению проблем буквально сразу, но об этом позже.

Поскольку Тойота является авто-производителем, в книге описание крутится вокруг массового производства деталей и автомобилей. Однако тут стоит притормозить и отметить, что Генри Форд придумал коверную сборку после наблюдения за работой мясной фабрики. А делегация от Тойоты, приехавшая в Мичиган на “Румяную” фабрику Форда, привезла домой новые идеи по производству автомобилей, наблюдая за работой Американских супермаркетов! Отсюда можно сделать вывод, что правда в еде, но более рациональный вывод — решения не должны находиться в каких-либо рамках.

Книга весьма интересная и напоминает “Проект Феникс”, однако менее романтична и концентрируется на принципах, которые весьма успешно сработали для Тойоты. 14-принципов довольно просты (в понимании), однако не являются моментальным решением, а наоборот — долгосрочными и взаимосвязанными. Если вырвать один принцип – например: “устранение потерь/отходов” то можно добиться результатов, по меньшей мере на определенном шаге производства, однако если не переорганизовывать все шаги, то устранение потерь на конкретном шаге может не дать никаких конечных результатов, а в худшем случае увеличит потери на следующем шаге производства.

Лично мне понравились несколько принципов, которые как ни странно напрямую пересекаются с программированием:
– Держи все в чистоте, чтобы можно было легко находить проблемы и ошибки;
– Контролируй поток визуальными инструментами/значками – люди визуальные существа;
– Используй простые решения, если это решение не помогает людям, то никакое количество технологических новшеств не решит эту проблему.

И тут поделюсь своим домашним (не профессиональным) опытом: моя жена и я переодически планируем череду задач – мелкие жизненные “проекты”. Однако моя жена достаточно забывчивая и задачи часто не выполнялись вовремя или не выполнялись вообще. Я, со своей технологической башни потратил достаточно денег на органайзеры, телефоны, смарт-часы и другие высоко-технологичные решения, которые, если верить “продавцам”, решат все проблемы! Однако результат не изменился, задачи не выполнялись вовремя, проекты растягивались и это было не прикольно, потому что пришлось бы отложить отпуск. Решение пришло с нескольких сторон: “принцип использую простые решения”, “принцип сделай поток визуальным” и простая kanban доска, которую я тупо сделал на кухонной стене используя простую изоленту (для покраски) и фломастер. Результат? Ошеломительный! Мне даже не приходится жене ни о чем напоминать. Задачи выполняются, а если зависают, сразу видны, и тут же проводится референдум (почему, кто, когда и как) — моментальная переорганизация.

Однако есть пара моментов, которые мне в книге не понравились. Если четко следить за книгой, то можно найти пару-тройку противоречий (с кем не бывает). Также в книге отсутсвует какая-либо критика принципов или системы Тойоты, как и самой компании — местами создается ощущение, что книга служит рекламой компании. Но что есть, то есть.

Итого:
+: Простое изложение
+: Примеры и байки
+: Обсуждения каждого принципа и его применения
+: Без воды и ступы
-: Отсутствие критики принципов и производственной системы Тойоты
=: Книга хорошая и я однозначно рекомендую ее читать – отличный возврат на инвестицию времени и денег. Да, мы все думаем, что наша работа не имеет ничего общего с конвейерной сборкой, но это не так, в любой работе можно найти повторяемые задачи и оптимизировать их!

Название: Toyota 14 principles
Авторы: Jeffrey K. Liker
Обложка:


Эту забавную книгу я обнаружил на одном блоге по программированию, в листе «любимых» книг. Идея мне понравилась: как определить когда люди пытаются от тебя что-то скрыть.

Техники и методики были написаны сотрудниками ЦРУ и использовались по прямому назначению. Однако книга не раскрывает все секреты мастерства, по понятным причинам. Но делится довольно интересными и серьезными техниками, которые на мой субъективный взгляд полностью эффективны.

Авторы дают много примеров и анализа в попытке познакомить читателя с ситуациями, разговорами, строением предложений и физиологической реакцией. Из личного опыта скажу: в таком деле нужна практика, если вы когда-либо покупали б/у авто с рук, то знаете, что разговаривать с продавцом довольно важно. Если продавец начинает кривить, отвечать на другой вопрос и так далее, то это еще не повод бежать, но точная заметка, что надо копать дальше. Пример из личной жизни: «авто когда-нибудь было в аварии?», ответ: «нет, пока я ездил на авто, я никогда не попадал в аварию» – перевод на Русский: я не знаю или не хочу раскрывать полную историю автомобиля, но я на нем не бывал в аварии. Повод уходить от покупки? Нет! Это повод очень серьёзно посмотреть на все стыки в корпусе, в моем случаем были видны признаки аварии.

Книга конечно же не является пособием «молодого бойца», однако хорошо подойдёт всем кто хочет проводить конструктивные интервью/беседы, так как основная цель и задача не давить на человека, а заставить его самого, свободно рассказать правду, всю правду и ничего кроме правды. Единственная критика, которая приходит мне в голову: есть разница когда идёт профессиональное интервью в ЦРУ / полицейском участке и разговор между двумя людьми в офисе – если кто-то не хочет говорить, то в одном случае могут быть последствия, а в другом – развернулся и ушёл.

Итого:
+: Хорошее изложение
+: Примеры
+: Просто и эффективно
+/-: Написана для общей публики – без глубины
-: Короткая – хотелось больше примеров и теоретической отработки материала
=: Книга интересная и, пожалуй, стоящая, но без практики может оказаться бесполезной.

Название: Spy the Lie
Авторы: Philip Houston, Michael Floyd, Susan Carnicero, Don Tennant
Обложка:


«Мы не стали программистами чтобы убивать людей…» – uncle Bob.

Интересное предложение, которое может быть интерпретировано разными способами, в особенности если вы программируете логику для оружия. Но это не то, что имел ввиду дядюшка Боб. Что он подразумевал, так это баги в программах, которые в последствии ведут к гибели человека, а таких сценариев придумать можно много, но можно и не придумывать, а поискать в интернете и, к сожалению, примеров достаточно.

Я не знаю почему начал с такой «оптимистической» ноты — когда я сел писать мысли о прочтенной книге, именно эта цитата пришла в голову. Исторически я начал программирование довольно традиционно — пишешь код, потом тыкаешь в программу и вроде все работает. Года 4 назад мне повезло и я работал с людьми, которые практиковали TDD (разработка через тестирование) ремесло. Я присосался на сколько мог и с того момента стал поклонником методики. Традиционно, программисты знают как «правильно» писать код и тесты, однако не все субъективные «правила» тесто-писания улеглись в моих мозгах. Некоторые из них меня напрягали, зудели и всячески не хотели приживаться. Визуально некоторые из правил выглядели так: если деталь куда-то не влазит, то по «правилам» нужно взять молоток, да побольше, и бить, пока не влезет, а когда расплющенная деталь влезла в разбитый корпус, тогда берешь напильник и замазку — «эх, говорил же тебе, что все влезет!!!».

Я никогда не умел забивать (привет дяде Роме и уже сгнившему забору на даче). По этой причине я продолжил изучать эту тематику. С опытом и дополнительными знаниями, я понял, что нет точных/абсолютных правил написания тестов, есть только основные (Three Laws Of TDD by uncle Bob). Все зависит от системы, кода и кучи других не сильно замысловатых факторов.

По иронии судьбы, к моменту «прозрения» я наткнулся на эту книгу. Кент Бэк обнаружил TDD технику в “древних” книгах по программированию и решил возродить ремесло. В этой книги Кент затрагивает многие темы, начиная от базовых примеров и заканчивая ответами на тяжелые вопросы: «а когда тест считается слишком большим?». Автор затрагивает многие типичные проблемы, которые вы рано или поздно встретите в TDD разработке, и даёт как конкретные, так и философские ответы. Этот материал является, на мой субъективный взгляд, основой, так как в индустрии можно найти много разных интерпретаций, в особенности, если смотреть TDD дебаты на YouTube-е.

Если вы заинтересованы в ремесле, стоит читать книгу, однако подготовьтесь — первые 40 страниц могут показаться нудными и тривиальными, однако не стоит их пропускать. Автор разбивает темы на под-темы и короткие отдельные главы — с одной стороны это немного раздражает, но со временем медленно вырисовывается шаблон. Шаблон служит как пример: мышления и написания кода. Очень интересно проходит параллель между изложением книги и программированием. Чувствуется, что автор книгу не писал, а программировал — название самой книги на 100% отображается в материале!

Не все в книге прошлось мне по вкусу. В некоторых моментах изложение довольно замороченное. Юмор автора тоже не даёт расслабиться, в итоге отдельные темы мне пришлось перечитывать несколько раз, а порой и ходить за альтернативным объяснением в интернет. Но тут я многое списываю на культурную и возрастную разницу (не первый раз натыкаюсь на такой стиль изложения).

Итого:
+: Структура, примеры и дискуссии
+: Наглядно от и до
+: Содержит все основы
+: Где использовать и какие существуют ограничения техники
+/-: Изложение местами оставляет желать лучшего
=: Отличная книга, которую стоит читать всем программистам. Я жалею, что не наткнулся на эту книгу всего пару лет назад.

Название: Test Driven Development: By Example
Авторы: Kent Beck
Обложка:


Сначала надо нарушить все правила — книга, в который мой скептицизм встретился с моим прагматизмом. Книгу я обнаружил в офисе нашего CEO и обложка показалась мне знакомой (не знаю почему). Не моргнув глазом, я её позаимствовал (и скоро верну), но читать её не стал, вместо этого я решил пройтись по аудиокниге — потейто-потато. По завершению книги я тут же хотел написать свои мысли о материале (спасибо OCD), но внутренние чувства меня раздирали на части: с одной стороны согласен с материалом из-за личного опыта, с другой — либерализм и почти здоровый скептицизм.

Книга написана для менеджеров: “Изучая неудачи, вы не найдете пути к совершенству. Только изучая совершенство, вы обретете совершенство.”, но пригодится не только им. На мой субъективный взгляд. книга довольно хорошая, даже если отбросить исследования и описанный статистический анализ. Много рецептов, с которыми я согласен, по меньшей мере из моих личных наблюдений.

Однако не все улеглось с первой попытки и я все ещё продолжаю внутренние дебаты. Например золотое правило, которое нужно пустить под откос: “обращайся с другими так как хочешь чтобы обращались с тобой”. Автор разбивает шаблон простым примером: менеджер, который любил публичные выступления и признания, решил поощрить своего лучшего работника предоставив ему центральное место на сцене перед всей компанией, не учтя того, что работник ненавидит публичные выступления и внимание публики. Результат получился довольно печальным, но более важен факт того что с каждым человеком нужен индивидуальный подход и то что нравится тебе может не понравится другим! Банально, просто, но почему-то игнорируется “золотым правилом”, которое весьма широко циркулирует в нашей жизни.

Другой, не менее интересный, но более спорный рецепт — проводите свое время (время менеджера) с самыми лучшими работниками — помогайте им. Моя личная предвзятость просто кричит: “Что за бред? У всех есть потенциал! Нужно лишь помочь!!!”. Однако за мое недолгое время в индустрии я заметил, что из уже отличных работников можно получить ещё больший результат если им помогать, убирая с дороги бюрократию, шелуху и предоставляя то что они просят. С другой стороны, сколько я не тянул за собой отстающих, как только я отпускал, то все возвращалось на круги свои – печально, но пока что таков мой личный опыт.

Однако, если рассматривать выше описанное, не стоит забывать о том что у каждого человека есть своя предрасположенность/талант. Вместо того чтобы человека пытаться продвинуть и/или запихнуть на определенную позицию, стоит потратить время и понять, а человек вообще может/должен там быть и какая работа более естественна для него. Если таланты человека не предрасполагают его к определенной позиции, то вы не делаете никаких одолжений тем что ставите его туда, все что вы на самом деле делаете это ставите человека на позицию, где он рано или поздно облажается.

Итого:
+: Рецепты и техники
+: Опыт успешных менеджеров
+: Интересные исследования
+/-: Изложение не самое лучше
+/-: Местами отдает догмой
=: Хорошая книга, которая не обязательна, но может вполне пригодиться, если вы стоите во главе (чего либо) и в особенности если вы менеджер. Если есть время, то инвестируйте — читайте.

Название: First, Break All the Rules: What the World’s Greatest Managers Do Differently
Авторы: Marcus Buckingham, Curt Coffman
Обложка:


Признаюсь, я не помню как эта книга попала в поле зрения и однозначно не знаю почему я решил ее прочитать. Несмотря на мою амнезию и нерешительность, я рад что прочитал ee. Честно говоря, эта книга для меня не откровение, а только подтверждение моего уже и так существующего мировоззрения — “лучше меньше, да лучше”, а ещё лучше ещё меньше.

Большинство вещей не приносят никакой ценности в нашу жизнь. Обычно вещи добавляют только головной боли, замедляют, истощают и требуют внимания. Тривиальные проблемы менеджмента вещей заполняют наше сознание и становятся целью и задачей повседневной жизни. Прямо по соседству так же живут бесконечные социальные обязанности и вечное стремление угодить всем и вся – начиная с начальника и заканчивая соседом. А стоит ли это того? Есть ли какая-либо ценность в этом? Почему нужно брать на себя больше, чем ты можешь? Стоит ли заполнять свою жизнь бесконечной чередой тривиальных актов?

Я целиком согласен с автором и рад, что он сформулировал идеи чётко, ясно, с примерами и техниками ведения “дел”. Однако не все идеи были рассмотрены достойно! На мой взгляд автор мог бы более конкретно рассмотреть идею “ценности” и “значимости”. На худой конец, рассмотрение можно было бы спихнуть на другую книгу или ресурс. Понятие “ценности”, конечно глубокий философский вопрос, который не должен быть переадресован в другую абстракцию – “самый высокий вклад в общество”. А если я отличный покупатель? И мой самый высокий вклад в общество это вклад мною заработанных денег в новые, красивые гаджеты! Я же помогаю обществу с продвижением и адаптацией технологий! Или все на чём мы должны сосредоточиться это работа и только работа? И вот это автор не рассматривает, а печально.

Итого:
+: Хорошо и просто изложено
+: Многочисленные примеры
+: Рецепты, методики и техники эссенциалиста
+: Философия жизни
-: Отсутствие дискуссии на тему “ценностей”, “значимости” и “приоритетов”
=: Хорошая книга, которую стоит прочитать! Книга является отличным пособием для всех кто хочет добиться большего и напоминанием, что в жизни нужно активно делать выбор (иначе сделают выбор за вас). Но в тоже самое время в книге отсутствует довольно важный аргумент. Как добавочный материал советую прочитать: “Глубокая работа…” и “Человеческий поиск смысла”.

Название: Essentialism: The Disciplined Pursuit of Less
Авторы: Greg McKeown
Обложки:


Сегодня закончил очередную серию книг от Питера Хамильтона – Пустота. Книги у меня валялись уже достаточно давно, однако не было времени. Вдобавок я хотел перечитать “Звезда Пандоры” и “Иуда освобожден” так как трилогия основывается на этих книгах.

Хамильтон продолжает сагу “Содружества” новой, захватывающей историей. В то время когда человечество находится на критическом эволюционном распутье, вселенная подвергается новой, но очень старой опасности.

Трилогия не разочаровала — захватывающая, непредсказуемая и интересная. Даже после всех прочтённых книг Хамильтона, я все ещё удивляюсь поворотам и развитию событий (возможно это только я). Конечно трилогию можно читать и по отдельности, однако некоторые нюансы будут упущены, поэтому я рекомендую читать по порядку.

Было здорово снова погрузиться в мир “Содружества”, однако отсутствие некоторых героев было не самым приятным поворотом. Но автор прав — даже с учётом того, что люди стали фактически бессмертны, не значит что они будут продолжать жить бесконечно.

Итого:

+: Продолжение саги “Содружества”
+: Легко читается
+: Интересная история и описание окружающего мира
+: В лучших традициях Питера Хамильтона
-: Отсутствие старых героев и несколько “роялей в кустах”
=: Трилогия хорошая и рекомендуется всем кому понравилась сага о “Содружестве”. Однако подготовитесь к некоторым “роялям в кустах” и отсутствию некоторых предыдущих героев.

Название: The Dreaming Void, The Temporal Void, The Evolutionary Void
Автор: Peter F. Hamilton
Обложка:


Книгу я обнаружил буквально неделю назад и с того момента читал фактически каждый раз, когда было время! Я не помню, когда последний раз меня книга так засасывала!

Книга опубликована в сети Лично я сделал PDF бэкап. Чтиво довольно короткое, всего 100 страниц, однако количество полезной информации просто поражает! Никакой воды, ни шагу в сторону, все кратко, чётко и сфокусировано. Местами создаётся ощущение, что можно было бы притормозить и вдаться в пару под-тем, однако автор не тормозит ни на секунду! Любая тема, которая стоит более глубокого рассмотрения, тут же передаётся по внешней ссылке на другой ресурс (книгу).

Книга ориентирована на исполнительных директоров стартапов (обычно они же основатели) и мой личный интерес к стартапам чисто теоретический. Однако я нахожу огромное количество полезной информации в таких материалах, так как методики управление и ведения дел могут быть применены в любой компании, которая хочет стать более эффективной. Пару методик я решил скопировать из книги, чтобы были под рукой – их я предоставлю после “итого”.

Итого:
+: Простое изложение
+: Кратко и чётко – без воды
+: Большое количество целенаправленных методик
+: Наглядные примеры
+: Рассмотрение типичных ошибок
=: На мой взгляд книга просто отличная! Она пригодится не только директорам, но и всем кто хочет оптимизировать процессы как на работе так и в своей жизни. Суммируя технически: ROI книги просто феноменален!

Название: The Great CEO Within
Автор: Matt Mochary
Обложка: Нет

Вырезки из книги:

Writing vs Talking

When two people are discussing an issue, the need to be efficient is important. When a team is discussing an issue, the need to be efficient is paramount, because each inefficient minute is multiplied by the number of people in the discussion.

If you want the most effective and efficient decision-making process, require that anyone who wants to discuss an issue write it up, along with the desired solution, ahead of time. The goal of this write-up is to be thorough enough that at the time of decision-meeting, there are few or no questions. This can be achieved one of two ways:

1. The hard way: Write an extraordinarily thorough analysis from the get-go.
2. The easy way: Write a draft, circulate it to the meeting participants before the meeting, and invite comments and questions. Then write out responses to all of these comments and questions prior to the meeting.

Jeff Bezos, founder and CEO of Amazon, is famous for using this written method. He requires that anyone who wants to bring up an issue or proposal must write up the item fully prior to the decision meeting (with someone else writing up a counterproposal if necessary). The meeting is then spent reading the write-ups. Once the decision-making team has read them all, a decision is made.  If consensus is not reached, an appointed decision-maker makes the call. If there are still open questions, then the decision-maker assigns one or more people to research, and of course write, the needed follow-up. At the end of the next meeting, the decision is made.

This method, though time-consuming for the sponsor, yields extraordinarily thoughtful decisions in a very short amount of time. The extra effort and work by one person creates a net savings in time and energy across the whole group.

Imposing this process on a group is daunting.  Here is a way to ease a group into it:

1. Reserve the first 15 minutes of the meeting for all participants to write out their updates and issues.  Then use another 10 minutes of the meeting for all participants to read each other’s updates and issues. Then discuss and decide.  Use this method for 2-3 meetings, then …

2. Require that all participants write their updates and issues prior to the meeting.  Do not allow people to bring up an issue that they have not already written up. Use the first 10 minutes of the meeting for all participants to read each other’s updates and issues.  Use this method for 1-2 meetings, then …

3. Require that all participants write their updates and issues by a certain time prior to the meeting (eg- 9pm the night before).  Require that all participants read and comment on each other’s updates and issues prior to the meeting. People prove that they have read the docs by having their comments in the docs themselves.  Do not allow people to make comments in the meeting if they haven’t already commented on the docs themselves.

Joy vs Fear

When people start diving into the Conscious Leadership work, they quickly lose their fear.  And just as quickly, they realize that fear was their primary motivator. Once fear is gone, their life becomes much better, but their business suffers.

It is important at this point to keep pushing forward with the CLG work (quickly) to get to a place where you are motivated by joy. Then you will have the best of all worlds.  Joy is an even better motivator than fear, so your business will thrive. And your life will be amazing!

Areas of Responsibility (AORs)

“Tragedy of the commons”.  When several people share responsibility for an action or process, often that action doesn’t get done well, or at all.

To prevent this from happening, group tasks into categories, and assign each category to one—and only one— person. These are your Areas of Responsibility. Apple is famous for having pioneered AORs in Silicon Valley, but now most successful tech companies use this method.

Create a document listing every possible function in the company. Next to each function, list the responsible person. This is the AOR list. It serves as a company directory and ensures that no functions fall through the cracks. Make sure everybody in the company knows how to access the list, and update it as new functions arise or as responsibilities shift.

Sell Yourself, Not Your Company

Cliff Weitzman, CEO of Speechify, realized that it was key to sell himself and not his company. If he was able to do so, he would gain investors for life—investors who would follow him through every pivot, and every company. So, when Cliff realized that trust and like had been established, he shared the story of his life—using a method that his brother Tyler had discovered.

Tyler Weitzman, CEO of BlackSMS, is a unique guy. He likes to research social situations. As an undergrad at Stanford, he researched a method for conveying one’s achievements (or bragging, if you prefer!) while remaining humble and relatable. Through countless interviews of master storytellers, Tyler determined the ultimate structure for telling one’s story in a humble way:

–    Credit: “It could not have happened without [name the others involved].”
–    Hard Work: “We had to put in so much to make it happen, for example, [describe the hard work].”
–    Vulnerability: “It was most difficult for me when…”
–    Duty: “We were driven by our dream to [noble motive].”
–    Gratitude: “I am so proud and thankful that…”

I encourage you to tell your story to a friend using this exact structure. See what comes out. Ask your friend for her reaction. I think you will be amazed.


Год назад я наткнулся на интересное видео, в котором советовали прочитать книгу – “Как это решить”. Я не знал чего ожидать, но хотел найти способы решать проблемы и почти год спустя почти закончил этот квест. Скажу сразу, книга мне настолько понравилась, что я её собираюсь перечитать ещё раз, сразу после того как закончу все практические задачи в конце книги. На этот раз я собираюсь пройти по книге быстрее, выбирая только основные моменты решения задач и даже задумываюсь сделать небольшой конспект и организовать его в шпаргалки.

Тут стоит чуть притормозить и заметить: книга основана на математических методах и большинство примеров изложены в геометрической и/или арифметической формах. Я очень давно не решал никаких математических проблем и не помню банальные вещи: например, теорему Пифагора или как решить интеграл, не говоря уже о более продвинутой математике. В принципе, математику можно пропустить, но я решил этого не делать и в итоге пришлось перечитывать решения и объяснения много раз.

Однако, волков бояться — в лес не ходить! При всем моем старании, я все равно многого не понял, но это ни как не уменьшило мое восхищение и удовольствие от книги. В определенные моменты текст казался каким-то откровением, заставляя меня вспоминать и соотносить похожий опыт в решениях проблем из разных областей деятельности. Джордж По́лиа сказал: “по существу, найти решение, это найти связь между данными и неизвестным”.

Итого:
+: Хорошо изложена
+: Учит думать и передавать знания
+: Пригодится в любом занятии
+: Очень стимулирующая книга
+/-: Решение проблем не является уникально математическим. Хотелось бы больше не математических примеров
=: Книга не легкая и для максимального результата стоит вкладываться. Я считаю, что книга является обязательным материалом для любого, кто хочет решать проблемы. Возможно вы и так отлично умеете их решать, но тогда книга поможет вам передать это умение ученику.

Название: How to solve it
Автор: George Polya
Обложки:

Quote: ”If you can’t solve a problem, then there is an easier problem you can’t solve: find it.”


Next Page »