Как сблизиться с командой? Памятка для руководителей и эйчаров

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

1️⃣ Интересуйтесь состоянием сотрудников. Оторвитесь от работы и спросите у коллеги, как дела. Сделайте это, даже если вам неловко, — в этом и заключается лидерство. Только не стоит навязывать разговор, если человек не хочет. Главное, чтобы каждый мог свободно рассказывать о наболевшем при необходимости.

2️⃣ Начните делиться эмоциями. Если для вас это комфортно, открыто расскажите сотрудникам о своих чувствах или личной проблеме. Когда вы не скрываете свою уязвимость, остальным становится безопаснее в вашем присутствии. В перспективе людям будет проще и приятнее работать вместе с вами и выкладываться на полную.

3️⃣ Поощряйте сотрудников отдыхать. Больше четверти людей не уходят в отпуск больше чем на четыре дня, а абсолютное большинство по итогам года не отгуливает отпуск целиком. Проблема в том, что отпусками и отгулами пренебрегают сами руководители. В компаниях, где руководители спокойно отрываются от работы, чтобы восстановить силы, сотрудники следуют их примеру.

4️⃣ Постарайтесь увидеть человека в каждом сотруднике. Многие компании декларируют подобные ценности на бумаге, но на практике руководители и эйчары часто фокусируются на совсем других вещах. Хотя практика показывает, что люди со здоровой психикой активнее вовлекаются в работу и в конечном итоге приносят больше пользы бизнесу.

🔗 Как обстановка на работе отражается на психическом здоровье — смотрите по ссылке

тревожный эйчар | психологическая поддержка команд

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

#Жека #machinelearning

О проекте, который надо было убить
#ml #career #fail #coolstorybob

Если меня на собесе просят “рассказать про какой-нибудь проект” (в такой формулировке – плохой вопрос) или “описать случай, когда я принял непопулярное решение” (куда лучше), то я теперь эту историю рассказываю – как пришел в компанию и с порога прибил проект.

Немного предыстории для контекста. Пришёл я в текущую компанию в апреле 2020, как раз как лохдаун обьявили, а дочке исполнилось 4 месяца.  Работа с дивана, порой дитё подсовывают, когда дебажишь, поначалу по 5 звонков в день, чтоб во все вникнуть, доступов еще нет, мак не привезли из-за бешеного спроса во время ковида – в-общем, было весело. Пришел синьором, а подопечных всего трое, причем неформально, и двух из них я скоро потерял. Девушка-миддл, которая меня вводила в курс дела, почти сразу ушла недели на 3 в бёрнаут, еще полгода мучалась и в итоге уволилась (у нее ADHD, а ковидное одиночество привело к бессоннице и куче проблем со здоровьем) - планировала изучать мозг, чтоб лучше понимать, что у нее самой в мозгу происходит. А толкового пацана-джуна продолбали сами, ему два раза продлевали временный контракт, и по закону Нидерландов с 3-го раза обязаны были дать постоянный, а одобренного бюджета на это не было. И так я остался на время с одной индусской, которая топ, но все же.

Один из проектов, который я перенял – LaQua, language quality assessment, эдакий PoC (proof of concept), затянувшийся на полтора года. Примерно в 10% случаев ревьюеры отшивают статьи из-за низкого качества языка, и хочется автоматически находить совсем уж дико написанные статьи. К тому же, одна из схем монетизации – можно подсветить плохо написанные абзацы и посоветовать обратиться к сервису proof-reading. На момент моего прихода бизнес-ожидания были колоссальные, хотели что-то типа научной версии Grammarly, был, конечно, и mismanagement, т.к. сильно доверились синьору, который был до меня и неплохо так наломал дров (чувак – с синдромом Ph.D.-гая, даже по оставшимся от него тикетам было видно, что он только и делал что архив читал, а про прод и Валуе (аминь!) не особо думал).

