Мы вплотную приблизились к моменту, когда очередная внучка Ростеха ООО "Вектор" будет на серьезных щщах будет просить олимпиарды на вечный двигатель. Это и есть скрепная технологическая сингулярность.
Моя контора дает. Я сам после каждого собеса заполняю анкету с оценкой кандидата (даже если собес был провальным). Если все хорошо, то даем развернутую обратную связь и оффер. Если плохо, то HR совсем кратко поясняет, что не так.
Мне самому как кандидату в 90% случаев всегда ОС давали. А кто не дает - я таких запоминаю. Потом когда через какое-то время они снова с предложениями лезут, я прямо говорю, что они грубияны и сотрудничать я с ними не собираюсь.
Это все элементарная вежливость. Этому мама в детстве еще должна была научить.
Я все понимаю, но зачем каждый раз идти по пути нейминга китайского контрафакта из 90х? Ну помните, когда все носили легендарные бренды Abibas, Puman, Niek и т.д.
Не, не жиза. Я грустил от проблем типа "компилятор не компиляет" и "спринг не спрингует" только в самом начале карьеры. Сейчас такие ошибки наоборот подстегивают интерес и побуждают покопаться в кишках библиотек. А говнокод побуждает переписать его по уму или как минимум написать хороший юнит-тест.
Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
Вы спросили обратную связь в конце собеседования (+30 баллов)
Подскажите, в вашей мультивселенной пони и единорогов сдачу в магазине тоже надо отдельно спрашивать? В нашей части мультивселенной это что-то само собой разумеющееся.
Стартап Horns&Hoofs Ltd (дочка Ростеха) уже заявил, что разработал инновационные нано-наклеечки с кириллицей. До конца 2022 года стартап планирует привлечь 5млрд рублей частных инвестиций и стать единорогом.
Кстати, кто шутит тут про детей - это ж никакие не шутки. Как только дети перестали быть дополнительными руками на поле, их тут же перестали рожать каждый год. Теперь ребенка заводят, когда есть средства на такую роскошь.
Джунов тоже стоит заводить только если у вас все обмазано CI, тестами и качественным код-ревью - чтобы молодой не имел даже шанса что-то сломать, но имел шанс быстро учиться. А кто заводит джунов в голозадом стартапе, которому без году неделя, - тот делает на самом деле хуже и себе и джунам.
Хватит обесценивать понятие "пет-проекта". Очередной "давайте напишем авторизацию на спринг-буте" - не пет проект. "Я научу вас формошлепать на анугляре" - не пет проект. Это, грубо говоря, детская раскраска. Контуры уже проведены - осталось фломастерами поработать. Так-то и литкодинг можно громко назвать "пет-проектом". Да, такие вещи необходимы, но раньше мы их скромненько называли "примерами".
Пет проектами в свое время были например nginx и scala. То есть люди в свободное время трудились первопроходцами, а не пирамидки из кубиков собирали.
Совет "начать пет-проект" тоже глупость несусветная. Сначала нужно увидеть какую-то проблему в своей рутине или в индустрии в целом, а потом иметь достаточный скилл, чтобы предложить новое решение проблемы. И это будет пет-проект
А бывает и по-другому. Компания чувствует твой энтузиазм в продукте и ездит на тебе не то что за 10х оплату, а даже ниже рынка. Не забывает заливать в уши про твою исключительную пользу и что "мы семья, мы команда". А потом да, смачно выплевывает и нанимает нового. И бывшие "братья по оружию" даже с днем рождения не поздравляют.
lessons learned: всегда смотри на рынок, даже если ты в восторге от работы. Незаменимых компаний и проектов тоже нет.
Он евангелист определенного подхода. Было бы странно, если бы он извинялся за каждое свое слово и делал ремарку, что можно и по-другому. Книга же рассчитана на начинающих - и поэтому следует принципу "научитесь делать хорошо, делать плохо потом само получится". Если каждый джун впитает идею TDD и вообще тестируемости кода, то у нас будет гораздо меньше функций длиной 500 строк, которые делают все на свете и потом возвращают void.
Пассаж про науку говорить "нет" и "да" вообще самая полезная вещь для карьеры. Сначала мне эту мудрость мой первый начальник передал, а потом я ее же прочитал в книге. Код, писаный теми коллективами, где умеют только брать под козырек и исполнять - это жалкое зрелище. К сожалению, убедился в 2 компаниях подряд.
Такие трансформации уже выходят за рамки смысла всех этих монад. Откуда авторам знать, какие у вас планы на данную коллекцию и какой подход к ошибкам предполагается. Это просто другой уровень абстракции. К слову о подходах: это или фейлфаст или фейлсейф.
Если вам по бизнесу нужен фейлсейф, то в стриме вместо X -> Y вы делаете X -> Try<Y> и на выходе получаете List<Try<Y>>. По сути получаете сводку типа "9 объектов из 10 обработались нормально, с 1 из 10 возникли такие-то проблемы".
Если фейлфаст подход, то я бы вообще предварительную валидацию написал. Опять же потому, что если написан стрим, который что-то делает и возвращает коллекцию, то пусть он всегда возвращает коллекцию, а не валится внезапно по исключению.
На мой взгляд, кидаться исключениями из стримов это даже для классического императивного подхода не комильфо. В ФП есть неписанный принцип "если компилируется - должно работать". Хороший принцип.
Если следовать ФП-подходу, то нужно таки дотащить объект монады с ошибкой до специального места, где обрабатываются все исключения - и там уже делать что угодно.
Они же не ради прикола это все печатают, а потому что соответствующий ворох законов имеется. А с другой стороны, потребитель имеет право знать состав продукта здесь и сейчас - даже если он находится у черта на рогах, где нет связи.
Это причина существования направления UI/UX, которому в российских реалиях как правило дают минимальный приоритет. Если вскрывать эту тему, то нужно снова начинать с себя, перестраивать сознание и нарабатывать опыт построения человечных интерфейсов.
Я сейчас конкретно вас ни в чем не обвиняю. Свечку не держал. Просто указываю, что в комнате находится огромный слон, которого вы могли не замечать.
Я всегда задаю такой вопрос: в каком виде разработчику приходят рекламации о проблемах на проде и какие у разработчика отношения с техподдержкой. Потому что:
Устроился однажды в контору. И внезапно оказалось, что каждый разраб по очереди обязан быть "дежурным". Это когда сидишь в каком-то всратом интерфейсе разбора инцидентов и тебе прилетают жалобы вида "Я что-то нажала и все исчезло". Ты должен проанализировать, перевести это на язык технического тикета и выполнить десять приседаний, чтобы в это всратом интерфейсе закрыть обращение как положено. А потом еще и баг исправить. Причем это был не стартап на полтора человка, а крупная страховая компания. Но на организации поддержки решили сэкономить. Там вообще много на чем экономили. Например, в мой отдел в принципе не нанимали QA - ну типа разрабы же умные, сами тесты напишут.
Теперь я в принципе любое "дежурство" на берегу обговариваю. Я согласен только на формат "вы мне баг в джире - я вам коммит".
По мнению Кирьянова, оператор будет способствовать защите национальных интересов РФ, снижению рисков распространения недостоверной информации, кибератак и актов хулиганства.
А так же станет елдиной точкой отказа. Как и все елдиное.
Мы вплотную приблизились к моменту, когда очередная внучка Ростеха ООО "Вектор" будет на серьезных щщах будет просить олимпиарды на вечный двигатель. Это и есть скрепная технологическая сингулярность.
Моя контора дает. Я сам после каждого собеса заполняю анкету с оценкой кандидата (даже если собес был провальным). Если все хорошо, то даем развернутую обратную связь и оффер. Если плохо, то HR совсем кратко поясняет, что не так.
Мне самому как кандидату в 90% случаев всегда ОС давали. А кто не дает - я таких запоминаю. Потом когда через какое-то время они снова с предложениями лезут, я прямо говорю, что они грубияны и сотрудничать я с ними не собираюсь.
Это все элементарная вежливость. Этому мама в детстве еще должна была научить.
Я все понимаю, но зачем каждый раз идти по пути нейминга китайского контрафакта из 90х? Ну помните, когда все носили легендарные бренды Abibas, Puman, Niek и т.д.
Не, не жиза. Я грустил от проблем типа "компилятор не компиляет" и "спринг не спрингует" только в самом начале карьеры. Сейчас такие ошибки наоборот подстегивают интерес и побуждают покопаться в кишках библиотек. А говнокод побуждает переписать его по уму или как минимум написать хороший юнит-тест.
Настоящие разочарования современного погромиста вообще в другой плоскости лежат. Шизанутый менеджмент, изменение требований от дуновения ветра, отмены проектов, бюрократия и т.п.
Нисколько. Но я и не называл "пет-проектами" всякий булшит, надёрганным из туториалов. Какие-то проблемы?
Подскажите, в вашей мультивселенной
пони и единороговсдачу в магазине тоже надо отдельно спрашивать? В нашей части мультивселенной это что-то само собой разумеющееся.Стартап Horns&Hoofs Ltd (дочка Ростеха) уже заявил, что разработал инновационные нано-наклеечки с кириллицей. До конца 2022 года стартап планирует привлечь 5млрд рублей частных инвестиций и стать единорогом.
Кстати, кто шутит тут про детей - это ж никакие не шутки. Как только дети перестали быть дополнительными руками на поле, их тут же перестали рожать каждый год. Теперь ребенка заводят, когда есть средства на такую роскошь.
Джунов тоже стоит заводить только если у вас все обмазано CI, тестами и качественным код-ревью - чтобы молодой не имел даже шанса что-то сломать, но имел шанс быстро учиться. А кто заводит джунов в голозадом стартапе, которому без году неделя, - тот делает на самом деле хуже и себе и джунам.
Хватит обесценивать понятие "пет-проекта". Очередной "давайте напишем авторизацию на спринг-буте" - не пет проект. "Я научу вас формошлепать на анугляре" - не пет проект. Это, грубо говоря, детская раскраска. Контуры уже проведены - осталось фломастерами поработать. Так-то и литкодинг можно громко назвать "пет-проектом". Да, такие вещи необходимы, но раньше мы их скромненько называли "примерами".
Пет проектами в свое время были например nginx и scala. То есть люди в свободное время трудились первопроходцами, а не пирамидки из кубиков собирали.
Совет "начать пет-проект" тоже глупость несусветная. Сначала нужно увидеть какую-то проблему в своей рутине или в индустрии в целом, а потом иметь достаточный скилл, чтобы предложить новое решение проблемы. И это будет пет-проект
Да никто никуда не спешит и ничего не ожидается. Банальность зла: предыдущий кусок прожевали, за новым потянулись.
Вот у нас в бэклоге диаграмма Ганта с фичами, а у них с "понуждениями". Кто освобождается - берет следующее "понуждение" из бэклога и "понуждает".
А бывает и по-другому. Компания чувствует твой энтузиазм в продукте и ездит на тебе не то что за 10х оплату, а даже ниже рынка. Не забывает заливать в уши про твою исключительную пользу и что "мы семья, мы команда". А потом да, смачно выплевывает и нанимает нового. И бывшие "братья по оружию" даже с днем рождения не поздравляют.
lessons learned: всегда смотри на рынок, даже если ты в восторге от работы. Незаменимых компаний и проектов тоже нет.
Он евангелист определенного подхода. Было бы странно, если бы он извинялся за каждое свое слово и делал ремарку, что можно и по-другому. Книга же рассчитана на начинающих - и поэтому следует принципу "научитесь делать хорошо, делать плохо потом само получится". Если каждый джун впитает идею TDD и вообще тестируемости кода, то у нас будет гораздо меньше функций длиной 500 строк, которые делают все на свете и потом возвращают void.
Пассаж про науку говорить "нет" и "да" вообще самая полезная вещь для карьеры. Сначала мне эту мудрость мой первый начальник передал, а потом я ее же прочитал в книге. Код, писаный теми коллективами, где умеют только брать под козырек и исполнять - это жалкое зрелище. К сожалению, убедился в 2 компаниях подряд.
Такие трансформации уже выходят за рамки смысла всех этих монад. Откуда авторам знать, какие у вас планы на данную коллекцию и какой подход к ошибкам предполагается. Это просто другой уровень абстракции. К слову о подходах: это или фейлфаст или фейлсейф.
Если вам по бизнесу нужен фейлсейф, то в стриме вместо X -> Y вы делаете X -> Try<Y> и на выходе получаете List<Try<Y>>. По сути получаете сводку типа "9 объектов из 10 обработались нормально, с 1 из 10 возникли такие-то проблемы".
Если фейлфаст подход, то я бы вообще предварительную валидацию написал. Опять же потому, что если написан стрим, который что-то делает и возвращает коллекцию, то пусть он всегда возвращает коллекцию, а не валится внезапно по исключению.
На мой взгляд, кидаться исключениями из стримов это даже для классического императивного подхода не комильфо. В ФП есть неписанный принцип "если компилируется - должно работать". Хороший принцип.
Если следовать ФП-подходу, то нужно таки дотащить объект монады с ошибкой до специального места, где обрабатываются все исключения - и там уже делать что угодно.
Они же не ради прикола это все печатают, а потому что соответствующий ворох законов имеется. А с другой стороны, потребитель имеет право знать состав продукта здесь и сейчас - даже если он находится у черта на рогах, где нет связи.
А это просят те же самые люди, которые придумали "русский литр" размером 923 мл и "русский килограмм" размером 917 г?
Это причина существования направления UI/UX, которому в российских реалиях как правило дают минимальный приоритет. Если вскрывать эту тему, то нужно снова начинать с себя, перестраивать сознание и нарабатывать опыт построения человечных интерфейсов.
Я сейчас конкретно вас ни в чем не обвиняю. Свечку не держал. Просто указываю, что в комнате находится огромный слон, которого вы могли не замечать.
Я всегда задаю такой вопрос: в каком виде разработчику приходят рекламации о проблемах на проде и какие у разработчика отношения с техподдержкой. Потому что:
Устроился однажды в контору. И внезапно оказалось, что каждый разраб по очереди обязан быть "дежурным". Это когда сидишь в каком-то всратом интерфейсе разбора инцидентов и тебе прилетают жалобы вида "Я что-то нажала и все исчезло". Ты должен проанализировать, перевести это на язык технического тикета и выполнить десять приседаний, чтобы в это всратом интерфейсе закрыть обращение как положено. А потом еще и баг исправить. Причем это был не стартап на полтора человка, а крупная страховая компания. Но на организации поддержки решили сэкономить. Там вообще много на чем экономили. Например, в мой отдел в принципе не нанимали QA - ну типа разрабы же умные, сами тесты напишут.
Теперь я в принципе любое "дежурство" на берегу обговариваю. Я согласен только на формат "вы мне баг в джире - я вам коммит".
А так же станет елдиной точкой отказа. Как и все елдиное.