В общем согласен. Достаточно натренировать литкод, софты и нарисовать опыт в резюме по советам волчар Назарова — и можно к вам с таким подходом устраиваться. Уметь программировать в целом не обязательно.
>И в четвертых, длина корабля по оси движения уменьшилась по той же самой причине - левая часть догоняет правую, так как она в будущем относительно правой.
Полезно добавить, что для реального наблюдателя (камера, глаз) объект будет выглядеть повёрнутым вдоль оси полёта: свет от дальнего конца задней части ракеты приходит позже чем от ближнего конца, и таким образом виден зад ракеты, который с неограниченной скоростью света виден не будет. Если решить простое уравнение — будет видно, что для наблюдателя эти 2 релятивистских эффекта внезапно окажутся идентичны повороту объекта.
Ну и капелька занудства: все это значит, что в физике нет понятия одновременности. Вообще, никакого. И любые отсылки на одновременность, или что-то в будущем/прошлом относительно чего-то другого — только путают и мешают адекватно делать выводы. Это же кстати верно для работы распределённых систем: синхронизации между ядрами процессоров, между серверами, итд
JetBrains был адекватен, да. Только с прошлого года закрывал тикеты с багами в Ютреке с резюме «вы из России, мы в Россию поддержку не оказываем». Сейчас всё что я видел удалено из публичного доступа, но тем не менее.
$2М в год — это чуть больше 1 американской команды с офисом и менеджментом, или 2-3 сильные команды из Индии. Сравнивая с масштабом «переписать весь бекэнд пинтереста», кажется эта экономия не окупится никогда даже на масштабах пинтереста. Это очень грустно.
Тем не менее, крупные технологические компании так и делают: вписывают бонусы и опционы в оффер, давая оклад существенно ниже альтернативных предложений — и это сложившаяся практика. Все мне известные офферы на $200-300k для разработчиков именно такие, как и большие офферы в JB и Я.
JetBrains так же работал — премии у многих составляли половину дохода. Яндекс до СВО высоким грейдам насыпал опционов и премий не меньше оклада. Предлагаете с ними не работать?
Автор принял условия сделки, в которой явно и с акцентом описано, что за несоответствующее заданию решение не заплатят. Условия сделки не выполнил, с этим согласен, но всё равно требует денег и называет поведение компании кидаловом.
По сути это конфликт между капиталистической и социалистической картиной мира, где в первой в основе отношений лежит соблюдение условий сделки, а во второй — самоценность труда и необходимость его «справедливой» оплаты безотносительно условий. Без специальных навыков спорить с картиной мира малополезно — не получите ничего кроме негативной реакции.
PS У многих болит, что их однажды кинул заказчик, и читатели эмоционально реагируют, не вникая в детали.
Статья как будто ChatGPT написана — мало конкретики, много воды и многозначительных фраз про стратегию и абстрактные результаты с обилием баззвордов вроде «таланты». При этом заголовок — кликбейт, в статье нет явно выделенных «5 причин ценить HRBP». Особый кринж, что статьёй про HRBP рекламируется курс для рекрутёров — это как статьёй про разработку на Python рекламировать курс для администраторов Windows.
По сути, в статье обошли все ключевые вопросы: зачем нужен HRBP, какие конкретные цели перед ними ставятся, как измеряется польза от HRBP, какую конкретную пользу в целом может извлечь бизнес от их появления (не рекрутёров, которые «помогают в привлечении талантливых сотрудников»).
Кажется такой статье место в бизнес-журнале для зала ожидания аэропорта, а не на портале где обитают инженеры.
Кажется в дихотомии 2 культур самое ценное — найти, где эти культуры пересекаются. Где с одной стороны есть читаемость и удобство второй культуры, и гарантии=сходу понятное для программиста поведение первой. Я пристрастен, но Go как раз об этом — сделан «людьми из множества {Керниган; Томпсон; Вирт; Хоар; Дейкстра; Торвальдс}», и для людей второй культуры, с максимально низким порогом входа. Особенно это характерно для документации, которая хранится в коде, и автоматически подтягивается в онлайн документацию из гитхаба.
Отдельно, обе культуры объединяются в мире микросервисов, где гарантии вызова между сервисами заведомо слабые, а строгая e2e проверка чаще всего невозможна.
Любые качества могут быть и минусом, так и плюсом. Возраст и огромный опыт в образовании, например, будет большим плюсом при найме в образовательные проекты.
А дискриминация есть везде, где достаточно кандидатов. Как только начинается настоящий дефицит, нанимающие менеджеры сразу разговаривают со всеми, кто хоть сколько-то похож на необходимого человека.
Наглядная иллюстрация конфликта разработки и топ менеджмента, когда люди вместо того чтобы договариваться и решать общие проблемы всячески мешают жить друг другу. Результат в заголовке (или нет, просто все недовольные ушли).
Правых тут, очевидно, нет. Кто виноват — сложно судить, чаще всего так бывает из-за отсутствия компетентного технического топ-менеджмента (CTO, VP of engineering etc), способного разрешить этот конфликт.
По моему опыту (несколько десятков разработчиков) у Go самый низкий порог входа: новичкам в языке (но минимум мидлам бэкенда) выдаётся задача на Go, и они с первого дня выдают деливери на уровне мидлов. tour.golang.org — великая вещь, которой не хватает многим языкам, как и простой документации по языку или стандартной библиотеке.
В целом, сравнивать промышенные и эзотерические языки имеет мало практического смысла — последние мало где получится использовать.
По пунктам, судя по аргументу про пакеты, это либо очень старая статья, либо автор не в теме. В Go важны другие вещи.
Экосистема. Go — редкое место, где можно спокойно апгрейдить зависимости большого проекта, и почти всегда это не портит работу приложения. По опыту разработки и менеджмента разработки — не хватает разве что больших фреймворков и универсальных ORM, но они не go way. Нет прекрасных проблем в духе миллиона версий питона и ноды
Понятная IDE система типов, вызовов, зависимостей итп. Можно быть уверенным, что поиск по функции (не по текстовому названию, именно по функции) найдёт все её использования, без какой-либо магии, и клик по параметру/функции найдёт именно её. Невозможна ситуация, когда из-за отсутствия (пустого init.py) файла приложение падает в (казалось бы) случайном месте.
Крутой инструментарий: в 1 строчку делается профайлинг прода (по CPU, памяти, горутинам, итп), отлов data race в 1 параметр, просто работающий дебаг, максимально простая система тестов и бенчмарков, максимально простой вылов протекающей памяти или горутин. Вылов data race — штука практически уникальная. К этому добавляется простая возможность оптимизаций вплоть до asm, засчёт чего производительность Go редко является проблемой.
Нет проблем со сборками: нет вечно падающих gyp зависимостей и прочих psycopg — в Go принято делать зависимости на чистом Go, а редкие биндинги к C-библиотекам без проблем собираются даже под другую ОС.
Обработка ошибок. Засчёт того, что разработчика принуждают обрабатывать ошибки, куда чаще они действительно обработаны.
Линейный код. В отличие от промисов и лямбда-программирования, код на Go обычно беглым взглядом прочитывается правильно.
Переносимость опыта. Go разработчик с рынка работал в той же экосистеме, с похожим до неразличимости code style, и в похожей по структуре кодовой базе => существенно короче онбординг.
Универсальность сериализации. В Go никогда нет проблемы «залогировать класс», не нужно изобретать сериализаторы полей итп — оно работает просто и предсказуемо.
Стабильность. Для Go нормально оставить крупное приложение на год без какой-либо поддержки, например перезапуска от медленно текущей памяти или моргнувшей сети.
Установка. Системная утилита на Go переносится 1 бинарником, без каких-либо зависимостей и проблем.
Результат хорошо виден: подавляющее количество опенсорсных системных утилит и сервисов (все эти докеры, кубернейтисы, прометеи, графаны, весь стек хешикорп и прочие кокроачи) пишутся на Go прямо с релиза. Т.е. в условиях чистой конкуренции Go уже победил конкурентов.
Недостатки, впрочем, тоже есть:
if err != nil вместо эксепшенов. Это замусоривает код, а решение пока в глубоком драфте. Зато мотивирует не делать излишне длинные функции, и обрабатывать пойманные ошибки (см. п.5), а эксепшены (паники) исп
Generic'и. Их долго не было, сейчас они весьма ограничены и не всегда удобны. Без них не получается приносить привычные из других языков паттерны, и некоторые библиотечные штуки вроде кастомных сетевых протоколов делать неудобно. С другой стороны, см. п.2 и п.6.
Фреймворки с огромным инструментарием типа админок. Это больно, аналога Django в Go нет и не предвидится. Кажется что для задач Django лучше использовать Django.
ORM. Они есть в урезанном виде без явного лидера. Это проблема, пока не появляются задачи собрать полноценный DDD со всеми агрегатами и value object'ами, или оптимизировать SQL запросы на 5 джойнов и window функцию.
Аргумент, конечно, манипулятивный: Go разработчики в целом больше знают и умеют ввиду большей сложности задач и большей нагрузки на продакшен (и собеседования заметно хардкорнее), и по некоторым исследованиями сравнимые кандидаты мало отличаются по оплате. Тем не менее, это работает как мотивация выбрать Go для разработчика, и как мотивация не выбирать Go для компании.
Насколько я читал региональные законы, не важно, подтверждают ли QR код Госуслуги — главное что QR код был выдан по 1 из 3 причин (вакцинация, болезнь, ПЦР), и не просрочен.
В общем согласен. Достаточно натренировать литкод, софты и нарисовать опыт в резюме по советам волчар Назарова — и можно к вам с таким подходом устраиваться. Уметь программировать в целом не обязательно.
>И в четвертых, длина корабля по оси движения уменьшилась по той же самой причине - левая часть догоняет правую, так как она в будущем относительно правой.
Полезно добавить, что для реального наблюдателя (камера, глаз) объект будет выглядеть повёрнутым вдоль оси полёта: свет от дальнего конца задней части ракеты приходит позже чем от ближнего конца, и таким образом виден зад ракеты, который с неограниченной скоростью света виден не будет. Если решить простое уравнение — будет видно, что для наблюдателя эти 2 релятивистских эффекта внезапно окажутся идентичны повороту объекта.
Ну и капелька занудства: все это значит, что в физике нет понятия одновременности. Вообще, никакого. И любые отсылки на одновременность, или что-то в будущем/прошлом относительно чего-то другого — только путают и мешают адекватно делать выводы. Это же кстати верно для работы распределённых систем: синхронизации между ядрами процессоров, между серверами, итд
У PS VR разрешение 960×1080 на каждый глаз — и растянуто на почти всю область видимости. И людям норм.
Моно — норм, мозг быстро привыкает.
JetBrains был адекватен, да. Только с прошлого года закрывал тикеты с багами в Ютреке с резюме «вы из России, мы в Россию поддержку не оказываем». Сейчас всё что я видел удалено из публичного доступа, но тем не менее.
Можете добавить в дайджест митап Go разработчиков в Москве?
https://go-meetup-spb.timepad.ru/event/2598423/
Митап от сообщества разработчиков.
$2М в год — это чуть больше 1 американской команды с офисом и менеджментом, или 2-3 сильные команды из Индии. Сравнивая с масштабом «переписать весь бекэнд пинтереста», кажется эта экономия не окупится никогда даже на масштабах пинтереста. Это очень грустно.
Тем не менее, крупные технологические компании так и делают: вписывают бонусы и опционы в оффер, давая оклад существенно ниже альтернативных предложений — и это сложившаяся практика. Все мне известные офферы на $200-300k для разработчиков именно такие, как и большие офферы в JB и Я.
JetBrains так же работал — премии у многих составляли половину дохода. Яндекс до СВО высоким грейдам насыпал опционов и премий не меньше оклада. Предлагаете с ними не работать?
Автор принял условия сделки, в которой явно и с акцентом описано, что за несоответствующее заданию решение не заплатят. Условия сделки не выполнил, с этим согласен, но всё равно требует денег и называет поведение компании кидаловом.
По сути это конфликт между капиталистической и социалистической картиной мира, где в первой в основе отношений лежит соблюдение условий сделки, а во второй — самоценность труда и необходимость его «справедливой» оплаты безотносительно условий. Без специальных навыков спорить с картиной мира малополезно — не получите ничего кроме негативной реакции.
PS У многих болит, что их однажды кинул заказчик, и читатели эмоционально реагируют, не вникая в детали.
«Три дня я гналась за вами, чтобы сказать, как вы мне безразличны»
С таким количеством претензий кажется правильнее сразу постучаться на вакансию продакта Алисы — вы же наверняка знаете, как сделать лучше .)
Статья как будто ChatGPT написана — мало конкретики, много воды и многозначительных фраз про стратегию и абстрактные результаты с обилием баззвордов вроде «таланты». При этом заголовок — кликбейт, в статье нет явно выделенных «5 причин ценить HRBP».
Особый кринж, что статьёй про HRBP рекламируется курс для рекрутёров — это как статьёй про разработку на Python рекламировать курс для администраторов Windows.
По сути, в статье обошли все ключевые вопросы: зачем нужен HRBP, какие конкретные цели перед ними ставятся, как измеряется польза от HRBP, какую конкретную пользу в целом может извлечь бизнес от их появления (не рекрутёров, которые «помогают в привлечении талантливых сотрудников»).
Кажется такой статье место в бизнес-журнале для зала ожидания аэропорта, а не на портале где обитают инженеры.
Вы описали tornado cash
Кажется в дихотомии 2 культур самое ценное — найти, где эти культуры пересекаются. Где с одной стороны есть читаемость и удобство второй культуры, и гарантии=сходу понятное для программиста поведение первой. Я пристрастен, но Go как раз об этом — сделан «людьми из множества {Керниган; Томпсон; Вирт; Хоар; Дейкстра; Торвальдс}», и для людей второй культуры, с максимально низким порогом входа. Особенно это характерно для документации, которая хранится в коде, и автоматически подтягивается в онлайн документацию из гитхаба.
Отдельно, обе культуры объединяются в мире микросервисов, где гарантии вызова между сервисами заведомо слабые, а строгая e2e проверка чаще всего невозможна.
График конверсии от просмотра графика цен выглядит очень странно. Вы его на выборке какого размера делали?
Любые качества могут быть и минусом, так и плюсом. Возраст и огромный опыт в образовании, например, будет большим плюсом при найме в образовательные проекты.
А дискриминация есть везде, где достаточно кандидатов. Как только начинается настоящий дефицит, нанимающие менеджеры сразу разговаривают со всеми, кто хоть сколько-то похож на необходимого человека.
Вы проводили нагрузочное тестирование? Сколько TPS обрабатывает кокроач в вашей конфигурации? Несколько лет назад там были очень печальные числа.
Наглядная иллюстрация конфликта разработки и топ менеджмента, когда люди вместо того чтобы договариваться и решать общие проблемы всячески мешают жить друг другу. Результат в заголовке (или нет, просто все недовольные ушли).
Правых тут, очевидно, нет. Кто виноват — сложно судить, чаще всего так бывает из-за отсутствия компетентного технического топ-менеджмента (CTO, VP of engineering etc), способного разрешить этот конфликт.
По моему опыту (несколько десятков разработчиков) у Go самый низкий порог входа: новичкам в языке (но минимум мидлам бэкенда) выдаётся задача на Go, и они с первого дня выдают деливери на уровне мидлов. tour.golang.org — великая вещь, которой не хватает многим языкам, как и простой документации по языку или стандартной библиотеке.
В целом, сравнивать промышенные и эзотерические языки имеет мало практического смысла — последние мало где получится использовать.
По пунктам, судя по аргументу про пакеты, это либо очень старая статья, либо автор не в теме. В Go важны другие вещи.
Экосистема. Go — редкое место, где можно спокойно апгрейдить зависимости большого проекта, и почти всегда это не портит работу приложения. По опыту разработки и менеджмента разработки — не хватает разве что больших фреймворков и универсальных ORM, но они не go way. Нет прекрасных проблем в духе миллиона версий питона и ноды
Понятная IDE система типов, вызовов, зависимостей итп. Можно быть уверенным, что поиск по функции (не по текстовому названию, именно по функции) найдёт все её использования, без какой-либо магии, и клик по параметру/функции найдёт именно её. Невозможна ситуация, когда из-за отсутствия (пустого init.py) файла приложение падает в (казалось бы) случайном месте.
Крутой инструментарий: в 1 строчку делается профайлинг прода (по CPU, памяти, горутинам, итп), отлов data race в 1 параметр, просто работающий дебаг, максимально простая система тестов и бенчмарков, максимально простой вылов протекающей памяти или горутин. Вылов data race — штука практически уникальная. К этому добавляется простая возможность оптимизаций вплоть до asm, засчёт чего производительность Go редко является проблемой.
Нет проблем со сборками: нет вечно падающих gyp зависимостей и прочих psycopg — в Go принято делать зависимости на чистом Go, а редкие биндинги к C-библиотекам без проблем собираются даже под другую ОС.
Обработка ошибок. Засчёт того, что разработчика принуждают обрабатывать ошибки, куда чаще они действительно обработаны.
Линейный код. В отличие от промисов и лямбда-программирования, код на Go обычно беглым взглядом прочитывается правильно.
Переносимость опыта. Go разработчик с рынка работал в той же экосистеме, с похожим до неразличимости code style, и в похожей по структуре кодовой базе => существенно короче онбординг.
Универсальность сериализации. В Go никогда нет проблемы «залогировать класс», не нужно изобретать сериализаторы полей итп — оно работает просто и предсказуемо.
Стабильность. Для Go нормально оставить крупное приложение на год без какой-либо поддержки, например перезапуска от медленно текущей памяти или моргнувшей сети.
Установка. Системная утилита на Go переносится 1 бинарником, без каких-либо зависимостей и проблем.
Результат хорошо виден: подавляющее количество опенсорсных системных утилит и сервисов (все эти докеры, кубернейтисы, прометеи, графаны, весь стек хешикорп и прочие кокроачи) пишутся на Go прямо с релиза. Т.е. в условиях чистой конкуренции Go уже победил конкурентов.
Недостатки, впрочем, тоже есть:
if err != nil вместо эксепшенов. Это замусоривает код, а решение пока в глубоком драфте. Зато мотивирует не делать излишне длинные функции, и обрабатывать пойманные ошибки (см. п.5), а эксепшены (паники) исп
Generic'и. Их долго не было, сейчас они весьма ограничены и не всегда удобны. Без них не получается приносить привычные из других языков паттерны, и некоторые библиотечные штуки вроде кастомных сетевых протоколов делать неудобно. С другой стороны, см. п.2 и п.6.
Фреймворки с огромным инструментарием типа админок. Это больно, аналога Django в Go нет и не предвидится. Кажется что для задач Django лучше использовать Django.
ORM. Они есть в урезанном виде без явного лидера. Это проблема, пока не появляются задачи собрать полноценный DDD со всеми агрегатами и value object'ами, или оптимизировать SQL запросы на 5 джойнов и window функцию.
На мой взгляд есть куда более важный аргумент: Go разработчикам больше платят. Вот статистика по 2021 году:
https://habr.com/ru/article/649423/#rec407700951 (Россия, +33%)
https://insights.stackoverflow.com/survey/2021#section-salary-salary-and-experience-by-language (мир, +25%)
Аргумент, конечно, манипулятивный: Go разработчики в целом больше знают и умеют ввиду большей сложности задач и большей нагрузки на продакшен (и собеседования заметно хардкорнее), и по некоторым исследованиями сравнимые кандидаты мало отличаются по оплате.
Тем не менее, это работает как мотивация выбрать Go для разработчика, и как мотивация не выбирать Go для компании.
Насколько я читал региональные законы, не важно, подтверждают ли QR код Госуслуги — главное что QR код был выдан по 1 из 3 причин (вакцинация, болезнь, ПЦР), и не просрочен.