Comments 20
Софт-скиллы позволяют разработчикам подходить к проблемам комплексно, улавливать их корни и искать такие решения, которые будут долгосрочными, а не просто краткосрочными "костылями".
Кажется, что в моей практике всё было ровно наоборот.
По-моему, способность видеть корень проблемы и стремление к максимально корректному поведению программы, это исключительно "хард" скилл. "Софт" скилл в 99% использовался для убеждения остальных, что "и так сойдёт".
Софт-скилл может пригодиться и для защиты правильного, с твоей точки зрения, решения. Иногда команду надо убедить, что твой подход - правильный подход.
Что может быть убедительнее кода? Схемы решения? Предлагаете послушать гуру, которые оперируют понятиями «пропитчить мысль»?
Или образец, к которому нас толкают, это питон Ка с его «Бандерлоги, хорошо ли слышно меня»?
Есть один код, есть другой код. Мне нравится первый, коллеге - второй. Как убедить коллегу в своей правоте не прибегая к насилию и угрозам?
если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
Что значит - нравится? Цвет более удачный или шрифты посимпатичнее? Если два решения идентичны (что маловероятно иначе в чем тогда спор) то к примеру тот что раньше был закоммичен. В ином случае более корректное, оптимальное и полное решение, и тут уж придется разбираться кто самое слабое звено, но опять же никакие софтскилы не помогут из некорректного решения сделать корректное - но вполне помогут уболтать и пропихнуть некорректное решение в проект. Если же при прочих равных вам принципиально что бы код был отмечен именно вашим авторством, то тогда даже не смотря на наличие прокачанных софтскилов вы как раз и есть не командный игрок :)
Из недавнего, я сам с собой решал вопрос что лучше. В общем, есть многопоточность. Есть главная задача, посылающая в параллель исполняться другие задачи и пуляет дальше. Когда мы пытаемся прервать выполнение задачи какой либо, то есть три пути - немедленное убийство, установка hard time limit (после которого произойдёт немедленное убийство - мы таким образом даём шанс завершиться до конца в пределах и только потом убиваем) и тёплое завершение всех процессов (когда дожидаемся выполнения текущего исполняемой задачи и прерываем процесс "забора" задач из очереди).
Вот что лучше? Или скомбинировать?
Немедленное убийство не приведёт к прерыванию забора задач из очереди. И может убить возможность возврата исполняемой задачи в очередь со статусом "retry"
Hard time limit сможет убить главную задачу - потому что она всегда работает и пуляет в очередь задачи. Остальные могут исполняться быстрее, чем есть time limit и это не перерывает процесс забора задач из очереди
Тёплое завершение не приведёт к убийству главной задачи, но приведёт к прерыванию забора задач из очереди
Ну и так далее
Почему теперь просто кодить мало?
А хотите честный ответ? Мало потому, что Айти в некоторых аспектах сейчас глубоко больнО. В эту сферу десяток с лишним лет назад хлынул мутный поток разного рода деятелей, которые увидели здесь благодатную почву для того, чтобы, поездив по ушам верхнему звену руководителей, оседлать все слои, лежащие ниже. И ничего не производя, как и не отвечая ни за что, начать торговать воздухом. При этом полноценно встроившись в пищевую цепочку Айти.
Вы пристально почитайте определения этих ваших софт-скиллов. Это же Эльдорадо!!! Тут можно разворачивать целую индустрию курсов и тренингов, все размыто, субъективно, критерии четкие отсутствуют. Недавно в статье тут же на хабре прочитал про софт-скилл "непрерывное лидерство". Обалдеть...
Господа суетологи, вы бы оставили Айти в покое.
Господа суетологи, вы бы оставили Айти в покое.
На сайте висит пузомерка зарплат в отрасли. Очевидно, до тех пор, пока этот показатель будет заметно выше среднего по больнице, в айтишечку будет ломиться всякое такое непрерывно прогрессорствующее суетливое лидерство.
Спасибо, полезно
Спасибо за комментарии. Очень интересные. Хочу обратить внимание, что наличие прокачанных софт скиллов никак не исключает хард скиллс. Но я часто на интервью встречаю ребят, кто не может объяснить, почему выбрал такое решение, как подходил к выбору, что за продукт или проект был, плывет по течению и не может объяснить, в чем его мотивация, почему работает на текущем проекте, на вопросы отвечает смотрите в резюме, там все написано, и так далее. При этом они наверняка неплохо кодят, но интервьюер не может знать о кандидате то, что сам кандидат знает о себе, только то, что он транслирует интервьюеру. Да и в рабочих ситуациях часто наблюдаю, что порой не хватает личностных качеств для решения каких-то ситуаций. Моя рекомендация - развиваться всесторонне, не только в технологиях и навыках кодинга.
"Это проблемы интервьюера.
Совсем нет. Если хотите можем разобрать это.
Вопрос. Почему вы участвуете в интервью на трудоустройство?
Я понимаю, некомпетентность той стороны становится моей проблемой. Но решать её можно по-разному: либо борьбой за повышение компетентности той стороны, либо прогибаться под их некомпетентные хотелки.
И вот, до наступления эпохи набега случайных людей в айти, проблемы поиска специалистов просто не было: в резюме выкладывались навыки и проекты, а интевьюер, тоже специалист, понимал с кем имеет дело. На собесе можно было перекинуться парой слов, просто потому что обе стороны понимали друг друга с полуслова. Сейчас айти с подачи "софтскилловых" продавцов пылесосов превратилось в какую ярмарку тщеславия, где надо уметь продавать себя. Даже работать уметь уже не обязательно, главное уметь продавать себя!
ЗЫ. Забавное как после каждой критики "софтскилловые" наваливают полную панамку в карму. Лицемерные и подлые людишки, непринимающие никакого другого мнения кроме их собственного.
Никогда ещё айти не было таким душным и токсичным как после набега "софтскилловых"!
"Раньше всё было проще: писал код и всё"
Какой временной промежуток имеется ввиду? )
Представь, что ты написал фантастический модуль для программы, но не можешь объяснить своим коллегам или клиенту, как он работает или почему он так важен.
А теперь представь, что ты можешь навешать лапши на уши коллегам и заказчику, но не можешь написать нормальный код...
Общаться с заказчиком вообще не дело разработчика (ну разве что фрилансера или мальчика-на-все-руки в артели "Сукин и Сын"). Для этого в нормальных местах есть специально обученные люди.
Разработчик - он на то и разработчик, что его дело разрабатывать. В первую, вторую и третью очередь. Объяснять заказчику почему он разработал именно так а не иначе вообще бессмысленно. Заказчику это не интересно.
Мир давно уже перешел на стадию разделения труда. Заказчик не должен приходить к разработчику (если у вас это так - у вас серьезные проблемы с организацией производства). Он приходит к специально обученному человеку и выкатывает свои пожелания. Которые потом оформляются виде бизнес-требований, затем уходят к архитекторам где формируется архитектурное решение, потом к аналитикам где формируется ТЗ и вот оно уже попадает к разработчикам.
Максимум софт-скиллов, требуемых от разработчика - умение общаться с себе подобными членами команды и аналитиками. Все. Но это уже после того, что он должен быть профессионалом в своем деле. Мимимшные пустобрехи с софт-скиллами 80lvl но полным отсутствием хардскиллов в разработке напрочь никому не нужны.
Если вы работаете в госсекторе, то возможно вам, вашей команде и само собой вашей организации (это же госсектор, у государства нет конкурента) не грозит опасность.
Но в современном мире коммерции нужно быть гибким, нужно чтобы все люди в компании (не в команде) понимали чего хочет клиент. И хотели ему помочь.
Если ваше дело только код писать, то похоже вы не сможете помочь клиенту. А значит ваша компания в долгосрочной перспективе находится на линии вымирания. Таков сейчас мир.
Вопрос в том. Вы хотите быть участником команды которая станет успешной?
Если да, то перечитать статью.
Если нет, то да, дальше пишите код (без сарказма).
Но по секрету скажу, что больше и намного платят спецам из первой группы. Которые не думают что их задача только кодить, а знают что их задача решать проблемы клиента, а значит помогают компании, а значит помогают себе и своему карьерному росту и профессионализму.
Статья об этом.
Чушь, вы даже не понимаете, что есть код который пишут, чтобы другой код работал, а не для клиента. Есть платформенные команды, есть девопсы и другие, которым весь этот бред не интересен, им интересны SLA, DX и премии по итогам SLA и достижения целей. И забивать им голову вот этой чушью, которая лишь оправдывает нахождение в штате человека который не понимает процессы разработки - только лишние расходы для компании которые не дают никакого профита ни для компании, ни для клиента. Зато софт-скилловый HR защищен от уволенения, из-за бурной деятельности по обучению персонала софт-скиллам.
Вы правильно сказали что все в компании должны иметь вижн клиента. Это ответственность CEO, построить правильные процессы, чтобы его/клиента вижн доносился до всех, без испорченного телефона и был доступным для понимания.
Время хороших разработчиков очень дорого, они получают ставку выше чем основатели и директора компаний. По этому не стоит его тратить на митинги, общение с клиентами и тд, для этого есть специально обученные люди. Их время дешевле и они справятся с задачей намного лучше.
Не забывайте про context-switch, это самый большой, не эффективный расход времени. Когда вы 2 часа кодили потом митинг с клиентом на час-два, а потом вам нужно вернуться кодить - разработчик теряет не час-два, а три часа минимум чтобы достичь пиковой продуктивности.
Эта сфера во влиянии логики и денег, вам здесь не дадут инфоцыганить и миссионерить без подкрепленных, логически верных фактов. Факты это не про психологические статьи в интернете и опыт в других сферах. Здесь все иначе и ошибки очень дороги для компаний и их инвесторов.
Upd:
Многие люди думают, что ИТ - токсичен из-за резких высказываний, типа "смотрите резюме" и тд. Но они не задумываются что притворяться экспертом - токсично для ИТ, изображать бурную деятельность - токсично для ИТ, уверенно, софт-скиллово говорить не правильные, бесполезные речи, говорить о том чем не компетентен - токсично для ИТ. Проблема то не в ИТшниках, они делают свою работу, а вы делайте свою и тогда все будет ок.
Я считаю, что основной затык по софтскиллам из-за психологии и надо ходить к психологам.
Больше, чем код. Невидимые ингредиенты успеха разработчика