Незаменимых не бывает, но почему то многие уверенны, что весь проект, а то и вся фирма держится только на его плечах
Я не говорил про незаменимых. Я говорил про дороговизну обучения. Первые минимум пару месяцев новые разрабы только тратят время других сотрудников, чем приносят пользу (по крайней мере из моего опыта и из книги mythical man month). А чтобы выйти на уровень ушедшего сотрудника им нужно минимум полгода. Вот и считайте, что сэкономив 10% на повышении, вы потеряли единоразово 600% денег (6 месяцев оплаты работы без ощутимого результата). Окупаемость - 5 лет.
И новый сотрудник, которого вы возьмёте, скорее всего будет хотеть больше чем +10% от предыдущего.
А очередь из желающих совершенно не означает очередь из умеющих. Мы одну позицию по несколько месяцев закрываем а то и год. Желающих много, а подходящих мало. И при всём при этом, нет никаких гарантий, что новый сотрудник действительно будет хорош.
И да, новый сотрудник, который придёт, может быть таким же как ТС, прыгать из компанию в компанию для повышения зп. Т.е. вы в него вложите большую зп, кучу денег на обучение, а он через год свалит.
Ради интереса, как близко вы находитесь к процессу приёма сотрудников и их онбоардинга/обучения?
Текучка кадров нужна менеджменту, потому что он не хочет в горизонт планирования
Менеджменту нужно зарабатывать деньги. Текучка кадров для IT это верный способ их сжигать. Не сходится
Единственный вид компании, который я себе представляю, где текучка кадров имеет менее критичное значение это галеры и разработка небольших проектов под ключ. Где твой опыт в компании не даёт никаких особых преимуществ и новые сотрудники не сильно хуже
Всё что вы (да и я) здесь пишите, это ваш личный опыт, основанный на частных случаях. Потому я и посоветовал делать опросы в таких случаях. Они не дают полностью объективную картину, но это явно лучше, чем мнение двух человек.
Кстати, если у вас в компании архитектор даже не понимал как всё работает, то он и не мог оценить насколько высокая у вас квалификация.
Вы бы это, опрос бы хотя бы прикрепили, кого и как часто повышают. Я работал всего в 3х компаниях, но в каждой мне стабильно каждый год повышали зп. Я об этом просил только однажды, после своего самого первого года работы.
Компаниям не выгодно не повышать хороших специалистов (я не про себя, а в целом). Т.к. у них будет выше мотивация уйти. А заменить хороших специалистов не так просто, не так быстро и ещё дорого (новым программистам нужно много времени, чтобы вникать в проекты/продукты).
По крайней мере это касается компаний средних размеров, в которых я работал. Где вклад каждого сотрудника довольно ощутимый, а продукты и домен требуют внимательного изучения.
Для таких же профанов как я, если интересно: https://www.championat.com/auto/article-3964602-kak-trenirovatsja-kak-gonschik-professional--uprazhnenija-plan-pitanie.html
Ну хорошо, не шахматы а гонки, например. Не вижу принципиальной разницы, что руль, что мышка. Физические кондиции нужны очень специфичные, в основном скорость реакции и знания
Я бы даже осмелился сказать это про настольный теннис. Насколько я знаю, там физическая сила не очень нужна.
Если человек написал решение при помощи chatgpt, полностью разбирается в решении и готов во время следующего этапа мне все объяснить и его улучшить, то мне ок.
По моему опыту как собеседующего, тестовое задание даёт наиболее объективное представление о технических навыках кандидата. Из всех остальных известных мне этапах приема на работу. За исключением пет проектов
Лайв кодинг по всем параметрам ему уступает (в качестве оценки). Как минимум потому что уровень стресса зашкаливает у кандидатов и не все способны с ним справиться.
Но тестовые задания действительно отнимают много времени и не очень справедливо их просить, и мы в итоге заменили их на лайв кодинг.
Не могу себе представить компании, где тестовое задание хотя бы частично может использоваться для продакшена.
Может быть, не работал с ней, не могу дать практический отзыв.
Но как будто бы, количество бойлерплейта там всё равно слишком велико для меня. Но безусловно, она решает многие недостатки sql и выбор между jooq/orm сложнее, чем sql/orm.
Когда я только начинал карьеру программиста, я слышал похожую фразу: "джаву используют те, кто не сумел в c++". Степень адекватности фразы для меня одинаковая. Продолжая аналогию: "машину используют те, кто не сумел в ходьбу".
Я поработал на продукте, где люди придерживаются вашего мнения и пишут на sql. Проблемы орм мне показались цветочками:
На обновление модели: будь добр обновить все запросы
Если ты их не обновил, то когда-нибудь что нибудь на проде не будет работать. Но это не точно
Кривые и неоптимальные sql запросы. Потому что это так классно писать сложные запросы в бд, вместо нормальной архитектуры
С очень слабыми аргументами и отсутствием альтернатив.
Я так понимаю, вы против ORM (или hibernate/JPA) в целом, поскольку spring data это всего лишь обертка поверх. Тот же @Entity вообще в JPA спеке.
Написание SQL ручками? И вы утверждаете, что проблем:
нужно поменять порядка 10 файлов для того чтобы добавить/изменить хоть какую-то функциональность
Вся валидация исключительно в Runtime,
с чистым SQL нет?
Если у вас есть 10 запросов, и вы добавили поле, будьте добры все 10 запросов обновить, даже если вы поле всего лишь читаете, чтобы положить в POJO. А если забыли ещё запятую в конце добавить, то о проблеме вы тоже узнаете только в рантайме.
Кстати, как насчет запроса к промежуточной таблице в случае n:n связи?
А как насчёт этого запроса, если у вас промежуточная таблица - другой (микро)сервис? Или такую проблему уже решить нереально? А если реально, то почему такой же подход нельзя использовать для другой таблицы, но в том же приложении?
В общем: "нормально делай, нормально будет"
ПС я главный хейтер спринга в компании. И не то, чтобы фанат hibernate, но как говорится "Демократия ORM – наихудшая форма правления технология для работы с БД, если не считать всех остальных."
Я не говорил про незаменимых. Я говорил про дороговизну обучения. Первые минимум пару месяцев новые разрабы только тратят время других сотрудников, чем приносят пользу (по крайней мере из моего опыта и из книги mythical man month). А чтобы выйти на уровень ушедшего сотрудника им нужно минимум полгода. Вот и считайте, что сэкономив 10% на повышении, вы потеряли единоразово 600% денег (6 месяцев оплаты работы без ощутимого результата). Окупаемость - 5 лет.
И новый сотрудник, которого вы возьмёте, скорее всего будет хотеть больше чем +10% от предыдущего.
А очередь из желающих совершенно не означает очередь из умеющих. Мы одну позицию по несколько месяцев закрываем а то и год. Желающих много, а подходящих мало. И при всём при этом, нет никаких гарантий, что новый сотрудник действительно будет хорош.
И да, новый сотрудник, который придёт, может быть таким же как ТС, прыгать из компанию в компанию для повышения зп. Т.е. вы в него вложите большую зп, кучу денег на обучение, а он через год свалит.
Ради интереса, как близко вы находитесь к процессу приёма сотрудников и их онбоардинга/обучения?
Менеджменту нужно зарабатывать деньги. Текучка кадров для IT это верный способ их сжигать. Не сходится
Единственный вид компании, который я себе представляю, где текучка кадров имеет менее критичное значение это галеры и разработка небольших проектов под ключ. Где твой опыт в компании не даёт никаких особых преимуществ и новые сотрудники не сильно хуже
Всё что вы (да и я) здесь пишите, это ваш личный опыт, основанный на частных случаях. Потому я и посоветовал делать опросы в таких случаях. Они не дают полностью объективную картину, но это явно лучше, чем мнение двух человек.
Кстати, если у вас в компании архитектор даже не понимал как всё работает, то он и не мог оценить насколько высокая у вас квалификация.
Вы бы это, опрос бы хотя бы прикрепили, кого и как часто повышают. Я работал всего в 3х компаниях, но в каждой мне стабильно каждый год повышали зп. Я об этом просил только однажды, после своего самого первого года работы.
Компаниям не выгодно не повышать хороших специалистов (я не про себя, а в целом). Т.к. у них будет выше мотивация уйти. А заменить хороших специалистов не так просто, не так быстро и ещё дорого (новым программистам нужно много времени, чтобы вникать в проекты/продукты).
По крайней мере это касается компаний средних размеров, в которых я работал. Где вклад каждого сотрудника довольно ощутимый, а продукты и домен требуют внимательного изучения.
Виноват, не прав
Для таких же профанов как я, если интересно: https://www.championat.com/auto/article-3964602-kak-trenirovatsja-kak-gonschik-professional--uprazhnenija-plan-pitanie.html
(Интервью одного гонщика)
Ну хорошо, не шахматы а гонки, например. Не вижу принципиальной разницы, что руль, что мышка. Физические кондиции нужны очень специфичные, в основном скорость реакции и знания
Я бы даже осмелился сказать это про настольный теннис. Насколько я знаю, там физическая сила не очень нужна.
Спасибо за статью
Какое ваше впечатление от темпорал? Если бы выбирали с нуля и без лицензионных нюансов, что бы вы выбрали и почему?
Вот кстати хороший вопрос. Мы не даём фидбека автоматически.
Но если нас просят, мы устраиваем 30 минутный созвон с кандидатом, в целом обозначаем проблемы и отвечаем на вопросы.
Если вам отказывают, попробуйте тоже попросить фидбек явно. Не знаю насколько это общепринятая практика, но почему бы нет.
Предлагать его каждому автоматически это накладно (тогда воронка не очень полезна).
Такие индивиды всегда есть и будут. Я просто не считаю нормой, что они этим гордятся и сваливают свою вину/опасность на других.
Если человек написал решение при помощи chatgpt, полностью разбирается в решении и готов во время следующего этапа мне все объяснить и его улучшить, то мне ок.
Вот только это очень маленький процент людей
Угу, светофоры это тоже террор?
Потому что для многих кандидатов даже оплачиваемые дополнительные часы это no go.
Плюс это вопрос к владельцам компании, на что они готовы тратить деньги. Business as usual.
Если вы копируете задание или решаете его как попало, то это не вопрос к заданию. Вы можете и на вопросы/лайв кодинг отвечать как попало, при желании.
На обсуждении того, как вы выполнили задание, очень часто и легко можно вычислить, что вы не сами делали.
По моему опыту как собеседующего, тестовое задание даёт наиболее объективное представление о технических навыках кандидата. Из всех остальных известных мне этапах приема на работу. За исключением пет проектов
Лайв кодинг по всем параметрам ему уступает (в качестве оценки). Как минимум потому что уровень стресса зашкаливает у кандидатов и не все способны с ним справиться.
Но тестовые задания действительно отнимают много времени и не очень справедливо их просить, и мы в итоге заменили их на лайв кодинг.
Не могу себе представить компании, где тестовое задание хотя бы частично может использоваться для продакшена.
Согласен насчёт совершенного кода. Я сперва прочитал её и на многое открылись глаза
Потом мельком видел чистый код, и не понял, почему люди фанатеют от весьма спорных утверждений в этой книге.
И ведь человек даже ссылку привел, где про crew-9 написано, что он уже давно там и просто ждёт плановой смены.
Вообще не понимаю, как некоторые люди работают с информацией.
Как связан итерационный подход старшипа и стандартный подход crew dragon?
Почему им конец? Они так же могут экстренно эвакуироваться на crew 9
Каким образом сдвиг на один месяц становится аргументом для союза? Типа подготовить новый союз и без задержек можно в течении одного месяца?
Пойдёт?
Я пропагандирую
repository.findById(id)вместо этих 6 строк.Может быть, не работал с ней, не могу дать практический отзыв.
Но как будто бы, количество бойлерплейта там всё равно слишком велико для меня. Но безусловно, она решает многие недостатки sql и выбор между jooq/orm сложнее, чем sql/orm.
Когда я только начинал карьеру программиста, я слышал похожую фразу: "джаву используют те, кто не сумел в c++". Степень адекватности фразы для меня одинаковая. Продолжая аналогию: "машину используют те, кто не сумел в ходьбу".
Я поработал на продукте, где люди придерживаются вашего мнения и пишут на sql. Проблемы орм мне показались цветочками:
На обновление модели: будь добр обновить все запросы
Если ты их не обновил, то когда-нибудь что нибудь на проде не будет работать. Но это не точно
Кривые и неоптимальные sql запросы. Потому что это так классно писать сложные запросы в бд, вместо нормальной архитектуры
Это старый добрый холивар: ORM vs no ORM?
С очень слабыми аргументами и отсутствием альтернатив.
Я так понимаю, вы против ORM (или hibernate/JPA) в целом, поскольку spring data это всего лишь обертка поверх. Тот же
@Entityвообще в JPA спеке.Написание SQL ручками? И вы утверждаете, что проблем:
с чистым SQL нет?
Если у вас есть 10 запросов, и вы добавили поле, будьте добры все 10 запросов обновить, даже если вы поле всего лишь читаете, чтобы положить в POJO. А если забыли ещё запятую в конце добавить, то о проблеме вы тоже узнаете только в рантайме.
А как насчёт этого запроса, если у вас промежуточная таблица - другой (микро)сервис? Или такую проблему уже решить нереально? А если реально, то почему такой же подход нельзя использовать для другой таблицы, но в том же приложении?
В общем: "нормально делай, нормально будет"
ПС я главный хейтер спринга в компании. И не то, чтобы фанат hibernate, но как говорится "
ДемократияORM – наихудшаяформа правлениятехнология для работы с БД, если не считать всех остальных."