Я к тому времени уже ушел с проекта, но у меня какое-то время оставался доступ к репозиторию, и я следил, что там происходит просто из интереса. Было приятное чувство, что меня там больше нет.
Раздел про инфраструктуру не выдерживает критики если честно.
> Обычно просто берут одну систему сборки, и один пакетный менеджер и пилят проект. То есть в начале было много утилит, но потом сузили до двух распространённых. Это ещё не стандарт, но программы, имеющие широкий функционал, сообщество и поддержку. Это не то, что вы искали?
Нет, не то.
Если у проекта множество зависимостей, всё равно замучаешься хоть с жутким CMake хоть с монстроузным Bazel, хоть с чем, потому что авторы библиотек зачастую лепят кто во что горазд. Инфраструктура вокруг сборки проекта превращается в какой-то ад с кучей скриптов, подпорок и костылей.
Когда-то писал CMake конфигурацию для одного проекта, старался всё аккуратно и красиво сделать на modern cmake и т. п., чтобы собиралось везде и у всех разработчиков максимально просто и унифицировано. После меня пришел в проект какой-то суровый C-программист с "30-летним стажем", выкинул всю мою работу и наколбасил как привык, как 20 лет назад делали, чтобы проект только у него одного в особом окружении собирался, потому что ему так удобно, и он так привык. Не представляю себе такую ситуацию в проекте на Rust (или с любым другом современном языком с современным build-тулчейном из коробки).
Проект не дал никаких результатов из-за того, что на самом высоком уровне в компании не было достаточной уверенности, чтобы остановиться на чём-то одном.
5 уровень автономности - это не "ещё более лучшие" айфоны клепать каждый год, ну или трекинг жестов в Vision Pro сделать. Для 5 уровня, вероятно, нужен AGI и уровень технологий на порядки выше того, что у них был и 10 лет назад и есть сейчас. Когда им сказали, что выше 3 они не прыгнут, они не поверили, а потом оказалось, что даже 3 уровень для них недостижим в скором будущем. Фантазии футуристов разбились о жестокую реальность.
Оказывается, сделать и отправить на Марс марсоход можно быстрее и дешевле чем запустить "Хлебушек", катающийся по треку. Стоимость миссии Персеверанс $2.4 миллиарда, реализация проекта от начала разработки до запуска заняла 7 лет. Но, конечно, без 5 уровня автономности. :)
Но опыт они получили хороший, вон сколько патентов осталось. Юристам точно найдётся работа.
Этот браузер по сути игрушечный, но он отлично демонстрирует каким быстрым мог бы быть веб и браузер.
Есть ещё один независимый проект SerenityOS и браузер Ladybird. Ladybird - это браузер, рассчитанный уже на современный веб, но с движком, полностью написанным с нуля.
Никто на самом деле не знает, что такое "микросервис" и насколько он должен быть микро. Достаточно проектировать архитектуру в виде просто сервисов, пользуясь принципом бритвы Оккама, а не плодить "микросервисы" на каждый чих, раздувая сложность разработки, сопровождения, развертывания и т. д.
Несколько сервисов можно поднимать локально через docker compose, это не так больно.
Но и монолит один сервис можно написать вполне себе модульно со слабым зацеплением, что работать с ним будет удобно всем разработчикам в команде.
Просто почему-то люди в IT отрасли сильно подвержены влиянию "авторитетных мнений", бездумному следованию за модными тенденциями и зачастую скатываются в карго-культы. Иногда смотришь на всё это и думаешь: "Ну что за дурдом, зачем люди всё это делают?"
В Atuin сильно не хватает подсветки найденной подстроки. Как им пользоваться без этого не понятно. Очень не удобно. Issue давно висит. https://github.com/atuinsh/atuin/issues/1151
Все, кто много лет говорят про идиотизм, неудобство, опасность сенсорных экранов в автомобилях, делают исследования на эту тему и т.д., все они просто воют? У вас не возникало мысли, что они правы, что технология замены физических элементов управления в автомобилях на сенсорные панели - это серьёзная ошибка, это просто не работает в контексте управления автомобилем?
Нет ничего технологичного, нового и революционного в том, чтобы убить эргономику физических кнопок и крутилок, заменив их на сенсорный экран. Даже если они улучшат юзабилити этих интерфейсов, убрав вложенные меню и мелкие иконки, даже если эти интерфейсы перестанут тормозить и глючить, они всё равно будут неудобны и опасныименнов автомобиле, потому что авто - это вообще опасная штука, это полторы тонны, которые несутся на скорости 30-90 км/ч, и любое отвлечение водителя от дороги, даже на несколько секунд, может повлечь аварию, травмы и смерти людей. И вы никак не сможете сделать интерфейсы на сенсорных экранах так, чтобы на них не надо было отвлекаться от слежения за дорогой.
Наверное всё же люди испытывают какие-то неудобства если задаются вопросами о патчах и написании недостающих библиотек под старую ОС.
Всё работает, но до того момента как понадобится какая-то программа, которая не ставится в старую систему, или пояляются критические уязвимости, которые никто уже не будет закрывать.
За последнее время я несколько раз столкнулся с проблемами совместимости современного софта с Windows 7, когда близкие люди просили меня "починить компьютер" или поставить какую-то нужную им программу.
В Unix есть несколько замечательных примеров «завершённого» ПО: это такие команды, как cd (для изменения текущего каталога) или ls (для вывода списка того, что там находится). Они никогда по сути не изменятся. На них можно полагаться до конца своей жизни.
Так что более-менее свежие продукты, фрукты, яйца и всё остальное нужное в Норильске есть
Только по таким ценам, что никаких "северных зарплат" у вахтовиков и постоянных жителей не хватает, чтобы есть их ежедневно в нужном количестве.
Норильск - это маленький ад на земле. Плохая экология, полярная ночь, холод, депрессии, пьянство и нехватка всего. Никакой романтики там нет. Лучше бы и не строили. Понятно, что природные ресурсы сами себя не добудут, но это не место для жизни людей, там должны "жить" и работать роботы.
Когда-то в молодости по глупости и из интереса ходил в Яндекс на собеседования. Тогда они были даже менее упоротыми, можно было по-человечески поговорить про архитектуру и всё такое. А потом начался такой вот абсурд. Когда-то кто-то свернул не туда и понеслось.
Спасибо за статью. Плюс одна ссылка в ответное письмо рекрутерам из Яндекса. Странно, что они до сих пор иногда мне пишут, давно попросил добавить меня в их базах в чёрный список особо токсичных и нелояльных кандидатов.
Да нет, здравый смысл тут подсказывает что корреляция должна быть. Человек задрочивший литкод будет буквально _с любыми_ задачами справляться значимо лучше. Не только в контексте программирования.
Человек, задрочивший литкод - это просто человек задрочивший лидкод, и это всё, что можно сказать о таком человеке не выясняя его реальный опыт и остальные способности. Это ничего не говорит о его способностях писать понятный, качественный, поддерживаемый, хорошо спроектированный код.
Ну вот за этим такие задачки там и задают. Не можешь развернуть бинарное дерево - жулик, иди гуляй.
Это уже когда-то было:
Google: 90% of our engineers use the software you wrote (Homebrew), but you can't invert a binary tree on a whiteboard so fuck off
Что всех так прямо клинит на этих деревьях? Часто вам деревья вращать приходится? Даже тем, кто занимается разработкой СУБД не приходится это делать, зачем такое спрашивать на собеседовании? Тесты, которые ничего не тестируют, что подтверждается примерами известных людей, которые завалили подобные собеседования в FAANG, но были далеко не идиотами и не шарлатанами.
Мне кажется, то, что вы описали: "стандартизованная система найма" - это "работает" только в умах тех, кто придумывает такие системы и в их отчётах и сопроводительных записках.
Люди - это не унифицированные роботы, каждый человек индивидуален, со своим багажом опыта, навыками, чертами характера, сильными и слабыми сторонами. Нельзя просто разработать "стандарт найма унифицированных людей" и нанимать на все случаи жизни с одинаковой эффективностью, прогоняя всех кандидатов по занимательным задачам в полном отрыве от реальности, предметной области и рабочих проблем.
И в то же время, люди обладают интеллектом и умением обучаться, подстраиваться и перестраиваться если нужно. Не нужно упрощать людей и обесценивать их способности, отталкиваясь только от того, смог человек решить задачу с литкода за 30 минут в условиях стресса или не смог. Так что наняв однажды хорошего инженера/разработчика не надо переживать, что он сможет крутить только одну гайку работать только на одном конкретном проекте только с одним руководителем, а на другом вдруг резко сломается как искусственная нейросетка.
И вот вопрос, как же выматывающие "стандартные" собеседования с элементами бессмысленного и беспощадного олимпиадного программирования помогают находить хороших инженеров с правильным мышлением, которые смогут работать на разных проектах, решать сложные задачи, прокачивать свои навыки и расширять кругозор? Что тестируют такие собеседования? Умение решать задачки с литкода (которые надо решать несколько месяцев, чтобы достичь успеха, как в книжках написано)?
Это попытка упростить то, что не упрощается. Нет никакой серебряной пули. Компании нужно готовиться к собеседованиям и проводить их разумно, а не по чьей-то глупой методичке.
И вы эти заблуждения приписываете всем оппонентам?
Извините, что вмешиваюсь, но думаю, что тут не приписывают "всем оппонентам". Но когда ты видешь в индустрии повальную эпидемию таких собеседований ("обмажемся десятью этапами собеса с дрочкой литкода"), то невольно начинаешь использовать обобщения "все", потому что чисто статистически ты скорее всего попадёшь именно на такое собеседование в компанию, где на самом деле пишут очередную пачку микросервисов с REST/gRPC, а задачи и алгоритмы с литкода не встречаются и никогда не встречались в их коде.
Никто вроде не спорит с тем, что на собеседовании можно и нужно проверять навыки программирования на работу программистом, но крайности - это почти всегда плохо. Когда в крайности впадают умные люди и целая индустрия - это вдвойне плохо, потому что получается психбольница в руках пациентов, и от этого помешательства страдают все участники.
А не окажется ли, что кандидат, способный решать средние задания с литкода, в 90% случаев будет работать лучше того, кто не способен?
Статистических данных и исследований на эту тему я не видел, но опыт и здравый смысл подсказывает мне, что скорее всего тут нет корреляции.
Работа разработчика в современном промышленном софтостроении состоит процентов на 90 из другой деятельности, большую часть навыков и опыта для которой не проверяют на собеседованиях, а что-то вообще невозможно проверить и понять за час времени вне реальной рабочей атмосферы и задач, даже задавая правильные вопросы, а не задалбывая кандидата специальной олимпиадой по "программированию".
Также есть мнение, что собеседования в принципе не совсем работают для найма профессионалов и опытных людей. На собеседовании можно отсеить совсем неопытных, хитрецов, жуликов и т.д. (если они, конечно, не прокачали навыки пускать пыль в глаза и проходить собеседования). Если вы ищете старших разработчиков, лучше проводить минимальные собеседования, а нанимать и увольнять быстро. Для этого и существует испытательный срок для сотрудников. Если спустя месяц-два видно, что человек не справляется, не тянет, не устраивает команду по каким-то причинам - увольняйте.
Я к тому времени уже ушел с проекта, но у меня какое-то время оставался доступ к репозиторию, и я следил, что там происходит просто из интереса. Было приятное чувство, что меня там больше нет.
Раздел про инфраструктуру не выдерживает критики если честно.
> Обычно просто берут одну систему сборки, и один пакетный менеджер и пилят проект. То есть в начале было много утилит, но потом сузили до двух распространённых. Это ещё не стандарт, но программы, имеющие широкий функционал, сообщество и поддержку. Это не то, что вы искали?
Нет, не то.
Если у проекта множество зависимостей, всё равно замучаешься хоть с
жуткимCMake хоть смонстроузнымBazel, хоть с чем, потому что авторы библиотек зачастую лепят кто во что горазд. Инфраструктура вокруг сборки проекта превращается в какой-то ад с кучей скриптов, подпорок и костылей.Когда-то писал CMake конфигурацию для одного проекта, старался всё аккуратно и красиво сделать на modern cmake и т. п., чтобы собиралось везде и у всех разработчиков максимально просто и унифицировано. После меня пришел в проект какой-то суровый C-программист с "30-летним стажем", выкинул всю мою работу и наколбасил как привык, как 20 лет назад делали, чтобы проект только у него одного в особом окружении собирался, потому что ему так удобно, и он так привык. Не представляю себе такую ситуацию в проекте на Rust (или с любым другом современном языком с современным build-тулчейном из коробки).
5 уровень автономности - это не "ещё более лучшие" айфоны клепать каждый год, ну или трекинг жестов в Vision Pro сделать. Для 5 уровня, вероятно, нужен AGI и уровень технологий на порядки выше того, что у них был и 10 лет назад и есть сейчас. Когда им сказали, что выше 3 они не прыгнут, они не поверили, а потом оказалось, что даже 3 уровень для них недостижим в скором будущем. Фантазии футуристов разбились о жестокую реальность.
Оказывается, сделать и отправить на Марс марсоход можно быстрее и дешевле чем запустить "Хлебушек", катающийся по треку. Стоимость миссии Персеверанс $2.4 миллиарда, реализация проекта от начала разработки до запуска заняла 7 лет. Но, конечно, без 5 уровня автономности. :)
Но опыт они получили хороший, вон сколько патентов осталось. Юристам точно найдётся работа.
Этот браузер по сути игрушечный, но он отлично демонстрирует каким быстрым мог бы быть веб и браузер.
Есть ещё один независимый проект SerenityOS и браузер Ladybird. Ladybird - это браузер, рассчитанный уже на современный веб, но с движком, полностью написанным с нуля.
У них же даже на скриншотах https открыт.
Никто на самом деле не знает, что такое "микросервис" и насколько он должен быть микро.
Достаточно проектировать архитектуру в виде просто сервисов, пользуясь принципом бритвы Оккама, а не плодить "микросервисы" на каждый чих, раздувая сложность разработки, сопровождения, развертывания и т. д.
Несколько сервисов можно поднимать локально через docker compose, это не так больно.
Но и
монолитодин сервис можно написать вполне себе модульно со слабым зацеплением, что работать с ним будет удобно всем разработчикам в команде.Просто почему-то люди в IT отрасли сильно подвержены влиянию "авторитетных мнений", бездумному следованию за модными тенденциями и зачастую скатываются в карго-культы. Иногда смотришь на всё это и думаешь: "Ну что за дурдом, зачем люди всё это делают?"
Open a word processor
Paste your pictures
Export to PDF
В Atuin сильно не хватает подсветки найденной подстроки. Как им пользоваться без этого не понятно. Очень не удобно. Issue давно висит.
https://github.com/atuinsh/atuin/issues/1151
Как альтернативы (у каждой свои проблемы):
https://github.com/cantino/mcfly
https://github.com/dvorka/hstr
Все, кто много лет говорят про идиотизм, неудобство, опасность сенсорных экранов в автомобилях, делают исследования на эту тему и т.д., все они просто воют? У вас не возникало мысли, что они правы, что технология замены физических элементов управления в автомобилях на сенсорные панели - это серьёзная ошибка, это просто не работает в контексте управления автомобилем?
Нет ничего технологичного, нового и революционного в том, чтобы убить эргономику физических кнопок и крутилок, заменив их на сенсорный экран. Даже если они улучшат юзабилити этих интерфейсов, убрав вложенные меню и мелкие иконки, даже если эти интерфейсы перестанут тормозить и глючить, они всё равно будут неудобны и опасны именно в автомобиле, потому что авто - это вообще опасная штука, это полторы тонны, которые несутся на скорости 30-90 км/ч, и любое отвлечение водителя от дороги, даже на несколько секунд, может повлечь аварию, травмы и смерти людей. И вы никак не сможете сделать интерфейсы на сенсорных экранах так, чтобы на них не надо было отвлекаться от слежения за дорогой.
Наверное всё же люди испытывают какие-то неудобства если задаются вопросами о патчах и написании недостающих библиотек под старую ОС.
Всё работает, но до того момента как понадобится какая-то программа, которая не ставится в старую систему, или пояляются критические уязвимости, которые никто уже не будет закрывать.
За последнее время я несколько раз столкнулся с проблемами совместимости современного софта с Windows 7, когда близкие люди просили меня "починить компьютер" или поставить какую-то нужную им программу.
Думаю, у большинства таких людей сложности всё же были с переездом туда, где спокойнее и удобнее работать на иностранную компанию.
Может проще на современную ОС перейти? Это какой-то принцип или самоцель - до конца жизни использовать Windows 7? Зачем всё это?
Как говорится, просто оставлю это здесь.
Усложнение команд консоли, 1979−2020
Только по таким ценам, что никаких "северных зарплат" у вахтовиков и постоянных жителей не хватает, чтобы есть их ежедневно в нужном количестве.
Норильск - это маленький ад на земле. Плохая экология, полярная ночь, холод, депрессии, пьянство и нехватка всего. Никакой романтики там нет. Лучше бы и не строили. Понятно, что природные ресурсы сами себя не добудут, но это не место для жизни людей, там должны "жить" и работать роботы.
Когда-то в молодости по глупости и из интереса ходил в Яндекс на собеседования. Тогда они были даже менее упоротыми, можно было по-человечески поговорить про архитектуру и всё такое. А потом начался такой вот абсурд. Когда-то кто-то свернул не туда и понеслось.
Спасибо за статью. Плюс одна ссылка в ответное письмо рекрутерам из Яндекса.
Странно, что они до сих пор иногда мне пишут, давно попросил добавить меня в их базах в чёрный список особо токсичных и нелояльных кандидатов.
Я же привел цитату создателя Homebrew :)
Создатель Rubi on Rails:
Какой-то инженер из Google:
Там много таких примеров в twitter-треде.
Создателя WhatsApp Яна Кума не взяли в Facebook, он завалил собеседование. А потом Facebook купил WhatsApp за 16 миллиардов долларов.
Человек, задрочивший литкод - это просто человек задрочивший лидкод, и это всё, что можно сказать о таком человеке не выясняя его реальный опыт и остальные способности. Это ничего не говорит о его способностях писать понятный, качественный, поддерживаемый, хорошо спроектированный код.
Это уже когда-то было:
Что всех так прямо клинит на этих деревьях? Часто вам деревья вращать приходится? Даже тем, кто занимается разработкой СУБД не приходится это делать, зачем такое спрашивать на собеседовании? Тесты, которые ничего не тестируют, что подтверждается примерами известных людей, которые завалили подобные собеседования в FAANG, но были далеко не идиотами и не шарлатанами.
Мне кажется, то, что вы описали: "стандартизованная система найма" - это "работает" только в умах тех, кто придумывает такие системы и в их отчётах и сопроводительных записках.
Люди - это не унифицированные роботы, каждый человек индивидуален, со своим багажом опыта, навыками, чертами характера, сильными и слабыми сторонами. Нельзя просто разработать "стандарт найма унифицированных людей" и нанимать на все случаи жизни с одинаковой эффективностью, прогоняя всех кандидатов по занимательным задачам в полном отрыве от реальности, предметной области и рабочих проблем.
И в то же время, люди обладают интеллектом и умением обучаться, подстраиваться и перестраиваться если нужно. Не нужно упрощать людей и обесценивать их способности, отталкиваясь только от того, смог человек решить задачу с литкода за 30 минут в условиях стресса или не смог. Так что наняв однажды хорошего инженера/разработчика не надо переживать, что он сможет
крутить только одну гайкуработать только на одном конкретном проекте только с одним руководителем, а на другом вдруг резко сломается как искусственная нейросетка.И вот вопрос, как же выматывающие "стандартные" собеседования с элементами бессмысленного и беспощадного олимпиадного программирования помогают находить хороших инженеров с правильным мышлением, которые смогут работать на разных проектах, решать сложные задачи, прокачивать свои навыки и расширять кругозор? Что тестируют такие собеседования? Умение решать задачки с литкода (которые надо решать несколько месяцев, чтобы достичь успеха, как в книжках написано)?
Это попытка упростить то, что не упрощается. Нет никакой серебряной пули. Компании нужно готовиться к собеседованиям и проводить их разумно, а не по чьей-то глупой методичке.
Извините, что вмешиваюсь, но думаю, что тут не приписывают "всем оппонентам". Но когда ты видешь в индустрии повальную эпидемию таких собеседований ("обмажемся десятью этапами собеса с дрочкой литкода"), то невольно начинаешь использовать обобщения "все", потому что чисто статистически ты скорее всего попадёшь именно на такое собеседование в компанию, где на самом деле пишут очередную пачку микросервисов с REST/gRPC, а задачи и алгоритмы с литкода не встречаются и никогда не встречались в их коде.
Никто вроде не спорит с тем, что на собеседовании можно и нужно проверять навыки программирования на работу программистом, но крайности - это почти всегда плохо. Когда в крайности впадают умные люди и целая индустрия - это вдвойне плохо, потому что получается психбольница в руках пациентов, и от этого помешательства страдают все участники.
Статистических данных и исследований на эту тему я не видел, но опыт и здравый смысл подсказывает мне, что скорее всего тут нет корреляции.
Работа разработчика в современном промышленном софтостроении состоит процентов на 90 из другой деятельности, большую часть навыков и опыта для которой не проверяют на собеседованиях, а что-то вообще невозможно проверить и понять за час времени вне реальной рабочей атмосферы и задач, даже задавая правильные вопросы, а не задалбывая кандидата специальной олимпиадой по "программированию".
Также есть мнение, что собеседования в принципе не совсем работают для найма профессионалов и опытных людей. На собеседовании можно отсеить совсем неопытных, хитрецов, жуликов и т.д. (если они, конечно, не прокачали навыки пускать пыль в глаза и проходить собеседования). Если вы ищете старших разработчиков, лучше проводить минимальные собеседования, а нанимать и увольнять быстро. Для этого и существует испытательный срок для сотрудников. Если спустя месяц-два видно, что человек не справляется, не тянет, не устраивает команду по каким-то причинам - увольняйте.