Дешевле не будет, будет долше и все равно нужен синиор который отревьювит, объяснит как правильно. В конечном итоге потратив времени больше чем если бы сам фиксил баг.
Существует всего две причины нанимать джунов: хорошая и плохая.
Джунам можно платить меньше. Это плохая причина. Потому что важно не сколько вы платите, а сколько получаете на потраченный рубль. От синьора вы получите больше.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
Сеньоров не нанять. Это действительно причина. Если вам нужно много программистов, то может оказаться дешевле выучить их самим.
Если же вам нужно нанимать одного двух в год, то можно и подождать пока появится подходящий.
Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.
Если могут возникнуть вопросы, то нужно иметь на них ответы.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
Глупо отрицать что существуют интервьюэры пытающиеся почесать свое ЧСВ на собеседованиях. Но надо помнить что собеседование процесс двухсторонний. Если вы видите что компания вам не подходит, скажите спасибо, за то что они об этом честно рассказали и двигайтесь дальше. Хуже когда на собеседовании врут про то что будет скрам и передовые технологии, а после выхода на работу оказывается что везде code-and-fix на фреймворке который уже вышел из поддержки, но для этого и дален испытательный срок. Он, как и собеседование, тоже работает в обе стороны.
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
Мне сложно сказать что-то про пользу, я его не читал, а если и возьмусь то не пойму.
Пара тех редакторов что заапувили считали что польза есть.
Вреда я не вижу ни какого.
Тоесть вы считаете что пейпер просто недостоин публикации.
Судя по тому что написано в статье по ссылке два редактора математических журналов с вами не согласны.
Не вижу проблемы. Просто продолжаем использовать Java стек с того места из которого вызвали нативный метод. Для ясности вставить dummy фрейм с пометкой «если вы вернулись сюда, то на самом деле вам нужно вернутся в нативный код».
Кстати есть довольно простое решение проблемы с нативными вызовами.
Нужно на каждый такой вызов заводить отдельный стек. Фокус в том что он может быть существенно меньшего размера.
Есть правда еще одна беда. Что делать если нативные вызовы блокируются?
Но тут никакие файберы не помогут и можно тупо добавлять нативных тредов в таком случае.
Я конечно извиняюсь, но почему бы просто не починить имеющиеся треды вместо создания новой фичи?
Что мешает вернутся к тем благословенным временам когда в яве небыло нативных тредов смахнуть пыль с шедулера и научить его работать не с одним нативным тредом, а с фиксированным количеством. Это снизит расходы памяти на нативные структуры.
В этих ваших файберах стек сократили с мегабайта до килобайта. Видимо за счет динамической аллокации. Если заимплементить динамическую аллокацию в тредах это сломает нативные фреймы точно так же как и в континуациях. Чинить надо так же как в континуациях :)
Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
Не нужно писать вагоны бойлерплейта.
Дешевле не будет, будет долше и все равно нужен синиор который отревьювит, объяснит как правильно. В конечном итоге потратив времени больше чем если бы сам фиксил баг.
Чтобы написать скрипт/фреймворк и перестать шмалять однотипные формочки.
Джунам можно платить меньше. Это плохая причина. Потому что важно не сколько вы платите, а сколько получаете на потраченный рубль. От синьора вы получите больше.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
Сеньоров не нанять. Это действительно причина. Если вам нужно много программистов, то может оказаться дешевле выучить их самим.
Если же вам нужно нанимать одного двух в год, то можно и подождать пока появится подходящий.
Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.
Семантика владения в Rust далеко не рокет сайенс.
И я уже знаю хаскел, так что не предвижу проблемы с камлаом, даже объектным.
По мне так любой программист должен владеть хотя-бы одним функциональным языком, а зная один освоить другой не сложно.
На данный момент с ним у меня было меньше всего проблем. Хотя это скорее всего объясняется тем что с ним у меня больше всего опыта.
Если ситуация повторилась не один раз, да еще и подряд, то возможно надо что-то в консерватории поправить.
У меня в «трудовой» есть запись о том что меня уволили во время испытательного срока. И ничего страшного в этом не вижу. С радостью рассказываю какие работодатели бывают чудаки.
И еще, мне кажется что если вы волнуетесь на собеседованиях, то вам еще рано называться senior :)
Пара тех редакторов что заапувили считали что польза есть.
Вреда я не вижу ни какого.
Судя по тому что написано в статье по ссылке два редактора математических журналов с вами не согласны.
Нужно на каждый такой вызов заводить отдельный стек. Фокус в том что он может быть существенно меньшего размера.
Есть правда еще одна беда. Что делать если нативные вызовы блокируются?
Но тут никакие файберы не помогут и можно тупо добавлять нативных тредов в таком случае.
Что мешает вернутся к тем благословенным временам когда в яве небыло нативных тредов смахнуть пыль с шедулера и научить его работать не с одним нативным тредом, а с фиксированным количеством. Это снизит расходы памяти на нативные структуры.
В этих ваших файберах стек сократили с мегабайта до килобайта. Видимо за счет динамической аллокации. Если заимплементить динамическую аллокацию в тредах это сломает нативные фреймы точно так же как и в континуациях. Чинить надо так же как в континуациях :)