Комментарии 51
В статье явно прослеживается желание автора найти "на все руки" мастера который
который и бэк сделает, и фронт, и вёрстку, и инфраструктуру настроит, с заказчиком сам общаться будет, новичков учить, а платить ему как за одного. Не работает это так на сколь-либо серьёзном проекте.
Впрочем, про менеджмент, программист может совмещать и навыки менеджера, но думаю что это уже как минимум тим-лид или какая-нибудь подобная должность :)
Речь в тексте не идёт о том, что программист должен быть менеджером.
Прошу вас подсказать, какой именно Пойнт сообщает об этом.
Непопулярно это (текущая тема) в среде суровых перцев
Знаете, мне пофигу какие "комникационные навыки" у хирурга, который меня режет. Пусть хоть кроет матом всю мою родню до седьмого колена — главное, чтобы сделал хотя бы хорошо (и салфетки внутри не забыл). В тоже время от "девочек" ("тётенек") на ресепшене я такого не потерплю. Всё-таки и медицина и программирование — области достаточно широкие и нужно разделение труда и обязанностей. Да и люди имеют разные склонности.
Что касается навыков программирования, то мой опыт подсказывает, что существуют три типа навыков ("склонностей"), которые не очень часто пересекаются:
1) Программист — очень хорошо может запрограммировать заданный извне алгоритм. И здесь речь идёт не о тупом кодинге, а именно о "творческом переводе" человеческого языка в язык программирования, с учётом всех особенностей и ограничений (ну там, чтоб память не текла, чтоб гонок не было и т.д.)
2) ИТ-инженер — очень хорошо умеет проектировать и планировать где и какой алгоритм применить. Может вообще код не писать, но обычно пишет довольно бажные но очень идеологически красивые прототипы (которые очень часто манагеры любят продавать вместо готового софта).
3) ИТ-исследователь — очень хорошо умеет придумывать новые или оптимизировать старые алгоритмы (которые потом ИТ-инженер куда-нибудь вставит, если сможет). Пишет быстрый и/или экономичный код, но долго (не всякий манагер дотерпит до середины) и часто черезмерно специализированный (смена минорной версии внешней библиотеки — катастрофа)
Все 3 покрывают весь спектр собственно разработки, остальное — это внешняя организационная "обвязка", которая должна быть у любого, кто работает в иерархическом коллективе. Никто вам не расскажет про тайм-менеджмент лучше солдата (особенно солдата в увольнении :) ).
Соответственно требовать от себя или другого человека чтобы он был всеми тремя одновременно — это довольно неразумно.
Хирурга я выбирал и буду выбирать не по бумажкам (меня не бумажки резать будут), а по личным рекомендациям и известным мне результатам (как положительным, так и отрицательным). И тут мат — не мат, просто не обращаешь внимание и всё, так же как не считаешь количество ушей и не смотришь на количество волос на голове.
Тем более, что матом можно объяснить все быстро, просто и доходчиво, а вежливо — гнать всякую пургу (а можно и наоборот). Просто нет корреляции и всё.
И хирурги с плохими результатами тоже долго не работают… У всех работающих результаты плюс-минус одинаковые.
Тут ещё проще. Если у них примерно одинаковые рекомендации и примерно одинаковая стоимость, то почему? По какой причине люди не начинают массово выбирать того, что вежливый и почему он не переходит в более дорогую больницу? Причины могут быть разные, но одна из возможных причин — его уровень для более дорогой больницы недостаточный. А тот, что кроет матом — почему его не выгоняют? Возможно он достаточно хорош, что б компенсировать недостаток "софт-скилов". Так и в чью пользу выбор будет?
Если вы разрабатываете технически сложную программу, то на первый план выходят именно hard skills. Если же это очередное CRUD-поделие с 5-ю активными пользователями в час, тогда верно — разработчику будет достаточно минимальных технических навыков, чтобы разобраться и участвовать, и вот тогда уже на первый план выходят другие качества — и бизнес и человеческие, м.б. даже умение веселить коллектив или метко бросать дартс.
Мне кажется в проектах с 5-ю активными разработчиками на первый план выходит стоимость разработчика, а не его умение играть в дартс :)
Скажи мне, программист, кем ты будешь через 5 лет?
Так и хочется ответить — "а я томат!"
Нифига этот вопрос не помогает понять способности планирования. Единственное о чем он говорит, да и то не вопрошающему, а кандидату — это то, что его собеседует какой-то "странный" тип.
Бред. Я понимаю еще это можно отнести к тимлиду, архитектору или на крайняк техлиду. Но обычный программист ничего этого не должен кроме основного своего скила
Компетенции современного программиста под другим углом
с учетом того, что это 153-ая статья на тему важности soft-skills и того, что обратного никто особо не декларирует, угол не такой уж и другой, а какой и обычно
Главный посыл, что программист сегодня — это не набиратель кода. Это важная боевая единица: юнит, который может решить исход сражения, если правильно будет пользоваться всеми своими заклинаниями.
Я скажу крамольную вещь, но по моим наблюдениям как раз всё с точностью до наоборот. Среднестатистический программист четвертьвековой давности, это как раз вполне себе самодостаточная боевая единица. Он садился и решал проблему. Среднестатистический программист сейчас нуждается в куче инфраструктуры вокруг, имеет массу навороченных бизнес-процессов, массу архитектурных и интеграционных требований, которые якобы должны повышать его эффективность, но… как в том старом анекдоте про самолёт: «А теперь попробуем со всей этой хернёй взлететь». Проблемы решаются намного медленнее и хуже.
Согласен, в некоторых местах разбухла чуть больше, чем нужно, но это не страшно.
Никто не говорит, что тот парень был плох. Он решал проблемы.
Как раз речь о том, что нужно решать проблемы (я ссылаюсь в материале на статью, где только про это и пишу). А для решения проблем в огромной и глубокой инфраструктуре сегодня, как раз и нужно обладать софт-скиллами, потому что раньше было легко. А сегодня нужно учиться сотрудничать со многими другими юнитами, разных бекграундов.
Инфраструктура в глобальных масштабах, конечно, выросла. Но с точки зрения одного разработчика охват его части проблем не вырос. А может, даже уменьшился. Современный программист общается с инфраструктурой через толстые слои библиотек, и он в общем-то может позволить себе нихрена не понимать, как оно там за этими слоями работает. А зачастую и не понимает. А четверть века назад во многом приходилось самостоятельно разбираться. Хочешь письмецо отправить? Вот тебе порты, вот тебе протокол SMTP, садись, пиши реализацию. Хочешь многоуровневое приложение? Вот тебе брокер CORBA, вон тот шкаф с книгами — это мануал, а вон там на стене винтовка, сам застрелишься, как прочтешь половину.
И самое загадочное — те самые проблемы и фичи. Даже в таких садистских условиях продуктивность труда была почему-то выше.
Было бы логично, если в таких условиях программист мог задуматься о конечном пользователе больше, чем раньше.
Было бы логично, если в таких условиях программист мог задуматься о конечном пользователе больше, чем раньше.
Программист о конечном пользователе не особо думает, ни тогда, ни сейчас. Для этого и появились UI-дизайнеры и бизнес-аналитики :)
А в небольших проектах, где нет UX / UI спецов и аналитиков, эта вещь становится более чем уместна.
а) не мыслит категориями «как это сделать, чтобы наиболее бестолковый пользователь разобрался». Для него логичен тот интерфейс, который он сам понимает.
б) если ещё и решает пользовательские проблемы, то бывает ими крайне раздражен.
Будучи человеком, который участвует в воспитании и мотивации сотен молодых специалистов в год, считаю, что нужно продвигать более идеальные профессиональные ценности.
Все специалисты сталкиваются с объективной реальностью, но, если периодически не поднимать планку мотивации, изменений к лучшему дожидаться придётся дольше.
Статья выглядит неплохо, но создаётся впечатление, что в своём обобщении вы совершенно расстались с реальностью.
О менеджерах в статье речи не идёт абсолютно совсем. Эти специалисты закрывают свой скоуп задач.
В моих командах у меня есть менеджеры, которые отлично справляются со своими обязанностями (было бы у меня время тогда строчить статьи).
К разговору о том, что расставаться с реальностью — я описываю свои принципы работы. Учитывая, что мне за них платят деньги и уважают в моей компании, значит, это реальность.
Потому что от специалиста в первую очередь требуются его профессиональные навыки, т.н. «hard skills». То, что вы описываете как «soft skills», является приятным дополнением, но никак не влияет на ваши профессиональные навыки. В вашей статье эти навыки указаны как требуемые, т.е. без них специалист — не специалист, что, на мой взгляд, является некорректным посылом.
Под расставанием с реальностью я имею ввиду, что описываемый набор навыков, тем более топ-6, применим далеко не ко всем случаям и не всем командам. Ваш пример, несмотря на обобщение, остаётся частным случаем, поэтому, как рекомендация для широкой аудитории, оторван от реальности.
Если вам нужен пример: в одноранговой группе (команде без иерархии) разработчиков без выраженного разделения функционала перечисленные навыки имеют ощутимый вес, в то время как в какой-нибудь конторе перечисленные навыки не принесут особой пользы отдельно взятому участнику.
Скажите, вам точно платят за ваши принципы, а не за навыки?
Компетенции современного программиста под другим углом