Переключение раскладки клавиатуры 2
На маках есть еще одна проблема — дефолтные кириллические раскладки отличаются от тех, что на винде. В процессе гугления стандартной раскладки я попал на знаменитую типографскую раскладку Ильи Бирмана. Там помимо возврата знака вопроса на его законное место, добавлено еще куча всяких полезных штук, самой часто используемой из которых у меня есть длинное тире —. Искушённый читатель наверняка это заметил: разница между - – — очевидна, а я всегда использую длинное тире 🙂
Всякие типографские символы там забиты на комбинации
Никита же пошёл еще дальше, и модифицировал раскладку полностью — убрав необходимость использовать нажатие
Тупо, что многие вещи были сделаны как попало, никто не хочет/не может их заменить и огромное количество людей страдает, совершая каждый день неэффективные действия, а забота об эргономике своего места — это почему-то удел задротов (тех самых, которые покупают себе девайсы вроде Truly Ergonomic (https://trulyergonomic.com/store/index.php), или Kinesis (https://kinesis-ergo.com/products/#keyboards).
Ультимативным решением проблемы раскладок был бы переход на латинницу, но, при всех достоинствах этого решения, mne ono sovsem ne po dushe. Надо было переходить еще при союзе, тогда бы бы ок 🙂
На маках есть еще одна проблема — дефолтные кириллические раскладки отличаются от тех, что на винде. В процессе гугления стандартной раскладки я попал на знаменитую типографскую раскладку Ильи Бирмана. Там помимо возврата знака вопроса на его законное место, добавлено еще куча всяких полезных штук, самой часто используемой из которых у меня есть длинное тире —. Искушённый читатель наверняка это заметил: разница между - – — очевидна, а я всегда использую длинное тире 🙂
Всякие типографские символы там забиты на комбинации
alt+символ и тут мне пришла в голову другая мысль — наверняка ведь можно забить в одну раскладку дополнительные символы — і, ї, ґ, є, чтобы не держать две кириллических раскладки. Оказалось что эту задачу до меня же решили, и я каким-то образом нагуглил раскладку Бирмана с добавленными нужными символами на хабре (https://habr.com/ru/post/130471/) установил и был таков! Наверняка есть похожие решения для винды, так что если вы вдруг страдаете от трёхъязычности срочно избавляйтесь.Никита же пошёл еще дальше, и модифицировал раскладку полностью — убрав необходимость использовать нажатие
shift для печати запятой и точки (https://tonsky.livejournal.com/318571.html). Это следующий этап, я до него пока не добрался, потому что привычка очень сильна, но обязательно буду пробовать.Тупо, что многие вещи были сделаны как попало, никто не хочет/не может их заменить и огромное количество людей страдает, совершая каждый день неэффективные действия, а забота об эргономике своего места — это почему-то удел задротов (тех самых, которые покупают себе девайсы вроде Truly Ergonomic (https://trulyergonomic.com/store/index.php), или Kinesis (https://kinesis-ergo.com/products/#keyboards).
Ультимативным решением проблемы раскладок был бы переход на латинницу, но, при всех достоинствах этого решения, mne ono sovsem ne po dushe. Надо было переходить еще при союзе, тогда бы бы ок 🙂
Вакансии в поверпоинте
Время вот времени получаю от рекрутёров предложения в виде ссылки на документ с вакансией.
Часто это гугл-док на страничку — удобно для рекрутёра и для нанимателя, они могут одновременно редактировать вакансию и не нужно перекидываться друг в друга правками в мессенджерах и почте — сам так делал. Неудобно для кандидата — открывать ссылку, читать чё-то там, что за дичь?
Абсолютно все(!) требования к любым вакансиям легко умещаются в абзац-другой неформатированного текста и могут быть озвучены еще в первом сообщении от рекрутёра, но это же слишком просто для такой тонкой вещи как найм околотехнарей и мозг начинает работать в стремлении раскатать потенциальных кандидатов оригинальностью подачи.
Особенно меня радуют такие порождения корпоративного мира как презентации. Духота переговорки, человек с лазерной указкой монотонно вещающий что-то, люди втыкающие в телефоны, постоянно обрывающаяся телеконференция, "коллеги мы все on the same page?", бессмысленные графики и обязательный фирменный стиль на презентации мутным потоком выплескиваются на меня прямо из монитора и погружают сознание в кошмар где 4 таких митинга в день с интервалом в час, на всех нужно обязательно быть, а на некоторые нужно готовить презентацию самому.
Итак, что же нас ждет в этой славной отрыжке корпоративного червя ловко владеющего основным инструментом убеждения окружающих в собственной ценности?
- прикольная картинка и название компании. Работать в нашей компании — большая честь!
- фотки руководителей/основателей этой славной конторы с краткими биографиями каждого. Очень важная информация.
- традиционный безликий булщит про миссию компании, революционный продукт, дизраптив технолоджи. Иногда фоточки офиса.
- три слова о проекте и пять буллитов про компетитив салари и медстраховку с залом
- требования к вакансии! Ура!
- слайд Thank You и контакты. Спасибо, что доехал до этого слайда и живой! Стресс-тест кандидата прямо во время чтения вакансии.
Все это сопровождается стильными иконками, большим количеством буллитов, отсутствием хоть какой-то консистентности в форматировании текста, мелким шрифтом и традиционными иллюстрациями улыбающихся людей из фотостоков.
Не уверен, как такой способ подачи материала влияет на конверсию, но я бы на вашем месте задумался о том, нужно ли идти работать в компанию, которая даже кучку требований не может оформить без поверпоинта.
Время вот времени получаю от рекрутёров предложения в виде ссылки на документ с вакансией.
Часто это гугл-док на страничку — удобно для рекрутёра и для нанимателя, они могут одновременно редактировать вакансию и не нужно перекидываться друг в друга правками в мессенджерах и почте — сам так делал. Неудобно для кандидата — открывать ссылку, читать чё-то там, что за дичь?
Абсолютно все(!) требования к любым вакансиям легко умещаются в абзац-другой неформатированного текста и могут быть озвучены еще в первом сообщении от рекрутёра, но это же слишком просто для такой тонкой вещи как найм околотехнарей и мозг начинает работать в стремлении раскатать потенциальных кандидатов оригинальностью подачи.
Особенно меня радуют такие порождения корпоративного мира как презентации. Духота переговорки, человек с лазерной указкой монотонно вещающий что-то, люди втыкающие в телефоны, постоянно обрывающаяся телеконференция, "коллеги мы все on the same page?", бессмысленные графики и обязательный фирменный стиль на презентации мутным потоком выплескиваются на меня прямо из монитора и погружают сознание в кошмар где 4 таких митинга в день с интервалом в час, на всех нужно обязательно быть, а на некоторые нужно готовить презентацию самому.
Итак, что же нас ждет в этой славной отрыжке корпоративного червя ловко владеющего основным инструментом убеждения окружающих в собственной ценности?
- прикольная картинка и название компании. Работать в нашей компании — большая честь!
- фотки руководителей/основателей этой славной конторы с краткими биографиями каждого. Очень важная информация.
- традиционный безликий булщит про миссию компании, революционный продукт, дизраптив технолоджи. Иногда фоточки офиса.
- три слова о проекте и пять буллитов про компетитив салари и медстраховку с залом
- требования к вакансии! Ура!
- слайд Thank You и контакты. Спасибо, что доехал до этого слайда и живой! Стресс-тест кандидата прямо во время чтения вакансии.
Все это сопровождается стильными иконками, большим количеством буллитов, отсутствием хоть какой-то консистентности в форматировании текста, мелким шрифтом и традиционными иллюстрациями улыбающихся людей из фотостоков.
Не уверен, как такой способ подачи материала влияет на конверсию, но я бы на вашем месте задумался о том, нужно ли идти работать в компанию, которая даже кучку требований не может оформить без поверпоинта.
Зарплата джуна
Сколько денег платить джуну? Сколько денег просить джуну?
Я был (и являюсь, лол) сооснователем небольшой аутсорс шлюпки на 10 гребцов (в пике, сейчас уже почти никого не осталось). Большинство из них были джунами, которых я брал вообще без опыта работы.
Сколько же платить таким ребятам?
Джун — в первую очередь затраты для компании. Наиболее ценный ресурс, который они отъедают — это время более квалифицированных специалистов. Первые несколько месяцев любой джун работает в минус, потому что задачи которые раньше делались быстро и качественно теперь делаются медленно и не очень (требуют правок) или не делаются вообще. Что джун получает взамен? А взамен он получает ценнейший опыт работы над реальным, нужным бизнесу проектом, опыт работы в команде и самое главное — заветную строчку в резюме и возможность рассказать следующему работодателю, над чем и как работал, без необходимости врать.
Человек получает путёвку в мир больших возможностей. Ведь если удастся закрепиться, то даже плохонький программист рано или поздно будет иметь свои полторы-две тысячи и сможет вести вполне нормальное существование без необходимости тяжело горбатиться.
Я убежден, что когда беру на работу людей без опыта, то оказываю им значительно большую услугу, нежели они — мне, но, даже несмотря на это, всякий труд должен оплачиваться. Ни в коем случае не работайте бесплатно и не нанимайте людей на проекты бесплатно. Всем надо платить, пусть даже немного.
И именно поэтому я считаю что денег джун должен получать ровно столько, чтобы не помереть с голоду. В киевских реалиях это примерно 300-400$. Взамен я не требую лояльности и чётко понимаю, что ушлый парень/девушка уже через полгода озаботится вопросом повышения зарплаты и есть риск, что он от меня уйдет, если я не соглашусь с его аппетитами, или не буду достаточно убедительным, чтобы он продолжал работать за мелкий прайс.
Через год джун должен как-то выходить на планку в 1000$. Если для меня он будет ценным — ок, я буду платить такие деньги. Если нет — ну что ж, бизнес есть бизнес, рынок есть рынок, вперед, я только порадуюсь за человека.
Сколько просить денег джуну? Вот минимум 300-400$ и просите. А вообще, как правило на таких позициях особо не торгуются и в компании уже есть фиксированная планка, с которой начинают все. Через пол-года в любом случае пора начинать ходить по собесам и присматриваться в другим конторам. У меня есть знакомый который за 3 года поднялся до 3 с хвостиком тысяч, при этом парень вовсе не экстраординарная личность. Просто хороший разработчик, вовремя менял конторы и умело торговался.
Не стыдно работать за мелкий прайс. Стыдно продолжать получать мелкий прайс через год.
Сколько денег платить джуну? Сколько денег просить джуну?
Я был (и являюсь, лол) сооснователем небольшой аутсорс шлюпки на 10 гребцов (в пике, сейчас уже почти никого не осталось). Большинство из них были джунами, которых я брал вообще без опыта работы.
Сколько же платить таким ребятам?
Джун — в первую очередь затраты для компании. Наиболее ценный ресурс, который они отъедают — это время более квалифицированных специалистов. Первые несколько месяцев любой джун работает в минус, потому что задачи которые раньше делались быстро и качественно теперь делаются медленно и не очень (требуют правок) или не делаются вообще. Что джун получает взамен? А взамен он получает ценнейший опыт работы над реальным, нужным бизнесу проектом, опыт работы в команде и самое главное — заветную строчку в резюме и возможность рассказать следующему работодателю, над чем и как работал, без необходимости врать.
Человек получает путёвку в мир больших возможностей. Ведь если удастся закрепиться, то даже плохонький программист рано или поздно будет иметь свои полторы-две тысячи и сможет вести вполне нормальное существование без необходимости тяжело горбатиться.
Я убежден, что когда беру на работу людей без опыта, то оказываю им значительно большую услугу, нежели они — мне, но, даже несмотря на это, всякий труд должен оплачиваться. Ни в коем случае не работайте бесплатно и не нанимайте людей на проекты бесплатно. Всем надо платить, пусть даже немного.
И именно поэтому я считаю что денег джун должен получать ровно столько, чтобы не помереть с голоду. В киевских реалиях это примерно 300-400$. Взамен я не требую лояльности и чётко понимаю, что ушлый парень/девушка уже через полгода озаботится вопросом повышения зарплаты и есть риск, что он от меня уйдет, если я не соглашусь с его аппетитами, или не буду достаточно убедительным, чтобы он продолжал работать за мелкий прайс.
Через год джун должен как-то выходить на планку в 1000$. Если для меня он будет ценным — ок, я буду платить такие деньги. Если нет — ну что ж, бизнес есть бизнес, рынок есть рынок, вперед, я только порадуюсь за человека.
Сколько просить денег джуну? Вот минимум 300-400$ и просите. А вообще, как правило на таких позициях особо не торгуются и в компании уже есть фиксированная планка, с которой начинают все. Через пол-года в любом случае пора начинать ходить по собесам и присматриваться в другим конторам. У меня есть знакомый который за 3 года поднялся до 3 с хвостиком тысяч, при этом парень вовсе не экстраординарная личность. Просто хороший разработчик, вовремя менял конторы и умело торговался.
Не стыдно работать за мелкий прайс. Стыдно продолжать получать мелкий прайс через год.
Идеальный джун
За свою карьеру я нанял большое количество нулячих джунов (без предыдущего опыта). Человек 20 точно будет, не меньше, а то и все 30. Соответственно просмотрел я далеко за сотню разных людей. Довольно давно я сформировал как говорят на западе highly opinionated профиль кандидата согласно которому я автоматически дискриминирую и отсекаю целую толпу народа. Кто же это?
— Обязательно студент/ка 3-5 очного курса профильного технического факультета. Разнообразные АСУ, ВТ, АУТС, кибернетики, автоматики, безопасность и прочие компьютерные науки. В принципе дальше можно не продолжать 🙂 но разберем по полочкам:
- Раз студент, значит парттаймщик. Это очень важно. Кто-то может думать что парттаймщик будет меньше работать, но на самом деле это не так. Человек который работает пол-дня будет эти пол-дня проводить сфокусированно над нужными задачами, а не смотреть мемасы. Чем меньше времени — тем более эффективно оно расходуется, тем проще отслеживать и контролировать прогресс. Непредсказуемость посещений делает ваш процесс более устойчивым, такой себе chaos engineering. Важно чтобы человек мог работать не меньше 20 часов в неделю — это необходимый минимум, из моей практики.
- Второй плюс парттайма — человек гарантированно задержится на подольше. Минимум на год, а это значит, что за это время он уже успеет нанести пользу и может быть даже выйдет на самоокупаемость.
- Раз студент, значит живет в общаге или с родителями. Соответственно, его будут меньше волновать деньги и больше — знания и опыт. Нет, есть конечно и меркантильные люди, но это не сравнить с взрослым человеком, у которого семья и дети, и которому вышеупомянутых 300 баксов явно будет маловато. С олдовыми дядями не связываемся.
- Профильный факультет гарантирует наличие хоть каких-то базовых знаний алгоритмов и адекватное знание одного, а то и двух языков программирования. Согласно моему опыту, все технари на старте просто на голову выше гуманитариев. Как правило у человека не возникает проблем повертеть деревьями или связными списками с рекурсиями, а значит и с вашими формочками он тоже справится. Бывают конечно и гуманитарии-самородки, но среди технарей таких больше.
- Идеальный джун уже с горем пополам знает парочку фреймворков/библиотек — spring/rails/react/angular/express/etc.
- Правильные друзья и одногруппники, мотивирующее окружение. Нетворкинг — это всегда хорошо. Наш джун может как привести своих друзей, так и уйти к ним 🙂
За свою карьеру я нанял большое количество нулячих джунов (без предыдущего опыта). Человек 20 точно будет, не меньше, а то и все 30. Соответственно просмотрел я далеко за сотню разных людей. Довольно давно я сформировал как говорят на западе highly opinionated профиль кандидата согласно которому я автоматически дискриминирую и отсекаю целую толпу народа. Кто же это?
— Обязательно студент/ка 3-5 очного курса профильного технического факультета. Разнообразные АСУ, ВТ, АУТС, кибернетики, автоматики, безопасность и прочие компьютерные науки. В принципе дальше можно не продолжать 🙂 но разберем по полочкам:
- Раз студент, значит парттаймщик. Это очень важно. Кто-то может думать что парттаймщик будет меньше работать, но на самом деле это не так. Человек который работает пол-дня будет эти пол-дня проводить сфокусированно над нужными задачами, а не смотреть мемасы. Чем меньше времени — тем более эффективно оно расходуется, тем проще отслеживать и контролировать прогресс. Непредсказуемость посещений делает ваш процесс более устойчивым, такой себе chaos engineering. Важно чтобы человек мог работать не меньше 20 часов в неделю — это необходимый минимум, из моей практики.
- Второй плюс парттайма — человек гарантированно задержится на подольше. Минимум на год, а это значит, что за это время он уже успеет нанести пользу и может быть даже выйдет на самоокупаемость.
- Раз студент, значит живет в общаге или с родителями. Соответственно, его будут меньше волновать деньги и больше — знания и опыт. Нет, есть конечно и меркантильные люди, но это не сравнить с взрослым человеком, у которого семья и дети, и которому вышеупомянутых 300 баксов явно будет маловато. С олдовыми дядями не связываемся.
- Профильный факультет гарантирует наличие хоть каких-то базовых знаний алгоритмов и адекватное знание одного, а то и двух языков программирования. Согласно моему опыту, все технари на старте просто на голову выше гуманитариев. Как правило у человека не возникает проблем повертеть деревьями или связными списками с рекурсиями, а значит и с вашими формочками он тоже справится. Бывают конечно и гуманитарии-самородки, но среди технарей таких больше.
- Идеальный джун уже с горем пополам знает парочку фреймворков/библиотек — spring/rails/react/angular/express/etc.
- Правильные друзья и одногруппники, мотивирующее окружение. Нетворкинг — это всегда хорошо. Наш джун может как привести своих друзей, так и уйти к ним 🙂
Почему нужно нанимать джунов
Я горячий сторонник найма джунов. Нанимал кучу джунов когда работал в большой корпорации, а потом нанимал уже к себе в компанию и платил им из своего кармана. Сейчас не нанимаю, потому что работаю практически сам, да и карманы опустели 😄
Убежден, что любая контора, которая зарабатывает хоть какое-то бабло просто обязана нанимать джунов, и вот почему.
- Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными. Чем больше препятствий на пути к продакшн серверу — тем лучше.
- Делегация рутинных задач и тех долга. Через пару месяцев обучения джун уже легко должен щелкать простые задачи до которых не доходили руки и разнообразный мелких тех долг. Понятное дело что переписать все с нуля никто не даст, но разгрузить инженеров от всякой мелкой ерунды и сделать множество несложных, но полезных для пользователей фич — изи.
- Улучшение качества документации, скорости введения нового человека в проект и прочих инфраструктурных вещей. Каждый новый джун будет повторять одни и те же шаги по первичной настройке окружения. Если первый раз еще можно объяснить на пальцах, то дальше грамотный специалист просто напишет доку/скрипты/внедрит билдсистему и так далее. А можно вообще посадить писать эту доку самого джуна.
- Далеко не последняя по значимости в этом списке — социальная миссия. Да, я лично готов терпеть (и терпел) убытки просто потому, что считаю важным давать путёвку в безбедную жизнь людям. Приятно видеть толкового специалиста, который вырастает на твоих глазах.
- Прокачивание менторских и лидерских скиллов внутри команды. Первый шаг как сделать из человека сеньера помидора — выдать ему пару джунов на обучение. А там глядишь уже и до тимлида недалеко.
Главное в этом всём счастье — сохранять правильные пропорции джунов к не-джунам, иначе глиняный колосс рискует развалиться под собственным весом 🙂
Я горячий сторонник найма джунов. Нанимал кучу джунов когда работал в большой корпорации, а потом нанимал уже к себе в компанию и платил им из своего кармана. Сейчас не нанимаю, потому что работаю практически сам, да и карманы опустели 😄
Убежден, что любая контора, которая зарабатывает хоть какое-то бабло просто обязана нанимать джунов, и вот почему.
- Улучшение и формализация процессов. Когда у вас на борту не самые опытные бойцы, такие вещи как CI/CD, статические анализаторы кода, тесты, код ревью и автодеплой становятся просто обязательными. Чем больше препятствий на пути к продакшн серверу — тем лучше.
- Делегация рутинных задач и тех долга. Через пару месяцев обучения джун уже легко должен щелкать простые задачи до которых не доходили руки и разнообразный мелких тех долг. Понятное дело что переписать все с нуля никто не даст, но разгрузить инженеров от всякой мелкой ерунды и сделать множество несложных, но полезных для пользователей фич — изи.
- Улучшение качества документации, скорости введения нового человека в проект и прочих инфраструктурных вещей. Каждый новый джун будет повторять одни и те же шаги по первичной настройке окружения. Если первый раз еще можно объяснить на пальцах, то дальше грамотный специалист просто напишет доку/скрипты/внедрит билдсистему и так далее. А можно вообще посадить писать эту доку самого джуна.
- Далеко не последняя по значимости в этом списке — социальная миссия. Да, я лично готов терпеть (и терпел) убытки просто потому, что считаю важным давать путёвку в безбедную жизнь людям. Приятно видеть толкового специалиста, который вырастает на твоих глазах.
- Прокачивание менторских и лидерских скиллов внутри команды. Первый шаг как сделать из человека сеньера помидора — выдать ему пару джунов на обучение. А там глядишь уже и до тимлида недалеко.
Главное в этом всём счастье — сохранять правильные пропорции джунов к не-джунам, иначе глиняный колосс рискует развалиться под собственным весом 🙂
Вранье на собесах
Несколько лет назад одна моя знакомая решила пойти на вайти курсы QA.
Курсы как курсы, учили там джире, аджайл процессам и написанию тест-кейсов. В конце был экзамен, включающий в себя теорию и практику (написать тест-кейс) по итогам которого слушателям давали сертификат.
А дальше начиналось самое интересное — особо отличившихся обещали взять в дальнейший оборот и помочь с трудоустройством. Моя знакомая отличилась и ей лично написал один из тренеров со следующим предложением — она платит некую сумму денег, а он тратит время на то, чтобы тщательно подготовить её к собеседованиям и провести еще один экзамен. Если она проваливает экзамен — то нужно платить еще раз.
Один из её одногруппников решил идти дальше и там вскрылся неожиданный сюрприз — оказывается, подготовка к собеседованию заключалась в заучивании "предыдущего опыта". Человеку, как заправскому шпиону, выдавали легенду, согласно которой он уже два года как работал тестировщиком на определенном проекте, с таким-то продуктом, по таким-то методологиям. Нужно было заучить все это дело, дальше пройти тестовое "собеседование" с одним из тренеров и после того, как они решали что можно отпускать тебя в свободное плавание, идти в настоящие конторы.
Уже потом я узнал что это распространённая практика на курсах, особенно тестировщиков. Стоит ли говорить, что любой нормальный специалист довольно быстро распознает вранье, ведь не может человек вообще без опыта просто так сэмулировать два года работы на реальном проекте. Ну а кандидат подвергает себя риску занесения в локальные чёрные списки (хотя я и не особо верю в их существование). И как-то с коллегами надо потом разговаривать, где раньше работал, что делал? А вдруг найдется кто-то из той фирмы, кто работал в тот же период?
Очевидно, врать на собесах не стоит. Наверное, раз курсы такое практикуют, то этот способ имеет какую-то эффективность и люди как-то устраиваются, особенно в большие конторы, где набирают много и не так тщательно, как в мелких. Но я бы такой способ не советовал.
Несколько лет назад одна моя знакомая решила пойти на вайти курсы QA.
Курсы как курсы, учили там джире, аджайл процессам и написанию тест-кейсов. В конце был экзамен, включающий в себя теорию и практику (написать тест-кейс) по итогам которого слушателям давали сертификат.
А дальше начиналось самое интересное — особо отличившихся обещали взять в дальнейший оборот и помочь с трудоустройством. Моя знакомая отличилась и ей лично написал один из тренеров со следующим предложением — она платит некую сумму денег, а он тратит время на то, чтобы тщательно подготовить её к собеседованиям и провести еще один экзамен. Если она проваливает экзамен — то нужно платить еще раз.
Один из её одногруппников решил идти дальше и там вскрылся неожиданный сюрприз — оказывается, подготовка к собеседованию заключалась в заучивании "предыдущего опыта". Человеку, как заправскому шпиону, выдавали легенду, согласно которой он уже два года как работал тестировщиком на определенном проекте, с таким-то продуктом, по таким-то методологиям. Нужно было заучить все это дело, дальше пройти тестовое "собеседование" с одним из тренеров и после того, как они решали что можно отпускать тебя в свободное плавание, идти в настоящие конторы.
Уже потом я узнал что это распространённая практика на курсах, особенно тестировщиков. Стоит ли говорить, что любой нормальный специалист довольно быстро распознает вранье, ведь не может человек вообще без опыта просто так сэмулировать два года работы на реальном проекте. Ну а кандидат подвергает себя риску занесения в локальные чёрные списки (хотя я и не особо верю в их существование). И как-то с коллегами надо потом разговаривать, где раньше работал, что делал? А вдруг найдется кто-то из той фирмы, кто работал в тот же период?
Очевидно, врать на собесах не стоит. Наверное, раз курсы такое практикуют, то этот способ имеет какую-то эффективность и люди как-то устраиваются, особенно в большие конторы, где набирают много и не так тщательно, как в мелких. Но я бы такой способ не советовал.
О стеклянном потолке 3. Оффлайновый бизнес
Предыдущие части: первая (https://xn--r1a.website/full_of_hatred/42), вторая (https://xn--r1a.website/full_of_hatred/43).
Многие люди ненадолго погрузившись в сладкие обещания, которые нам вещают со страниц книг, буллитов презентаций, сцен залов всевозможные бизнес-тренеры, рано или поздно задумываются о своем деле. В качестве такого "своего" дела часто выбирается какое-то оффлайновое предприятие — магазинчик китайского барахла, фургончик с фастфудом, СТО или похожие активности. Будущие бизнесмены мечтают о том, как они вложат десяток тысяч баксов, поставят все процессы на поток, а сами укатят на #сказочноебали лежать на пляже и любоваться закатами.
По-моему мнению, если вы околоразработчик, то заниматься таким однозначно не стоит, и вот почему.
В 2010 году нам предложили вложиться в такое предприятие — оффлайн магазин зоотоваров. Пораскинув мозгами и найдя в закромах $10k мы решили вписаться. Long story short: спустя 5 лет все точки, которые у нас были, закрылись.
Самый большой недостаток оффлайновых штук как раз и заключается в том, что они, собственно оффлайновые. Товар может испортиться, его нужно где-то хранить. Его могут забрать или украсть. Его могут не купить и тогда придется что-то делать с остатками. Нужно арендовать место для точки продаж и склад. Заниматься логистикой доставки товара туда-сюда и поставщиками. Иметь дело с многочисленными контролирующими органами. Контролировать сотрудников. Заниматься складским учётом и осваивать 1С.
В итоге, очень большую часть времени забирают на себя не слишком интеллектуальные операционные заботы. Часть из них можно делегировать, часть как-то автоматизировать, но все равно не получится просто вложить деньги и сидеть, смотреть как они капают на счет.
Чтобы понять, насколько это невыгодное дело, достаточно посмотреть на ротацию лавочников, которые арендуют ларьки возле метро — по моим прикидкам, большая их часть сменяется раз в 3 месяца. Стабильно выживают и долго существуют дешевые наливайки, сухофрукты и шаурма, игровые автоматы. Все остальное загибается довольно быстро.
Безусловно, есть люди, которые уверенно чувствуют себя на поприще ритейла и всяких похожих штук. Но если вы девелопер — лучше сфокусироваться на том, что вы умеете делать лучше всего — писать софт. Цифровые ассеты у вас никто не заберет, не украдет, они не испортятся, их не нужно хранить, не нужно закупать, ездить на склады, забирать и везти, не нужно думать что делать с нераспроданными остатками. Люди сейчас готовы платить за любую дичь, а скорость запуска MVP — довольно высокая чтобы заниматься этим параллельно основной работе.
Предыдущие части: первая (https://xn--r1a.website/full_of_hatred/42), вторая (https://xn--r1a.website/full_of_hatred/43).
Многие люди ненадолго погрузившись в сладкие обещания, которые нам вещают со страниц книг, буллитов презентаций, сцен залов всевозможные бизнес-тренеры, рано или поздно задумываются о своем деле. В качестве такого "своего" дела часто выбирается какое-то оффлайновое предприятие — магазинчик китайского барахла, фургончик с фастфудом, СТО или похожие активности. Будущие бизнесмены мечтают о том, как они вложат десяток тысяч баксов, поставят все процессы на поток, а сами укатят на #сказочноебали лежать на пляже и любоваться закатами.
По-моему мнению, если вы околоразработчик, то заниматься таким однозначно не стоит, и вот почему.
В 2010 году нам предложили вложиться в такое предприятие — оффлайн магазин зоотоваров. Пораскинув мозгами и найдя в закромах $10k мы решили вписаться. Long story short: спустя 5 лет все точки, которые у нас были, закрылись.
Самый большой недостаток оффлайновых штук как раз и заключается в том, что они, собственно оффлайновые. Товар может испортиться, его нужно где-то хранить. Его могут забрать или украсть. Его могут не купить и тогда придется что-то делать с остатками. Нужно арендовать место для точки продаж и склад. Заниматься логистикой доставки товара туда-сюда и поставщиками. Иметь дело с многочисленными контролирующими органами. Контролировать сотрудников. Заниматься складским учётом и осваивать 1С.
В итоге, очень большую часть времени забирают на себя не слишком интеллектуальные операционные заботы. Часть из них можно делегировать, часть как-то автоматизировать, но все равно не получится просто вложить деньги и сидеть, смотреть как они капают на счет.
Чтобы понять, насколько это невыгодное дело, достаточно посмотреть на ротацию лавочников, которые арендуют ларьки возле метро — по моим прикидкам, большая их часть сменяется раз в 3 месяца. Стабильно выживают и долго существуют дешевые наливайки, сухофрукты и шаурма, игровые автоматы. Все остальное загибается довольно быстро.
Безусловно, есть люди, которые уверенно чувствуют себя на поприще ритейла и всяких похожих штук. Но если вы девелопер — лучше сфокусироваться на том, что вы умеете делать лучше всего — писать софт. Цифровые ассеты у вас никто не заберет, не украдет, они не испортятся, их не нужно хранить, не нужно закупать, ездить на склады, забирать и везти, не нужно думать что делать с нераспроданными остатками. Люди сейчас готовы платить за любую дичь, а скорость запуска MVP — довольно высокая чтобы заниматься этим параллельно основной работе.
Производительность веб-сервисов
До сих пор люди иногда спорят о скорости программ, написанных на том или ином языке или платформе. Хотя тренд значительно пошел на убыль и редко где услышишь "Java тормозит" или "1 000 000 конкуррентных подключений на node.js" но время от времени все равно этот вопрос подымается.
Так вот.
У меня в продакшене уже несколько лет крутится куча сервисов, часть на JVM, часть на Rails, часть на Python, часть на PHP, парочка на node.
80% (а то и все 99%) проблем с производительностью ваших и моих приложений связаны с I/O, и никак не связаны с тормознутностью интерпретатора отдельно взятого языка. Если вы не гугл конечно. А вы — не гугл.
Так или иначе все упирается в базу данных, и скорость выполнения запросов. В большой корпорации где я раньше работал, сидел целый отдел (человек 50, не меньше), специальных людей, которые занимались тюнингом SQL-запросов. Каждый день, с утра до вечера. Переписывали говна, которые понаворотили обычные девелоперы, добавляли эзотерические оракловые хинты и все начинало быстро работать.
Ruby on Rails известен своей медленностью во всяких модных бенчмарках. И действительно — интерпретатор медленный по сравнению с JVM или node, а фреймворк наворачивает поверх этого кучу барахла которое еще больше замедляет время ответа. Да вот только вся скорость JVM-приложений так или иначе упирается в (No)SQL-запросы и сетевое взаимодействие.
Поэтому при выборе платформы на перформенс языка следует строго забить и взамен сосредоточиться на удобстве разработки, богатстве библиотек и инфраструктуры и на архитектуре структур данных и запросов к ним.
Ruby тормозит? Да плевать, зато я за 5 минут подыму работающее АРІ, пока вы будете импортировать build.gradle в IntelliJ.
Туда же NoSQL барахло. Современные базы работают очень бодро, поэтому постгреса хватит всем. Ту да же микросервисы, но это отдельный разговор 🙂
И только когда наш продукт полетит, навалится пользователей и появится больше данных, вот только тогда можно (и нужно) смотреть, есть ли что-то, что уже нельзя оптимизировать без смены платформы и утолщения серверов. Но скорее всего, это случится очень не скоро 🙂
До сих пор люди иногда спорят о скорости программ, написанных на том или ином языке или платформе. Хотя тренд значительно пошел на убыль и редко где услышишь "Java тормозит" или "1 000 000 конкуррентных подключений на node.js" но время от времени все равно этот вопрос подымается.
Так вот.
У меня в продакшене уже несколько лет крутится куча сервисов, часть на JVM, часть на Rails, часть на Python, часть на PHP, парочка на node.
80% (а то и все 99%) проблем с производительностью ваших и моих приложений связаны с I/O, и никак не связаны с тормознутностью интерпретатора отдельно взятого языка. Если вы не гугл конечно. А вы — не гугл.
Так или иначе все упирается в базу данных, и скорость выполнения запросов. В большой корпорации где я раньше работал, сидел целый отдел (человек 50, не меньше), специальных людей, которые занимались тюнингом SQL-запросов. Каждый день, с утра до вечера. Переписывали говна, которые понаворотили обычные девелоперы, добавляли эзотерические оракловые хинты и все начинало быстро работать.
Ruby on Rails известен своей медленностью во всяких модных бенчмарках. И действительно — интерпретатор медленный по сравнению с JVM или node, а фреймворк наворачивает поверх этого кучу барахла которое еще больше замедляет время ответа. Да вот только вся скорость JVM-приложений так или иначе упирается в (No)SQL-запросы и сетевое взаимодействие.
Поэтому при выборе платформы на перформенс языка следует строго забить и взамен сосредоточиться на удобстве разработки, богатстве библиотек и инфраструктуры и на архитектуре структур данных и запросов к ним.
Ruby тормозит? Да плевать, зато я за 5 минут подыму работающее АРІ, пока вы будете импортировать build.gradle в IntelliJ.
Туда же NoSQL барахло. Современные базы работают очень бодро, поэтому постгреса хватит всем. Ту да же микросервисы, но это отдельный разговор 🙂
И только когда наш продукт полетит, навалится пользователей и появится больше данных, вот только тогда можно (и нужно) смотреть, есть ли что-то, что уже нельзя оптимизировать без смены платформы и утолщения серверов. Но скорее всего, это случится очень не скоро 🙂
О работе над продуктом
Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов.
На старой работе у нас был такой термин "продуктизация". Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации. А если уж и брать что-то — то думать, как сделать фичу как можно более универсальной.
Вся эта штука здорово профдеформирует личность. Теперь я не могу просто так взять и закодить что-нибудь жестко под спецификации, даже если понятно что проект одноразовый. Мозг непроизвольно начинает думать как бы сделать решение более гибким, какие сценарии предусмотреть, как бы это все генерализировать так, чтобы потом, когда, может быть, придут за доработкой, то сделать её не из говна и палок а изящно встроить в как раз подготовленное год назад место.
Впрочем, ожидания часто разбиваются о жестокую реальность и оказывается, что предусмотрели далеко не все, и уже в красивую архитектуру нужно добавлять немножко костылей, чтобы новая фича завелась.
С другой стороны, мне кажется, что для инженера это все-таки полезная привычка — продумывать сценарии использования как можно более общими, и строить решение с оглядкой на них. Естественно, везде важен баланс. Когда времени мало, то не до разработки фреймворков, захардкодили, чик чик и в продакшн. Так этот уродец и живет, пока не сменится поколение разработчиков, и новые ребята не сожгут все напалмом, поверху построив как им кажется на этот раз уже хорошее решение. Вот правда ожидает судьба предшественников...
Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.
А начиналось-то все просто, давайте увеличим лимит на 10 мегабайт? Поэтому я перехардкодил существующее значение. Будем проделывать правильную работу в следующий раз, когда потребуется изменение, градуируя улучшения.
Почти всю свою карьеру я так или иначе занят в продуктовой разработке. Помимо продуктов я делал собственно демо-проекты и разнообразные прототипы других продуктов.
На старой работе у нас был такой термин "продуктизация". Это когда бралось решение, сделанное кастомного под определенного заказчика, творчески переосмыслялось и впихивалось в продукт. Идея была в том, что эта кастомная функциональность могла бы пригодиться кому-нибудь в будущем. Одной из моих задач, как технического руководителя одного из продуктов, было отбиваться от запросов на такие всякие разные продуктизации. А если уж и брать что-то — то думать, как сделать фичу как можно более универсальной.
Вся эта штука здорово профдеформирует личность. Теперь я не могу просто так взять и закодить что-нибудь жестко под спецификации, даже если понятно что проект одноразовый. Мозг непроизвольно начинает думать как бы сделать решение более гибким, какие сценарии предусмотреть, как бы это все генерализировать так, чтобы потом, когда, может быть, придут за доработкой, то сделать её не из говна и палок а изящно встроить в как раз подготовленное год назад место.
Впрочем, ожидания часто разбиваются о жестокую реальность и оказывается, что предусмотрели далеко не все, и уже в красивую архитектуру нужно добавлять немножко костылей, чтобы новая фича завелась.
С другой стороны, мне кажется, что для инженера это все-таки полезная привычка — продумывать сценарии использования как можно более общими, и строить решение с оглядкой на них. Естественно, везде важен баланс. Когда времени мало, то не до разработки фреймворков, захардкодили, чик чик и в продакшн. Так этот уродец и живет, пока не сменится поколение разработчиков, и новые ребята не сожгут все напалмом, поверху построив как им кажется на этот раз уже хорошее решение. Вот правда ожидает судьба предшественников...
Вот сегодня приехала мне задача увеличить максимальный размер принимаемых определённым API файлов. Раньше ограничения не было, но какие-то ребята додумались слать видео по 50 мегабайт. Сделали ограничение в 10 мегабайт, хардкодом, потому что не было времени (или уже не помню почему). Сегодня оказалось что один из клиентов этого API присылает файлы по 11 мегабайт и здорово было бы лимит увеличить. Можно перехаркодить значение. Можно внести настройку в базу. Но тогда на каждый запрос надо ходить в базу, а это плохо. Значит нужно сверху навернуть кеширование. Хорошо. Но клиентов у API много и разных. Некоторые могут попросить оставить 10 MiB. Делать настройку per-application или per-customer? Если добавлять настройку то нужно добавлять поле в базу для этого клиента. Или записать в json-конфиг его подключения. Но если добавлять в json-конфиг, то нужно добавлять поля в классы(прости Господи) дто, нужно добавлять настройку в админку (которая написана отдельным приложением), добавлять валидацию, устаналивать дефолтное значение, мигрировать существующие конфиги на новые, с добавленным полем, добавлять код чтения настройки уже не из общесистемных настроек, а из конфига подключения...В общем работы на день есть точно.
А начиналось-то все просто, давайте увеличим лимит на 10 мегабайт? Поэтому я перехардкодил существующее значение. Будем проделывать правильную работу в следующий раз, когда потребуется изменение, градуируя улучшения.
Беспомощность
Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди.
За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить).
Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул. Как вдруг решили меня отправить на демо-проект (2-4 недели угарной разработки потемкинских деревень из говна и палок). Я уже на таких проектах бывал, но всегда работал со "своими" компонентами, которые я же поддерживал, или хотя бы знал. Но тут была совсем другая бизнес-область, суть была такова — интегрироваться с Network Discovery какого-то вендора сетевых железяк (Ericcson что ли? не помню), получать от них данные и на основании этих данных заводить у нас в системе карту устройств. Как-то так.
Цимес был в том, что для таких вещей в компании уже давно разработали продукт, и нужно было только его законфигурировать. А конфигурация производилась с помощью написания XSLT-трансформаций, о которых я впервые услышал как раз на этом проекте.
Часть команды поехала к заказчику в штаты, часть осталась в CIS. Из штатов коллега присылал мне задания и тестовые данные, я а пытался что-то из этого сделать. Получалось очень плохо. Среди сотрудников в комнате никто не работал с XSLT, скилл обучения и поиска тогда у меня был не очень хороший, а задания были довольно сложными, то есть hello world примеры не прокатывали. В общем в этот момент я и ощутил невероятную беспомощность, когда не к кому пойти, не у кого спросить, и нет времени обучаться, потому что демонстрации были прибиты гвоздями к определенным датам. Старший коллега, который выдавал задачи (собственно он и сидел в штатах) писал эти трансформации на раз-два, но я или не мог ничего понять из его примеров, или просто смотрел как он переделывал мои xmlины сокращая объем в несколько раз и попутно исправляя кучу багов. Я пытался воззвать к руководству и объяснить им что я ни черта не понимаю в этих штуках и им бы лучше найти толкового специалиста, а то щас все завалим, но был услышан не сразу и страдал пару недель. Щас то я бы наверное как-то на опыте бы выехал, а тогда было совсем плохо. Дему конечно же сделали, правда проект не стартанул.
Спустя годы уже я сам забыл каково это — быть беспомощными и поставил в такое же положение одного из джунов, которые у меня работали — дал ему задачу на распознавание текста на изображениях. Задача оказалась выше его возможностей, о чем он прямо заявлял, но я предлагал еще потыкать и попробовать разные штуки (мануалов в интернете по OCR куча же, чего сложного!). В итоге месяц времени он непостижимым образом выдержал, но удовлетворительного результата, очевидно, мы так и не добились, зато получили демотивированного товарища.
Старайтесь отслеживать такие состояния (только не надо их путать с нежеланием обучаться) и не попадать в них, а так же здраво оценивать возможности своих людей.
Обычно у разработчиков не возникает проблем с решением задач. Поисковики, стековерфлоу, куча мануалов, в принципе все типовые задачи уже давным-давно решены, а нетиповые — так их делают опытные люди.
За всю карьеру полностью прочувствовать свою беспомощность и неспособность справиться с задачей меня угораздило только один раз (ну и еще было много других мелких случаев, когда просто задача давалась тяжело, но удавалось как-то разрулить).
Дело было в 2009-2010 году — работал я значит в корпорации, подпиливал свой маленький (тогда) продукт, в ус не дул. Как вдруг решили меня отправить на демо-проект (2-4 недели угарной разработки потемкинских деревень из говна и палок). Я уже на таких проектах бывал, но всегда работал со "своими" компонентами, которые я же поддерживал, или хотя бы знал. Но тут была совсем другая бизнес-область, суть была такова — интегрироваться с Network Discovery какого-то вендора сетевых железяк (Ericcson что ли? не помню), получать от них данные и на основании этих данных заводить у нас в системе карту устройств. Как-то так.
Цимес был в том, что для таких вещей в компании уже давно разработали продукт, и нужно было только его законфигурировать. А конфигурация производилась с помощью написания XSLT-трансформаций, о которых я впервые услышал как раз на этом проекте.
Часть команды поехала к заказчику в штаты, часть осталась в CIS. Из штатов коллега присылал мне задания и тестовые данные, я а пытался что-то из этого сделать. Получалось очень плохо. Среди сотрудников в комнате никто не работал с XSLT, скилл обучения и поиска тогда у меня был не очень хороший, а задания были довольно сложными, то есть hello world примеры не прокатывали. В общем в этот момент я и ощутил невероятную беспомощность, когда не к кому пойти, не у кого спросить, и нет времени обучаться, потому что демонстрации были прибиты гвоздями к определенным датам. Старший коллега, который выдавал задачи (собственно он и сидел в штатах) писал эти трансформации на раз-два, но я или не мог ничего понять из его примеров, или просто смотрел как он переделывал мои xmlины сокращая объем в несколько раз и попутно исправляя кучу багов. Я пытался воззвать к руководству и объяснить им что я ни черта не понимаю в этих штуках и им бы лучше найти толкового специалиста, а то щас все завалим, но был услышан не сразу и страдал пару недель. Щас то я бы наверное как-то на опыте бы выехал, а тогда было совсем плохо. Дему конечно же сделали, правда проект не стартанул.
Спустя годы уже я сам забыл каково это — быть беспомощными и поставил в такое же положение одного из джунов, которые у меня работали — дал ему задачу на распознавание текста на изображениях. Задача оказалась выше его возможностей, о чем он прямо заявлял, но я предлагал еще потыкать и попробовать разные штуки (мануалов в интернете по OCR куча же, чего сложного!). В итоге месяц времени он непостижимым образом выдержал, но удовлетворительного результата, очевидно, мы так и не добились, зато получили демотивированного товарища.
Старайтесь отслеживать такие состояния (только не надо их путать с нежеланием обучаться) и не попадать в них, а так же здраво оценивать возможности своих людей.
Тьюринг-полные круды
В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений.
Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике.
Разработчик, задолбавшись реализовывать n-дцатое условие в коде, рано или поздно решает написать некую конфигурацию бизнес-правил обработки этих самых заказов, дать в руки бизнес-людям конфигуратор и свалить в закат. Вроде все просто, реализовал десяток блочков, как-то их собрал в кучку под каждый отдельный случай и все работает, можно пить смузи.
Но бизнес приходит с новыми требованиями. Там, где раньше были только составные условия типа ИЛИ теперь появляются И и НЕ. Там, где была последовательная обработка всех правил по очереди, теперь появляются ветвления и дополнительные условия.
Монстр обрастает кастомными обработчиками, спец-функциями, простым шаблонизатором с переменными... Это все дело нужно как-то поддерживать и дебажить и вот уже появляется расширенная система логирования, вначале для разработчиков, а потом уже и для бизнес-людей, чтобы они сами могли смотреть, почему их штука не работает как надо и не дергать девелоперов.
Ну и апофеозом этого дела будет встраивание скриптового языка (js/groovy и тд) в условия и действия. Цикл замкнулся. Поздравляю, ваш круд теперь тьюринг-полный.
Я наблюдал это и в больших проектах и в маленьких. Рано или поздно хардкода начинает не хватать, и разработка изобретает очередной велосипед, вначале беговел и потихоньку превращая это все дело в мотоцикл из безумного макса.
Готовых отчетов по данным не хватает, и вот аналитикам в руки уже дается база, SQL или BI-система куда разработчики сгружают подготовленные данные.
Множество промежуточных этапов казалось бы можно было бы и избежать, если начать разработку всех этих хитрых движков заранее, на старте проекта, да вот нет. Во-первых, громадный оверкилл, а во-вторых, все равно не угадаете, что понадобится.
В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений.
Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике.
Разработчик, задолбавшись реализовывать n-дцатое условие в коде, рано или поздно решает написать некую конфигурацию бизнес-правил обработки этих самых заказов, дать в руки бизнес-людям конфигуратор и свалить в закат. Вроде все просто, реализовал десяток блочков, как-то их собрал в кучку под каждый отдельный случай и все работает, можно пить смузи.
Но бизнес приходит с новыми требованиями. Там, где раньше были только составные условия типа ИЛИ теперь появляются И и НЕ. Там, где была последовательная обработка всех правил по очереди, теперь появляются ветвления и дополнительные условия.
Монстр обрастает кастомными обработчиками, спец-функциями, простым шаблонизатором с переменными... Это все дело нужно как-то поддерживать и дебажить и вот уже появляется расширенная система логирования, вначале для разработчиков, а потом уже и для бизнес-людей, чтобы они сами могли смотреть, почему их штука не работает как надо и не дергать девелоперов.
Ну и апофеозом этого дела будет встраивание скриптового языка (js/groovy и тд) в условия и действия. Цикл замкнулся. Поздравляю, ваш круд теперь тьюринг-полный.
Я наблюдал это и в больших проектах и в маленьких. Рано или поздно хардкода начинает не хватать, и разработка изобретает очередной велосипед, вначале беговел и потихоньку превращая это все дело в мотоцикл из безумного макса.
Готовых отчетов по данным не хватает, и вот аналитикам в руки уже дается база, SQL или BI-система куда разработчики сгружают подготовленные данные.
Множество промежуточных этапов казалось бы можно было бы и избежать, если начать разработку всех этих хитрых движков заранее, на старте проекта, да вот нет. Во-первых, громадный оверкилл, а во-вторых, все равно не угадаете, что понадобится.
👍1
Прогресс регресс
Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — "черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?".
Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — "ну все, в этот раз такой шляпы не будет", а нет, проходит год и опять понимаешь что делал дичь. Да, не такую, как 5 лет назад, например, но все равно дичь.
И так каждый год.
Где-то читал цитату, типа если ты не считаешь что год назад ты был дураком то ты не прогрессируешь. Может быть, может быть.
Согласно этому утверждению, прогрессировать у меня получается неплохо 😄
p.s. это не про майнинг битка в 2008 или другие околослучайнолотерейные вещи, "знал бы прикуп, жил бы в Сочи", нет. Это больше про осмысленную ежедневную рутину, работу, проекты и так далее.
Уже несколько лет подряд я ретроспективно оцениваю решения и поступки которые совершал в прошлом году. И каждый раз думаю — "черт, как я мог творить такую дичь? зачем я в это вписывался? зачем соглашался? почему не приложил больше усилий для?".
Что характерно, история повторяется каждый год. То есть вроде бы и думаешь — "ну все, в этот раз такой шляпы не будет", а нет, проходит год и опять понимаешь что делал дичь. Да, не такую, как 5 лет назад, например, но все равно дичь.
И так каждый год.
Где-то читал цитату, типа если ты не считаешь что год назад ты был дураком то ты не прогрессируешь. Может быть, может быть.
Согласно этому утверждению, прогрессировать у меня получается неплохо 😄
p.s. это не про майнинг битка в 2008 или другие околослучайнолотерейные вещи, "знал бы прикуп, жил бы в Сочи", нет. Это больше про осмысленную ежедневную рутину, работу, проекты и так далее.
Удаленная работа в офисе
В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира.
Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих. То есть ты спокойно мог годами вообще никак не пересекаться с коллегами из комнаты, где ты сидишь. В запущеном случае (саппорт например) мало того, что у тебя не было тиммейтов в твоем офисе, так еще и во всем постсовковом регионе.
То есть, на самом деле, это была самая настоящая удаленная работа. Только из офиса. При этом, компания не разрешала работать удаленно из дому (или разрешала но очень-очень ограниченно). Парадокс, да? Твой босс сидит в командировке уже больше полугода, ребята за соседними столами занимаются непонятно чем (или понятно чем, но это тебе фиолетово), но в офис все равно нужно ходить.
Не знаю, насколько часта такая ситуация в других конторах, но тогда мне это здорово рвало шаблон от бессмысленности происходящего.
В больших корпорациях часто есть множество офисов, рассосредоточеных по всему миру. В конторе, где я раньше работал, было 2 офиса в Украине, 5+ офисов в РФ и бесчисленное количество команд, которые сидели у заказчика по всем странам и часовым поясам мира.
Из-за большого количества проектов, практически всегда команда собиралась из разных офисов. Очень редко было такое, что все сидели в одной комнате. Но, что интересно, не так редка была ситуация, когда человек был единственным, кто работал на проекте из его окружающих. То есть ты спокойно мог годами вообще никак не пересекаться с коллегами из комнаты, где ты сидишь. В запущеном случае (саппорт например) мало того, что у тебя не было тиммейтов в твоем офисе, так еще и во всем постсовковом регионе.
То есть, на самом деле, это была самая настоящая удаленная работа. Только из офиса. При этом, компания не разрешала работать удаленно из дому (или разрешала но очень-очень ограниченно). Парадокс, да? Твой босс сидит в командировке уже больше полугода, ребята за соседними столами занимаются непонятно чем (или понятно чем, но это тебе фиолетово), но в офис все равно нужно ходить.
Не знаю, насколько часта такая ситуация в других конторах, но тогда мне это здорово рвало шаблон от бессмысленности происходящего.
Неразглашение зарплаты
Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись.
Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных. Да и вообще тарифная сетка фиксированная, плановая экономика же.
Мне кажется что это не было проблемой в те времена, потому что повышение было получить невозможно за просто так, а только в результате какой-то формальной аттестации. То есть, нельзя было просто так прийти к боссу и сказать "товарищ начальник, я или повышайте мне зп или я ухожу на соседний завод потому что там дают больше". Получается что люди как бы не влияли на свою зарплату, поэтому это воспринималось как непреложный факт. Но, может быть, я и не прав.
Сейчас проблема з разглашениями очевидная — никто не знает как оценивать труд программиста, поэтому работает рынок, а тут уже кто во что себя горазд продать. Соответственно, легко возможны ситуации когда топ перформер получает меньше свеженанятого джуна. Поэтому внутри компании, в коллективе, обсуждение зарплаты табуированное, это в интересах работодателя. Не думаю, что у вас принято обсуждать зарплату даже запрет на это явно не прописан в контракте. Меньше знаешь — крепче спишь. Однако, если есть возможность, например случайно подсмотреть что у кого или узнать сумму налога (по которой, с помощью нехитрых вычислений можно определить базу), то это однозначно стоит сделать. Предупрежден — вооружён.
Обсуждать зп с корешами-девелоперами из других контор вполне себе комильфо и очень даже полезно. По крайней мере, у меня с этим проблем не было. Всякие зарплатные опросы хороши, но нет ничего лучше данных из первых рук. Заодно можно потроллить ребят, которые работают за миску риска.
Ну а людям со стороны, особенно в нашей стране, говорить свою зарплату однозначно не стоит — не поймут. Я несколько раз наивно отвечал на вопрос сколько щас зарабатывают программисты и всегда об этом жалел. Не нужно давать лишний повод для зависти и манипуляций. В последнее время я даже избегаю обсуждать работу и профессию, чтобы не провоцировать лишние расспросы.
Компании часто добавляют в договора пункты о неразглашении зарплат а руководство с HRами еще и грозит анальными карами и санкциями за нарушение этого пункта. В конторе где я раньше работал один из руководителей прямо заявлял — за разглашение зп увольняем сразу. О прецедентах никто не слышал, но все боялись.
Что интересно, в советские времена такого не было — все знали зарплаты друг друга. Социализм во все поля! Приходишь в бухгалтерию, расписываешься в ведомости и там видишь зарплаты всех остальных. Да и вообще тарифная сетка фиксированная, плановая экономика же.
Мне кажется что это не было проблемой в те времена, потому что повышение было получить невозможно за просто так, а только в результате какой-то формальной аттестации. То есть, нельзя было просто так прийти к боссу и сказать "товарищ начальник, я или повышайте мне зп или я ухожу на соседний завод потому что там дают больше". Получается что люди как бы не влияли на свою зарплату, поэтому это воспринималось как непреложный факт. Но, может быть, я и не прав.
Сейчас проблема з разглашениями очевидная — никто не знает как оценивать труд программиста, поэтому работает рынок, а тут уже кто во что себя горазд продать. Соответственно, легко возможны ситуации когда топ перформер получает меньше свеженанятого джуна. Поэтому внутри компании, в коллективе, обсуждение зарплаты табуированное, это в интересах работодателя. Не думаю, что у вас принято обсуждать зарплату даже запрет на это явно не прописан в контракте. Меньше знаешь — крепче спишь. Однако, если есть возможность, например случайно подсмотреть что у кого или узнать сумму налога (по которой, с помощью нехитрых вычислений можно определить базу), то это однозначно стоит сделать. Предупрежден — вооружён.
Обсуждать зп с корешами-девелоперами из других контор вполне себе комильфо и очень даже полезно. По крайней мере, у меня с этим проблем не было. Всякие зарплатные опросы хороши, но нет ничего лучше данных из первых рук. Заодно можно потроллить ребят, которые работают за миску риска.
Ну а людям со стороны, особенно в нашей стране, говорить свою зарплату однозначно не стоит — не поймут. Я несколько раз наивно отвечал на вопрос сколько щас зарабатывают программисты и всегда об этом жалел. Не нужно давать лишний повод для зависти и манипуляций. В последнее время я даже избегаю обсуждать работу и профессию, чтобы не провоцировать лишние расспросы.
Навіщо ходити до офісу
Ось уже два роки я працюю віддалено. В інтернетах купа матеріалів на тему чому віддалена робота це добре, або чому добре фрілансити, як почати і так далі. В осносному там фокусються на перевагах ремоуту.
Можу підтвердити що все що пишуть відповідає дійсності. Не брешуть.
Навіщо ж ходити до офісу?
Істотним недоліком віддаленої роботи з дому для мене є відсутність соціалізації. Людина—тварина соціальна, бачити інших та спілкуватися з ними вживу, а не через інтернет—обов'язково.
Тому раз на два місяці, коли я починаю сумувати за спілкуванням, я йду до офісу та балакаю з колегами. Десь за кілька годин, коли всі важливі питання обговорені, у повний зріст постають недоліки опенспейсу/офісу—в першу чергу шум, розмови довкола, стук каблуків по ламінату, смикання від колег, мітинги , кондиціонер, незручне крісло та стіл, відсутність сонячного світла і так далі. Коли я йду додому то щоразу думаю—„як добре, що завтра вранці не треба буде туди плентатись!“.
Офіс потрібно відвідувати щоб не забувати, що нічого доброго там немає.
На наступні кілька місяців я знову вільний від думок про опенспейс.
Вважаю що якщо регулярно ходити на різноманітні мітапи, зустрічатися з друзями, то потреба в соціалізації буде закрита, але в мене наразі то все якось не виходить. В будь-якому разі, до офісу треба час від часу зазирати щоб переконатися—ти все робиш правильно.
#лайфстайл
permalink | donate
Ось уже два роки я працюю віддалено. В інтернетах купа матеріалів на тему чому віддалена робота це добре, або чому добре фрілансити, як почати і так далі. В осносному там фокусються на перевагах ремоуту.
Можу підтвердити що все що пишуть відповідає дійсності. Не брешуть.
Навіщо ж ходити до офісу?
Істотним недоліком віддаленої роботи з дому для мене є відсутність соціалізації. Людина—тварина соціальна, бачити інших та спілкуватися з ними вживу, а не через інтернет—обов'язково.
Тому раз на два місяці, коли я починаю сумувати за спілкуванням, я йду до офісу та балакаю з колегами. Десь за кілька годин, коли всі важливі питання обговорені, у повний зріст постають недоліки опенспейсу/офісу—в першу чергу шум, розмови довкола, стук каблуків по ламінату, смикання від колег, мітинги , кондиціонер, незручне крісло та стіл, відсутність сонячного світла і так далі. Коли я йду додому то щоразу думаю—„як добре, що завтра вранці не треба буде туди плентатись!“.
Офіс потрібно відвідувати щоб не забувати, що нічого доброго там немає.
На наступні кілька місяців я знову вільний від думок про опенспейс.
Вважаю що якщо регулярно ходити на різноманітні мітапи, зустрічатися з друзями, то потреба в соціалізації буде закрита, але в мене наразі то все якось не виходить. В будь-якому разі, до офісу треба час від часу зазирати щоб переконатися—ти все робиш правильно.
#лайфстайл
permalink | donate
❤🔥1👎1
Слабоумие и отвага
Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность.
Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — "вот это сделаем так и так, я готов взяться/возглавить". Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — "лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать". Люди любят когда к ним приходят с набором готовых решений или предложений, а не смотрят в глаза и говорят — "ну, что будем делать?".
Я неоднократно наблюдал некомпетентность менеджеров, но тем не менее их все объединяла уверенность и бесстрашие в принятии решений.
Другой РМ, с которым я довольно долго работал, говорил — "по крайней мере у нас есть план".
Что интересно, несмотря на всю эту мудрость я частенько попадал (и иногда продолжаю попадать) в следующую ситуацию — обнаруживается какая-то техническая проблема, которую в принципе, известно как решать, или понятны первые шаги, но вместо того, чтобы проактивно взяться за эту штуку "босс, вот тут такое дело, нам надо вот это и вот это сделать иначе швах. вот план как мы хотим это делать, вот достоинства, вот недостатки, аппрувишь?" я пускал все на самотек и дожидался пока все не рванет и не дойдет до руководства/заказчиков а дальше реактивно уже решал проблему. Но момент упускал и кредит доверия терял.
Не стоит беспокоиться о том, что ваш план будет неидеальным. Если посмотреть на индустрию, то сотни денег сжигаются из-за плохого планирования, делаются говенные продукты (G+, редизайн гмейла, слак ))), но никого это не волнует. Потому что есть люди, которые берут на себя ответственность за всё это безобразие.
И они — возле руля. Главное — не ссать.
Главный движитель карьерного роста — готовность бесстрашно брать на себя ответственность.
Когда долгое время работаешь простым разработчиком то как-то привыкаешь что все решения принимают за тебя — как делать продукт, какие технологии или стек выбирать, как развивать команду, куда расти тебе лично (менеджеру, ему же точно виднее). В этом мирке очень ценятся люди, которые не очкуют встать и сказать — "вот это сделаем так и так, я готов взяться/возглавить". Когда я только начинал менеджерить и беспокоился о решениях, которые нужно было принимать, то мой босс все время твердил — "лучше предложить хоть какой-то план, даже если он не очень хорош и взять на себя ответственность, нежели вообще ничего не делать". Люди любят когда к ним приходят с набором готовых решений или предложений, а не смотрят в глаза и говорят — "ну, что будем делать?".
Я неоднократно наблюдал некомпетентность менеджеров, но тем не менее их все объединяла уверенность и бесстрашие в принятии решений.
Другой РМ, с которым я довольно долго работал, говорил — "по крайней мере у нас есть план".
Что интересно, несмотря на всю эту мудрость я частенько попадал (и иногда продолжаю попадать) в следующую ситуацию — обнаруживается какая-то техническая проблема, которую в принципе, известно как решать, или понятны первые шаги, но вместо того, чтобы проактивно взяться за эту штуку "босс, вот тут такое дело, нам надо вот это и вот это сделать иначе швах. вот план как мы хотим это делать, вот достоинства, вот недостатки, аппрувишь?" я пускал все на самотек и дожидался пока все не рванет и не дойдет до руководства/заказчиков а дальше реактивно уже решал проблему. Но момент упускал и кредит доверия терял.
Не стоит беспокоиться о том, что ваш план будет неидеальным. Если посмотреть на индустрию, то сотни денег сжигаются из-за плохого планирования, делаются говенные продукты (G+, редизайн гмейла, слак ))), но никого это не волнует. Потому что есть люди, которые берут на себя ответственность за всё это безобразие.
И они — возле руля. Главное — не ссать.
Менеджеры-белки (истерички)
Оставлять гребцов в лодке одних, наедине с океаном нереализованных требований опасно (пойдут не туда), поэтому над разработчиками всегда ставят надсмотрщика-менеджера.
Когда начинается жопа, все горит и ломается, то, как правило, проблему может исправить только вдумчивая и длительная работа соответствующих специалистов. Однако если у инженера есть возможность прямо влиять на ситуацию — разбирать ошибки, читать стековерфлоу и пробовать-пробовать-пробовать починить, или есть в голове примерный план переписывания совсем уже прогнившего участка трубы, то у менеджера такой роскоши нет. Весь жар он должен загребать чужими руками, его для этого и наняли.
Но менеджер не может просто стоять в сторонке, не мешать ценными указаниями и смотреть как тушится пожар — тогда получается что от него вроде бы как ничего и не зависит, а так нельзя. Поэтому, чтобы оправдать свое (жалкое) существование, эти люди начинают изобретать планы, писать отчеты, рисовать графики, собирать заседания и комитеты, заставлять людей овертаймить, ну и самое главное — каждые полчаса спрашивать статус. "Ну что там?", "Ну как?", "Когда починишь?", "Это же просто сделать, почему так долго?". В легкой форме это все сливается в чат, который тут же мьютится, в тяжелой — начинаются звонки в мессенджеры и если совсем тяжко — то на телефон, потом хождение ногами лично, а на команду или человека проецируется повышенный градус истерии и неадеквата.
Их можно понять — если не можешь ничего сделать, то нужно хотя бы быть в курсе. Или давать ценные указания. Неопытный разработчик часто прогибается под такого руководителя и пытается воспринимать его всерьез, товарищи пожестче правильно управляют ожиданиями ("будет завтра, нет, быстрее сделать нельзя, нет, у меня сегодня дела вечером") а особо назойливых просто блокируют или игнорируют.
Особенно печален расклад когда менеджер это просто прокладка между заказчиком и разработчиком, который сам по себе не особо понимает что происходит вообще, но находится под давлением заказчика. Тогда приходится еще и тратить время на правильную коммуникацию и объяснение проблемы, вместо того, чтобы собственно заниматься работой.
Увы, ситуация такая на нашем рынке встречается довольно часто, особенно с гражданами которые пришли извне ІТ а не выросли из разработчиков/тестировщиков/аналитиков.
Оставлять гребцов в лодке одних, наедине с океаном нереализованных требований опасно (пойдут не туда), поэтому над разработчиками всегда ставят надсмотрщика-менеджера.
Когда начинается жопа, все горит и ломается, то, как правило, проблему может исправить только вдумчивая и длительная работа соответствующих специалистов. Однако если у инженера есть возможность прямо влиять на ситуацию — разбирать ошибки, читать стековерфлоу и пробовать-пробовать-пробовать починить, или есть в голове примерный план переписывания совсем уже прогнившего участка трубы, то у менеджера такой роскоши нет. Весь жар он должен загребать чужими руками, его для этого и наняли.
Но менеджер не может просто стоять в сторонке, не мешать ценными указаниями и смотреть как тушится пожар — тогда получается что от него вроде бы как ничего и не зависит, а так нельзя. Поэтому, чтобы оправдать свое (жалкое) существование, эти люди начинают изобретать планы, писать отчеты, рисовать графики, собирать заседания и комитеты, заставлять людей овертаймить, ну и самое главное — каждые полчаса спрашивать статус. "Ну что там?", "Ну как?", "Когда починишь?", "Это же просто сделать, почему так долго?". В легкой форме это все сливается в чат, который тут же мьютится, в тяжелой — начинаются звонки в мессенджеры и если совсем тяжко — то на телефон, потом хождение ногами лично, а на команду или человека проецируется повышенный градус истерии и неадеквата.
Их можно понять — если не можешь ничего сделать, то нужно хотя бы быть в курсе. Или давать ценные указания. Неопытный разработчик часто прогибается под такого руководителя и пытается воспринимать его всерьез, товарищи пожестче правильно управляют ожиданиями ("будет завтра, нет, быстрее сделать нельзя, нет, у меня сегодня дела вечером") а особо назойливых просто блокируют или игнорируют.
Особенно печален расклад когда менеджер это просто прокладка между заказчиком и разработчиком, который сам по себе не особо понимает что происходит вообще, но находится под давлением заказчика. Тогда приходится еще и тратить время на правильную коммуникацию и объяснение проблемы, вместо того, чтобы собственно заниматься работой.
Увы, ситуация такая на нашем рынке встречается довольно часто, особенно с гражданами которые пришли извне ІТ а не выросли из разработчиков/тестировщиков/аналитиков.
Нужно на вчера, давай быстрее
Крайне распространённая манипуляция — "нужно на вчера".
"Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?", "Два дня на подумать", "Багу срочно нужно пофиксить", "Фичу срочно надо выкатывать", "Никто, кроме тебя это не сможет сделать" и так далее.
Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели?
Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их. Сколько мне надо будет, столько и буду думать. Если вы ставите меня в неудобные рамки — значит мне с вами не по пути.
Бага и так была месяц как, никто не умер. Пофиксим завтра. Или в понедельник.
Ничего не случится если выкатим фичу не завтра а через неделю. Ну конечно же кроме того, что менеджерку который пообещал большим боссам это сделать придется объяснять причину задержек.
Bus factor равный единице это проблема конкретного босса а не ваша.
Во всех этих случаях люди пытаются перекинуть на вас свои проблемы. Не поддавайтесь. Нужно ценить свое время, свои возможности, свое здоровье. Не ваша проблема, что контора долго не может найти нужных людей. Не ваша проблема, что рекрутер пообещала закрыть вакансию послезавтра. Не ваша проблема что процесс разработки организован так, что нужно овертаймить или тушить пожары. Не ваша проблема в том что менеджерье выставляет нереалистичные сроки а потом пушит команду "ну мы же закоммитились, надо выдавать".
Как я уже говорил (https://xn--r1a.website/full_of_hatred/52), контора и глазом не моргнёт, когда встанет вопрос о сокращениях и прочих пертурбациях связанных с бизнесом и выкинет вас на мороз. Если вы работаете в найме, то можно и нужно платить той же монетой. Ничего страшного не случится. Ну а если вас кикнут с формулировкой "не горят глаза", значит так им и нужно. Пусть ищут лохов, готовых жертвовать собой ради чужих интересов дальше.
Крайне распространённая манипуляция — "нужно на вчера".
"Нам нужно срочно закрыть вакансию, не могли бы вы выйти пораньше?", "Два дня на подумать", "Багу срочно нужно пофиксить", "Фичу срочно надо выкатывать", "Никто, кроме тебя это не сможет сделать" и так далее.
Так вот, ничего не случится, если человек выйдет на две недели позже. Вы и так уже ищете два месяца подходящего, не подождете еще две недели?
Допустим, я ищу работу. Последнее, что стоит делать — соглашаться на первое предложение и отметать будущие возможные варианты, даже не рассмотрев их. Сколько мне надо будет, столько и буду думать. Если вы ставите меня в неудобные рамки — значит мне с вами не по пути.
Бага и так была месяц как, никто не умер. Пофиксим завтра. Или в понедельник.
Ничего не случится если выкатим фичу не завтра а через неделю. Ну конечно же кроме того, что менеджерку который пообещал большим боссам это сделать придется объяснять причину задержек.
Bus factor равный единице это проблема конкретного босса а не ваша.
Во всех этих случаях люди пытаются перекинуть на вас свои проблемы. Не поддавайтесь. Нужно ценить свое время, свои возможности, свое здоровье. Не ваша проблема, что контора долго не может найти нужных людей. Не ваша проблема, что рекрутер пообещала закрыть вакансию послезавтра. Не ваша проблема что процесс разработки организован так, что нужно овертаймить или тушить пожары. Не ваша проблема в том что менеджерье выставляет нереалистичные сроки а потом пушит команду "ну мы же закоммитились, надо выдавать".
Как я уже говорил (https://xn--r1a.website/full_of_hatred/52), контора и глазом не моргнёт, когда встанет вопрос о сокращениях и прочих пертурбациях связанных с бизнесом и выкинет вас на мороз. Если вы работаете в найме, то можно и нужно платить той же монетой. Ничего страшного не случится. Ну а если вас кикнут с формулировкой "не горят глаза", значит так им и нужно. Пусть ищут лохов, готовых жертвовать собой ради чужих интересов дальше.
О сроках 1
Самая большая проблема разработки — сроки.
Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются.
В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится). Ни разу еще не видел большого проекта который бы вот запланировали и уложили. Впрочем, может быть, мало видел и такие проекты есть.
Так что если вас нанимают допустим в стартап и говорят что "наша цель — выпустить первую версию продукта через год" — можете смело рассчитывать на тройку лет кропотливого труда до первого релиза. Если вы слышите "через 3 года мы станем лидером в ХХХ" — ожидайте что вообще не станете никогда, или через 10 лет будете середнячками.
Более-менее адекватно работает планирование на коротких участках — пара недель-месяц. Но даже при таких раскладах разработчики ухитряются оптимистично смотреть в конец спринта а под конец опять не укладываться (https://xn--r1a.website/full_of_hatred/94)
Любимый вопрос бизнес-людей — "сколько времени займет сделать (сайт/продукт/фичу)"? На это можно спокойно отвечать: от месяца до бесконечности, в зависимости от пожеланий к качеству 🙂
Без сроков, увы, работать тоже нельзя — людям же нужно знать, когда они смогут пощупать то, что кодерки пытаются слепить по плохо написанным спецификациям...
Для меня сроки являются серьезным источником стресса. Во-первых они висят как дамоклов меч и это напрягает само по себе, а во-вторых, не знаю как кто, а я довольно сильно начинаю беспокоиться и переживать, если чувствую, что не укладываюсь. Иногда это можно обсудить заказчиком и растянуть их, но конкретно у меня часто бывает такое что задачи привязываются к ивентам из реального мира, и подвинуть их ну никак нельзя (например уже отпечатана реклама). Тут уж приходится трайхардить и срезать чтобы хоть как-то уложиться.
Самая большая проблема разработки — сроки.
Бизнес любит ставить сроки (а как работать-то, без них?), разработчики не любят называть сроки, менеджеры любят занижать сроки, а в итоге они всегда продалбываются.
В чем я точно уверен — так это в том, что сроки на длинном временном промежутке планирования (год, а то и меньше) 100% будут сорваны. Даже если не изменятся требования (а они изменятся), не будет смены приоритетов (а они будут), не будет меняться состав команды (а люди будут приходить и уходить), и будут заложены буферы (работа занимает столько времени, сколько на нее отводится). Ни разу еще не видел большого проекта который бы вот запланировали и уложили. Впрочем, может быть, мало видел и такие проекты есть.
Так что если вас нанимают допустим в стартап и говорят что "наша цель — выпустить первую версию продукта через год" — можете смело рассчитывать на тройку лет кропотливого труда до первого релиза. Если вы слышите "через 3 года мы станем лидером в ХХХ" — ожидайте что вообще не станете никогда, или через 10 лет будете середнячками.
Более-менее адекватно работает планирование на коротких участках — пара недель-месяц. Но даже при таких раскладах разработчики ухитряются оптимистично смотреть в конец спринта а под конец опять не укладываться (https://xn--r1a.website/full_of_hatred/94)
Любимый вопрос бизнес-людей — "сколько времени займет сделать (сайт/продукт/фичу)"? На это можно спокойно отвечать: от месяца до бесконечности, в зависимости от пожеланий к качеству 🙂
Без сроков, увы, работать тоже нельзя — людям же нужно знать, когда они смогут пощупать то, что кодерки пытаются слепить по плохо написанным спецификациям...
Для меня сроки являются серьезным источником стресса. Во-первых они висят как дамоклов меч и это напрягает само по себе, а во-вторых, не знаю как кто, а я довольно сильно начинаю беспокоиться и переживать, если чувствую, что не укладываюсь. Иногда это можно обсудить заказчиком и растянуть их, но конкретно у меня часто бывает такое что задачи привязываются к ивентам из реального мира, и подвинуть их ну никак нельзя (например уже отпечатана реклама). Тут уж приходится трайхардить и срезать чтобы хоть как-то уложиться.
О сроках 2
Хорошо работает только планирование рутинных задач. Типа "добавить отчет". Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде "давайте попробуем потратить 5 дней на исследование а дальше посмотрим". Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.
Когда мне приезжает неизвестная задача то я как правило говорю "давайте мы поковыряем и за пару дней сделаем прототип а дальше будем смотреть". В целом подход работает, но были случаи, когда не получалось сделать вообще (например нам как-то нужно было распознавать текст с кассовых документов, но точность была довольно низкой, как ни старались) или прототип шёл на ура, а на реальных данных работал плохо (хитрое сравнение изображений отлично работало на тестовых фотках которые делал заказчик но быстро обломалось на пользовательских данных).
Ребята из Basecamp в противопоставление спринтам и аджайлу придумали целую философию "работа как гора" (https://m.signalvnoise.com/new-in-basecamp-see-where-projects-really-stand-with-the-hill-chart/). Кто-то занимается тотальным нано-таскингом и бьет скоуп на супер-мелкие задачи по полчаса, кто-то вотерфоллит и рисует диаграммы Гантта которая уже через неделю становится неактуальной. Кто-то работает без сроков 🙂
Но и без сроков тоже сильно можно расслабиться и забивать, особенно если деньги получаешь не за жопочасы в офисе а за выполненные задачи.
Еще для меня хорошо работает схема когда есть реально жесткие дедлайны и надо к ним успеть. Тогда я мобилизуюсь, и ударно батрачу несколько дней пока не будет готово. Но, по моим ощущениям после такого рубилова надо обязательно отдыхать несколько дней, иначе усталость и апатия. Этот подход отлично описал господин Дубаков и мне его модель сейчас кажется самой прикольной (https://medium.com/@mdubakov/94-давайте-пошлём-рабочую-неделю-в-жопу-e71a853e8f35) и походу я по ней в некотором смысле и живу, потому что у меня нет ни фиксированных выходных, ни праздников, а лишь периоды активностей и затишья.
Короче говоря, сроки — не соблюдаются, стресс от них — серьезный, и похоже что никто с этим ничего делать не собирается. Всем 5 дней по 8 часов в офисе, котаны!
Хорошо работает только планирование рутинных задач. Типа "добавить отчет". Если мы уже делали похожие отчеты, то примерно знаем, сколько на них нужно будет потратить времени, накидываем ±пару дней и спокойно едем. А вот всякие околоисследовательские штуки, или что-то неизвестное можно только ограничивать временем вроде "давайте попробуем потратить 5 дней на исследование а дальше посмотрим". Ну это тоже такое себе планирование, потому что может оказаться что 5 дней мало, дальше берутся еще 5, потом еще, потом еще и вот уже два месяца ушло и только теперь стало ясно куда можно копать дальше.
Когда мне приезжает неизвестная задача то я как правило говорю "давайте мы поковыряем и за пару дней сделаем прототип а дальше будем смотреть". В целом подход работает, но были случаи, когда не получалось сделать вообще (например нам как-то нужно было распознавать текст с кассовых документов, но точность была довольно низкой, как ни старались) или прототип шёл на ура, а на реальных данных работал плохо (хитрое сравнение изображений отлично работало на тестовых фотках которые делал заказчик но быстро обломалось на пользовательских данных).
Ребята из Basecamp в противопоставление спринтам и аджайлу придумали целую философию "работа как гора" (https://m.signalvnoise.com/new-in-basecamp-see-where-projects-really-stand-with-the-hill-chart/). Кто-то занимается тотальным нано-таскингом и бьет скоуп на супер-мелкие задачи по полчаса, кто-то вотерфоллит и рисует диаграммы Гантта которая уже через неделю становится неактуальной. Кто-то работает без сроков 🙂
Но и без сроков тоже сильно можно расслабиться и забивать, особенно если деньги получаешь не за жопочасы в офисе а за выполненные задачи.
Еще для меня хорошо работает схема когда есть реально жесткие дедлайны и надо к ним успеть. Тогда я мобилизуюсь, и ударно батрачу несколько дней пока не будет готово. Но, по моим ощущениям после такого рубилова надо обязательно отдыхать несколько дней, иначе усталость и апатия. Этот подход отлично описал господин Дубаков и мне его модель сейчас кажется самой прикольной (https://medium.com/@mdubakov/94-давайте-пошлём-рабочую-неделю-в-жопу-e71a853e8f35) и походу я по ней в некотором смысле и живу, потому что у меня нет ни фиксированных выходных, ни праздников, а лишь периоды активностей и затишья.
Короче говоря, сроки — не соблюдаются, стресс от них — серьезный, и похоже что никто с этим ничего делать не собирается. Всем 5 дней по 8 часов в офисе, котаны!
О рекрутерах-посредниках
Давно не было нытья о рекрутерах!
Все знают что на рынке есть рекрутинговые агенства. Типа мы вам подберем лучшего кандидата, овер 9000 лет экспертизы и все такое.
Такие конторы конечно же очень даже нужны всяким стартапам или компаниям, которые только заходят на рынок, вообще не имеют команды, или пока что не обзавелись внутренним рекрутером, а так же полезны для найма C-level людей и закрытия всяких экзотических вакансий.
Но вот что меня всегда забавляло — так это рекрутеры из агенств, которые перепродают тебе вакансию условного Люксофта или другого крупного игрока. То есть приходят такие и говорят — "привет братишка, у Люксофта вот есть вакансия, не хо поработать?". При том, что эта же вакансия как бы открыто висит на сайте этого самого Люксофта. Дальше происходит следующее — они просят поговорить по скайпу чтобы спросить стандартные вещи типа сколько денег хочешь, когда выходишь и почему уходишь и дальше передают эту инфу в собственноручно структурированном виде в Люксофт. Люксофт смотрит на их выводы (на самом деле нет), смотрит на CV и зовет к себе, чтобы опять провести точно такое же рекрутерское собеседование после чего передать технарям.
Рекрутеры из агенств, естественно, не имеют доступа к CRM компаний, поэтому не могут знать, что вы уже были в конторе, куда они вас зовут, а в случае вакансий у крупных контор, естественно, вы скорее всего там уже были, и возникает раздражение от того, что вас бомбят одинаковыми предложениями так, как будто вы их видите в первый раз.
Я понимаю, какую ценность дают такие рекрутеры компании-нанимателю — дополнительный пул кандидатов. Но какой толк от этого кандидату? Тратить время на общение с посредником, чтобы потом еще раз отвечать на те же вопросы уже непосредственно в компании? Спасибо, не надо. Работа рекрутера заканчивается ровно на этапе передачи вашего CV а дальше он или работает испорченным телефоном или просто ждет пока вас наймут.
Рекрутеры за найм получают хорошие деньги в виде процента от вашей месячной или годовой зарплаты, при этом все что они делают — это пересылают ваше CV (самые старательные форматируют под свой стандарт) в искомую контору. И все. Ничего не напоминает? Правильно, точно такие же граждане сдают или продают вам квартиру и пальцем не пошевелив, но при этом хотят свои 100% от месячной оплаты аренды или 5% от сделки за покупку.
Короче говоря, если ко мне придёт такой рекрутер и я увижу что вакансия висит на сайте конторы, то я из принципа пойду напрямую в контору, и буду просить у них sign-in бонус (который бы они иначе заплатили за найм). Потому что мне не нравится, когда люди получают деньги за настолько бесполезное посредничество.
Еще есть варик когда рекрутер специально под вас шерстит рынок на предмет интересных вакансий (типа риэлтора который бегает по объектам и ищет подходящий вам). Тогда да, ему есть смысл платить, он свои деньги отрабатывает. Но если к вам просто пришел рандомный человек и предлагает поработать в лидере рынка а потом начинаются "вначале нам нужно провести короткое интервью на 30 минут, а потом я передам ваше резюме заказчику" то нет, спасибо. Я сам напишу заказчику, так и для меня и для него будет быстрее и дешевле.
Давно не было нытья о рекрутерах!
Все знают что на рынке есть рекрутинговые агенства. Типа мы вам подберем лучшего кандидата, овер 9000 лет экспертизы и все такое.
Такие конторы конечно же очень даже нужны всяким стартапам или компаниям, которые только заходят на рынок, вообще не имеют команды, или пока что не обзавелись внутренним рекрутером, а так же полезны для найма C-level людей и закрытия всяких экзотических вакансий.
Но вот что меня всегда забавляло — так это рекрутеры из агенств, которые перепродают тебе вакансию условного Люксофта или другого крупного игрока. То есть приходят такие и говорят — "привет братишка, у Люксофта вот есть вакансия, не хо поработать?". При том, что эта же вакансия как бы открыто висит на сайте этого самого Люксофта. Дальше происходит следующее — они просят поговорить по скайпу чтобы спросить стандартные вещи типа сколько денег хочешь, когда выходишь и почему уходишь и дальше передают эту инфу в собственноручно структурированном виде в Люксофт. Люксофт смотрит на их выводы (на самом деле нет), смотрит на CV и зовет к себе, чтобы опять провести точно такое же рекрутерское собеседование после чего передать технарям.
Рекрутеры из агенств, естественно, не имеют доступа к CRM компаний, поэтому не могут знать, что вы уже были в конторе, куда они вас зовут, а в случае вакансий у крупных контор, естественно, вы скорее всего там уже были, и возникает раздражение от того, что вас бомбят одинаковыми предложениями так, как будто вы их видите в первый раз.
Я понимаю, какую ценность дают такие рекрутеры компании-нанимателю — дополнительный пул кандидатов. Но какой толк от этого кандидату? Тратить время на общение с посредником, чтобы потом еще раз отвечать на те же вопросы уже непосредственно в компании? Спасибо, не надо. Работа рекрутера заканчивается ровно на этапе передачи вашего CV а дальше он или работает испорченным телефоном или просто ждет пока вас наймут.
Рекрутеры за найм получают хорошие деньги в виде процента от вашей месячной или годовой зарплаты, при этом все что они делают — это пересылают ваше CV (самые старательные форматируют под свой стандарт) в искомую контору. И все. Ничего не напоминает? Правильно, точно такие же граждане сдают или продают вам квартиру и пальцем не пошевелив, но при этом хотят свои 100% от месячной оплаты аренды или 5% от сделки за покупку.
Короче говоря, если ко мне придёт такой рекрутер и я увижу что вакансия висит на сайте конторы, то я из принципа пойду напрямую в контору, и буду просить у них sign-in бонус (который бы они иначе заплатили за найм). Потому что мне не нравится, когда люди получают деньги за настолько бесполезное посредничество.
Еще есть варик когда рекрутер специально под вас шерстит рынок на предмет интересных вакансий (типа риэлтора который бегает по объектам и ищет подходящий вам). Тогда да, ему есть смысл платить, он свои деньги отрабатывает. Но если к вам просто пришел рандомный человек и предлагает поработать в лидере рынка а потом начинаются "вначале нам нужно провести короткое интервью на 30 минут, а потом я передам ваше резюме заказчику" то нет, спасибо. Я сам напишу заказчику, так и для меня и для него будет быстрее и дешевле.