Комментарии 31
Польза от менеджера становится очевидной, когда у проекта возникают проблемы, которые не решаются с помощью кода. Похоже у вас там какая-то ситуация, что стало подгорать, но я бы не проводил однозначные параллели между менеджерами и говнокодом.
В сложных проектах, всегда есть простор, чтобы улучшить решение. Не пробовали из разработчиков переместиться в саппорт?
Автор вроде как не сомневается в пользе от менеджеров. Он сомневается в пользе менеджеров, которые совсем "не в теме" того, чем именно они "управляют" — эдаких манагеров. Это те, кто считает, что нанять в помощь одному программисту 4-рёх студентов означает — получить автоматическое ускорение разработки в 4 раза.
Как мне кажется что самый эффективный способ (если вам действительно хочется развиваться как программисту), попробуйте устроиться на работу туда, где работают хорошие программисты. Они вас вытянут на свой уровень (с условием что это тебе надо и ты не в конец тупинамбур).Как понять что там работают хорошие программисты? Интересуюсь вполне серьезно.
Я у вас посмотрел интересы в профиле, может, это какая-то специфика 1С?
В 1с до последнего времени современные подходы к разработке ПО практически не применялись. Сейчас при желании есть возможность их таки применять. Но вот убедить этих самых менеджеров в необходимости применения задача непростая...
1) Задача поменялась в процессе реализации (и хорошо, если уменьшилась).
2) Сжатые сроки и/или переработки.
3) Большой объем задачи.
4) Реализовались технические риски.
Большинство этих проблем решаются не кодом, а общением ртом с менеджерами. Первые три решаются переходом на SCRUM, а последняя только с опытом — учишься избегать граблей.
Невероятная жизнь Уолтера Митти.
Гениально снятое кино с невероятно чудовищным посылом: фотолаборант теряет важную фотку в кризисный для компании период, когда новый, только что назначенный ради решения одной конкретной задачи менеджер эту фотку при каждом удобном случае требует. Менеджер, ясное дело, эффективный, и вообще по фильму представлен редкостным говном, он всего-то требует найти то за что отвечает лаборант. Далее фотолаборант весь фильм героически сражается с собой, обстоятельствами, вулканами, акулами и горами по всей планете, а фотку в итоге находит дома.
Менеджеров в принципе принято не любить, а эффективных (без кавычек), тех кто жестко решает поставленную бизнес-задачу, и вовсе ненавидят. Менеджер в фильме безусловно редкостная гнида, но не потому что успешно решает поставленную задачу, паралельно отрабатывая запасные варианты с утерянной фоткой, а потому что в процессе издевается над главгероем, да и в целом получает удовольствие от решения поставленной задачи. А главгерой страдает. Зритель ненавидит того кто получает удовольствие и любит того кто страдает.
Но фотку профакапил кто?
Картинка, звук, игра актеров, все великолепно в этом кино. Но посыл жуткий.
Иван, в статье написаны правильные слова, но они неправильно расставлены. Менеджер решает свои задачи, разработчик свои. У менеджера свой горизонт событий, у разработчика свой. Эти роли в принципе думают разными абстракциями. Я когда-то, лет пятнадцать назад, был думается мне неплохим разработчиком, а потом стал менеджером. С тех пор я не пишу код. Иногда я открываю исходники и что-то по старой памяти смотрю, вижу знакомые "слова" но чтобы понять их "смысл" (правильность, сложность кода и т.п.) мне не хватает тех самых пятнадцати лет потраченных на совершенствование навыков менеджера. Это как разработчику (не связанному по работе с с ФХД) открыть БДР и БДДС, рядом в окне воронку продаж и попросить указать зависимости, лол-што?
Я не защищаю менеджеров, там полно случайных людей, но вот так грубо передергивать на тему что причина плохого кода это менеджер — неправильно.
… любимая сцена в фильме, когда Митти бежит к вертолету.
… или когда едет на лонгборде?
Только в свободном творчестве ты поймешь и прочувствуешь, что такое классный код, увидишь красоту ЯП и технологий, ощутишь прелесть бизнес-задач.
Ох уж эти творцы. По моему опыту, если программисту дать полную свободу, то натворит он неописуемое. В 90% случаев получается оверинжиниринг на самом модном фреймворке, на котором пишут 10 человек в мире. Наверное, в этом есть своя красота, но потом такой творец-перфекционист увольняется и тем, кому придется это поддерживать остается только посочувствовать. На всякий случай, я не менеджер.
У вас по другому?
При том, что я двумя руками за качественный код, команда, которая три года писала идеальный код, который никогда не увидит продакшен (потому что писать надо было не это) — потеряла три года в пустую.
У меня был момент в карьере, когда я писал "в стол". Это ужасно. Это демотивирует, это разрушает. Хороший менеджмент решает.
Так вот, в каждой мини-команде, которая разрабатывает под определённую ОС, есть несколько разработчиков. У нас используется git, и куплен BitBucket. Все мерджи в master-ветку происходят только после Code Review, прохождения всех тестов и удачной сборки проекта на агенте битбакета. Если изменились или появились строки в интерфейсе, автоматом в Review добавляется главный переводчик. При наличии определённых тэгов в описании ревью, агент собирает проект и постит ссылку на него в Slack, чтобы тестировщики могли прогнать собранный билд из ветки на предмет фикса бага и т.п.
Например, нас в команде Андроида три разработчика. Один создаёт ревью, два других проверяют.
Хотя, конечно, такой подход к разработке не решает всех проблем, и иногда в мастер попадают разные несуразности, всё-таки все мы люди, и не получается весь код перекомпилить в голове, особенно когда в ревью показываются только изменённые части файлов. Но очень большая часть косяков, какая-нибудь лапша и т.п. не попадают в мастер.
Секрет эффективности — качественный код, а не эффективный менеджер