Что нужно, чтобы стать отличным разработчиком

материал из разряда пропаганды "теории малых дел"

почему не заданы вопросы:

почему компания хочет команду но никогда не закладывает ресурсов на построение этой самой команды?

почему компания не ограждает исполнителей от заказчиков без внятного тз?

почему компании говорят о важности общения в команде но тут же забывают о солидарности внутри этой команды относительно харасмента, увольнения?

рыба гниёт с головы, чистят её с хвоста...проблема команд лежит на 99% в рамках требований тех, кто платит зарплату и эти требования как раз и мешают разработчикам создавать нормальные команды но вопрос в статье рассматривается сугубо с "хвоста"

все считают что построение культуры командной работы это побочный эффект работы...нет это тоже работа и на неё нужно тратить временные ресурсы

Советы от эффективных менеджеров как нам выполнять хорошо свою работу?

Волки из пацанских пабликов. Докатились.

Никому не сказать, закрыть задачу, потому что нет времени что-то исправлять. 

С одной стороны, за такое надо просто увольнять. С другой - если система настроена правильно, то к задаче (заявке, тикету - в разных системах разное название), должен подвязаться твой PullRequest. Или, нет PullRequest-а - нельзя задачу закрыть. Как то так.

Верно. Никто не заставляет углубляться в виды дизайна или учить другие языки разработки. Но пригодится знать, как устроена работа коллег в соседних командах: это сэкономит время на переговорах. 

Что то ни разу не видел, что бы дизайнер, HR, бухгалтер или вообще кто поинтересовались - как устроена работа у программистов. В основном всё общение происходит на совещаниях. Например, недавно дизайнер хотел изменить окно в браузере, которое отвечает за авторизацию в домене.

P.S. Дальше читать уже сил не было, оценка -6 сама за себя говорит

У меня не так много опыта, но думаю, что …  

Лучше промолчать.

Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало.

Ссылаться на абстрактный опыт абстрактной другой компании - куда хуже, чем на учебник. Потому, что от учебника можно ожидать обоснованного мнения с границами применимости и причинами, а опыт другой компании в такой постановке - это анекдот.

Я сейчас в компании в которой мы работаем так, как расписывает попунктно автор, у нас всё идёт лучше некуда, о нас знает весь мир и я полностью согласен с её мыслью. Абстрактный работник в своём личном вакууме который не соображает что происходит вокруг и чем занимаются его коллеги никому нахер не упал. В целом зависит от компании, если ваша работа это жира -> компьютер -> обед -> посрать -> отчет -> свалить домой, то это одно, а если ваша работа подразумевает хоть что-то полезное, то это совсем другое.

Дизлайкают явно отбитые которые не понимают что работа это про зарабатывание денег, конечно про зарабатывание денег, не про какую-то духовность и остальную чушь которую можно наматывать на уши до аль-денте, но вместе и помогая друг другу. Если конечно речь не про Сбербанк, Яндекс и прочие конвееры по переработке людей в мясо за копейки, в которых в здравом уме никто мариноваться не будет. Но если вы решили именно туда — извольте поприкусить жабры и не жаловаться, не минусить посты про адекватную работу и не ныть теперь что ничего вы не должны никому на свете, фантастические вы существа.

Очень правильные мысли в статье, очень жаль коллег которые с такими комментариями приходят.

❌ Плохо

Я знаю, что так будет лучше. Я читал в учебнике.

✅ Хорошо

Лучше выкатить … после …, потому что однажды одна компания сделала наоборот — и всё упало. То, что вы предлагаете, проще и быстрее, но, мне кажется, мы рискуем.

Тут обе вещи плохо. Если однажды компания сделала наоборот и все упало, то дело может быть не в идее, а в реализации. А в учебниках может быть описана world best practice, просто опять таки реализовывать ее надо с пониманием.

Во-вторых почти все проблемы указанные в статье, особенно касающиеся замалчивания - относятся не к разработчикам, а к менеджерам младшего и среднего звена. А то и старшего. Я не помню, чтобы разработчики о чем-то умалчивали. Наоборот регулярно доносят наверх о существующих технических проблемах и накапливающемся техническом долге, из-за которого повышаются риски багов. Но менеджеру нужно отчитаться заказчику о выполненных бизнес-задачах, поэтому все техническое замалчивается и заметывается под коврик. Но это делают МЕНЕДЖЕРЫ, а не разработчики.

капасити на технические задачи могут выделить только менеджеры

капасити на курирование джунов могут выделить только менеджеры

капасити на правильный code-review могут выделить только менеджеры

проактивность без капасити невозможна, проактивность без поддержки со стороны менеджеров невозможна. Я работал в проекте, где за проактивность могли дать премию, если она проходила определенный этап ревью. За год от нашей команды было подано около 400 идей, из которых за 18 получили премию. А без этого, откуда взяться проактивности?

Разработчик - имеет очень мало прав. В одной компании у нас в коридоре был турник, и мы почти всей командой разработчиков на нем регулярно занимались. Потом в компании случились перестановки, мы переехали в другой блок здания, где не было турника. Мы просили компанию организовать (стоимость такого турника ничтожна, мы его и сами бы купили и сами бы установили), но компания не позволяла. Нас было 12 человек разработчиков, проактивных. И только через пол года активных переговоров и переписок нам позволили организовать турник. Купили stand-alone, поставили прямо в кабинете.

И это еще про-активность, которая была очень мотивирована, еще и поддерживалась дайрект менеджером, но рубилась чуть выше, и совершенно не понятно почему рубилась - никому от этого не было бы плохо.

В общем все эти советы давать разработчикам бессмысленно. Просто читаешь как сказочку о том, как в какой-то волшебной компании есть волшебные менеджеры, и тогда все это заработает и без этих советов.

В статье можно заменить "разработчик" на любую другую роль в команде - и общий посыл ни на йоту не изменится. Потому что должна быть синергия и взаимопроникновение опыта. Что бывает редко.

Но я не вижу статей вроде "как стать отличным аналитиком и начать писать ТЗ, а не филькины грамоты". Вместо этого зачастили статьи, где учат жить разрабов, причем довольно топорно.