а если мы, например, микросервисы пишем на каком-нибудь Micronaut или VertX? :)

Вполне может быть, просто Spring Boot, де-факто, самый распространенный фреймворк на сейчас ( дабы не начинать потенциальных холиваров, специально подчеркиваю — «распространенный», а не «самый лучший»)

або навіть Spring

сталкивался только с ElasticSearch, и то немного. Ну ОК, ещё Docker

Т.е. у вас скорее всего Java-стек в компании далеко не основной, так?

Имел крайне негативный опыт. Суть проблемы — у меня там был давний ипотечный кредит, ещё с 2007 года, задолго до того как я стал ФОПом ( с 2012 ). Я перевел туда ФОП счёт, ну не помню точно, но не позже года так 2014-2015. Потом в 2017 я релоцировался в US, и, будучи на Украине летом 2019 в отпуске, решил таки полностью погасить кредит. Как говорится, это только присказка, сказка впереди.

И вот, захожу я такой утром с пачкой кэша, вооруженный паспортом, ИНН, кредитным договором, и пытаюсь провести сию нехитрую операцию, и попадаю в альтернативную реальность.
— Мы не можем принять деньги на ипотечный договор.
— WTF ???
— У вас нет пройдена ФОП-идентификация
— < Полная фрустрация с моей стороны ,>
— За потраченные 5 (sic!) часов, мне так никто и не смог объяснить, какая связь между моим ипотечным кредитом физ. лица и ФОП идентификацией (о которой, кстати, меня никто не соизволил уведомить), кроме как «у нас такая процедура», и «система не пропускает».
— (Почти сдался) Говорю — ну ладно, хотите , я по-молодому привезу вам все ФОП документы, верифицируйте что вам там надо.
— Не, чувак, это так не работает. У нас автоматические синхронизации с реестрами, поэтому не хочешь ли ты ,метнуться кабанчиком, быстро что-то поменять в ФОП-регистрации, типа там добавить новый КВЕД, тогда у нас пройдет синхронизация, и будет всем счастье

Сказать, что я фалломорфировал после этого, это значит просто ничего не сказать.

В конце концов, я просто на следующий день отправил платеж безналом через Ощадбанк, заплатив при этом комиссию, и закрыл вопрос в течение 15 минут.

Вот из-за этого фееричного идиотизма — NEVER AGAIN.

У меня по страховке, $20 — обычный врач за визит, $35 — профильный специалист, $100 — emergency room, max out-of-pocket за год, то ли 3 то ли 4 тыс. Были варианты чуть дешевле, с бОльшими доплатами, но дешевле непринципиально, так что я не видел смысла пытаться отчаянно сэкономить $100/мес на семью из 4 человек

Знайомий корінний американець жалівся на високу франшизу для операції на очі і зуби. Каже це непоодинокий випадок. Страховка в нього думаю що гут — він по-перше місцевий, по-друге айтішник.

Обычно глаза и зубы это отдельные страховки. И тут еще как я понимаю может очень сильно зависеть от непосредственно процедуры — если это проходит как необходимая операция по направлению от врача, это одно, по своему желанию — это второе. Типа как хочу лазерную коррекцию просто потому что очки мне не идут vs удаление катаракты или там хочу сделать идеальный прикус vs срочное удаление зуба.

ТОЛЬКО.НЕ.УКРССИБ.
Never again

Не сказал бы. Адвокаты без проблем бьют эти тикеты... и даже DUI

До поры до времени. А в один прекрасный день судье это надоедает, и получается что-то типа такого.
www.rosaleslawfirm.com/...​ence-following-sixth-dwi

Интересно, она тоже рассказывала что у нее «все всегда под контролем» ? Ну подумаешь, ехала и пила пиво за рулем, в чем проблема?

Хотя мне похер в целом. Кончается все равно все одинаково — либо постами всяких МотоХэлпов про сбор средств на склеивание по кусочкам мотобрата, либо слезливыми постами в соцсетях, типа «он так любил жизнь ...» и аналогичная типа как грустно-романтично-пацанская срань пубертатного периода

Окончательно очки слетели, когда за езду на мотоцикле быстрее потока мне влепили штраф в 560$ с лишением прав на 2 недели. В Украине так исторически повелось, что полиции плевать на мотоциклистов. Делай что хочешь ...

Как раз этим штаты и хороши — неадекватов с манией величия очень быстро ставят на место.
А вообще, сильно толстый и скучный наброс

