Надо понимать, что нынешняя ситуация на рынке труда (и не только там) - это аналог ситуации условного 89 года в СССР. Т.е. необратимых перемен в относительно устоявшемся мире ещё не произошло, но говоря образно, уже виден туман над водопадом, к которому нас относит. Я в конце 90х, общаясь со старшими родственниками из Москвы с удивлением узнал, что при СССР они работали программистом, а сейчас чуть ли не на рынке торгуют. А я тогда учился в ВУЗе (я не инженер, если что), читал истории успеха про Гейтса, Нортона и Джобса и видел бум, к примеру, веб-разработки. Когда я выпустился, оказалось, что знания по алгоритмам и т.п. не востребованы, т.к. к тому времени все важные алгоритмы уже были в open source библиотеках и надо было просто аккуратно комбинировать в программах, нужных на тот момент рынку. Спустя много лет часть фундаментальных знаний пригодилось, но откровенно говоря, если бы я выбрал другой ВУЗ, где бы пьянствовал с однокурсниками под гитару, эффект мог бы быть и лучше.
По итогу, ответ на ваш вопрос - любовь к профессии не станет финансовым штрафом, но лучше будет, если это действительно будет любовь (либо к самой профессии, либо к результату, который с помощью неё стремишься достичь)
Зря не пишете. Помимо соседнего ответа про HR-ов, которым нужны ключевые слова, не забывайте, что средний мидл может не уметь элементарно ребейзить или, скажем, пуллить из не основного апстрима, не говоря уже о специализированных возможностях, вроде git subtree или “добавить с помощью git submodule в docker-compose окружение конкретную версию зависимости для отладки”. Просто потому что мидл обычно “просто закрывает таски”, а для них продвинутые возможности не требуются.
В подобных историях, включая притчу про остров, поражает, что для того, чтобы спланировать и сделать всё по уму сразу и подстелить соломки ресурсы, обычно, не находятся. Зато чтобы героически исправлять последствия ресурсы находятся всегда и в неограниченном объёме…
Самолёты - это не супер уникальная технология, а кроме того это “подсадка на контракт поддержки от производителя”. А “Б/У Фальконы” - это уникальная технология, так что в данном случае, если Илон действительно не преувеличивает и не выдаёт желаемое за действительное, их никому не дадут.
Очевидно, угловая скорость зеркала по курсу должна быть связана со скоростью (а значит, высотой) пролета. А также должны быть связаны “фазы” всей группировки, что бы солнечный зайчик от всех аппаратов при полётах над местом освещения был в примерно одном месте.
Видимо, удешевить товары с одновременным увеличением средней производительности и при незначительном изменении занятости. А получается так, что производительность примерно остаётся на своём месте, а вот занятость уменьшается, да и удешевление готовых товаров не особо заметно, т.к. высвобождаются преимущественно начальные роли, которые ранее обслуживали верхние в задаче создания добавочной стоимости.
Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального Agile достаточно UserStory, написанной на салфетке или стикере. Но там и аналитики не нужны - их роль выполняют исполнители.
В принципе, все, что вы перечислили - должно быть в ТЗ по ГОСТУ. Если ТЗ делалось нормально, а не формально, то принципиальных ошибок там не должно быть. А мелких сложно избежать.
Итеративная/Agile разработка это хорошо и это отдельная история. Но не стоит называть User Story техническим заданием. Это разные документы. Равно как не стоит путать совместную разработку ТЗ с регулярным исправлением ошибок аналитиков разработчиками (такие аналитики и не нужны).
Статья немного сумбурная - кажется, её надо было разбить на две. Первая - про спорное отношение к ТЗ. Вторая с мемуарами и чеклистом.
По отношению к ТЗ: если писать ТЗ нормально, по ГОСТу, то обсуждений никаких не требуется. Там и так должно быть все подробно и понятно описано. Если разраб бросился писать код на низкоуровневом ЯП с первых строчек, то это его проблема.
Во всяком случае “аналитик написал ТЗ, а теперь обсудите и поспорьте о нем” - это очень странный подход. Такое можно говорить об эскизе ТЗ на каком-то промежуточном этапе сбора требований. Но о готовом ТЗ, за которое аналитик расписался?
К слову, в не функциональные требования почему-то брошены и функциональные (точнее, их нюансы, которые должны быть расписаны вместе с этими ФТ).
Вы читали описание https://github.com/adriancable/eternal/blob/main/docs/napkin.md ? Возможно, автору статьи имело бы смысл её перевести. Вкратце, идея о примитивной виртуальной машине, имеющей посимвольный последовательный ввод-вывод, цветной TrueColor экран 800x512, возможность узнавать текущее время по запросу изнутри виртуальной машины, и ещё какое то странное немаскируемое прерывание, принцип и назначение работы которого из описания совсем непонятно.
Вообще, идея очень интересная.
Там, конечно, есть косяки. Например, я так понимаю, что символы, получаемые из портов ввода-вывода - это ASCII. Возможно, автору проекта стоило бы привести таблицу таких символов. Потом, хорошо бы какой-то глоссарий и примеры цветов (я опускаю идею, что возможно “human” тогда не будет, а у тогдашних разумных существ будут органы чувств, не распознающих привычный нам спектр). Возможно, с глоссарием понятия адреса и описание прерываний было бы более понятно. Без этого данное описание - это просто какая-то шутка “для немногих причастных” :)
Против этого есть правило, что аудит таких систем должны осуществлять другие админы. Ну а дальше вопрос политический: требовать соблюдения этого или нет?
Надо понимать, что нынешняя ситуация на рынке труда (и не только там) - это аналог ситуации условного 89 года в СССР. Т.е. необратимых перемен в относительно устоявшемся мире ещё не произошло, но говоря образно, уже виден туман над водопадом, к которому нас относит. Я в конце 90х, общаясь со старшими родственниками из Москвы с удивлением узнал, что при СССР они работали программистом, а сейчас чуть ли не на рынке торгуют. А я тогда учился в ВУЗе (я не инженер, если что), читал истории успеха про Гейтса, Нортона и Джобса и видел бум, к примеру, веб-разработки. Когда я выпустился, оказалось, что знания по алгоритмам и т.п. не востребованы, т.к. к тому времени все важные алгоритмы уже были в open source библиотеках и надо было просто аккуратно комбинировать в программах, нужных на тот момент рынку. Спустя много лет часть фундаментальных знаний пригодилось, но откровенно говоря, если бы я выбрал другой ВУЗ, где бы пьянствовал с однокурсниками под гитару, эффект мог бы быть и лучше.
По итогу, ответ на ваш вопрос - любовь к профессии не станет финансовым штрафом, но лучше будет, если это действительно будет любовь (либо к самой профессии, либо к результату, который с помощью неё стремишься достичь)
Главный критерий МП - наличие ответственности и полномочий (особенно, по части освоения бюджета и по кадровым вопросам).
Но часто именно это вырезают, вот и получаются непонятные “чебурашки”, которые вы или ваш ИИ-агент описал…
Зря не пишете. Помимо соседнего ответа про HR-ов, которым нужны ключевые слова, не забывайте, что средний мидл может не уметь элементарно ребейзить или, скажем, пуллить из не основного апстрима, не говоря уже о специализированных возможностях, вроде git subtree или “добавить с помощью git submodule в docker-compose окружение конкретную версию зависимости для отладки”. Просто потому что мидл обычно “просто закрывает таски”, а для них продвинутые возможности не требуются.
Обычно с питона переписывают сначала на go (и, собственно, для этого он и создавался)
Плюс ещё не забывайте про DNS.
Если нужна нормальная защита - то только предустановка клиентского сертификата и информирование пользователя на тему фишинга…
В подобных историях, включая притчу про остров, поражает, что для того, чтобы спланировать и сделать всё по уму сразу и подстелить соломки ресурсы, обычно, не находятся. Зато чтобы героически исправлять последствия ресурсы находятся всегда и в неограниченном объёме…
Читайте про evil атаки (evil novnc и т.п.). Это все про социнженерию, конечно
Самолёты - это не супер уникальная технология, а кроме того это “подсадка на контракт поддержки от производителя”. А “Б/У Фальконы” - это уникальная технология, так что в данном случае, если Илон действительно не преувеличивает и не выдаёт желаемое за действительное, их никому не дадут.
Очевидно, угловая скорость зеркала по курсу должна быть связана со скоростью (а значит, высотой) пролета. А также должны быть связаны “фазы” всей группировки, что бы солнечный зайчик от всех аппаратов при полётах над местом освещения был в примерно одном месте.
Зачем? Вон, часы GPS отличаются на 13 секунд и всё нормально.
Видимо, удешевить товары с одновременным увеличением средней производительности и при незначительном изменении занятости. А получается так, что производительность примерно остаётся на своём месте, а вот занятость уменьшается, да и удешевление готовых товаров не особо заметно, т.к. высвобождаются преимущественно начальные роли, которые ранее обслуживали верхние в задаче создания добавочной стоимости.
Не все пассажиры в вашем авто оплатили функцию “Быстрота”, скорость ограничена до 90 км/ч
Смотря какой fabric, смотря сколько details
С одной стороны, верно, а с другой стороны, у провода и радио просто разные риски. И получается, что провод и радио друг друга резервируют.
Если бизнес такое устраивает, то почему бы нет? Сделать по нормальному сейчас будет примерно на столько дольше, насколько дольше было бы сделать изначально, зато фирма работает уже сейчас. Если на это исправление не выделяют ресурсов, значит еще не пришла пора.
Почему ТЗ не может быть на уровне отдельных сторей? Вполне может. Главное что бы было прописано все, касающееся доработки. Не обязательно, что бы был том “войны и мира”.
Совмещение ролей - это хорошо. Но важно понимать: если есть ТЗ, то фактически систему проектируют разработчики этого ТЗ (на основе интервью по сбору требований и т.п. соображений). У тех, кто будет использовать ТЗ тоже может быть существенный вклад, но поскольку выйти за рамки ТЗ они не могут, то какой бы хитрой разработанная система ни была внутри, снаружи она будет вести себя как описано в ТЗ. Если же ТЗ нет, -то результат ХЗ-, то разрабатывает систему тот, кто её шатает (разработчик, программист, админ и т.п.).
Для нормального Agile достаточно UserStory, написанной на салфетке или стикере. Но там и аналитики не нужны - их роль выполняют исполнители.
В принципе, все, что вы перечислили - должно быть в ТЗ по ГОСТУ. Если ТЗ делалось нормально, а не формально, то принципиальных ошибок там не должно быть. А мелких сложно избежать.
Итеративная/Agile разработка это хорошо и это отдельная история. Но не стоит называть User Story техническим заданием. Это разные документы. Равно как не стоит путать совместную разработку ТЗ с регулярным исправлением ошибок аналитиков разработчиками (такие аналитики и не нужны).
Статья немного сумбурная - кажется, её надо было разбить на две. Первая - про спорное отношение к ТЗ. Вторая с мемуарами и чеклистом.
По отношению к ТЗ: если писать ТЗ нормально, по ГОСТу, то обсуждений никаких не требуется. Там и так должно быть все подробно и понятно описано. Если разраб бросился писать код на низкоуровневом ЯП с первых строчек, то это его проблема.
Во всяком случае “аналитик написал ТЗ, а теперь обсудите и поспорьте о нем” - это очень странный подход. Такое можно говорить об эскизе ТЗ на каком-то промежуточном этапе сбора требований. Но о готовом ТЗ, за которое аналитик расписался?
К слову, в не функциональные требования почему-то брошены и функциональные (точнее, их нюансы, которые должны быть расписаны вместе с этими ФТ).
Вы читали описание https://github.com/adriancable/eternal/blob/main/docs/napkin.md ? Возможно, автору статьи имело бы смысл её перевести. Вкратце, идея о примитивной виртуальной машине, имеющей посимвольный последовательный ввод-вывод, цветной TrueColor экран 800x512, возможность узнавать текущее время по запросу изнутри виртуальной машины, и ещё какое то странное немаскируемое прерывание, принцип и назначение работы которого из описания совсем непонятно.
Вообще, идея очень интересная.
Там, конечно, есть косяки. Например, я так понимаю, что символы, получаемые из портов ввода-вывода - это ASCII. Возможно, автору проекта стоило бы привести таблицу таких символов. Потом, хорошо бы какой-то глоссарий и примеры цветов (я опускаю идею, что возможно “human” тогда не будет, а у тогдашних разумных существ будут органы чувств, не распознающих привычный нам спектр). Возможно, с глоссарием понятия адреса и описание прерываний было бы более понятно. Без этого данное описание - это просто какая-то шутка “для немногих причастных” :)
Против этого есть правило, что аудит таких систем должны осуществлять другие админы. Ну а дальше вопрос политический: требовать соблюдения этого или нет?