Wiki Category: Дао

Восходящая разработка, или аджайл в действительности

Спустя каких-то 10-15 лет авторы “Манифеста аджайла” начали бить в набат: “Ребята, что вы делаете, мы имели в виду другое”. Они в чем-то правы, восходящая разработка так проста и тем притягательна, что все эти дополнительные процедуры кажутся необязательными.

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

Об архитекторе (и архитектуре)

*Архитектура* – это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему. …
Архитектор несет непосредственную личную ответственность не “за систему”, а за продуктивность всех членов команды в их повседневной работе.

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

Про влияние удаленки на проектные команды во времена COVID-а

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

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

Разработка продукта НАЧИНАЕТСЯ с выхода в продакшен.

Только с выхода в продакшен вы встречаетесь с реальными задачами бизнеса, а не с тем что вам напели так называемые бизнес-пользователи и как мог записал ваш аналитик. Только там вы встретитесь с реальными трудностями, реальными объёмами, реальными скоростями разработки смежных команд, реальными жалобами клиентов.

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

Подлинное самообучение

Довольно быстро я обнаружил, что ссылки кольцевые. В словаре было примерно шесть статей, циклически ссылающихся друг на друга. Они все были написаны птичьим языком. И не понятно было ровным счетом нихуя, то есть совсем. От безысходности и отчаяния, я начал читать их по кругу.

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

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

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

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

Хотите стать разработчиком? 10 признаков того, что вам не стоит идти в профессию ни при каких условиях

Отсутствие любознательности
Отсутствие автономности и находчивости
Отсутствие настойчивости в решении проблемы
Отсутствие радости при преодолении трудностей
Нетерпение в обучении
Ощущение скуки или усталости от мыслей
Неспособность к самостоятельному мышлению
Узкое, ригидное и хаотичное мышление
Желание получить «правильный» ответ, когда есть «хорошие» и «плохие» ответы
Неумение обращать внимание на детали

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

Про разработку програм и продуктов

Отлично сказано!

Я тут может очевидное кому-то скажу, а кому-то может неочевидное.

Часто бывают программеры, которые типа “на проекте был бардак – ни четких ТЗ, ни куда гребем непонятно”. Это от непонимания, что никто никогда не знает зачем ПО вообще делают, и куда дорога вывезет. За редкими исключениями.

Давайте от противного. Вот есть, условно, MS Word. Туда никаких фичей, кроме текущих – и не надо. Да и тех что есть – можно выкосить половину. Можно ли сделать точно также? Да, думаю где-то за 100M баксов – вполне. Что копейки по сравнению с продажами. Можно ли достать 100 лямов, переписать Word – и зарабатывать как MS? Неа. Потому что срать будет всем на ваш новый Word. Чтобы стать продуктом, Office-у пришлось прожить с людьми десятилетия, делать фичи типа “радужный 3D-текст Comic Sans-ом с тенью” – потому что тогда это было модно. А потом – поддерживать эти фичи. Учить поколения людей форматировать пробелами. И так, не мытьем, но катаньем, они захватили рынок.

Сложность и сила ПО – не в текущем его наборе фич, а в возможности его постоянно менять. А талант программиста – не в том чтобы по спеке сделать с тестами. Он про то, чтобы предсказать куда дует ветер, и про вычленить те кусочки, которые скорее всего пригодятся – когда надо будет разобрать и собрать всё заново. Или понять что хер угадаешь куда вывезет, и просто писать код быстро, просто и без ошибок. А как поменялось – стирать и переписывать.

Сам код – вообще имеет отрицательную ценность – чем его больше, тем хуже, если ценность продукта постоянна.

Технический долг на проекте

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

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

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

С программным обеспечением всегда так. На поверхности кажется, что мы делаем простые штуки. Но на самом деле — оно невероятно сложное. Проблема в том, что сложность станет видна, только когда ты погрузишься во все технические нюансы.

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

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

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

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

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

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

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

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