Full focus TDD
Не являюсь большим сторонником практик TDD. Скорее всего, дело в том, что я не работал в тех местах, где это было серьезной частью культуры, не видел как это может работать, и/или не находил мотивации перестроить мышление соответствующим образом.
Как правило, по TDD я делаю совсем простые вещи, вроде функций преобразований, валидаций, и так далее, когда результат очень детерминирован и легко кодируем в тестах.
Давно заметил, что наибольшая продуктивность в разработке у меня больше всего связана с понятностью задачи. Всегда я делаю в первую очередь не самые сложные или самые приоритетные задания, а самые простые и понятные. Даже если они объемные.
Теперь мне кажется, что главная польза от TDD не в том, что у вас код покрыт тестами еще до того, как он написан, а в том, что заранее составленный набор условий фокусирует разработчика на решении конкретной маленькой задачи. Вместо прокрастинации и раздумий о том, с чего начать, какие структуры данных подготовить и так далее, вы предварительно очень сильно уточняете требования буквально до результата возврата функции. Это здорово помогает не отвлекаться и сосредоточиться на главном. Декомпозиция происходит не во время решения задачи, а до неё.
Мамонта нужно есть по частям, и если не сформировать в себе привычку это делать на постоянной основе, то есть большой риск так и не приступить к поеданию, или откусить по кусочку тут и там.
По-большому счёту, вместо тестов можно использовать чеклист на бумажке—результат, в смысле фокусировки на маленьких кусочках решения, будет примерно одним и тем же. Думаю, что практика TDD в основном про это, а не про есть у вас тесты или нет, хотя не могу припомнить, чтобы кто-то продавал людям или мне именно это преимущество. В основном речь шла про корректность, покрытие кода и тд и тд, а про декомпозицию и фокус ни слова.
Не являюсь большим сторонником практик TDD. Скорее всего, дело в том, что я не работал в тех местах, где это было серьезной частью культуры, не видел как это может работать, и/или не находил мотивации перестроить мышление соответствующим образом.
Как правило, по TDD я делаю совсем простые вещи, вроде функций преобразований, валидаций, и так далее, когда результат очень детерминирован и легко кодируем в тестах.
Давно заметил, что наибольшая продуктивность в разработке у меня больше всего связана с понятностью задачи. Всегда я делаю в первую очередь не самые сложные или самые приоритетные задания, а самые простые и понятные. Даже если они объемные.
Теперь мне кажется, что главная польза от TDD не в том, что у вас код покрыт тестами еще до того, как он написан, а в том, что заранее составленный набор условий фокусирует разработчика на решении конкретной маленькой задачи. Вместо прокрастинации и раздумий о том, с чего начать, какие структуры данных подготовить и так далее, вы предварительно очень сильно уточняете требования буквально до результата возврата функции. Это здорово помогает не отвлекаться и сосредоточиться на главном. Декомпозиция происходит не во время решения задачи, а до неё.
Мамонта нужно есть по частям, и если не сформировать в себе привычку это делать на постоянной основе, то есть большой риск так и не приступить к поеданию, или откусить по кусочку тут и там.
По-большому счёту, вместо тестов можно использовать чеклист на бумажке—результат, в смысле фокусировки на маленьких кусочках решения, будет примерно одним и тем же. Думаю, что практика TDD в основном про это, а не про есть у вас тесты или нет, хотя не могу припомнить, чтобы кто-то продавал людям или мне именно это преимущество. В основном речь шла про корректность, покрытие кода и тд и тд, а про декомпозицию и фокус ни слова.
Робота по таймеру рік по тому
Трохи менше ніж рік тому я написав повний фрустрації пост про роботу по таймеру. Пройшло багато часу і спішу поділитися апдейтами по цій темі.
Виявилося, що справа у звичці. Весь цей рік я справно трекав все, що витрачав на роботу, і з часом це просто стало звичкою. Сів за комп'ютер — натиснув на кнопку. Встав випити чаю поки біжить CI/CD — ок. Треба сидіти й моніторити як біжать тести або щось інше — ок. Сів обідати або вийшов у справах — зупинив трекінг. Більше мене це не непокоїть, працюю як і раніше, але не думаю про час. Ніяких проблем з таймерами — хочете працювати по T&M? Без питань!
Конфліктів з клієнтами з приводу того, чому багато (або чому мало) часу було витрачено на ту чи іншу задачу, за весь цей час у мене не було. Мені здається що якщо ти добре працюєш, а з того боку адекватні люди, то не буде жодних проблем.
Я трекаю навіть той час, який витрачаю на фіксед-прайс задачі, або на неоплачувані активності (наприклад, цього року я витратив 86 годин на написання постів), щоб ретроспективно оцінювати складність проєктів, точність оцінки та продуктивність у грошовому еквіваленті.
Для трекінгу користуюсь безплатною версією Toggl. Окремо навіть написав мікропродукт для генерації інвойсів звідти — бо шкода віддавати 5$ за підписку.
P.S.: це все про роботу на ручному таймері, а не по шпигунському монітору активності як на апворку.
#продуктивність
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Трохи менше ніж рік тому я написав повний фрустрації пост про роботу по таймеру. Пройшло багато часу і спішу поділитися апдейтами по цій темі.
Виявилося, що справа у звичці. Весь цей рік я справно трекав все, що витрачав на роботу, і з часом це просто стало звичкою. Сів за комп'ютер — натиснув на кнопку. Встав випити чаю поки біжить CI/CD — ок. Треба сидіти й моніторити як біжать тести або щось інше — ок. Сів обідати або вийшов у справах — зупинив трекінг. Більше мене це не непокоїть, працюю як і раніше, але не думаю про час. Ніяких проблем з таймерами — хочете працювати по T&M? Без питань!
Конфліктів з клієнтами з приводу того, чому багато (або чому мало) часу було витрачено на ту чи іншу задачу, за весь цей час у мене не було. Мені здається що якщо ти добре працюєш, а з того боку адекватні люди, то не буде жодних проблем.
Я трекаю навіть той час, який витрачаю на фіксед-прайс задачі, або на неоплачувані активності (наприклад, цього року я витратив 86 годин на написання постів), щоб ретроспективно оцінювати складність проєктів, точність оцінки та продуктивність у грошовому еквіваленті.
Для трекінгу користуюсь безплатною версією Toggl. Окремо навіть написав мікропродукт для генерації інвойсів звідти — бо шкода віддавати 5$ за підписку.
P.S.: це все про роботу на ручному таймері, а не по шпигунському монітору активності як на апворку.
#продуктивність
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
Разговоры о работе
Стараюсь не говорить о работе вне работы. С коллегами на обеде, в отпуске, на посиделках в баре. Хотя я люблю своё дело, в мире есть еще миллион других интересных вещей, которые можно обсудить.
Постоянное развитие технологий это круто, но у меня есть ощущение, что чем дальше в лес и больше опыта, тем меньше нового под солнцем и тем меньше желания перетирать очередные библиотеки и инструменты.
Вот о чем бы я говорил, так это о философии/культуре разработки. Но желающих пообщаться на эту тему чуть менее чем никого, приходится обсуждать зарплаты и кто куда пошёл работать.
Встречал мнение, что разработчик который не интересуется работой вне работы вроде как и не разработчик вовсе, а так, мимокрок в индустрии ради денег.
Не соглашусь с этим. Тот, кто грамотно распределяет своё время, учится на работе, а не после неё. Интерес к другим сферам жизни придает сил копать в основном направлении, расширяет кругозор, позволяет взглянуть на проблемы с других сторон, наконец позволяет применить знания и умения в чем-то другом.
Для профессионального общения есть профессиональные ивенты—митапы, конференции. Вот туда надо ходить, чтобы концентрированно получать знания. А не спорить с коллегой на кухне о react vs vue.
Стараюсь не говорить о работе вне работы. С коллегами на обеде, в отпуске, на посиделках в баре. Хотя я люблю своё дело, в мире есть еще миллион других интересных вещей, которые можно обсудить.
Постоянное развитие технологий это круто, но у меня есть ощущение, что чем дальше в лес и больше опыта, тем меньше нового под солнцем и тем меньше желания перетирать очередные библиотеки и инструменты.
Вот о чем бы я говорил, так это о философии/культуре разработки. Но желающих пообщаться на эту тему чуть менее чем никого, приходится обсуждать зарплаты и кто куда пошёл работать.
Встречал мнение, что разработчик который не интересуется работой вне работы вроде как и не разработчик вовсе, а так, мимокрок в индустрии ради денег.
Не соглашусь с этим. Тот, кто грамотно распределяет своё время, учится на работе, а не после неё. Интерес к другим сферам жизни придает сил копать в основном направлении, расширяет кругозор, позволяет взглянуть на проблемы с других сторон, наконец позволяет применить знания и умения в чем-то другом.
Для профессионального общения есть профессиональные ивенты—митапы, конференции. Вот туда надо ходить, чтобы концентрированно получать знания. А не спорить с коллегой на кухне о react vs vue.
Мудрые советы от опытных людей
Когда я вижу, что какой-то (на его словах) шарящий человек предлагает окружающим бесплатно с ним пообщаться, то стараюсь немедленно хвататься за возможность.
В том году удалось так поговорить с местным ML-гуру и устроить целый митап со специалистом по ножевому бою. Получилось очень интересно. Вчера предварительно договорился с еще одной очень интересной личностью, если все пройдет ок, то напишу репорт.
Кажется, люди недооценивают ценность общения с экспертами. Многие наверное думают "что мне это даст? просто потрепаться? да я лучше пойду поработаю или отдохну. у меня и так все ок". Может ничего и не даст. А может и даст. Если есть хоть малейшая вероятность за мелкий прайс улучшить своё положение—почему бы этим не воспользоваться?
Я бы и сам раздавал советы (лучше за деньги конечно), но кажется что пока еще не дорос до этой категории. Самый топ—это стать как чувак из книжки "Цель", который за процент от прибыли поучал протагониста премудростям управления заводом. Вот это хороший вариант, так бы я работал.
Короче говоря, видите что кто-то предлагает свою экспертизу—букайте время. Хуже точно не станет.
Когда я вижу, что какой-то (на его словах) шарящий человек предлагает окружающим бесплатно с ним пообщаться, то стараюсь немедленно хвататься за возможность.
В том году удалось так поговорить с местным ML-гуру и устроить целый митап со специалистом по ножевому бою. Получилось очень интересно. Вчера предварительно договорился с еще одной очень интересной личностью, если все пройдет ок, то напишу репорт.
Кажется, люди недооценивают ценность общения с экспертами. Многие наверное думают "что мне это даст? просто потрепаться? да я лучше пойду поработаю или отдохну. у меня и так все ок". Может ничего и не даст. А может и даст. Если есть хоть малейшая вероятность за мелкий прайс улучшить своё положение—почему бы этим не воспользоваться?
Я бы и сам раздавал советы (лучше за деньги конечно), но кажется что пока еще не дорос до этой категории. Самый топ—это стать как чувак из книжки "Цель", который за процент от прибыли поучал протагониста премудростям управления заводом. Вот это хороший вариант, так бы я работал.
Короче говоря, видите что кто-то предлагает свою экспертизу—букайте время. Хуже точно не станет.
Печеньки в офисе
Встречаю мнение, что хороший работодатель должен предоставлять полный пакет бонусов в дополнение к заработной плате, как-то: страховку для вас и для семьи, абонемент в спортзал, стол с теннисом и комнату с плейстейшоном, печеньки, чай кофе и баристу, массаж, выездные корпоративы 4 раза в год и прочие приятности.
Некоторые люди даже склонны делать выбор в ту или иную сторону основываясь на наличии тех или иных плюшек.
Мне эта позиция совершенно противна. По-большому счету, все эти штуки являются ничем иным как теми же самыми деньгами, только в другой форме. Но так как мы не можем просто сказать "у нас нет дмс, зато зп на 300 баксов выше чем у конкурентов", то начинаются все эти ухищрения.
Оказывая всестороннюю работу вокруг сотрудника, компания становится "родителем", а люди, которые там работают—"детьми". Капризный ребёнок требует все больше и больше игрушек и внимания, забывая зачем он вообще сюда пришел. Возможно, реакция компаний как раз и обусловлена инфантилизацией поголовья работников, которые хотят оставаться детьми. Мне не нравится быть ребенком, за которого решают, мне нравится получать деньги и самому направлять их куда надо. У меня есть свои дела вместо игр с коллегами, я сам знаю, мне нужно в зал, бассейн или на массаж или не нужно, у меня подобранная под меня страховка.
Компания наверное должна обеспечивать людей рабочими местами и техникой. Но мне кажется, что профессионал должен сам обустраивать личный офис и иметь свою технику. Свой стол, стул, десктоп, лептоп, гарнитуры и так далее. Выбранное под себя и качественное. У квалифицированных строителей, например, всегда свой, топовый инструмент.
Я за бизнес-подход. С меня—сделанная работа, с вас—оплата. Все что сверху—лишнее и отвлекает.
Еще мне кажется, что если бы у людям давали выбор—деньги или вышеозначенные бонусы, то большинство выбрали бы деньги.
А печеньки и плейстейшон оставим детям.
p.s.: наверное единственное преимущество, которое может иметь компания в заказе вещей типа страховки—это скидка за объем.
p.p.s.: если уж нужно ходить в офис, то чай-кофе там должны быть, так же как и туалетная бумага и мыло, это гигеничские потребности.
Встречаю мнение, что хороший работодатель должен предоставлять полный пакет бонусов в дополнение к заработной плате, как-то: страховку для вас и для семьи, абонемент в спортзал, стол с теннисом и комнату с плейстейшоном, печеньки, чай кофе и баристу, массаж, выездные корпоративы 4 раза в год и прочие приятности.
Некоторые люди даже склонны делать выбор в ту или иную сторону основываясь на наличии тех или иных плюшек.
Мне эта позиция совершенно противна. По-большому счету, все эти штуки являются ничем иным как теми же самыми деньгами, только в другой форме. Но так как мы не можем просто сказать "у нас нет дмс, зато зп на 300 баксов выше чем у конкурентов", то начинаются все эти ухищрения.
Оказывая всестороннюю работу вокруг сотрудника, компания становится "родителем", а люди, которые там работают—"детьми". Капризный ребёнок требует все больше и больше игрушек и внимания, забывая зачем он вообще сюда пришел. Возможно, реакция компаний как раз и обусловлена инфантилизацией поголовья работников, которые хотят оставаться детьми. Мне не нравится быть ребенком, за которого решают, мне нравится получать деньги и самому направлять их куда надо. У меня есть свои дела вместо игр с коллегами, я сам знаю, мне нужно в зал, бассейн или на массаж или не нужно, у меня подобранная под меня страховка.
Компания наверное должна обеспечивать людей рабочими местами и техникой. Но мне кажется, что профессионал должен сам обустраивать личный офис и иметь свою технику. Свой стол, стул, десктоп, лептоп, гарнитуры и так далее. Выбранное под себя и качественное. У квалифицированных строителей, например, всегда свой, топовый инструмент.
Я за бизнес-подход. С меня—сделанная работа, с вас—оплата. Все что сверху—лишнее и отвлекает.
Еще мне кажется, что если бы у людям давали выбор—деньги или вышеозначенные бонусы, то большинство выбрали бы деньги.
А печеньки и плейстейшон оставим детям.
p.s.: наверное единственное преимущество, которое может иметь компания в заказе вещей типа страховки—это скидка за объем.
p.p.s.: если уж нужно ходить в офис, то чай-кофе там должны быть, так же как и туалетная бумага и мыло, это гигеничские потребности.
Дверью по голове
Много лет назад произошла со мной забавная история. У меня в отделе работал мужичок, старше меня лет на 10, на должности сеньер девелопера. Но была незадача—тянул он хуже студентов с полугодом опыта. Так получилось, что мужичка нанял мой экс-босс, потом босс свинтил в штаты, я пошел на повышение и соответственно получил в наследство всё существующее хозяйство.
После регулярного получения негативных отзывов с проектов, я решил действовать. План был уволить человека. Но так как увольнять на мороз просто так не хотелось, решено было дать выбор—или уменьшаем зп или досвидания.
Я позвал его в переговорку, но так как и он и я чувствовали некоторую нервозность, то почему-то начали идти быстрее обычного. На середине дороги перед нами открываются двери одного из кабинетов и парень на полной скорости врезается головой в угол двери. Кровь-кишки-зовем скорую чтобы зашивать бровь. Травма на рабочем месте. Меня тогда почему-то ужасно пробило на ржач, хотя ничего смешного в раскладах не было.
Не помню, это было до собственно оглашения ему неприятных новостей, или после, но в итоге он принял решение уволиться. Потом устроился сеньером в другую контору, а еще через пару лет мы с парнями из отдела смотрели на его фотки из Америки на фоне то ли камаро то ли мустанга, короче какой-то машины. Пацан пришел к успеху, переехал и устроился разработчиком, сейчас архитектор.
Я думаю, что тот удар дверью пошел ему однозначно на пользу. Не будь его, чел бы еще многие года сидел без повышений и перспектив.
p.s.: кстати, вместе с ним мне перепал еще один парень, тоже олдовый джуниор. Ему тоже был предъявлен ультиматум, чел собрал манатки и релоцировался в Польшу. Сейчас сеньер а раньше едва мог простую задачу сделать.
Много лет назад произошла со мной забавная история. У меня в отделе работал мужичок, старше меня лет на 10, на должности сеньер девелопера. Но была незадача—тянул он хуже студентов с полугодом опыта. Так получилось, что мужичка нанял мой экс-босс, потом босс свинтил в штаты, я пошел на повышение и соответственно получил в наследство всё существующее хозяйство.
После регулярного получения негативных отзывов с проектов, я решил действовать. План был уволить человека. Но так как увольнять на мороз просто так не хотелось, решено было дать выбор—или уменьшаем зп или досвидания.
Я позвал его в переговорку, но так как и он и я чувствовали некоторую нервозность, то почему-то начали идти быстрее обычного. На середине дороги перед нами открываются двери одного из кабинетов и парень на полной скорости врезается головой в угол двери. Кровь-кишки-зовем скорую чтобы зашивать бровь. Травма на рабочем месте. Меня тогда почему-то ужасно пробило на ржач, хотя ничего смешного в раскладах не было.
Не помню, это было до собственно оглашения ему неприятных новостей, или после, но в итоге он принял решение уволиться. Потом устроился сеньером в другую контору, а еще через пару лет мы с парнями из отдела смотрели на его фотки из Америки на фоне то ли камаро то ли мустанга, короче какой-то машины. Пацан пришел к успеху, переехал и устроился разработчиком, сейчас архитектор.
Я думаю, что тот удар дверью пошел ему однозначно на пользу. Не будь его, чел бы еще многие года сидел без повышений и перспектив.
p.s.: кстати, вместе с ним мне перепал еще один парень, тоже олдовый джуниор. Ему тоже был предъявлен ультиматум, чел собрал манатки и релоцировался в Польшу. Сейчас сеньер а раньше едва мог простую задачу сделать.
Не смог замотивировать
Был у меня в отделе еще один кадр. Студиозус из КПИ, умный парень. Однако работать у него получалось не очень. Всё началось еще во время найма когда наш герой спросил "когда я могу рассчитывать на повышение (зарплаты)". В целом это очень хороший вопрос, я уже писал о нем ранее (https://xn--r1a.website/full_of_hatred/65). Для студентов у нас была простая схема—каждые 3-4 месяца +X%, если хорошо перформит. Если плохо—реже. Внятных критериев "перформит" конечно же (у меня) не было, всё определялось на глаз. Рассказал схему товарищу, пошли работать.
И тут оказалось что парень совсем не спешит собственно делать задачи, апатичен и вообще делает вид, как будто ему тут все должны. Спустя несколько разговоров выяснилось что его расстраивает стартовая маленькая зарплата, большое количество внутренней специфики (это правда), скучные таски (а ты как хотел), отсутствие печенек на кухне и так далее. Пока другие ребята, которые были наняты одновременно с ним уже стали самостоятельно (и очень даже неплохо) копать, наш герой продолжал спрашивать когда уже ему подымут зарплату. В коллективе он тоже не особо прижился, ни с кем не дружил, держался обособленно.
Я, методом прямого сравнения с его коллегами, решил, что наверное нам не по пути, и спустил дело на тормозах. Через короткий промежуток времени парень обрадовал меня оффером и был отпущен на все четыре стороны.
Через год ко мне постучалась рекрутёр из конторы, где он работал. Хотела переманить. Я отказался и упомянул что у них уже работает мой экс-джун. Рекрутер в ответ сообщила что парень—просто находка, очень грамотный, хорошо работает и вообще спасибо.
Значит я не смог его замотивировать. Или в другом месте всё было точно так же, просто до парня дошло, что есть рынок, на котором ты до определённого этапа должен доказывать, что можешь годно работать и только потом чиллить, перебирая спортзалами и плейстейшонами, и он начал перформить. А может действительно человека кроме денег ничего не интересовало.
Спустя годы пацан пришёл к успеху—вначале релоцировался в немецкий амазон, потом в американский AWS, и вот уже пару месяцев как работает в американском же гугле. Целеустремлённый молодой человек. Думаю у него всё хорошо.
Интересно, как бы всё сложилось, если бы я проявил безумные умения и он продолжил работать у меня (как множество других ребят работают там до сих пор)?
Был у меня в отделе еще один кадр. Студиозус из КПИ, умный парень. Однако работать у него получалось не очень. Всё началось еще во время найма когда наш герой спросил "когда я могу рассчитывать на повышение (зарплаты)". В целом это очень хороший вопрос, я уже писал о нем ранее (https://xn--r1a.website/full_of_hatred/65). Для студентов у нас была простая схема—каждые 3-4 месяца +X%, если хорошо перформит. Если плохо—реже. Внятных критериев "перформит" конечно же (у меня) не было, всё определялось на глаз. Рассказал схему товарищу, пошли работать.
И тут оказалось что парень совсем не спешит собственно делать задачи, апатичен и вообще делает вид, как будто ему тут все должны. Спустя несколько разговоров выяснилось что его расстраивает стартовая маленькая зарплата, большое количество внутренней специфики (это правда), скучные таски (а ты как хотел), отсутствие печенек на кухне и так далее. Пока другие ребята, которые были наняты одновременно с ним уже стали самостоятельно (и очень даже неплохо) копать, наш герой продолжал спрашивать когда уже ему подымут зарплату. В коллективе он тоже не особо прижился, ни с кем не дружил, держался обособленно.
Я, методом прямого сравнения с его коллегами, решил, что наверное нам не по пути, и спустил дело на тормозах. Через короткий промежуток времени парень обрадовал меня оффером и был отпущен на все четыре стороны.
Через год ко мне постучалась рекрутёр из конторы, где он работал. Хотела переманить. Я отказался и упомянул что у них уже работает мой экс-джун. Рекрутер в ответ сообщила что парень—просто находка, очень грамотный, хорошо работает и вообще спасибо.
Значит я не смог его замотивировать. Или в другом месте всё было точно так же, просто до парня дошло, что есть рынок, на котором ты до определённого этапа должен доказывать, что можешь годно работать и только потом чиллить, перебирая спортзалами и плейстейшонами, и он начал перформить. А может действительно человека кроме денег ничего не интересовало.
Спустя годы пацан пришёл к успеху—вначале релоцировался в немецкий амазон, потом в американский AWS, и вот уже пару месяцев как работает в американском же гугле. Целеустремлённый молодой человек. Думаю у него всё хорошо.
Интересно, как бы всё сложилось, если бы я проявил безумные умения и он продолжил работать у меня (как множество других ребят работают там до сих пор)?
Доменные эксперты
Мой первый нормальный босс говорил мне: "Вова, ты не просто программист, ты программист-эксперт в своём домене, а это очень важно и ценится гораздо больше чем просто умение писать код".
Мотивировал меня, потому что за "доменной экспертизой" скрывались мало кому на рынке нужные знания узкоспециализированных продуктов и инструментов. Но я верил и мнил себя экспертом и даже бравировал этим перед рекрутёрами которые искали "спринг девелопера".
Иллюзии эти развеялись после того, как в компании открылись новые офисы разработки и стали массово набирать новых людей. И внезапно оказалось что мои знания не такие уж ценные и уникальные. Потому что свеженанятые сеньеры помидоры, после вводных тренингов и короткого периода изучения проекта начинали копать не хуже чем старички, а иногда даже и лучше, потому что обладали большим опытом в других областях и имели шире кругозор.
Отмечу, что это касается именно доменной области а не знаний о конкретном продукте или фреймворке. Логично, что я лучше понимал, как использовать внутреннюю кухню, но это специфика любого мало-мальски большого проекта.
Поэтому считаю, что доменные знания программисту особо не нужны. Адекватный специалист довольно быстро изучит новую область. Для углублённых знаний есть бизнес-аналитики и прочие SME, а разработчику нужно знать только то, что нужно для работы.
Конечно есть характерные области—бетттинг, финтех, медицины, где знание специфики вероятно поможет сильно быстрее въехать в дело и наверное есть прям совсем узкие вещи вроде разработки компиляторов или плагинов под конкретные продукты. Но я на практике видел, что это не такое уж и большое преимущество. Кроме того, компании же как-то набирают новых людей, и ничего, те вполне себе работают.
Поэтому я больше не придаю большого значения своим знаниям о том или о сём. Надо будет—сяду и разберусь.
Мой первый нормальный босс говорил мне: "Вова, ты не просто программист, ты программист-эксперт в своём домене, а это очень важно и ценится гораздо больше чем просто умение писать код".
Мотивировал меня, потому что за "доменной экспертизой" скрывались мало кому на рынке нужные знания узкоспециализированных продуктов и инструментов. Но я верил и мнил себя экспертом и даже бравировал этим перед рекрутёрами которые искали "спринг девелопера".
Иллюзии эти развеялись после того, как в компании открылись новые офисы разработки и стали массово набирать новых людей. И внезапно оказалось что мои знания не такие уж ценные и уникальные. Потому что свеженанятые сеньеры помидоры, после вводных тренингов и короткого периода изучения проекта начинали копать не хуже чем старички, а иногда даже и лучше, потому что обладали большим опытом в других областях и имели шире кругозор.
Отмечу, что это касается именно доменной области а не знаний о конкретном продукте или фреймворке. Логично, что я лучше понимал, как использовать внутреннюю кухню, но это специфика любого мало-мальски большого проекта.
Поэтому считаю, что доменные знания программисту особо не нужны. Адекватный специалист довольно быстро изучит новую область. Для углублённых знаний есть бизнес-аналитики и прочие SME, а разработчику нужно знать только то, что нужно для работы.
Конечно есть характерные области—бетттинг, финтех, медицины, где знание специфики вероятно поможет сильно быстрее въехать в дело и наверное есть прям совсем узкие вещи вроде разработки компиляторов или плагинов под конкретные продукты. Но я на практике видел, что это не такое уж и большое преимущество. Кроме того, компании же как-то набирают новых людей, и ничего, те вполне себе работают.
Поэтому я больше не придаю большого значения своим знаниям о том или о сём. Надо будет—сяду и разберусь.
👍1
Бесполезная работа
Нет ничего хуже, чем работать в стол или делать что-то просто так. На моей первой работе меня и еще одного парня определили разрабатывать модуль к продукту под присмотром пары тимлидов.
Требования к этому самому продукту явно не были сформулированы, поэтому делали как считали нужным. Этот модуль прямо сейчас не был нужен никакому клиенту, поэтому делался в стол. Вначале я зарядился (первая работа все-таки!) но потом быстро понял, что делать непонятые штуки просто так, потому что надо занять чем-то людей, это не самая хорошая идея. Спустя менее чем полгода нас перекинули на саппорт легаси проектов, а про тот модуль все забыли.
Сдули пыль с него только через несколько лет, когда нашёлся клиент. Естественно, в коде было много недоработок и перформенс проблем. Допиливала и доводила до ума его уже совсем другая команда.
Я четко помню некоторое безразличие нашего тогдашнего инжиниринг менеджера, когда мы с ребятами показывали/рассказывали что сделали. Сейчас я понимаю что у него тогда были совсем другие заботы, нежели какие-то локальные успехи пары студентов, которые толком и продать-то некому, но тогда чот приуныл. Добро пожаловать в реальный мир.
Когда у нас была своя шлюпка, то я тоже давал ребятам делать работу в стол, когда не было проектов или задач, каюсь. Для такого момента хорошо иметь беклог незакрытых низкоприоритетных задач, но даже это мне кажется не очень хорошим. До сих пор есть куча кода, который так никуда и не был запущен.
Говорят что в аутсорсах люди могут месяцами сидеть на бенче в ожидании проекта. Месяцами! С ума сойти можно. Нет, я понимаю, самообразование и всё такое, но... Почему нельзя просто платить человеку за то, что он ничего не делает, но и не уходит? Как-то безумно звучит, бизнес так не работает, надо заставлять людей копать ямы.
Поэтому обычно эта задача решается наиболее простым способом—компания набирает работы чуть-чуть больше, чем на это есть ресурса. На моей шлюпке работы часто было чуть-чуть меньше, поэтому приходилось заниматься ерундой.
Нет ничего хуже, чем работать в стол или делать что-то просто так. На моей первой работе меня и еще одного парня определили разрабатывать модуль к продукту под присмотром пары тимлидов.
Требования к этому самому продукту явно не были сформулированы, поэтому делали как считали нужным. Этот модуль прямо сейчас не был нужен никакому клиенту, поэтому делался в стол. Вначале я зарядился (первая работа все-таки!) но потом быстро понял, что делать непонятые штуки просто так, потому что надо занять чем-то людей, это не самая хорошая идея. Спустя менее чем полгода нас перекинули на саппорт легаси проектов, а про тот модуль все забыли.
Сдули пыль с него только через несколько лет, когда нашёлся клиент. Естественно, в коде было много недоработок и перформенс проблем. Допиливала и доводила до ума его уже совсем другая команда.
Я четко помню некоторое безразличие нашего тогдашнего инжиниринг менеджера, когда мы с ребятами показывали/рассказывали что сделали. Сейчас я понимаю что у него тогда были совсем другие заботы, нежели какие-то локальные успехи пары студентов, которые толком и продать-то некому, но тогда чот приуныл. Добро пожаловать в реальный мир.
Когда у нас была своя шлюпка, то я тоже давал ребятам делать работу в стол, когда не было проектов или задач, каюсь. Для такого момента хорошо иметь беклог незакрытых низкоприоритетных задач, но даже это мне кажется не очень хорошим. До сих пор есть куча кода, который так никуда и не был запущен.
Говорят что в аутсорсах люди могут месяцами сидеть на бенче в ожидании проекта. Месяцами! С ума сойти можно. Нет, я понимаю, самообразование и всё такое, но... Почему нельзя просто платить человеку за то, что он ничего не делает, но и не уходит? Как-то безумно звучит, бизнес так не работает, надо заставлять людей копать ямы.
Поэтому обычно эта задача решается наиболее простым способом—компания набирает работы чуть-чуть больше, чем на это есть ресурса. На моей шлюпке работы часто было чуть-чуть меньше, поэтому приходилось заниматься ерундой.
Главные грехи разработчиков: обратная несовместимость
Никто не любит поддерживать старое.
Долго время я занимался разработкой продукта, который выставлял наружу набор интерфейсов. Довольно серьезной проблемой была необходимость поддерживать обратную совместимость. Руки так и чесались выбросить всё и переписать, но проекты, которые нас использовали, неизменно были этому не рады.
Я был молод и у меня постоянно горела жопа от того, что приходилось думать как держать кучу легаси в коде и не поломать то, что и так работало. Я тогда мыслил так—неужели так сложно поменять пару сигнатур тут и там, пересобрать и зарелизить? Иногда это удавалось провернуть и код выбрасывался, иногда проектное руководство имело больше веса и приходилось городить костыли.
В целом, в большей части своей карьеры я придерживался позиции "плевать на пользователей, мы рефакторим код".
Недавно это начало меняться, особенно когда я сам столкнулся с последствиями недальновидного поведения других разработчиков. Про питон 2 и 3 все в курсе, да? Ну это так уже, часть истории, с грехом пополам всё уже мигрировали, хотя и несколько раз продлевали sunset. А вот скала 2.11 vs все остальное это похуже. Разработчики скалы оказались настолько самоуверенными, что сделали бинарную обратную несовместимость. То есть код, написанный и собранный под scala 2.11 не будет работать с рантаймом scala 2.12. В итоге что? Правильно, весь мир сидит на 2.11 и в ус не дует. Spark до сих пор по-дефолту собран под 2.11. Я тоже в ус не дул, пока не оказалось что надо собрать библиотеку, над которой я работаю под 2.12, потому что у заказчика один из тех самых редких случаев когда всё собирается под 2.12. И тут началось... Long story short, все заработало, но нервов было потрачено изрядно.
У меня на саппорте есть несколько продуктов которые предоставляют внешний rest api. Ещё давно у меня были идеи сделать его более "красивым", ну знаете, поменять параметры с snake_case на camelCase и наоборот, урлы там более прилично назвать и так далее.
Но на нас заинтегрировано куча решений, и когда я задеплою, то они все сломаются. Разработчикам придется вспоминать, что мы вообще такое, менять параметры, тестировать. Часть людей наверное вообще отвалилась и их сервисы просто сломаются.
Сейчас я четко понимаю, что это плохая идея. Хочешь красивое API? Ок, делай /v2 (или другой способ версионирования) и поехал. И не забудь в старом добавить костылики чтобы ничего не поломалось.
Да, нам инженерам хочется всё выбросить и переписать. Убрать легаси, перестать поддерживать старые версии библиотек, обновить зависимости. Но нельзя просто так плевать на существующих потребителей.
Никто не любит поддерживать старое.
Долго время я занимался разработкой продукта, который выставлял наружу набор интерфейсов. Довольно серьезной проблемой была необходимость поддерживать обратную совместимость. Руки так и чесались выбросить всё и переписать, но проекты, которые нас использовали, неизменно были этому не рады.
Я был молод и у меня постоянно горела жопа от того, что приходилось думать как держать кучу легаси в коде и не поломать то, что и так работало. Я тогда мыслил так—неужели так сложно поменять пару сигнатур тут и там, пересобрать и зарелизить? Иногда это удавалось провернуть и код выбрасывался, иногда проектное руководство имело больше веса и приходилось городить костыли.
В целом, в большей части своей карьеры я придерживался позиции "плевать на пользователей, мы рефакторим код".
Недавно это начало меняться, особенно когда я сам столкнулся с последствиями недальновидного поведения других разработчиков. Про питон 2 и 3 все в курсе, да? Ну это так уже, часть истории, с грехом пополам всё уже мигрировали, хотя и несколько раз продлевали sunset. А вот скала 2.11 vs все остальное это похуже. Разработчики скалы оказались настолько самоуверенными, что сделали бинарную обратную несовместимость. То есть код, написанный и собранный под scala 2.11 не будет работать с рантаймом scala 2.12. В итоге что? Правильно, весь мир сидит на 2.11 и в ус не дует. Spark до сих пор по-дефолту собран под 2.11. Я тоже в ус не дул, пока не оказалось что надо собрать библиотеку, над которой я работаю под 2.12, потому что у заказчика один из тех самых редких случаев когда всё собирается под 2.12. И тут началось... Long story short, все заработало, но нервов было потрачено изрядно.
У меня на саппорте есть несколько продуктов которые предоставляют внешний rest api. Ещё давно у меня были идеи сделать его более "красивым", ну знаете, поменять параметры с snake_case на camelCase и наоборот, урлы там более прилично назвать и так далее.
Но на нас заинтегрировано куча решений, и когда я задеплою, то они все сломаются. Разработчикам придется вспоминать, что мы вообще такое, менять параметры, тестировать. Часть людей наверное вообще отвалилась и их сервисы просто сломаются.
Сейчас я четко понимаю, что это плохая идея. Хочешь красивое API? Ок, делай /v2 (или другой способ версионирования) и поехал. И не забудь в старом добавить костылики чтобы ничего не поломалось.
Да, нам инженерам хочется всё выбросить и переписать. Убрать легаси, перестать поддерживать старые версии библиотек, обновить зависимости. Но нельзя просто так плевать на существующих потребителей.
Собеседования в фаангах
Западный интернет очень любит жаловаться на вайтбординг-собесы в больших корпорациях. Там даже ходит шутка, что "в долине проще открыть свою компанию чем устроиться в существующие". Авторы популярных инструментов и библиотек пишут в твиторах о том, что их не взяли в фаанг, хотя они создали продукты, которыми пользуется весь мир.
Отечественный интернет не жалуется. Отечественный интернет молча, сцепив зубы, зубрит литкод по вечерам, тщательно готовится и в итоге проходит на работу, хоть тушкой, хоть чучелом.
Неоднократно упоминалось что работа в таких компаниях в целом мало отличается от работы в других компаниях. Перекладываешь протобафы из одного места в другое, никаких суперсложных задач (которые скорее всего есть, но там где давно уже все места заняты). Если вы посмотрите на опенсорс код, который выходит из-под пера этих ребят, то можете легко в этом убедиться. Там работают точно такие же люди как и мы.
Когда я присоединялся к дискуссии по этому поводу, то всегда думал что собесы в фаангах—это такой карго-культ пополам с стокгольмским синдромом и цепочкой положительной обратной связи. Если меня гоняли бессмысленными задачами—значит и я буду так же гонять первоходов! Чем больше других компаний перенимает опыт гуглов в проведении собеседований—тем больше гугл уверен в том что он всё делает правильно.
Тем не менее, меня всегда удивлял тот факт, что по идее, там ведь работают неглупые люди? Раз они спрашивают на интро про сокеты в юниксе, предлагают на доске нарисовать quicksort и требуют оценить O-сложность алгоритма, значит они видят в этом какой-то смысл? Не может же быть так, что огромное количество людей повторяют какую-то бесполезную работу? Не может же быть, чтобы эти компании не думали над тем, как упростить и ускорить процесс собеседований (ведь каждый час проведённый за доской стоит больших денег)? Значит, ничего лучше пока что не придумали.
Поэтому я пришел к такому выводу. Основная проблема таких компаний какая? Масштаб. У них очень много сотрудников и очень-очень много желающих попасть на работу со всего мира (многие из которых едва ли умеют программировать). Тупые вопросы от рекрутёра, клоунские задачи из литкода и социально-приемлемое behavioral interview—это всего лишь стандартный способ провести собес, отсеять негодных людей и убедиться что кандидат ±умеет программировать. Если каждый отдел начнет придумывать себе задачи и вопросы которые важны именно для них, то всё это закончится полным хаосом в найме. А так—у всех есть единообразный набор вопросов, методов, метрик. Для больших корпораций это мастхев. Задача процесса—не взять лучшего и оценить личность, а отсеять неадекватных и убедиться что человек сможет быть винтиком в системе.
Люди тратят месяцы на подготовку к таким собеседованиям. Мне кажется это тоже неплохо для означенных компаний—раз человек готов уделять своё личное время на зубрёжку, значит он уже в некоторой степени лоялен.
У нас, в Украине, такие собеседования не распространены. Причина проста—желающих поработать есть меньше, чем вакансий, а вайтишников отсеивают по другим критериям (опыт работы). Поэтому как только компания начнет прикидываться фейсбуком, у нее резко просядет конверсия кандидатов. Все будут просто вставать и уходить, потому что за углом на работу берут без дурацких задач. Фаангом может попробовать прикинуться только какой-нибудь граммарли или пипл.аи.
Стратегически, с точки зрения кандидата тоже гораздо удобнее знать что за тип задач будет на собеседовании, чтобы подготовиться к ним. Пусть даже это трудоёмкий процесс, но зато предсказуемый. А мы, люди, любим предсказуемость больше чем что-либо другое.
Западный интернет очень любит жаловаться на вайтбординг-собесы в больших корпорациях. Там даже ходит шутка, что "в долине проще открыть свою компанию чем устроиться в существующие". Авторы популярных инструментов и библиотек пишут в твиторах о том, что их не взяли в фаанг, хотя они создали продукты, которыми пользуется весь мир.
Отечественный интернет не жалуется. Отечественный интернет молча, сцепив зубы, зубрит литкод по вечерам, тщательно готовится и в итоге проходит на работу, хоть тушкой, хоть чучелом.
Неоднократно упоминалось что работа в таких компаниях в целом мало отличается от работы в других компаниях. Перекладываешь протобафы из одного места в другое, никаких суперсложных задач (которые скорее всего есть, но там где давно уже все места заняты). Если вы посмотрите на опенсорс код, который выходит из-под пера этих ребят, то можете легко в этом убедиться. Там работают точно такие же люди как и мы.
Когда я присоединялся к дискуссии по этому поводу, то всегда думал что собесы в фаангах—это такой карго-культ пополам с стокгольмским синдромом и цепочкой положительной обратной связи. Если меня гоняли бессмысленными задачами—значит и я буду так же гонять первоходов! Чем больше других компаний перенимает опыт гуглов в проведении собеседований—тем больше гугл уверен в том что он всё делает правильно.
Тем не менее, меня всегда удивлял тот факт, что по идее, там ведь работают неглупые люди? Раз они спрашивают на интро про сокеты в юниксе, предлагают на доске нарисовать quicksort и требуют оценить O-сложность алгоритма, значит они видят в этом какой-то смысл? Не может же быть так, что огромное количество людей повторяют какую-то бесполезную работу? Не может же быть, чтобы эти компании не думали над тем, как упростить и ускорить процесс собеседований (ведь каждый час проведённый за доской стоит больших денег)? Значит, ничего лучше пока что не придумали.
Поэтому я пришел к такому выводу. Основная проблема таких компаний какая? Масштаб. У них очень много сотрудников и очень-очень много желающих попасть на работу со всего мира (многие из которых едва ли умеют программировать). Тупые вопросы от рекрутёра, клоунские задачи из литкода и социально-приемлемое behavioral interview—это всего лишь стандартный способ провести собес, отсеять негодных людей и убедиться что кандидат ±умеет программировать. Если каждый отдел начнет придумывать себе задачи и вопросы которые важны именно для них, то всё это закончится полным хаосом в найме. А так—у всех есть единообразный набор вопросов, методов, метрик. Для больших корпораций это мастхев. Задача процесса—не взять лучшего и оценить личность, а отсеять неадекватных и убедиться что человек сможет быть винтиком в системе.
Люди тратят месяцы на подготовку к таким собеседованиям. Мне кажется это тоже неплохо для означенных компаний—раз человек готов уделять своё личное время на зубрёжку, значит он уже в некоторой степени лоялен.
У нас, в Украине, такие собеседования не распространены. Причина проста—желающих поработать есть меньше, чем вакансий, а вайтишников отсеивают по другим критериям (опыт работы). Поэтому как только компания начнет прикидываться фейсбуком, у нее резко просядет конверсия кандидатов. Все будут просто вставать и уходить, потому что за углом на работу берут без дурацких задач. Фаангом может попробовать прикинуться только какой-нибудь граммарли или пипл.аи.
Стратегически, с точки зрения кандидата тоже гораздо удобнее знать что за тип задач будет на собеседовании, чтобы подготовиться к ним. Пусть даже это трудоёмкий процесс, но зато предсказуемый. А мы, люди, любим предсказуемость больше чем что-либо другое.
Единственный 99% метод успешного найма
Почти всю свою карьеру я нанимал джунов. У компании, где я работал, был учебный центр, который регулярно поставлял свежую рабсилу (в том числе и меня поставил хехех), а на людей с рынка до определённого времени не было бюджета.
Поэтому я хорошо насобачился за 10 минут понимать, годный джун или нет. Дал пару задач, спросил пару вопросов и всё ясно. Джуны у меня были самые лучшие, промахов считай и не было, кроме парня из пары постов выше.
А вот с помидорами было похуже. Я их долгое время просто не нанимал. Позже, работая в стартапе, нам выдали картбланш, мы пошли искать людей и я отсобеседовал наверное пару десятков клиентов. Практически все из них ничего не стоили, хотя до этого работали сеньерами в украинской "большой пятерке". Я так никого и не нанял.
Тем не менее, первую команду того стартапа собрал именно я. Каким образом? Очень просто—я брал тех людей, которых знал и с которыми работал лично. Все это были ребята из моего экс-отдела, которые рискнули пойти за мной. Ни об одном из этих наймов ни я, ни боссы не пожалели ни разу.
Если бы я щас делал новую команду, то поступил бы точно так же.
Конечно метод этот вообще никак не масштабируется, потому что экс-коллеги рано или поздно заканчиваются или недоступны, но для сбора ядра—вполне может хватить.
Так что нанимайте своих коллег, получайте за них бонус и будьте счастливы.
Почти всю свою карьеру я нанимал джунов. У компании, где я работал, был учебный центр, который регулярно поставлял свежую рабсилу (в том числе и меня поставил хехех), а на людей с рынка до определённого времени не было бюджета.
Поэтому я хорошо насобачился за 10 минут понимать, годный джун или нет. Дал пару задач, спросил пару вопросов и всё ясно. Джуны у меня были самые лучшие, промахов считай и не было, кроме парня из пары постов выше.
А вот с помидорами было похуже. Я их долгое время просто не нанимал. Позже, работая в стартапе, нам выдали картбланш, мы пошли искать людей и я отсобеседовал наверное пару десятков клиентов. Практически все из них ничего не стоили, хотя до этого работали сеньерами в украинской "большой пятерке". Я так никого и не нанял.
Тем не менее, первую команду того стартапа собрал именно я. Каким образом? Очень просто—я брал тех людей, которых знал и с которыми работал лично. Все это были ребята из моего экс-отдела, которые рискнули пойти за мной. Ни об одном из этих наймов ни я, ни боссы не пожалели ни разу.
Если бы я щас делал новую команду, то поступил бы точно так же.
Конечно метод этот вообще никак не масштабируется, потому что экс-коллеги рано или поздно заканчиваются или недоступны, но для сбора ядра—вполне может хватить.
Так что нанимайте своих коллег, получайте за них бонус и будьте счастливы.
Сегодня в 20:00 по Києву, 21:00 Мск проведу стрим.
Как бороться с прокрастинацией?
Недостатки работы в большой корпорации.
Как тратить 2к грн в месяц на еду?
Лучший совет молодому разработчику.
👇👇👇
https://youtu.be/YcVKva5e8Go
👆👆👆
Задать свой вопрос или проголосовать здесь -> https://app.sli.do/event/q89hkv3v
Предыдущие стримы, для ознакомления с форматом: первый, второй, третий, четвёртый.
Для тех кто пропустит завтра будет доступна запись с таймкодами.
Приходите!
Как бороться с прокрастинацией?
Недостатки работы в большой корпорации.
Как тратить 2к грн в месяц на еду?
Лучший совет молодому разработчику.
👇👇👇
https://youtu.be/YcVKva5e8Go
👆👆👆
Задать свой вопрос или проголосовать здесь -> https://app.sli.do/event/q89hkv3v
Предыдущие стримы, для ознакомления с форматом: первый, второй, третий, четвёртый.
Для тех кто пропустит завтра будет доступна запись с таймкодами.
Приходите!
YouTube
Стрим №5: выгорание, прокрастинация, сокращённая рабочая неделя и лучший совет молодым разработчикам
Телеграм канал: https://xn--r1a.website/full_of_hatred/ Топ темы:
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:54:00 Как заработать авторитет если ты лид.…
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:54:00 Как заработать авторитет если ты лид.…
Таймкоды с стрима №5 https://youtu.be/YcVKva5e8Go смотреть на 2x скорости!
🔥Топ темы🔥:
👉00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
👉01:17:35 Как я борюсь с прокрастинацией? Про продуктивность. 🐒
👉01:54:00 Как заработать авторитет если ты лид. Про работу лида. 🐅
👉02:17:05 Как бороться с выгоранием? 🔥
👉02:26:20 Как договориться о переходе на 4-дневную рабочую неделю. 🦦🦥
Остальное (это не полный список, для полного заходите на ютуб. В телеграм все не влазит):
00:08:20 Дауншифтинг на теплотрассу
00:12:09 Можно ли работать на двух работах одновременно? Мультипроектность https://www.rozhkov.me/post/multi-projects/
00:15:31 Как мне помогает личный бренд
00:17:31 Стоит ли копить деньги и жить на минималках если ты джун?
00:18:48 Еще раз про две параллельных работы
00:21:42 Как понять свой уровень знаний? Еще джун или уже мид?
00:24:17 Как прокачал английский до разговорного? https://www.rozhkov.me/post/english/
00:24:51 Стоит ли ходить на собесы если не думаешь про смену работы?
00:26:16 Как я питаюсь? Сколько трачу на еду? Про АТБ https://www.rozhkov.me/post/lesser-better-1/
00:34:29 Личный бренд внутри работы. Как быть "видимым" специалистом? https://jvns.ca/blog/brag-documents/
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
00:46:10 Немного про клавиатуры, столы, аппаратуру
00:50:28 Стоит ли переходить на новый проект если потеряешь в деньгах?
00:54:33 Как бороться с синдромом самозванца? https://www.rozhkov.me/post/impostor-syndrome/
00:57:43 Что изучаю сейчас? Почему не слежу за техническими новостями. https://www.kalzumeus.com/start-here-if-youre-new/
01:04:00 Есть ли смысл переходить из тимлида 5k на архитектора 6k?
01:08:07 Видел ли ты чтобы крутой сеньерный специалист получал сильно меньше формошлепа который удачно себя продал?
01:10:03 Почему не получилось сработаться с джунами для разработки adopt.com.ua https://www.rozhkov.me/post/adopt-com-ua-one-year-later/
01:12:17 Чем собираютсь заниматься после 40?
01:14:24 Показываю своего кота с особенными потребностями
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:32:32 Как бороться с вредными привычками? Как я воздерживаюсь от спонтанных трат.
01:35:05 Аутсорс или продукт? Рассказываю про databand.ai
01:38:02 Как развиваюсь вне работы? https://www.rozhkov.me/post/resume-driven-development/
01:39:22 Стоит ли становиться вайтишником после 30? История успеха одного из подписчиков.
01:44:20 Недостатки работы в больших корпорациях.
01:48:23 Есть ли смысл идти на вайти-курсы. Поиск работы если ты джун.
01:50:46 Советы по входу в рабочий режим.
01:54:00 Как заработать авторитет если ты лид. Про работу лида.
02:03:12 Что лучше—купить квартиру поплоше сейчас или подкопить и взять получше через пару лет? https://www.rozhkov.me/post/half-measure/
02:06:54 Что делать если менеджер часто спрашивает статус по задаче? https://www.rozhkov.me/post/push-pull/
02:09:18 Про зарплаты и ранги.
02:13:03 Финансовые принципы https://www.rozhkov.me/post/basic-finances/
02:17:05 Как бороться с выгоранием?
02:25:36 Советы по поводу первой работы джуну
02:26:20 Как договориться о переходе на 4-дневную рабочую неделю
🔥Топ темы🔥:
👉00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
👉01:17:35 Как я борюсь с прокрастинацией? Про продуктивность. 🐒
👉01:54:00 Как заработать авторитет если ты лид. Про работу лида. 🐅
👉02:17:05 Как бороться с выгоранием? 🔥
👉02:26:20 Как договориться о переходе на 4-дневную рабочую неделю. 🦦🦥
Остальное (это не полный список, для полного заходите на ютуб. В телеграм все не влазит):
00:08:20 Дауншифтинг на теплотрассу
00:12:09 Можно ли работать на двух работах одновременно? Мультипроектность https://www.rozhkov.me/post/multi-projects/
00:15:31 Как мне помогает личный бренд
00:17:31 Стоит ли копить деньги и жить на минималках если ты джун?
00:18:48 Еще раз про две параллельных работы
00:21:42 Как понять свой уровень знаний? Еще джун или уже мид?
00:24:17 Как прокачал английский до разговорного? https://www.rozhkov.me/post/english/
00:24:51 Стоит ли ходить на собесы если не думаешь про смену работы?
00:26:16 Как я питаюсь? Сколько трачу на еду? Про АТБ https://www.rozhkov.me/post/lesser-better-1/
00:34:29 Личный бренд внутри работы. Как быть "видимым" специалистом? https://jvns.ca/blog/brag-documents/
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
00:46:10 Немного про клавиатуры, столы, аппаратуру
00:50:28 Стоит ли переходить на новый проект если потеряешь в деньгах?
00:54:33 Как бороться с синдромом самозванца? https://www.rozhkov.me/post/impostor-syndrome/
00:57:43 Что изучаю сейчас? Почему не слежу за техническими новостями. https://www.kalzumeus.com/start-here-if-youre-new/
01:04:00 Есть ли смысл переходить из тимлида 5k на архитектора 6k?
01:08:07 Видел ли ты чтобы крутой сеньерный специалист получал сильно меньше формошлепа который удачно себя продал?
01:10:03 Почему не получилось сработаться с джунами для разработки adopt.com.ua https://www.rozhkov.me/post/adopt-com-ua-one-year-later/
01:12:17 Чем собираютсь заниматься после 40?
01:14:24 Показываю своего кота с особенными потребностями
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:32:32 Как бороться с вредными привычками? Как я воздерживаюсь от спонтанных трат.
01:35:05 Аутсорс или продукт? Рассказываю про databand.ai
01:38:02 Как развиваюсь вне работы? https://www.rozhkov.me/post/resume-driven-development/
01:39:22 Стоит ли становиться вайтишником после 30? История успеха одного из подписчиков.
01:44:20 Недостатки работы в больших корпорациях.
01:48:23 Есть ли смысл идти на вайти-курсы. Поиск работы если ты джун.
01:50:46 Советы по входу в рабочий режим.
01:54:00 Как заработать авторитет если ты лид. Про работу лида.
02:03:12 Что лучше—купить квартиру поплоше сейчас или подкопить и взять получше через пару лет? https://www.rozhkov.me/post/half-measure/
02:06:54 Что делать если менеджер часто спрашивает статус по задаче? https://www.rozhkov.me/post/push-pull/
02:09:18 Про зарплаты и ранги.
02:13:03 Финансовые принципы https://www.rozhkov.me/post/basic-finances/
02:17:05 Как бороться с выгоранием?
02:25:36 Советы по поводу первой работы джуну
02:26:20 Как договориться о переходе на 4-дневную рабочую неделю
YouTube
Стрим №5: выгорание, прокрастинация, сокращённая рабочая неделя и лучший совет молодым разработчикам
Телеграм канал: https://xn--r1a.website/full_of_hatred/ Топ темы:
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:54:00 Как заработать авторитет если ты лид.…
00:39:24 Лучший совет разработчикам 20-25 лет https://www.rozhkov.me/post/company-vs-project/
01:17:35 Как я борюсь с прокрастинацией? Про продуктивность.
01:54:00 Как заработать авторитет если ты лид.…
Неразговорный английский
Я намеренно никогда не учил английский язык. В школе вообще пошел на немецкий, в КПИ сами знаете какое качество преподавания, на работе курсы тоже как-то не помогли, думаю что плохо старался.
Тем не менее, с грехом пополам, разговаривать я научился. В 2010 я поехал в свою первую командировку, в Канаду, где, можно сказать, впервые поговорил с нейтивами. Там я работал в большой команде, в которой были наши инженеры, люди от заказчика и контракторы из компаниии ThoughtWorks (это там где щас работает Мартин Фаулер). Был выделенный скрам мастер (хотя тогда кажется это называлось по-другому), у нас были дейли стендапы и всё такое. На этих самых стендапах приходилось, естественно, утром говорить, что сделал вчера, что будешь делать сегодня, какие проблемы.
Ну и я рассказывал, как и все. Уверенно и громко.
Через некоторое время подходит ко мне наш PM и тихо говорит: "слушай, ты на дейли вместо yesterday говоришь tomorrow, получается немного неточно". Я конечно же немедленно осознал всю глупость и кринжовость ситуации: когда перед 20-ью людьми (стендап на 20 людей это то еще развлечение) ты говоришь "завтра я пофиксил баг, а сегодня собираюсь пофиксить еще один". Ни один человек не сделал мне замечание на протяжении нескольких дней кряду—вот что значит толерантность к иностранцам!
Потом на всяких корпоративных ивентах я тоже допускал смешные ошибки: путал времена (я и щас иногда их путаю), he/she и тд.
Сейчас у меня уровень конечно подрос. Но думаю что главное качество которое мне помогало всё это время—это уверенность и отсутствие страха ошибиться.
p.s.: всё еще не знаете английского? Я уже писал, что английский—первый язык нужный программисту, до паскаля, С и джавы, а так же публиковал советы по изучению и свой опыт.
Я намеренно никогда не учил английский язык. В школе вообще пошел на немецкий, в КПИ сами знаете какое качество преподавания, на работе курсы тоже как-то не помогли, думаю что плохо старался.
Тем не менее, с грехом пополам, разговаривать я научился. В 2010 я поехал в свою первую командировку, в Канаду, где, можно сказать, впервые поговорил с нейтивами. Там я работал в большой команде, в которой были наши инженеры, люди от заказчика и контракторы из компаниии ThoughtWorks (это там где щас работает Мартин Фаулер). Был выделенный скрам мастер (хотя тогда кажется это называлось по-другому), у нас были дейли стендапы и всё такое. На этих самых стендапах приходилось, естественно, утром говорить, что сделал вчера, что будешь делать сегодня, какие проблемы.
Ну и я рассказывал, как и все. Уверенно и громко.
Через некоторое время подходит ко мне наш PM и тихо говорит: "слушай, ты на дейли вместо yesterday говоришь tomorrow, получается немного неточно". Я конечно же немедленно осознал всю глупость и кринжовость ситуации: когда перед 20-ью людьми (стендап на 20 людей это то еще развлечение) ты говоришь "завтра я пофиксил баг, а сегодня собираюсь пофиксить еще один". Ни один человек не сделал мне замечание на протяжении нескольких дней кряду—вот что значит толерантность к иностранцам!
Потом на всяких корпоративных ивентах я тоже допускал смешные ошибки: путал времена (я и щас иногда их путаю), he/she и тд.
Сейчас у меня уровень конечно подрос. Но думаю что главное качество которое мне помогало всё это время—это уверенность и отсутствие страха ошибиться.
p.s.: всё еще не знаете английского? Я уже писал, что английский—первый язык нужный программисту, до паскаля, С и джавы, а так же публиковал советы по изучению и свой опыт.
Rabbit hole
Это выражение в английском языке примерно обозначает сложности, которые возникают после того как начинаешь решать вроде бы простую проблему и проваливаешься как Алиса в кроличью нору.
Думаю что каждому инженеру знакомо то чувство, когда чинишь маленький баг а через день приходишь в сознанение с наполовину отрефакторенным проектом.
Такие норы часто непонятны менеджерам и бизнес людям, для которых задача "добавить кнопочку" выглядит работой на 1 час а не на 2 дня.
На той неделе мне нужно было добавить возможность деактивировать объявления в наш проект adopt.com.ua. Выглядит просто, да? Поменять где-то там статус с "опубликовано" на "деактивировано" и делов. Но не всё так просто :) Оказалось что год назад я неосмотрительно не предусмотрел этой функции и для обозначения активно объявление или нет сделал булево поле is_approved. Когда добавляют объявление, оно попадает модераторам на проверку, его проверяют и публикуют. За всё отвечает один флаг.
Как деактивировать объявление? Если делать это с помощью флага, то получается что объявление попадет в список "на проверку" так как будет считаться "новым". Можно добавить костылик, сделать еще одно поле типа "было уже опубликовано". Но правильно конечно будет сделать для объявления жизненный цикл и стейт машину "новое"->"опубликовано"<->"деактивировано". И тут началось.
Напиши миграцию, добавь новое поле. Проставь это поле вместо старого булевского флага везде где это было. Поправь фронтэнд где есть отдельные закладки для непроверенных и так как они сделаны по dry, то там передавался булев параметр, надо переписать шаблон. Добавь еще одну вкладку для деактивированных. Добавь кнопочки для деактивации и активации в админке. Добавь кнопки для деактивации в пользовательской части. Поправь контроллер для пользовательской части чтобы там были эти методы. Поправь нотификации для модераторов. Теперь надо чтобы старая кнопка "опубликовать", которая сохраняла и публиковала, проставляла новый статус. Но вот незадача, в rails на кнопки нельзя вешать параметры просто так, а так как мне нужно отделять "сохранить" от "сохранить и опубликовать" то это превратилось в еще одну проблему... Ой, а еще мы не можем назвать скоуп (метод) класса new потому что очевидно это зарезервированное слово. Не забудь после миграции вручную проставить статус старым объявлениям. Залей на продакшен, убедись что работает там.
Спустя 2 часа кнопка была готова. Конечно, большое количество работы было вызвано некорректным изначальным дизайном, но в нашей жизни скорее всего таких случаев будет значительно больше, нежели "правильных".
Очень классно эту метафору передает вот это видео: https://www.youtube.com/watch?v=AbSehcT19u0
Это выражение в английском языке примерно обозначает сложности, которые возникают после того как начинаешь решать вроде бы простую проблему и проваливаешься как Алиса в кроличью нору.
Думаю что каждому инженеру знакомо то чувство, когда чинишь маленький баг а через день приходишь в сознанение с наполовину отрефакторенным проектом.
Такие норы часто непонятны менеджерам и бизнес людям, для которых задача "добавить кнопочку" выглядит работой на 1 час а не на 2 дня.
На той неделе мне нужно было добавить возможность деактивировать объявления в наш проект adopt.com.ua. Выглядит просто, да? Поменять где-то там статус с "опубликовано" на "деактивировано" и делов. Но не всё так просто :) Оказалось что год назад я неосмотрительно не предусмотрел этой функции и для обозначения активно объявление или нет сделал булево поле is_approved. Когда добавляют объявление, оно попадает модераторам на проверку, его проверяют и публикуют. За всё отвечает один флаг.
Как деактивировать объявление? Если делать это с помощью флага, то получается что объявление попадет в список "на проверку" так как будет считаться "новым". Можно добавить костылик, сделать еще одно поле типа "было уже опубликовано". Но правильно конечно будет сделать для объявления жизненный цикл и стейт машину "новое"->"опубликовано"<->"деактивировано". И тут началось.
Напиши миграцию, добавь новое поле. Проставь это поле вместо старого булевского флага везде где это было. Поправь фронтэнд где есть отдельные закладки для непроверенных и так как они сделаны по dry, то там передавался булев параметр, надо переписать шаблон. Добавь еще одну вкладку для деактивированных. Добавь кнопочки для деактивации и активации в админке. Добавь кнопки для деактивации в пользовательской части. Поправь контроллер для пользовательской части чтобы там были эти методы. Поправь нотификации для модераторов. Теперь надо чтобы старая кнопка "опубликовать", которая сохраняла и публиковала, проставляла новый статус. Но вот незадача, в rails на кнопки нельзя вешать параметры просто так, а так как мне нужно отделять "сохранить" от "сохранить и опубликовать" то это превратилось в еще одну проблему... Ой, а еще мы не можем назвать скоуп (метод) класса new потому что очевидно это зарезервированное слово. Не забудь после миграции вручную проставить статус старым объявлениям. Залей на продакшен, убедись что работает там.
Спустя 2 часа кнопка была готова. Конечно, большое количество работы было вызвано некорректным изначальным дизайном, но в нашей жизни скорее всего таких случаев будет значительно больше, нежели "правильных".
Очень классно эту метафору передает вот это видео: https://www.youtube.com/watch?v=AbSehcT19u0
YouTube
Hal fixing a light bulb (from Malcolm in the Middle S03E06 - Health Scare)
I think this is pretty familiar for most of us.
To everyone who watches this: please check out this youtube creator called nartharie . He has created some of the must absurd and funniest videos I've ever seen, but he's still at 280 subs at the time of writing.…
To everyone who watches this: please check out this youtube creator called nartharie . He has created some of the must absurd and funniest videos I've ever seen, but he's still at 280 subs at the time of writing.…
Отзывчивость
Замечали ли вы когда-нибудь, насколько приятнее работать с банкоматами в который установлен древний софт на ncurses? Они моментально срабатывают на любое нажатие клавиши, не тупят при переходах между экранами. Новые терминалы, на которых (вероятно) открывается что-то типа электрона нереально медленные по сравнению со старыми. Как по мне интерфейсная отзывчивость сильно недооценена.
Впрочем я не о программах.
Большинство действительно нужной работы, которую я делаю, работается за очень маленькое время. Если смотреть по таймеру, то это зачастую всего лишь несколько часов, а то и меньше. Но штука в том, что для того, чтобы добраться до выполнения нужно пробраться сквозь прокрастинацию, настройку окружения, выяснение требований, вход в рабочий режим. В результате оверхед обычно составляет 80% (цифра взята из головы).
Подозреваю, что эффективные люди—это те, кто смогли упаковать и выполнить задачи таким образом, что оверхед этот минимизирован.
Но самое главное, если результат вашей работы кому-то нужен, то наилучшее впечатление, которое обычно вы можете произвести на человека—это сделать задачу как можно быстрее и так же быстро реагировать на новые запросы. В мире где все имеют свойство затягивать сроки, тупить, не отвечать, отзывчивость мне кажется важнейшей характеристикой. Супер приятно работать с инженером который решает задачи быстрее, чем ты ожидаешь.
Конечно работать быстро вообще невыгодно для наемного работника, потому что в вас будут просто паковать больше задач, но для перехода к более самостоятельной жизни навык быть отзывчивым и быстро делать нужное чрезвычайно важен.
Сейчас я растягиваю несколько часов работы на целый день и мне это не нравится. Способы решения этой задачи я вяло ищу уже на протяжении нескольких лет.
Замечали ли вы когда-нибудь, насколько приятнее работать с банкоматами в который установлен древний софт на ncurses? Они моментально срабатывают на любое нажатие клавиши, не тупят при переходах между экранами. Новые терминалы, на которых (вероятно) открывается что-то типа электрона нереально медленные по сравнению со старыми. Как по мне интерфейсная отзывчивость сильно недооценена.
Впрочем я не о программах.
Большинство действительно нужной работы, которую я делаю, работается за очень маленькое время. Если смотреть по таймеру, то это зачастую всего лишь несколько часов, а то и меньше. Но штука в том, что для того, чтобы добраться до выполнения нужно пробраться сквозь прокрастинацию, настройку окружения, выяснение требований, вход в рабочий режим. В результате оверхед обычно составляет 80% (цифра взята из головы).
Подозреваю, что эффективные люди—это те, кто смогли упаковать и выполнить задачи таким образом, что оверхед этот минимизирован.
Но самое главное, если результат вашей работы кому-то нужен, то наилучшее впечатление, которое обычно вы можете произвести на человека—это сделать задачу как можно быстрее и так же быстро реагировать на новые запросы. В мире где все имеют свойство затягивать сроки, тупить, не отвечать, отзывчивость мне кажется важнейшей характеристикой. Супер приятно работать с инженером который решает задачи быстрее, чем ты ожидаешь.
Конечно работать быстро вообще невыгодно для наемного работника, потому что в вас будут просто паковать больше задач, но для перехода к более самостоятельной жизни навык быть отзывчивым и быстро делать нужное чрезвычайно важен.
Сейчас я растягиваю несколько часов работы на целый день и мне это не нравится. Способы решения этой задачи я вяло ищу уже на протяжении нескольких лет.
Самозамеры
Многие любители упороться по продуктивности так же любят замерять себя по всевозможным параметрам.
Начинается всё с невинных вещей, вроде списка статистики сколько шагов прошёл за день. Потом подключается Strava и считаешь сколько пробежал. Потом ставишь на девайсы RescueTime и считаешь сколько в каких приложениях провел времени. Потом считаешь время потраченное на каждый проект в Toggl. Потом добавляешь сюда умные весы, умные часы, умный унитаз и другие приколы.
Стивен Вольфрам, человек который сделал Wolfram Mathematica, упоролся по-максимуму. Он считает вообще всё, вплоть до того, сколько кнопок нажал на клавиатуре. Эту статистику он ведет еще с конца восьмидесятых. Рекомендую к прочтению: https://writings.stephenwolfram.com/2012/03/the-personal-analytics-of-my-life/
Я тоже раньше угорал по трекингу. Проезжал на велике X километров, а потом смотрел в страве на них. Ставил RescueTime и смотрел на красивые отчетики. Пытался мерять что-то другое.
Потом я понял что трекаю ради трекинга и мне не хватает второй части паззла: понимания, что делать с этой информацией. Ок, rescuetime говорит, что на прошлой неделе я много времени проводил на твитче. Смотрел матчи по ксго. Епт, но я и так знаю что я их смотрел? Что я должен сделать с этим? Наверное, смотреть меньше! Но ведь ежу понятно что если ты каждый день вечером под пивко смотришь новый сезон острых козырьков, то ты тратишь на это прорву времени. Не нужно трекать, чтобы понять, что ты примерно 8 часов в неделю залипаешь в сериалы (или кому-то нужно?)
Я ничего не делал ни с информацией от стравы, ни с информацией от RescueTime. Скорее всего предполагается что каким-то образом замеряется прогресс по мере применения практик улучшения продуктивности и ты наглядно видишь результат. Но я и так со временем прекратил залипать, пошел в зал, занялся другой полезной деятельностью. Наверное это не для меня.
Поэтому все трекеры я выбросил (кроме тех, которые считают проектное время). Мне не нужно считать шаги чтобы понимать что на этой неделе я мало гулял. Мне не нужно считать сколько времени я потратил на стримы или игры чтобы понять что я слишком этим увлекаюсь. У меня есть куда более хорошая метрика для этого—простаивающие проекты и количество заработанных денег.
Трекаешь себя по всем параметрам? Поделись, что ты дальше с этим делаешь.
Многие любители упороться по продуктивности так же любят замерять себя по всевозможным параметрам.
Начинается всё с невинных вещей, вроде списка статистики сколько шагов прошёл за день. Потом подключается Strava и считаешь сколько пробежал. Потом ставишь на девайсы RescueTime и считаешь сколько в каких приложениях провел времени. Потом считаешь время потраченное на каждый проект в Toggl. Потом добавляешь сюда умные весы, умные часы, умный унитаз и другие приколы.
Стивен Вольфрам, человек который сделал Wolfram Mathematica, упоролся по-максимуму. Он считает вообще всё, вплоть до того, сколько кнопок нажал на клавиатуре. Эту статистику он ведет еще с конца восьмидесятых. Рекомендую к прочтению: https://writings.stephenwolfram.com/2012/03/the-personal-analytics-of-my-life/
Я тоже раньше угорал по трекингу. Проезжал на велике X километров, а потом смотрел в страве на них. Ставил RescueTime и смотрел на красивые отчетики. Пытался мерять что-то другое.
Потом я понял что трекаю ради трекинга и мне не хватает второй части паззла: понимания, что делать с этой информацией. Ок, rescuetime говорит, что на прошлой неделе я много времени проводил на твитче. Смотрел матчи по ксго. Епт, но я и так знаю что я их смотрел? Что я должен сделать с этим? Наверное, смотреть меньше! Но ведь ежу понятно что если ты каждый день вечером под пивко смотришь новый сезон острых козырьков, то ты тратишь на это прорву времени. Не нужно трекать, чтобы понять, что ты примерно 8 часов в неделю залипаешь в сериалы (или кому-то нужно?)
Я ничего не делал ни с информацией от стравы, ни с информацией от RescueTime. Скорее всего предполагается что каким-то образом замеряется прогресс по мере применения практик улучшения продуктивности и ты наглядно видишь результат. Но я и так со временем прекратил залипать, пошел в зал, занялся другой полезной деятельностью. Наверное это не для меня.
Поэтому все трекеры я выбросил (кроме тех, которые считают проектное время). Мне не нужно считать шаги чтобы понимать что на этой неделе я мало гулял. Мне не нужно считать сколько времени я потратил на стримы или игры чтобы понять что я слишком этим увлекаюсь. У меня есть куда более хорошая метрика для этого—простаивающие проекты и количество заработанных денег.
Трекаешь себя по всем параметрам? Поделись, что ты дальше с этим делаешь.
Как выбирать компанию для работы
Предположим, я решаю по каким-то причинам отчалить с работы и выбрать новое место. На что бы я обращал внимание и что бы искал?
(Пишу про себя, свои цели, приоритеты, интересы, у вас это все может сильно отличаться, соответственно вам не подойдут эти рекомендации)
Цель: получить побольше опыта: технического, бизнес, коммуникационного. Для этого отлично подойдёт молодая компания, работающая на мировом рынке, с распределённой мультинациональной командой.
1. Чем моложе компания тем больше у вас будет возможностей технического развития, потому что можно будет заниматься всем. С другой стороны, всё что сделали на ранних этапах скорее всего потом выбросят и перепишут заново. Так что нужно смотреть на баланс между "молодостью" и "зрелостью". Чем более сформированная команда и решение, тем меньше будет ваш "радиус поражения".
2. Чем ближе вы к руководству, тем больше у вас понимания что происходит вообще, и тем лучше люди, которые платят вам деньги, видят результат вашей работы. Чем ближе вы к началу работы, тем больше шансов у вас потом запромоутиться в менеджмент или принципал инженера (но это сильно маловероятно).
3. Чем больше разных людей в команде, тем лучше будут прокачиваться ваши скиллы коммуникации и английский.
Главные критерии для меня такие: строго иностранная компания, близость к руководству (маленький размер команды и отсутствие местных прокладок), наличие у конторы денег.
Разберём по пунктам мною написанное:
1. Думаю не надо объяснять, почему не стоит работать с местными бизнесменами. Сразу нет и всё. Нас интересует компания зарегистрированная и ведущая свой бизнес зарубежом. Основателями могут быть соотечественниками, но надо смотреть. Лучше всего америка конечно, так как там больше всего денег.
2. Работа напрямую. Самый нормальный вариант—когда вы репортите CTO. Если это невозможно, между вами должно быть как можно меньше уровней. Сразу отказать местным аутсорсерам. Можно смотреть на аутстафф который просто продает вашу тушку со столом—в этом случае у вас тоже будет прямая коммуникация с клиентом. Этот пункт предполагает что в компании будет маленькая команда когда CTO еще в курсе дел рядовых разработчиков (идеально если он сам еще программирует). Так же это означает что еще не был создан уровень менеджеров среднего звена, которые ничего не делают, а только собирают митинги и спрашивают статус. Меньше политики—лучше для всех.
3. Компания должна уже иметь посевной раунд инвестиций (а лучше раунд А, хотя это иногда конфликтует со вторым пунктом). Это значит, что вам должны платить по рынку или выше. У конторы должно быть бабло на зарплату вам на год вперед, новенький макбук и нормальное рабочее окружение. Про инвестиции спокойно можно спрашивать на собесе. Компания не должна жмотиться на зп. Торгуются и пытаются прогнуть—плохо.
Это всё общие факторы, на которые я бы обращал внимание в первую очередь. Где искать такую работу? Ну, большие аутстафферы часто работают со стартапами, ребята из creative quarters тоже. Спрашивайте своих рекрутеров, такие вакансии есть.
Дальше надо говорить с фаундерами, смотреть на команду, на предметную область и так далее.
Предположим, я решаю по каким-то причинам отчалить с работы и выбрать новое место. На что бы я обращал внимание и что бы искал?
(Пишу про себя, свои цели, приоритеты, интересы, у вас это все может сильно отличаться, соответственно вам не подойдут эти рекомендации)
Цель: получить побольше опыта: технического, бизнес, коммуникационного. Для этого отлично подойдёт молодая компания, работающая на мировом рынке, с распределённой мультинациональной командой.
1. Чем моложе компания тем больше у вас будет возможностей технического развития, потому что можно будет заниматься всем. С другой стороны, всё что сделали на ранних этапах скорее всего потом выбросят и перепишут заново. Так что нужно смотреть на баланс между "молодостью" и "зрелостью". Чем более сформированная команда и решение, тем меньше будет ваш "радиус поражения".
2. Чем ближе вы к руководству, тем больше у вас понимания что происходит вообще, и тем лучше люди, которые платят вам деньги, видят результат вашей работы. Чем ближе вы к началу работы, тем больше шансов у вас потом запромоутиться в менеджмент или принципал инженера (но это сильно маловероятно).
3. Чем больше разных людей в команде, тем лучше будут прокачиваться ваши скиллы коммуникации и английский.
Главные критерии для меня такие: строго иностранная компания, близость к руководству (маленький размер команды и отсутствие местных прокладок), наличие у конторы денег.
Разберём по пунктам мною написанное:
1. Думаю не надо объяснять, почему не стоит работать с местными бизнесменами. Сразу нет и всё. Нас интересует компания зарегистрированная и ведущая свой бизнес зарубежом. Основателями могут быть соотечественниками, но надо смотреть. Лучше всего америка конечно, так как там больше всего денег.
2. Работа напрямую. Самый нормальный вариант—когда вы репортите CTO. Если это невозможно, между вами должно быть как можно меньше уровней. Сразу отказать местным аутсорсерам. Можно смотреть на аутстафф который просто продает вашу тушку со столом—в этом случае у вас тоже будет прямая коммуникация с клиентом. Этот пункт предполагает что в компании будет маленькая команда когда CTO еще в курсе дел рядовых разработчиков (идеально если он сам еще программирует). Так же это означает что еще не был создан уровень менеджеров среднего звена, которые ничего не делают, а только собирают митинги и спрашивают статус. Меньше политики—лучше для всех.
3. Компания должна уже иметь посевной раунд инвестиций (а лучше раунд А, хотя это иногда конфликтует со вторым пунктом). Это значит, что вам должны платить по рынку или выше. У конторы должно быть бабло на зарплату вам на год вперед, новенький макбук и нормальное рабочее окружение. Про инвестиции спокойно можно спрашивать на собесе. Компания не должна жмотиться на зп. Торгуются и пытаются прогнуть—плохо.
Это всё общие факторы, на которые я бы обращал внимание в первую очередь. Где искать такую работу? Ну, большие аутстафферы часто работают со стартапами, ребята из creative quarters тоже. Спрашивайте своих рекрутеров, такие вакансии есть.
Дальше надо говорить с фаундерами, смотреть на команду, на предметную область и так далее.
На что еще смотреть при выборе работы
После того, как базовые вопросы закрыты, следует посмотреть, собственно на то, чем контора занимается.
Я уже писал об этичности работы. В целом, я бы скорее не уделял большого внимания предметной области. Конечно, большая удача, если вы нашли проект, который вам реально интересен, но в большинстве случаев это будет не так. Я много лет пилил вообще не всравшиеся мне ERP для телекомов, потом пару лет порталы недвижимости—тоже такое, до сейчас пилю инструменты для промоакций irl—такое, в databand уже год занимаюсь мониторингом процессов для датасаенс/ml команд—±ок.
Современная экономика активно борется за внимание человека, поэтому вполне вероятно что вам нужно будет заниматься около-рекламой, залипаловом и другими интересными и нужными миру вещами.
Мне в конце-концов рано или поздно всё надоедает, поэтому я бы смотрел на сложность и спектр задач. Есть ли "хайлоад"? B2B или B2C? Какие еще есть технологии на проекте, можно ли будет заниматься resume-driven разработкой? Есть ли пространство для принятия решений или "все уже сделано до нас"? Есть ли продакшн (лучше если он вот-вот будет и вы поучаствуете, хотя тут есть риск никогда не дождаться).
Куда бы скорее всего не шёл—так это к аутсорсерам на гринфилд проекты (когда компания выиграла заказ и теперь собирает под него команду)—тут есть риск не получить ожидаемое. Да и вообще бы к аутсорсерам не шёл :)
Как и в случае с рецептом успешного найма, работает и обратная зависимость—идти работать к знакомым. Пошерстите по одногруппникам и экс-коллегам, может кто-то из них как раз работает в хорошем месте?
Гигенические факторы должны быть на месте—зарплата, рабочее железо и место, офис или коворкинг, чай, печенье, страховка, зал—you name it. Плохой знак, если компания экономит на гигиене.
Ну а дальше нужно смотреть на людей которые вас берут и тренировать интуицию через опыт. Пяток лет назад мне легко было можно навешать разной лапши на уши, сейчас я уже немного насобачился детектить булшит.
В остальном—опыт решает.
После того, как базовые вопросы закрыты, следует посмотреть, собственно на то, чем контора занимается.
Я уже писал об этичности работы. В целом, я бы скорее не уделял большого внимания предметной области. Конечно, большая удача, если вы нашли проект, который вам реально интересен, но в большинстве случаев это будет не так. Я много лет пилил вообще не всравшиеся мне ERP для телекомов, потом пару лет порталы недвижимости—тоже такое, до сейчас пилю инструменты для промоакций irl—такое, в databand уже год занимаюсь мониторингом процессов для датасаенс/ml команд—±ок.
Современная экономика активно борется за внимание человека, поэтому вполне вероятно что вам нужно будет заниматься около-рекламой, залипаловом и другими интересными и нужными миру вещами.
Мне в конце-концов рано или поздно всё надоедает, поэтому я бы смотрел на сложность и спектр задач. Есть ли "хайлоад"? B2B или B2C? Какие еще есть технологии на проекте, можно ли будет заниматься resume-driven разработкой? Есть ли пространство для принятия решений или "все уже сделано до нас"? Есть ли продакшн (лучше если он вот-вот будет и вы поучаствуете, хотя тут есть риск никогда не дождаться).
Куда бы скорее всего не шёл—так это к аутсорсерам на гринфилд проекты (когда компания выиграла заказ и теперь собирает под него команду)—тут есть риск не получить ожидаемое. Да и вообще бы к аутсорсерам не шёл :)
Как и в случае с рецептом успешного найма, работает и обратная зависимость—идти работать к знакомым. Пошерстите по одногруппникам и экс-коллегам, может кто-то из них как раз работает в хорошем месте?
Гигенические факторы должны быть на месте—зарплата, рабочее железо и место, офис или коворкинг, чай, печенье, страховка, зал—you name it. Плохой знак, если компания экономит на гигиене.
Ну а дальше нужно смотреть на людей которые вас берут и тренировать интуицию через опыт. Пяток лет назад мне легко было можно навешать разной лапши на уши, сейчас я уже немного насобачился детектить булшит.
В остальном—опыт решает.