Опытному рекрутеру достаточно просто побеседовать с кандидатом, чтобы составить психологический портрет и все понять про человека. Правильные вопросы помогают раскрыть отношение кандидата к тому, что интересует рекрутера. Из ответов мы формируем вывод — подходит ли человек компании или нет.
Любой человек, осознанно или нет, запоминает социально-желательные ответы чтобы лучше справляться с порядками общества, в котором находится. Что говорить про кандидатов, которые находятся в активном поиске работы. Хоть посреди ночи их разбудите, они вам споют самые сладкие песни про свой психологический портрет работника.
Как бы там ни было, можете привести несколько правильных вопросов которые дадут вам всё понять про человека?
Реагируют не на слово, а на безосновательные обобщения. Я вот например нагуглил что по МКБ (в российской медицинской практике), термин "шизоидный тип личности" является патологией. И мне в принципе не хотелось бы от карьерного психолога слышать что очевидно я шизоид, раз решил работать программистом.
А так, смотрите, я тоже, своего рода, интернет психолог и разбираюсь в теме:
Возьмем, например, профессию карьерного психоаналитика. Очевидно, что туда идут люди, получающие удовольствие от мыслительного процесса в одиночку, которым с домыслами и фантазиями проще, чем с реальной научной работой по нейропсихологии. В психоаналитике очень много специалистов с так называемым бредовым типом самосознания личности, которая выражается в крайней степени переоценки значимости собственного мнения
Ну и ещё парочка забавных фактов: На момент написания этой статьи (06.07) баблишко так и не выплатили
Меня позабавило что для получения призовых нужно написать заявление в бумажном виде и отправить оригинал с подписями в Москву. Довольно иронично в контексте хакатона "лидеры цифровой трансформации".
Как бы там ни было, с выводами я согласен, участвовать стоит. Это ещё хороший вариант для проверки собственных амбиций и навыков, если вдруг заскучали на рутиной работе.
Когда ко мне, как к нанимающему менеджеру, приходят с просьбой прособеседовать человека на должность, я сначала спрошу: а чем он должен будет заниматься?
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.
Я правильно понимаю что BDUI это современная реинкарнация HATEOS?
Проблема в том, что подобные решения пригодны только для унифицированного интерфейса. Например, для старых банковских терминалов или текстовых консолей.
Интерактивность и разнообразие пользовательских сценариев неизбежно приведёт к тому что вам придется выбрать одну из стратегий:
Клепать на каждый сценарий отдельный виджет
Делать конфигурацию виджетов гибче и подробнее
Вторая не рабочая, потому что ведёт к изобретению собственного языка разметки вроде HTML. Это бессмысленная работа, проще реализовать механизм динамического обновления клиента на используемом стеке UI.
Для решения этой проблемы мы решили собраться и подумать, а что у нас получилось - в следующей статье
То что вы перечислили, в российских компаниях называется нематериальной мотивацией, к социальным гарантиям это действительно не относится.
К сожалению, большинство компаний на практике использует эти мотивации буквально для уменьшения зарплаты сотрудников. Расчет очень простой. Из вашей потенциальной зарплаты вычитают сумму и её половину вам выдают в виде талончиков в соседнюю столовку знакомого дядьки или по рекомендации бизнес-центра.
Применительно к небольшим компаниям, очень наивно полагать что эти плюшки вам выдают дополнительно к рыночной зарплате.
Не верьте мне на слово, из интереса просто, посчитайте сколько стоит бюджетный ДМС, аренда кофемашины и партнёрская программа в спортзал на одного сотрудника, и насколько это соотносится с разницей к верхнему уровню зарплат по его должности.
И еще не забывайте, что работодатель платит не только зарплатой, но и социальными плюшками.
И ещё не забывайте, что социальные гарантии это не "плюшки", а обязанность работодателя в рамках трудового кодекса. Наличие таких гарантий не может быть поводом для уменьшения зарплаты.
В целом, нормально спрашивать на собеседовании о том, есть ли какие-то правила пересмотра зарплаты, если этот вопрос вас волнует (но не задавайте его первым — это правило хорошего тона).
Нет такого правила. Наличие в компании четких процедур пересмотра зарплаты имеет прямое отношение к качеству процессов и порядку в компании, её заинтересованности в развитии и удержании сотрудников. Стоит спрашивать о таких вещах в первую очередь.
Ну, вы и ruomserg сразу стали представлять неадекватную команду, которая хочет принять решение явно противоречащее интересам команды. Давайте представим, что у команды и компании в целом всё в порядке с целеполаганием и взаимопониманием.
Например:
Компания бережёт свою репутацию, хочет сохранить всех своих текущих клиентов и остро нуждается в новых для выполнения стратегии по развитию бизнеса. Появляется новый крупный клиент, который готов воспользоваться услугами вашей компании, при условии, что вы обеспечите новый функционал. Техническая команда это не оспаривает, но решает обеспечить функционал только в следующем году. Приводит технические аргументы, подсвечивает риски для существующих клиентов и т.д. Менеджмент выше, далёкий от технических деталей, понимает только то что у него уходит выгодный клиент, требует от вас функционал всё же реализовать.
У вас не было таких ситуаций? В разных масштабах такое происходит в любой IT компании регулярно. Если тема серьёзная, функционал сложный, и ответственность высока - это превращается в час Х. В этот час вы, как руководитель, рискуете потерять не только вовлеченность, но и ведущих сотрудников, если их экспертное решение будет проигнорировано.
Свой вопрос я озвучил потому в российских IT компаниях много говорят про ответственность, но не говорят про полномочия, которые должны быть неотделимы от этой ответственности. И не говорят про последствия такого несоответствия.
Если результат голосования по сути ни на что не влияет. То есть голосовать предлагают только за удобные и заранее принятые сверху варианты решений - то такое голосование создаёт опасную для компании видимость вовлечения сотрудников в процесс развития компании.
В статье написано, что повысилась лояльность и вовлеченность сотрудников. Она могла повыситься только потому что сотрудники восприняли голосование как реальную возможность проявить свою волю позже, в тот самый час Х. Если руководитель будет не готов понести эту волю против интереса компании, не создаст каналы обратной связи и механизмы верификации таких решений - вся лояльность и вовлеченность рухнет.
Можно читать книжки, статьи на эту тему. Кому-то это поможет, но имхо это один из тех навыков, которые приобретаются не за счет изучения теории, а целиком из практики. Невозможно научиться кататься на велосипеде по книжке, сразу сев и поехав
А ещё в некоторых книгах пишут что существуют разные виды навыков. Например, двигательные навыки требуют многократных мышечных повторений и понимания техники их исполнения. В то время как когнитивные навыки основаны на памяти, и работают преимущественно благодаря ранее освоенным знаниям, благодаря теории. Можно проваливать проекты один за другим, навык их ведения не появится без соответствущих знаний.
Например, давайте поговорим про управление рисками.
Примеры применительно к работе: возможность выйти разработчикам работать в выходные взамен, например, будущих дополнительных выходных или сверхурочных (если у вас такое возможно).
То что вы хитро назвали "boosting", по книжкам называется перенос рисков. Отправляя разработчиков на внеурочку вы не только передаете им управление сработавшим риском, но и переносите ответственность за возможные дефекты. А эти дефекты обязательно будут учитывая внеплановость и стрессовость ситуации. Кроме того, предлагая неравнозначное вознаграждение в виде выходных вы еще и создаёте новый риск демотивации сотрудников.
Перенос рисков на исполнителей самый очевидный и для многих (не)менеджеров единственный способ управлять риском, потому что других не знают. Хотя в книгах и статьях на эту тему есть разнообразие:
дублирование, одна реализация разными командами
диверсификация, разная реализация одной фичи
предотвращение, отказ от фичи
эксплуатация, превращение риска в фичу
и т.д.
Конечно невозможно быть прорицателем и предсказать все риски. Но работа с рисками сама по себе вполне предсказуемый процесс. Теоретическая база для этого есть: как спланировать большую часть рисков, как их актуализировать, сделать прозрачными, и т.д. Полностью отказываться от такой работы ради "у меня хороше предчувствие, а если че, подключу разработчиков" не приемлемо.
Так что предлагаю всё же читать книги и статьи. И не распускать миф о том что менеджером может стать каждый, без каких либо знаний, стоит только захотеть.
Я думаю, что в ходе отработки реальных проблем рождается необходимая любому PM-у интуиция, которая лишает его иллюзий, что все можно предусмотреть и спланировать.
Вы не поверите что пишут про интуицию в современных книгах. Спойлер. Это накопленные знания.
Высокий порог входа, особенно для тех, кто вообще не имеет опыта в программировании. Дело в том, что в Rust используется сущность «время жизни» ...
Думается мне, для тех кто вообще не имеет опыта программирования любой язык создаёт высокий порог входа. Будут там механизмы заимствования, сырые указатели или приколы с value и reference объектами — для новичка всё это одна головная боль.
Компилятор Rust мало того что сразу говорит о проблеме, так в некоторых случаях буквально подсказывает какой код нужно написать чтобы заработало. Я думаю это гораздо проще для новичков, чем ловить непонятные проблемы в рантайме.
А вот для опытных разработчиков Rust действительно сложен. Борьба с компилятором постепенно сменяется осознанием отвественности за владение тем или иным объектом, начинаешь учиться программированию заново, вспоминаешь зачем нужно проектирование, архитектура приложения и т.д.
Тоже заказывал диск по почте. Бандеролька пришла из Нидерланд. На диске были изображены счастливые люди разных рас, держащиеся за руки, как на картинке в статье...
Мама подумала что я попал в секту, сидела со мной рядом и смотрела как я устанавливаю систему с этого диска.
На мой взгляд, это всё равно лучше, чем если бы на продакшн сервисе оказался неверно имплементированный метод или несовпадение со спецификацией.
Так я же не отрицаю. Это я к тому, что не все языки как Java умеют гарантировать соответствия интерфейса реализации. Поэтому, если надо, можно использовать формальность API спеки и реализовать проверку в более общем виде. Это еще одно преимущество API-First.
Не отрицает, я под Agile адептами имел в виду некоторый собирательный образ мейнстримового IT менеджера, для которого проектирование API звучит как саботаж эффективной работы, как призыв к "устаревшим" моделям управления разработкой.
А по сути нет никакого "API-First" подхода. Есть рациональный и давно известный подход — сначала анализируешь, проектируешь, затем реализуешь. И это даёт все перечисленные в статье преимущества.
Просто в один момент отрасль поразила идея, что для эффективной разработки можно только "обсудить на митинге", а всё остально табу. Вот и приходится уже существующие практики и опыт преподносить по новому, придумывать новые названия, лишь бы не пугать тех самых менеджеров.
Ирония в том, что этот подход не что иное, как воплощение классических этапов разработки, о которых всё время твердят олды, но шарахаются Agile адепты: проектирование и системный анализ.
На практике именно так. Четкая спецификация API позволяет бустануть разработку в разы, автоматизировать некоторую деятельность, увеличить качество и стабильность софта.
Я бы еще добавил, что наличие генерируемых интерфейсов для сервера не гарантирует вам что они будут реализованы. Поэтому на сервере можно добавить механизм, который будет явно верифицировать спеку и реализованный бэкенд.
Любой API фреймворк фактически регистрирует все модели и роуты, достаточно привести это к формату вашей спеки и сравнить. Так на продакшене точно не окажется сервис, который реализует заявленный API не полностью.
Это особенно актуально для динамических языков типа Python.
А зачем вы сразу драматизируете и рисуете образ Васи у которого проблемы общения с девушками? Давайте без эмоций, рационально и аргументировано.
Мои примеры вполне реальны, а не абстракты. В родном городе лет 15 назад была примерно такая картина:
60к помощник водителя белаза на комбинате сразу после ПТУ
40к продавец бытовой техники (с учетом бонусов)
40к инженер-программист на том же комбинате
10к программист в отдел статистики больницы
А описываемые в негативном ключе сокурсники Васи, скорее всего, прекрасно понимают как устроена жизнь.
Даже те, кто был близок к IT (поднимал локалку по городу или играл в компьютерные игры) шли сразу в ПТУ. Зачем учится в универе, тратить свои выходные на программирование, инвестировать в самообразование, если можно совершить очевидный выбор?
Теперь рынок другой. Водители белазов имеют 120к и профессиональные болезни, а программисты отделов статистики по 240-360к.
Только вот "устройство жизни” не изменилась. Как тогда нужно было образовываться в технических темах, так и сейчас. Но некоторые думают, что достаточно пройти курс, как они раньше "сдавали на разряд" для формальной прибавки к зарплате. В этом месте и происходит конфликт взаимопонимания.
Не удивительно что многие реагируют и пытаются улучшить свои условия жизни переходя в денежную отрасль. Осуждать за такие стремления людей нельзя, я думаю, это же очевидно и разумно. Но где тут понимание как устроена жизнь, о которой вы говорите?
Будем реалистами, индустрия и деньги в ней подросли вовсе не от того, что Вася не мог общаться с девушками и потому все свое свободное время учился. Вася тут точно такой же пассажир, удачно оказавшийся в нужном месте.
Кто, по-вашему, развивает индустрию? Буквально, кто открывает новые технические решения и приёмы? Допустим раньше да, была распространена модель поставки коробочных проприетарных решений для бизнеса. Штат разработчиков коммерческих компаний, по сути, и развивал отрасль.
Сейчас разве так? На мой взгляд, сейчас даже в крупных компаниях используются наработки тех самых Вась, которые по выходным пишут новые опенсорс тулы и фреймворки, чтобы те самые средние разработчики были способны сделать типовые задачи бизнеса.
Вы по умолчанию считаете всех нас идиотами, которые где-то услышали о том что "программисты нормально поднимают бабла", тут же разбили мамкину копилку и побежали платить за курсы.
Сокурсники и друзья нынешних IT специалистов кутили по выходным, отмахивались от необходимости образовываться, шли за "лёгкими деньгами" в продажи или на водителя белаза, посмеиваясь над тыж-программистами, которые всё свое личное время тратили на образование технических дисциплин и технологий.
А теперь, когда всё готово, и зарплаты подросли, че бы не стать "коллегами", да? Дайте только инструкцию, желательно покороче в виде интерактивного курса!
Как ещё должны реагировать специалисты на сложившуюся ситуацию?
Знаете в чём ваша ошибка? Ну конечно знаете, а я всё равно скажу: пока вы прилаживались менять мир, этот самый мир изменился
Приятно, конечно, чувствовать себя на волне, но увы. При внешней изменчивости, некоторые принципы жизни не меняются столетиями.
Так, чтобы стать востребованным и оплачиваемым специалистом нужно потратить годы практики и теории. Нет и не может быть волшебного курса за пару месяцев, который изменит вашу жизнь к лучшему. Считать ли людей идиотами, которые этого не понимают?
Так давайте не будем рефлексировать о прошлом, но воспользуемся всеми прелестями настоящего! Давайте сотрудничать, КОЛЛЕГИ!
Давайте. Расскажу только историю успеха сначала.
Мой друг детства проработав до 30 бухгалтером, решил податься в IT. Естественно он проигнорировал все мои советы и рекомендации. Чудесное предложение платных курсов на пару месяцев ему показалось гораздо реалистичнее.
В итоге курсы ему не помогли. Вход в IT затянулся на два года мучений и разочарований, собеседований, стажировок и прочего. Он не сдался и сейчас работает в Яндексе. Но зарплатные ожидания пока не сбываются, впереди еще несколько лет профессионального развития.
Его стремление и старания вызывает уважение, он молодец. Думаю что от таких джунов никто не откажется.
Однако “прошареных по жизни” людей, которые реально думают, что для входа в отрасль достаточно собственного жизненного опыта и обучающего курса на пару месяцев — называть джунами, и уж тем более сотрудничать, спасибо не надо.
Интеграционная или shared база данных это архитектурный подход с которым мне часто приходилось сталкиваться, и практически никогда эта встреча не сулила ничего хорошего.
Так это вы ещё не встречались значит с проблемами подходов, которые не используют общую базу.
Суть ведь не меняется. У вас есть одна предметная область, но разные сценарии и требования, которые вызывают конфликты в моделях.
Что вам сулит много хорошего: микросервисы, serverless, акторы? Допустим, микросервисы. Решать придётся точно такие же проблемы:
Менять API микросервиса страшно. Вам так же придется бегать по потребителям и проверять не используют ли они изменяемый API.
Точно так же у вас появится shared микросервис. Если им владеет другая команда, вы получите все перечисленные организационные проблемы.
Отказавшись от shared базы в пользу микросервисов, вам придется так же отказаться от многих плюшек. Опытные DB девелоперы умеют аудит через механизмы СУБД, умеют генерировать динамический SQL, расширять возможности базы, гибко настраивать политики доступа, встраиваться в аналитические системы и прочее.
Объединять потоки коммуникации микросервисов тоже становится невозможно или очень сложно. Например, у вас один сервис GraphQL, другой REST, а третий gRPC. Новая команда аналитики хочет получить доступ к некоторым данным в потоке из этих сервисов. Им вместо банальной выгрузки из базы придется писать адаптеры для всех перечисленных протоколов. Или идти напрямую в хранилища этих сервисов... Oh, wait! Это же нарушение инкапсуляции.
Классические СУБД и архитектура с общей базой данных успешно функционируют уже 40 лет. И не зря. Как минимум инструментально, это позволяет решать многие проблемы наших систем. В то время как другие подходы за иллюзорной простотой могут скрывать проблемы, решение которых может и не существует даже.
Так что пока эти решения не найдём, называть shared базу данных антипаттерном рановато.
Нужно изменить одну функцию, которая затрагивает 20 других сервисов.
По правилам разработки библиотечного кода. Через обратную совместимость. В сложных случаях у вас будет две версии функции одновременно. Устаревшую версию удаляете только когда все потребители перейдут на новую версию.
Как делать хотфикс, если функционал из убежавшего вперед мастера еще не должен быть выпущен?
Если проект большой и в него комитят хотя бы десяток человек, вы будете один и тот же фикс реализовывать столько раз, сколько релизов у вас на текущий момент.
Вообще TBD не новое изобретение. Так работали практически все системы контроля версий до эпохи git. Этот недостаток и стал одной из ключевых причин популярности git и git flow лет 10 назад.
Интерес к TBD возобновился в контексте применения непрерывной разработки и доставки сервисов. Когда вы ежедневно выкатываете новую версию сервиса, а цена ошибки не велика — в принципе теряется значение таких понятий как "hotfix" и "develop".
Если у вас есть необходимость в релизных ветках и продолжительной поддержке — это прямой сигнал что к TBD вам возвращаться не стоит.
Как при таком подходе делать рефакторинг?
Очень хорошо. Фактически у вас не должно быть старых веток. Цикл обновления очень короткий. Всё это сводит вероятность конфликтов при слиянии рефакторинга к минимуму.
Другой вопрос что рефакторинг тоже нужно уметь делать, вносить по очереди типовые изменения, а не всё в кучу одним супер коммитом. Но это уже не проблема TBD.
Любой человек, осознанно или нет, запоминает социально-желательные ответы чтобы лучше справляться с порядками общества, в котором находится. Что говорить про кандидатов, которые находятся в активном поиске работы. Хоть посреди ночи их разбудите, они вам споют самые сладкие песни про свой психологический портрет работника.
Как бы там ни было, можете привести несколько правильных вопросов которые дадут вам всё понять про человека?
Реагируют не на слово, а на безосновательные обобщения. Я вот например нагуглил что по МКБ (в российской медицинской практике), термин "шизоидный тип личности" является патологией. И мне в принципе не хотелось бы от карьерного психолога слышать что очевидно я шизоид, раз решил работать программистом.
А так, смотрите, я тоже, своего рода, интернет психолог и разбираюсь в теме:
Меня позабавило что для получения призовых нужно написать заявление в бумажном виде и отправить оригинал с подписями в Москву. Довольно иронично в контексте хакатона "лидеры цифровой трансформации".
Как бы там ни было, с выводами я согласен, участвовать стоит. Это ещё хороший вариант для проверки собственных амбиций и навыков, если вдруг заскучали на рутиной работе.
Последнее время практикую именно такой подход. Задаю вопросы по опыту кандидата в контексте предстоящих бизнес задач. Ключевые преимущества, на мой взгляд, следующие.
Комфортный диалог
Стресс улетучивается, кандидат открывается как только понимает что он не на экзамене, а на совместном обсуждении причин для сотрудничества.
Вообще получается что модель типичного собеседования “я оцениваю тебя” превращается в “мы обсуждаем что можем сделать вместе”. Это начинает больше походить на диалог потенциальных партнеров, поэтому кандидат проявляет больше заинтересованности и инициативы.
Вы точно поймете уровень кандидата
Прикол в том, что вы уже реально работаете вместе, выполняя первый этап любой задачи – её обсуждение.
Если обсуждение развивается, вопросы кандидата вам кажутся подходящими, предложения не вызывают сомнений – значит вы сработаетесь. Разве не это настоящая цель любого собеседования?
Если интервьюер не может отличить заученные слова кандидата от реального опыта, не может понять корректность и применимость технической экспертизы – то как он у вас работает вне собеседований на реальных задачах? Это уже проблема квалификации интервьюера, а не кандидата.
Кандидат получает ответы на свои вопросы
Вспомните насколько абсурдным иногда бывает техническое интервью: после нескольких часов абстрактных ребусов и задач, кандидату дают всего 5-10 минут на вопросы о реальном положении дел в компании, ещё и ответить внятно не могут некоторые.
Кандидат сможет сразу понять и оценить устройство вашей технической кухни, сможет сопоставить ваши требования и ожидания к собственной экспертизе, если вы ясно обозначите какие задачи хотите решать и почему.
Польза тут ещё в том, что вы уменьшаете риск ухода нового разработчика на период адаптации, потому что сразу решаете проблему несоответствия ожидания и реальности. Во всяком случае, я убежден, что это одна из самых частых причин: когда на техническом собеседовании компания Лев Толстой, а не деле формошлёп простой.
Решает проблему законсервированности текущих решений
Одна из проблем любой команды – это замыкание технической экспертизы на мнение текущих разработчиков. Кроме инертности и устаревания технических решений это приводит ещё и к проблеме найма. Разработчиков со свежим взглядом часто отфильтровывают не актуальными техническими вопросами.
Но если обсуждать реальные задачи, кандидат может на основе своего опыта предложить лучшее решение этих задач уже на этапе собеседования. А вместе с тем и дать импульс текущим разработчикам освежить свое техническое видение.
Я правильно понимаю что BDUI это современная реинкарнация HATEOS?
Проблема в том, что подобные решения пригодны только для унифицированного интерфейса. Например, для старых банковских терминалов или текстовых консолей.
Интерактивность и разнообразие пользовательских сценариев неизбежно приведёт к тому что вам придется выбрать одну из стратегий:
Клепать на каждый сценарий отдельный виджет
Делать конфигурацию виджетов гибче и подробнее
Вторая не рабочая, потому что ведёт к изобретению собственного языка разметки вроде HTML. Это бессмысленная работа, проще реализовать механизм динамического обновления клиента на используемом стеке UI.
Было бы интересно почитать что у вас получилось.
То что вы перечислили, в российских компаниях называется нематериальной мотивацией, к социальным гарантиям это действительно не относится.
К сожалению, большинство компаний на практике использует эти мотивации буквально для уменьшения зарплаты сотрудников. Расчет очень простой. Из вашей потенциальной зарплаты вычитают сумму и её половину вам выдают в виде талончиков в соседнюю столовку знакомого дядьки или по рекомендации бизнес-центра.
Применительно к небольшим компаниям, очень наивно полагать что эти плюшки вам выдают дополнительно к рыночной зарплате.
Не верьте мне на слово, из интереса просто, посчитайте сколько стоит бюджетный ДМС, аренда кофемашины и партнёрская программа в спортзал на одного сотрудника, и насколько это соотносится с разницей к верхнему уровню зарплат по его должности.
И ещё не забывайте, что социальные гарантии это не "плюшки", а обязанность работодателя в рамках трудового кодекса. Наличие таких гарантий не может быть поводом для уменьшения зарплаты.
Нет такого правила. Наличие в компании четких процедур пересмотра зарплаты имеет прямое отношение к качеству процессов и порядку в компании, её заинтересованности в развитии и удержании сотрудников. Стоит спрашивать о таких вещах в первую очередь.
Если гонитесь за скоростью, попробуйте ещё убрать аллокацию вектора. На большом количестве вызовов, должно быть ощутимо быстрее.
Ну, вы и ruomserg сразу стали представлять неадекватную команду, которая хочет принять решение явно противоречащее интересам команды. Давайте представим, что у команды и компании в целом всё в порядке с целеполаганием и взаимопониманием.
Например:
Компания бережёт свою репутацию, хочет сохранить всех своих текущих клиентов и остро нуждается в новых для выполнения стратегии по развитию бизнеса. Появляется новый крупный клиент, который готов воспользоваться услугами вашей компании, при условии, что вы обеспечите новый функционал. Техническая команда это не оспаривает, но решает обеспечить функционал только в следующем году. Приводит технические аргументы, подсвечивает риски для существующих клиентов и т.д. Менеджмент выше, далёкий от технических деталей, понимает только то что у него уходит выгодный клиент, требует от вас функционал всё же реализовать.
У вас не было таких ситуаций? В разных масштабах такое происходит в любой IT компании регулярно. Если тема серьёзная, функционал сложный, и ответственность высока - это превращается в час Х. В этот час вы, как руководитель, рискуете потерять не только вовлеченность, но и ведущих сотрудников, если их экспертное решение будет проигнорировано.
Свой вопрос я озвучил потому в российских IT компаниях много говорят про ответственность, но не говорят про полномочия, которые должны быть неотделимы от этой ответственности. И не говорят про последствия такого несоответствия.
Если результат голосования по сути ни на что не влияет. То есть голосовать предлагают только за удобные и заранее принятые сверху варианты решений - то такое голосование создаёт опасную для компании видимость вовлечения сотрудников в процесс развития компании.
В статье написано, что повысилась лояльность и вовлеченность сотрудников. Она могла повыситься только потому что сотрудники восприняли голосование как реальную возможность проявить свою волю позже, в тот самый час Х. Если руководитель будет не готов понести эту волю против интереса компании, не создаст каналы обратной связи и механизмы верификации таких решений - вся лояльность и вовлеченность рухнет.
Если большинство примет решение конфликтующее с интересами компании, что будете делать?
А ещё в некоторых книгах пишут что существуют разные виды навыков. Например, двигательные навыки требуют многократных мышечных повторений и понимания техники их исполнения. В то время как когнитивные навыки основаны на памяти, и работают преимущественно благодаря ранее освоенным знаниям, благодаря теории. Можно проваливать проекты один за другим, навык их ведения не появится без соответствущих знаний.
Например, давайте поговорим про управление рисками.
То что вы хитро назвали "boosting", по книжкам называется перенос рисков. Отправляя разработчиков на внеурочку вы не только передаете им управление сработавшим риском, но и переносите ответственность за возможные дефекты. А эти дефекты обязательно будут учитывая внеплановость и стрессовость ситуации. Кроме того, предлагая неравнозначное вознаграждение в виде выходных вы еще и создаёте новый риск демотивации сотрудников.
Перенос рисков на исполнителей самый очевидный и для многих (не)менеджеров единственный способ управлять риском, потому что других не знают. Хотя в книгах и статьях на эту тему есть разнообразие:
дублирование, одна реализация разными командами
диверсификация, разная реализация одной фичи
предотвращение, отказ от фичи
эксплуатация, превращение риска в фичу
и т.д.
Конечно невозможно быть прорицателем и предсказать все риски. Но работа с рисками сама по себе вполне предсказуемый процесс. Теоретическая база для этого есть: как спланировать большую часть рисков, как их актуализировать, сделать прозрачными, и т.д. Полностью отказываться от такой работы ради "у меня хороше предчувствие, а если че, подключу разработчиков" не приемлемо.
Так что предлагаю всё же читать книги и статьи. И не распускать миф о том что менеджером может стать каждый, без каких либо знаний, стоит только захотеть.
Вы не поверите что пишут про интуицию в современных книгах. Спойлер. Это накопленные знания.
Думается мне, для тех кто вообще не имеет опыта программирования любой язык создаёт высокий порог входа. Будут там механизмы заимствования, сырые указатели или приколы с value и reference объектами — для новичка всё это одна головная боль.
Компилятор Rust мало того что сразу говорит о проблеме, так в некоторых случаях буквально подсказывает какой код нужно написать чтобы заработало. Я думаю это гораздо проще для новичков, чем ловить непонятные проблемы в рантайме.
А вот для опытных разработчиков Rust действительно сложен. Борьба с компилятором постепенно сменяется осознанием отвественности за владение тем или иным объектом, начинаешь учиться программированию заново, вспоминаешь зачем нужно проектирование, архитектура приложения и т.д.
Тоже заказывал диск по почте. Бандеролька пришла из Нидерланд. На диске были изображены счастливые люди разных рас, держащиеся за руки, как на картинке в статье...
Мама подумала что я попал в секту, сидела со мной рядом и смотрела как я устанавливаю систему с этого диска.
Так я же не отрицаю. Это я к тому, что не все языки как Java умеют гарантировать соответствия интерфейса реализации. Поэтому, если надо, можно использовать формальность API спеки и реализовать проверку в более общем виде. Это еще одно преимущество API-First.
Не отрицает, я под Agile адептами имел в виду некоторый собирательный образ мейнстримового IT менеджера, для которого проектирование API звучит как саботаж эффективной работы, как призыв к "устаревшим" моделям управления разработкой.
А по сути нет никакого "API-First" подхода. Есть рациональный и давно известный подход — сначала анализируешь, проектируешь, затем реализуешь. И это даёт все перечисленные в статье преимущества.
Просто в один момент отрасль поразила идея, что для эффективной разработки можно только "обсудить на митинге", а всё остально табу. Вот и приходится уже существующие практики и опыт преподносить по новому, придумывать новые названия, лишь бы не пугать тех самых менеджеров.
Ирония в том, что этот подход не что иное, как воплощение классических этапов разработки, о которых всё время твердят олды, но шарахаются Agile адепты: проектирование и системный анализ.
На практике именно так. Четкая спецификация API позволяет бустануть разработку в разы, автоматизировать некоторую деятельность, увеличить качество и стабильность софта.
Я бы еще добавил, что наличие генерируемых интерфейсов для сервера не гарантирует вам что они будут реализованы. Поэтому на сервере можно добавить механизм, который будет явно верифицировать спеку и реализованный бэкенд.
Любой API фреймворк фактически регистрирует все модели и роуты, достаточно привести это к формату вашей спеки и сравнить. Так на продакшене точно не окажется сервис, который реализует заявленный API не полностью.
Это особенно актуально для динамических языков типа Python.
А зачем вы сразу драматизируете и рисуете образ Васи у которого проблемы общения с девушками? Давайте без эмоций, рационально и аргументировано.
Мои примеры вполне реальны, а не абстракты. В родном городе лет 15 назад была примерно такая картина:
60к помощник водителя белаза на комбинате сразу после ПТУ
40к продавец бытовой техники (с учетом бонусов)
40к инженер-программист на том же комбинате
10к программист в отдел статистики больницы
Даже те, кто был близок к IT (поднимал локалку по городу или играл в компьютерные игры) шли сразу в ПТУ. Зачем учится в универе, тратить свои выходные на программирование, инвестировать в самообразование, если можно совершить очевидный выбор?
Теперь рынок другой. Водители белазов имеют 120к и профессиональные болезни, а программисты отделов статистики по 240-360к.
Только вот "устройство жизни” не изменилась. Как тогда нужно было образовываться в технических темах, так и сейчас. Но некоторые думают, что достаточно пройти курс, как они раньше "сдавали на разряд" для формальной прибавки к зарплате. В этом месте и происходит конфликт взаимопонимания.
Не удивительно что многие реагируют и пытаются улучшить свои условия жизни переходя в денежную отрасль. Осуждать за такие стремления людей нельзя, я думаю, это же очевидно и разумно. Но где тут понимание как устроена жизнь, о которой вы говорите?
Кто, по-вашему, развивает индустрию? Буквально, кто открывает новые технические решения и приёмы? Допустим раньше да, была распространена модель поставки коробочных проприетарных решений для бизнеса. Штат разработчиков коммерческих компаний, по сути, и развивал отрасль.
Сейчас разве так? На мой взгляд, сейчас даже в крупных компаниях используются наработки тех самых Вась, которые по выходным пишут новые опенсорс тулы и фреймворки, чтобы те самые средние разработчики были способны сделать типовые задачи бизнеса.
Сокурсники и друзья нынешних IT специалистов кутили по выходным, отмахивались от необходимости образовываться, шли за "лёгкими деньгами" в продажи или на водителя белаза, посмеиваясь над тыж-программистами, которые всё свое личное время тратили на образование технических дисциплин и технологий.
А теперь, когда всё готово, и зарплаты подросли, че бы не стать "коллегами", да? Дайте только инструкцию, желательно покороче в виде интерактивного курса!
Как ещё должны реагировать специалисты на сложившуюся ситуацию?
Приятно, конечно, чувствовать себя на волне, но увы. При внешней изменчивости, некоторые принципы жизни не меняются столетиями.
Так, чтобы стать востребованным и оплачиваемым специалистом нужно потратить годы практики и теории. Нет и не может быть волшебного курса за пару месяцев, который изменит вашу жизнь к лучшему. Считать ли людей идиотами, которые этого не понимают?
Давайте. Расскажу только историю успеха сначала.
Мой друг детства проработав до 30 бухгалтером, решил податься в IT. Естественно он проигнорировал все мои советы и рекомендации. Чудесное предложение платных курсов на пару месяцев ему показалось гораздо реалистичнее.
В итоге курсы ему не помогли. Вход в IT затянулся на два года мучений и разочарований, собеседований, стажировок и прочего. Он не сдался и сейчас работает в Яндексе. Но зарплатные ожидания пока не сбываются, впереди еще несколько лет профессионального развития.
Его стремление и старания вызывает уважение, он молодец. Думаю что от таких джунов никто не откажется.
Однако “прошареных по жизни” людей, которые реально думают, что для входа в отрасль достаточно собственного жизненного опыта и обучающего курса на пару месяцев — называть джунами, и уж тем более сотрудничать, спасибо не надо.
Так это вы ещё не встречались значит с проблемами подходов, которые не используют общую базу.
Суть ведь не меняется. У вас есть одна предметная область, но разные сценарии и требования, которые вызывают конфликты в моделях.
Что вам сулит много хорошего: микросервисы, serverless, акторы? Допустим, микросервисы. Решать придётся точно такие же проблемы:
Менять API микросервиса страшно. Вам так же придется бегать по потребителям и проверять не используют ли они изменяемый API.
Точно так же у вас появится shared микросервис. Если им владеет другая команда, вы получите все перечисленные организационные проблемы.
Отказавшись от shared базы в пользу микросервисов, вам придется так же отказаться от многих плюшек. Опытные DB девелоперы умеют аудит через механизмы СУБД, умеют генерировать динамический SQL, расширять возможности базы, гибко настраивать политики доступа, встраиваться в аналитические системы и прочее.
Объединять потоки коммуникации микросервисов тоже становится невозможно или очень сложно. Например, у вас один сервис GraphQL, другой REST, а третий gRPC. Новая команда аналитики хочет получить доступ к некоторым данным в потоке из этих сервисов. Им вместо банальной выгрузки из базы придется писать адаптеры для всех перечисленных протоколов. Или идти напрямую в хранилища этих сервисов... Oh, wait! Это же нарушение инкапсуляции.
Классические СУБД и архитектура с общей базой данных успешно функционируют уже 40 лет. И не зря. Как минимум инструментально, это позволяет решать многие проблемы наших систем. В то время как другие подходы за иллюзорной простотой могут скрывать проблемы, решение которых может и не существует даже.
Так что пока эти решения не найдём, называть shared базу данных антипаттерном рановато.
По правилам разработки библиотечного кода. Через обратную совместимость. В сложных случаях у вас будет две версии функции одновременно. Устаревшую версию удаляете только когда все потребители перейдут на новую версию.
Если проект большой и в него комитят хотя бы десяток человек, вы будете один и тот же фикс реализовывать столько раз, сколько релизов у вас на текущий момент.
Вообще TBD не новое изобретение. Так работали практически все системы контроля версий до эпохи git. Этот недостаток и стал одной из ключевых причин популярности git и git flow лет 10 назад.
Интерес к TBD возобновился в контексте применения непрерывной разработки и доставки сервисов. Когда вы ежедневно выкатываете новую версию сервиса, а цена ошибки не велика — в принципе теряется значение таких понятий как "hotfix" и "develop".
Если у вас есть необходимость в релизных ветках и продолжительной поддержке — это прямой сигнал что к TBD вам возвращаться не стоит.
Очень хорошо. Фактически у вас не должно быть старых веток. Цикл обновления очень короткий. Всё это сводит вероятность конфликтов при слиянии рефакторинга к минимуму.
Другой вопрос что рефакторинг тоже нужно уметь делать, вносить по очереди типовые изменения, а не всё в кучу одним супер коммитом. Но это уже не проблема TBD.