Comments 98
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики? Кажется это их задача: выяснить чего в точности хочет заказчик, перевести эти пожелания с языка предметной области на общечеловеческий, и оформить этот перевод в виде документа - задания программисту. А программист уже переводит с общечеловеческого на язык машины/ОС/фреймворка и т.п.
Справедливо, но это предполагает, что все остальные кто там этим всем должен заниматься глубоко погружены в технологии, так же глубоко понимают все возможности и ограничения разработки, а ещё никогда не ошибаются. То есть это рабочая схема, самая распространенная даже наверно, но у неё есть проблемы – люди не совершенны. А командная работа на всех этапах нивелирует эти несовершенства, не полностью, конечно, но так приятнее. Зависит от приоритетов, как всегда, на мой взгляд.
Кажется это их задача: выяснить чего в точности хочет заказчик, перевести эти пожелания с языка предметной области на общечеловеческий
На самом деле, нет. Их задача (после сбора пожеланий) перевести их с того языка предметной области, который используется заказчиком, в тот, который будет использоваться на проекте (обычно более формализованный). Классическое описание этого - у Эванса в Domain-Driven Design.
Можно предложить такую формулировку: "перевести на тот язык, который будет понятен всем участникам команды". И если там есть непонятные термины предметной области, без которых никак - то их задача разжевать эти термины (в том числе уточняя у заказчиков, консультантов, в специальной литературе и т.п.) и оформить эти разъяснения документально, причем все это следует обсуждать и делать вместе с программистами.
Трюк состоит в том, что после "разжевывания" термины никуда не денутся - потому что они нужны, чтобы упростить общение, сделав его более коротким и однозначным, - просто появится словарь, который их описывает (я вообще рекомендую с такого словаря начинать любые сколько-нибудь нетривиальные требования). Чтобы начать работать на проекте, нужно будет этот словарь освоить - и это как раз и будет изучением предметной области (словарем дело не ограничится, потому что дальше будут отношения, сценарии использования и так далее).
Вот очень часто термины предметной области как раз максимально не однозначны, поскольку контекстны.
Пользователи очень часто могут использовать один и тот же термин для совершенно разных с точки зрения разработки сущностей. Банально сотрудник, это может быть и подписант в ЭЦП, и номер телефона, и логин, и ИНН и Вася в реальном мире с руками и ногами. И фраз, я передаю сотруднику шариковую ручку, в такой ситуации может свихнуть мозг любому разработчику.
Как уже отметили, дело не в терминах (не только и не столько в терминах), но в понимании как оно вообще работает. Без этого понимания сложно написать что-то более-менее эффективное для сколь-либо сложной системы/процесса.
И да и нет.
Если, допустим, речь идет о сайте, который надо сверстать (ну условно говоря), то там да - продакты с аналитиками договорятся с заказчиком как оно должно выглядеть, а программист уже сверстает - сайт, он и в африке сайт, что порнхаб, что госуслуги - принципиальной разницы нет.
Но если речь идет о какой-то сложной бизнес-логике, да еще в большой системе, то все становится сложнее - если разработчик "ни в зуб ногой" в том как все это устроено, то ему придется расписывать задачу до уровня псевдокода и это будет уже не разработчик, а просто кодировщик. И не дай бог, аналитик где-то там ошибется/опечатается - кодировщик тупо все это перенесет в код и скажет что так и было. И чем он тогда отличается от тех девочек, что когда-то сидели на ВЦ и с бланков на перфокарты перебивали чужой код?
Еще хуже, когда такой "разработчик" еще и инициативу проявит - "ща, мы вот тут закешируем - вообще все летать будет". Летать-то будет, но не туда. Потому что вот именно "тут" кешировать никак нельзя иби "это" может параллельно меняться в другом процессе и надо всегда иметь актуальное значение. Но для этого надо хоть в общих чертах представлять как оно работает в целом. Т.е. как-то иметь представление о "предметной области".
С другой стороны, если разработчик давно крутится в предметной области и представляет что там и как, он уже может и аналитика проконтролировать и поправить - "тут надо вот такой срез данных, предлагается вот такая таблица, но эти же данные можно и из вот этой таблицы взять - она поменьше, там индекс лучше в план запроса ложится...". Это уже качественно иной подход к задаче.
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики?
Справедливо, но надо понимать что сейчас в айти очень серьёзная конкуренция, и она будет только нарастать. Найти просто кодерка на условной Жаве уже сейчас ни разу не проблема. А вот "кодерок" который ещё и хорошо разбирается в предметной области, в бизнес-процессах конкретного бизнеса - поди найди такого. Поэтому хочешь жить - придётся потихоньку перекатываться из чистого кодерка в [полу]продакта по-совместительству. Увы, но за те же деньги, скорее всего.
В моем мире продакты ищут потребности пользователей и способы закрыть эти потребности.
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики?
Во-первых, мешаться под ногами, чтоб жизнь мёдом не казалась. Во-вторых, отвечать на дурацкие вопросы людей, которые не умеют в гугл или базу знаний. В-третьих, делать красивые отчёты для начальства. И в-четвётрых, выбивать бюджеты. Очень полезные люди, в целом.
Они могут расшифровать, но не могут сделать задачу предметной области проще, чем она есть в предметной области.
Какую то часть все равно нужно понимать конечному исполнителю.
Не совсем так. Я изучал этот вопрос где-то лет двадцать назад. И тогда считалось, что для описания "пожеланий заказчика" - точнее, предметной области бизнеса, функционирования предприятия и т.п. - нужно делать описания не на общечеловеческом языке, а с помощью специальных средств, таких как диаграммы САДТ (IDEF0) для функционального описания, диаграммы "сущность-связь"(IDEF1) для описания данных предприятия и т.п. Был, как минимум, один целый набор методологий (IDEF) для разработки таких описаний.
Изучал я по книгам и статьям в журналах, естественно: в фирмочке, где я тогда работал, таких сложностей не требовалось. Хотя кое-что из этого инструментария использовал - к примеру автоматическую генерацию схемы БД по методологии "сущность-связь" программой ERWin
Как с этим в нынешней реальности - не знаю. Но, судя по таким вот статьям - не очень хорошо, снизить сложность разработки и требований к квалификации программистов, непосредственно пишущих код, путем отвязывания непосредственно разработчиков от неточностей и неясностей предметной области, выяснение котторых - задача аналитиков, не получилось.
каждый из перечисленных смотрит на бизнес проблемы со своего ракурса, а программисты вообще зачастую где то в подвале и про проблемы бизнеса не подозревают, хотя в итоге именно они делают систему.
И когда программисты не желают вникать в предметную область возникает множество курьезов и проблем.
Далеко не всегда все особенности досконально описывается аналитиком, многие проблемы отдаются на откуп разработчику и требуют для решения только здравый смысл и немного понимания (в противном случае процесс описания требований может занять ну очень много времени и затрат)
Хороший у тебя никнейм NeoCode, а на аватарке наверное OLLO (два кружка и два треугольника) - 0110 (десятичная шестерка) тоже красиво смотрится. Вот чего я не понял - это зачем автор написал эту статью, какая цель этой статьи - он печатал буквы на клавиатуре, даже упомянул ветхозаветные сюжеты, которые не касаются наших дней. Судя по статье, этот автор отличнейший человек, каждый день трудится и взаимодействует с заказчиками, а потом с другими исполнителями обсуждает чего это заказчики хотят в бизнесе.
Это - статья/заметка как крик профессиональной души и оправдание своих устоявшихся взглядов на мир "Розовых пони"?
P.S. А, реальность такая как дана нам не только в своих ощущениях и с ней нужно и имеет смысл работать.
То что джун при увольнении подумал о Вас и компании в которой он начал работать осталось же, конечно, за рамками данной "статьи".
Эта "статья" обёртка для ссылки на телегу, не более.
У нас был такой разраб, он не хотел вникать в бизнес заказчика, он хотел "херачить код". Не сработались, но где-то, по любому, есть фирма которой подойдёт его стиль.
полно таких фирм. В любом банке аля сбер такие сотнями например нужны
Не в любом. Нам, к примеру, не нужны. Ну по крайней мене на уровне центральных систем.
У нас ценится человек, который, к примеру, знает как
Отобрать записи по условиям:
- Счет не закрыт
- Счет не зарезервирован
- Балансовый номер 2 порядка входит в контролируемые
реализуется в реальном коде - какие поля в какой таблице отвечают за "счет не закрыт, не зарезервирован", что такое "балансовый номер второго порядка", как по номеру счета узнать его валюту и т.д. и т.п.
Т.е. люди, которым не надо разжевывать все до буковки.
У нас ценится человек, который, к примеру, знает как
Весь вопрос как ценится. И как будет цениться в перспективе. Я например когда-то работал на Казначество, и чем 401 счёт от 407 отличается знал. Но вот на вкусные позиции продавалось это так себе. Продавалось только хорошее знание SQL. Вы поставьте себя на место разработчика, он ведь тоже вкусно кушать хочет, а не "за всё хорошее" вкалывать. Сейчас конечно всё должно поменяться, знатоков "кафок и кубернетисов" стало как собак нерезанных. Но предметную область тоже надо выбирать с пристрастием. Может познания сернистостей нефти выгоднее чем знания особенностей закрытия опердня.
Весь вопрос как ценится.
Ну я лично не жалуюсь :-) Доход давно уже превышает основные потребности и позволяет систематично наращивать "финансовую подушку". Ну и "вкусным" для себя давно уже считаю не то, где заплатят на три копейки больше, а где задачи будут нестандартные и интересные.
А поскольку в разработке уже более 30-ти лет, то одним "закрытием опердня" знания не ограничиваются. Могу в промавтоматизацию пойти (в тот же нефтегаз приглашали, к примеру). Или что-то связанное с ГИС (есть базовые понятия работы с геоданными - системы координат, датумы, проекции, преобразования..., в случае чего быстро подтянуть точечно не проблема). Могу в обработку данных - неплохая физмат база в наличии, когда-то занимался регрессионным, статистическим анализом - тоже не с нуля начинать...
Естественно, плюс инструментарий - неплохо знаю "потроха" винды, достаточно уверенно - AS/400. Линукс - тут чисто базовые вещи, не сильно много под нее писал. Ну с БД неплохой опыт работы (в т.ч. с сетевой моделью БД приходилось сталкиваться). IP стек опять же (не на уровне фреймворков, а внутри).
Вот на прошлом месте интересно было - с одной стороны сеть промконтроллеров со всеми протоколами обмена от RS485 до UDP и TCP, с другой - привязка всего этого хозяйства к карте - работа с серверами OSM/2GIS на уровне формирования нужного участка карты на лету по координатам объектов в БД.
Я ж не говорю что упереться во что-то одно. Просто если чем-то занимаешься, кроме инструментов стоит и понимать что ты делаешь и зачем. А просто тупо кодить по ТЗ без понимания что к чему и как - это скучно.
Хорошо когда 40+, все деньги заработаны [пока был хайп], и уже можно работать чисто для души за мелкий прайс. Или вообще не работать. Но поставьте себя на место 30-. Семья, жена в декрете, ипотека. Сейчас уже даже чисто программные направления выбирать приходится очень тщательно. Вляпаешься в какой-нибудь фронтенд, и всё, не найдёшь больше работы за пределами этого болота. Прошли времена "тыжпрограммист" когда легко можно было перекатываться из "проавтоматизации" в "базы данных". Попробуй сейчас в сытные "микросервисы" например сунуться без уже присутствующего релевантного стажа. Сейчас резюме просто в мусорку улетает если там в свежем 3-5 летнем опыте нет нужных ключевых слов.
Ну конечно хорошо :-)
Только на месте 30-летнего, как это ни удивительно, я был. В свое время.
И сейчас не скажу чтобы "за мелкий прайс" работаю. В частности смена работы позволила быстрее дом достроить и переехать за город жить. Да и детям иногда помочь. Плюс родители пожилые - тоже помощь нужна.
Вляпаешься в какой-нибудь фронтенд, и всё, не найдёшь больше работы за пределами этого болота.
Ну кто заставляет вляпываться во всякое?
По тем предложениям, которые мне прилетают регулярно, достаточно много мест, где требуется разработчик "с головой". Типа
система защиты от утечек информации и защиты баз данных, комплекс для расследования сетевых инцидентов, а также анти-DDoS-, антифрод-решения и другие перспективные разработки.
Стек: С++, STL, Clickhouse, ALTLinux, TCP/IP.
передовые системы беспроводной связи, которые применяют операторы связи на железнодорожном и морском транспорте, добывающие и промышленные предприятия.
Проектов несколько:
1. Прикладное ПО
Задачи:
Проектирование и разработка ПО прикладного уровня на С++ и С:
- Система конфигурирования устройства.
- Реализация современных протоколов взаимодействия (gRPC, REST).
- Реализация пользовательских интерфейсов управления устройством (WEB, CLI).
- Реализация прикладных сетевых протоколов (в том числе проприетарных).2. Беспроводное сетевое оборудование.
Задачи:
Проектирование и реализация ПО для беспроводного сетевого оборудования на основе стандартов WiFi IEEE802.11:
- Адаптация драйвера для работы с собственной ОС реального времени.
- Модификация встраиваемого ПО радио модулей.
- Развитие и поддержка проприетарных протоколов разделения беспроводной среды.3. Проводное сетевое оборудование (коммутатор).
Задачи:
Сделать высокопроизводительный коммутатор 10+Гигабит в секунду: проектирование и реализация ПО для проводного сетевого оборудования на основе стандартов Ethernet IEEE802.3:
- Адаптация драйвера для работы с собственной ОС реального времени.
- Проектирование высоко производительных коммутаторов на базе ОС Linux с использованием библиотеки DPDK.4. Материнская плата ключевого устройства (ядро)
Задачи:
Проектирование BSP для новых и поддержка существующих платформ.
Участие в выборе SoC при проектировании новых платформ.
Развитие и поддержка собственной ОС реального времени:
- Добавление поддержки новых архитектур CPU.
- Поддержка и развитие toolchain.
- Добавление поддержки новых периферийных устройств.
- Первичный, вторичный загрузчик.
Стек: C/C++
⁃ Ты займешься разработкой и поддержкой сетевых приложений;
⁃ Разработаешь модули ядра Linux, обрабатывающих сетевой трафик;
⁃ Примешь непосредственное участие в исследовании различных схем и способов обработки трафика, сравнишь результаты, и выберешь наиболее оптимальные решения.
аналог Active Directory; ядро продукта пишется на C, в качестве основы взята SAMBA.
Задачи :
- доработка Samba DC доменов, функций уровня P2
- работа с СУБД - OpenLDAP
- репликация и развитие системы
- помещение Samba в Kubernetes
Ну и похожее всякое... Поверьте, таких достаточно много предложений. Со вполне пристойными рейтами. Не 100500 в час, но жить вполне можно не сильно напрягаясь.
Прошли времена "тыжпрограммист" когда легко можно было перекатываться из "проавтоматизации" в "базы данных".
Я в 17-м перекатывался. И было мне тогда 52 годика. И ничего, вкатился. И кроме БД еще и со всяким системным-низкоуровневым порой приходится работать (например, дорабатывал наши внутренние сервисы для работы с IBM MQ - там приходилось разбирваться с низкоуровневм MQ API, делал свое API для удобной работы из прикладных программ с объектами типа *USRQ - это такая очередь, работа с ней идет через "системные указатели" и "машинные инструкции" и т.п.).
Так что есть места, где нужно уметь не с фреймворками работать, а на уровне системы.
Сейчас, кстати, на это есть спрос.
Попробуй сейчас в сытные "микросервисы" например сунуться
Вот уж точно нафиг-нафиг... То же болото.
Только на месте 30-летнего, как это ни удивительно, я был. В свое время.
В своё время и айти было куда проще в плане смена стека. Не технически - технически любой вменяемый инженер разберётся с чем угодно. Лишь бы не настолько радикально что бизнес просто не может долго ждать. С позиций найма сейчас попа в плане смены специализации. А если ещё зарываться в "предметную область", то вообще можно навсегда остаться без шансов выбраться в куда-то более денежное место.
Ну кто заставляет вляпываться во всякое?
Ну да, специально вляпывались. Люди когда-то думали что "перспективно". И хрен кто их теперь возьмёт туда где "есть спрос". Да я вообще сомневаюсь что в "Сделать высокопроизводительный коммутатор 10+Гигабит в секунду" возьмут любого кто не щупал эти коммутаторы на низком уровне хоть как-то.
Когда я общался с разработчиками из банков, они всегда знали предметную область в этом самом банке лучше меня (хотя я занимался интеграцией, поэтому тоже про нее что-то знал).
Вопрос просто в нейроресурсе. Позиция по типу «чужая работа», «я делаю только код не хочу знать предметную область» стоит рассматривать в контексте того, зачем человек транслирует такого рода сообщения. А этот вопрос уже упирается в вопрос куда и как ему направлять нейроресурс и какая у человека система ценностей и приоритетов.
И подумав, надев эту «ментальность» становится очевидно что человеку просто глубоко по… Человек не хочет ни грамма более тратить своего нервного топлива, сверх того что прописано. Вот есть какие-то обязанности прописанные, и он находит наиболее дешевый путь исполнения за тот же результат(бабки) для себя. Уважение(уважение от слова важность) к колегам, к их нейроресурсу, уважение к заказчику и его проблеме, оно стоит в списке приоритетов намного ниже чем экомномия мыслетоплива.
Видел на хабре похожую статью. Там один идейный и одухотворенный it специалист сетовал на собеседуемых девопсов. Мол, неужели не интересно развиваться в своей области, расширять собственные границы, глубоко понимать принципы и т.д. Почему людям так лень выйти за рамки существующего для них стека и любая попытка оформить задачу в отрыве от технологий вызывает сильный протест? Да все по той же причине. Обобщение задачи требует значительных трат нейроресурса. А человек рассматривает себя как блэк бокс с input и output причём исключительно с эгоцентричной позиции, не желая видеть всю систему
IMHO программист должен хоть немного понимать, то что он делает, иначе chatGPT какой-то получается. Но в наших реалиях зачастую, программист, единственный, кто понимает в бизнес процессах компании от начала до конца, и все нюансы которые, он не учел, т.к. не знал, и с другой стороны — условный бухгалтер, который забил на нормальную постановку, и обвиняющий программиста в своем промахе (хотел написать другое слово)
"Вавилоняни" ? Или всё-таки "ВавилонянЕ"?
Хороший слог.
Про sonar cube прямо в сердечко
На большом личном опыте понял, что принимать от клиента задачу, не поняв, как именно он будет ее использовать для нужд бизнеса (и какой именно это принесет ему профит) - тупая потеря времени и денег. Даже если клиент торопит - мол сделай так-то и так-то. А ты видишь - что херня какая то. Значит, нельзя такую задачу делать. Пока сам не врубишься для чего она.
Вы изначально не разделяете предметную область и бизнес, или программирование и бизнес. Это неправильно
Подозреваю, что ваш "джун" (который судя по описанию всё же мидл, просто с другим подходом к работе, чем вы) в первую очередь думал о своей карьере. А для карьеры ему нужно развиваться в тех навыках, которые он сможет продать. Изучение узкой предметной области нигде не продашь, поэтому она ему неинтересна.
И это его право, придерживаться такой позиции. Ну а ваше право быть с ним несогласным и отказаться от его услуг.
Если спросите моего мнения, то я считаю, что по большей части "джун" прав. За знание, чем крокет отличается от крикета на рынке труда не платят. Да, наверное, минимальное погружение в предметную область ему бы не помешало бы, ну настолько, насколько можно погрузиться за несколько дней, но не более того.
Ибо, как показывает история, если каждый человек действует исходя из собственных, зачастую эгоистических интересов, всегда получается лучше, чем когда все вместе в едином порыве, за ради всеобщего блага.
Он действовал из своих личных интересов. Вы же считаете, что за ради общественного блага всей организации, он должен был действовать по другому. Но это так не работает.
Всё по делу. Один нюанс я не считаю, что общественное выше собственного. Просто я считаю, что не надо сталкивать лбами интересы: либо общее, либо моё. Гораздо выгоднее через общее достигать своего, это открывает возможности. Ну а умение разбираться в том числе в предметной области (то бишь учиться и быть открытым к новому знанию) – прекрасно продается и дает преимущество. Если связь отсутствует между личными интересами и интересами бизнеса, очевидно не стоит там задерживаться, всё так.
прекрасно продается и дает преимуществ
Правильно ли я вас понимаю, что когда конкретно вы нанимаете разработчика в конкретно вашу команду, то, что разработчик увлеченно рассказывал вам на собеседовании про то, как отличается нефть разной сернистости и как и зачем её смешивают, вы засчитаете как некий уверенный плюс кандидату?
Правильно ли я понимаю, что конкретно вы любитель передергивать из крайности в крайность? ?
Отвечая на вопрос, который видимо вы бы хотели задать: конкретно я, считаю плюсом в период испытательного срока погружение в предметную область и интерес к теме.
Правильно ли я понимаю, что конкретно вы любитель передергивать из крайности в крайность? ?
Нет, я просто хочу подсветить момент в отношении исходного комментария и вашего ответа) Don't hate the player, hate the game
Вот ваша компания (как и тысячи других компаний) формируют конкретные требования для оценки и найма соискателя. И ваша компания (как и другие компании) будут игнорировать погруженность соискателя в предметную область не совпадающую с вашей. Как и тысячи других компаний.
Неудивительно, что в рынке, в котором сформированы такие правила игры, игроки будут следовать правилам и стараться больше сил, времени и внимания уделять тому, что увеличивает их ценность. А тому, что их ценность не увеличивает - они будут соответственно стараться уделять поменьше сил времени и внимания).
Напротив, было бы странно, если бы такое явление не было бы очень распространено.
А при чем тут сернистость нефти? "Предметная область" это прежде всего понимание тех процессов, которые надо автоматизировать.
Ну вот ка пример. Когда-то давно (еще в 90-е) попросили сделать для студентов демонстрационную программку, иллюстрирующую принципы молекулярной динамики и машинного моделирования. Связь между микроканоническим ансамблем (импульсы отдельных молекул) и микроканоническим (температура и давление газа в сосуде).
Как думаете, возможно такое без понимания физики, потенциалов взаимодействия и т.п.? Кстати, гугля с википедией тогда не было - это где-то 89-90 гг.
Позже делал систему анализа торгов на одной местной бирже. И опять - пришлось вникать в то, как организованы торги, а потом еще вспоминать математику - всякий статистический анализ и т.п.
Пару лет назад зазывали на работу в один из банков. Им нужен был человек, который не просто знает платформу, на которой они работают и стек, но еще и имеет представлены о том, как происходит процедура закрытия опердня и перехода на следующий день - какие там могут быть варианты реализации и подводные камни. Т.е. человек с опытом разработки центральных банковских систем, а не просто абстрактный "разработчик".
И за 30+ лет разработки в самых разных областях (от обработки различных данных, до промавтоматизации и разработки центральных банковских систем) такого в моей личной практике навалом - чем лучше ты понимаешь что именно ты автоматизируешь, тем качественней результат твоей работы.
А при чем тут сернистость нефти?
Вы действительно не понимаете при чём? Да при том, что человек потратил кучу сил и времени на то, чтобы быть полезным бизнесу, досконально изучал нефтепереработку и всё что с ней связано. А другой его коллега в это время игнорировал нефтепереработку, а вместо этого изучал Kubernetes, Kafka и NoSQL.
чем лучше ты понимаешь что именно ты автоматизируешь, тем качественней результат твоей работы
Да, первый работает лучше и качественнее второго, но платят ему меньше. Потому, что цена определяется не качеством работы, а спросом и предложением. А ему со знанием сернистости нефти податься больше некуда и его руководство это прекрасно понимает, что никуда он не денется, даже если ему платить чуть ниже рынка. А вот второй сотрудник со знанием широко востребованных технологий везде нарасхват, и чтобы его удержать, ему придётся много платить.
Не надо утрировать. Я так-то тоже умею.
Вот вы позиционируете себя как "плотник, хорошо владеющий пилой". А вам говорят "нужно сделать стол". А что такое стол? "Ну... это такая доска горизонтальная на четырех ножках". Делаете "доску горизонтальную на четырёх ножках". А ножки подламываются... Ну нет понимания как их крепить правильно...
В конечном итоге вам просто скажут - хорошо пилите? ну вот идите дрова пилить, на большее вы не способны.
Потому что деньги, которые вам платят - они приходят не от того, что вы там виртуозно пилите, а от продажи конкретного продукта, в данном случае стола. Нет стола - нет денег.
технологии - они для вас какую-то ценность имеют. А для заказчика все равно что там внутри. ему функционал нужен. А чтобы хорошо реализовать функционал, прежде всего надо понимать задачу, которую он решает, окружение в котором он работает.
В тех сферах, где мне приходилось и приходится работать, больше платят не тем, кто кафку с кубернетисом знает, но тем, кто умеет быстро и эффективно решать конкретные задачи. А это подразумевает не только владение инструментом, но и понимание того, что ты делаешь и зачем. Без этого... Ну продержитесь вы сколько-то на кафке с кубернетисом, но потом от вас будут ждать чего-то большего. Или навсегда застрянете на уровне кодировщика.
Вы приводите в пример стол. Навык изготовления стола широко востребованный. Да и сами вы разбираетесь в области широко востребованной - банковских оперднях. Банков много, есть рынок где можно предложить свои знания и за них заплатят. Но есть предприятия с уникальными сферами. И в их предметную область погружаться никто не хочет, т.к. потом себя не продашь. Как это часто бывает у программистов-наладчиков оборудования на предприятиях. Человек может быть спецом экстра класса в программировании ЧПУ прядильно-вязальной автоматики, и отлично разбираться во всех видах пряжи и бесчисленных нюансах вязания, натяжения нитей, узлов, рядов и узоров. Но, как правило, платят за такую работу не очень много.
Конечно! Но при условии, что смешивание нефти как-то влияет на код и решаемые задачи.
Например, чисто из головы (я про нефть ничего не знаю), рассказывает, что есть нефть разной зернистости в определённом количестве, есть задача её смешивания с онлайн контролем, но есть разные нюансы, типа температуры, вязкости и т.п.. А дальше рассказывает как считали, как мониторили, откуда данные попадали в систему, как обеспечивали отказоустойчивость, какое участие он принимал во всём этом и т.д.
Даже, если кандидат не знает всего процесса (от него до пользователя было 15 микросервисов), я ожидаю, что он будет хорошо знать свою полянку и на что она влияет.
Конечно! Но при условии, что смешивание нефти как-то влияет на код и решаемые задачи.
Суть мего примера - "нефть не имеет вообще никакого отношения к вашей предметной области" (куда вы человека нанимаете). Ваша предметная область в это примере - это спорт, таймы, крикет, крокет, вот это всё из исходного поста.
Можете нефть и спорт заменить на две любые области, главное, чтобы они находились друг от друга как можно дальше.
Согласен, из нефти в нефть легче перекатиться.
Мой же посыл, разработчик на собесе должен уметь объяснить какие задачи и какого уровня он решал. Его предыдущий домен - это декорации.
От уровня решаемых задач, так же, зависит уровень вопросов, которые он задаст. Это важно на собесе.
Так же я не отрицаю, что нужны "хардовые спецы", чтобы прийти и затюнить кафку. Но они не особо занимаются разработкой.
Если на испытательном сроке он прочтет книгу про нефтепереработку, то засчитаем.
Противопоставление "общественное" vs "личное" в корне неверно. Если под "общественным" понимать интересы того, кто платит вам деньги за вашу работу. Они просто не будет вам платить, если вам откровенно наплевать на его интересы.
Залог востребованности в том, чтобы уметь находить приемлемый для всех баланс между "личным" и "общественным".
В первую очередь думал о своей карьере и инвестировал в свои скилы? По описанию этот джун относится к тому типу людей, которые максимально зажимают энергию. Инвестиция в себя дело очень затратное. Как правило такие работают на минимум и поддерживают самый базовый набор навыков для сохранения своего биологического(именно нейронные свзязи имеются в виду, точнее их полный покой и отсутсвие создания новых) комфорта, такой человек не приходит домой в состоянии «вау как я хочу изучать что-то новое» предметную область, технологии, новые сферы(из it) и т.д Доработал до черты и все и так до следующего дня
Внутри компании люди сделали тз на свою задачу которую они хотят автоматизировать и вот спустя полгода первый релиз со всеми хотела и они юзают месяц но последние 10 дней никто не заходил в систему. Оказывается в ней надо работать! С бумажками проще и привычнее.
Спор остроконечников с тупоконечниками. Есть два подхода, условно промышленый и условно крафтовый, в первои исполнитель (разработчик) знает о предметке примерно ничего во втором примерно все. И есть еще бесконечное число промежуточных вариантов. И все они (в том числе) применяются в жизни. Мне несколькоближе именно промышленный подход, но его труднее реализовать, нужна сложная работа с заказчиком по выстраиванию процессов, это никто не любит.
Проще тешить себя мыслью что ты лучше заказчика знаешь область которой он годы учился и потом годы нарабатывал опыт. И делать это каждому джуну. Никого не осуждаю, сам таким был
От компании еще многое зависит. Если царит микроменеджмент, с ежедневными церемониями, с тайм-трекингом задач. С какой-то давлеющей иерархией, сквозь которую не пропихать свои идеи, и в итоге делается просто какой-то колхоз. А самое главное - с фиксированными закрытыми окладами без премий, то и получайте тогда "кодеров", которые будут из-под палки работать. Да еще и параллельно гребущих где-то в другом месте, таком же.
С какой-то давлеющей иерархией, сквозь которую не пропихать свои идеи
А можно пример "своей идеи"?
Ну вот представьте, есть система, достаточно сложная, в которой крутится 100500 разных процессов. И приходит заказчик ("бизнес") с просьбой автоматизировать и добавить туда еще один процесс. Но так, чтобы остальные не зацепить. В такой ситуации, чтобы "пропихнуть свою идею", нужно очень хорошо знать всю систему в целом - что и как там работает, что с чем связано. Ну просто чтобы в процессе интеграции не огрести проблем по самое немогу.
пример своей идеи - "давайте, наймем аналитика, а то я зае.....ся полдня за юзерами бегать, а вторые полдня от них бегать чтобы спрятаться и немного код пописать"
Програмист вникающий в проблемы бизнеса - это как продавец из всем известного анекдота:
Вот пришел программист с хорошим знанием разработки. Ему платят по рынку. Дальше он начинает погружаться в предметную область. Допустим, хорошо погрузился. Это погружение будет как-то оценено в денежном измерении? А если не будет, зачем погружаться?
Пока сотрудник не погрузился в предметную область, он не может выйти на нормальную производительность. Компания, в некотором смысле, инвестирует в него.
Если сотрудник так не выйдет на норм производительность, тот тут несколько путей:
Уволить
Смириться, всё равно за эти деньги никого лучше не найдёшь
Построить процесс так, чтобы люди с большими головами говорили что кодить
Третий вариант опасен выгораниями, т.к. сотрудника выжимают (ибо уплочено) и он не понимает что происходит.
>>Компания, в некотором смысле, инвестирует в него.
В каком смысле? При собеседовании кто-то говорит, мол, через полгода не выйдешь на нужный уровень - уволим? А раз этого не говорится - отчего программист должен сам додумывать, что там в голове у менеджмента?
Да никто не будет ничего на собеседовании говорить.
От человека будут требоваться решение поставленных задач в заданные сроки. Если справляется - есть шанс на повышение и т.п. (за себя могу сказать что на "потолок" до ложность в разработке вышел за четыре года года, за шесть лет уровень оплаты вырос в 3.5 раза). Не справляешься - в лучшем случае завязнешь и по уровню и по деньгам надолго.
А чтобы справляться, не надо тратить время по каждой задаче на выяснение "а тут что, а это как, а это что такое", но понимать сходу о чем речь. А иногда еще и самостоятельно принимать решения - "в данном случае в этих условиях эффективнее будет сделать вот так, а не так". Но для таких решений надо понимать суть процесса.
Обычно это называют "время на погружение в проект", т.е. пока погружаешься, точно будешь медленнее остальных работать. Если после погружения программист "не тянет", то там уже от фирмы зависит.
Грубо говоря, если Вася по 10 раз не может пройти ревью, потому что косячит из-за незнания предметной области, то зачем нам такой Вася?
Что такое "хорошее знание разработки"? Умение хорошо буковки печатать на нужном языке?
"Программист", который не понимает что он программирует суть простой кодировщик. Раньше этим занимались девочки на ВЦ - им приносили программы на бланках, они их на перфокарты набивали.
Разработчик - это немного больше. Он должен понимать что он делает. И почему именно так а не иначе. Если это системная разработка - должен знать как система устроена изнутри. Если это банк - там все еще сложнее. Много команд по разным направлениям и везде свои сущности. Работаешь в команде комплаенса? Ты не должен спрашивать что такое "списки росфина", "стоплисты", чем "полное совпадение субъекта с клиентом" отличается от частичного... А если он будет постоянно ходить и спрашивать "а где вот это лежит, а что вот это значит..." - долго не продержится. На первых порах простительно, но потом от него будут избавляться просто потому что он будет впустую тратить свое и чужое время.
Ну да, симптоматично. Я задал простой вопрос - каким образом прогресс программиста в предметной области будет вознагражден материально. Вместо ответа - манипуляции.
В моем (там где работаю) - очень просто. Прогресс в предметной области позволяет быстрее и эффективнее решать поставленные задачи. Что приводит к хорошим оценкам деятельности. Хорошая оценка дает повышенный коэффициент квартального бонуса + положительное решение в случае вопросов "есть возможность повысить одного человека в должности - кого повышать будем?" Или "нам увеличили ФОТ - кому сколько добавим?". Т.е. вы становитесь человеком, приносящим больше прибыли и вас выгоднее "подкармливать" чтобы не ушли. Если там, где Вы работаете не так, это или не нормально. Или просто Ваша позиция такова, что никто за Вас особо не держится - уйдете и бог в Вами, другого такого же найдут.
В моем конкретном случае развитие не только в плане технологии, но и предметной области дало увеличение оплаты в 3.5 раза за 6 лет. Плюс повышение по должности (через 5 лет мне вообще предлагали из разработчика в архитекторы направления переходить, но тут уже сам отказался потому что не интересна эта тема, хватает того что техлид направления).
Так понятно?
Разработчик - это немного больше. Он должен понимать что он делает. И почему именно так а не иначе.
Я всё ещё не понимаю)
долго не продержится.
На первых порах простительно, но потом от него будут избавляться просто потому что он будет впустую тратить свое и чужое время.
Вот мне надо нанять разработчика, допустим.
Вот есть проблема, озвученная автором - "разработчики хотят код фигачить, а не в предметную область погружаться".
Мотивация, почему разработчику хочется код фигачить - мне понятна.
Экономические предпосылки, почему разработчику может быть глубоко не интересно вникать в предметную область - мне понятны.
А вот как то, как задачу найма поможет решить то, что мы с вами тут начнём таких разработчиков называть "ненастоящими разработчиками" и сравнивать с "девочками на ВЦ" - мне решительно непонятно. Вообще никаких плюсов не вижу.
Я бы на месте разработчика услышав вопрос в духе "а ты настоящий разработчик или девочка из вц?" от нанимающего менеджера - бежал бы сверкая пятками. Особенно если речь идёт о разработчике, который вникать в бизнес-требования умеет и готов ценность внести.
Во-первых, согласен с соседним комментом, во-вторых, как использовать свои навыки и знания, контакты и отношения с людьми себе на пользу зависит от человека, польза и в деньгах может выражаться, и в стабильности, и в уникальности, и в чём угодно ещё. Это поиск возможностей. Вас никто не обязан продвигать по службе просто потому что, но вы, в свою очередь, можете не оставить шансов поступить иначе. Крепкое понимание предметной области – это отличительная черта, преимущество, в том числе. Конвертируется ли это в деньги не вопрос. Вопрос: сможете ли вы конвертировать это в деньги? Если получается с технологиями, то и здесь получится. Важно, конечно, понимать, что предметная область не заменяет навыки программирования, а дополняет.
>>Если получается с технологиями, то и здесь получится.
С технологиями то проще. Считаешь что мало платят? Выучиваешь получше технологии, находишь того, кто заплатит больше, меняешь место работы. Задача выполнена.
А как хорошее знание предметной области конвертировать? Не переставая при этом быть программистом? Научите...
Технология - это инструмент. А платят из тех денег, что идут с продажи продукта. Т.е. за умение создавать продукт. Тут мало одних технологий (ну или вы работаете в какой-то такой области, где все продукты одинаковые у всех производителей).
Если вы нанимаете человека, чтобы сделал вам электрику в доме, вам не важно насколько виртуозно он пассатижами или отверткой владеет. Вам важно чтобы он правильно посчитал сечения проводом, номиналы автоматов, распределил нагрузку по фазам и т.п. - за это вы ему платите.
А с вашим подходом всегда будет винтиком-подмастерьем, который делает ровно то, что ему сказали, но на большее не способен. А это тупик достаточно быстро.
Сравнение с электриком имело бы смысл только при работе по договору подряда. Есть работа, которую надо сделать, есть цена. Выполнил - деньги получил. Да, некоторые программисты так работают, и в этом случае они вероятно будут заинтересованы в прокачке предметной области.
А вы как работаете? "Я человек маленький, хожу сюда за зарплатой, делаю ровно что сказали"? И как оно развивается? Просто оцените для себя - сколько мест работы поменяли за последние 5 лет и во сколько раз вырос доход?
Я, даже будучи на бессрочном контракте, все равно работаю как на подряде - мне платят за решение конкретных задач. Хорошо решаю - хорошо платят и увеличивают бонусы и оплату (ну и всякие мелкие приятности типа "мы его не будем всякой фигней грузить рутинной - от него на сложных задачах толку больше, с ними не все справятся, а для фигни кого попроще припашем" или "хочешь в архитектуру - твоих компетенций за глаза уже хватит? не хочешь? не интересно? ну ок, занимайся чем нравится").
Смотрите, никто не спорит, что программист, погружающийся в предметную область будет работать лучше и приносить больше пользы, чем не погружающийся.
Но тут ситуация такая же, как, допустим, с job hopping'ом.
Правда же, что сотрудник, который работает в компании 10 лет скорее всего намного глубже погружен в процессы внутри компании и будет работать эффективнее, чем человек, пришедший полгода назад и через полтора года планирующий уйти? Да очевидно, что так.
Но вот есть рынок. Есть наниматели, которые устанавливают правила игры. Наниматели устанавливают такие правила, по которым Job Hopping - становится выгоден.
Если такие правила игры установлены - соискатели будут так себя вести в массе своей. Это просто факт.
Никакие уговоры, манипуляции, пламенные речи, искренние возмущения, коллективные осуждения, тренды в тик-токе, написание книжек про культуру настоящих разработчиков - ничего из этого списка ни в коем случае не изменит и не может изменить ситуации на рынке.
Кроме одного - смены правил игры.
На собесе рассказываешь какие проблемы разрулил на предыдущем месте работы. Типа была такая-то проблема, желательно системная, вот так я её решил, вот так всем стало жить лучше. Исходим из того, что код - это инструмент с помощью которого программист решает задачи.
Правда, такой опыт можно получить только на практике. При этом нужно как-то взаимодействовать с заинтересованными лицами, иначе никаких важных решений не принять. Не получится, сидеть и не отсвечивать.
Меня на последнем собесе в основном спрашивали кто задачи ставил, кто архитектуру разрабатывал, насколько был самостоятелен в принятии конкретных решений (писал "точно по ТЗ буква в букву", или сам предлагал наиболее эффективное решение).
Как потом узнал (задним числом) сильно впечатлило когда рассказал что команда была маленькая и все архитектурные решения вырабатывались сообща, ТЗ каждый себе вырабатывал сам (на свою часть задачи), потом все это согласовывали и состыковывали воедино. Фактически это и было основанием для быстрого решения "этого - берем" и офера на следующий день после собеса с командой.
Сравниваю что было еще лет 5 назад и сейчас. Тогда просто не получалось находить эффективные решения потому что не понимал как оно работает. Приходилось тупо по ТЗ фигачить, а что там напридумываают уж...
Сейчас, когда есть понимание как оно работает (в том направлении где работаю) намного проще решать всякие сложные задачи, требующие высокой эффективности. Просто в силу понимания как оно работает и где можно что-то (например) закешировать, а где, наоборот, нельзя т.к. требуются актуальные данные которые могут изменяться в параллельном процессе.
Естественно, совершенствования в технологиях это все никак не отменяет. Просто понимание процесса + владение технологиями дает существенно лучший результат чем что-то одно из двух.
Только вот при смене работы прокаченное немалыми трудами знание предметной области может обнулиться. Если только новое место работы не в аналогичной сфере, типа из банка в банк уйти. Но если только такие места искать - значительно сужается область поиска.
Зато при выборе между человеком "знающим кафку и кубернетис" и человеком, "знающим кафку, кубернетис и имеющим опыт работы в данной области" - кому предпочтение отдадут?
Понимание предметной области не отменяет знание технологий. Не надо противопоставлять эти вещи - они из разных областей.
Кстати, в банк я пришел из промавтоматизации. И на совсем другую платформу и технологический стек. Что абсолютно не помешало здесь выйти на достаточно приличный уровень. и по технологиям и по предметной области (хотя в этом плане, конечно, пробелов еще хватает т.к. область очень обширная).
А те вакансии, которые прилетают (сам давно уже не ищу, сами приходят) - везде "предметку" какую-никакую хотят. Будь то опыт работы с промконтроллерами, или понимание как IP стек работает на низком уровне или еще что-то такое... Т.е. то, что далеко выходит за пределы всяких фреймворков и конкретных языков программирования. И, поверьте, подтянуть до нужного уровня язык или освоить еще один фреймворк куда проще, чем понять тонкости области в которой работаешь.
Когда-то давно (лет 20-25 назад) тоже только "в технологии упирался". Пока не понял что там потолок достаточно быстро достигается, а дальше и выше можно развиваться только в сочетании со знанием предметной области в которой работаешь.
Есть такое. Но я бы не сказал про немалые затраты. Для меня предметная область - это часть задачи, которую я решаю. Просто часть разработки.
Когда есть куча вариантов решения, поднятие на уровень верх помогает принять решение.
Вопрос: сможете ли вы конвертировать это в деньги?
А вот этот ваш джун-не-джун, с которым вы расстались - он новую работу не нашёл? И платят ли ему на новой работе меньше? Просто если ему таки не платят там меньше, то вопроса такого, получается, в принципе и не стоит.
А вот вопрос, как быстро вы сможете нанять разработчика, который подходит под ваши ожидания, за те деньги, которые вы платили тому разработчику, и как отобрать среди соискателей разработчика, который не имеет аллергии на предметную область - стоит (иначе бы не было и поста).
Это погружение будет как-то оценено в денежном измерении?
Ну да, а что? Я на такие вещи смотрел на регулярной оценке сотрудников, и это влияло на повышение зарплаты.
Именно. И повышение з/п и коэффициенты при начислении регулярных бонусов - все это учитывается.
Вот смотрите, вот у вас - конкретный ответ на конкретный вопрос)
приходит джун, говорит, что не очень понимает, почему от него требуется в эту область глубоко погружаться
вы объясняете ему, что вот, смотри, дорогой джун, ты не погружаешься, а Васян погружается. Тебе на ревью поставят +-, а Васяну поставят ++ и зарплата ваша меняться будет совершенно разным образом. А повторяться этот процесс с ревью будет ни раз и не два.
Наглядно и понятно)
---
Автор статьи на тот же вопрос отвечает на через "польза и в деньгах может выражаться, и в стабильности, и в уникальности, и в чём угодно ещё. Это поиск возможностей... Конвертируется ли это в деньги не вопрос. Вопрос: сможете ли вы конвертировать это в деньги?".
Может быть, конечно, с этим джуном-не-джуном в статье и был разговор, где ему объяснили, что это ему выгодно, но что-то мне подсказывает, что такого разговора не было.
Ну это предполагает и наличие системы оценки сотрудников. И возможность по результатам этой оценки реально повысить з/п. (Не путать повышение зарплаты с компенсацией инфляции). Если такие предпосылки есть, и правила игры заранее озвучены - тогда может иметь смысл. Но такое ведь не везде.
Полностью поддерживаю докладчика.
Никто не отменял работу продактов, но разработчик, который более глубоко понимает предметную область, вероятно быстрее будет понимать поставленные задачи, и сможет эффективнее с ними работать.
Ну и если так подумать. Погружение в предметную область (поверхностно) не занимает какого-то огромного количества времени, а эффект может принести колоссальный.
язык программирования – это всего-лишь инструмент
за это отдельный +
слово "поверхностно" меня тут смущает
У всех предметные области разные. Где-то можно пройти полное погружение за неделю, где-то и полгода не хватит. Я имею ввиду про погружение без ненужных деталей
На мой взгляд формулировка не точная. Скорее не "поверхностно", но "достаточно для повышения эффективности решений поставленных задач".
Ну вот мне совершенно не требуется изучать экономику, законодательство в банковской сфере и т.д. и т.п.
Но вот знать, что 20-значный банковский счет это не просто набор цифр для работы полезно. Что первые 5 цифр - это "балансовый номер 2 порядка" (который много где используется для фильтрации, являясь типом счета), а следующие за ним 3 цифры - код валюты счета. Знать что у клиента несколько типов адресов (фактический, регистрации, юридический, почтовый...) и прочие такие вот вещи.
Буквально вчера вечером прямо тут попалась на глаза статья Фильтрация объектов по координатам (широте и долготе) По мне так лютый костылинг. А стоит чуть-чуть погрузится в "предметную область" чтобы понять что любая карта есть прямоугольная проекция геоида на плоскость. И есть способы перехода от геодезических координат в прямоугольные. Работать с которыми намного проще и быстрее.
Вот пример получения более эффективного решения в случае когда владеешь не только инструментом, которым работаешь, но и немного ориентируешься в предметной области. Тут для начала достаточно просто знать о существовании проекций. А нужные подробности уже гуглятся в том объеме, который потребен для решения задачи.
Ну вот мне совершенно не требуется изучать экономику, законодательство
До синьора, включительно - не надо. Но для тимлида или архитектора - уже очень желательно. Достаточно часто нарываюсь на то, что после того, как, для примера, задача прошла от приказа МинФина через финдиректора клиента, его зама (key-user), и консультанта-аналитика, "испорченный телефон" искажает суть задачи до неузнаваемости. И только обратившись к первоисточнику, тому самому приказу, становится понятно, что архитектура должна меняться на совершенно не том уровне одной узкой задачи, как прописано в постановке, а существенно глобальней. И это будет в итоге одна модификация, а не ряд несвязанных мелких.
А стоит чуть-чуть погрузится в "предметную область" чтобы понять что любая карта есть прямоугольная проекция геоида на плоскость.
А когда дело касается расстояний хотя бы на широте Мурманска, даже сфера не устраивает, как приближение, и прогноз начинают совпадать с фактом с приемлемой точностью, только если брать, как приближение, элипсоид. Так что все от задачи зависит. И кратчайший путь от Домодедово до Елизово лежит над Северным Ледовитым океаном. Хотя они, примерно, на одной параллели.
Вообще под определение "типа" применительно к банковским счетам лучше подходит БС1 (например, 423 - депозиты ФЛ), а БС2 - это уже подмножество типа (например, 42303).
В своё время я понял, что высшего технического образования мне не хватает и получил ещё и высшее экономическое с юридическим уклоном. Это действительно позволило эффективно общаться напрямую с заказчиками. Но требовать такого даже от синьора - перегиб. Для таких задач есть аналитики, а в спорных вопросах - тимлид или архитектор.
Так же даже от синьора нет смысла требовать глубокого понимания регрессионного анализа или дробного интегрирования. В коде ARFIMA он воспользуется по постановке, даже не погружаясь в то, как же она работает. А коэффициенты подберёт или аналитик, или кроссвалидация.
Программисты с аллергией на предметную область