Про внезапное архитектурно-софтскиловое
В последнее время энергия писателя уходит в подготовку новых лекций и нескольких выступлений на TeamLead Conf (программа готова, получилось отлично https://teamleadconf.ru/spb/2025/schedule), поэтому пишу мало (отмазался, типа). Но если без шуток, никогда бы не подумал, что ограничения мозга в части производительной составляющей имеют на столько четкие границы. При этом читать получается и много, чем я и занимаюсь последние пару месяцев. Про наиболее яркие труды дальше.
Вернулся к технической литературе, почти осилил (и даже программировал немного с ИИ в напарниках) «Apache Kafka» от Орейли, потому что кругом внезапно случилась кафка головного мозга. В целом откуда растут ноги — понятно — удобный инструмент, хорошая надежность, хорошая масштабируемость, позволяет замещать огромную кучу косяков в разработке других узлов. Но в моем случае — тот вариант, когда речь идет о нездоровом применении инструмента. Не можешь сделать надежную и доступную систему — воткни кафку, не можешь добиться хорошей производительности на многопоточных запросах — воткни кафку, и т.д. При этом решение принимается мгновенно и без попыток исправить что-то и обойтись без лишнего узла. Книжка норм, кто кафку гоняет — обязательно почитайте, ключевые идеи и возможности описаны хорошо, хотя по традиции воды тоже хватает. Свои инструменты надо знать очень хорошо.
Следом пошла «Фундаментальный подход к программной архитектуре» от того же Орейли. Интерес вызвала примерно по той же самой причине — я давно в ойти и систем видел немало, но вдруг что-то пропустил. Более того, стали делать много новых конструкций с ранее не применявшимися бизнес-процессами. Архитектор во мне давненько не брал шашки в руки, поэтому решил себе напомнить про паттерны, свойства, подходы и пр, чтобы не развивать ту самую кафку головного мозга. Особый интерес в этом труде вызвала Часть третья, которая посвящена совсем не типичной информацией для архитекторов — софтскилам. Неплохо описана значимость умения создавать презентации и демонстрировать свои решения команде. А дальше «Эффективная команда» — глава про личные качества, про влияние на команду, про различные варианты контроля, «Навыки лидерства и ведение переговоров» — глава не только про переговоры, но и про фасилитацию, про роль лидера и взаимодействие с командой. Согласно авторам архитектор должен быть прокачан по софтам не меньше, чем тимлид или любой другой руководитель. Вот это да, подумал я, а все ли архитекторы знают про это? И ответ не заставил себя долго ждать. Какие софт-скилы? Вот вам решение — делайте. Не можете? — Страдайте. И вообще моя борода бородее вашей. В общем даже если считаете, что можете выбрать какой архитектурный паттерн выбрать для решения своей задачи, обязательно инвестируйте несколько сотен рублей и пару часов в чтение этой части. В моем мире я таких ребят встречал штучно. В основном взаимодействие архитекторов и разработки с эксплуатацией — боль.
Чтобы закрепить взялся еще за «Современный подход к программной архитектуре» от той же Орейли, она прям инженерная и про принципы и подходы. Осилил пока лишь часть, выглядит, что принципиально нового ничего не изобрели, но очень полезно взбодрить все это в памяти.
Отдельно отмечу труд Елены Тихомировой — «Обучение со смыслом». Очень удачное приобретение, опытный практик, куча важных и полезных мыслей. И совсем не про андрогогику, а про вполне себе понятные Если имеете отношение к обучению взрослых и созданию курсов — обязательно ознакомьтесь.
Книжка с загадочным названием «Изменить других можно» г-на Брегмана внутри оказалась очень годным набором советов, как находить общий язык с окружающими и помогать им решать задачи и развиваться.