В 2012-м году Wikileaks начал публикацию закрытых документов частной разведывательной компании Stratfor, известной, как «теневое ЦРУ». Среди прочих, был обнаружен документ связанный с онбордингом – словарь терминов для новых сотрудников. Вступительное слово к этому словарю выглядело так:
«Каждая предметная область имеет свои собственные термины, бесполезно обсуждать футбольный матч, используя термины, например, из бейсбола, поэтому в этом документе собраны термины, которые используем мы».
Далее следует страниц двадцать подробного разбора специфичных (и не очень) терминов, дабы познакомить новичков с местной кухней. Изучать мы их, конечно, не будем, но давайте поговорим об отношении к предметной области среднего разработчика, какие встречаются чаще остальных.
Пример из практики
Однажды, в мою команду пришёл джун, хотя сам он всем говорил, что миддл с пелёнок и даже проводит вебинары для студентов каких-то там курсов, мол собаку съел на вашей разработке (он не кореец – это фигура речи). Да и позиция не предполагала, что на ней окажется джун, но интервью тогда проводили, увы, без моего участия. Примечательно, что посыпался он не столько на нехватке знаний и навыков, сколько на резком нежелании разбираться в предметной области бизнеса, который он собирался автоматизировать.
Постановка задачи превратилась в головную боль: сложная коммуникация, ошибки, связанные с непониманием данных, разночтения, когда каждый кивает и говорит «понятно», но «понятно» как-то по-своему, по-особенному и вы уходите на второй, третий и, в конце концов, десятый круг разбора задачи. Пренебрежение предметной областью одним единственным разработчиком приносило неудобства всей команде и отнимало много времени, не вдаваясь в подробности – это было слишком дорого для всех нас. Он, простите, погроммист, ему эти две четверти или три тайма и, тем более, четыре периода в этом вашем снукере вообще по-барабану – аллергия на спорт (если у вас тоже, не обращайте внимания – это смешная шутка про виды спорта, который и был предметной областью).
Дисклеймер
Возможно, как руководитель, я не имею права перекладывать ответственность на нерадивого сотрудника и вообще сам виноват. Просто нам было не по пути и я уверен, что у него всё прекрасно, он вырос и отличный специалист. Но факт остается фактом, посредственные профессиональные навыки разработчика, ну те, что принято звать твердыми (включить компуктер или открыть IDE), оказались не так важны по сравнению с острой непереносимостью предметной области, а скорее с непониманием того, что это важно.
Вавилоняне
Можно ли рядовому кодеру не заморачиваться с пониманием предметной области и писать качественный, производительный код? Совершенно точно – да.
Если не верите, пройдитесь по компаниям и их совещаниям: пол дня два участника спорят, десять их молча слушают, а те решают проблему, которой ещё, как окажется и не существует. Невольно начинаешь оглядываться: кажется, что вдалеке шумят Тигр и Евфрат, а где-то поблизости вот-вот рухнет та самая башня, языки то уже смешались и никто друг друга понять не может. И что? И ничего – работают, к тому же успешно, раз банкет кто-то оплачивает.
Принеси то, не знаю что
Часто (чаще, чем вы можете себе представить и в местах, где «ну там то такого точно не может быть») бывает так, что все делают свою работу на пять с плюсом, но проблема бизнеса не решена и пользователь уже заплакал клавиатуру крокодильими слезами в попытках получить то, что ему требуется. Зато код – произведение искусства, производительный, даже SonarQube вами восхищается (это инструмент такой для анализа кодовой базы, с блекджеком и метриками).
Так происходит в том числе и потому, что исполнитель (программист) не в состоянии провалидировать задачу, не знает своего пользователя и не понимает проблемы бизнеса. Важно понимать, что это нормальная ситуация для совсем зеленого жуна: пусть тимлид с наставником эти вопросики обкашляют, он ещё синтаксис языка не до конца знает. Или, скажем, в заказной разработке – крыша поедет глубоко погружаться в предметную область каждого проекта.
Но в любом другом случае (на мой взгляд), понимать предметную область для программиста жизненно необходимо. Из бонусов: вы можете существенно сократить объем бестолковой работы, повлиять на выпуск продукта, который реально работает. Не в смысле, что кнопочки нажимаются, а джейсончики перекладываются – нет. В смысле, что проблема бизнеса решается, а пользователь получает то, что должен (унижение, презрение и проблемы – это не то).
Шейп ав май харт
Допустим погрузились в предметную область, имеется отличный программист: понимает бизнес и понимает пользователя. Вот бы ему в копилочку (не представляйте декольте сантехника, прошу) загрузить ещё пресловутого T-shape и будет совсем счастье. Чем занимается продакт? А проджект? Тестирование и дизайн? Аналитики вообще делают какую-то работу? С тимлидом-то понятно – этот всё делегировал.
Нет, не поймите неправильно, не надо досконально разбираться вообще во всей «чужой» работе, она на то и «чужая», но понимать смежников и этапы, на которых вы соприкасаетесь – бесценно. Например, фронтендир, который умеет в UX не хуже вашего дизайнера, а не только готовит отличный тыквенный латте, менеджер с техническим бэкграундом может быть крайне приятным в работе, как и дизайнер, который понимает ограничения и возможности разработки, ну а скрам-мастер, который… которого выгнали с позором (да, я знаю, что скрам-мастер это просто роль, но пройти мимо не мог). Всё это повышает шансы сделать что-то реально хорошее, а не просто какой-то код. И пусть этот код совершенный, только может оказаться, что он совершенно бесполезный (а вы и не в курсе).
Лучшее, что может сделать программист для себя и для команды – разобраться в предметной области. Кто поспорит?
Заключение и мотивация
Мне бы хотелось, чтобы на моём пути (в командах, на собеседованиях, в сообществах) встречалось гораздо больше осознанных разработчиков-профессионалов, понимающих, что язык программирования – это всего-лишь инструмент; код сам по себе ничего не стоит, если не решает проблему бизнеса; «чужая» работа (к сожалению или к счастью) не совсем «чужая», так как влияет на вашу и ещё много разного и полезного, что наполняет ежедневную рутину смыслами. А без смысла вы как угли в печке: уже задумываете новую статью на скатившийся Хабрахабр о том, как вы сгорели.
Powered by Программистика – телеграм-канал для программистов, в котором мы не переписываем документацию, а говорим о вечном – о том, что важно (и не всегда очевидно) в работе программиста и, конечно, шутим. Приходите, подписывайтесь, участвуйте в обсуждениях, если что-то из сказанного отзывается где-то в сердечке. Всем хорошего рабочего дня, держите огнетушитель поблизости.
Комментарии (93)
forthuse
23.10.2023 11:48+1Это - статья/заметка как крик профессиональной души и оправдание своих устоявшихся взглядов на мир "Розовых пони"?
P.S. А, реальность такая как дана нам не только в своих ощущениях и с ней нужно и имеет смысл работать.
То что джун при увольнении подумал о Вас и компании в которой он начал работать осталось же, конечно, за рамками данной "статьи".
Gromilo
23.10.2023 11:48+1У нас был такой разраб, он не хотел вникать в бизнес заказчика, он хотел "херачить код". Не сработались, но где-то, по любому, есть фирма которой подойдёт его стиль.
Ivan22
23.10.2023 11:48полно таких фирм. В любом банке аля сбер такие сотнями например нужны
SpiderEkb
23.10.2023 11:48+1Не в любом. Нам, к примеру, не нужны. Ну по крайней мене на уровне центральных систем.
У нас ценится человек, который, к примеру, знает как
Отобрать записи по условиям:
- Счет не закрыт
- Счет не зарезервирован
- Балансовый номер 2 порядка входит в контролируемыереализуется в реальном коде - какие поля в какой таблице отвечают за "счет не закрыт, не зарезервирован", что такое "балансовый номер второго порядка", как по номеру счета узнать его валюту и т.д. и т.п.
Т.е. люди, которым не надо разжевывать все до буковки.
Leetc0deM0nkey
23.10.2023 11:48У нас ценится человек, который, к примеру, знает как
Весь вопрос как ценится. И как будет цениться в перспективе. Я например когда-то работал на Казначество, и чем 401 счёт от 407 отличается знал. Но вот на вкусные позиции продавалось это так себе. Продавалось только хорошее знание SQL. Вы поставьте себя на место разработчика, он ведь тоже вкусно кушать хочет, а не "за всё хорошее" вкалывать. Сейчас конечно всё должно поменяться, знатоков "кафок и кубернетисов" стало как собак нерезанных. Но предметную область тоже надо выбирать с пристрастием. Может познания сернистостей нефти выгоднее чем знания особенностей закрытия опердня.
SpiderEkb
23.10.2023 11:48Весь вопрос как ценится.
Ну я лично не жалуюсь :-) Доход давно уже превышает основные потребности и позволяет систематично наращивать "финансовую подушку". Ну и "вкусным" для себя давно уже считаю не то, где заплатят на три копейки больше, а где задачи будут нестандартные и интересные.
А поскольку в разработке уже более 30-ти лет, то одним "закрытием опердня" знания не ограничиваются. Могу в промавтоматизацию пойти (в тот же нефтегаз приглашали, к примеру). Или что-то связанное с ГИС (есть базовые понятия работы с геоданными - системы координат, датумы, проекции, преобразования..., в случае чего быстро подтянуть точечно не проблема). Могу в обработку данных - неплохая физмат база в наличии, когда-то занимался регрессионным, статистическим анализом - тоже не с нуля начинать...
Естественно, плюс инструментарий - неплохо знаю "потроха" винды, достаточно уверенно - AS/400. Линукс - тут чисто базовые вещи, не сильно много под нее писал. Ну с БД неплохой опыт работы (в т.ч. с сетевой моделью БД приходилось сталкиваться). IP стек опять же (не на уровне фреймворков, а внутри).
Вот на прошлом месте интересно было - с одной стороны сеть промконтроллеров со всеми протоколами обмена от RS485 до UDP и TCP, с другой - привязка всего этого хозяйства к карте - работа с серверами OSM/2GIS на уровне формирования нужного участка карты на лету по координатам объектов в БД.
Я ж не говорю что упереться во что-то одно. Просто если чем-то занимаешься, кроме инструментов стоит и понимать что ты делаешь и зачем. А просто тупо кодить по ТЗ без понимания что к чему и как - это скучно.
Leetc0deM0nkey
23.10.2023 11:48Хорошо когда 40+, все деньги заработаны [пока был хайп], и уже можно работать чисто для души за мелкий прайс. Или вообще не работать. Но поставьте себя на место 30-. Семья, жена в декрете, ипотека. Сейчас уже даже чисто программные направления выбирать приходится очень тщательно. Вляпаешься в какой-нибудь фронтенд, и всё, не найдёшь больше работы за пределами этого болота. Прошли времена "тыжпрограммист" когда легко можно было перекатываться из "проавтоматизации" в "базы данных". Попробуй сейчас в сытные "микросервисы" например сунуться без уже присутствующего релевантного стажа. Сейчас резюме просто в мусорку улетает если там в свежем 3-5 летнем опыте нет нужных ключевых слов.
SpiderEkb
23.10.2023 11:48+1Ну конечно хорошо :-)
Только на месте 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 - это такая очередь, работа с ней идет через "системные указатели" и "машинные инструкции" и т.п.).
Так что есть места, где нужно уметь не с фреймворками работать, а на уровне системы.
Сейчас, кстати, на это есть спрос.
Попробуй сейчас в сытные "микросервисы" например сунуться
Вот уж точно нафиг-нафиг... То же болото.
Leetc0deM0nkey
23.10.2023 11:48Только на месте 30-летнего, как это ни удивительно, я был. В свое время.
В своё время и айти было куда проще в плане смена стека. Не технически - технически любой вменяемый инженер разберётся с чем угодно. Лишь бы не настолько радикально что бизнес просто не может долго ждать. С позиций найма сейчас попа в плане смены специализации. А если ещё зарываться в "предметную область", то вообще можно навсегда остаться без шансов выбраться в куда-то более денежное место.
Ну кто заставляет вляпываться во всякое?
Ну да, специально вляпывались. Люди когда-то думали что "перспективно". И хрен кто их теперь возьмёт туда где "есть спрос". Да я вообще сомневаюсь что в "Сделать высокопроизводительный коммутатор 10+Гигабит в секунду" возьмут любого кто не щупал эти коммутаторы на низком уровне хоть как-то.
lair
23.10.2023 11:48+1Когда я общался с разработчиками из банков, они всегда знали предметную область в этом самом банке лучше меня (хотя я занимался интеграцией, поэтому тоже про нее что-то знал).
appet1te
23.10.2023 11:48+6Вопрос просто в нейроресурсе. Позиция по типу «чужая работа», «я делаю только код не хочу знать предметную область» стоит рассматривать в контексте того, зачем человек транслирует такого рода сообщения. А этот вопрос уже упирается в вопрос куда и как ему направлять нейроресурс и какая у человека система ценностей и приоритетов.
И подумав, надев эту «ментальность» становится очевидно что человеку просто глубоко по… Человек не хочет ни грамма более тратить своего нервного топлива, сверх того что прописано. Вот есть какие-то обязанности прописанные, и он находит наиболее дешевый путь исполнения за тот же результат(бабки) для себя. Уважение(уважение от слова важность) к колегам, к их нейроресурсу, уважение к заказчику и его проблеме, оно стоит в списке приоритетов намного ниже чем экомномия мыслетоплива.
Видел на хабре похожую статью. Там один идейный и одухотворенный it специалист сетовал на собеседуемых девопсов. Мол, неужели не интересно развиваться в своей области, расширять собственные границы, глубоко понимать принципы и т.д. Почему людям так лень выйти за рамки существующего для них стека и любая попытка оформить задачу в отрыве от технологий вызывает сильный протест? Да все по той же причине. Обобщение задачи требует значительных трат нейроресурса. А человек рассматривает себя как блэк бокс с input и output причём исключительно с эгоцентричной позиции, не желая видеть всю систему
JYE
23.10.2023 11:48IMHO программист должен хоть немного понимать, то что он делает, иначе chatGPT какой-то получается. Но в наших реалиях зачастую, программист, единственный, кто понимает в бизнес процессах компании от начала до конца, и все нюансы которые, он не учел, т.к. не знал, и с другой стороны — условный бухгалтер, который забил на нормальную постановку, и обвиняющий программиста в своем промахе (хотел написать другое слово)
korvint
23.10.2023 11:48+3На большом личном опыте понял, что принимать от клиента задачу, не поняв, как именно он будет ее использовать для нужд бизнеса (и какой именно это принесет ему профит) - тупая потеря времени и денег. Даже если клиент торопит - мол сделай так-то и так-то. А ты видишь - что херня какая то. Значит, нельзя такую задачу делать. Пока сам не врубишься для чего она.
SpiderEkb
23.10.2023 11:48Аналогично и с разработкой - не понимая в каком контексте будет вызываться ваш модуль, какова прогнозируемая плотность вызова, взаимодействие с другими модулями и т.п. просто не получится реализовать эффективное решение.
Arkasha
23.10.2023 11:48-1Вы изначально не разделяете предметную область и бизнес, или программирование и бизнес. Это неправильно
GospodinKolhoznik
23.10.2023 11:48+1Подозреваю, что ваш "джун" (который судя по описанию всё же мидл, просто с другим подходом к работе, чем вы) в первую очередь думал о своей карьере. А для карьеры ему нужно развиваться в тех навыках, которые он сможет продать. Изучение узкой предметной области нигде не продашь, поэтому она ему неинтересна.
И это его право, придерживаться такой позиции. Ну а ваше право быть с ним несогласным и отказаться от его услуг.
Если спросите моего мнения, то я считаю, что по большей части "джун" прав. За знание, чем крокет отличается от крикета на рынке труда не платят. Да, наверное, минимальное погружение в предметную область ему бы не помешало бы, ну настолько, насколько можно погрузиться за несколько дней, но не более того.
Ибо, как показывает история, если каждый человек действует исходя из собственных, зачастую эгоистических интересов, всегда получается лучше, чем когда все вместе в едином порыве, за ради всеобщего блага.
Он действовал из своих личных интересов. Вы же считаете, что за ради общественного блага всей организации, он должен был действовать по другому. Но это так не работает.
prctmlm Автор
23.10.2023 11:48+3Всё по делу. Один нюанс я не считаю, что общественное выше собственного. Просто я считаю, что не надо сталкивать лбами интересы: либо общее, либо моё. Гораздо выгоднее через общее достигать своего, это открывает возможности. Ну а умение разбираться в том числе в предметной области (то бишь учиться и быть открытым к новому знанию) – прекрасно продается и дает преимущество. Если связь отсутствует между личными интересами и интересами бизнеса, очевидно не стоит там задерживаться, всё так.
kogemrka
23.10.2023 11:48прекрасно продается и дает преимуществ
Правильно ли я вас понимаю, что когда конкретно вы нанимаете разработчика в конкретно вашу команду, то, что разработчик увлеченно рассказывал вам на собеседовании про то, как отличается нефть разной сернистости и как и зачем её смешивают, вы засчитаете как некий уверенный плюс кандидату?
prctmlm Автор
23.10.2023 11:48+1Правильно ли я понимаю, что конкретно вы любитель передергивать из крайности в крайность? ????
Отвечая на вопрос, который видимо вы бы хотели задать: конкретно я, считаю плюсом в период испытательного срока погружение в предметную область и интерес к теме.
kogemrka
23.10.2023 11:48+1Правильно ли я понимаю, что конкретно вы любитель передергивать из крайности в крайность? ????
Нет, я просто хочу подсветить момент в отношении исходного комментария и вашего ответа) Don't hate the player, hate the game
Вот ваша компания (как и тысячи других компаний) формируют конкретные требования для оценки и найма соискателя. И ваша компания (как и другие компании) будут игнорировать погруженность соискателя в предметную область не совпадающую с вашей. Как и тысячи других компаний.
Неудивительно, что в рынке, в котором сформированы такие правила игры, игроки будут следовать правилам и стараться больше сил, времени и внимания уделять тому, что увеличивает их ценность. А тому, что их ценность не увеличивает - они будут соответственно стараться уделять поменьше сил времени и внимания).
Напротив, было бы странно, если бы такое явление не было бы очень распространено.
SpiderEkb
23.10.2023 11:48+1А при чем тут сернистость нефти? "Предметная область" это прежде всего понимание тех процессов, которые надо автоматизировать.
Ну вот ка пример. Когда-то давно (еще в 90-е) попросили сделать для студентов демонстрационную программку, иллюстрирующую принципы молекулярной динамики и машинного моделирования. Связь между микроканоническим ансамблем (импульсы отдельных молекул) и микроканоническим (температура и давление газа в сосуде).
Как думаете, возможно такое без понимания физики, потенциалов взаимодействия и т.п.? Кстати, гугля с википедией тогда не было - это где-то 89-90 гг.
Позже делал систему анализа торгов на одной местной бирже. И опять - пришлось вникать в то, как организованы торги, а потом еще вспоминать математику - всякий статистический анализ и т.п.
Пару лет назад зазывали на работу в один из банков. Им нужен был человек, который не просто знает платформу, на которой они работают и стек, но еще и имеет представлены о том, как происходит процедура закрытия опердня и перехода на следующий день - какие там могут быть варианты реализации и подводные камни. Т.е. человек с опытом разработки центральных банковских систем, а не просто абстрактный "разработчик".
И за 30+ лет разработки в самых разных областях (от обработки различных данных, до промавтоматизации и разработки центральных банковских систем) такого в моей личной практике навалом - чем лучше ты понимаешь что именно ты автоматизируешь, тем качественней результат твоей работы.
GospodinKolhoznik
23.10.2023 11:48А при чем тут сернистость нефти?
Вы действительно не понимаете при чём? Да при том, что человек потратил кучу сил и времени на то, чтобы быть полезным бизнесу, досконально изучал нефтепереработку и всё что с ней связано. А другой его коллега в это время игнорировал нефтепереработку, а вместо этого изучал Kubernetes, Kafka и NoSQL.
чем лучше ты понимаешь что именно ты автоматизируешь, тем качественней результат твоей работы
Да, первый работает лучше и качественнее второго, но платят ему меньше. Потому, что цена определяется не качеством работы, а спросом и предложением. А ему со знанием сернистости нефти податься больше некуда и его руководство это прекрасно понимает, что никуда он не денется, даже если ему платить чуть ниже рынка. А вот второй сотрудник со знанием широко востребованных технологий везде нарасхват, и чтобы его удержать, ему придётся много платить.
SpiderEkb
23.10.2023 11:48Не надо утрировать. Я так-то тоже умею.
Вот вы позиционируете себя как "плотник, хорошо владеющий пилой". А вам говорят "нужно сделать стол". А что такое стол? "Ну... это такая доска горизонтальная на четырех ножках". Делаете "доску горизонтальную на четырёх ножках". А ножки подламываются... Ну нет понимания как их крепить правильно...
В конечном итоге вам просто скажут - хорошо пилите? ну вот идите дрова пилить, на большее вы не способны.
Потому что деньги, которые вам платят - они приходят не от того, что вы там виртуозно пилите, а от продажи конкретного продукта, в данном случае стола. Нет стола - нет денег.
технологии - они для вас какую-то ценность имеют. А для заказчика все равно что там внутри. ему функционал нужен. А чтобы хорошо реализовать функционал, прежде всего надо понимать задачу, которую он решает, окружение в котором он работает.
В тех сферах, где мне приходилось и приходится работать, больше платят не тем, кто кафку с кубернетисом знает, но тем, кто умеет быстро и эффективно решать конкретные задачи. А это подразумевает не только владение инструментом, но и понимание того, что ты делаешь и зачем. Без этого... Ну продержитесь вы сколько-то на кафке с кубернетисом, но потом от вас будут ждать чего-то большего. Или навсегда застрянете на уровне кодировщика.
GospodinKolhoznik
23.10.2023 11:48Вы приводите в пример стол. Навык изготовления стола широко востребованный. Да и сами вы разбираетесь в области широко востребованной - банковских оперднях. Банков много, есть рынок где можно предложить свои знания и за них заплатят. Но есть предприятия с уникальными сферами. И в их предметную область погружаться никто не хочет, т.к. потом себя не продашь. Как это часто бывает у программистов-наладчиков оборудования на предприятиях. Человек может быть спецом экстра класса в программировании ЧПУ прядильно-вязальной автоматики, и отлично разбираться во всех видах пряжи и бесчисленных нюансах вязания, натяжения нитей, узлов, рядов и узоров. Но, как правило, платят за такую работу не очень много.
Gromilo
23.10.2023 11:48Конечно! Но при условии, что смешивание нефти как-то влияет на код и решаемые задачи.
Например, чисто из головы (я про нефть ничего не знаю), рассказывает, что есть нефть разной зернистости в определённом количестве, есть задача её смешивания с онлайн контролем, но есть разные нюансы, типа температуры, вязкости и т.п.. А дальше рассказывает как считали, как мониторили, откуда данные попадали в систему, как обеспечивали отказоустойчивость, какое участие он принимал во всём этом и т.д.
Даже, если кандидат не знает всего процесса (от него до пользователя было 15 микросервисов), я ожидаю, что он будет хорошо знать свою полянку и на что она влияет.
kogemrka
23.10.2023 11:48Конечно! Но при условии, что смешивание нефти как-то влияет на код и решаемые задачи.
Суть мего примера - "нефть не имеет вообще никакого отношения к вашей предметной области" (куда вы человека нанимаете). Ваша предметная область в это примере - это спорт, таймы, крикет, крокет, вот это всё из исходного поста.
Можете нефть и спорт заменить на две любые области, главное, чтобы они находились друг от друга как можно дальше.
Gromilo
23.10.2023 11:48Согласен, из нефти в нефть легче перекатиться.
Мой же посыл, разработчик на собесе должен уметь объяснить какие задачи и какого уровня он решал. Его предыдущий домен - это декорации.
От уровня решаемых задач, так же, зависит уровень вопросов, которые он задаст. Это важно на собесе.
Так же я не отрицаю, что нужны "хардовые спецы", чтобы прийти и затюнить кафку. Но они не особо занимаются разработкой.
leotsarev
23.10.2023 11:48Если на испытательном сроке он прочтет книгу про нефтепереработку, то засчитаем.
SpiderEkb
23.10.2023 11:48+2Противопоставление "общественное" vs "личное" в корне неверно. Если под "общественным" понимать интересы того, кто платит вам деньги за вашу работу. Они просто не будет вам платить, если вам откровенно наплевать на его интересы.
Залог востребованности в том, чтобы уметь находить приемлемый для всех баланс между "личным" и "общественным".
appet1te
23.10.2023 11:48В первую очередь думал о своей карьере и инвестировал в свои скилы? По описанию этот джун относится к тому типу людей, которые максимально зажимают энергию. Инвестиция в себя дело очень затратное. Как правило такие работают на минимум и поддерживают самый базовый набор навыков для сохранения своего биологического(именно нейронные свзязи имеются в виду, точнее их полный покой и отсутсвие создания новых) комфорта, такой человек не приходит домой в состоянии «вау как я хочу изучать что-то новое» предметную область, технологии, новые сферы(из it) и т.д Доработал до черты и все и так до следующего дня
ALexKud
23.10.2023 11:48Внутри компании люди сделали тз на свою задачу которую они хотят автоматизировать и вот спустя полгода первый релиз со всеми хотела и они юзают месяц но последние 10 дней никто не заходил в систему. Оказывается в ней надо работать! С бумажками проще и привычнее.
ssmaslov
23.10.2023 11:48+1Спор остроконечников с тупоконечниками. Есть два подхода, условно промышленый и условно крафтовый, в первои исполнитель (разработчик) знает о предметке примерно ничего во втором примерно все. И есть еще бесконечное число промежуточных вариантов. И все они (в том числе) применяются в жизни. Мне несколькоближе именно промышленный подход, но его труднее реализовать, нужна сложная работа с заказчиком по выстраиванию процессов, это никто не любит.
Проще тешить себя мыслью что ты лучше заказчика знаешь область которой он годы учился и потом годы нарабатывал опыт. И делать это каждому джуну. Никого не осуждаю, сам таким был
AHMED_RAPIRA
23.10.2023 11:48От компании еще многое зависит. Если царит микроменеджмент, с ежедневными церемониями, с тайм-трекингом задач. С какой-то давлеющей иерархией, сквозь которую не пропихать свои идеи, и в итоге делается просто какой-то колхоз. А самое главное - с фиксированными закрытыми окладами без премий, то и получайте тогда "кодеров", которые будут из-под палки работать. Да еще и параллельно гребущих где-то в другом месте, таком же.
SpiderEkb
23.10.2023 11:48С какой-то давлеющей иерархией, сквозь которую не пропихать свои идеи
А можно пример "своей идеи"?
Ну вот представьте, есть система, достаточно сложная, в которой крутится 100500 разных процессов. И приходит заказчик ("бизнес") с просьбой автоматизировать и добавить туда еще один процесс. Но так, чтобы остальные не зацепить. В такой ситуации, чтобы "пропихнуть свою идею", нужно очень хорошо знать всю систему в целом - что и как там работает, что с чем связано. Ну просто чтобы в процессе интеграции не огрести проблем по самое немогу.
Ivan22
23.10.2023 11:48пример своей идеи - "давайте, наймем аналитика, а то я зае.....ся полдня за юзерами бегать, а вторые полдня от них бегать чтобы спрятаться и немного код пописать"
SpiderEkb
23.10.2023 11:48От контор, где разработчику приходится бегать за юзерами и от них надо держаться как можно дальше изначально.
А на предложение "давайте наймем..." могут ответить - "давайте, но платить ему будете вы лично из своего кармана".
Ivan22
23.10.2023 11:48платит тот кого бюджет, а нанимают тогда когда это повышает эффективность всей команды, у нас так.
Ivan22
23.10.2023 11:48Програмист вникающий в проблемы бизнеса - это как продавец из всем известного анекдота:
Yuriy_75
23.10.2023 11:48Вот пришел программист с хорошим знанием разработки. Ему платят по рынку. Дальше он начинает погружаться в предметную область. Допустим, хорошо погрузился. Это погружение будет как-то оценено в денежном измерении? А если не будет, зачем погружаться?
Gromilo
23.10.2023 11:48+2Пока сотрудник не погрузился в предметную область, он не может выйти на нормальную производительность. Компания, в некотором смысле, инвестирует в него.
Если сотрудник так не выйдет на норм производительность, тот тут несколько путей:
Уволить
Смириться, всё равно за эти деньги никого лучше не найдёшь
Построить процесс так, чтобы люди с большими головами говорили что кодить
Третий вариант опасен выгораниями, т.к. сотрудника выжимают (ибо уплочено) и он не понимает что происходит.
Yuriy_75
23.10.2023 11:48>>Компания, в некотором смысле, инвестирует в него.
В каком смысле? При собеседовании кто-то говорит, мол, через полгода не выйдешь на нужный уровень - уволим? А раз этого не говорится - отчего программист должен сам додумывать, что там в голове у менеджмента?
SpiderEkb
23.10.2023 11:48Да никто не будет ничего на собеседовании говорить.
От человека будут требоваться решение поставленных задач в заданные сроки. Если справляется - есть шанс на повышение и т.п. (за себя могу сказать что на "потолок" до ложность в разработке вышел за четыре года года, за шесть лет уровень оплаты вырос в 3.5 раза). Не справляешься - в лучшем случае завязнешь и по уровню и по деньгам надолго.
А чтобы справляться, не надо тратить время по каждой задаче на выяснение "а тут что, а это как, а это что такое", но понимать сходу о чем речь. А иногда еще и самостоятельно принимать решения - "в данном случае в этих условиях эффективнее будет сделать вот так, а не так". Но для таких решений надо понимать суть процесса.
Yuriy_75
23.10.2023 11:48+1Можно подумать, если справляешься - нет варианта остаться по деньгам на том же уровне (если не считать ежегодной компенсации инфляции, называемую индексацией). Да запросто.
Gromilo
23.10.2023 11:48Обычно это называют "время на погружение в проект", т.е. пока погружаешься, точно будешь медленнее остальных работать. Если после погружения программист "не тянет", то там уже от фирмы зависит.
Грубо говоря, если Вася по 10 раз не может пройти ревью, потому что косячит из-за незнания предметной области, то зачем нам такой Вася?
SpiderEkb
23.10.2023 11:48Что такое "хорошее знание разработки"? Умение хорошо буковки печатать на нужном языке?
"Программист", который не понимает что он программирует суть простой кодировщик. Раньше этим занимались девочки на ВЦ - им приносили программы на бланках, они их на перфокарты набивали.
Разработчик - это немного больше. Он должен понимать что он делает. И почему именно так а не иначе. Если это системная разработка - должен знать как система устроена изнутри. Если это банк - там все еще сложнее. Много команд по разным направлениям и везде свои сущности. Работаешь в команде комплаенса? Ты не должен спрашивать что такое "списки росфина", "стоплисты", чем "полное совпадение субъекта с клиентом" отличается от частичного... А если он будет постоянно ходить и спрашивать "а где вот это лежит, а что вот это значит..." - долго не продержится. На первых порах простительно, но потом от него будут избавляться просто потому что он будет впустую тратить свое и чужое время.
Yuriy_75
23.10.2023 11:48Ну да, симптоматично. Я задал простой вопрос - каким образом прогресс программиста в предметной области будет вознагражден материально. Вместо ответа - манипуляции.
SpiderEkb
23.10.2023 11:48В моем (там где работаю) - очень просто. Прогресс в предметной области позволяет быстрее и эффективнее решать поставленные задачи. Что приводит к хорошим оценкам деятельности. Хорошая оценка дает повышенный коэффициент квартального бонуса + положительное решение в случае вопросов "есть возможность повысить одного человека в должности - кого повышать будем?" Или "нам увеличили ФОТ - кому сколько добавим?". Т.е. вы становитесь человеком, приносящим больше прибыли и вас выгоднее "подкармливать" чтобы не ушли. Если там, где Вы работаете не так, это или не нормально. Или просто Ваша позиция такова, что никто за Вас особо не держится - уйдете и бог в Вами, другого такого же найдут.
В моем конкретном случае развитие не только в плане технологии, но и предметной области дало увеличение оплаты в 3.5 раза за 6 лет. Плюс повышение по должности (через 5 лет мне вообще предлагали из разработчика в архитекторы направления переходить, но тут уже сам отказался потому что не интересна эта тема, хватает того что техлид направления).
Так понятно?
Yuriy_75
23.10.2023 11:48-1>>дало увеличение оплаты в 3.5 раза за 6 лет
Вы в рублях считаете? А во сколько раз за 6 лет увеличилась стоимость кв. метра жилья?
kogemrka
23.10.2023 11:48Разработчик - это немного больше. Он должен понимать что он делает. И почему именно так а не иначе.
Я всё ещё не понимаю)
долго не продержится.
На первых порах простительно, но потом от него будут избавляться просто потому что он будет впустую тратить свое и чужое время.
Вот мне надо нанять разработчика, допустим.
Вот есть проблема, озвученная автором - "разработчики хотят код фигачить, а не в предметную область погружаться".
Мотивация, почему разработчику хочется код фигачить - мне понятна.
Экономические предпосылки, почему разработчику может быть глубоко не интересно вникать в предметную область - мне понятны.
А вот как то, как задачу найма поможет решить то, что мы с вами тут начнём таких разработчиков называть "ненастоящими разработчиками" и сравнивать с "девочками на ВЦ" - мне решительно непонятно. Вообще никаких плюсов не вижу.
Я бы на месте разработчика услышав вопрос в духе "а ты настоящий разработчик или девочка из вц?" от нанимающего менеджера - бежал бы сверкая пятками. Особенно если речь идёт о разработчике, который вникать в бизнес-требования умеет и готов ценность внести.
prctmlm Автор
23.10.2023 11:48+1Во-первых, согласен с соседним комментом, во-вторых, как использовать свои навыки и знания, контакты и отношения с людьми себе на пользу зависит от человека, польза и в деньгах может выражаться, и в стабильности, и в уникальности, и в чём угодно ещё. Это поиск возможностей. Вас никто не обязан продвигать по службе просто потому что, но вы, в свою очередь, можете не оставить шансов поступить иначе. Крепкое понимание предметной области – это отличительная черта, преимущество, в том числе. Конвертируется ли это в деньги не вопрос. Вопрос: сможете ли вы конвертировать это в деньги? Если получается с технологиями, то и здесь получится. Важно, конечно, понимать, что предметная область не заменяет навыки программирования, а дополняет.
Yuriy_75
23.10.2023 11:48+1>>Если получается с технологиями, то и здесь получится.
С технологиями то проще. Считаешь что мало платят? Выучиваешь получше технологии, находишь того, кто заплатит больше, меняешь место работы. Задача выполнена.
А как хорошее знание предметной области конвертировать? Не переставая при этом быть программистом? Научите...
SpiderEkb
23.10.2023 11:48Технология - это инструмент. А платят из тех денег, что идут с продажи продукта. Т.е. за умение создавать продукт. Тут мало одних технологий (ну или вы работаете в какой-то такой области, где все продукты одинаковые у всех производителей).
Если вы нанимаете человека, чтобы сделал вам электрику в доме, вам не важно насколько виртуозно он пассатижами или отверткой владеет. Вам важно чтобы он правильно посчитал сечения проводом, номиналы автоматов, распределил нагрузку по фазам и т.п. - за это вы ему платите.
А с вашим подходом всегда будет винтиком-подмастерьем, который делает ровно то, что ему сказали, но на большее не способен. А это тупик достаточно быстро.
Yuriy_75
23.10.2023 11:48Сравнение с электриком имело бы смысл только при работе по договору подряда. Есть работа, которую надо сделать, есть цена. Выполнил - деньги получил. Да, некоторые программисты так работают, и в этом случае они вероятно будут заинтересованы в прокачке предметной области.
SpiderEkb
23.10.2023 11:48А вы как работаете? "Я человек маленький, хожу сюда за зарплатой, делаю ровно что сказали"? И как оно развивается? Просто оцените для себя - сколько мест работы поменяли за последние 5 лет и во сколько раз вырос доход?
Я, даже будучи на бессрочном контракте, все равно работаю как на подряде - мне платят за решение конкретных задач. Хорошо решаю - хорошо платят и увеличивают бонусы и оплату (ну и всякие мелкие приятности типа "мы его не будем всякой фигней грузить рутинной - от него на сложных задачах толку больше, с ними не все справятся, а для фигни кого попроще припашем" или "хочешь в архитектуру - твоих компетенций за глаза уже хватит? не хочешь? не интересно? ну ок, занимайся чем нравится").
kogemrka
23.10.2023 11:48Смотрите, никто не спорит, что программист, погружающийся в предметную область будет работать лучше и приносить больше пользы, чем не погружающийся.
Но тут ситуация такая же, как, допустим, с job hopping'ом.
Правда же, что сотрудник, который работает в компании 10 лет скорее всего намного глубже погружен в процессы внутри компании и будет работать эффективнее, чем человек, пришедший полгода назад и через полтора года планирующий уйти? Да очевидно, что так.
Но вот есть рынок. Есть наниматели, которые устанавливают правила игры. Наниматели устанавливают такие правила, по которым Job Hopping - становится выгоден.
Если такие правила игры установлены - соискатели будут так себя вести в массе своей. Это просто факт.
Никакие уговоры, манипуляции, пламенные речи, искренние возмущения, коллективные осуждения, тренды в тик-токе, написание книжек про культуру настоящих разработчиков - ничего из этого списка ни в коем случае не изменит и не может изменить ситуации на рынке.
Кроме одного - смены правил игры.
SpiderEkb
23.10.2023 11:48Наниматели устанавливают такие правила, по которым Job Hopping - становится выгоден.
Кому выгоден? Нанимателю? Естественно. А что вам выгоднее не задумывались? Не пробовали поставить себя так, чтобы работодателю было выгоднее повысить оплату вам, чем искать нового "кузнечика"?
Gromilo
23.10.2023 11:48На собесе рассказываешь какие проблемы разрулил на предыдущем месте работы. Типа была такая-то проблема, желательно системная, вот так я её решил, вот так всем стало жить лучше. Исходим из того, что код - это инструмент с помощью которого программист решает задачи.
Правда, такой опыт можно получить только на практике. При этом нужно как-то взаимодействовать с заинтересованными лицами, иначе никаких важных решений не принять. Не получится, сидеть и не отсвечивать.
SpiderEkb
23.10.2023 11:48+2Меня на последнем собесе в основном спрашивали кто задачи ставил, кто архитектуру разрабатывал, насколько был самостоятелен в принятии конкретных решений (писал "точно по ТЗ буква в букву", или сам предлагал наиболее эффективное решение).
Как потом узнал (задним числом) сильно впечатлило когда рассказал что команда была маленькая и все архитектурные решения вырабатывались сообща, ТЗ каждый себе вырабатывал сам (на свою часть задачи), потом все это согласовывали и состыковывали воедино. Фактически это и было основанием для быстрого решения "этого - берем" и офера на следующий день после собеса с командой.
Сравниваю что было еще лет 5 назад и сейчас. Тогда просто не получалось находить эффективные решения потому что не понимал как оно работает. Приходилось тупо по ТЗ фигачить, а что там напридумываают уж...
Сейчас, когда есть понимание как оно работает (в том направлении где работаю) намного проще решать всякие сложные задачи, требующие высокой эффективности. Просто в силу понимания как оно работает и где можно что-то (например) закешировать, а где, наоборот, нельзя т.к. требуются актуальные данные которые могут изменяться в параллельном процессе.
Естественно, совершенствования в технологиях это все никак не отменяет. Просто понимание процесса + владение технологиями дает существенно лучший результат чем что-то одно из двух.
Yuriy_75
23.10.2023 11:48Только вот при смене работы прокаченное немалыми трудами знание предметной области может обнулиться. Если только новое место работы не в аналогичной сфере, типа из банка в банк уйти. Но если только такие места искать - значительно сужается область поиска.
SpiderEkb
23.10.2023 11:48Зато при выборе между человеком "знающим кафку и кубернетис" и человеком, "знающим кафку, кубернетис и имеющим опыт работы в данной области" - кому предпочтение отдадут?
Понимание предметной области не отменяет знание технологий. Не надо противопоставлять эти вещи - они из разных областей.
Кстати, в банк я пришел из промавтоматизации. И на совсем другую платформу и технологический стек. Что абсолютно не помешало здесь выйти на достаточно приличный уровень. и по технологиям и по предметной области (хотя в этом плане, конечно, пробелов еще хватает т.к. область очень обширная).
А те вакансии, которые прилетают (сам давно уже не ищу, сами приходят) - везде "предметку" какую-никакую хотят. Будь то опыт работы с промконтроллерами, или понимание как IP стек работает на низком уровне или еще что-то такое... Т.е. то, что далеко выходит за пределы всяких фреймворков и конкретных языков программирования. И, поверьте, подтянуть до нужного уровня язык или освоить еще один фреймворк куда проще, чем понять тонкости области в которой работаешь.
Когда-то давно (лет 20-25 назад) тоже только "в технологии упирался". Пока не понял что там потолок достаточно быстро достигается, а дальше и выше можно развиваться только в сочетании со знанием предметной области в которой работаешь.
Leetc0deM0nkey
23.10.2023 11:48Зато при выборе между человеком "знающим кафку и кубернетис" и человеком, "знающим кафку, кубернетис и имеющим опыт работы в данной области" - кому предпочтение отдадут?
Тому кто умеет на собесе красиво срать в уши. :)
Gromilo
23.10.2023 11:48+2Есть такое. Но я бы не сказал про немалые затраты. Для меня предметная область - это часть задачи, которую я решаю. Просто часть разработки.
Когда есть куча вариантов решения, поднятие на уровень верх помогает принять решение.
kogemrka
23.10.2023 11:48Вопрос: сможете ли вы конвертировать это в деньги?
А вот этот ваш джун-не-джун, с которым вы расстались - он новую работу не нашёл? И платят ли ему на новой работе меньше? Просто если ему таки не платят там меньше, то вопроса такого, получается, в принципе и не стоит.
А вот вопрос, как быстро вы сможете нанять разработчика, который подходит под ваши ожидания, за те деньги, которые вы платили тому разработчику, и как отобрать среди соискателей разработчика, который не имеет аллергии на предметную область - стоит (иначе бы не было и поста).
lair
23.10.2023 11:48+1Это погружение будет как-то оценено в денежном измерении?
Ну да, а что? Я на такие вещи смотрел на регулярной оценке сотрудников, и это влияло на повышение зарплаты.
SpiderEkb
23.10.2023 11:48Именно. И повышение з/п и коэффициенты при начислении регулярных бонусов - все это учитывается.
kogemrka
23.10.2023 11:48Вот смотрите, вот у вас - конкретный ответ на конкретный вопрос)
приходит джун, говорит, что не очень понимает, почему от него требуется в эту область глубоко погружаться
вы объясняете ему, что вот, смотри, дорогой джун, ты не погружаешься, а Васян погружается. Тебе на ревью поставят +-, а Васяну поставят ++ и зарплата ваша меняться будет совершенно разным образом. А повторяться этот процесс с ревью будет ни раз и не два.
Наглядно и понятно)
---
Автор статьи на тот же вопрос отвечает на через "польза и в деньгах может выражаться, и в стабильности, и в уникальности, и в чём угодно ещё. Это поиск возможностей... Конвертируется ли это в деньги не вопрос. Вопрос: сможете ли вы конвертировать это в деньги?".
Может быть, конечно, с этим джуном-не-джуном в статье и был разговор, где ему объяснили, что это ему выгодно, но что-то мне подсказывает, что такого разговора не было.
prctmlm Автор
23.10.2023 11:48Я ответил по концепции, а вас волнует всего лишь её иллюстрация. Вопрос более широкий, чем конкретный пример. О чём я говорю или не говорю с командой в другой раз, если хотите)
Yuriy_75
23.10.2023 11:48Ну это предполагает и наличие системы оценки сотрудников. И возможность по результатам этой оценки реально повысить з/п. (Не путать повышение зарплаты с компенсацией инфляции). Если такие предпосылки есть, и правила игры заранее озвучены - тогда может иметь смысл. Но такое ведь не везде.
Sadovikow
23.10.2023 11:48Полностью поддерживаю докладчика.
Никто не отменял работу продактов, но разработчик, который более глубоко понимает предметную область, вероятно быстрее будет понимать поставленные задачи, и сможет эффективнее с ними работать.
Ну и если так подумать. Погружение в предметную область (поверхностно) не занимает какого-то огромного количества времени, а эффект может принести колоссальный.
язык программирования – это всего-лишь инструмент
за это отдельный +
Ivan22
23.10.2023 11:48слово "поверхностно" меня тут смущает
Sadovikow
23.10.2023 11:48У всех предметные области разные. Где-то можно пройти полное погружение за неделю, где-то и полгода не хватит. Я имею ввиду про погружение без ненужных деталей
Ivan22
23.10.2023 11:48если без "ненужных" деталей погружаться, то 99% что без нормального аналитика все равно не обойдешься. Ну либо наворотишь херни, что потом переделать дороже выйдет
SpiderEkb
23.10.2023 11:48+2На мой взгляд формулировка не точная. Скорее не "поверхностно", но "достаточно для повышения эффективности решений поставленных задач".
Ну вот мне совершенно не требуется изучать экономику, законодательство в банковской сфере и т.д. и т.п.
Но вот знать, что 20-значный банковский счет это не просто набор цифр для работы полезно. Что первые 5 цифр - это "балансовый номер 2 порядка" (который много где используется для фильтрации, являясь типом счета), а следующие за ним 3 цифры - код валюты счета. Знать что у клиента несколько типов адресов (фактический, регистрации, юридический, почтовый...) и прочие такие вот вещи.
Буквально вчера вечером прямо тут попалась на глаза статья Фильтрация объектов по координатам (широте и долготе) По мне так лютый костылинг. А стоит чуть-чуть погрузится в "предметную область" чтобы понять что любая карта есть прямоугольная проекция геоида на плоскость. И есть способы перехода от геодезических координат в прямоугольные. Работать с которыми намного проще и быстрее.
Вот пример получения более эффективного решения в случае когда владеешь не только инструментом, которым работаешь, но и немного ориентируешься в предметной области. Тут для начала достаточно просто знать о существовании проекций. А нужные подробности уже гуглятся в том объеме, который потребен для решения задачи.
ptr128
23.10.2023 11:48Ну вот мне совершенно не требуется изучать экономику, законодательство
До синьора, включительно - не надо. Но для тимлида или архитектора - уже очень желательно. Достаточно часто нарываюсь на то, что после того, как, для примера, задача прошла от приказа МинФина через финдиректора клиента, его зама (key-user), и консультанта-аналитика, "испорченный телефон" искажает суть задачи до неузнаваемости. И только обратившись к первоисточнику, тому самому приказу, становится понятно, что архитектура должна меняться на совершенно не том уровне одной узкой задачи, как прописано в постановке, а существенно глобальней. И это будет в итоге одна модификация, а не ряд несвязанных мелких.
А стоит чуть-чуть погрузится в "предметную область" чтобы понять что любая карта есть прямоугольная проекция геоида на плоскость.
А когда дело касается расстояний хотя бы на широте Мурманска, даже сфера не устраивает, как приближение, и прогноз начинают совпадать с фактом с приемлемой точностью, только если брать, как приближение, элипсоид. Так что все от задачи зависит. И кратчайший путь от Домодедово до Елизово лежит над Северным Ледовитым океаном. Хотя они, примерно, на одной параллели.
ptr128
23.10.2023 11:48В своё время я понял, что высшего технического образования мне не хватает и получил ещё и высшее экономическое с юридическим уклоном. Это действительно позволило эффективно общаться напрямую с заказчиками. Но требовать такого даже от синьора - перегиб. Для таких задач есть аналитики, а в спорных вопросах - тимлид или архитектор.
Так же даже от синьора нет смысла требовать глубокого понимания регрессионного анализа или дробного интегрирования. В коде ARFIMA он воспользуется по постановке, даже не погружаясь в то, как же она работает. А коэффициенты подберёт или аналитик, или кроссвалидация.
NeoCode
А зачем тогда нужны все эти продакты, проджекты, менеджеры и аналитики? Кажется это их задача: выяснить чего в точности хочет заказчик, перевести эти пожелания с языка предметной области на общечеловеческий, и оформить этот перевод в виде документа - задания программисту. А программист уже переводит с общечеловеческого на язык машины/ОС/фреймворка и т.п.
prctmlm Автор
Справедливо, но это предполагает, что все остальные кто там этим всем должен заниматься глубоко погружены в технологии, так же глубоко понимают все возможности и ограничения разработки, а ещё никогда не ошибаются. То есть это рабочая схема, самая распространенная даже наверно, но у неё есть проблемы – люди не совершенны. А командная работа на всех этапах нивелирует эти несовершенства, не полностью, конечно, но так приятнее. Зависит от приоритетов, как всегда, на мой взгляд.
lair
На самом деле, нет. Их задача (после сбора пожеланий) перевести их с того языка предметной области, который используется заказчиком, в тот, который будет использоваться на проекте (обычно более формализованный). Классическое описание этого - у Эванса в Domain-Driven Design.
NeoCode
Можно предложить такую формулировку: "перевести на тот язык, который будет понятен всем участникам команды". И если там есть непонятные термины предметной области, без которых никак - то их задача разжевать эти термины (в том числе уточняя у заказчиков, консультантов, в специальной литературе и т.п.) и оформить эти разъяснения документально, причем все это следует обсуждать и делать вместе с программистами.
lair
Трюк состоит в том, что после "разжевывания" термины никуда не денутся - потому что они нужны, чтобы упростить общение, сделав его более коротким и однозначным, - просто появится словарь, который их описывает (я вообще рекомендую с такого словаря начинать любые сколько-нибудь нетривиальные требования). Чтобы начать работать на проекте, нужно будет этот словарь освоить - и это как раз и будет изучением предметной области (словарем дело не ограничится, потому что дальше будут отношения, сценарии использования и так далее).
SpiderEkb
Как уже отметили, дело не в терминах (не только и не столько в терминах), но в понимании как оно вообще работает. Без этого понимания сложно написать что-то более-менее эффективное для сколь-либо сложной системы/процесса.
Ivan22
а вообще нужна золотая середина
SpiderEkb
И да и нет.
Если, допустим, речь идет о сайте, который надо сверстать (ну условно говоря), то там да - продакты с аналитиками договорятся с заказчиком как оно должно выглядеть, а программист уже сверстает - сайт, он и в африке сайт, что порнхаб, что госуслуги - принципиальной разницы нет.
Но если речь идет о какой-то сложной бизнес-логике, да еще в большой системе, то все становится сложнее - если разработчик "ни в зуб ногой" в том как все это устроено, то ему придется расписывать задачу до уровня псевдокода и это будет уже не разработчик, а просто кодировщик. И не дай бог, аналитик где-то там ошибется/опечатается - кодировщик тупо все это перенесет в код и скажет что так и было. И чем он тогда отличается от тех девочек, что когда-то сидели на ВЦ и с бланков на перфокарты перебивали чужой код?
Еще хуже, когда такой "разработчик" еще и инициативу проявит - "ща, мы вот тут закешируем - вообще все летать будет". Летать-то будет, но не туда. Потому что вот именно "тут" кешировать никак нельзя иби "это" может параллельно меняться в другом процессе и надо всегда иметь актуальное значение. Но для этого надо хоть в общих чертах представлять как оно работает в целом. Т.е. как-то иметь представление о "предметной области".
С другой стороны, если разработчик давно крутится в предметной области и представляет что там и как, он уже может и аналитика проконтролировать и поправить - "тут надо вот такой срез данных, предлагается вот такая таблица, но эти же данные можно и из вот этой таблицы взять - она поменьше, там индекс лучше в план запроса ложится...". Это уже качественно иной подход к задаче.
Leetc0deM0nkey
Справедливо, но надо понимать что сейчас в айти очень серьёзная конкуренция, и она будет только нарастать. Найти просто кодерка на условной Жаве уже сейчас ни разу не проблема. А вот "кодерок" который ещё и хорошо разбирается в предметной области, в бизнес-процессах конкретного бизнеса - поди найди такого. Поэтому хочешь жить - придётся потихоньку перекатываться из чистого кодерка в [полу]продакта по-совместительству. Увы, но за те же деньги, скорее всего.
ArchimeD
В моем мире продакты ищут потребности пользователей и способы закрыть эти потребности.
event1
Во-первых, мешаться под ногами, чтоб жизнь мёдом не казалась. Во-вторых, отвечать на дурацкие вопросы людей, которые не умеют в гугл или базу знаний. В-третьих, делать красивые отчёты для начальства. И в-четвётрых, выбивать бюджеты. Очень полезные люди, в целом.
SadOcean
Они могут расшифровать, но не могут сделать задачу предметной области проще, чем она есть в предметной области.
Какую то часть все равно нужно понимать конечному исполнителю.
mvv-rus
Не совсем так. Я изучал этот вопрос где-то лет двадцать назад. И тогда считалось, что для описания "пожеланий заказчика" - точнее, предметной области бизнеса, функционирования предприятия и т.п. - нужно делать описания не на общечеловеческом языке, а с помощью специальных средств, таких как диаграммы САДТ (IDEF0) для функционального описания, диаграммы "сущность-связь"(IDEF1) для описания данных предприятия и т.п. Был, как минимум, один целый набор методологий (IDEF) для разработки таких описаний.
Изучал я по книгам и статьям в журналах, естественно: в фирмочке, где я тогда работал, таких сложностей не требовалось. Хотя кое-что из этого инструментария использовал - к примеру автоматическую генерацию схемы БД по методологии "сущность-связь" программой ERWin
Как с этим в нынешней реальности - не знаю. Но, судя по таким вот статьям - не очень хорошо, снизить сложность разработки и требований к квалификации программистов, непосредственно пишущих код, путем отвязывания непосредственно разработчиков от неточностей и неясностей предметной области, выяснение котторых - задача аналитиков, не получилось.