Это работает немного по-другому, непосредственный руководитель человека должен обязательно присутствовать на собеседованиях, чтобы понимать, что в голове у потенциального сотрудника, а сотрудник соответственно понимать, какие ожидания у руководителя.
Видите, как я написал в комментарии мой пост был про "хорошего" сотрудника, таким сотрудником я в силу своего опыта считаю только тех, для кого деньги не являются основным мотиватором. А что является? Интерес к отрасли, к технологиям, любопытство, стремление к познанию и саморазвитию (возможно неосознанное). И безусловно недовольство и даже обида, когда руководитель оказывается "не тот". Не потому, что платит мало денег. А потому, что "ведет компанию не туда", "выбирает не те технологии", "не хочет прислушиваться к профессионалам"... Именно для людей в такой ситуации я писал комментарий, а не тех, кто ставит материальную выгоду во главу угла. Деньги конечно важны, но "хороший" сотрудник в моём понимании - это человек, для которого в принципе может существовать вакансия, ради которой он готов пожертвовать материальной выгодой, пусть это и не та компания, в которой он работает сейчас. То, о чём пишете вы - я хорошим сотрудником не считаю и с такими людьми обычно долго не разговариваю. Вы скажете - это удобная позиция для руководителя и невыгодная для сотрудника. На поверхности это выглядит так, но если вы рассмотрите типичную карьеру сотрудника, для которого материальная выгода является вторичной перед нематериальной, то в конечном счёте через некоторое время выяснится, что он и зарабатывает больше и позиция у него выше и кругозор шире. Я не хочу вас переубеждать, это просто мой опыт.
Начал читать статью со скепсисом, но в итоге дочитал с интересом. Из своего 19 летнего опыта могу сказать, что практически со всем согласен. Отдельно хочу заметить про четвертый пункт: часто бывает такое, что и сотрудник хороший и руководитель неплохой, но вместе работать не могут. Никак. При другом руководителе всё было классно, при этом плохо. А у руководителя при этом с большинством сотрудников всё идеально. Я бывал с обеих сторон этой ситуации и могу дать совет сотруднику - надо отпустить и уйти. Не потому что ты плохой, неэффективный, халявщик, или непризнанный герой-правдоруб, а потому что в этой ситуации нет хороших решений, и копаться в причинах скорее всего бесполезно - вы не подходите друг другу. Но есть решение, которое чуть лучше, чем другое. Уход сотрудника по собственному желанию без скандала во-первых открывает перед ним новые горизонты рынка труда и обычно увеличение зарплаты, во-вторых это новые вызовы, новые технологии, возможно уход в смежную деятельность, короче всё, что принято называть развитием. И в-третьих о человеке останется хорошая память в команде: был не согласен с руководством, развернулся и сам ушёл, сохранил принципы, не изменил себе и т.д. Поверьте, репутация такого человека очень поможет вам в будущем, ваши бывшие коллеги через nное кол-во лет могут всё это вспомнить и сделать интересный оффер, хорошая репутация всегда хорошо запоминается. Ну а вторая опция - стоять до конца, саботировать, мочить в курилке и т.д. Обычно эта опция приятнее в моменте, но последствия будут значительно менее приятными причем не только для вас, но и для команды в целом.
Если мало ли вы попадете в такую ситуацию, смело выбирайте первый вариант. Если же вы руководитель, дайте человеку немного времени, пару раз намекните, что в мире много интересного помимо вашего болота, ну а потом, что делать, увольняйте.
Самое удивительное в истории с микросервисами - это как люди много лет делали вид, что все в порядке, и вдруг к середине 20х годов прозрели, что они не гугл, а бизнесу больше неинтересно слышать в качестве причины для увеличения бюджета/сроков "особенности архитектуры". Я хорошо помню свой шок от того, как в 16 году руководство настойчиво предложило мне "поделить всё на 10" - вместо одного приложения, репозитория, ci/cd и базы сделать 10. "-Зачем?" "-Так надо!" "-Нас пятеро, нас не 50!" "-Суть не в этом, мы изолируем бизнес области" "-У нас же все разбито по модулям, все изолировано!" "-Это не то!". Мне стоило больших усилий тогда отговорить их, хотя информационный фон этому мягко говоря не способствовал. 10 years later... и эти усилия к счастью больше не нужны. Начинаешь снова верить в здравый смысл.
Сделайте типизированный объект params/options и передавайте его.
Это можно, но тогда у каждого метода будет свой "in" объект и свой "out" объект. Для внешнего апи действительно, лучше так и делать, но для внутреннего, это выглядит тяжеловато особенно с учетом того, что компилятор подскажет тому, кто изменил метод, где еще нужно поменять и, например, если перед комитом обязательно делать билд, то без исправления всех мест человек просто не сможет отправить изменение, т.е. проблема обратной совместимости автоматизируется, а не энфорсится битьём по голове. Это работает почти из коробки для монорепы, если же речь о наборе репозиториев, то помучавшись чуть дольше можно настроить процесс так, чтобы перед коммитом собирались все репозитории с новыми изменениями. Еще как вариант - сделать полиморфный метод, со старой сигнатурой, который вызовет новый метод с дефолтными параметрами.
Аспекты вполне работают для библиотечного кода, например аннотация Transactional из спринга оборачивает метод соответствующим аспектом. А если вы когда-либо использовали библиотеку javamelody для observability, то там целый набор аспектов, которые регистрируют разные события и считают метрики абсолютно независимо от вашего кода и не требуя от вас практически ничего, кроме добавления зависимости и включения в код одной аннотации. Что касается джунов, то как ни странно, джун джуну рознь, есть толковые ребята, которые все схватывают на лету.
Про обертки над библиотеками двумя руками за. Много раз это спасало. Из последнего, меняли реализацию http библиотеки с okhttp на java http клиент, чтобы произвести замену нам пришлось переписать только один класс - собственно реализацию нашей обертки и всё, это очень экономит время.
Про параметры api согласен не до конца. Если речь про внутренний программный API и речь идет о строго типизированном языке, то лучше иметь конкретные параметры, которые нужны в данный момент. После их изменения компилятор подскажет вам, где нужно поменять код, а если делать универсальный нетипизированный параметр, то да, расширить его будет просто, но поправить все места, где это требуется будет сложнее.
Если же речь про внешний апи, то лучше всего и входные и выходные значения оборачивать в объект и добавлять в него поля по необходимости, либо, что, конечно, более правильно но дольше, делать api/v2/ с новым интерфейсом.
Что касается колбэков, то у разных языков есть разные механизмы, которые позволяют не тащить специфику middleware в параметрах по стеку вызовов. Для Java, например, можно использовать аспекты, на которых построено много интересного, от общих вещей вроде observability и транзакционности, до реализации бизнес специфичных требований. Этим не стоит увлекаться, иначе есть шанс получить сложно отлаживаемые ситуации, но часто это гораздо лучше, чем протаскивать лишнее в сигнатурах.
Пропустили пожалуй самый важный Jep - 491. Если кто не в курсе, проблема, которую он решает - это последняя преграда для того, чтобы можно было полноценно использовать Loom не боясь неприятностей (читай - дедлоков) от synchronized. Если вдруг вы не в курсе, что такое Loom, очень рекомендую прекрасную статью https://www.infoq.com/articles/java-virtual-threads. Спойлер: мучиться с async больше будет не нужно.
Не было никаких проблем с тем, чтобы двигаться с Classic UI вперед. Добавлять AI и новые функции можно было легко и в нём. Полностью всё менять в угоду сомнительной моде было совершенно необязательно.
То, что Jetbrains делает с UI/UX своих продуктов в последние 3 года - это очень плохо. Я не знаю, что точно у них изменилось внутри компании, но невооружееным глазом видно, что важные решения теперь принимаются без оглядки на пользовательский опыт. Похоже их стратегией стало: "Догнать и перегнать Vscode", а что там на местах происходит - это проблема мест.
Всегда удивлялся, что люди после java переходят на go. Единственный реальный плюс, который был актуален до недавнего времени, это горутины (сейчас после релиза loom это больше не актуально). Другие аргументы вроде "spring сложный, аннотации неочевидны" мягко скажем не про java и если у вас нет необходимости их использовать - это необязательно. Но больше всего меня поразило, когда в go наконец завезли генерики и я даже рассматривал его как потенциальный язык для следующего проекта, внезапно значительная часть комьюнити начала их хейтить, мол оно нам не надо. Это чем-то напомнило мне, как мои родители долго не переходили на смартфоны: "нам нужен кнопочный".
Много раз писал об этом на хабре, но раз уж есть целая статья о том, какие тестовые задания плохие, напишу еще раз. Тестовые задания работают. Я даю их уже много лет и нахожу с помощью них прекрасных специалистов, при этом не выгорая на разгребании сотен холодных откликов. Я не использую код в рамках тестовых в продакшене. Любому, кто сделал тестовое я оставляю обратную связь. С любым кто сделал тестовое хорошо, я разговариваю. Разговор я всегда начинаю с тестового задания, которое в дальнейшем выступает лейтмотивом разговора и предметом life-кодинга. За все эти годы ни разу поиск не занимал больше полутора месяцев. Я отдаю себе отчет, что тестовое может срезать специалистов высокого уровня, но с введением этой практики значительно выросло как минимальное, так и среднее время нахождения нанятых спеалистов в компаниях, т.е. люди, выполнившие тестовые, оказывались в среднем лояльнее. Это крайне важно, поскольку частые увольнения, особенно в небольших командах, сильно бьют по их устойчивости. Также на практике было проверено, что люди хорошо выполнившие тестовое и прошедшие собеседование, гораздо проактивнее в целом и быстрее разбираются в чём-то новом, т.е. дорасти до нужного уровня, если он ниже, чем хотелось бы, для них проще, а с учетом того, что они реже увольняются, время на это есть.
Компаниям, которые внедряют эту практику, могу посоветовать потратить время и сделать тестовое задание небанальным и интересным. От себя добавлю, что когда сам устраивался, то получал от интересных тестовых большое удовольствие, а неинтересные просто не делал, в этом смысле выбор всегда есть.
Если у вас всё замечательно с индексами субд, то какие тогда могут быть проблемы с хэш таблицей? Если же у вас есть проблемы с хэш таблицей, то я не уверен, что вы до конца понимаете индексы субд.
Это не совсем так. Если вас что-то не устраивает, вы всегда можете собрать команду единомышленников и продолжить. Могу привести пример из своего опыта, в своё время существовал AOT компилятор Java кода под иос под названием RoboVM: https://github.com/robovm/robovm, их с потрохами купил майкрософт и недолго думая на следующий год убил https://venturebeat.com/business/following-xamarin-acquisition-microsoft-will-kill-its-robovm-service-in-april-2017/ Мэйнтейнера разумеется по-майкрософтовски озолотили и скорее всего в контракте прописали, что этим больше заниматься не надо. Казалось бы всё, финита. Но нет, появился форк, который прекрасно дожил до наших дней, последние комиты в мастер за прошлый месяц https://github.com/MobiVM/robovm. Опенсурс силён тем, что если людям что-то сильно надо, то они могут заняться этим сами несмотря ни на что. Всё остальное, включая что кто-то чей-то PR не принял и почему это произошло - наносное.
Они исправились, потому что это было хорошо для их бизнеса. В случае, который мы рассматриваем, в текущих обстоятельствах, для бизнеса мэйнтейнеров флюттера хорошо другое. А если говорить про рандомного одинокого мэйнтэйнера, то как ему лучше делать, решает только он сам. Правда случались прецеденты, когда из-за этого были проблемы у всех (https://en.wikipedia.org/wiki/Npm_left-pad_incident), но это скорее говорит про незрелость платформы в те годы, а по-хорошему мэйнтэйнер должен иметь право делать то, что он считает нужным в рамках тех возможностей, которые ему предоставляются платформой. В конце концов он тратит своё время, а в случае компаний свои деньги и упрекать их за некую предвзятость - это то же самое, что ругаться на киоск с бесплатным мороженным, что он неудобно стоит.
Казалось бы open source у вас никто не отнимает. Код открыт, лицензия щадящая, форкайте и наслаждайтесь. А что касается разрешения на коммиты, то это не про open source, по хорошему майнтэнер вообще может никого не слушать и делать, что хотеть, open source как таковой его ни к чему не обязывает кроме открытия кода.
Это работает немного по-другому, непосредственный руководитель человека должен обязательно присутствовать на собеседованиях, чтобы понимать, что в голове у потенциального сотрудника, а сотрудник соответственно понимать, какие ожидания у руководителя.
Видите, как я написал в комментарии мой пост был про "хорошего" сотрудника, таким сотрудником я в силу своего опыта считаю только тех, для кого деньги не являются основным мотиватором. А что является? Интерес к отрасли, к технологиям, любопытство, стремление к познанию и саморазвитию (возможно неосознанное). И безусловно недовольство и даже обида, когда руководитель оказывается "не тот". Не потому, что платит мало денег. А потому, что "ведет компанию не туда", "выбирает не те технологии", "не хочет прислушиваться к профессионалам"... Именно для людей в такой ситуации я писал комментарий, а не тех, кто ставит материальную выгоду во главу угла. Деньги конечно важны, но "хороший" сотрудник в моём понимании - это человек, для которого в принципе может существовать вакансия, ради которой он готов пожертвовать материальной выгодой, пусть это и не та компания, в которой он работает сейчас. То, о чём пишете вы - я хорошим сотрудником не считаю и с такими людьми обычно долго не разговариваю. Вы скажете - это удобная позиция для руководителя и невыгодная для сотрудника. На поверхности это выглядит так, но если вы рассмотрите типичную карьеру сотрудника, для которого материальная выгода является вторичной перед нематериальной, то в конечном счёте через некоторое время выяснится, что он и зарабатывает больше и позиция у него выше и кругозор шире. Я не хочу вас переубеждать, это просто мой опыт.
Начал читать статью со скепсисом, но в итоге дочитал с интересом. Из своего 19 летнего опыта могу сказать, что практически со всем согласен. Отдельно хочу заметить про четвертый пункт: часто бывает такое, что и сотрудник хороший и руководитель неплохой, но вместе работать не могут. Никак. При другом руководителе всё было классно, при этом плохо. А у руководителя при этом с большинством сотрудников всё идеально. Я бывал с обеих сторон этой ситуации и могу дать совет сотруднику - надо отпустить и уйти. Не потому что ты плохой, неэффективный, халявщик, или непризнанный герой-правдоруб, а потому что в этой ситуации нет хороших решений, и копаться в причинах скорее всего бесполезно - вы не подходите друг другу. Но есть решение, которое чуть лучше, чем другое. Уход сотрудника по собственному желанию без скандала во-первых открывает перед ним новые горизонты рынка труда и обычно увеличение зарплаты, во-вторых это новые вызовы, новые технологии, возможно уход в смежную деятельность, короче всё, что принято называть развитием. И в-третьих о человеке останется хорошая память в команде: был не согласен с руководством, развернулся и сам ушёл, сохранил принципы, не изменил себе и т.д. Поверьте, репутация такого человека очень поможет вам в будущем, ваши бывшие коллеги через nное кол-во лет могут всё это вспомнить и сделать интересный оффер, хорошая репутация всегда хорошо запоминается. Ну а вторая опция - стоять до конца, саботировать, мочить в курилке и т.д. Обычно эта опция приятнее в моменте, но последствия будут значительно менее приятными причем не только для вас, но и для команды в целом.
Если мало ли вы попадете в такую ситуацию, смело выбирайте первый вариант. Если же вы руководитель, дайте человеку немного времени, пару раз намекните, что в мире много интересного помимо вашего болота, ну а потом, что делать, увольняйте.
Самое удивительное в истории с микросервисами - это как люди много лет делали вид, что все в порядке, и вдруг к середине 20х годов прозрели, что они не гугл, а бизнесу больше неинтересно слышать в качестве причины для увеличения бюджета/сроков "особенности архитектуры". Я хорошо помню свой шок от того, как в 16 году руководство настойчиво предложило мне "поделить всё на 10" - вместо одного приложения, репозитория, ci/cd и базы сделать 10. "-Зачем?" "-Так надо!" "-Нас пятеро, нас не 50!" "-Суть не в этом, мы изолируем бизнес области" "-У нас же все разбито по модулям, все изолировано!" "-Это не то!". Мне стоило больших усилий тогда отговорить их, хотя информационный фон этому мягко говоря не способствовал. 10 years later... и эти усилия к счастью больше не нужны. Начинаешь снова верить в здравый смысл.
Это можно, но тогда у каждого метода будет свой "in" объект и свой "out" объект. Для внешнего апи действительно, лучше так и делать, но для внутреннего, это выглядит тяжеловато особенно с учетом того, что компилятор подскажет тому, кто изменил метод, где еще нужно поменять и, например, если перед комитом обязательно делать билд, то без исправления всех мест человек просто не сможет отправить изменение, т.е. проблема обратной совместимости автоматизируется, а не энфорсится битьём по голове. Это работает почти из коробки для монорепы, если же речь о наборе репозиториев, то помучавшись чуть дольше можно настроить процесс так, чтобы перед коммитом собирались все репозитории с новыми изменениями. Еще как вариант - сделать полиморфный метод, со старой сигнатурой, который вызовет новый метод с дефолтными параметрами.
Аспекты вполне работают для библиотечного кода, например аннотация Transactional из спринга оборачивает метод соответствующим аспектом. А если вы когда-либо использовали библиотеку javamelody для observability, то там целый набор аспектов, которые регистрируют разные события и считают метрики абсолютно независимо от вашего кода и не требуя от вас практически ничего, кроме добавления зависимости и включения в код одной аннотации. Что касается джунов, то как ни странно, джун джуну рознь, есть толковые ребята, которые все схватывают на лету.
Про обертки над библиотеками двумя руками за. Много раз это спасало. Из последнего, меняли реализацию http библиотеки с okhttp на java http клиент, чтобы произвести замену нам пришлось переписать только один класс - собственно реализацию нашей обертки и всё, это очень экономит время.
Про параметры api согласен не до конца. Если речь про внутренний программный API и речь идет о строго типизированном языке, то лучше иметь конкретные параметры, которые нужны в данный момент. После их изменения компилятор подскажет вам, где нужно поменять код, а если делать универсальный нетипизированный параметр, то да, расширить его будет просто, но поправить все места, где это требуется будет сложнее.
Если же речь про внешний апи, то лучше всего и входные и выходные значения оборачивать в объект и добавлять в него поля по необходимости, либо, что, конечно, более правильно но дольше, делать api/v2/ с новым интерфейсом.
Что касается колбэков, то у разных языков есть разные механизмы, которые позволяют не тащить специфику middleware в параметрах по стеку вызовов. Для Java, например, можно использовать аспекты, на которых построено много интересного, от общих вещей вроде observability и транзакционности, до реализации бизнес специфичных требований. Этим не стоит увлекаться, иначе есть шанс получить сложно отлаживаемые ситуации, но часто это гораздо лучше, чем протаскивать лишнее в сигнатурах.
Пропустили пожалуй самый важный Jep - 491. Если кто не в курсе, проблема, которую он решает - это последняя преграда для того, чтобы можно было полноценно использовать Loom не боясь неприятностей (читай - дедлоков) от synchronized. Если вдруг вы не в курсе, что такое Loom, очень рекомендую прекрасную статью https://www.infoq.com/articles/java-virtual-threads. Спойлер: мучиться с async больше будет не нужно.
Удалено
В старом интерфейсе они хотя бы были. В новом всё скрыто за несколькими слоями различных меню по принципу hotkey or die.
Не было никаких проблем с тем, чтобы двигаться с Classic UI вперед. Добавлять AI и новые функции можно было легко и в нём. Полностью всё менять в угоду сомнительной моде было совершенно необязательно.
Нет, этого недостаточно. Я говорю не только за себя. Это ясно видно из статистики скачиваний и комментариев к плагину classic ui.
То, что Jetbrains делает с UI/UX своих продуктов в последние 3 года - это очень плохо. Я не знаю, что точно у них изменилось внутри компании, но невооружееным глазом видно, что важные решения теперь принимаются без оглядки на пользовательский опыт. Похоже их стратегией стало: "Догнать и перегнать Vscode", а что там на местах происходит - это проблема мест.
Если коротко отвечать автору, то нет, ООП не так плох, как написано в статье, а Java до сих пор один из лучших языков программирования.
Всегда удивлялся, что люди после java переходят на go. Единственный реальный плюс, который был актуален до недавнего времени, это горутины (сейчас после релиза loom это больше не актуально). Другие аргументы вроде "spring сложный, аннотации неочевидны" мягко скажем не про java и если у вас нет необходимости их использовать - это необязательно. Но больше всего меня поразило, когда в go наконец завезли генерики и я даже рассматривал его как потенциальный язык для следующего проекта, внезапно значительная часть комьюнити начала их хейтить, мол оно нам не надо. Это чем-то напомнило мне, как мои родители долго не переходили на смартфоны: "нам нужен кнопочный".
Много раз писал об этом на хабре, но раз уж есть целая статья о том, какие тестовые задания плохие, напишу еще раз. Тестовые задания работают. Я даю их уже много лет и нахожу с помощью них прекрасных специалистов, при этом не выгорая на разгребании сотен холодных откликов. Я не использую код в рамках тестовых в продакшене. Любому, кто сделал тестовое я оставляю обратную связь. С любым кто сделал тестовое хорошо, я разговариваю. Разговор я всегда начинаю с тестового задания, которое в дальнейшем выступает лейтмотивом разговора и предметом life-кодинга. За все эти годы ни разу поиск не занимал больше полутора месяцев. Я отдаю себе отчет, что тестовое может срезать специалистов высокого уровня, но с введением этой практики значительно выросло как минимальное, так и среднее время нахождения нанятых спеалистов в компаниях, т.е. люди, выполнившие тестовые, оказывались в среднем лояльнее. Это крайне важно, поскольку частые увольнения, особенно в небольших командах, сильно бьют по их устойчивости. Также на практике было проверено, что люди хорошо выполнившие тестовое и прошедшие собеседование, гораздо проактивнее в целом и быстрее разбираются в чём-то новом, т.е. дорасти до нужного уровня, если он ниже, чем хотелось бы, для них проще, а с учетом того, что они реже увольняются, время на это есть.
Компаниям, которые внедряют эту практику, могу посоветовать потратить время и сделать тестовое задание небанальным и интересным. От себя добавлю, что когда сам устраивался, то получал от интересных тестовых большое удовольствие, а неинтересные просто не делал, в этом смысле выбор всегда есть.
Если у вас всё замечательно с индексами субд, то какие тогда могут быть проблемы с хэш таблицей? Если же у вас есть проблемы с хэш таблицей, то я не уверен, что вы до конца понимаете индексы субд.
Это не совсем так. Если вас что-то не устраивает, вы всегда можете собрать команду единомышленников и продолжить. Могу привести пример из своего опыта, в своё время существовал AOT компилятор Java кода под иос под названием RoboVM: https://github.com/robovm/robovm, их с потрохами купил майкрософт и недолго думая на следующий год убил https://venturebeat.com/business/following-xamarin-acquisition-microsoft-will-kill-its-robovm-service-in-april-2017/
Мэйнтейнера разумеется по-майкрософтовски озолотили и скорее всего в контракте прописали, что этим больше заниматься не надо. Казалось бы всё, финита. Но нет, появился форк, который прекрасно дожил до наших дней, последние комиты в мастер за прошлый месяц https://github.com/MobiVM/robovm.
Опенсурс силён тем, что если людям что-то сильно надо, то они могут заняться этим сами несмотря ни на что. Всё остальное, включая что кто-то чей-то PR не принял и почему это произошло - наносное.
Они исправились, потому что это было хорошо для их бизнеса. В случае, который мы рассматриваем, в текущих обстоятельствах, для бизнеса мэйнтейнеров флюттера хорошо другое. А если говорить про рандомного одинокого мэйнтэйнера, то как ему лучше делать, решает только он сам. Правда случались прецеденты, когда из-за этого были проблемы у всех (https://en.wikipedia.org/wiki/Npm_left-pad_incident), но это скорее говорит про незрелость платформы в те годы, а по-хорошему мэйнтэйнер должен иметь право делать то, что он считает нужным в рамках тех возможностей, которые ему предоставляются платформой. В конце концов он тратит своё время, а в случае компаний свои деньги и упрекать их за некую предвзятость - это то же самое, что ругаться на киоск с бесплатным мороженным, что он неудобно стоит.
"Очень жаль, что в 2025 году open source..."
Казалось бы open source у вас никто не отнимает. Код открыт, лицензия щадящая, форкайте и наслаждайтесь. А что касается разрешения на коммиты, то это не про open source, по хорошему майнтэнер вообще может никого не слушать и делать, что хотеть, open source как таковой его ни к чему не обязывает кроме открытия кода.
Сферический патриIТизм в вакууме. Наблюдать за этим явлением рекомендуется из самой дальней точки вселенной.