Привет всем, кто только попал на канал! Меня вы можете знать, как Морозова Ивана и попали вы сюда скорее всего насильно, благо есть такая функция в телеграме. Я пишу тут иногда про мир разработки, иногда про собственную жизнь, иногда скидываю картинки. Возможно в будущем это будет большой популярный канал с несколькими авторами и большим количеством подписчиков. Тогда у вас будет шанс сказать, что вы одни из первых. Добро пожаловать!
Если вы давно не подписывались на личные каналы с небольшой (пока) аудиторией, хотите больше размышлений о том, как выжить в современном мире стрессоустойчивых, легко обучаемых, любящих книги и путешествия людей и плюшечно-кофейных, уютно-офисо-вцентремосковских компаний, рекомендую вам человека, без которого, нужно признаться, я бы не стал создавать свой собственный канал.
Подписывайтесь, https://t.me/ismalife, здесь говорят правду.
Подписывайтесь, https://t.me/ismalife, здесь говорят правду.
Telegram
ismalife
You can contact @ismalife right away.
Почему не нужно читать техническую литературу
- Знания полученные в отрыве от практики не откладываются в голове. Имеет смысл читать только то, чем сможешь воспользоваться сразу, желательно решая какую-либо проблему.
- Даже если есть проблема и книга в которой написано как ее решить, зачем читать 400+ строк сопутствующей воды, рассчитанной на массового читателя, когда есть спецификации, мануалы и референсы?
- Книги по разработке устаревают во время написания. Книги переведенные на русский устаревают вдвойне. Зачем читать неактуальную информацию, когда есть свежая документация для самой последней версии?
- Эгокастинг. Любой из нас читая умную книгу склонен замечать только те факты, которые соответствуют устоявшейся точке зрения и отбрасывать контраргументы.
- Знания полученные в отрыве от практики не откладываются в голове. Имеет смысл читать только то, чем сможешь воспользоваться сразу, желательно решая какую-либо проблему.
- Даже если есть проблема и книга в которой написано как ее решить, зачем читать 400+ строк сопутствующей воды, рассчитанной на массового читателя, когда есть спецификации, мануалы и референсы?
- Книги по разработке устаревают во время написания. Книги переведенные на русский устаревают вдвойне. Зачем читать неактуальную информацию, когда есть свежая документация для самой последней версии?
- Эгокастинг. Любой из нас читая умную книгу склонен замечать только те факты, которые соответствуют устоявшейся точке зрения и отбрасывать контраргументы.
Почему нужно читать техническую литературу
- Лучший способ для новичка погрузиться в предметную область. Самые крутые в своей области книги быстро становятся своего рода библиями, как например "Thinking in Java" или "Learn python the hard way"
- Книги содержат емкую выжимку знаний и опыта суперзвёзд индустрии, собираемых ими годами, как например "Refactoring" Мартина Фаулера или "Clean architecture" Боба Мартина
- Технологии меняются, основы остаются. Наверное, нет смысла читать книгу о новой версии Spring, но прочесть основы работы веб-фреймворков, принцип устройства основных протоколов, разобраться в паттернах проектирование можно только прочтя книгу
- Читать, чтобы быть в контексте. Авторитет легендарных книг многие используют при аргументации. Нужно хотя бы представлять о чем они, дабы изначально не находиться на обочине спора.
- Лучший способ для новичка погрузиться в предметную область. Самые крутые в своей области книги быстро становятся своего рода библиями, как например "Thinking in Java" или "Learn python the hard way"
- Книги содержат емкую выжимку знаний и опыта суперзвёзд индустрии, собираемых ими годами, как например "Refactoring" Мартина Фаулера или "Clean architecture" Боба Мартина
- Технологии меняются, основы остаются. Наверное, нет смысла читать книгу о новой версии Spring, но прочесть основы работы веб-фреймворков, принцип устройства основных протоколов, разобраться в паттернах проектирование можно только прочтя книгу
- Читать, чтобы быть в контексте. Авторитет легендарных книг многие используют при аргументации. Нужно хотя бы представлять о чем они, дабы изначально не находиться на обочине спора.
Люблю такое
На хабре вышла статья Двенадцать способов понять, что находишься в виртуальной реальности описывающая признаки смоделированных миров, таких как ограничение на скорость передвижения (скорость света), магические константы (космологическая постоянная), плохая и скудная детализация отдаленных от мира мест и другие.
Мой любимый момент, когда автор иронично, хотя и без явных признаков, создающий теорию заговора начинает иронизировать над другими популярными схожими теориями.
Как узнаешь в конце это статья от настоящего писателя, который в данный момент пишет роман, отсюда все постмодернистские трюки, но это, конечно, не делает статью менее привлекательной.
На хабре вышла статья Двенадцать способов понять, что находишься в виртуальной реальности описывающая признаки смоделированных миров, таких как ограничение на скорость передвижения (скорость света), магические константы (космологическая постоянная), плохая и скудная детализация отдаленных от мира мест и другие.
Мой любимый момент, когда автор иронично, хотя и без явных признаков, создающий теорию заговора начинает иронизировать над другими популярными схожими теориями.
Как узнаешь в конце это статья от настоящего писателя, который в данный момент пишет роман, отсюда все постмодернистские трюки, но это, конечно, не делает статью менее привлекательной.
Хабр
Двенадцать способов понять, что находишься в виртуальной реальности
Известный польский философ и биограф Станислав Лем как-то заметил, что «Иллюзорность виртуальной реальности, находящийся в виртуальной реальности человек, может установить только путем сравнения с...
#управление_проектами #TL;DR #сарказм
По тем или иным причинам у некоторых людей причастных к разработке софта есть устойчивое отвращение к гибким методологиям, а именно к таким словам, как аджайл и скрам, с лёгкой руки известных топ-менеджеров, любящих кичиться их внедрением, ставшими устоявшимися buzz-words.
Отчасти это объясняется непониманием большинства пользователей истинных смыслов лежащих в основе этих практик и концентрацией на выполнении сопутствующих ритуалов из методичек в надежде на автоматическое решение всех проблем. В связи с чем появляется горький опыт неудачного использования этих самых практик, рождающий неприязнь.
Вернувшись с очередной двухчасовой ретроспективы, посвященной вопросу целесообразности использования фреймворка Скрам, и в частности проведения ежедневных синхронизаций я решил, что идеи скрама изжили себя и пора бы предоставить миру что-нибудь кардинально новое.
Итак, это мой манифест новой методологии ведения проектов под названием ЗДРАВЫЙ СМЫСЛ (ЗС)
1. С точки зрения методологии ЗДРАВЫЙ СМЫСЛ в постоянно меняющемся мире целесообразно планировать работу на короткие сроки, что-то в районе двух недель. Такие сроки назовем ЗАБЕГИ.
2. Очень полезно приходя на рабочее место сообщать коллегам свой прогресс по задачам, дабы оперативно решать возникшие проблемы. Эти мероприятия будут иметь название УТРЕННИК.
4. Оценивать задачи при планировании человеку проще в относительных единицах измерения, нежели в абсолютных. Я решил назвать их поэтично - ОЧКИ ИСТОРИЙ.
5. Чтобы планирование протекало в интерактивном режиме и люди могли оценивать задачи независимо друг от друга можно нанести ОЧКИ ИСТОРИЙ на карты и дать этой игре говорящее название, например ПРЕФЕРАНС ПЛАНИРОВАНИЯ.
6. В конце каждого забега команде полезно собраться и обсудить свои проблемы с целью выработки эффективного решения хотя бы одной из них, такие встречи можно было бы назвать РАЗБОР ПОЛЕТОВ.
Также опционально доступна возможность использования таких ролей в команде, как ВЛАДЕЛЕЦ ПРОДУКТА и МАСТЕР ЗДРАВОГО СМЫСЛА.
Внедряйте методологию ЗДРАВЫЙ СМЫСЛ в своих проектах!
По тем или иным причинам у некоторых людей причастных к разработке софта есть устойчивое отвращение к гибким методологиям, а именно к таким словам, как аджайл и скрам, с лёгкой руки известных топ-менеджеров, любящих кичиться их внедрением, ставшими устоявшимися buzz-words.
Отчасти это объясняется непониманием большинства пользователей истинных смыслов лежащих в основе этих практик и концентрацией на выполнении сопутствующих ритуалов из методичек в надежде на автоматическое решение всех проблем. В связи с чем появляется горький опыт неудачного использования этих самых практик, рождающий неприязнь.
Вернувшись с очередной двухчасовой ретроспективы, посвященной вопросу целесообразности использования фреймворка Скрам, и в частности проведения ежедневных синхронизаций я решил, что идеи скрама изжили себя и пора бы предоставить миру что-нибудь кардинально новое.
Итак, это мой манифест новой методологии ведения проектов под названием ЗДРАВЫЙ СМЫСЛ (ЗС)
1. С точки зрения методологии ЗДРАВЫЙ СМЫСЛ в постоянно меняющемся мире целесообразно планировать работу на короткие сроки, что-то в районе двух недель. Такие сроки назовем ЗАБЕГИ.
2. Очень полезно приходя на рабочее место сообщать коллегам свой прогресс по задачам, дабы оперативно решать возникшие проблемы. Эти мероприятия будут иметь название УТРЕННИК.
4. Оценивать задачи при планировании человеку проще в относительных единицах измерения, нежели в абсолютных. Я решил назвать их поэтично - ОЧКИ ИСТОРИЙ.
5. Чтобы планирование протекало в интерактивном режиме и люди могли оценивать задачи независимо друг от друга можно нанести ОЧКИ ИСТОРИЙ на карты и дать этой игре говорящее название, например ПРЕФЕРАНС ПЛАНИРОВАНИЯ.
6. В конце каждого забега команде полезно собраться и обсудить свои проблемы с целью выработки эффективного решения хотя бы одной из них, такие встречи можно было бы назвать РАЗБОР ПОЛЕТОВ.
Также опционально доступна возможность использования таких ролей в команде, как ВЛАДЕЛЕЦ ПРОДУКТА и МАСТЕР ЗДРАВОГО СМЫСЛА.
Внедряйте методологию ЗДРАВЫЙ СМЫСЛ в своих проектах!
Forwarded from Городские данные (Anna Barinova)
Урбика в партнёрстве с Greenpeace Russia перезапускает карту раздельного сбора мусора: https://beta.recyclemap.ru/.
«Recyclemap часто становится точкой входа в тему защиты окружающей среды: это самый популярный онлайн-проект Greenpeace в России. Мы создавали инструмент, который станет проводником в новый вопрос, и проектировали новый продукт с добротой и заботой. Делая продукт понятнее и проще, мы снижаем порог входа и расширяем сообщество осознанных потребителей.»
«Recyclemap часто становится точкой входа в тему защиты окружающей среды: это самый популярный онлайн-проект Greenpeace в России. Мы создавали инструмент, который станет проводником в новый вопрос, и проектировали новый продукт с добротой и заботой. Делая продукт понятнее и проще, мы снижаем порог входа и расширяем сообщество осознанных потребителей.»
Как вы программируете?
Вот вроде бы нет ничего эдакого в описании данного процесса. Открываешь любимый редактор, пишешь код, гуглишь, пишешь снова.
Но большая часть процесса программирования происходит в нашем бессознательном. Когда мы гуляем, едим, спим. Бывало ли, что приходя на работу вы легко решали проблему, с которой никак не могли справиться накануне вечером? Причем над которой вы даже не задумывались осознанно вне рабочего места.
Вот вроде бы нет ничего эдакого в описании данного процесса. Открываешь любимый редактор, пишешь код, гуглишь, пишешь снова.
Но большая часть процесса программирования происходит в нашем бессознательном. Когда мы гуляем, едим, спим. Бывало ли, что приходя на работу вы легко решали проблему, с которой никак не могли справиться накануне вечером? Причем над которой вы даже не задумывались осознанно вне рабочего места.
Сервис, который генерит изображения несуществующих котов. Если всех существующих вы уже пересмотрели
https://thiscatdoesnotexist.com/
https://thiscatdoesnotexist.com/
Очень понравился подкаст Devleads, посвященный проблемам, которые стоят перед тимлидами и руководителями разработки. На данный момент у подкаста всего два выпуска:
Первый об эмоциональном выгорании - феномене встречающимся во многих интеллектуальных сферах деятельности, предполагающих высокий уровень стресса и ответственности, о том, как вовремя распознать выгорание и что такое синдром самозванца.
Второй выпуск о способах мотивации сотрудников, таких как материальная и нематериальная мотивация и почему в творческих профессиях вторая намного важнее первой.
Обе темы постараюсь подробнее раскрыть в отдельных постах в ближайшее время. А пока прилагаю TED talk о парадоксе свечи - эксперименте, проводившимся множество раз и каждый раз показывающем падение эффективности выполнения задачи, требующей нестандартного инженерного мышления при увеличении финансовой награды, а также о том, что действительно мотивирует людей в работе после удовлетворения базовых материальных нужд
https://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_about_our_work
Первый об эмоциональном выгорании - феномене встречающимся во многих интеллектуальных сферах деятельности, предполагающих высокий уровень стресса и ответственности, о том, как вовремя распознать выгорание и что такое синдром самозванца.
Второй выпуск о способах мотивации сотрудников, таких как материальная и нематериальная мотивация и почему в творческих профессиях вторая намного важнее первой.
Обе темы постараюсь подробнее раскрыть в отдельных постах в ближайшее время. А пока прилагаю TED talk о парадоксе свечи - эксперименте, проводившимся множество раз и каждый раз показывающем падение эффективности выполнения задачи, требующей нестандартного инженерного мышления при увеличении финансовой награды, а также о том, что действительно мотивирует людей в работе после удовлетворения базовых материальных нужд
https://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_about_our_work
Google Podcasts
devleads podcast
devleads - открытое сообщество тимлидов, руководителей разработки и всех неравнодушных к менеджменту в IT-сфере.
Всех нас объединяет одно – технический бэкграунд. Причем не так важно, программировали ли вы микроконтроллеры или занимались тестированием мобильных…
Всех нас объединяет одно – технический бэкграунд. Причем не так важно, программировали ли вы микроконтроллеры или занимались тестированием мобильных…
Сколько моделей принятия решения вы знаете? Этот сервис может помочь выбрать нужную в зависимости от условий, в которых решение необходимо принять
https://thedecider.app/?fbclid=IwAR3ksbsy5WQu97IefzStzVGgkwVl-Y-igR_b_Sz_bATC_8sRN6fRhIvd9XU
https://thedecider.app/?fbclid=IwAR3ksbsy5WQu97IefzStzVGgkwVl-Y-igR_b_Sz_bATC_8sRN6fRhIvd9XU
How Do We Decide?
The Decider – Team Decision Making and Decision Making Models, by NOBL Collective
#управление
Есть ли у вас на работе люди, являющиеся своего рода центрами определенных знаний, недоступных никому другому? Я уверен, что есть. Очень часто можно услышать истории, о том, как проекты, большие и малые, во многих, даже самых прогрессивных компаниях держатся на одном-двух специалистах, которые участвовали в проекте с ранних пор и обладают исчерпывающими знаниями о самых тонких нюансах. Таких людей обычно ценят, уважают и всячески стараются удержать.
Я же считаю, что наличие в проекте таких людей должно быть главной головной болью менеджера, а главной целью - поскорее от них избавиться и вот мои аргументы:
- Такого человека очень сложно уволить. Потерять члена команды, на котором держится проект - смерти подобно. Незаменимый специалист, как правило, сам чувствует свою незаменимость и может начать этим пользоваться.
- Такой человек может уйти самостоятельно. За любым хорошим специалистом непрестанно охотится армия рекрутеров и люди часто сами меняют работу
- Ротация становится невозможной. На проект все сложнее привлечь и обучить новых людей, так как информация скрыта и требует постоянной коммуникации с "центром знаний"
- Работа такого человека неэффективна. Если специалиста постоянно отвлекают менее опытные члены команды, он сам перестает успевать приносить пользу, ввиду частого переключения контекста.
У любого человека может возникнуть соблазн стать таким вот "центром информации", дабы закрепить свои позиции внутри компании ну или просто ради удовлетворения чувства собственной важности, но нужно помнить, что хорошего специалиста помимо знаний и опыта характеризует доступность этих знаний для остальных, а информация это единственный ресурс, которого не становится меньше, когда им делишься.
Есть ли у вас на работе люди, являющиеся своего рода центрами определенных знаний, недоступных никому другому? Я уверен, что есть. Очень часто можно услышать истории, о том, как проекты, большие и малые, во многих, даже самых прогрессивных компаниях держатся на одном-двух специалистах, которые участвовали в проекте с ранних пор и обладают исчерпывающими знаниями о самых тонких нюансах. Таких людей обычно ценят, уважают и всячески стараются удержать.
Я же считаю, что наличие в проекте таких людей должно быть главной головной болью менеджера, а главной целью - поскорее от них избавиться и вот мои аргументы:
- Такого человека очень сложно уволить. Потерять члена команды, на котором держится проект - смерти подобно. Незаменимый специалист, как правило, сам чувствует свою незаменимость и может начать этим пользоваться.
- Такой человек может уйти самостоятельно. За любым хорошим специалистом непрестанно охотится армия рекрутеров и люди часто сами меняют работу
- Ротация становится невозможной. На проект все сложнее привлечь и обучить новых людей, так как информация скрыта и требует постоянной коммуникации с "центром знаний"
- Работа такого человека неэффективна. Если специалиста постоянно отвлекают менее опытные члены команды, он сам перестает успевать приносить пользу, ввиду частого переключения контекста.
У любого человека может возникнуть соблазн стать таким вот "центром информации", дабы закрепить свои позиции внутри компании ну или просто ради удовлетворения чувства собственной важности, но нужно помнить, что хорошего специалиста помимо знаний и опыта характеризует доступность этих знаний для остальных, а информация это единственный ресурс, которого не становится меньше, когда им делишься.
Bus factor
Bus factor это метрика здоровья проекта, вычисляемая как минимальное количество человек, которых должен сбить автобус, чтобы проект полностью остановился. А какой bus factor у вашего проекта?
Bus factor это метрика здоровья проекта, вычисляемая как минимальное количество человек, которых должен сбить автобус, чтобы проект полностью остановился. А какой bus factor у вашего проекта?
Советский UX
Ручка разблокировки двери и стеклоподъёмник в старых москвичах выглядят одинаково. Интересно, сколько людей повыпадало из машины на ходу, пытаясь открыть окно.
Ручка разблокировки двери и стеклоподъёмник в старых москвичах выглядят одинаково. Интересно, сколько людей повыпадало из машины на ходу, пытаясь открыть окно.
Forwarded from xpinjection via @like
Сегодня на кухне за поеданием торта с командой родилась гениальная идея интерактивного формата собеседования и я решил поделиться задумкой. Итак, кандидату предоставляется на входе выбор остаться на классическом формате собеседования или переключиться интерактивный.
В случае остановки на интерактивном варианте, ему предлагаются такие правила:
- Все вопросы будут разделены по темам и "категориям сложности", выраженные числами. Например, Hibernate за 300 или Spring Boot за 700. Кандидат может выбирать из оставшихся вариантов следующий вопрос. Это дает ему возможность выстроить стратегию собеседования под себя.
- Целью кандидата является набрать как можно больше баллов за ограниченное время. После каждого ответа на вопрос собеседующие оценивают ответ и дают какую-то сумму очков за ответ без объяснения причин.
- На разные позиции можно заранее объявлять ожидаемый от кандидата уровень, выраженный в количестве набранных баллов. Например, на синьора ожидается 5000 баллов за полтора часа.
- Чтобы сделать собеседование еще более интерактивным, кандидату предоставляется на выбор 4 карточки с опциями (пропустить вопрос, звонок другу, заглянуть в stack overflow, отвечает сам интервьювер). Кандидат может выбрать из этих карточек себе 3 и применить каждую из них не более одного раза за собеседование.
Мне кажется, приоткрытого занавеса хватит, чтобы оценить идею. Я бы очень хотел поучаствовать в таком собеседовании в роли кандидата, а вы? Нет скучным собеседованиям! ;)
В случае остановки на интерактивном варианте, ему предлагаются такие правила:
- Все вопросы будут разделены по темам и "категориям сложности", выраженные числами. Например, Hibernate за 300 или Spring Boot за 700. Кандидат может выбирать из оставшихся вариантов следующий вопрос. Это дает ему возможность выстроить стратегию собеседования под себя.
- Целью кандидата является набрать как можно больше баллов за ограниченное время. После каждого ответа на вопрос собеседующие оценивают ответ и дают какую-то сумму очков за ответ без объяснения причин.
- На разные позиции можно заранее объявлять ожидаемый от кандидата уровень, выраженный в количестве набранных баллов. Например, на синьора ожидается 5000 баллов за полтора часа.
- Чтобы сделать собеседование еще более интерактивным, кандидату предоставляется на выбор 4 карточки с опциями (пропустить вопрос, звонок другу, заглянуть в stack overflow, отвечает сам интервьювер). Кандидат может выбрать из этих карточек себе 3 и применить каждую из них не более одного раза за собеседование.
Мне кажется, приоткрытого занавеса хватит, чтобы оценить идею. Я бы очень хотел поучаствовать в таком собеседовании в роли кандидата, а вы? Нет скучным собеседованиям! ;)
Синдром самозванца
Синдром самозванца - психологическое явление, при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. Это то самое чувство, когда, несмотря на все ваши очевидные заслуги, вы думаете и чувствуете, что все, чего вы добились не связано непосредственно с вашими личностными качествами, а является счастливым стечением обстоятельств. Синдром самозванца ведет к пониженой самооценке, недовольству жизнью и эмоциональному выгоранию.
Чаще всего синдрому самозванца подвержены люди научных или технических специальностей. Это связано со следующими причинами:
- В этих областях необходимы углубленные знания, которые облегчают решения многих проблем. Легкие решения, в свою очередь, ведут к обесцениванию собственных успехов.
- Люди склонны связывать самооценку со своими знаниями и умениями. Работа с областями, в которых знать все невозможно не идет ей на пользу.
- В условиях высокой конкуренции кажется, что тебя окружают люди, намного умнее и увереннее в себе, хотя частенько они сами переживают точно такие же проблемы.
Наш разум это лишь искаженная в некоторой мере проекция реальности вокруг нас. И это искажение чаще всего работает в негативную для нас сторону, заставляя думать и чувствовать, а также раз за разом убеждать себя в собственной неполноценности. Проблема в том, что от самоубеждения довольно сложно абстрагироваться, каким абсурдным оно бы ни было. Для борьбы с синдромом самозванца прилагаю небольшую памятку, подсмотренную на сайте codingmindfully.com о психологических проблемах у разработчиков.
Синдром самозванца - психологическое явление, при котором человек не способен приписать свои достижения собственным качествам, способностям и усилиям. Это то самое чувство, когда, несмотря на все ваши очевидные заслуги, вы думаете и чувствуете, что все, чего вы добились не связано непосредственно с вашими личностными качествами, а является счастливым стечением обстоятельств. Синдром самозванца ведет к пониженой самооценке, недовольству жизнью и эмоциональному выгоранию.
Чаще всего синдрому самозванца подвержены люди научных или технических специальностей. Это связано со следующими причинами:
- В этих областях необходимы углубленные знания, которые облегчают решения многих проблем. Легкие решения, в свою очередь, ведут к обесцениванию собственных успехов.
- Люди склонны связывать самооценку со своими знаниями и умениями. Работа с областями, в которых знать все невозможно не идет ей на пользу.
- В условиях высокой конкуренции кажется, что тебя окружают люди, намного умнее и увереннее в себе, хотя частенько они сами переживают точно такие же проблемы.
Наш разум это лишь искаженная в некоторой мере проекция реальности вокруг нас. И это искажение чаще всего работает в негативную для нас сторону, заставляя думать и чувствовать, а также раз за разом убеждать себя в собственной неполноценности. Проблема в том, что от самоубеждения довольно сложно абстрагироваться, каким абсурдным оно бы ни было. Для борьбы с синдромом самозванца прилагаю небольшую памятку, подсмотренную на сайте codingmindfully.com о психологических проблемах у разработчиков.