Еще проверка гипотезы затянулась, т.к. уж больно хорош, как кажется, датасет – сотни тысяч статей, прошедших через сервис по пруф-ридингу, т.е у нас было много пар вида “оригинальное предложение; его поправленная версия”. Пришел, чекнул, что есть, как seq2seq задача совсем не заводилась, ладно, пытаемся зафайнтюнить SciBERT на бинарную классификацию "хорошее vs. плохое предложение”. И тут я понимаю, что все что чуваки делали работает примерно на уровне шума. За месяц проверил сам пару гипотез (хотелось как регрессию решить, предсказывать левенштейна, т.е. как сильно надо поправить оригинальный параграф), и устроил внутри команды своего рода Толоку из Экселя, палок и изоленты – быстро чекнули гипотезу, что мы сами вообще можем отличить хорошие параграфы от плохих. На выходе - 60% точности (если подсвечиваем параграф текста как плохой, это только на 60% верно), да еще и black box.

Идей, конечно, много было, там и Grammarly опубликовали свой алгоритм, да и просто крутая тема (у Grammarly, говорят, в проде не нейронки, но тссс….). Но все же если фэйлить, то надо быстро. Вот я и собрал всех оунеров, менеджеров, представился, и донес до них, что наши попытки пора прикрыть и лучше переключиться на оценку сторонних решений типа Grammarly. То есть я рекомендовал не полностью прибить проект, а просто купить продукт, вместо того, чтоб парой джунов и одним синьором сделать его с нуля. Зашло неплохо, удивился, как адекватно это воспринял и мой менеджер, и прочие. Такой вот конструктивно-негативный опыт, вроде и фэйл, но вроде и нет. Вывод: всегда надо держать в уме вариант, что проект, который ты сейчас тащишь, воообще-то может быть выгодно прибить. И хорошо бы иметь весомые аргументы, чтоб (самому себе) объяснить, почему проект должен существовать. Конечно, когда дают свободу делать PoC, все не так жестко, но тем не менее, надо понимать, что вместо текущего исследовательского проектика ты вообще-то можешь делать другой, потенциально очень прибыльный.

Курс по базам данных для начинающих

Серия уроков по серверам баз данных. Как установить базу данных, как настроить доступ, как сделать бэкап, как создать кластер базы данных, как настроить репликацию таблиц, базы данных. Ответы на эти вопросы вы получите в данном видеокурсе.

Подробнее: 👉 тут

#видео #бд

Буфферный кеш в PostgreSQL

Очередная серия статей от ребят из postgres. На этот раз о механизме журналирования, он же write-ahead log, он же WAL. Статьи не из лёгких и требуют серьезного погружения.

В первой статье автор рассказывает о такой важной штуке, как буферный кеш. Буферный кеш представляет собой массив буферов, каждый буфер – это место под одну страницу данных. Чтобы работать с данными, процессы читают страницы в кеш, тем самым далее экономя на обращениях к диску. Для поиска страниц в кеше используются хеш-таблицы, но, конечно, со своими нюансиками.

Когда кеш переполняется, что-то нужно вытеснить. Для этого используется алгоритм clock-sweep, который по кругу перебирает все буферы, уменьшает счётчики обращений, учитывает ещё разную хитрую магию и решает кого бы вытеснить.

Чтобы потрогать кеш руками, есть расширение pg_buffercache. С помощью специального запроса можно посмотреть количество страниц, счётчик обращений ним, привязку к процессу. Также можно узнать, какая часть каких таблиц закеширована и насколько активно используются эти данные.

Размер кеша – это, что рекомендуют менять сразу после развёртывания базы. По умолчанию он равен 128 Мб. Нет конкретного значения, которое стоит выбрать для кеша, всё зависит от задачи и лучше выяснять на практике. Автор рекомендует взять для начала 1/4 оперативной памяти. Также стоит учитывать, что postgres использует обычные вызовы операционной системы, поэтому происходит двойное кеширование – кеш СУБД и кеш ОС.

