Накатал статейку на хабр про когнитивные искажения
https://habr.com/ru/company/karuna/blog/555270/
https://habr.com/ru/company/karuna/blog/555270/
Хабр
Когнитивные искажения с примерами для айтишников
Про когнитивные искажения много пишут и много говорят. Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как...
Есть маленькие классные нераскрученные каналы в tg, где попадается интересная инфа
Forwarded from Shit books (Maxi Frolof)
И снова привет!
Заключительный пост, привезенный из отпуска. Статья Винстона Ройса “Managing the development of large software systems”. Написана в 1970 году, недавно юбилей был. Прочитал по совету моего другана Фредерика Брукса. Читал 20 минут - камон, это статья.
Ройс пишет, что фундаментально процесс производства маленькой софтины состоит из двух шагов, “Анализ” и “Производство“. Для большой софтверной системы шагов больше. Пример смотрите на скриншоте 1.
Правда, скриншот что-то напоминает? Не буду томить - это классическое и, вероятно, первое изображение так называемого каскадного (водопадного) процесса. Интересно здесь то, что Ройс приводит это изображение в качестве примера и сразу же пишет, что подобный процесс неминуемо привёл бы к провалу. Вот так новости! Первый раз упомянули водопад и сразу провал? Почему так печально?
Все от того, что обратная связь из поздних этапов разработки имеет высокие шансы уничтожить плоды трудов предыдущих этапов. Так называемые “хвостовые риски” появляются в момент, когда работа вроде бы почти завершена. Эта обратная связь отправляется на предыдущий этап в виде “у вас тут не работает как описано“. Хорошо, если можно поправить и забыть. Но что, если поправить нельзя? Что, если надо менять архитектуру еще выше по потоку? Это уже совсем другие затраты времени и денег! Почему мы не узнали об этом раньше? Смотрите схему реальной обратной связи на скриншоте 2.
Что делать в таком случае? Ройс предлагает знакомый вариант. Если хотите, назовите его MVP. Он говорит, что если бы мы могли ввести стадию “предварительной реализации“, то там мы заранее увидели бы хотя бы намеки на хвостовые риски. Смотрите скриншот 3. Напоминает что-нибудь? Подскажу - вероятно, это одно из самых ранних изображений гибкого процесса с итеративно-инкрементальной моделью.
Так где же мы свернули не туда? Если статья, впервые упомянувшая каскадную модель сразу же разносит ее в пух и прах. Если эта же статья предлагает нам более безопасное итеративное производство - откуда берется спор об эффективности водопадов?
Ответ простой и глупый одновременно. Уже в восьмидесятые, через 18 лет после выпуска статьи, Министерство Обороны США искало себе удобный и логичный метод разработки софта. В статье Ройса, на скриншоте 1, они увидели рекламу каскадной модели. Так этот метод и получил официальное признание - в доктрине DOD-STD-2167A какой-то офисный клерк сказал, что софт надо разрабатывать каскадно. Оттуда это утекло в доктрину НАТО. А оттуда в разработку по всему миру.
Морали тут нет. Небольшое предложение от меня: когда в следующий раз встретите спор о преимуществах каскадной модели в разработке, вспомните, что даже ее якобы создатель Ройс сразу же заклеймил такой подход нерабочим. Более того, каноничное изображение с первого скриншота - никакой не каскад водопадов. Ройс просто подумал, что такая визуализация будет понятнее для целей статьи.
Прикладываю официальную ссылочку для ознакомления со статьей
Заключительный пост, привезенный из отпуска. Статья Винстона Ройса “Managing the development of large software systems”. Написана в 1970 году, недавно юбилей был. Прочитал по совету моего другана Фредерика Брукса. Читал 20 минут - камон, это статья.
Ройс пишет, что фундаментально процесс производства маленькой софтины состоит из двух шагов, “Анализ” и “Производство“. Для большой софтверной системы шагов больше. Пример смотрите на скриншоте 1.
Правда, скриншот что-то напоминает? Не буду томить - это классическое и, вероятно, первое изображение так называемого каскадного (водопадного) процесса. Интересно здесь то, что Ройс приводит это изображение в качестве примера и сразу же пишет, что подобный процесс неминуемо привёл бы к провалу. Вот так новости! Первый раз упомянули водопад и сразу провал? Почему так печально?
Все от того, что обратная связь из поздних этапов разработки имеет высокие шансы уничтожить плоды трудов предыдущих этапов. Так называемые “хвостовые риски” появляются в момент, когда работа вроде бы почти завершена. Эта обратная связь отправляется на предыдущий этап в виде “у вас тут не работает как описано“. Хорошо, если можно поправить и забыть. Но что, если поправить нельзя? Что, если надо менять архитектуру еще выше по потоку? Это уже совсем другие затраты времени и денег! Почему мы не узнали об этом раньше? Смотрите схему реальной обратной связи на скриншоте 2.
Что делать в таком случае? Ройс предлагает знакомый вариант. Если хотите, назовите его MVP. Он говорит, что если бы мы могли ввести стадию “предварительной реализации“, то там мы заранее увидели бы хотя бы намеки на хвостовые риски. Смотрите скриншот 3. Напоминает что-нибудь? Подскажу - вероятно, это одно из самых ранних изображений гибкого процесса с итеративно-инкрементальной моделью.
Так где же мы свернули не туда? Если статья, впервые упомянувшая каскадную модель сразу же разносит ее в пух и прах. Если эта же статья предлагает нам более безопасное итеративное производство - откуда берется спор об эффективности водопадов?
Ответ простой и глупый одновременно. Уже в восьмидесятые, через 18 лет после выпуска статьи, Министерство Обороны США искало себе удобный и логичный метод разработки софта. В статье Ройса, на скриншоте 1, они увидели рекламу каскадной модели. Так этот метод и получил официальное признание - в доктрине DOD-STD-2167A какой-то офисный клерк сказал, что софт надо разрабатывать каскадно. Оттуда это утекло в доктрину НАТО. А оттуда в разработку по всему миру.
Морали тут нет. Небольшое предложение от меня: когда в следующий раз встретите спор о преимуществах каскадной модели в разработке, вспомните, что даже ее якобы создатель Ройс сразу же заклеймил такой подход нерабочим. Более того, каноничное изображение с первого скриншота - никакой не каскад водопадов. Ройс просто подумал, что такая визуализация будет понятнее для целей статьи.
Прикладываю официальную ссылочку для ознакомления со статьей
Forwarded from Pro WEB & IT
Недавно озадачился идеей отключить eval в PHP8. В итоге поисков решения накатал свое простейшее расширение на С, которое делает простую вещь - ломает eval
https://tech.geekjob.ru/disable-evil-eval-in-php-8/
https://tech.geekjob.ru/disable-evil-eval-in-php-8/
Medium
Fullstack CTO – Medium
Read writing from Fullstack CTO on Medium. CTO and co-founder at NEWHR & Geekjob. Every day, Fullstack CTO and thousands of other voices read, write, and share important stories on Medium.
написал статью про мониторинг запросов pg своими руками из Go и палок
https://habr.com/ru/company/karuna/blog/565466/
https://habr.com/ru/company/karuna/blog/565466/
Хабр
Real-time мониторинг тормозящих запросов PostgreSQL своими руками за полчаса
В моей практике не раз были ситуации, когда хотелось посмотреть, какие именно запросы долго тупили в базе в определённый (конкретный) момент времени. А может, запросы не тупили, но каких-то запросов...
Forwarded from Канал «Цинковый прод»
Всем привет. Завтра у нас философский вечер с Гришей Петровым. Будем обсуждать усложнение языков программирования. Был простой язык - и тут фигак, обмазан 100500 фич.
https://www.youtube.com/watch?v=Q0wLO2VB85g
https://www.youtube.com/watch?v=Q0wLO2VB85g
YouTube
Беседа с Григорием Петровым. Усложнение языков программирования
Поговорили с Гришей про усложнение языков программирования.
Python, C++, Tust, Ruby, JS
Python, C++, Tust, Ruby, JS
Forwarded from Anton Okolelov
Опрос для программистов СНГ. Что думаете о том, чтобы уехать заграницу?
Anonymous Poll
29%
Останусь тут
52%
Подумываю уехать
9%
Делал конкретные шаги для переезда
7%
Переехал
3%
Уже вернулся обратно
Forwarded from Тимлид Очевидность | Евгений Антонов
Горящие глаза
Многим знакомо желание работодателя видеть «горящие глаза» у своих сотрудников. Но хотелось бы обсудить, насколько реалистично и этично превращать это в требование.
Где горящие глаза нужны
Наверное, самый главный случай, когда нужен большой энтузиазм в работе, – когда работать приходит джуниор. Впереди его ждет очень долгая и сложная дорога, а ухабы начинаются прямо со старта. Чтобы это всё не бросить (что часто бывает) и расти дальше профессионально, потребуется действительно огромный энтузиазм.
Где горящие глаза не нужны
Почти во всех остальных случаях, если вы работаете с уже компетентным специалистом.
Я не говорю сейчас о наплевательском отношении к работе. Я говорю о купировании лозунгов «МЫ СЕМЬЯ», «НОЧЬ РАБОТЕ НЕ ПОМЕХА», и прочих манипулятивных историях, в которых из людей тянут жизнь капельку за капелькой.
В целом наша работа во многом довольно рутинная, что бы там ни говорили про труд программистов и менеджеров. Да, есть творческие аспекты, но есть и обыкновенные скучные рядовые задачи, которые нам необходимо решать. Есть известное сравнение людей в профессии с малярами и художниками. Да, кое-где иногда нужны одаренные художники. Им, конечно, энтузиазм в работе необходим для реализации своего творческого потенциала. Но в подавляющем большинстве случаев мы с вами – маляры. А маляры просто делают свою обычную работу, и я не понимаю, зачем от них требовать какого-то дополнительного запала.
Однажды меня и моего коллегу работодатель на полном серьезе вызвал на разговор. Единственной его претензией было то, что у нас «не горят глаза». Прямо буквально в этом была суть претензии. При этом работа была абсолютно рутинная, а зарплаты хватало ровно на то, чтобы заплатить за квартиру, купить по скидкам простейшую еду в пятерочке и оплатить интернет. На новую одежду, или лекарства, или поездку куда-то, или технику оставалось от 0 до 1к рублей в месяц. От чего конкретно у меня должны были зажечься глаза, я не понимал ни тогда, ни сейчас.
Этично ли было это требование? Я считаю, что нет. Долго ли мы потом проработали вместе? Тоже нет.
Чем хорошо заменяются горящие глаза
Они заменяются профессиональным и добросовестным трудом.
Это значит, что работу, которую вы беретесь делать, вы делаете хорошо и качественно. Если что-то непонятно или есть сомнения – уточняете, а не лепите откровенно некорректное решение, прикрываясь «в задаче так сказано». Если где-то можете что-то предложить, улучшить, привнести – делаете, потому что так система станет лучше, так труд вас и ваших товарищей станет эффективнее и комфортнее. Если где-то чувствуете, что что-то идет не так – предупреждаете кого следует, или принимаете меры самостоятельно.
Если при этом вам еще и в целом не безразличен продукт, который вы делаете, то это вообще красота. Для работодателя это большая удача найти не просто профессионала, а профессионала, активно заинтересованного в самом продукте. Это не базовое требование к сотруднику, это большая удача (либо сознательное формирование целого комплекса материальных и нематериальных факторов, формирующих именно такой найм).
Итог
Трудитесь хорошо и добросовестно, но не позволяйте на себе бессовестно кататься.
А если вы работодатель, то цените тех, кому ваше дело не безразлично. Не тираньте тех, кто продает вам свой труд. Вам продают свои труд, время, навыки, опыт, а не душу.
Многим знакомо желание работодателя видеть «горящие глаза» у своих сотрудников. Но хотелось бы обсудить, насколько реалистично и этично превращать это в требование.
Где горящие глаза нужны
Наверное, самый главный случай, когда нужен большой энтузиазм в работе, – когда работать приходит джуниор. Впереди его ждет очень долгая и сложная дорога, а ухабы начинаются прямо со старта. Чтобы это всё не бросить (что часто бывает) и расти дальше профессионально, потребуется действительно огромный энтузиазм.
Где горящие глаза не нужны
Почти во всех остальных случаях, если вы работаете с уже компетентным специалистом.
Я не говорю сейчас о наплевательском отношении к работе. Я говорю о купировании лозунгов «МЫ СЕМЬЯ», «НОЧЬ РАБОТЕ НЕ ПОМЕХА», и прочих манипулятивных историях, в которых из людей тянут жизнь капельку за капелькой.
В целом наша работа во многом довольно рутинная, что бы там ни говорили про труд программистов и менеджеров. Да, есть творческие аспекты, но есть и обыкновенные скучные рядовые задачи, которые нам необходимо решать. Есть известное сравнение людей в профессии с малярами и художниками. Да, кое-где иногда нужны одаренные художники. Им, конечно, энтузиазм в работе необходим для реализации своего творческого потенциала. Но в подавляющем большинстве случаев мы с вами – маляры. А маляры просто делают свою обычную работу, и я не понимаю, зачем от них требовать какого-то дополнительного запала.
Однажды меня и моего коллегу работодатель на полном серьезе вызвал на разговор. Единственной его претензией было то, что у нас «не горят глаза». Прямо буквально в этом была суть претензии. При этом работа была абсолютно рутинная, а зарплаты хватало ровно на то, чтобы заплатить за квартиру, купить по скидкам простейшую еду в пятерочке и оплатить интернет. На новую одежду, или лекарства, или поездку куда-то, или технику оставалось от 0 до 1к рублей в месяц. От чего конкретно у меня должны были зажечься глаза, я не понимал ни тогда, ни сейчас.
Этично ли было это требование? Я считаю, что нет. Долго ли мы потом проработали вместе? Тоже нет.
Чем хорошо заменяются горящие глаза
Они заменяются профессиональным и добросовестным трудом.
Это значит, что работу, которую вы беретесь делать, вы делаете хорошо и качественно. Если что-то непонятно или есть сомнения – уточняете, а не лепите откровенно некорректное решение, прикрываясь «в задаче так сказано». Если где-то можете что-то предложить, улучшить, привнести – делаете, потому что так система станет лучше, так труд вас и ваших товарищей станет эффективнее и комфортнее. Если где-то чувствуете, что что-то идет не так – предупреждаете кого следует, или принимаете меры самостоятельно.
Если при этом вам еще и в целом не безразличен продукт, который вы делаете, то это вообще красота. Для работодателя это большая удача найти не просто профессионала, а профессионала, активно заинтересованного в самом продукте. Это не базовое требование к сотруднику, это большая удача (либо сознательное формирование целого комплекса материальных и нематериальных факторов, формирующих именно такой найм).
Итог
Трудитесь хорошо и добросовестно, но не позволяйте на себе бессовестно кататься.
А если вы работодатель, то цените тех, кому ваше дело не безразлично. Не тираньте тех, кто продает вам свой труд. Вам продают свои труд, время, навыки, опыт, а не душу.
Удивительно, когда в некоторых компаниях просьбу о повышении зарплаты до рыночной воспринимают как нелояльность или шантаж. Много раз такое видел в своей жизни.
Противоречие здесь вот в чем:
С одной стороны, человек должен быть максимально практичен на своей работе: везде бест практис, системный подход, ориентированность на максимизацию прибыли бизнеса, исследования рынка и тд.
А с другой стороны - к своей жизни должен относиться как дурачок: мало платят - ну и ладно, зато дружный коллектив, а какие зарплаты на рынке - даже не интересно.
Это просто поразительно странно
Противоречие здесь вот в чем:
С одной стороны, человек должен быть максимально практичен на своей работе: везде бест практис, системный подход, ориентированность на максимизацию прибыли бизнеса, исследования рынка и тд.
А с другой стороны - к своей жизни должен относиться как дурачок: мало платят - ну и ладно, зато дружный коллектив, а какие зарплаты на рынке - даже не интересно.
Это просто поразительно странно
Прикольный список бесплатных публичных API
https://github.com/public-apis/public-apis
Правда, многие из этих апишек можно назвать free только с натяжкой. Virustotal, например, стоит совершенно конских денег, странно, что он в этом списке. Возможно, есть какая-то усеченная версия, хз
https://github.com/public-apis/public-apis
Правда, многие из этих апишек можно назвать free только с натяжкой. Virustotal, например, стоит совершенно конских денег, странно, что он в этом списке. Возможно, есть какая-то усеченная версия, хз
GitHub
GitHub - public-apis/public-apis: A collective list of free APIs
A collective list of free APIs. Contribute to public-apis/public-apis development by creating an account on GitHub.
Появилась игра для определения лучшего шрифта для программирования. Там предлагается попарно сравнить несколько шрифтов, и в конце концов определяется победитель
Мне прям нравится, потому что подбирать шрифт в ide не так удобно, и всё время кажется, что может быть выбрал не тот шрифт, предыдущий был круче.
Правда там пример кода на css, блин. Должны предлагать выбор из языков и подсветок (светлая / темная тема)
Мне прям нравится, потому что подбирать шрифт в ide не так удобно, и всё время кажется, что может быть выбрал не тот шрифт, предыдущий был круче.
Правда там пример кода на css, блин. Должны предлагать выбор из языков и подсветок (светлая / темная тема)
Как получить оффер в FAANG. Подробная инструкция со всеми подводными камнями и ссылками на помогающие ресурсы и инструменты
https://twitter.com/_frsv_/status/1454449701726695428
https://twitter.com/_frsv_/status/1454449701726695428
Хелловинская страшилка про робототехнику.
Есть знаменитое исследование, получившее название "Зловещая долина". Цитата из Википедии:
"...японский учёный Масахиро Мори провёл опрос, исследуя эмоциональную реакцию людей на внешний вид роботов. Поначалу результаты были предсказуемыми: чем больше робот похож на человека, тем симпатичнее он кажется — но лишь до определённого предела.
Наиболее человекоподобные роботы неожиданно оказались неприятны людям из-за мелких несоответствий реальности, вызывающих чувство дискомфорта и страха. Неожиданный спад на графике «симпатии» и был назван «Зловещей долиной», притом Масахиро Мори обнаружил, что анимация усиливает и позитивное, и негативное восприятие."
Ну так вот, а теперь страшилка. Как с точки зрения эволюции появляются страхи? Мы боимся находиться рядом с тиграми и медведями, потому наши предки, которые их не боялись, были съедены и не оставили потомства. Т.е. этот страх инстинктивен и имеет объяснимые корни.
А теперь подумайте про страх перед людьми, которые очень похожи на людей, но не люди. Откуда он?
Есть знаменитое исследование, получившее название "Зловещая долина". Цитата из Википедии:
"...японский учёный Масахиро Мори провёл опрос, исследуя эмоциональную реакцию людей на внешний вид роботов. Поначалу результаты были предсказуемыми: чем больше робот похож на человека, тем симпатичнее он кажется — но лишь до определённого предела.
Наиболее человекоподобные роботы неожиданно оказались неприятны людям из-за мелких несоответствий реальности, вызывающих чувство дискомфорта и страха. Неожиданный спад на графике «симпатии» и был назван «Зловещей долиной», притом Масахиро Мори обнаружил, что анимация усиливает и позитивное, и негативное восприятие."
Ну так вот, а теперь страшилка. Как с точки зрения эволюции появляются страхи? Мы боимся находиться рядом с тиграми и медведями, потому наши предки, которые их не боялись, были съедены и не оставили потомства. Т.е. этот страх инстинктивен и имеет объяснимые корни.
А теперь подумайте про страх перед людьми, которые очень похожи на людей, но не люди. Откуда он?
В сети столько курсов, тренингов, статей и прочей хрени, столько всего, что я хотел бы пощупать в качестве пет-проекта, что глаза разбегаются. А время далеко не резиновое.
Сколько времени я убил на то, что мне потом не пригодилось - уму непостижимо. Ну, разве что, для кругозора полезно.
Пока что для себя решил, что сконцентрируюсь на двух вещах:
1) изучать то, что будешь пытаться применять в ближайшее время
2) изучать то, что капец интересно
Желательно, чтобы было два в одном.
Сколько времени я убил на то, что мне потом не пригодилось - уму непостижимо. Ну, разве что, для кругозора полезно.
Пока что для себя решил, что сконцентрируюсь на двух вещах:
1) изучать то, что будешь пытаться применять в ближайшее время
2) изучать то, что капец интересно
Желательно, чтобы было два в одном.
❤1
Forwarded from Канал «Цинковый прод»
139-ый выпуск Цинкового прода!
Поговорили с Димой Санниковым из All Cups про соревнования программистов.
видео: https://www.youtube.com/watch?v=CzM-bPS2Y2I
Аудио: https://soundcloud.com/znprod/139-govorim-pro-sportivnoe-programmirovanie-s-dmitriem-sannikovym
Поговорили с Димой Санниковым из All Cups про соревнования программистов.
видео: https://www.youtube.com/watch?v=CzM-bPS2Y2I
Аудио: https://soundcloud.com/znprod/139-govorim-pro-sportivnoe-programmirovanie-s-dmitriem-sannikovym
YouTube
#139 Говорим про спортивное программирование с Дмитрием Санниковым
Поговорили про спортивное программирование c руководителем All Cups Димой Санниковым.
А еще у Олега день рождения, так что приходите все :)
All Cups: https://cups.online/
А еще у Олега день рождения, так что приходите все :)
All Cups: https://cups.online/
Дрю ДеВолт хочет убить npm, чтобы сделать его сильней.
Его достало, что практически в каждом проекте в дереве зависимостей есть тысячи npm-пакетов, написанные бог знает кем, и непонятно, как это выстрелит (вспомним печально известный leftpad). Многие пакеты состоят из одной-двух строк, и подключать их как зависимость просто нет смысла.
Поэтому он предложил интересную идею: Дрю будет ПЛАТИТЬ за то, чтобы владельцы пакетов сами уничтожали своё детище, причем чем меньше строк и чем больше популярность, тем сумма будет больше:
Вознаграждение($) = 100 * log10(количество загрузок в неделю / количество строк кода)
Например, для практически однострочного пакета isArray с 51 млн загрузок, это будет $710
Идея в том, что если уничтожение популярных однострочников примет массовое явление и породит хаос, то люди начнут задумываться, а так ли необходимо подключать isArray, isEven и прочий мусор.
Его достало, что практически в каждом проекте в дереве зависимостей есть тысячи npm-пакетов, написанные бог знает кем, и непонятно, как это выстрелит (вспомним печально известный leftpad). Многие пакеты состоят из одной-двух строк, и подключать их как зависимость просто нет смысла.
Поэтому он предложил интересную идею: Дрю будет ПЛАТИТЬ за то, чтобы владельцы пакетов сами уничтожали своё детище, причем чем меньше строк и чем больше популярность, тем сумма будет больше:
Вознаграждение($) = 100 * log10(количество загрузок в неделю / количество строк кода)
Например, для практически однострочного пакета isArray с 51 млн загрузок, это будет $710
Идея в том, что если уничтожение популярных однострочников примет массовое явление и породит хаос, то люди начнут задумываться, а так ли необходимо подключать isArray, isEven и прочий мусор.