Pull to refresh

Comments 55

Ну хватит уже плодить мультистаночников, senior это старший разработчик, и да, его задача писать код, кроме него есть еще техлид, тимлид, аналитики и прочие

Другое дело что компании хотят одним человеком закрыть 2-4 роли, но это скорее проблема компаний)

Во-первых, не во всех компаниях есть все перечисленные вами роли.

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

Лично по моим ощущениям, сам кодинг занимает наверное процентов 25-30 рабочего времени (и это самая легкая часть). Остальное время - это продумывание решений, взаимодействие с другими командами, ревью кода, анализ задач и т.д.

чем он отличается от мидла или джуна

Как минимум, тем, что сможет решить проблему, от которой меньшие грейды обгадятся. Ну, и он может принимать решения с учетом большего опыта.

Так выше же написали что принимать решения не нужно, нужно только кодить, а принимать решения это мультистаночность. Написано в задаче вкрутить кафку, он должен вкрутить кафку, а не сказать слово против, и что аналитик/заказчик не прав, не должен предлагать альтернативы. /s

Вот объясните мне, как идиоту, просто... Вы что серьёзно считаете, что разбираетесь в бизнесе заказчика лучше чем сам заказчик? Будучи программистом, в чужом бизнесе....?

В бизнесе, нет. В технологиях, для внедрения которых заказчик нанимает программистов, да.

Вы не видите здесь противоречие? Зачем ему решать проблему если он только кодер, проблему решает техлид, архитектор. Кодер делает что ему сказали делать. Извините но я не понимаю, в чем я не прав в комментарии выше. Что старший разработчик сам может решить сложную проблему? Сам может обозначить проблему? Сам может проектировать решения? Или делегировать решение проблемы.

Вопрос из разряда "чем капитан отличается от штурмана"

если исходить, что старший разработчик - это кодер, то чем он отличается от мидла или джуна? Скоростью печати?

Если бы вы хоть чучуть шарили в разработке, а не во взгляде со стороны, такой вопрос просто не появился бы в голове.

сам кодинг занимает наверное процентов 25-30 рабочего времени

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

Сеньер нужен там, где полезен его опыт, если же корабль не знает куда ему плыть, то все равно какой ветер дует.

не во всех компаниях есть все перечисленные вами роли.

Вот прям интересно — и чья же это проблема?

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

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

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

Может быть, вам пора работать на себя, а не на дядю?

В целом ок, я хоть и тестировщик, но мне тоже интересна не только функциональная часть вопроса, но и бизнес-концепция. И тут важно именно, что у человека есть интерес. И ещё момент - у него должно быть время на дополнительные активности.

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

не только компании хотят, чтобы один человек закрывал 2-4 роли.

Я хочу придумывать полное решение бизнес-план и программировать его основу, а части попроще передавать мидлам и/или Джуниора.

да и по времени выгоднее, когда один человек придумывает решение и руководит его воплощением в жизнь

  1. «Закрывать 2–4 роли» — не равно «руководить».

  2. Точно ли один человек «по времени выгоднее», чем несколько спецов, выполняющих работу параллельно (пока один общается с заказчиком, другой фиксит баги, третий тестирует)? А фактор автобуса? Или бизнес не против потерпеть резкое увеличение риска полной остановки проекта на неопределенное время ради «сэкономить на болтологии»?

Точно ли один человек «по времени выгоднее», чем несколько спецов, выполняющих работу параллельно

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

Поэтому да, 20 лет назад программист включал в себя аналитика, тестировщика и архитектора. Отлично работало - рабочая группа из нескольких таких многостаночников, умеющих распределять внутри себя обязанности, очень эффективна.

Или бизнес не против потерпеть резкое увеличение риска полной остановки проекта на неопределенное время ради «сэкономить на болтологии»?

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

Другое дело что компании хотят одним человеком закрыть 2-4 роли, но это скорее проблема компаний)

классика

