Одной из самых важных вещей в разработке и тимлидстве является управление фокусом внимания. Нельзя делать несколько вещей сразу - ты просто потратишь время и еще и устанешь.
Эта вещь далеко не всегда очевидна интуитивно. Такое бывает сплошь и рядом: день потрачен, вроде бы весь день что-то делал, но результат трудно понять и сформулировать.
У разрабов это отвлечение на митинги, обсуждения (особенно у синьоров) и постороннюю от работы активность. У лидов - это коммуникация с какими-то людьми и решение проблем разной важности.
Особенно часто этим страдают начинающие тимлиды: им что-то пишут, а они сразу отвечают и начинают суетиться, кодить че-то. Результат - выгорание при отсутствии результата.
Поэтому, разрабам я бы посоветовал что-то вроде метода pomodoro: делать явные периоды, когда занимаешься задачей со 100% фокусом, игноря вообще всё остальное, и явные периоды отдыха, когда ты, например, сидишь в твиторе и пишешь туда всякую токсичную хуйню. Сколько выделять на то, и сколько на это - индивидуально. Даже от времени дня зависит.
Ну и полезно ставить в календаре слоты "работаю", если часто задалбывают внешними событиями.
Лидам в приципе тоже самое. НЕ реагировать на каждое сообщение в мессенджере. Делать это раз в определенный период времени, например полчаса-час. Если будет что-то совсем срочное - вам позвонят. Я много лет скрываю нижнюю панель на маке, чтобы НЕ ВИДЕТЬ, что кто-то написал что-то. Даже если вы прочли какое-то сообщение, НЕ БРОСАТЬСЯ его сразу делать. Запишите себе в блокнот, в жиру и т.д. Потом спокойно приоритезируете, делегируете и т.д. и делаете в периоды фокуса, причем самое важное.
В состоянии расфокуса невозможно сделать ничего полезного.
По сути всё, что происходит на работе, - это пайплайн. На входе необработанное хаотичное говно, посередине две чередующиеся джобы (фокус и расфокус), на выходе - сделанные самые важные задачи.
Канал Cross Join. Подпишись
Эта вещь далеко не всегда очевидна интуитивно. Такое бывает сплошь и рядом: день потрачен, вроде бы весь день что-то делал, но результат трудно понять и сформулировать.
У разрабов это отвлечение на митинги, обсуждения (особенно у синьоров) и постороннюю от работы активность. У лидов - это коммуникация с какими-то людьми и решение проблем разной важности.
Особенно часто этим страдают начинающие тимлиды: им что-то пишут, а они сразу отвечают и начинают суетиться, кодить че-то. Результат - выгорание при отсутствии результата.
Поэтому, разрабам я бы посоветовал что-то вроде метода pomodoro: делать явные периоды, когда занимаешься задачей со 100% фокусом, игноря вообще всё остальное, и явные периоды отдыха, когда ты, например, сидишь в твиторе и пишешь туда всякую токсичную хуйню. Сколько выделять на то, и сколько на это - индивидуально. Даже от времени дня зависит.
Ну и полезно ставить в календаре слоты "работаю", если часто задалбывают внешними событиями.
Лидам в приципе тоже самое. НЕ реагировать на каждое сообщение в мессенджере. Делать это раз в определенный период времени, например полчаса-час. Если будет что-то совсем срочное - вам позвонят. Я много лет скрываю нижнюю панель на маке, чтобы НЕ ВИДЕТЬ, что кто-то написал что-то. Даже если вы прочли какое-то сообщение, НЕ БРОСАТЬСЯ его сразу делать. Запишите себе в блокнот, в жиру и т.д. Потом спокойно приоритезируете, делегируете и т.д. и делаете в периоды фокуса, причем самое важное.
В состоянии расфокуса невозможно сделать ничего полезного.
По сути всё, что происходит на работе, - это пайплайн. На входе необработанное хаотичное говно, посередине две чередующиеся джобы (фокус и расфокус), на выходе - сделанные самые важные задачи.
Канал Cross Join. Подпишись
👍57👏4🔥1
😌💨
Научное исследование влияния каннабиса на способность программировать:
"Случайные свидетельства употребления каннабиса профессиональными программистами многочисленны. Недавние исследования показали, что некоторые профессионалы регулярно употребляют каннабис во время программирования, даже для решения рабочих задач.
Однако рассказы о влиянии каннабиса на программирование сильно различаются и часто противоречат друг другу. Например, некоторые программисты утверждают, что он снижает их способность генерировать правильные решения, в то время как другие утверждают, что он повышает креативность и концентрацию. Остается потребность в эмпирическом понимании истинного влияния каннабиса на программирование.
В данной работе представлено первое контролируемое обсервационное исследование влияния каннабиса на способность к программированию. На основе внутрисубъектного исследования с участием более 70 человек мы обнаружили, что в экологически обоснованных дозах каннабис значительно снижает эффективность программирования. Программы, выполненные под кайфом содержат больше ошибок и требуют больше времени для написания (𝑝 < 0,05) - эффект от малого до среднего (0,22 ≤ 𝑑 ≤ 0,44). Мы также не нашли никаких доказательств того, что укуренные программисты генерируют больше разнообразных решений"
Канал Cross Join. Подпишись
Научное исследование влияния каннабиса на способность программировать:
"Случайные свидетельства употребления каннабиса профессиональными программистами многочисленны. Недавние исследования показали, что некоторые профессионалы регулярно употребляют каннабис во время программирования, даже для решения рабочих задач.
Однако рассказы о влиянии каннабиса на программирование сильно различаются и часто противоречат друг другу. Например, некоторые программисты утверждают, что он снижает их способность генерировать правильные решения, в то время как другие утверждают, что он повышает креативность и концентрацию. Остается потребность в эмпирическом понимании истинного влияния каннабиса на программирование.
В данной работе представлено первое контролируемое обсервационное исследование влияния каннабиса на способность к программированию. На основе внутрисубъектного исследования с участием более 70 человек мы обнаружили, что в экологически обоснованных дозах каннабис значительно снижает эффективность программирования. Программы, выполненные под кайфом содержат больше ошибок и требуют больше времени для написания (𝑝 < 0,05) - эффект от малого до среднего (0,22 ≤ 𝑑 ≤ 0,44). Мы также не нашли никаких доказательств того, что укуренные программисты генерируют больше разнообразных решений"
Канал Cross Join. Подпишись
👍18🤣14😢5💩3🗿3
Написал статью про семантический поиск с помощью посгреса и OpenAI API.
Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?
TLDR:
1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.
Как всегда, буду рад плюсикам на Хабре:
https://habr.com/ru/companies/karuna/articles/809305/
Канал Cross Join. Подпишись
Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?
TLDR:
1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.
Как всегда, буду рад плюсикам на Хабре:
https://habr.com/ru/companies/karuna/articles/809305/
Канал Cross Join. Подпишись
🔥42🤔8👍6😁2❤1
Посмотрел исходники DOS. 85% на asm, 15% на Си
🥰6
Из мира фронтенда. Я тут вышел из комы, и оказывается, уже во всех основных браузерах работает popover API (https://developer.mozilla.org/en-US/docs/Web/API/Popover_API )
Его можно использовать для менюшек, всплывашек, тостов, диалогов и тд.
Поповеры всегда наверху, независимо от z-index
Клик вне поповера или esc его закрывает.
И тд.
Т.е. на голом html и css можно делать интересные вещи.
Вот примеры:
https://mdn.github.io/dom-examples/popover-api/
Десяток (-другой) лет назад я много верстал, и недоумевал, почему с первой версии css не сделали ничего для "сетки" (все верстали на таблицах) и вот таких вот штук для всплывающих элементов / диалогов, зато постоянно пихали много всякой сомнительной нужности хрени.
Его можно использовать для менюшек, всплывашек, тостов, диалогов и тд.
Поповеры всегда наверху, независимо от z-index
Клик вне поповера или esc его закрывает.
И тд.
Т.е. на голом html и css можно делать интересные вещи.
Вот примеры:
https://mdn.github.io/dom-examples/popover-api/
Десяток (-другой) лет назад я много верстал, и недоумевал, почему с первой версии css не сделали ничего для "сетки" (все верстали на таблицах) и вот таких вот штук для всплывающих элементов / диалогов, зато постоянно пихали много всякой сомнительной нужности хрени.
👍21🆒1
Не реклама.
И Алексей Пименов, и Макс Фролов (автор канала shit books) - на мой взгляд, самые прошаренные люди в галактике во всём, что касается процессов работы организаций. Поэтому было забавно почитать рецензию одного на книгу другого про Кнабан-метод. А если мне занесут за рекламу, то еще и порекомендую эту книгу купить ))
И Алексей Пименов, и Макс Фролов (автор канала shit books) - на мой взгляд, самые прошаренные люди в галактике во всём, что касается процессов работы организаций. Поэтому было забавно почитать рецензию одного на книгу другого про Кнабан-метод. А если мне занесут за рекламу, то еще и порекомендую эту книгу купить ))
😁2👍1
Forwarded from Shit books (Maxi Frolof)
Привет! Дочитал "Канбан-метод. Базовая практика" Алексея Пименова. Читал неделю, книга - всего 200 страниц.
С Лёшей мы знакомы уже шесть лет. О Канбан-методе я узнал именно на лёшином тренинге. "Пора бы написать книгу про Канбан" - так о Лёше шутили уже давно. Вот книга наконец вышла - ура! Вопреки традиции, напишу рекомендацию в самом начале - рекомендую эту книгу тем, кто интересуется Канбан-методом и хочет последовательно разобраться в канбан-инструментарии. На русском более подходящей книги не найти.
Для меня полезнейшая часть книги (канбан-инструментарий) явилась и самой спорной частью. Канбан-метод представлен как "то, что нужно" для интеллектуального труда. Нежелание изучать Канбан названо ключевой проблемой менеджеров наравне с отсутствием управленческого опыта. Мне трудно с этим согласиться - не все канбан-инструменты я считаю полезными. Пример: на мой взгляд, "принципы изменений" Канбана - это мидл-менеджерский подход к изменениям, который на половину состоит из "нормально делай - нормально будет".
Рассказ о практиках Канбана берет практический вектор. Информация дана в формате, как если бы вы уже в процессе чтения изучали рабочий процесс и пытались его улучшить. Это классно вовлекает. Взгляд зацепился за фигуру абстрактного "руководителя". В книге он не раз приводится как эквивалент фатума - все время мешает нормально жить абстрактным "заказчику" и "инженеру". То работы не вовремя подкинет, то приоритеты поменяет. Ух!
Итого - читайте эту книгу, если решили применять Канбан. "Базовая практика" станет отличным помощником с понятной структурой и практическим уклоном. Однако, если хотите больше узнать о производственных процессах - тогда лучше начать с "Цели" или "Проект Феникс". Дальше взял читать пьесы Островского, как советовали мне подписчики в комментариях выше
С Лёшей мы знакомы уже шесть лет. О Канбан-методе я узнал именно на лёшином тренинге. "Пора бы написать книгу про Канбан" - так о Лёше шутили уже давно. Вот книга наконец вышла - ура! Вопреки традиции, напишу рекомендацию в самом начале - рекомендую эту книгу тем, кто интересуется Канбан-методом и хочет последовательно разобраться в канбан-инструментарии. На русском более подходящей книги не найти.
Для меня полезнейшая часть книги (канбан-инструментарий) явилась и самой спорной частью. Канбан-метод представлен как "то, что нужно" для интеллектуального труда. Нежелание изучать Канбан названо ключевой проблемой менеджеров наравне с отсутствием управленческого опыта. Мне трудно с этим согласиться - не все канбан-инструменты я считаю полезными. Пример: на мой взгляд, "принципы изменений" Канбана - это мидл-менеджерский подход к изменениям, который на половину состоит из "нормально делай - нормально будет".
Рассказ о практиках Канбана берет практический вектор. Информация дана в формате, как если бы вы уже в процессе чтения изучали рабочий процесс и пытались его улучшить. Это классно вовлекает. Взгляд зацепился за фигуру абстрактного "руководителя". В книге он не раз приводится как эквивалент фатума - все время мешает нормально жить абстрактным "заказчику" и "инженеру". То работы не вовремя подкинет, то приоритеты поменяет. Ух!
Итого - читайте эту книгу, если решили применять Канбан. "Базовая практика" станет отличным помощником с понятной структурой и практическим уклоном. Однако, если хотите больше узнать о производственных процессах - тогда лучше начать с "Цели" или "Проект Феникс". Дальше взял читать пьесы Островского, как советовали мне подписчики в комментариях выше
👍11🔥2🖕1
Google Cloud случайно удалил всю информацию крупнейшего Австралийского пенсионного фонда UniSuper, включая резервные копии в разных регионах.
Это произошло из-за сбоя, в результате которого удалилась подписка - а из-за этого и вообще всё.
UniSuper повезло, что они делали бекап информации в другие облака, поэтому процесс восстановления идёт.
https://www.theregister.com/2024/05/09/unisuper_google_cloud_outage_caused/
Это произошло из-за сбоя, в результате которого удалилась подписка - а из-за этого и вообще всё.
UniSuper повезло, что они делали бекап информации в другие облака, поэтому процесс восстановления идёт.
https://www.theregister.com/2024/05/09/unisuper_google_cloud_outage_caused/
The Register
UniSuper Google Cloud outage caused by an unfortunate series of events
Duplication across geographies no defense against the 'one-of-a-kind' accidental deletion
😁19🤯9🤷♀7😎3❤2🔥2👍1
Не реклама, от всей души хочу порекомендовать онлайн конфу Podlodka Go Crew. А заодно я вымутил для вас промокод на скидку 500 рублей: Cross_Join_Crew
Если ты — golang-разработчик и страдаешь от недостатка профильных конференций, у нас для тебя клевая новость. Уже 13 мая стартует новый сезон Podlodka Go Crew с темой базы данных. Мы в Podlodka организовываем онлайн-конференции по разным секциям разработки, так что тебе не придётся куда-то ехать. Все знания получишь прямо у экрана своего монитора.
Научимся сравнивать библиотеки и ORM вместе с Арсеном Абдусаламовым из Авито. Познакомимся с решениями как можно подключаться к базам данных и узнаем про «Go way» способ.
Попрактикуемся обращаться с распределённым MySQL с помощью Vitess вместе с Ильёй Ушаковым. Ведь одного инстанса MySQL в какой-то момент может начать не хватать. Что же делать, если переходить на NoSQL совсем неохота? Vitess — ответ на этот вопрос, золотая середина между NoSQL distributed базами данных и проверенным опытом MySQL.
Узнаем всё о продвинутых структурах данных в Redis вместе с Олегом Арутюновым из Контура. Углубимся в преимущества и недостатки подхода, разберёмся с миграциями данных и оптимизацией базы.
Мокать или предзаполнять базы данных? На этот вопрос ответят спикеры из Ozon Fintech. И это будет не просто доклад, а баттл: не на жизнь, а на смерть. Разберёмся, когда какой подход выбрать и стоит ли ограничиваться только одним.
Бонус: публичный собес по работе с PostgreSQL. И это, естественно, не все сессии сезона. Залетай за билетом, чтобы не пропустить специализированную конференцию для Golang-разработчиков: https://podlodka.io/gocrew
Если ты — golang-разработчик и страдаешь от недостатка профильных конференций, у нас для тебя клевая новость. Уже 13 мая стартует новый сезон Podlodka Go Crew с темой базы данных. Мы в Podlodka организовываем онлайн-конференции по разным секциям разработки, так что тебе не придётся куда-то ехать. Все знания получишь прямо у экрана своего монитора.
Научимся сравнивать библиотеки и ORM вместе с Арсеном Абдусаламовым из Авито. Познакомимся с решениями как можно подключаться к базам данных и узнаем про «Go way» способ.
Попрактикуемся обращаться с распределённым MySQL с помощью Vitess вместе с Ильёй Ушаковым. Ведь одного инстанса MySQL в какой-то момент может начать не хватать. Что же делать, если переходить на NoSQL совсем неохота? Vitess — ответ на этот вопрос, золотая середина между NoSQL distributed базами данных и проверенным опытом MySQL.
Узнаем всё о продвинутых структурах данных в Redis вместе с Олегом Арутюновым из Контура. Углубимся в преимущества и недостатки подхода, разберёмся с миграциями данных и оптимизацией базы.
Мокать или предзаполнять базы данных? На этот вопрос ответят спикеры из Ozon Fintech. И это будет не просто доклад, а баттл: не на жизнь, а на смерть. Разберёмся, когда какой подход выбрать и стоит ли ограничиваться только одним.
Бонус: публичный собес по работе с PostgreSQL. И это, естественно, не все сессии сезона. Залетай за билетом, чтобы не пропустить специализированную конференцию для Golang-разработчиков: https://podlodka.io/gocrew
podlodka.io
Онлайн-конференция Podlodka Go Crew, сезон #7
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным вопросам Go-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🌚6🔥2😁2
Как вы наверно знаете, компания Open AI вчера выпустила новую модель GTP-4o (o - от слова omni)
https://openai.com/index/hello-gpt-4o/
Она умеет в режиме реального времени обрабатывать видео, звук и текст, отвечая с минимальной задержкой, сходной с человеческой.
Пока сложно сказать, что это нам даст, но выглядит впечатляюще, посмотрите видос, кто еще не. Просто говоришь как с живым человеком по видеосвязи, и он понимает то, что видит в камере. Ну и слышит. Плюс, сделаны более менее человеческие интонации, а не просто монотонное бормотание.
Я так понимаю, можно показать свой экран в момент отладки кода и попросить подсказать, где баг. Т.е. потенциально это хороший ассистент, с которым можно обсудить какие-то вещи, не описывая их скурпулёзно в чате, а просто сказать "смари, какая хрень, чё это?"
Да и вообще, пора уже это приделать к роботам из Boston Dynamics, и пусть уже делают дома уборку, гладят там, готовят, следят за детьми.
В принципе, можно и в магазин за пивом посылать.
https://openai.com/index/hello-gpt-4o/
Она умеет в режиме реального времени обрабатывать видео, звук и текст, отвечая с минимальной задержкой, сходной с человеческой.
Пока сложно сказать, что это нам даст, но выглядит впечатляюще, посмотрите видос, кто еще не. Просто говоришь как с живым человеком по видеосвязи, и он понимает то, что видит в камере. Ну и слышит. Плюс, сделаны более менее человеческие интонации, а не просто монотонное бормотание.
Я так понимаю, можно показать свой экран в момент отладки кода и попросить подсказать, где баг. Т.е. потенциально это хороший ассистент, с которым можно обсудить какие-то вещи, не описывая их скурпулёзно в чате, а просто сказать "смари, какая хрень, чё это?"
Да и вообще, пора уже это приделать к роботам из Boston Dynamics, и пусть уже делают дома уборку, гладят там, готовят, следят за детьми.
В принципе, можно и в магазин за пивом посылать.
Openai
Hello GPT-4o
We’re announcing GPT-4 Omni, our new flagship model which can reason across audio, vision, and text in real time.
👍16😁7🤔2❤1
Интересно, почему угасают популярные пакеты в Go?
Довольно популярный когда-то пакет для работы с посгресом lib/pq давно сдох и перешел в режим багфиксов. В readme советуют переходить на pgx, и все так и сделали, но блин!
pgx находится в репозитории какого-то Джека Кристенсена. Т.е. ноунейм из интернета владеет популярнейшей либой. Ждём, когда ему надоест.
Дальше squirrel - тоже популярнейшее решение (query builder), тоже с тыщами звёзд, оказывается, разместило у себя, что больше развиваться не будет.
Опенсорс - это круто, но всё же есть какое-то ощущение, что это всё могло бы работать лучше. Одного энтузиазма условного Джека маловато для поддержки суперпопулярных штук. Донаты от людей не особо работают, если что.
Возможно надо сделать модель как у spotify. За пользование гитхабом платишь в месяц какие-то небольшие деньги, а гитхаб распределял бы по авторам реп, в зависимости от популярности.
Довольно популярный когда-то пакет для работы с посгресом lib/pq давно сдох и перешел в режим багфиксов. В readme советуют переходить на pgx, и все так и сделали, но блин!
pgx находится в репозитории какого-то Джека Кристенсена. Т.е. ноунейм из интернета владеет популярнейшей либой. Ждём, когда ему надоест.
Дальше squirrel - тоже популярнейшее решение (query builder), тоже с тыщами звёзд, оказывается, разместило у себя, что больше развиваться не будет.
Опенсорс - это круто, но всё же есть какое-то ощущение, что это всё могло бы работать лучше. Одного энтузиазма условного Джека маловато для поддержки суперпопулярных штук. Донаты от людей не особо работают, если что.
Возможно надо сделать модель как у spotify. За пользование гитхабом платишь в месяц какие-то небольшие деньги, а гитхаб распределял бы по авторам реп, в зависимости от популярности.
👍37🥰4👎3🤔2🥴2
Исследование Cisco показало, что 57% времени разработчики тратят на решение проблем с приложением и кризисные совещания вместо пиления новых фич.
https://developer.cisco.com/articles/from-frustration-to-innovation/from-frustration-to-innovation
https://developer.cisco.com/articles/from-frustration-to-innovation/from-frustration-to-innovation
Cisco DevNet
From frustration to innovation - Cisco DevNet
From frustration to innovation - How full-stack observability can help developers escape war rooms and maximize impact
👍8🌚1
Forwarded from System Design & Highload (Alexey Rybak)
Удержать нельзя отпустить
Мне часто попадается мнение о том, что уходящих сотрудников удерживать нельзя ни в коем случае. Понимаю эту логику, но честно говоря, считаю эту формулу вредной.
Почему считается, что удерживать не нужно? Почти все рассуждения примерно такие: дескать, человек, получивший оффер, уже мысленно уволился, “изменил”, “укусил”, поэтому остается только пристрелить. Даже если удержишь - все равно ненадолго, человек все равно уйдет.
Ребят, да, есть такой шанс, но вообще это ерунда. Любой мало-мальски талантливый сотрудник, особенно в начале карьеры, постоянно в сомнениях и соблазнах, и нет вообще ничего страшного, если вдруг на него “накатило”, и он собрался увольняться. Есть миллион ситуаций, в которых люди не нашли в себе сил поговорить о карьере до момента, когда на руках уже оффер. Либо не было создано для этого условий. Короче, вины “компании” в этой ситуации может быть не меньше, чем сотрудника. Это я не говорю о таких случаях, когда принести оффер в другую контору - это вообще единственный вариант заявить о своих целях и получить повышение (таких компаний становится меньше, но их до сир пор полно, уверен, что каждый из вас уж одну-две такие компании точно вспомнит).
Думаю, что большинство причин, по которым люди думают уволиться - эмоциональные, от усталости, от ограниченного видения плюсов и перспектив, от отсутсвия диалога - короче, эти причины сегодня есть, завтра нет. Надо это учитывать.
Лично знаю очень много примеров, когда бизнес рос очень быстро, у всех была куча дел, и люди просто в какой-то момент банально “задалбывались”, были готовы уйти в никуда из-за усталости, переработок, несовершенства процессов. Их удерживали и старались что-то изменить, и если получалось, то они ещё долго-долго успешно работали. Если бы их всех марали “предателями” - ещё неизвестно, насколько успешно бы развивалась компания. В крутых успешных компаниях люди работают долго. И почти каждый такой “долгожитель” - скорее всего когда-то хотел уволиться, но был удержан.
Короче, хороших людей, приносящих пользу - обязательно нужно удерживать. Только так можно построить по-настоящему крутую культуру. Каждый уход - это челлендж для вас: получше узнать и про человека, и про компанию. И дать шанс человеку, и вашим отношениям, и может быть это сигнал что-то поменять в компании. Да, есть шанс, что сотрудник зазвездился, загордился, преисполнился совершенно неадекватных ожиданий, и оставлять его нет смысла. Каждый ли сотрудник, кто собрался увольняться, такой? Нет. Дайте ему и вам шанс.
Мне часто попадается мнение о том, что уходящих сотрудников удерживать нельзя ни в коем случае. Понимаю эту логику, но честно говоря, считаю эту формулу вредной.
Почему считается, что удерживать не нужно? Почти все рассуждения примерно такие: дескать, человек, получивший оффер, уже мысленно уволился, “изменил”, “укусил”, поэтому остается только пристрелить. Даже если удержишь - все равно ненадолго, человек все равно уйдет.
Ребят, да, есть такой шанс, но вообще это ерунда. Любой мало-мальски талантливый сотрудник, особенно в начале карьеры, постоянно в сомнениях и соблазнах, и нет вообще ничего страшного, если вдруг на него “накатило”, и он собрался увольняться. Есть миллион ситуаций, в которых люди не нашли в себе сил поговорить о карьере до момента, когда на руках уже оффер. Либо не было создано для этого условий. Короче, вины “компании” в этой ситуации может быть не меньше, чем сотрудника. Это я не говорю о таких случаях, когда принести оффер в другую контору - это вообще единственный вариант заявить о своих целях и получить повышение (таких компаний становится меньше, но их до сир пор полно, уверен, что каждый из вас уж одну-две такие компании точно вспомнит).
Думаю, что большинство причин, по которым люди думают уволиться - эмоциональные, от усталости, от ограниченного видения плюсов и перспектив, от отсутсвия диалога - короче, эти причины сегодня есть, завтра нет. Надо это учитывать.
Лично знаю очень много примеров, когда бизнес рос очень быстро, у всех была куча дел, и люди просто в какой-то момент банально “задалбывались”, были готовы уйти в никуда из-за усталости, переработок, несовершенства процессов. Их удерживали и старались что-то изменить, и если получалось, то они ещё долго-долго успешно работали. Если бы их всех марали “предателями” - ещё неизвестно, насколько успешно бы развивалась компания. В крутых успешных компаниях люди работают долго. И почти каждый такой “долгожитель” - скорее всего когда-то хотел уволиться, но был удержан.
Короче, хороших людей, приносящих пользу - обязательно нужно удерживать. Только так можно построить по-настоящему крутую культуру. Каждый уход - это челлендж для вас: получше узнать и про человека, и про компанию. И дать шанс человеку, и вашим отношениям, и может быть это сигнал что-то поменять в компании. Да, есть шанс, что сотрудник зазвездился, загордился, преисполнился совершенно неадекватных ожиданий, и оставлять его нет смысла. Каждый ли сотрудник, кто собрался увольняться, такой? Нет. Дайте ему и вам шанс.
👍38❤13🔥7🤡3
Исследование показало, что 52 процента ответов ChatGPT на вопросы по программированию неверны
Исследователи просмотрели более 517 вопросов в Stack Overflow и проанализировали попытки ChatGPT ответить на них.
«Мы обнаружили, что 52 процента ответов ChatGPT содержат дезинформацию, 77 процентов ответов более многословны, чем человеческие ответы, а 78 процентов ответов страдают от различной степени несоответствия человеческим ответам», — написали они.
Команда также провела лингвистический анализ 2000 случайно выбранных ответов ChatGPT и обнаружила, что они были «более формальными и аналитическими», но при этом отражали «менее негативные настроения» — тот мягкий и веселый тон, который обычно производит ИИ.
Исследователи Purdue опросили 12 программистов (по общему признанию, это небольшой размер выборки) и обнаружили, что они не обнаруживают ошибок, сгенерированных ИИ, в 39 процентах случаев.
Почему это происходит? Возможно, ChatGPT более вежлив, чем люди в сети.
«Последующие полуструктурированные интервью показали, что вежливый язык, четко сформулированные ответы в стиле учебника, а также полнота являются одними из основных причин, по которым ответы ChatGPT выглядели более убедительными, поэтому участники ослабили бдительность и упустили из виду некоторую дезинформацию в ответах ChatGPT», — пишут исследователи.
Думаю, у каждого есть такой приятель-пиздабол, который с видом умудрённого опытом знатока дружелюбным голосом несёт ахинею
Исследователи просмотрели более 517 вопросов в Stack Overflow и проанализировали попытки ChatGPT ответить на них.
«Мы обнаружили, что 52 процента ответов ChatGPT содержат дезинформацию, 77 процентов ответов более многословны, чем человеческие ответы, а 78 процентов ответов страдают от различной степени несоответствия человеческим ответам», — написали они.
Команда также провела лингвистический анализ 2000 случайно выбранных ответов ChatGPT и обнаружила, что они были «более формальными и аналитическими», но при этом отражали «менее негативные настроения» — тот мягкий и веселый тон, который обычно производит ИИ.
Исследователи Purdue опросили 12 программистов (по общему признанию, это небольшой размер выборки) и обнаружили, что они не обнаруживают ошибок, сгенерированных ИИ, в 39 процентах случаев.
Почему это происходит? Возможно, ChatGPT более вежлив, чем люди в сети.
«Последующие полуструктурированные интервью показали, что вежливый язык, четко сформулированные ответы в стиле учебника, а также полнота являются одними из основных причин, по которым ответы ChatGPT выглядели более убедительными, поэтому участники ослабили бдительность и упустили из виду некоторую дезинформацию в ответах ChatGPT», — пишут исследователи.
Думаю, у каждого есть такой приятель-пиздабол, который с видом умудрённого опытом знатока дружелюбным голосом несёт ахинею
👍24😁19💯5🔥3
Тут надо понимать, что обычный программист тоже не ответил бы 100% правильно на все вопросы stackoverflow. Если посмотреть ответы, там иногда такая дичь попадается, что диву даёшься.
Stackoverflow выруливает потому, что много людей вычитывают код. Т.е. бажный код + код ревью = правильный ответ (и то не всегда, мягко говоря)
В этом плане сгенеренный чатом код может даже и получше будет в среднем, чем код рандомного человека. Если его проверять, конечно, а не тупо копипастить.
Stackoverflow выруливает потому, что много людей вычитывают код. Т.е. бажный код + код ревью = правильный ответ (и то не всегда, мягко говоря)
В этом плане сгенеренный чатом код может даже и получше будет в среднем, чем код рандомного человека. Если его проверять, конечно, а не тупо копипастить.
👍10
Новость не новая, но интересная.
Любопытное заявление сделал гугл. Они утверждают, что на Rust писать код в 2 раза быстрее, чем на C++
А команды, перешедшие с Go на Rust, пишут примерно с той же скоростью.
В последнее трудновато поверить, честно говоря
Любопытное заявление сделал гугл. Они утверждают, что на Rust писать код в 2 раза быстрее, чем на C++
А команды, перешедшие с Go на Rust, пишут примерно с той же скоростью.
В последнее трудновато поверить, честно говоря
dev.by
Google: Rust-разработчики вдвое продуктивнее разработчиков на C++
Писать код на Rust оказалось вдвое эффективнее, чем на С++. Такое заявление на конференции Rust Nation UK, прошедшей в Лондоне на прошлой неделе, сделал глава разработки Google Ларс Бергстром. Его команда занимается созданием инструментов и библиотек для…
❤2🤡2