Горячий вопрос: прогрев кеша. В postgres для этого есть расширение pg_prewarm. С помощью него можно сразу прочитать в кеш данные определённых таблиц. Также можно сохранять состояние кеша и восстанавливать после перезагрузки сервера.

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

#skills #database

Нестареющая классика, шпаргалка по SSH

Очень давняя, но информативная статья, которая лежит у меня как шпаргалка, если что-то подзабыл.

Начинается с базы, коротко и по делу. Не нужно авторизовываться по паролю, настраивайте вход по ключу. Ключ генерируется одной командой и может быть закрыт паролем. Разумеется, ключ состоит из двух частей: открытой и закрытой. На сервер ключ можно скопировать ручками или специальной командой. У сервера есть свой ключ, который помещается в known_hosts. Для копирования данных через ssh-сессию есть команда scp. Это база. Теоретические основы были в отдельном посте.

Дальше, как всегда, интереснее:
– с помощью дополнительной утилиты sshfs можно предоставить доступ к удалённой файловой системе. При этом локальные приложения не будут подозревать, что работают с удалённой файловой системой

– можно выполнить команду на удалённом сервере, оставаясь в локальной командной строке. Интересное применение, например, вывести содержимое какого-то файла и с помощью конвейера скормить его локально запущенной программе

– если хотим вызвать удалённую команду, а её вывод поместить в локальный файл, то для этого можно пробросить stdin/out

– чтобы каждый раз не вспоминать ip-адрес, куда подключаешься, или, наоборот, не вспоминать длиннющее имя сервера, то для этого можно в конфиг файле ssh прописать алиасы

– если локальная машина имеет графический x-сервер, а удаленная нет, то можно сделать так, чтобы приложения с сервера рисовались у вас на рабочем столе

– публичные wi-fi совсем небезопасны, а VPN порой просто режут, поэтому есть выход – работа ssh в режиме socks-proxy

– заканчивается статья такими схемами, от которых волосы начинают шевелиться: проброс портов, вложенные туннели, реверс-сокс-прокси и проброс авторизации

Интересный факт, которым меня мучали в институте, и он упоминается в статье: ip-адреса 127.0.0.1 и 127.1 идентичны и нет никакой ошибки. Вот такие пироги.

#skills

#interview

Вопросы для собеседования:

- Примеры последних интересных и скучных задач;
- Какие последние задачи запустили в продуктив;
- Как "выглядит" продуктив: какие инструменты/технологии используются, как это выглядит на практике;
- Есть ли мониторинг качества моделей и их переобучение?
- Есть ли code review или иные способы контроля качества проекта?
- Есть ли A/B тесты, как они реализованы, как используются результаты;
- Есть ли feedback от заказчиков по результатам проектов? Если есть, то в каком виде и как используется?
- Как приходят и ставятся/распределяются задачи?
- Какие обычные сроки у проектов? Есть ли adh-hoc и их доля? Есть ли исследовательские проекты?
- Какая текучка в отделе? Какая структура отдела?
- Какой стиль управления руководства/непосредственного начальника - жесткий контроль, свобода действия или что-то среднее.
- Были ли идеи от заказчиков, которые вы отказались делать? Что это было и почему?
- Какие конкретные задачи (1-2) буду выполнять, если выйду к вам?
- гибкий график? Возможность ходить на встречи/конференции? Переработки?
- Есть ли годовые цели и kpi? В каком виде?
- Планы по развитию отдела и людей?
- как ведется работа над проектами - в одиночку или команды по какому-то принципу?
- где хранятся данные, какое у них качество?
- как ведется разработка - инструменты, версионирование и так далее

#ml #petproject

(1) В этой статье можно отлично разобраться в большинстве оптимизаторов и их параметрах.

Статья с хорошими примерами проектирования сетей с помощью строительных блоков pytorch.