А представьте: опытный хирург, проработавший 20 лет, вдруг узнаёт, что "просто делать операции" больше не достаточно! Теперь от него требуют не только филигранно удалять аппендициты, но и участвовать в маркетинговых кампаниях больницы, лично обзванивать пациентов после выписки и оптимизировать логистику поставок бинтов. Ведь "ценность хирурга" измеряется не количеством спасённых жизней, а скоростью прохождения пациентов и уровнем их удовлетворенности.

Оказывается, знание анатомии и владение скальпелем - это прошлый век. Сейчас главное - умение "влиять на продукт" (читай, на поток пациентов) и "взаимодействовать с командой" (медсёстрами и уборщицами). А если хирург принципиально отказывается от новых требований, его с лёгкостью заменит молодой, гибкий терапевт, который готов "дорасти до нужного уровня". Грустно, да? Но таков рынок, и никто не будет ждать, пока вы, заслуженный профессионал, перестроитесь.

"влиять на продукт" (читай, на поток пациентов) 

именно поэтому в каждой второй (первой?) частной клинике, по какому вопросу вы бы не обратились бы к врачу, он вас направит на все возможные анализы. Во-первых, это несколько поможет врачу, а во-вторых, это лично ему поможет выполнить ΚΠΙ по среднему чеку.

его с лёгкостью заменит молодой, гибкий терапевт, который готов "дорасти до нужного уровня"

Вы сами то у кого из этих двоих предпочтёте операцию делать? Так то понятно что ваша внезапная смерть под ножом гибкого терапевта может даже и не повлияет на общий коэффициент удовлетворённости по больнице, учитывая возросшую скорость прохождения пациентов.

P.S. Статью не стал читать, сразу пошёл посраться в комменты.

Вы не поверите, но вообще-то именно так и происходит.

А вы какого хирурга предпочтете чтобы вам операцию на сердце/мозге делал?

Тот который занимается подготовкой плана операции, использованием новых методик, участвует в международных конференциях с докладами или тот который делал несложные операции по учебнику, особо не вникая почему именно так нужно делать (в учебниках написано ведь).

Мне кажется, здесь такая аналогия более уместна.

Несложные операции по учебнику вы приравниваете к уровню Senior?

В других ветках писали что Senior "только кодит". Без участия в принятии решений это уровень несложных операций по учебнику. Просто джуну нужно ещё найти в учебнике правильную главу и не перепутать с другими, а сеньор помнит где искать.

"Только кодит" это всё же не про сеньёра. Это мидл со стажем сеньёра. Без такого определения не вышел бы заголовок - уставшие мидлы...

Без участия в принятии решений это уровень несложных операций по учебнику

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

вы какого хирурга предпочтете чтобы вам операцию на сердце/мозге делал?

По моему опыту общения с современной медициной никто там ни за что не отвечает. Кроме аварийных случаев, разве что. Вот к реаниматологии претензий нет. Остальное сгнило.

Всё, что относится к беременности, рождению и детской терапии просто п-ц

Типичная менеджерская статья. Я подобное лет 20 назад читал, с тех пор моя ЗП выросла раз в 10. С учетом инфляции.

Джунам не платят, факт

Опыт, который раньше был козырем, иногда становится якорем. Причём это не специфика IT — исследования из Harvard Business School показывают ту же картину.

Дайте, пожалуйста, цитату из этого "исследования" подтверждающие ваши слова, ну чтоб не выглядеть балаболом. :) Статья на тему того, что ИИ заменяет джуниоров, первым параграфом написано, что если ты сеньор, то в относительной безопастности. Поиск по словам experience и senior ничего не дал подтверждающего ваши слова.

Две другие статьи, на которые вы ссылаетесь, закрыты пейволом (одна вообще на медиуме, который теперь уже в приличном обществе лучше не упоминать), так что увы, проверить о чем там речь, не могу.

Из того кусочка, что доступен от статьи на медиуме, там какой-то чувачок хвалится, что сеньер у него не прошел системный дизайн, хотя все было верно и все скейлится, но стек был выбран не тот, что в компании, поэтому давай досвидания, а трехлетний мидл стек угадал и прошел. Ну да, хороший пример подражания, отлично показывает, что на помойку-медиум лучше не ходить. Ну посыл, в статье, похоже, совсем не тот, что вы увидели. До 2024 года в Кремниевой долине рынок было совсем не тот, что в России: если ты сеньер с кучей опыта в одном стеке и идешь собеседоваться на другой стек - тебя брали, ибо переучиться на новый стек, ну займет время, но раз тебе интересно - давай вперед. После 2024, когда пошли увольнения волнами и этих сеньеров за забором готовых собеседоваться стало много, компании стали брать тех, у кого есть опыт под конкретный стек. И статья на медуме наверняка об этом, и нихера не подходит под Российские реалии, где всегда брали под конкретный стек и если ты сеньер в другом, значит не подходишь.

Это самое грустное, что я вижу последние годы...

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

нейрослоп

подумал, что опечатка, но такое слово действительно уже есть %)

Всегда думал, что сеньор должен, и в архитектуру, и в дба, и в девопс. Без этого спроектировать и запустить продукт просто не возможно. Скорее мидл это просто про написание кода.

Статья, на мой взгляд, описывает очевидные вещи.

Знать - да. Чтобы учитывать это в работе и взаимодействовать с соседними командами. А фигачить в это - нет

долгое время IT росло в тепличных условиях

Давайте конкретно, статья про разработку, а не "вообще всё IT". Так вот, разработчики НИКОГДА не "росли в тепличных условиях". Так может думать только человек, ни года не проработавший в коммерческой разработке. С точки зрения увлечённого, может немного даже фанатичного разработчика, разработка - это потрясающе интересно, хоть и требует огромных жертв.

НО!

С т.з. "нормального" человека (с разнообразными увлечениями, семьей, личной жизнью и т.п.), который реально пытался в разработку - это САМЫЙ НАСТОЯЩИЙ АД! "Тепличные условия" - наивняк от непросвещённых в теме...

выросло поколение разработчиков, которые привыкли, что их ценность — это код.

[...] либо застываешь в позиции «я просто пишу код»

Выросло поколение манагеров-не разработчиков (и не одно), которые думают, что сложность коммерческкой разработки - в коде... ТОТАЛЬНОЕ непонимание сути разработки...

С 2020-го пошло по-другому. Бизнес стал лучше понимать, за что он платит.

Я вас умоляю... Бизнес ВСЕГДА понимал, за ЧТО он платит. Даже так: бизнес - это ПЕРВЫЙ институт, который СЧИТАЕТ: СКОЛЬКО и за ЧТО он платит, и какие у этого риски и какие должны быть планы на будущее а-ля A, B, C...

Но цифры говорят обратное.

Вот здесь автор начинает оправдывать ожидания. Путает цифры и числа... Теперь всё сходится...

проще и дешевле развить нормального мидла, чем переучивать senior'а

А кто его будет "развивать", манагеры которые путают цифры и числа? Или он должен сам как-нибудь "саморазвиться? =DDDD

Это самое грустное, что я вижу последние годы...

Какая печаль и эмпатия! *смахиваю скупую мужскую слезу

Далеко не всегда бизнес понимает, за что он платит. В синей банке, например, горе менеджеры придумали характеристику утилизация процессорного времени серверов. И если утилизация опускается ниже, ну например 80%(цифра условная), команде вставляются пистоны. Ну разработчики тоже не дураки - они вставляют в код запуски случайных задач с пустыми циклами, чтобы процессор работал и создавал утилизацию. Понимает бизнес за, что он платит?

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

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

А теперь представьте, если какой-нибудь небольшой стартап вместо тестирования гипотез и поиска эффективых решений начнёт заниматься "кручением пустых циклов для достижения 80% утилизации CPU"... - что с этим стартапом вскоре станет...

Слушайте ну вы не только душните, но душните некомпетентно.

цифры говорят обратное - устойчивое выражение
цифры говорят обратное - устойчивое выражение


По формально правильному запросу - релевантных результатов меньше
По формально правильному запросу - релевантных результатов меньше

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

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

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

Так и линейные менеджеры и продакты не всегда получает долю в бизнесе.

Ах нет, бизнес будет прикрываться громкими словами, о том, что он несёт риски

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

