К основному контенту

Отзыв-конспект "Покажи свою работу!" Остин Клеон


"Кошка села на подушку" - это еще не начало истории.
"Кошка села на подушку собаки" - вот это другое дело.
                                              - Джон Ле Карре, писатель

Издательство "Манн, Иванов и Фербер" в лице Натальи Шаниной не дает мне скучать и продолжает снабжать своими новинками.

В этот раз, в обзоре книжка "Покажи свою работу!" художника Остина Клеона.

Наверно многие подумают - художник? в блоге IT-шника?
Да, сам удивляюсь :)
Но книжка оказалась интересной: она соответствует моему любимому критерию для книг - не взрывает мозг, а показывает, что мои мысли еще кто-то разделяет.

Ну и, на самом деле, советы, которые дает Остин, легко можно применять в нашей отрасли. Мы же тоже часто творим, а не просто кодируем :)

Книга для тех, кто хочет рассказать о своей работе. Фактически пошаговая инструкция. Гид.

Все мысли Остина в книге отражаются в классной подборке цитат известных людей. Одна из них в заголовке.

Поехали по содержанию и моим заметкам.

Понятие "коллективного гения" - есть мнение, что, часто, великие идеи появляются благодаря группе творческих людей. Ну разве это не про команду программистов, которая делает одну работу, любимый мега-проект коллективно?

Про любителей и их активность - "Настоящая пропасть лежит между бездействием и действием, каким бы оно ни было. Любители знают: лучше сделать хоть что-нибудь, чем не сделать ничего".  На эту же тему притча о двух школьниках - часто одноклассник может дать лучше совет по учебе, чем учитель. Потому что одноклассник меньше знает и он недавно сталкивался с теми же трудностями. А учитель давно забыл, каково это - учится, он профессионал.
В своей работе я часто сталкиваюсь с таким понятием, как "зашоренность". Мне кажется мысль со школьниками из той же серии - они не думают, как объяснить правильно, не боятся. Они просто объясняют.

"Лучший способ начать делится своей работой - подумать о том, чему вы хотите научиться, и взять на себя обязательство делать это на глазах других" - тут я вспомнил Мишу Рыжикова, который рассказывал про такое на одной из встреч СПб сообщества "SMART management" (кстати, присоединяйтесь).

"Делитесь тем, что любите, и к вам придут люди, которые любят то же самое" - хорошо и правильно.

Интересный, но сомнительный совет про чтение некрологов. "Когда я читаю о достижениях людей, которых уже нет в живых, мне самому хочется сделать что-нибудь стоящее". Хмм, кто-нибудь знает, где можно почитать? :) Вообще, я думаю, можно и про живых почитать. Эффект разве будет другим? А думать о том, что ты не вечен.... Это грустно :)

Делитесь ежедневно! Не давайте про себя забывать.

Даются советы про то, где брать время. Советы напомнили Лешу Пименова, который так часто отвечает на вопрос "как ты успеваешь так много читать", что устал и написал ответ в блоге, и теперь отвечает ссылками: раз, два  и "просто перестал ездить на работу на машине, поэтому освободилась куча времени в дороге" :) Кстати, рекомендую подписаться на новости Лешиного блога - очень много полезной информации. Он действительно много читает.
А насчет времени - действительно, время есть всегда. Надо просто побороть лень. Только часто это "просто" непросто сделать :)

Стоит ли делиться? Тут все просто:


Еще полезная мысль про то, что короткие ежедневные отчеты, твиты и тому подобное надо просматривать по прошествии некоторого времени и, возможно, их можно будет объединить в нечто большее: статью, книгу.

Остин настоятельно рекомендует завести себе сайт. Со своим доменным именем. Надо заняться, а то у всех знакомых уже есть.

Делитесь не только своей работой, но и тем, что находите: книгами, полезными справочными материалами, статьями.

Ну и встречайтесь с теми, с кем общаетесь онлайн - лично. Это действительно хороший совет. И мне везет на таких друзей :)

Не ленитесь делиться знаниями, это вернется вам сторицей.

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

PS жена тоже почитала. Сказала, что много повторений - можно лаконичней изъясняться. А мне все равно понравилось :)

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu