fb.com/yaroslav.maxymovych Ярослав Максимович пишет про программистов в белых халатах
Сначала известная цитата одного неизвестного программиста: ...я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами.
И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл.
Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков.
Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты.
Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь.
Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики...
* * *
Вторую часть иллюстрации мне, лет десять назад, рассказывали одни потенциальные покупатели старого интернет-аукциона, когда мы обсуждали технические вопросы, поскольку у нас к тому времени уже было 200 тыс пользователей и десять программистов.
История раннего Ebay:
Первая версия их сайта была смешной, слепленной на коленке. Но внезапно к ним полезли регистрироваться тысячи юзеров ежедневно.
Просто их сайт хорошо и вовремя попал в боль рынка.
И постоянно оч быстро росли.
А сервера стабильно оказывались не готовы к все возростающей нагрузке.
Постоянно добирали программистов, вводили новые функции, неважно по какой причине, то ли по требованию пользователей, или безопасности, или срочности, или чего угодно, не важно в общем. Важно лишь что эти функции были нужны.
В результате, на сервере творилось неизвестно что. Какие-то куски кода, разные версии, зависания, глюки. Программисты в белых халатах негодуют. Но главное что бизнес не останавливался, а продолжал отлично расти и приносить деньги на переписку "с нуля".
К какому-то моменту оказалось что в компании из всех программистов был один главный, который из жадности замкнул на себе все процессы, и только он знал как шаманскими танцами с бубном возвращать работоспособность, когда что-то шло не так.
А это совсем не простая работа в условиях стресса, когда у тебя ежедневно миллионы пользователей с миллионами товаров. То есть, каждая минута простоя стоит реальных денег.
В результате парень вымотался, сказал что ему срочно нужен отпуск. Раздал инструкции и пароли сотрудникам.
И умчался в направлении неизвестного отеля на Багамах, выключив телефон.
Спустя какое-то время сервера опять упали.
Оставшиеся программисты не смогли поднять. Спустя сутки, один из инвесторов психанул, взял самолет и помчался на поиски.
Программиста привезли, сервера подняли.
Это был самый большой, полуторасуточный сбой на Ebay.
Сначала известная цитата одного неизвестного программиста: ...я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами.
И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл.
Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков.
Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты.
Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь.
Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики...
* * *
Вторую часть иллюстрации мне, лет десять назад, рассказывали одни потенциальные покупатели старого интернет-аукциона, когда мы обсуждали технические вопросы, поскольку у нас к тому времени уже было 200 тыс пользователей и десять программистов.
История раннего Ebay:
Первая версия их сайта была смешной, слепленной на коленке. Но внезапно к ним полезли регистрироваться тысячи юзеров ежедневно.
Просто их сайт хорошо и вовремя попал в боль рынка.
И постоянно оч быстро росли.
А сервера стабильно оказывались не готовы к все возростающей нагрузке.
Постоянно добирали программистов, вводили новые функции, неважно по какой причине, то ли по требованию пользователей, или безопасности, или срочности, или чего угодно, не важно в общем. Важно лишь что эти функции были нужны.
В результате, на сервере творилось неизвестно что. Какие-то куски кода, разные версии, зависания, глюки. Программисты в белых халатах негодуют. Но главное что бизнес не останавливался, а продолжал отлично расти и приносить деньги на переписку "с нуля".
К какому-то моменту оказалось что в компании из всех программистов был один главный, который из жадности замкнул на себе все процессы, и только он знал как шаманскими танцами с бубном возвращать работоспособность, когда что-то шло не так.
А это совсем не простая работа в условиях стресса, когда у тебя ежедневно миллионы пользователей с миллионами товаров. То есть, каждая минута простоя стоит реальных денег.
В результате парень вымотался, сказал что ему срочно нужен отпуск. Раздал инструкции и пароли сотрудникам.
И умчался в направлении неизвестного отеля на Багамах, выключив телефон.
Спустя какое-то время сервера опять упали.
Оставшиеся программисты не смогли поднять. Спустя сутки, один из инвесторов психанул, взял самолет и помчался на поиски.
Программиста привезли, сервера подняли.
Это был самый большой, полуторасуточный сбой на Ebay.
Yessssssssss!!!!!!!!!!!!!!!!!!!!!! Мы дожили до того момента, когда можно гордиться своим футболом!
Никогда не думал, что в своей жизни такое напишу, но наша сборная сыграла результативнее Аргентины, Германии, Португалии и, это невероятно, Испании.
Более того, оба гола в игре с Испанией залетели от ноги наших футболистов.
Это невероятно.
Это не-ве-ро-ят-но.
Более того, оба гола в игре с Испанией залетели от ноги наших футболистов.
Это невероятно.
Это не-ве-ро-ят-но.
В число неочевидных обязанностей CTO входит жёсткий пуш всей команды для финализации решения на последних метрах дистанции.
Обычная ситуация, когда всё вроде бы по отдельности готово, а вместе не работает. В этом случае требуется аккуратно собрать всё воедино и заставить работать.
Именно тут требуются сила воли и способность концентрировано совершить подвиг. Это вопрос готовности самого CTO победить, когда карманы есть, рукава есть, полы есть, а пиджака ещё нет.
Обычная ситуация, когда всё вроде бы по отдельности готово, а вместе не работает. В этом случае требуется аккуратно собрать всё воедино и заставить работать.
Именно тут требуются сила воли и способность концентрировано совершить подвиг. Это вопрос готовности самого CTO победить, когда карманы есть, рукава есть, полы есть, а пиджака ещё нет.
https://news.1rj.ru/str/temno пишет, что обучение – это вам не то
1. Обучение – это вовсе не последовательная передача новых знаний. Обучение – это последовательное устранение существующих непониманий (misconceptions).
2. Тестирование – это вовсе не инструмент для проверки того, чему ученик научился. Ученик может выбрать правильный ответ по десятку не связанных с правильным пониманием причин. Тестирование – это инструмент для выявления непониманий. Каждый неверный вариант должен соответствовать какому-то из базовых непониманий, которое мы хотим отловить и устранить.
3. Применять этот подход можно не только для обучения. Например, продажи – это не процесс убеждения людей в том, что им нужно купить наш продукт, а поиск и устранение причин – в голове потребителя или в нашем продукте – по которым его не покупают.
1. Обучение – это вовсе не последовательная передача новых знаний. Обучение – это последовательное устранение существующих непониманий (misconceptions).
2. Тестирование – это вовсе не инструмент для проверки того, чему ученик научился. Ученик может выбрать правильный ответ по десятку не связанных с правильным пониманием причин. Тестирование – это инструмент для выявления непониманий. Каждый неверный вариант должен соответствовать какому-то из базовых непониманий, которое мы хотим отловить и устранить.
3. Применять этот подход можно не только для обучения. Например, продажи – это не процесс убеждения людей в том, что им нужно купить наш продукт, а поиск и устранение причин – в голове потребителя или в нашем продукте – по которым его не покупают.
Telegram
Тёмная сторона / Темнографика
Аркадий Морейнис @amoreynis
РКН id=673c96c2340096358bb6492d
РКН id=673c96c2340096358bb6492d
Подражая Морейнису
Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.
Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.
@maslennikovdm рассказывает про гугловые практики разработки!
Типы ситуаций для вызова внешних экспертов:
Потушить пожар
В IT отделе давно все плохо. Но лиды рапортовали наверх, что все идет по плану. В определенный момент проблем накопилось столько, что произошел взрыв. Учредитель в панике ищет, кто ему поможет.
Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.
Предстартовая подготовка
Новая компания или новый проект или новый большой функционал в старом проекте. Учредитель, или даже CTO или лид сомневаются в выборе технологий и архитектурных решений. Нужен аудит архитектуры прежде чем начать проект.
Регулярный техосмотр
Все вроде бы нормально, но хочется лучше. Нужен аудит процессов, практик, кода и архитектуры, чтобы взглянуть свежим незамыленным взглядом и внести новизну в проект.
Потушить пожар
В IT отделе давно все плохо. Но лиды рапортовали наверх, что все идет по плану. В определенный момент проблем накопилось столько, что произошел взрыв. Учредитель в панике ищет, кто ему поможет.
Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.
Предстартовая подготовка
Новая компания или новый проект или новый большой функционал в старом проекте. Учредитель, или даже CTO или лид сомневаются в выборе технологий и архитектурных решений. Нужен аудит архитектуры прежде чем начать проект.
Регулярный техосмотр
Все вроде бы нормально, но хочется лучше. Нужен аудит процессов, практик, кода и архитектуры, чтобы взглянуть свежим незамыленным взглядом и внести новизну в проект.
Когда вас вызывать?
public poll
Эвакуатор – 12
👍👍👍👍👍👍👍 33%
Потушить пожар – 8
👍👍👍👍👍 22%
У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%
Регулярный техосмотр – 5
👍👍👍 14%
Всегда!!! – 3
👍👍 8%
Предстартовая подготовка – 1
👍 3%
👥 36 people voted so far.
public poll
Эвакуатор – 12
👍👍👍👍👍👍👍 33%
Потушить пожар – 8
👍👍👍👍👍 22%
У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%
Регулярный техосмотр – 5
👍👍👍 14%
Всегда!!! – 3
👍👍 8%
Предстартовая подготовка – 1
👍 3%
👥 36 people voted so far.
Волынкин Николай @Nick_Volynkin поднимает в своём канале @docops одну из фундаментальных проблем в современной разработки, актуальную для компаний любого размера, начиная от стартапов и заканчивая многослойными большими корпорациями: как замапить код и его изменения на требования бизнеса.
Например, мы хотим поменять какой-то участок кода. Как найти все требования, которые он реализует? Как спрогнозировать последствия от изменения?
Кажется, что для этого нужно заранее выстраивать цепочку от коммитов к задачи в трекере и к общим документам уровня feature vision или контракта. Просто номера задачи в сообщении коммита не хватает — часто в задаче есть описание только на функциональном уровне, но не рассказано про значение для бизнеса.
Например, мы хотим поменять какой-то участок кода. Как найти все требования, которые он реализует? Как спрогнозировать последствия от изменения?
Кажется, что для этого нужно заранее выстраивать цепочку от коммитов к задачи в трекере и к общим документам уровня feature vision или контракта. Просто номера задачи в сообщении коммита не хватает — часто в задаче есть описание только на функциональном уровне, но не рассказано про значение для бизнеса.
Рекламирую работу @YaviKosh Виктории Кошелевой, трудившуюся над моей скромной персоной упорно и кропотливо, строя настоящего мультяшного персонажа в стикерах для телеги!
Вопросы про найм людей:
- Какие люди приходят, с каким опытом
- Какого рода вопросы ты задаешь
- Сколько людей обычно собеседуют кандидата
- На что ты обращаешь больше всего внимание
- Что важнее - технические навыки - или софт скиллс
- Взял бы ты на работу талантиливого новичка - и как бы ты определил, что он талантливый
- Как ты поймешь, что в команду нужны еще люди
- Какие люди приходят, с каким опытом
- Какого рода вопросы ты задаешь
- Сколько людей обычно собеседуют кандидата
- На что ты обращаешь больше всего внимание
- Что важнее - технические навыки - или софт скиллс
- Взял бы ты на работу талантиливого новичка - и как бы ты определил, что он талантливый
- Как ты поймешь, что в команду нужны еще люди
Опять Морейнис жжёт! Знакомая проблема?
"У нас в бэклоге есть много задач, которые мы реализуем, но очень медленно. Что делать? Искать инвестиции на увеличение количества разработчиков? Как-то разделять задачи по приоритетам – но как?".
1. Как ни странно, но увеличение количества разработчиков приведет к увеличению количества задач в бэклоге. Каждая новая реализованная фича приведет вызовет мысль о реализации двух новых, вытекающих из нее фич. И так далее – как снежный ком.
2. Как ни странно – 2. Увеличение количества разработчиков на реализацию одной фичи, скорее всего, увеличит время разработки этой фичи. Эффект, подмеченный еще Бруксом в "Мифическом человеко-месяце".
3. Единственный совет, который можно дать в такой ситуации – разделить все задачи на три категории.
– Первая категория – реализация фич, которые уверенно дадут вам улучшение конверсии. Эта уверенность базируется на их очевидности. Следствие из очевидности – увеличение конверсии будет ожидаемым, но не критичным.
– Вторая категория – фичи из серии "Хрен его знает, но это может быть круто". Мы не знаем, сработает это или нет. Но, если сработает – конверсия вырастет в разы.
– Третья категория – фичи из серии "Полезно, красиво, удобно, нужно".
4. Так вот, в первую очередь надо реализовывать задачи из второй категории. Потому что этап стартапа – это этап проверки рискованных гипотез. Только в них заложен шанс на взрывной рост.
5. Если мы добираемся до задач из первой категории, стоит задать себе вопрос – а мы уже исчерпали фантазию по поводу рискованных гипотез? Мы уже довольны тем ростом, который у нас есть?
6. А вот задачи из третьей категории вообще не надо реализовывать. Никогда.
"У нас в бэклоге есть много задач, которые мы реализуем, но очень медленно. Что делать? Искать инвестиции на увеличение количества разработчиков? Как-то разделять задачи по приоритетам – но как?".
1. Как ни странно, но увеличение количества разработчиков приведет к увеличению количества задач в бэклоге. Каждая новая реализованная фича приведет вызовет мысль о реализации двух новых, вытекающих из нее фич. И так далее – как снежный ком.
2. Как ни странно – 2. Увеличение количества разработчиков на реализацию одной фичи, скорее всего, увеличит время разработки этой фичи. Эффект, подмеченный еще Бруксом в "Мифическом человеко-месяце".
3. Единственный совет, который можно дать в такой ситуации – разделить все задачи на три категории.
– Первая категория – реализация фич, которые уверенно дадут вам улучшение конверсии. Эта уверенность базируется на их очевидности. Следствие из очевидности – увеличение конверсии будет ожидаемым, но не критичным.
– Вторая категория – фичи из серии "Хрен его знает, но это может быть круто". Мы не знаем, сработает это или нет. Но, если сработает – конверсия вырастет в разы.
– Третья категория – фичи из серии "Полезно, красиво, удобно, нужно".
4. Так вот, в первую очередь надо реализовывать задачи из второй категории. Потому что этап стартапа – это этап проверки рискованных гипотез. Только в них заложен шанс на взрывной рост.
5. Если мы добираемся до задач из первой категории, стоит задать себе вопрос – а мы уже исчерпали фантазию по поводу рискованных гипотез? Мы уже довольны тем ростом, который у нас есть?
6. А вот задачи из третьей категории вообще не надо реализовывать. Никогда.
GraphQL
public poll
Что это? – 22
👍👍👍👍👍👍👍 54%
Не панацея, как оказалось :( – 8
👍👍👍 20%
Хочу попробовать! – 6
👍👍 15%
Рулит!!! – 5
👍👍 12%
👥 41 people voted so far.
public poll
Что это? – 22
👍👍👍👍👍👍👍 54%
Не панацея, как оказалось :( – 8
👍👍👍 20%
Хочу попробовать! – 6
👍👍 15%
Рулит!!! – 5
👍👍 12%
👥 41 people voted so far.
fb.com/rulezguy Денис Степанов пишет про unixtime:
С удивлением обнаружил, что экосистема ETH не умеет корректно работать со временем. Все работа со временем сводится к unixtime. Это в системе, где каждый вызов функции стоит реальных денег! Это правда, что ли?!
Unixtime не привязан к реальному времени [и таймзонам] никак. Это отдельная временная линия, живущая внутри компов, которую надо отдельной логикой привязывать к реальности, учитывая високосные года и секунды координации.
Предположу, что это можно делать в сайдчейне, чтобы делать это бесплатно, но могли бы уже добавить в структуру хеш для прошедших лет и обновлять его раз в полгода.
С удивлением обнаружил, что экосистема ETH не умеет корректно работать со временем. Все работа со временем сводится к unixtime. Это в системе, где каждый вызов функции стоит реальных денег! Это правда, что ли?!
Unixtime не привязан к реальному времени [и таймзонам] никак. Это отдельная временная линия, живущая внутри компов, которую надо отдельной логикой привязывать к реальности, учитывая високосные года и секунды координации.
Предположу, что это можно делать в сайдчейне, чтобы делать это бесплатно, но могли бы уже добавить в структуру хеш для прошедших лет и обновлять его раз в полгода.
Говнокод
Все знают, как правильно работать, но ни кто правильно не работает. Ваш Кэп.
Это не плохо, а ужасно. Избавляться от него требуется настолько быстро, насколько это возможно. Дело не в том, что он неприятен, а в том, что он - очень токсичный блокер разработки.
В погоне за результатом говнокод накапливается стремительно и избавится от него реально только в несколько подходов. И тут самое главное - не подавиться.
Отрефакторили кусок и как можно скорее через ручное тестирование, через авто, юнит, блекбокс, вайтбокс тесты в бой сбрасывайте! Не давайте рефакторингу залежаться, иначе он вас утопит.
Не жалейте автоматизированного тестирования, особенно юнит-тестирования, - оно даст точнее покрытие и больше уверенности.
Пока не прожуете весь говнокод, нельзя расслабляться. Чередуйте порции говнокода и с заказами бизнеса. Держите ритм.
Говнокод - это опасно.
Все знают, как правильно работать, но ни кто правильно не работает. Ваш Кэп.
Это не плохо, а ужасно. Избавляться от него требуется настолько быстро, насколько это возможно. Дело не в том, что он неприятен, а в том, что он - очень токсичный блокер разработки.
В погоне за результатом говнокод накапливается стремительно и избавится от него реально только в несколько подходов. И тут самое главное - не подавиться.
Отрефакторили кусок и как можно скорее через ручное тестирование, через авто, юнит, блекбокс, вайтбокс тесты в бой сбрасывайте! Не давайте рефакторингу залежаться, иначе он вас утопит.
Не жалейте автоматизированного тестирования, особенно юнит-тестирования, - оно даст точнее покрытие и больше уверенности.
Пока не прожуете весь говнокод, нельзя расслабляться. Чередуйте порции говнокода и с заказами бизнеса. Держите ритм.
Говнокод - это опасно.