Дык и уборщица тоже без бонусов. Когда линейные манагеры, продукты, Heads of Anything смогут так же равнозначно не только переливать из пустого в порожнее на синках, а очень увлечённо помогать бизнесу тем, что они еще и КОДЯТ, тогда и поговорим. Согласитесь ведь, чем больше народу кодит, тем бизнесу выгоднее. Вот нечем манагеру занятся, все таски раздал, все запланировал - иди кодируй и на уровне сеньера!!! А пока это просто очередные влажные фантазии и тупо зависть людям с реальными способностями и мозгами в IT, без которых ни один менеджер не стоит ни копейки.

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

Государство поможет, ведь too-big-to-fail. Рядовой Вася рискует много сильнее - его лишат источников доходов, а подушки, скорее всего, нет.

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

Скорее всего, у него просто времени нет вникать куда-то там, т.к. все ресурсы заняты корпоративными играми. Ну и, видимо, остаётся относительно незатронутым линейный персонал, на который и сваливаются все обязанности. Включая поиск новых сотрудников. :-)

Компании всё реже смотрят на список технологий в резюме

Бред. Даже первичный фильтр не пройдешь если нет нужных слов с нужным кол-вом лет.

Поэтому все пишут эти слова и годы просто чтобы пройти фильтры. Так что эти слова теперь никакого смысла вообще ни имеют, как и годы опыта.

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

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

И да, бизнес стал другим. Он перестал быть нацеленным на результат. Теперь всем рулит его величество процесс, в котором проблемы, легко предсказываемые технической эспертизой, становятся "инцидентами" с четким регламентом их решения. Пусть и неправильного, плодящего эти "инциденты" как снежный ком. Зато все при деле - менеджеры рисуют диаграммы Ганта, мастера с видом индийских йогов проводят митинги, кодеры пишут код с помощью искусственного интеллекта. Зачем в этой системе сеньоры и техническая экспертиза? Потому никакой я не сеньор. Я просто пишу код. Я ведь даже не мидл, а по сути джун. Ровно потому что мой код лучше, чем тот, который пишет ИИ, но появляется он медленнее. И лишает работы всех, кто вокруг - от мастеров и DevOps'ов (что бы это не значило), до менеджеров, которым неоткуда становится брать новый "инциденты" и показывать свою значимость. И да, я и не делаю из этого секрета - поэтому я мало того, что хуже джунов, так я еще и величайший токсик в компании.

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

Такое чувство, что статья намеренно ради хайпа написана.

Вот интересно, когда это бизнес не понимал, за что он платит?
Единственный вопрос который мне задавали: ты докажи, что то, что ты делаешь нужно бизнесу.
Под разными соусами: эффективность управления, эффективность решения, эффективность потраченного времени на внедрение - реализацию фичи.
Сколько ты уже это пилишь? 2 дня? Долго возишься.
Автор получал зарплату. Но никогда не работал на результат?

Когда это программисты работали в тепличных условиях? В тепличных условиях, чем кто? Рабочие, которые асфальт кладут? Или у автора не было такого, что нужно сидеть до 10-12 вечера, потому что фича должна быть готова к завтрашнему утру.
Или автора не поднимали в 2 часа ночи со словами: у нас тут сломалось. Ситуация критическая?
Или при очередной выкладке какой-нибудь фичи, прод ни разу не заваливался?
Я не понимаю, о каких тепличных условиях речь.

Если бы я хоть сейчас, хоть 20 лет назад сказал бизнесу - я только код пишу, разговор был бы таким: у нас место мидла, сейнера, техлида освободилось, у тебя нет знакомых?
Или таким: мы с тобой друзья. Давай. Мы тебе жизнь не портим, ты нам. Пиши по собственному.

Сеньер, это не застывший монолит, который гордится тем, что он в профессии 100 лет и только пишет код. Это прежде всего специалист, способный задачу довести до конца. И видеть наперед последствия своих решений. Как было сказано выше - ни мидл, ни джуниор этого делать не могут.

Вот интересно, когда это бизнес не понимал, за что он платит?
Единственный вопрос который мне задавали: ты докажи, что то, что ты делаешь нужно бизнесу.