Я не вижу в этом проблемы, если эти команды никак не пересекаются, а выбор технологического стека каждой из них позволяет выполнить проект наиболее оптимальным способом.

Проблемы начинаются потом. Когда заканчивается проект у команд использующих специфичный стек. Или заказчик разрывает отношения. В результате в компании появляется 5 свободных разработчиков с проекта на NodeJs и 5 свободных Scala разработчиков, при одновременно открытых горящих 15 вакансияx Java и 10 .Net на других проектах.

Бывает ещё и так, что заказчик например уже вложился в некую инфраструктуру, у него есть персонал, который умеет именно эту инфраструктуру и этот софт обслуживать

Это точно такой же архитектурный стандарт, причина, по которой он возник, тут второстепенна. Он просто есть и не обсуждается.

И новый «зоопарк» (каким бы стандартным он не был для компании-исполнителя) заказчику совсем ни к чему.

Мнение исполнителя в этом случае вообще никого не интересует. Я же про это и пишу — что наверное не стоит хватать такие проекты, просто в надежде на сениорность или фулл-стечность, если в компании нет соответствующей экспертизы.

Разумеется, но как это относится именно к вопросу выделенных DBA? Инвестиции именно в них пока не выглядели особенно оправданными.

Поскольку вопросу специфики работы с разными БД в данном топике уделяется повышенное внимание, я делаю допущение, что БД таки играют роль в обсуждаемых проектах большую чем примитивные хранилища данных из трех таблиц. Соответсвенно, для меня выглядит разумным иметь несколько специалистов в области вместо надежды на универсальность

Наоборот, такая специализация мешает растить бизнес,

Ну так если речь идет об растить, то это требует некоторых инвестиций, не так ли?

Внезапно, я работал в GlobalLogic и до этого в Validio до осени 2010 года. Выделенных специалистов по базам данных даже в середине нулевых можно было пересчитать по пальцам, а уж к концу нулевых вообще затрудняюсь вспомнить, кто у нас в харьковском офисе работал именно как DBA.

Вполне возможно, я перешел в GL позже и в Киевский офис.

К вашему сведению, далеко не во всех компаниях оно существует как структурная единица — это первое.

И вы считаете это нормальным? То есть условые n команд девелоперов, независимо друг от друга, используют любые языки/БД/версии что им нравится?

И не всегда выбор БД является степенью свободы для компании-исполнителя — это второе.

Да, я это прекрасно понимаю. У серьезных заказчиков обычно как раз есть архитектурные стандарты. Ну так тут вопрос в другом — если у вас нет соответствующей экспертизы, зачем хватать такие проекты? Или, см. п1, рост требует инвестиций.

Ти платиш за страхування, але усе ж діє франшиза у 1,5 чи 3 тисячі доларів. Це означає, що все, що менше від цієї суми, платиш зі своєї кишені. Лише коли сума витрат на лікування за раз перевищує ці 1,5 чи 3 тисячі, 90% наступних витрат оплачує компанія, а 10% — працівник

ШТА ? А других вариантов не было? Или компания настолько жлобская что их не предоставляла?

У кого є 200 тисяч доларів на університет, аби потім ще 10–15 років сплачувати борги?

Ну раз учатся, то наверное есть много у кого :)) Это кстати примерно полторы-две годовые зарплаты квалифицированного специалиста. Причем скорее всего под студенческий кредит на дофига лет под небольшой процент. Немало, но не так чтобы уж совсем невозможно

И, если только компания не делает «на конвейере» проекты с подходящими для уровня DBA уровнем задач, то для такого специалиста просто не будет загрузки.

Не совсем понятно. Компания, больше совсем уж маленькой шлюпки на 20 человек, обычно специализируется на каких-то стеках технологий. .NET + MS Sql или там Java + Postgres или там php + MySql. Под них подбираются типовые команды c типовыми скиллами. И обычно всегда имеет смысл иметь специалистов по базам данных, из расчета один на n проектов. Очень странно слышать что для специалиста «просто не будет загрузки»

Если это конечно не:
— Маленькая шлюпка которая хватает что попало и набирает кого попало.
— Полный бардак и анархия в архитектурном подразделении, когда в 10 аналогичных проектах используется 10 разных СУБД

Когда я слышу, что синьор должен в первую очередь думать о бизнесе

