Comments 13
Я бы не хотел обобщать и передёргивать, но на первый взгляд статья состоит из обобщений и передёргиваний.
Техлид нужен, чтобы когда есть выбор, было кому хлопнуть рукой по столу и сказать «делаем так и ниипет» и быть ответственным, чтобы всякие джуны не делали левой пяткой с возгласами «работает же!», ну совсем вкратце.
Если кажется, что 20 лет назад программировали совсем по другому (кек!), и человек с 20 (Карл!) годами опыта ни*** не смыслит и проиграет таким как ты — ты вообще ничего не понял и не миддл ни***.
Я сначала хотел ответить автору по всем пунктам, но потом подумал, что статья намеренно написана в провокационном стиле и спорить с автором не имеет смысла.
К сожалению сейчас это "нормально" — человек налабал два сайта на php (я не об авторе конкретно а в общем) и решил что значет о программировании все.
Имея техлида всегда можно возложить всю ответственность на него и уже не команда плохая, а техлид плохой.
Ключевой момент что у тех/тимлида кроме ответственности есть и возможности. Вообще две эти вещи (ответственность + возможности) нужно всегда рассматривать вместе. Я к чему это все веду.
Вот спорят разработчики по какой-то пустой проблеме, табы vs пробелы. И просто разработчик говорит хочу табы! но ему плевать к чему это приведет, он не несет ответственности, будет какой-то критический баг из-за его решения? Пофиг, на его ЗП это не повлияет, его не уволят, когда попросят повышение ЗП про это не вспомнят.
Давайте теперь более серьезную проблему, пусть у нас будет баг когда будет больше 1024*1024 пользователей, но мы сейчас делаем стартап и не факт что у нас их хоть 100 будет. Можем ли мы оставить этот баг, еще и учитывая что в будущем его будет сложнее пофиксить и он будет обрастать костылями? Ситуация опять же как в первом случае. тех/тимлид/сто могут принять решение, у них есть ВОЗМОЖНОСТЬ, но им же и отвечать за это.
Я как разработчик прекрасно понимаю чужую ответственность, по этому когда тимлид говорит "говнокодим!" то окей, даже если я считаю что он не прав, я не будут "грустить" по этому поводу, или увольнятся потому что "мой техлид — идиот!". Его решение, возможно не правильное, его ответственность.
P.S. я понимаю что мой текст получится немного водянистым и повторимым, но я еще раз скажу — ответственность и возможности должны всегда быть вместе.
Умеет видеть проблемы — возложить всю внимательность на одного человека? Чем будут заниматься другие?Другие, если техлида с опытом нет, будут раскладывать грабли по проекту и выращивать тех-долг.
Банально, многие разработчики с опытом могут видеть больше возможных уязвимостей и багов заранее.
А людям с живым умом не нужно техлидство. Им нужна свобода и шаринг знаний.
Проще говоря - бардак и анархия
Не со всем в статье согласен, но накинул плюс за старания и желание поднять важный вопрос. Проблема конкретно этой статьи, пожалуй, в излишней абстрагированности. Команды бывают разные, проекты разные, ситуации... а здесь автор пытается подвести их под один общий шаблон. Ну, не сводятся они, что поделать. Иногда лидер бывает тормозом для команды (отличная статья была на эту тему не так давно). А когда-то может как раз таки успешно тянуть банду юных падаванов.
С демократиями тоже ведь не всё так просто. То, что один человек считает спасительной соломинкой, другой может видеть ненужным балластом. Вася думает, что эффективно срезает углы, а Петя говорит ему, что тот страдает перфекционизмом. А лодка общая. Как им всем договориться и принять совместное решение, куда двигаться? Или, наоборот, если они не будут договариваться, а каждый будет волен двигать судно в свою сторону (ой, это уже "с поклажей воз")? В идеале, позиция техлида состоит (среди прочего) в том, чтобы консолидировать шевеления всех членов команды и направить их примерно в одном направлении. Но то идеал, а у нас реальная жизнь с несовершенными людьми.
Может быть, автору стоило бы не увлекаться обобщениями, а поделиться конкретными историями, которые толкнули его к этим мыслям. Читатели любят истории. Так все остались бы в плюсе.
Рассмотрим ситуацию. Есть два кандидата:
20 лет опыта. java 6,7,8; j2ee; jdbc and so on.
5 лет опыта. java 11; spring jpa; kubernetes; kafka
Странно что это противопоставляется. Далеко не у всех так. Если условный техлид не уже седой теоретик, а активный разработчик, то будет: java 6,7,8-11; j2ee; jdbc and so on + spring jpa; kubernetes; kafka. За 20 лет это возможно и наиболее вероятно.
Рассмотрим ситуацию. Есть два кандидата:
20 лет опыта. java 6,7,8; j2ee; jdbc and so on.
Java 1.1-17, Kotlin/Scala/Clojure, Spring/Guice/Micronaut/любой другой DI, J2EE (CDI, JPA, JMS, SOAP, JTA), ApacheMQ/RabbitMQ/WebsphereMQ, паттерны проектирования, архитектура приложений. Прокачанные скиллы и интуиция. Человек, понимающий как внутри устроены инструменты, которыми он пользуется, и способный при необходимости написать с нуля любой из них.
5 лет опыта. java 11; spring jpa; kubernetes; kafka
Толком не знает как работает ни одно из этих "чудес", а тупо копипейстит из туториалов и SO, строгая шаблонные микросервисы. При вопросе про ACID, transaction isolation levels, delivery semantics той же kafka, и даже же про основу — Spring-овский DI, впадает в ступор. В итоге без надлежащего контроля уже с конвеера выходит абсолютный хлам. Модный, но хлам.
Некоторые решения давно устарели.
Не устарели, а вышли из моды. Потому как моду диктуют джуны и мидлы, где основной критерий — чтобы решение соответствовало их уровню понимания темы. Но уровень понимания любого айтишника растет вместе с эволюцией этого самого решения. И когда они вроде бы оба достигли состояния дзена, решение внезапно выходит из моды, и вытесняется очередным примитивным велосипедом, понятным вновь прибывшим в эту отрасль народного хозяйства.
У всех программистов есть свои идеи и своё видение(
У детей тоже есть свое видение мира. Красочное, интересное, но наивное. Но оно никак не поможет построить ракету.
Склад ума === навязывание образа мыслей.
Так кажется неопытным айтишникам, которые не доросли до уровня, при котором аргументы техлида для них становятся понятны. Кроме того есть такая вещь как интуиция — "мне не нравится это решение, и я предвижу кучу скрытых проблем, которые последуют за ним, перечислять и анализировать которые у меня нет желания и времени".
Человек, готовый принять на себя удар в случае неверного решения. Щит команды. С какой целью?
Хотя бы с целью, чтобы тебя в субботу полупьяного из клуба не достал звонок разгневанного клиента, невнятно орущего, что у него все лежит, и он теряет кучу денег ежеминутно (реальный случай). Человека, способного оперативно разобраться с проблемой и предпринять необходимые действия. А также недопустить, чтобы откровенная халтура проникла на прод. Иначе каждый из команды будет объяснять клиенту как "у вас на компьютере все работало" и "все тесты были зелеными".
Начните набирать/обучать активных джунов/мидлов.
И кто, простите, будет их обучать? Онлайн академия с недельными курсами? Или собственными силами, собирая все грабли в одном проекте?
После того, как предложили техлидом поставить чувака с 5!! Годами Опыта, дальше читать перестал.
Из-за того, что техлид не досмотрел теперь вся команда мучается!
Вот такие как автор ходят по проектам, год там, год тут, вчера он за ООП топил, сегодня за react hooks.
Техлид это человек, который закомичен в проект больше остальных технических специалистов и его задача думать на перспективу от года и далее. Конечно этого не понять людям, которые пришли в индустрию 3-5 лет назад, на все готовое…
К сожалению сегодня хайп и мода на технологии затмевает здравый смысл + синдром самозванца заставляет инженеров вставать в позицию защищающегося в страхе что его сейчас зашеймят, за то что он не знает зачем нужен Kubernetes…
У автора статьи есть потенциал стать хорошим технарем в будущем, но сейчас пока не хватает опыта.
TechLead — уходи