Вопрос: пытаюсь объяснить важность тестирования коллегам, но не получается — кто-то совсем против, а кто-то соглашается, но ничего не делает. Как быть?
Наверное, вы это спросили не для того, чтобы услышать очевидные ответы вроде почитать Кэмпа или сменить работу (хотя я бы так и сделал). Поэтому расскажу про сложный, и скорее всего неправильный путь.
Пишите тесты. Найдите проект, на котором вы можете это делать, и пишите. Со временем коллеги заметят, что ребята на вашем проекте раньше уходят домой, а бизнес охотнее приходит к вам с проблемами.
А может и не заметят. Если от коллеги плохо пахнет (простите) то есть вероятность что никакой личный пример не заставит его соблюдать правила гигиены.
Есть #вопрос про ИТ? Задавай в @fedor_borshev
Наверное, вы это спросили не для того, чтобы услышать очевидные ответы вроде почитать Кэмпа или сменить работу (хотя я бы так и сделал). Поэтому расскажу про сложный, и скорее всего неправильный путь.
Пишите тесты. Найдите проект, на котором вы можете это делать, и пишите. Со временем коллеги заметят, что ребята на вашем проекте раньше уходят домой, а бизнес охотнее приходит к вам с проблемами.
А может и не заметят. Если от коллеги плохо пахнет (простите) то есть вероятность что никакой личный пример не заставит его соблюдать правила гигиены.
Есть #вопрос про ИТ? Задавай в @fedor_borshev
В mtrl.ai мы ищем ведущего питониста. Вы будете работать над нашим бекофисом — это сложное бизнес-приложение, которое позволяет нам взаимодействовать с неорганизованными строительными рынками, как с настоящими складами.
Вам придется работать с асинхронным предсказанием наличия, системой принятия решений о выборе поставщика\менеджера, API для сайта, телефонии, маркетинга и еще кучей всего. Код без легаси, самые старые участки написаны в начале 2017 года.
Кол пишем на Django2/DRF и python 3.6. БД — Postgres и Redis, планирование задач на Celery/RabbitMQ, поиск на elasticsearch. Переиcпользуемый код опенсорсим или выносим в микросервисы. Пишем юнит- и интеграционные тесты на pytest, на самом большом проекте сейчас ~4500 тестов.
Работаем удаленно, недельными спринтами, таски ставим в issues гитхаба. Сейчас в команде, включая меня, трое питонистов — вы будете четвертым.
Если порекомендуете друга, который пройдет испытательный срок — получите 30к.
По всем вопросам — @fedor_borshev.
#работамечты
Вам придется работать с асинхронным предсказанием наличия, системой принятия решений о выборе поставщика\менеджера, API для сайта, телефонии, маркетинга и еще кучей всего. Код без легаси, самые старые участки написаны в начале 2017 года.
Кол пишем на Django2/DRF и python 3.6. БД — Postgres и Redis, планирование задач на Celery/RabbitMQ, поиск на elasticsearch. Переиcпользуемый код опенсорсим или выносим в микросервисы. Пишем юнит- и интеграционные тесты на pytest, на самом большом проекте сейчас ~4500 тестов.
Работаем удаленно, недельными спринтами, таски ставим в issues гитхаба. Сейчас в команде, включая меня, трое питонистов — вы будете четвертым.
Если порекомендуете друга, который пройдет испытательный срок — получите 30к.
По всем вопросам — @fedor_borshev.
#работамечты
Понятный код
Долго думал над тем, как можно было бы одним словом охарактеризовать хороший код. Недавно дошел: ПОНЯТНЫЙ.
Понятный код можно покрыть тестами; его можно переписать, если он не соответствует требованиям; можно выкинуть, потому что взаимодействие понятного кода с окружающей средой тоже понятно.
Может ли хороший код быть непонятным? Нет. Может ли понятный код быть плохим? Вряд ли.
Долго думал над тем, как можно было бы одним словом охарактеризовать хороший код. Недавно дошел: ПОНЯТНЫЙ.
Понятный код можно покрыть тестами; его можно переписать, если он не соответствует требованиям; можно выкинуть, потому что взаимодействие понятного кода с окружающей средой тоже понятно.
Может ли хороший код быть непонятным? Нет. Может ли понятный код быть плохим? Вряд ли.
Вопрос: Я программист, хочу стать тимлидом и руководить людьми, что почитать?
Тимлиду нужно прокачивать то же, что и менеджеру — общение с людьми, ответственность, планирование проектов и управление командой.
Прокачку софтскиллов стоит начать с классики вроде Стивена Кови и Джима Кэмпа. Обе книги — сложный и качественный селф-хелп, почти без воды.
Для хардскиллов рекомендую Голдрадта — Цель (все три части) и Критическую цепь.
Если прочитали основы, поизучайте список книг в моем блоге.
#вопрос
Тимлиду нужно прокачивать то же, что и менеджеру — общение с людьми, ответственность, планирование проектов и управление командой.
Прокачку софтскиллов стоит начать с классики вроде Стивена Кови и Джима Кэмпа. Обе книги — сложный и качественный селф-хелп, почти без воды.
Для хардскиллов рекомендую Голдрадта — Цель (все три части) и Критическую цепь.
Если прочитали основы, поизучайте список книг в моем блоге.
#вопрос
Первый закон Паркинсона
В 50-х годах прошлого века умный дядька по фамилии Паркинсон, историк по профессии, вывел немного шутливый, но верный и правдивый закон — работа занимает все отведенное на нее время.
Если внучка может писать бабушке письмо три дня, то она будет писать его три дня.
Если у вас в спринте три мелкие задачи, то вы будете делать их две недели.
Наоборот тоже работает — если до конца недели нужно сделать 20 задач (и вам отрежут руку, если не сделаете), то вы найдете способ все успеть — пофлексите, упростите код, напишете говно, наконец.
А если внучка торопится в кино с подружками, то бабушке хватит и открыточки.
В 50-х годах прошлого века умный дядька по фамилии Паркинсон, историк по профессии, вывел немного шутливый, но верный и правдивый закон — работа занимает все отведенное на нее время.
Если внучка может писать бабушке письмо три дня, то она будет писать его три дня.
Если у вас в спринте три мелкие задачи, то вы будете делать их две недели.
Наоборот тоже работает — если до конца недели нужно сделать 20 задач (и вам отрежут руку, если не сделаете), то вы найдете способ все успеть — пофлексите, упростите код, напишете говно, наконец.
А если внучка торопится в кино с подружками, то бабушке хватит и открыточки.
Сервисы: Periscope
Люблю SQL-дешборды — это классный инструмент, который делает данные в компании полностью прозрачными почти для любого представителя бизнеса. Чтобы собрать отчет, публичный монитор или даже мини-интерфейс для работы, не нужно ходить к программистам — достаточно потратить пару дней изучение SQL.
У нас в mtrl.ai уже давно внедрен Periscope — помимо привычной функциональности, вроде построения графиков и сборки красивых дешбордов, он сильно упрощает построение запросов — там есть упрощенные джоины (
Periscope — дорогой инструмент (цены начинаются от 500$ в месяц), наверное есть и подешевле. Но простота настройки и фичи, которые позволяют аналитикам не ковыряться в дебрях SQL, кажется стоят еще дороже.
Люблю SQL-дешборды — это классный инструмент, который делает данные в компании полностью прозрачными почти для любого представителя бизнеса. Чтобы собрать отчет, публичный монитор или даже мини-интерфейс для работы, не нужно ходить к программистам — достаточно потратить пару дней изучение SQL.
У нас в mtrl.ai уже давно внедрен Periscope — помимо привычной функциональности, вроде построения графиков и сборки красивых дешбордов, он сильно упрощает построение запросов — там есть упрощенные джоины (
SELECT order.id, order.date, customer.name from [order+customer]), джоины из разных БД, кастомные вьюхи и еще много всего, упрощающего жизнь и аналитикам и программистам.Periscope — дорогой инструмент (цены начинаются от 500$ в месяц), наверное есть и подешевле. Но простота настройки и фичи, которые позволяют аналитикам не ковыряться в дебрях SQL, кажется стоят еще дороже.
Процесс vs результат
Умение отличать процесс от результата — больная тема для всех программистов. Наш мозг просто обязан думать про процесс — мы инженеры с огромной предметной областью, и мышление, не нацеленное на процесс (постоянное познание и улучшение), в нашей профессии скорее всего не выживет.
Вам знакома ситуация, когда близко дедлайн, в коде в общем-то нужно поставить один
Программист, который хочет вырасти дальше начинающего мидла, должен уметь отличать процесс от результата на уровне рефлексов. К сожалению, никакие книги, курсы и семинары не помогут — это телесный навык, который достигается только тренировкой (я не шучу, погуглите быстрое мышление).
Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго проеба вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для результата?»; «Что из того, что я запланировал можно НЕ делать?».
Если проектов нет на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Хорошая личная задача — «завести блог». Напишете себе бекенд на гошечке? Возьмете модный генератор статичных сайтов? Или все-таки медиум?
Умение отличать процесс от результата — больная тема для всех программистов. Наш мозг просто обязан думать про процесс — мы инженеры с огромной предметной областью, и мышление, не нацеленное на процесс (постоянное познание и улучшение), в нашей профессии скорее всего не выживет.
Вам знакома ситуация, когда близко дедлайн, в коде в общем-то нужно поставить один
if, и вы принимаете тяжелое решение — переписать несколько методов с выходом в надсистему, вместо того, чтобы увеличивать цикломатическую сложность. Это и есть разница — if это результат, переделать методы — процесс.Программист, который хочет вырасти дальше начинающего мидла, должен уметь отличать процесс от результата на уровне рефлексов. К сожалению, никакие книги, курсы и семинары не помогут — это телесный навык, который достигается только тренировкой (я не шучу, погуглите быстрое мышление).
Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго проеба вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для результата?»; «Что из того, что я запланировал можно НЕ делать?».
Если проектов нет на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Хорошая личная задача — «завести блог». Напишете себе бекенд на гошечке? Возьмете модный генератор статичных сайтов? Или все-таки медиум?
Слово «Аджайл» заездили давно и наглухо. Даже Сбербанк уже работает по аджайлу. Тем не менее, я до сих пор встречаю ребят, которые не понимают, что такое «гибкость» в процессе разработки ПО.
Если вы тоже знаете таких ребят — прочитайте статью Натальи Бабаевой Как объяснить аджайл дедушке: сможете быть очень убедительными, да и свое понимание, наверняка, улучшите.
Если вы тоже знаете таких ребят — прочитайте статью Натальи Бабаевой Как объяснить аджайл дедушке: сможете быть очень убедительными, да и свое понимание, наверняка, улучшите.
Medium
Как объяснить дедушке эджайл и скрам за 5 минут без картинок. И самому лучше понять
Пост об интуитивности эджайла
Ребята из Zeit.co (они же now.sh) выкатили классную фичу — деплой докер-образа в одну команду.
Поясню, как это круто — можно моментально, ничего не настраивая, выпустить в продакшн любой код на любом языке. Конечно есть ограничения — сложную инфраструктуру с БД, кешем и очередями таким образом не построить. Но для хипстерского serverless это не так уж и важно — ведь можно таким же образом задеплоить хоть десяток образов с чем угодно.
Плюшки вроде автоотката в случае фейла, скейлинга и полного отсутствия серверов, жестких дисков, дистрибутивов убунты и apt-get прилагаются.
Поясню, как это круто — можно моментально, ничего не настраивая, выпустить в продакшн любой код на любом языке. Конечно есть ограничения — сложную инфраструктуру с БД, кешем и очередями таким образом не построить. Но для хипстерского serverless это не так уж и важно — ведь можно таким же образом задеплоить хоть десяток образов с чем угодно.
Плюшки вроде автоотката в случае фейла, скейлинга и полного отсутствия серверов, жестких дисков, дистрибутивов убунты и apt-get прилагаются.
Сервисы: retool
В прошлый понедельник я рассказывал про Перископ — инструмент, который позволяет людям, не разбирающимся в коде, строить клевые отчеты и графики.
Ребята из retool пошли еще дальше — они позволяют прямо мышкой собирать кастомные интерфейсы, которые будут ходить в API или напрямую в БД.
Доступ на запись к БД — штука сомнительная: пользователь должен неплохо разбираться в кодовой базе, чтобы не обрушить все приложение парой инсертов, консистентных с точки зрения БД, но бессмысленных в контексте приложения (да, такое бывает у всех).
А вот доступ к API — это круто. В комплекте с работающей документацией (вроде apiary + dredd), это позволит не привлекая программистов на коленке собирать новые рабочие места.
Теперь, чтобы проверить гипотезу об улучшении операционного процесса, достаточно просто накликать мышкой нужный интерфейс, и проверить, как люди себя в нем поведут.
В прошлый понедельник я рассказывал про Перископ — инструмент, который позволяет людям, не разбирающимся в коде, строить клевые отчеты и графики.
Ребята из retool пошли еще дальше — они позволяют прямо мышкой собирать кастомные интерфейсы, которые будут ходить в API или напрямую в БД.
Доступ на запись к БД — штука сомнительная: пользователь должен неплохо разбираться в кодовой базе, чтобы не обрушить все приложение парой инсертов, консистентных с точки зрения БД, но бессмысленных в контексте приложения (да, такое бывает у всех).
А вот доступ к API — это круто. В комплекте с работающей документацией (вроде apiary + dredd), это позволит не привлекая программистов на коленке собирать новые рабочие места.
Теперь, чтобы проверить гипотезу об улучшении операционного процесса, достаточно просто накликать мышкой нужный интерфейс, и проверить, как люди себя в нем поведут.
Приходи с решением, а не с проблемой
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.
Post mortem
Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.
Обычно в таких документах на более или менее понятном языке объясняют причины произошедшей аварии и рассказывают про выводы и изменения в командных процессах.
Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.
Помимо интересного чтива, подробные и интересные отчеты об ошибках служат важной задаче — оздоровлению культуры в команде. Самое главное, что устраняют внутрикомандные post mortem — боязнь ошибиться.
Это прям наша национальная черта — еще со школы всех приучают, что ошибаться — плохо. Пофиг, что ты ошибся потому, что делаешь сложную работу, жизнеспособность которой зачастую лежит вне круга твоего влияния: в мозгу многих ребят застряла формула «ошибка = косяк, штраф, публичный ататат и профессиональная смерть». А что серьезного может сделать программист, который боится написать даже сложную дата-миграцию?
В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).
Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.
Обычно в таких документах на более или менее понятном языке объясняют причины произошедшей аварии и рассказывают про выводы и изменения в командных процессах.
Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.
Помимо интересного чтива, подробные и интересные отчеты об ошибках служат важной задаче — оздоровлению культуры в команде. Самое главное, что устраняют внутрикомандные post mortem — боязнь ошибиться.
Это прям наша национальная черта — еще со школы всех приучают, что ошибаться — плохо. Пофиг, что ты ошибся потому, что делаешь сложную работу, жизнеспособность которой зачастую лежит вне круга твоего влияния: в мозгу многих ребят застряла формула «ошибка = косяк, штраф, публичный ататат и профессиональная смерть». А что серьезного может сделать программист, который боится написать даже сложную дата-миграцию?
В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).
В эту субботу закрывается старая версия CircleCI.com
Вторая версия Серкла — это не эволюция, а революция: вместо того, чтобы фокусироваться на создании универсальной среды сборки для вашего кода, они создали среду для сборки среды — вы можете просто развернуть все, что вам привычно из внутренних докер-образов.
Много времени вложили и в ускорение сборки — на самом медленном нашем проекте мы снизили время сборки в 8 раз, просто перейдя на вторую версию.
Наверное, что-то похожее есть у гитлаба, но все три раза, когда я пробовал их облачную инфраструктуру, у них были какие-то жуткие тормоза в выделении контейнеров, что замедляло CI до такого уровня, что он превращался из помощника в процессе разработки в тупой автоматизатор деплоя.
Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.
Вторая версия Серкла — это не эволюция, а революция: вместо того, чтобы фокусироваться на создании универсальной среды сборки для вашего кода, они создали среду для сборки среды — вы можете просто развернуть все, что вам привычно из внутренних докер-образов.
Много времени вложили и в ускорение сборки — на самом медленном нашем проекте мы снизили время сборки в 8 раз, просто перейдя на вторую версию.
Наверное, что-то похожее есть у гитлаба, но все три раза, когда я пробовал их облачную инфраструктуру, у них были какие-то жуткие тормоза в выделении контейнеров, что замедляло CI до такого уровня, что он превращался из помощника в процессе разработки в тупой автоматизатор деплоя.
Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.
Сервисы: dependabot
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Самый первый дедлайн
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Микроменеджмент ←———→ доверие
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Работа мечты: Сделать домашнюю работу
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
Вопрос: куда пойти работать начинающему веб-программисту: в студию или продуктовую команду?
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
Самый частый ответ на вопрос «почему вы не пишете тестов» — «ну, нам не дают времени, чтобы делать все хорошо».
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Работа мечты: Резюме
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты