Чалдини + Crossing the Chasm + Дилемма инноватора + Как пасти котов – это программа-минимум по моему мнению. Читал, перечитывал, знаю, уважаю, пробовал, работает, воспроизводимо. Если я вижу подборку, которая расширяет этот набор – мне это интересно. Личное мнение. Про архитектуры я бы рекомендовал другое чтение, но это тоже личное мнение.
Также вы узнаете, чем отличаются разработчики, использующие методологию Scrum, от других
Хорошо, что agile/scrum хайп прошёл, и люди поняли в общем, что утренние планёрки проводили и в 60-е годы в НИИ и КБ, а coach для этого не нужен (особенно если вместе собрались зрелые люди, получающие удовольствие от своего труда, и им понятны цели бизнеса). Книгу по скрам имеет смысл читать for reference. В целом отличная подборка, спасибо!
Статьи по Cache на хабре всегда интересны, но складывается такое впечатление – требуется весьма низкоуровневое понимание этой технологии, чтобы эффективно с ней работать. Может быть я не так понимаю нишу этой технологии?
Теоретически бывают такие bread-and-butter / getting-things-done области разработки, где программа просто-таки ложится в переданное описание функционала. В области mission-critical / line-of-business приложений таких ситуаций значительно меньше. В современном мире, мне кажется, неизвестных столько, что проще начать разработку по минимальному черновику и корректировать ход в процессе, нежели потратить сотни страниц, которые потом всё равно придётся корректировать, т.к. они были построены из слегка не тех предположений.
Печально, что современному разработчику, пользующемуся, на минуточку, реляционной базой данных, вот так вот на пальцах приходится разъяснять про алгоритмическую сложность сортировки слиянием. Это почти что макака с гранатой, что и подтверждается практикой. Вроде бы и пользуются базой данных, да не очень. Выходит сплошной mongodb-is-web-scale.com.
Технология замечательная, давно присматриваемся для клиентов. Есть ли практические замеры, например в случае с репликацией снапшотов и лог-записей disk-based и in-memory баз данных? Понятно, что для SQL Server есть более специализированное решение по репликации и failover, но всё же Storage Replica как-то более commodity в этом плане, и является failover для целого приложения, а не только базы данных, что принципиально.
> У нас всё строго наоборот- если ты менеджер проекта, то ты делаешь всё: контролируешь закупщиков, контролируешь поставщиков, общаешься с заказчиком, разрабатываешь детали, измеряешь размеры деталей, собираешь прототипы, обсуждаешь производство оснастки, собираешь образцы, решаешь проблемы и т.д. Делать надо всё. По нескольким проектам одновременно.
Кстати, вот замечание по этому поводу – англосаксонская vs постсоветская.
Есть чудная книжка, в оригинале она называется:
THE PRIMES: HOW ANY GROUP CAN SOLVE ANY PROBLEM
А на русский перевели:
ИСКУССТВО УПРАВЛЯТЬ: 46 КЛЮЧЕВЫХ ПРИНЦИПОВ И ИНСТРУМЕНТОВ РУКОВОДИТЕЛЯ
По-моему, сразу всё понятно. Но а дальше всё зависит от вас. В Европе я встречал ИТ-компании, построенные по постсоветской модели. В России – англосаксонские модели компаний. Всё относительно и зависит от ваших намерений. Для меня «руководитель» – это «leader», а не «manager». То есть руководитель не говорит «что делать», а слушает, наставляет и объясняет «почему делать».
В РФ мне удалось быть со-строителем компании именно на таких принципах. При должном уровне барьера от более постсоветских партнеров всё строится и работает великолепно и долгоиграючи. Главное – это нанимать людей с таким же видением и менталитетом. Не садящихся на шею уродцев и «тыжменеджер»-ов. Людей ты нанимаешь не для того, чтобы говорить им, что делать, но для того, чтобы они тебе говорили, что надо сделать в компании для её оптимального развития, и делали. А на людей иной закваски всегда найдётся N+1 постсоветская вакансия.
На мой взгляд «промежуточный язык» режет. Многим нравится читать книги в русском переводе, как и мне, но я верю что для этих людей частота употребления «промежуточный язык» в ежедневной работе равна нулю. Лучше уж тогда IL.
Хорошо, что agile/scrum хайп прошёл, и люди поняли в общем, что утренние планёрки проводили и в 60-е годы в НИИ и КБ, а coach для этого не нужен (особенно если вместе собрались зрелые люди, получающие удовольствие от своего труда, и им понятны цели бизнеса). Книгу по скрам имеет смысл читать for reference. В целом отличная подборка, спасибо!
Эдакий «тыжменеджер», крайний товарищ-стахановец. Типично-постсоветское.
:( Питер, ребята, ну как же.
Есть чудная книжка, в оригинале она называется:
THE PRIMES: HOW ANY GROUP CAN SOLVE ANY PROBLEM
А на русский перевели:
ИСКУССТВО УПРАВЛЯТЬ: 46 КЛЮЧЕВЫХ ПРИНЦИПОВ И ИНСТРУМЕНТОВ РУКОВОДИТЕЛЯ
По-моему, сразу всё понятно. Но а дальше всё зависит от вас. В Европе я встречал ИТ-компании, построенные по постсоветской модели. В России – англосаксонские модели компаний. Всё относительно и зависит от ваших намерений. Для меня «руководитель» – это «leader», а не «manager». То есть руководитель не говорит «что делать», а слушает, наставляет и объясняет «почему делать».