Не стоит заниматься подменой понятий, да еще и настолько неуклюжей. Речь в основном шла о том, что синьор должен ясно представлять бизнес-контекст конкетной задачи с точки зрения реализации и NFR, а не заменять отдел маркетинга и сейлзов у заказчика на полставки.

безупречно тестировать,

У меня в команде синьоры всегда ревьювили интеграционные тесты. Не с точки зрения деталей имплементации, а чтобы удостовериться что неочевидные сценарии не упущены.

архитекторы в конце концов

Видел массу примеров когда хорошие, годные синьоры вполне себе удачно совмещали роли архитекторов. Обратные примеры тоже видел, но гораздо реже.

В галерном ИТ максимальный срок жизни знаний/опыта — это 5 лет

Когда нынешнему сообществу Ит в Украине, 200 000 человек, будет по 50-60 лет — много они смогут повыбирать?

Вот тут уже соглашусь с ораторами выше. Саморазвитие, хотя бы минимальное, всегда должно присутствовать. Если нет — то се ля ви, некого обвинять кроме себя. И кстати, ИТ тут еще и в очень выигрышном положении, так как требования по здоровью, возрасту или внешности минимальны по сравнению с остальными сферами деятельности.

Человек не станет в ИТ аналогом уважаемого врача, чиновника со связями/знакомствами, он никогда не станет частью истеблишмента.

Ну так это как бы очевидно. Как и автомеханик. Как и электрик. Как еще и n! профессий. Хочешь стать уважаемым чиновником — иди в политику. Хочешь стать уважаемым врачом — ну так закончи медицинский и поработай вначале ординатором на мизерную зарплату. Это так во всем мире, Украина тут уж никак не уникальна.

Что там было в 2000-х — это уже история. Тогда у доллара была совершенно другая покупательная способность в мире.

Нельзя рассматривать зарплату в одной отрасли в отрыве от экономической ситуации в целом.

И самое главное — это не зарплата в стабильной сфере.

Что тогда есть «стабильная сфера» в Украине («стабильная» != «стабильно нищая») ?

Это был очень приблизительный пример (зарплата может быть и не минимальная, кодеров можно попробовать найти еще подешевле , масштаб бизнеса может быть больше и т.п.), основной смысл — показать примерное отношение затрат и потенциальной экономии. Т.е, условный проект на 5 человек на год в Украине, стоимостью в $ 240 000, примерно окупатеся экономией на минимальной зарплате 5 человек в US в течение 2.5 лет для заказчика.
Причем с увеличением размеров экономия растет нелинейно
Ну и это только прямая экономия, а есть же еще такие вещи как увеличение удовлетворенности клиентов (~ рост бизнеса ), уменьшение издержек производства и т.п.

Назовём его иначе — продакт оунер

Средний продакт оунер тебе запилит юзер-стори типа «As a user ... I need to have a possibility to use an external identity provider ... so that I can avoid the creation of the separate profile»
Чуть более продвинутый — разобьет на две — логин и логаут.

Вопросы выбора конкретного протокола, провайдера — это и не его, в принципе, компетенция. Также как и декомпозиция этой стори с точки зрения реализации.

зависит от проекта. и если на проекте вменяемые — то поводят за ручку, чтобы быстрее начал работать

Думаю что речь шла немного о другом. Когда на проект заходит новый senior специалист, то я ожидаю примерный паттерн поведения:

0. Знакомство с командой
1. Короткий овервью митинг плюс ссылки на проектную документацию
2. Краткое самостоятельное погружение в курс дела
3. Несколько митингов для ответа на конкретные вопросы

При этом я ожидаю, что текущие вопросы (типа доступов) он решает самостоятельно, после знакомства с командой

А не о том, что «оружие добудешь в бою, ура сразу в атаку»

В отличие от — «ну давайте, рассказывайте мне неделю по 4 часа в день как оно все у вас тут»

синьор в первую очередь думает о бизнес задаче, а потом о фреймворках, тех что знает, да и тех что не знает
мидл думает о фреймворках, а потом, если хороший, о бизнес задаче. а может и не думать о б.з

Отлично сказано. Добавлю еще, что синьор всегда учитывает существующую архитектуру и старается делать единообразно, даже если что-то не хайпе или самых последниих версиях.

К большому сожалению бизнес-аналитики это больше исключение чем правило в современной разработке. И да, нормальный senior как минимум должен уметь в UML и в нормальную декомпозицию и постановку задач