Привет, меня зовут Паша! Я работаю в Mad Devs, и считаю, что просто программировать уже мало для того, чтобы быть хорошим специалистом.
Надеюсь, этим материалом не задену чьи-то чувства. Этот материал — попытка раскрыть систему навыков современного программиста под другим углом. Не больше.
Программист — это важнейшее звено в цепочке создания программного обеспечения. Без него новое ПО не может создаваться. Что же такого важного делает программист? Какая ответственность лежит на нём, раз он такой незаменимый.
Хочу сразу обратить ваше внимание на то, что ответственность программиста зависит от исторического таймлайна. Вернёмся примерно на 20 лет назад.
Этот мем мало что имеет общего с образом современного разработчика. Тем не менее давайте обсудим, за что ответственен этот фантастический специалист. Скорее всего, он занимается разработкой системы, которая нестабильна в работе. Пользователи этого программного обеспечения — это, так называемые в то время, продвинутые пользователи персонального компьютера. В то время только продвинутые пользователи могли пользоваться программным обеспечением дальше текстового редактора.
Что входит в обязанности такого специалиста? Он должен просто писать код на одном языке программирования. Этот специалист гордо именует себя C++-программист (подставь другой язык программирования, популярный в то время). Его руководство, как правило, совершенно не понимает, чем он занимается. В этой связи он имеет возможность создавать тот образ своей деятельности, который сам пожелает. Этот образ может быть негативным, программистам тогда не много платили, было из-за чего злиться. Может быть и положительным, он может решать задачи от своего руководства и творить полезную магию. Некоторые мои коллеги до сих пор считают, что сохранять образ негативного специалиста — это норма. В их компаниях менеджеры всё ещё не понимают, чем они занимаются, а эти специалисты абсолютно негативно относятся ко всему их окружающему миру. Но таких не много — это радует. Да и вообще, мне кажется, что ИТ-компаниями являются те компании, где менеджеры понимают, что происходит в современной отрасли. Это достаточный критерий, чтобы быть ИТ-компанией, как по мне.
В этой связи вопрос: что входит в обязанности современного программиста? На этот вопрос можно отвечать очень долго, но я попробую его раскрыть более быстро, и сразу откинуть те вещи, которые являются важными, но могут растянуть этот материал до бесконечности. А начнём мы его раскрывать с компетенций, которыми может обладать современный программист.
Компетенции современных специалистов в любой отрасли делятся на три большие категории:
- Хард-скиллы;
- Софт-скиллы;
- Диджитал-скиллы.
Логика подсказывает, что в каждом специалисте должны быть одинаково развиты все типы навыков. Они взаимно дополняют друг друга.
Раскрывать эти термины я не буду, потому что в русском языке у них даже постоянного названия нет. Много специалистов из образования именуют эти навыки по-разному, тем самым, путая аудиторию иногда. Представлю вашему вниманию таблицу соответствия этих названий.
| Primary key | Название, которое буду использовать я | Другие синонимы | На рунглише | Убить за такое |
|---|---|---|---|---|
| Хард-скиллы | Профессиональные навыки | Глубокие навыки, жёсткие навыки | Хард-скиллс, Хард-скиллз | Хард-скиллзы |
| Софт-скиллы | Надпрофессиональные навыки | Мягкие навыки, общие навыки | Софт-скиллс, софт-скиллз | Софт-скиллзы |
| Диджитал-скиллы | Цифровые навыки | Диджитал-скиллс, диджитал-скиллз | Диджитал-скиллзы |
Если уж с названиями проблемы, с определением и подавно. Дам лишь те понятия, которые нужны для сегодняшнего обсуждения.
Если быть кратким. Профессиональный навык каждому специалисту нужен ровно один: программисту — программировать, строителю — строить, хирургу — хирургировать (неуместная шутка) и так далее. В этот навык входит то самое бесконечное количество знаний, которым обладает специалист. В случае с программистом — это и понимания той самой великой базы, которые все должны знать, понимание принципов работы его языка программирования и так далее.
Цифровые навыки — это для большинства профессий отдельная история. Потому что ИТ сегодня проникает во все отрасли. Сложно найти отрасль, которая сегодня не поддаётся цифровизации: в другое время я бы сказал, что это религия, но нет! Поэтому для специалистов большинства профессий владение цифровыми навыками — это отдельная статья, с которой нужно работать. Для программистов цифровые навыки и профессиональные навыки по понятным причинам сильно пересекаются. Хотя я каждому программисту, я считаю, следует быть продвинутым пользователем ПО. Имею ввиду, использовать разные сервисы для организации своей жизни, пробовать делать умный дом, использовать современные приложения для жизнедеятельности и так далее. Это развивает цифровые навыки больше. Ведь, чтобы быть хорошим поставщиком, неплохо быть и хорошим потребителем.
Надпрофессиональные навыки — эта вещь, на которой мы остановимся поподробнее. По сравнению с профессиональные навыками, надпрофессиональных навыков нужно каждому специалисту несколько, а лучше много. Примеры надпрофессиональных навыков: тайм-менеджмент, поиск ресурсов, использование ресурсов, умение договариваться, коммуникабельность, управление людьми, публичные выступления и т.д.
Зачем мне эти навыки? Я на Reactе пишу! — прозвучит из зала.
Здесь и начинается та самая разница ответственности между программистами 20 лет назад и программистами сегодня. Сегодня мы с вами поставщики будущего, без нас невозможна разработка программного обеспечения. Наши коллеги из компаний (менеджеры, продакт-оунеры, сейлзы, стейкхолдеры, маркетологи и другие) нуждаются в нашей помощи. Наши компетенции (а именно профессиональные навыки) и то, как мы умеем их применять, играют порой решающую роль в развитии того или иного продукта. Почему именно так? Я описал в статье о настоящих фулстеках на Хабре. Там описано, в каком месте нужно применять свои профессиональные навыки больше, чем большинство из нас привыкло. По сути навыки, про которые я сейчас пишу, как раз и складывают очень крутое качество, которое хорошо развито у нас в Mad Devs, — customer affiinity (близость к заказчику).
Как я писал выше, все типы навыков должны быть одинаково развиты в каждом специалисте. И чтобы качественно применять свои профессиональные навыки в ситуациях, которые я описал в статье по ссылке выше, нужно обладать и хорошо развитыми надпрофессиональными навыками.
Каким конкретно? Я перечислю топ 6 важных надпрофессиональных навыков, которыми, как мне видится, должен обладать любой современный специалист:
- Тайм-менеджмент. Тут я думаю, очевидно. Навык тайм-менеджмента лишь косвенно относится к оценке задач. Оценка задач — это профессиональный навык. Тайм-менеджмент для программиста — это логичное распределение времени на кодинг, чтение статей, самообразование и митинги.
- Умение работать в команде. Проекты в одиночку почти никто не делает. Умение работать в команде абсолютно незаменимый навык.
- Умение обучать. А если быть точным, умение вводить в контекст, навык, сравнимый с умением обучать. Задача человека, который обучает — это по сути введение в контекст. Только набор знаний более обширный. Программисты очень часто меняют контексты из-за смены проектов и команд. И умение ввести в контекст коллегу, указав на самые важные и опустив ненужные детали, — это очень важный навык, учитывая, насколько операция ввода в контекст сегодня дорогая. Кстати, этот навык так же применяется и в наставничестве.
- Деловой этикет. Начиная от соблюдения правил русского языка и заканчивая элементарными правилами общения с заказчиками. Некоторые специалисты при деловом общении забывают, что находятся не в слак чатике гоферов или Yii-фреймворка (подставь свою технологию). В некоторых компаниях деловой этикет важен в переписках по почте внутри компании. У нас в Mad Devs деловой этикет важен только в контексте, когда это важно для продукта, который мы делаем. Если членам команды легче воспринимать именно такой тип общения, будет принят такой этикет общения. Но по крайней мере все заказчики, с которыми я работал, — это люди, сосредоточенные прежде всего на результате, и предпочитают общаться без серьёзных щей. Тут каждому своё. Но! Умение включить деловой этикет тогда, когда этого требует ситуация — важно!
- Целеполагание. Двух видов. Личное и проектное. Скажи мне, программист, кем ты будешь через 5 лет? Типичный вопрос на собеседовании, но ответ на него помогает разобраться, как человек относится к долгосрочному планированию. Моё личное мнение (это значит, что я никому не навязываю, а значит, нет смысла спорить): несмотря на энтропию современного мира долгосрочное планирование НУЖНО-НУЖНО-НУЖНО! Никто не просит от вас держаться плана вне зависимости от происходящего. Планы нужно менять, и это по-взрослому. Но держать постоянно в голове цель и набор задач на ближайшие годы (желательно в районе 10 лет) — это ориентир, в соответствие с которым принимаются решения. Конкретно, мне легче работать с людьми с долгосрочным планированием. Можно в них вкладываться и развиваться с ними, не боясь, что они завтра ливнут куда-нибудь. Целеполагание в проекте тоже важный момент. Как программист, даже если отбросить весь этот типа бред про надпрофессиональные навыки и прочее, ты отвечаешь за одну из частей проекта. И нужно планировать развитие этой части проекта в долгосрочной перспективе. Какие абстракции появятся, какие модули уйдут отдельно жить своей жизнью и так далее.
- Коммуникабельность. Речь об умении общаться с коллегами из других профессий. Быть отзывчивым, помогать коллегам разбираться в своих вопросах, которые связаны с нашими профессиональными навыками. Быть палочкой-выручалочкой для них, когда они в тупике и так далее. Коммуникабельность так же помогает налаживать контакт с заказчиком, а это всегда полезно для любого проекта.
Эти надпрофессиональные навыки по моему мнению помогут раскрыться полноценно вашим профессиональным навыкам.
Главный посыл, что программист сегодня — это не набиратель кода. Это важная боевая единица: юнит, который может решить исход сражения, если правильно будет пользоваться всеми своими заклинаниями.
А для этого нужно не только быть хорошим разрабом и кодить уметь, а ещё и обладать набором навыков, на первый взгляд отдалённо помогающих в выполнении своих обязанностей, но это не так.
Отвечаем на вопрос: какую ответственность несёт современный программист. В первом приближении — это код писать. А по сути, хороший современный программист в большинстве случаев обладает настолько размытым набором ответственности, насколько размыты понятия о надпрофессиональных навыках сегодня. Это вдобавок ко всему зависит от компании, команды, проекта и руководителя команды.
Безусловно, каждый разработчик сам решает, кем ему быть. И какие навыки развивать, что важно и так далее. Можно остаться и дальше набирателем кода, и ближайшие годы вы себя будете чувствовать супер хорошо.
Правда, есть специалисты, которые расскажут, что узкие специалисты в ИТ скоро начнут вымирать. Полное вымирание им не грозит, но в том виде, в котором сейчас, профессии не останутся точно.
Есть такой интересный проект: Атлас новых профессий. Ознакомьтесь с ним и посмотрите, что новые профессии — это, как правило, профессии вида ИТ + другая отрасль.
Профессии разработчик сборщиков JS-кода там что-то нет.
Надеюсь, этим материалом не задел чьих-то чувств. Этот материал — попытка раскрыть систему навыков современного программиста под другим углом. Не больше.
Комментарии (49)
EvgeniiR
21.05.2019 07:35В статье явно прослеживается желание автора найти "на все руки" мастера который
который и бэк сделает, и фронт, и вёрстку, и инфраструктуру настроит, с заказчиком сам общаться будет, новичков учить, а платить ему как за одного. Не работает это так на сколь-либо серьёзном проекте.
kalashnikovisme Автор
21.05.2019 12:30Хочу обратить ваше внимание, что в материале никого не ищу. Один раз лишь указал, что мне лично уютнее работать именно с такими специалистами.
EvgeniiR
21.05.2019 13:04Я абсолютно согласен с тем что софт скиллы, должны быть, и познания в смежных областях, желательно, тоже. Но, что хороший программист должен на таком же хорошем уровне являться менеджером, на сколько является программистом, или что «бэкенд» — разработчик это слишком узкий специалист — ну нет уж, это все же разные должности.
Впрочем, про менеджмент, программист может совмещать и навыки менеджера, но думаю что это уже как минимум тим-лид или какая-нибудь подобная должность :)kalashnikovisme Автор
21.05.2019 13:40Речь в тексте не идёт о том, что программист должен быть менеджером.
Прошу вас подсказать, какой именно Пойнт сообщает об этом.EvgeniiR
21.05.2019 14:07Вообще, я про эту часть:
Как я писал выше, все типы навыков должны быть одинаково развиты в каждом специалисте.
kalashnikovisme Автор
21.05.2019 14:10В этой части слов "менеджер" или "менеджмент" нет.
В навыках тоже не упоминал, что требуется быть менеджером.
kalashnikovisme Автор
21.05.2019 14:11И это не предполагалось. Это как раз и есть тот самый главный Пойнт, который "под другим углом". Что софт-скиллы — это не только лишь менеджерские навыки.
Whuthering
21.05.2019 09:21+2Ведь, чтобы быть хорошим поставщиком, неплохо быть и хорошим потребителем.
"А я программист. И я знаю как это все устроено и работает. Поэтому в моем доме не будет никаких умных лампочек, замков, чайников, туалетов и прочей дофига умной техники"
Alexeyslav
21.05.2019 10:58Это вы знаете как работает чужое. Кто мешает сделать это же самое но лучше и менее уязвимое? Только извечная спешка и гонка за прибылью и/или экономией…
VolodjaT
21.05.2019 11:21+1потому что это уже разработка, а не потребление.
И цена лампочки заново разработаной в единственном экземпляре будет космической
Whuthering
21.05.2019 11:52Кто мешает сделать это же самое но лучше и менее уязвимое?
Отсутствие на это ресурсов и времени, например. Если я сам лично займусь всем вышеперечисленным, то на это жизни не хватит. Да и вообще у меня немного другая сфера интересов.kalashnikovisme Автор
21.05.2019 12:32Думаю, здесь стоит указать то, что всё это лишь советы, и каждому самому виднее, что использовать и чем заниматься.
И если исходить из логики, что всё уязвимо, то и SaaS пользоваться не стоит в том числе, например.
ggo
21.05.2019 09:41+1Сейчас суровые айтишники набегут и запинают кирзачами ;)
Непопулярно это (текущая тема) в среде суровых перцевkalashnikovisme Автор
21.05.2019 12:35Я знал, на что иду :)
В любом случае, считаю аудиторию Хабра адекватной.
В любом случае, этот материал — попытка посмотреть на компетенции современных специалистов с другой стороны.
Я даже извинился пару раз, если задел чувства чьи-то :)
ksbes
21.05.2019 10:43Знаете, мне пофигу какие "комникационные навыки" у хирурга, который меня режет. Пусть хоть кроет матом всю мою родню до седьмого колена — главное, чтобы сделал хотя бы хорошо (и салфетки внутри не забыл). В тоже время от "девочек" ("тётенек") на ресепшене я такого не потерплю. Всё-таки и медицина и программирование — области достаточно широкие и нужно разделение труда и обязанностей. Да и люди имеют разные склонности.
Что касается навыков программирования, то мой опыт подсказывает, что существуют три типа навыков ("склонностей"), которые не очень часто пересекаются:
1) Программист — очень хорошо может запрограммировать заданный извне алгоритм. И здесь речь идёт не о тупом кодинге, а именно о "творческом переводе" человеческого языка в язык программирования, с учётом всех особенностей и ограничений (ну там, чтоб память не текла, чтоб гонок не было и т.д.)
2) ИТ-инженер — очень хорошо умеет проектировать и планировать где и какой алгоритм применить. Может вообще код не писать, но обычно пишет довольно бажные но очень идеологически красивые прототипы (которые очень часто манагеры любят продавать вместо готового софта).
3) ИТ-исследователь — очень хорошо умеет придумывать новые или оптимизировать старые алгоритмы (которые потом ИТ-инженер куда-нибудь вставит, если сможет). Пишет быстрый и/или экономичный код, но долго (не всякий манагер дотерпит до середины) и часто черезмерно специализированный (смена минорной версии внешней библиотеки — катастрофа)
Все 3 покрывают весь спектр собственно разработки, остальное — это внешняя организационная "обвязка", которая должна быть у любого, кто работает в иерархическом коллективе. Никто вам не расскажет про тайм-менеджмент лучше солдата (особенно солдата в увольнении :) ).
Соответственно требовать от себя или другого человека чтобы он был всеми тремя одновременно — это довольно неразумно.
Alexeyslav
21.05.2019 11:03Тут очень просто… когда хирург вас УЖЕ режет — вам конечно пофиг, лишь бы профессионал был. А когда до операции есть выбор между двумя специалистами примерно одного уровня, неужели вы предпочтёте того кто матом вас посылает? Проверить реальный уровень вы не можете, пока лично не прооперируетесь у обоих раз по 10… поэтому доверяем «бумажкам» а у них примерно одинаковый набор бумажек, но один посылает всех к чертям, а другой вежливо делает свою работу. В чью пользу выбор будет?
ksbes
21.05.2019 11:16Хирурга я выбирал и буду выбирать не по бумажкам (меня не бумажки резать будут), а по личным рекомендациям и известным мне результатам (как положительным, так и отрицательным). И тут мат — не мат, просто не обращаешь внимание и всё, так же как не считаешь количество ушей и не смотришь на количество волос на голове.
Тем более, что матом можно объяснить все быстро, просто и доходчиво, а вежливо — гнать всякую пургу (а можно и наоборот). Просто нет корреляции и всё.
Alexeyslav
21.05.2019 11:35+1Матом ничего объяснить не получится, слишком мала у него информационная ёмкость. Только команды отдавать, причем в заранее известном контексте. Там где есть хоть минимальная конкуренция, там не будет исполнителей разговаривающих матами.
И хирурги с плохими результатами тоже долго не работают… У всех работающих результаты плюс-минус одинаковые.
Hardcoin
21.05.2019 12:30Тут ещё проще. Если у них примерно одинаковые рекомендации и примерно одинаковая стоимость, то почему? По какой причине люди не начинают массово выбирать того, что вежливый и почему он не переходит в более дорогую больницу? Причины могут быть разные, но одна из возможных причин — его уровень для более дорогой больницы недостаточный. А тот, что кроет матом — почему его не выгоняют? Возможно он достаточно хорош, что б компенсировать недостаток "софт-скилов". Так и в чью пользу выбор будет?
Alexeyslav
21.05.2019 13:16Почему не выгоняют? Может потому что с зав.отделением пьют вместе? Родственники и прочее прочее… Или периферия, где эти два хирурга единственные на ближайшие 100км и его просто терпят.
Hardcoin
21.05.2019 15:34Может быть и так. Но это тоже намек на разный уровень хирургов. В любом случае мат — так себе показатель, остальные факторы важнее.
Whuthering
21.05.2019 11:55Знаете, мне пофигу какие «комникационные навыки» у хирурга, который меня режет. Пусть хоть кроет матом всю мою родню до седьмого колена — главное, чтобы сделал хотя бы хорошо
Это пока Хирург один. А если сложную операцию делает бригада хирургов, то наличие в ней нервно орущего на коллег матом, влезающего в чужую область, не способного четко объяснить что ему от них надо, может весьма негативно повлиять на результат работы. А скорее всего в итоге его просто не возьмут в бригаду хирургов, если только он не рок-звезда медицины и мировое светило науки, но таких в мире мало.
MR12
21.05.2019 11:05+1ИМХО, тут надо плясать от задачи. Если вы разрабатываете технически сложную программу, то на первый план выходят именно hard skills. Если же это очередное CRUD-поделие с 5-ю активными пользователями в час, тогда верно — разработчику будет достаточно минимальных технических навыков, чтобы разобраться и участвовать, и вот тогда уже на первый план выходят другие качества — и бизнес и человеческие, м.б. даже умение веселить коллектив или метко бросать дартс.
EvgeniiR
21.05.2019 11:50Если вы разрабатываете технически сложную программу, то на первый план выходят именно hard skills. Если же это очередное CRUD-поделие с 5-ю активными пользователями в час, тогда верно — разработчику будет достаточно минимальных технических навыков, чтобы разобраться и участвовать, и вот тогда уже на первый план выходят другие качества — и бизнес и человеческие, м.б. даже умение веселить коллектив или метко бросать дартс.
Мне кажется в проектах с 5-ю активными разработчиками на первый план выходит стоимость разработчика, а не его умение играть в дартс :)
rjhdby
21.05.2019 14:50Скажи мне, программист, кем ты будешь через 5 лет?
Так и хочется ответить — "а я томат!"
Нифига этот вопрос не помогает понять способности планирования. Единственное о чем он говорит, да и то не вопрошающему, а кандидату — это то, что его собеседует какой-то "странный" тип.
testopatolog
21.05.2019 20:55Программисту, в ситуации, когда остальные специалисты команды в соответствующих проектных ролях недостаточно компетентны, от временно приятного ощущения самодостаточности и значимости до выгорания — один шаг из-за взваленного (им самим на себя или типа делегированного ему) тяжелого бремени несвойственных задач и прочих, «севших на шею».
Но, если я правильно понял, статья не об этом. Благодарен Автору за его точку зрения, предлагаю свою, где спрашиваю относительно навыков, которые Автором отдельно выделены, как обязательные (по-моему типа сначала условия обеспечь, а потом требуй, если есть смысл):
1. Тайм-менеджмент. Должно ли в таком случае руководство/менеджмент доводить до Программиста свои меняющиеся требования, приоритеты, риски, коммерческие планы, цели… в контексте чего он мог бы осмысленно и корректно планировать свои рабочие задачи?
2. Умение работать в команде. Должно ли его руководство/менеджмент, специалисты отдела кадров, сначала грамотно подбирать рабочий персонал, затем оптимально формировать совместимые проектные команды? при выполнении этих условий и грамотного управления командой про это умение выдумывать ничего не надо, кроме способности вовремя признавать справедливую критику или терпеть объективные «неудобства».
3. Умение обучать. Должно ли руководство минимизировать риск изменения состава проектной команды, тем более ввода в неё таких специалистов, которые почти с ходу не подключатся к работе, помогая команде, а которых, наоборот, команда должна тащить/обучать,- долгое время исправляя их ошибки, бояться поручать серьёзную работу, вместо того, чтобы комфортно и быстро решать запланированные задачи? Должно ли руководство стимулировать наставников, организовывать обучение или выделять ресурсы для неопытных, но перспективных специалистов так, чтобы работа не страдала при их вливании?
Интересно, какое умение важнее для Программиста: обучать или самообучаться (не упомянутое Автором)?
4. Деловой этикет. Кому «вылизывать» толстых и капризных Заказчиков по принятому у кого-то там этикету? Зачем-то предлагается быть готовым к этому Программисту, а Заказчик, как правило, ждёт этого от его руководства. Может в менеджмент не надо ставить неспособных людей, которые осознают себя как «испорченный телефон», и напрямую замыкают Заказчика на Программиста?
5. Целеполагание. Какова будет реакция руководства, если одному Программисту для достижения благих целей захочется делегировать кому-то часть своих самых сложных задач, у второго цель — обучиться и добиться роста благосостояния в другой компании, а у третьего — сделать так, чтобы поскорее хоть что-то как-то заработало (и каждый целеустремлён)? Непонятно почему «Целеполагание», как элемент планирования, подаётся Автором отдельно от пп.1 «Тайм-менеджмент».
6. Коммуникабельность. Каким местом способность взаимовыгодного понимания, профессионально требующаяся специалистам, тратящим практически полностью на общение своё рабочее время, связана, как ключевая, с Программистом. Основываясь на правилах общения, непонятно, почему «Коммуникабельность» подаётся Автором отдельно от пп.4 «Деловой этикет» и, тем более, от пп.2 «Умение работать в команде»?
Все вопросы выше риторические, как и этот: а почему бы Программисту не пожелать умения типа уверенно вести свой собственный бизнес, писать/лицензировать/продавать свои (с единомышленниками) программы, развивать и себя и отрасль/технологии?
Короче, у меня предложение, оставить Программиста в покое, не требовать от него большего, чем, как от творца, наделённого искусством писать (и документировать, сопровождать...) требуемого качества программный код в подходящих для него условиях, и, с другой стороны, рассматривать его не как указывает Автор, цитирую: «важнейшее звено в цепочке создания программного обеспечения»,- цепь отдельное звено разве что ослабить может, а как элемент, который наравне с остальными, правильно выбранными, каждый со своими знаниями, задачами, зонами ответственности, усиливая друг друга, могут создать достойное ПО.
zim32
21.05.2019 22:54Бред. Я понимаю еще это можно отнести к тимлиду, архитектору или на крайняк техлиду. Но обычный программист ничего этого не должен кроме основного своего скила
Ketovdk
22.05.2019 01:06Компетенции современного программиста под другим углом
с учетом того, что это 153-ая статья на тему важности soft-skills и того, что обратного никто особо не декларирует, угол не такой уж и другой, а какой и обычно
DrPass
22.05.2019 01:41Главный посыл, что программист сегодня — это не набиратель кода. Это важная боевая единица: юнит, который может решить исход сражения, если правильно будет пользоваться всеми своими заклинаниями.
Я скажу крамольную вещь, но по моим наблюдениям как раз всё с точностью до наоборот. Среднестатистический программист четвертьвековой давности, это как раз вполне себе самодостаточная боевая единица. Он садился и решал проблему. Среднестатистический программист сейчас нуждается в куче инфраструктуры вокруг, имеет массу навороченных бизнес-процессов, массу архитектурных и интеграционных требований, которые якобы должны повышать его эффективность, но… как в том старом анекдоте про самолёт: «А теперь попробуем со всей этой хернёй взлететь». Проблемы решаются намного медленнее и хуже.kalashnikovisme Автор
22.05.2019 01:52Инфраструктура выросла вместе с отраслью.
Согласен, в некоторых местах разбухла чуть больше, чем нужно, но это не страшно.
Никто не говорит, что тот парень был плох. Он решал проблемы.
Как раз речь о том, что нужно решать проблемы (я ссылаюсь в материале на статью, где только про это и пишу). А для решения проблем в огромной и глубокой инфраструктуре сегодня, как раз и нужно обладать софт-скиллами, потому что раньше было легко. А сегодня нужно учиться сотрудничать со многими другими юнитами, разных бекграундов.DrPass
22.05.2019 02:04Да дело не только в инфраструктуре. Я бы сказал, в основном не в ней. Где-то произошел сбой метрик, например, когда результативность и оплату труда стали мерить в часах, строках кода и прочей ереси, а не в решенных проблемах.
Инфраструктура в глобальных масштабах, конечно, выросла. Но с точки зрения одного разработчика охват его части проблем не вырос. А может, даже уменьшился. Современный программист общается с инфраструктурой через толстые слои библиотек, и он в общем-то может позволить себе нихрена не понимать, как оно там за этими слоями работает. А зачастую и не понимает. А четверть века назад во многом приходилось самостоятельно разбираться. Хочешь письмецо отправить? Вот тебе порты, вот тебе протокол SMTP, садись, пиши реализацию. Хочешь многоуровневое приложение? Вот тебе брокер CORBA, вон тот шкаф с книгами — это мануал, а вон там на стене винтовка, сам застрелишься, как прочтешь половину.
И самое загадочное — те самые проблемы и фичи. Даже в таких садистских условиях продуктивность труда была почему-то выше.kalashnikovisme Автор
22.05.2019 02:16Хм. Я бы сказал, это хорошо, что уровни абстракции инкапсулировали от программиста реализацию многих низкоуровневых вещей.
Было бы логично, если в таких условиях программист мог задуматься о конечном пользователе больше, чем раньше.DrPass
22.05.2019 02:24Я не говорю, что это плохо. Это хорошо. Я говорю, что даже несмотря на это продуктивность работы программистов упала.
Было бы логично, если в таких условиях программист мог задуматься о конечном пользователе больше, чем раньше.
Программист о конечном пользователе не особо думает, ни тогда, ни сейчас. Для этого и появились UI-дизайнеры и бизнес-аналитики :)kalashnikovisme Автор
22.05.2019 02:52Считаю, что программисту тоже стоит думать о конечном пользователе. Как минимум на уровне мотивации к его деятельности. Типа, а зачем мы тогда всё это делаем.
А в небольших проектах, где нет UX / UI спецов и аналитиков, эта вещь становится более чем уместна.DrPass
22.05.2019 03:03Я опять же, не про то, как оно там должно быть, а про то, как есть. Это объективная реальность. Среднестатистическому программисту в общем не то, чтобы наплевать на пользователей, но он
а) не мыслит категориями «как это сделать, чтобы наиболее бестолковый пользователь разобрался». Для него логичен тот интерфейс, который он сам понимает.
б) если ещё и решает пользовательские проблемы, то бывает ими крайне раздражен.kalashnikovisme Автор
22.05.2019 03:16Согласен с вами.
Будучи человеком, который участвует в воспитании и мотивации сотен молодых специалистов в год, считаю, что нужно продвигать более идеальные профессиональные ценности.
Все специалисты сталкиваются с объективной реальностью, но, если периодически не поднимать планку мотивации, изменений к лучшему дожидаться придётся дольше.
Wundarshular
23.05.2019 08:08Исходя из вашего ТОП-6, могу предположить, что в вашей команде отсутствует т.н. менеджер, в обязанности которого входит общение с заказчиком и специалистами из других отделов, вводить в контекст и организация работы команды, либо, если он есть, работает он неэффективно, раз эти функции вы возложили на абстрактного программиста.
Статья выглядит неплохо, но создаётся впечатление, что в своём обобщении вы совершенно расстались с реальностью.kalashnikovisme Автор
23.05.2019 13:19Я всё ещё не понимаю, почему существует мнение, что софт-скиллами должен обладать именно и только менеджер.
О менеджерах в статье речи не идёт абсолютно совсем. Эти специалисты закрывают свой скоуп задач.
В моих командах у меня есть менеджеры, которые отлично справляются со своими обязанностями (было бы у меня время тогда строчить статьи).
К разговору о том, что расставаться с реальностью — я описываю свои принципы работы. Учитывая, что мне за них платят деньги и уважают в моей компании, значит, это реальность.Wundarshular
23.05.2019 13:51Потому что в его — менеджера — задачи входит использование данных навыков, и за умелое применение оных ему, в общем-то, и платят деньги. Если у вас небольшая команда, и вы в состоянии организоваться за конечное время, то вам он, разумеется, не нужен. В средних и крупных командах менеджер оправдывает своё существование. Я не сказал, что это только его задачи, но разве рационально разбазаривать время команды, когда это можно поручить отдельному человеку специально приспособленному под эти задачи?
Потому что от специалиста в первую очередь требуются его профессиональные навыки, т.н. «hard skills». То, что вы описываете как «soft skills», является приятным дополнением, но никак не влияет на ваши профессиональные навыки. В вашей статье эти навыки указаны как требуемые, т.е. без них специалист — не специалист, что, на мой взгляд, является некорректным посылом.
Под расставанием с реальностью я имею ввиду, что описываемый набор навыков, тем более топ-6, применим далеко не ко всем случаям и не всем командам. Ваш пример, несмотря на обобщение, остаётся частным случаем, поэтому, как рекомендация для широкой аудитории, оторван от реальности.
Если вам нужен пример: в одноранговой группе (команде без иерархии) разработчиков без выраженного разделения функционала перечисленные навыки имеют ощутимый вес, в то время как в какой-нибудь конторе перечисленные навыки не принесут особой пользы отдельно взятому участнику.
Скажите, вам точно платят за ваши принципы, а не за навыки?
VolodjaT
Если программист должен столько всего уметь, а зачем тогда эти все скрам мастера, бизнес аналитики, продукт овнеры, маркетологи и это все это?
Alexeyslav
А откуда тогда возьмутся такие программисты? Самому это всё постигать это x5 времени, которого сейчас и так не хватает. Освободившиеся часы времени лучше потратить с большей пользой для себя, а не работодателя.
kalashnikovisme Автор
Это часы времени будут потрачены именно на вас, потому что компетенции останутся с вами в итоге, а не с работодателем.
Alexeyslav
Это безусловно, но это будет неэффективное обучение и неполное. За то же время можно 1) больше отдохнуть, 2) получить больше и/или качественнее компетенции.
kalashnikovisme Автор
Маркетологи, продукт-овнеры и прочие обладают своими профессиональными навыками. Программист не должен обладать их навыками.
DrunkBear
Странно, нам всегда пушили менеджеров в проекты, чтоб они ограждали излишне нежных программистов от ужасных заказчиков с дурацкими идеями (или наоборот) и переводили задачи про 5 красных линий во вменяемое ТЗ, а тут оказывается это задача юнита-программиста.