Программист
В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает.
Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc
Однако я уверен, что есть такие люди, которым не хочется 2 часа смотреть вебинар, а хочется за 15 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде на то, что он найдет своего заинтересованного читателя.
Общий стаж моей работы в ИТ - около 14 лет. Я начинал с системного администрирования, потом перешел в разработку, поработав как в аутсорсе, так и в продукте. Не один раз проходил путь от рядового разработчика до тимлида.
Всем привет! В последнее время я вплотную занимаюсь исследованием возможностей systemd и решил поделиться результатом исследований с сообществом, в виде небольшого (или большого, как пойдёт ;-) цикла статей. Итак первым номером нашей программы будет запуск юнитов по различным событиям происходящим во время работы ОС. В качестве исследовательской платформы будет выступать Manjaro Linux c systemd v247.2. И... да. Некоторые события, вынудили меня написать внеочередную статью, которая «взлетела на вершину хит-парада», а опрос показал, что тема актуальна и вызывает интерес, так что погнали!
Статей о TDD достаточно много, и я обратил внимание на то, что все они затрагивают преимущественно техническую составляющую этого подхода, и практически никак не описывают ментальные принципы, лежащие в основе TDD.
Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.
В статье речь пойдет о неких абстракциях, которые применимы на разных слоях мировоззрения и, вне зависимости от контекста, помогают достигать хорошего результата. Универсальность этих абстракций и факт, что они применимы даже к процессу написания кода, сделали меня ярым приверженцем как TDD подхода, так и этих абстракций.
Как проверить себя на эффект Даннинга-Крюгера, и преодолеть его?
Итак вы захотели оценить положение дел в команде. Оказались только что назначенным лидом или выдохнули после первого сданного проекта, который сделали не только собственными руками. Прежде чем бросаться за новый проект, задумались:
Теперь продукт работы, как тимлида – больше не только код, не количество закрытых задач в срок и даже не изящность или скорость решений.
Представьте игру, в которой выполняются простые правила:
1. На плоскости проведены несколько линий, каждая пара линий пересекается в одной точке.
2. Линии разбивают плоскость на области, раскрашенные в шахматном порядке.
3. Вы можете перестраивать разбиение, «схлопывая» и «выворачивая» треугольники.
4. Ваша цель – получить максимально возможное количество темных областей.
Я уже запрограммировал браузерную игрушку по этим правилам. Под катом – гифка прохождения для 5 линий, личный опыт игры и краткое описание математики в основе головоломки.
В недавнем выпуске подкаста DotNet & More мы обсуждали полезные материалы для тимлидов и всплыла классическая проблема: как совмещать управление командой и написание кода. Этой осенью я рассказывал о лайвхаках, которые помогают мне продолжать программировать на позиции лида и мне показалось полезным, в этом контексте, выложить текстовую расшифровку доклада.
Мало кто хочет брать джуниор-разработчиков в трещащий по швам проект. Однако берут. И я заметил, что есть компании, в которых боятся брать сеньоров. Компания предпочтет взять нескольких джуниоров вместо одного сеньора. Мысль взять одного сеньора вместо мидлов или джуниоров, можно сказать, даже и не рассматривается.
Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте.
За 15 лет работы разработчиком я обнаружил, что ложные убеждения о человеческой природе — основные враги хорошей декомпозиции. Если знать о них и стремиться не угодить к ним в ловушку, со временем можно сформулировать советы по созданию качественной декомпозиции. Так произошло со мной, и я спешу поделиться этим знанием.