Это же взаимоисключающие параграфы. Если бизнес понимает - зачем задает такие дурацкие вопросы совершенно не по адресу? Сеньор может выбрать лопату, организовать процесс копки, и рассказать, чем чревато рыть рядом с табличкой "Газ". Но надо ли вообще копать, решает в конечном счете не он.

чем чревато рыть рядом с табличкой "Газ". Но надо ли вообще копать, решает в конечном счете не он.

а на каком уровне техническая экспертиза (синьора) интерпретируется в профиты/убытки (владельца бизнеса)?

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

понятно, что в крупных компаниях между синьором и собственником может быть больше посредников (типа менеджер проекта, CTO и т.п.)

а на каком уровне техническая экспертиза (синьора) интерпретируется в профиты/убытки (владельца бизнеса)?

Ну уж точно не на уровне исполнителя, коим по большому счету сеньор и является. Да, он может что-то полезное посоветовать, но генерация прибыли - это не его задача (если бы он умел, он бы как минимум не за зарплату работал, или вообще не в найме).

Но, конечно же, бизнес хочет, чтобы генерацией прибыли занимались все, и задает такие вот вопросы. Разработчик это прекрасно понимает, но также понимает, что если он ответит честно (а честным ответом зачастую будет "да нафиг это не нужно"), то недолго тут проработает, и сочиняет устраивающее всех обоснование. Все довольны и счастливы, пока у компании есть на этот круговорот деньги. Типичные корпоративные игрища, я сейчас ровно такое в полный рост и наблюдаю и скучаю по временам, когда работал в компаниях помельче.

Я писал код, пишу код и буду писать код. Как меня будут при этом называть и кем считать -- сеньор, миддл или джун -- мне плевать.

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

Появилось внимание к процессам

И каке же внимание появилось к процессам:

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

Тоесть появились впроцессы, в которых один человек работает оркестром: начиная от бихзнес анализа и заканчивая поддержкой.

Специализация - это отсталый вчерашний день. Прекрасно, я считаю!

PS

А все начиналось с мифических "фулстеков".

Потом такие ребята задают вопросы на собесе 'какая выполненная вами задача принесла наибольшую прибыль компании'...

Тоже часто сталкиваюсь с тем, что клиенты не хотят брать синьоров. Но проблемы не в том, что они ленивые или закостенелые. У нас из студентов зачастую до синьоров дорастают за три года, поэтому в большинстве случаев синьоры это вовсе не выгоревшие старики. Большая часть отказов из-за денег. Ставка синьоров существенно выше, нам продавать их услуги по цене мидлов невыгодно, а клиент считает, что у него не настолько сложные задачи, чтобы больше платить за опыт. Вторая причина в том, что клиент опасается, что синьор быстро заскучает без сложных задач. Если разработчик нужен на два три месяца, то это не проблема, но если на больший срок, то правда может заскучать. Третья проблема, что синьоры во многих случаях уже имеют под собой какую-то минимальную команду, коучат кого-то и отвечают за работу мидла или джунов. А далеко не всегда клиент готов брать синьора с его подаванами. Если это джуны, то почти никогда не готов.
Что касается запроса на универсальность, то это во многом связано с тем, как вообще устроена работа с ИТ сотрудниками в самой организации, которая ищет внешний ресурс. Если у них все аналитки-разработчики-девопсы в одном лице, и с бизнесом на одном языке говорят, и код пишут, и оптимизируют производительность, и CI/CD настраивают, то им кажется, что и внешний специалист должен быть таким же. Тут ничего личного, просто иначе он плохо впишется в их модель управления. При том, что у нас все люди специализируются либо на аналитике либо на разработке, приходится подбирать для таких клиентов более-менее универсальных людей. Но на практике, если копнуть глубже, все равно специализация есть. Даже там где пестуют как бы универсалов. Все они называются словом дата-инженер, например, но реально кто-то больше с бизнесом разбирается, а кто-то больше в код закапывается. Просто это уже складывается по факту неформально.

Sign up to leave a comment.

Articles