Чудес не бывает или я ошибаюсь?

Митоз клетки команды Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд.  Иногда это происходит "органически" - в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее - продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым.  Я наблюдал 3 варианта "рождения" новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего): - команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под "многокомандность" и новая команда - это лишь еще одна шестеренка в настро

Возрастной философии твиттер-тред , который я решил переложить в статью, заодно попытавшись поправить правописание. Ну и ссылку на заметку сейчас удобнее отправлять, чем ссылку на твиттер. А желание ее кому-нибудь отправить по-прежнему иногда возникает.   Уже даже не помню, чем было навеяно. В лучших традициях твиттерского жанра "дед ноет". Все как положено: нытье, без конкретных примеров действий и противодействий.  Где-то плюс/минус несколько дней в это время 20 лет назад (тред писался в феврале 2021) заканчивалась моя военная служба и я уже официально (а не в самоволку, как было несколько месяцев до этого) ходил писать новые компоненты для Delphi-библиотек. С тех пор много чего (все?) поменялось в IT-отрасли, но речь сегодня пойдет не про технику.  А будет про людей. Даже скорее про конкретного человека в моем лице, как и что менялось во мне за эти 20 лет, отношение к возрасту, возрастные фобии если хотите :) После увольнения, наверное около 10 лет кряду, возраст коллег не

На базе треда в тви. Признаться, я давно не провожу "каноничные" 1:1.  В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии. А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени.  Ну или просто терпения не хватает дождаться реальной пользы. Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю. Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить: 1.  Вопросы для первой встречи  2. Хорошая замена традиционного вопроса " How's everything going?" -> "What's one thing that could be bett

 Про то, что менеджмент  - это не единственный путь развития :)

Есть тред в твиттере, но пусть тут для удобства тоже будет. Книги большей частью достаточно "возрастные", у некоторых есть свежие переиздания, где добавлены "свежие" темы, типа мобилок и тп. Из-за "возраста" сравнительно легко ищутся не только в магазинах. Вводная по "разработческому" тестированию Про тестирование обзорно для разработчика Developer Testing The Art of Unit Testing (лучшая, на мой взгляд, книга по юнит-тестам) С примерами на С#   С примерами на JS   Применимо и к другим языкам Паттерны для хороших тестов (практически любых) xUnit Test Patterns: Refactoring Test Code (есть книга) То, что мало кто из тестировщиков читал: Теория тестирования Lessons Learned in Software Testing: A Context-Driven Approach Букварь по тест-дизайну A Practitioner's Guide to Software Test Design Гибрид двух предыдущих Software Testing and Analysis: Process, Principles and Techniques: Process, Principles, and Techniques Еще один гибрид The Art of Softw

Лет 5 назад наваял на коленке для рассказа разработчикам про тестирование в команде без тестировщиков. Что такое качество? С точки зрения пользователя: Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно. С точки зрения разработчика: Качество — это соответствие специфицированным и собранным требованиям. Делает ли данный продукт все то, что указано в требованиях.

Часто мимо пролетают вопросы "как начать с IT с нулевого уровня", "как понять, что IT мое". Отвечая, собрал набор ссылок. Кого я обманываю, просто собирал, потому что люблю собирать полезные штуки. Но некоторым действительно уже помогло :) Ссылки с упором на backend-разработку с нуля. По тестированию ищите тут Начало Введение в программирование Жизнь программиста Введение в Git Основы командной строки Как решать задачу, если непонятно с чего начать (Хекслет) Планы развития Developer Roadmaps (тут не только бек, там много) Oh My BackEnd ------ Основы Python (там еще и Java есть) Python: Основы программирования ------ Неплохой ресурс про IT, но уже на английском freeCodeCamp ( https://www.youtube.com/freecodecamp ) ------ Алгоритмы и структуры данных (английский) Algorithms Specialization Data Structures and Algorithms Specialization Аналоги на русском Алгоритмы: теория и практика. Методы Алгоритмы: теория и практика. Структуры данных Разбор задач LeetCode и вопрос