Жизнь – это игра, а в любой игре герой отправляется в путешествие, чтобы преодолеть трудности и победить финального босса. Последние 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.”


Что делает человека выдающимся? Трудолюбие, гениальность, персонаж… а может быть обстоятельства? Автор книги решил проанализировать этот вопрос и выяснить, что на самом деле ведет к большому успеху. Я взялся за книгу по совету друга, однако первая попытка (годы назад) закончилась после нескольких глав. На этот раз я решил пройти до конца, дабы закончить начатое и узнать что нужно делать, чтобы стать успешным.

Если суммировать всю книгу в одно предложение то получаем: “…правильные люди, в правильном месте, в правильное время” (“… the right people, in the right place at the right time.”). Автор разбивает успех на разные факторы и отдельно их анализирует. Фактор времени проявляется весьма интересно в хоккее (и другом спорте) – месяц рождения очень сильно влияет на профессиональный успех. Аналогично год рождения влияет на успех в той или иной индустрии. Место так же влияет на успех – учились ли вы университете с одним из первых доступных компьютеров? Была ли у вас возможность программировать ночи напролет? Человеческий фактор так же интересен, так как автор объясняет почему быть гением недостаточно для успеха… и тут книга очень интересно пересекается с другим пройденным мною материалом – “эмоциональный интеллект”. Автор так же затрагивает не менее интересный и важный культурный и лингвистический фактор.

Честно признаюсь, я перестал задумываться об “успехе” некоторое время назад. Это слово всегда вызывало у меня смятение и путаницу, но несмотря на это книга оказалась интересной. Я думаю, книга вызовет разные реакции у разных людей – с одной стороны можно сделать вывод что “успех” не является продуктом личных достижений, с другой — если не верить в свои силы то что дальше? Автор не пытается придумать рецепт успеха, он просто составляет список ингридиентов и как в любом успешном блюде отличных продуктов должно быть как минимум несколько.

Итого:
+: Хорошо изложена и легко идет
+: Интересный анализ и заключения
+: Исторический и культурный фактор
+/-: Расширяет кругозор, но не очень широко
-: “Доказательства” строятся на подходящих примерах, а что не вписывается, об этом автор не говорит и даже не упоминает!
=: Книга интересная и хорошо изложена – её можно читать по разным причинам и на мой взгляд остаться довольным. Я не думаю что вернусь к этой книге – так как в ней нет той изюминки, которая стимулирует моё мышление. Однако я точно не жалею о проведенном с этой книгой времени.

Название: Outliers: The Story of Success
Автор: Malcolm Gladwell
Обложки:


Next Page »