Рубрика: Разработчикам

Никто не умеет управлять программистами — и все придумывают костыли, вместо решений

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

Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется.

Читать дальше

А вы хороший руководитель?

1. Донесение своих мыслей и слов спокойно.
2. Прозрачное и понятное донесение своих мыслей.
3. Умение давать людям делать свою работу.
4. Умение слушать своих людей.
5. Умение управлять не жестко, а компетентно.
7. Принятие ответственности за результат работы команды.
8. Умение принимать решения и нести за них ответственность.
9. Понимание, что его задача нужна прежде всего ему, а не его подчиненным.

Читать дальше

Что делать, если в вашей команде появился «эффективный» менеджер?

ряд психологических лайфхаков, которые могут помочь сохранить нервы при работе с “эффективным” менеджером:

Сохраняйте доброжелательность, в данный момент они тоже часть команды.
Презентуйте и подводите “руководителей” к нужным решениям, как будто это их идеи. Покажите, что они нужны и вносят ценный вклад в развитие продукта.
Рассказывайте о достижениях, результатах работ и планах на следующий этап. Создавайте видимость, что “эффективные” менеджеры полностью контролируют процесс разработки и при желании могут на него повлиять.
Постройте канал общения с “эффективными” менеджерами — отдавайте ту информацию, которую они хотят получить, без вреда для основных процессов.

Читать дальше

разрабы и студенты заипали

Не, я все понимаю. Такой рынок. Разработчиков нужно больше, чем их есть. И уже они устраивают собеседования работодателям, а не наоборот. И я дипломатично лавирую между интересами заказчиков и разработчиков. Ибо заказчиков не ебет. Им нужен результат, с качеством и в срок. И их даже близко не ебет, что кто-то там почему-то чего-то не сделал. При этом разработчики тоже жгут: NDA мы подписывать не хотим, эта тематика нам не нравится, тут слишком давят, там слишком не понятны перспективы проекта. Сроки, порой, вообще не про них. Съезжают с темы. И у меня уже голова пухнет. Мне отвечать перед заказчиком, а они сваливают и ищи свищи потом.

Читать дальше

Хорошие программисты пишут код, лучшие — тикеты

хорошие программисты пишут код, но лучшие пишут тикеты. Код написать проще, чем хороший тикет — это хорошее объяснение, почему этот код нужно сделать. Поэтому если вы хотите развиваться и поднимать свой уровень, то фокусируйтесь на способности объяснить другому программисту, что нужно сделать, и умению выслушать клиента или заказчика и перевести его мысли в тикеты.

Читать дальше

8 шишек, которые я набил, управляя удаленной командой

1. Не все слышат / читают то, что я пишу. Многие слышат / читают то, что хотят прочитать
2. Мало кто способен к самоорганизаци
3. Сорок джуниоров не то же самое, что сорок миддлов
4. Отсутствие лояльности
5. Бесконтрольность
6. У всех разная мотивация
7. Работа в разных часовых поясах
8. Невовремя заданные вопросы

Читать дальше

Монолит vs микросервис – эмпирическая диаграмма

Согласен

modules-or-microservices-45-638

Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
Martin Fowler

Using the microservice architecture makes it much more difficult to iterate rapidly.
A startup should almost certainly begin with a monolithic application.
Chris Richardson

Как закаляется сталь

И, вот, ты остался один. Тебе не с кем посоветоваться по проблемам, которые тебе волнуют. Нет, конечно, ты можешь о чём-то поговорить с другими одиночками, они даже попробуют тебе чем-то помочь, но по факту – ты один на один с твоей областью проблем.

Читать дальше

Опыт тимлида: 17 советов самому себе на будущее

1. Все начинается с требований
2. Планируй техническую часть
3. Твои планы не высечены в камне
4. Убедись, что все понимают план
5. Минимизируй зависимость от других людей (отделов)
6. Приложи дополнительные усилия, чтобы разделить задачи на части
7. Всегда будь как минимум на шаг впереди
8. Следи за тем, чтобы собрания не уклонялись от темы
9. Командная культура важна, и ты играешь важную роль в ее создании
10. Проводи личные встречи
11. Делегируй полномочия и доверяй людям
12. Будь тем, кто расчищает путь
12+1. Не пытайся геройствовать
13. Сначала слушай других. Свои идеи высказывай в конце
14. Откажись от подхода «Сделаем это позже». Скорее всего, не сделаете.
15. Знай, что нужно тестировать
16. Используй парное программирование как способ распространения знаний
17. Меньше обещай, делай – больше

Читать дальше

20 вещей, которые я вынес за 20 лет в программировании

– Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции
– Вы пишите код не для машин.
– Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
– Хороший код не требует документации, но отличный код задокументирован по определению.
– Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи.

Читать дальше

Почему шансы на найм у кандидата с 5+ лет опыта ниже, чем 2+?

ПМ, который нанял в команду 10 джунов по 500 баксов, а клиент платит за них по 20 баксов в час — дает компании 80% прибыли! А тот, кто нанял 10 синьоров за 4К баксов и продал клиенту по 50 баксов в час — только 50%

Читать дальше

Программирование — не тяжелый физический труд, но все равно отстой

Вы полностью компетентны, и все хорошо, и вдруг все ломается.

«Шо за нах?» — восклицаете вы и начинаете отлавливать проблему. Выясняется, что однажды один идиот решил, что раз другой идиот решил, что 1/0 равно бесконечности, он может использовать это как условное обозначение для «бесконечности» для упрощения своего кода. Затем не-идиот справедливо решил, что это идиотизм, то, что должен был решить первый идиот, но поскольку он этого не сделал, не-идиот решил стать козлом и сделать это ошибкой компиляции. Затем он решил никому не говорить, что это ошибка, потому что он козел, и теперь все ваши снежинки — моча, а вы даже не можете найти кошку.

Читать дальше

Мысли по ходу

Фиксинг багов требует бОльшей квалификации чем написание нового кода, или костылей поверх бага

Как малоэффективна компенсация низкой квалификации персонала бюрократией, так и правила разработки, архитектура проекта – не могут уберечь код проекта от разного вида прилепленной скотчем копипасты. Люди в обоих случаях – Люди и взаимодействие важнее процессов и инструментов. В прямом, а не аджайл смысле, потому что:

Аджайл как руководство к действию воспринимается чаще как всего как “Ура! Не надо думать, пишем код чтобы закрыть тикет! И побыстрее, а думать – это долго и сложно”

Тимлид – это сержант

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

Читать дальше