Комментарии 12
Хорошо написано, но, как въедливый программист, замечу - не рассмотрен ещё один вариант - мы ведём за ручку коллегу к границам его познания, и в итоге оказывается, что нас привели туда, куда хотели [не мы]. Как пережить эту боль?
Отличный вопрос!
Это действительно болезненный - но очень полезный опыт. Всегда, проживая его, рос как разработчик.
У меня такое случалось несколько раз и всегда - неделя настоящей депрессии. Мне помогало сразу начинать использовать новые знания на практике. И, также, помогало обращаться за помощью к человеку который раскрыл новые знания. Этот человек проходил схожие этапы осознания, он выслушивал душевную боль как свою, поддерживал и направлял.
Со своей стороны, я попутно укреплял его знания задавая наивные вопросы. Вопросы новичка - самые каверзные. Они касаются основ и обоснования взглядов - это вопросы "а зачем это вообще?" от человека который не принял пока концепции как разумеющиеся сами собой. Эти вопросы позволяют опытному человеку увидеть вещи на которые замылился глаз.
Посыл в статье правильный. Но есть загвоздка: как быть, если нет возможности сидеть за чаем с каждым коллегой и настраивать совместное понимание? Правильно, обычно в этих случаях пишут документацию. А вот как её-то написать на языке читающего? Вопрос...
Хороший вопрос. Доки которые я делал, по ощущениям, читались людьми плохо. И в этом большая доля моей ответственности. Я их писал со своих позиций и очень слабо собирал по ним обратную связь.
Думаю, для качественного решения этот вопрос должен решаться на уровне процессов компании. Поддержка ключевых, качественных док должна выполняться в рамках задач, равноправных с прочей разработкой. И она на уровне рекомендуемых процессов должна включать в себя сбор обратной связи.
Альтернатива - делегировать написание док специально выделенным специалистам - техническим писателям. Они хорошо понимают как выполнять работу по созданию качественной документации, с этим связаны их прямые рабочие обязанности.
По опыту, качественная документация получается в результате скурпулёзной обработки обратной связи. Нужно пересиливать себя и спрашивать у читателей доки: "Что понравилась? Что было не понятно? Что бы ты доработал?" Страшновато услышать критику - но с развитием опыта вы начнёте воспринимать критику не как набор упрёков, а как обучение коммуникации в документациях.
Кстати для себя вывел один способ ненавязчивого ревью документации. Берешь свою доку, и по ее оглавлению начинаешь с непосвещенными проходить материал с демонстрацией кода. Если дока хорошо структурирована, и четко сформулирована, то этото процесс пройдет плавно и сам по себе. Если же ты почуствуешь, что приходится делать отступления чтобы пояснить какие-то моменты, то вот это и есть дыры в документации.
А ведь так можно и без команды и всех этих софт-скиллов обойтись, просто а нанять людей (и не важно социопат он или гений общения) с хорошим умением именно програмировать, а не договариваться.
А вариант прочитать статью повнимательней и подумать головой - не рассматривается? (пардон за сарказм)
Проблема в том, что предугадать заранее, где именно придётся "стелить соломку" в командной работе, практически невозможно. Люди очень разные, в голову к каждому не заглянешь, и его будущие реакции на код не предугадаешь. На многие проблемы возможно реагировать только реактивно. С одним товарищем согласовали принципы работы с API, с другим баланс функциональщины и императивщины (иду по примерам из статьи), с третьим тесты, с четвёртым схему БД, с пятым... И это вещь совершенно перпендикулярная "хорошему умению именно программировать". Даже у хороших программистов будет разный личный опыт и разные собственные предпочтения в работе, которые могут влиять на итоговый результат из труда. Многие из этих отличий не будут оказывать существенного влияния на код, но в некоторых случаях будут. И статья про то, что делать в этих случаях.
Конечно, если мы из раза в раз вынуждены объяснять определённые правила работы с кодом разным людям, это важный симптом. "Запах", как говорят некоторые. Если в определённом месте пахнет, это надо фиксить, факт. Либо, действительно, доки писать, либо код рефакторить. Но с доками всё тот же прикол, что и с кодом. Писать их надо уметь, это отдельный навык. Напишешь неправильно, и люди всё равно ничего не поймут или поймут по-своему (опять же, в силу отличий индивидуального опыта и предпочтений). И этот процесс недешёвый - см. выше. Писать документацию на всё подряд дорого и не особо полезно.
С другой стороны, если смотреть со стороны разработчика, эти скиллы развивать как раз выгодно, так что если это не сильно напряжно — развивать их стоит.
Но в предыдущем комментарии я посмотрел как раз со стороны менеджера.
Адекватный менеджер - редкий зверь в нашем захолустье. Приходится выживать как умеем
Да. добавлю кое-что важное, чтобы исключить появление лишних иллюзий. Я не посчитал бы адекватным менеджера, который хочет контролировать всё общение программистов между собой. Типа, трепаться про кино и тачки без менеджера можно, а обсудить, где и как лучше провести границы в коде уже и нельзя? Это уже его зона ответственности, что ли? Что за хрень вообще?
Почему-то вспомнился Карнеги. И его советы, которые, может, и работают в его стране и окружении, но, увы, в наших реалиях в лучшем случае вызывают "о, парень начитался Карнеги! ну-ну...", а в худшем, от не столь начитанного человека можно и схлопотать... Нет?
Я написал статью по реальному рабочему опыту в российской конторе. Научился (плюс-минус, до совершенства оч долго ещё) менторить через призму чужого опыта у одного из своих крутых коллег, российского разработчика... Возможно, мне просто повезло встретить такого коллегу - но вот, вроде, вполне реальные реалии
Программирование — это про общение