Январь. Боль тимлида. Резюме.
С новым годом! Пусть растёт, что должно расти, и не растёт, что не должно.
1.01
Наступил новый год. Вышло краткое содержание за декабрь. https://teletype.in/@dumtest/Hyw3Nj_yL
Обсудили советские новогодние фильмы. Правда очень скромно. Оно и понятно, оливье ещё не весь съеден.
Немного по традиции поговорили про образование и сертификацию. Но всё-таки оливье.
Сейчас школа вообще мрак
2.01
Полезного за день:
"Однажды русская и немецкая компании договорились провести совместные соревнования по гребле на восьмиместных байдарках.
Обе команды долго и упорно тренировались и когда обе были на пике формы, устроили соревнования, но... Немцы победили с преимуществом в 1 км. После поражения русская команда была деморализована. Топ-менеджмент решил выяснить причину провала.
Была создана рабочая группа для подготовки предложений по изменению и реструктуризации в команде. После многих недель изысканий было установлено, что в немецкой команде гребли семеро и один рулевой... а в русской - один на веслах и семеро рулевых!
Топ-менеджментом русской компании была привлечена консалтинговая компания для подготовки и проведения реструктуризации команды. Получив солидный гонорар и внедрив показатели KPI, ССП и ISO 9001 и проведя маркетинговые исследования, консалтинговая фирма пришла к выводу: Слишком много сотрудников в русской команде подает команды и слишком мало гребет....
После реструктуризации русская команда выглядела так:
- четыре рулевых...
- два старших рулевых,
- один рулевой директор,
- и один гребец.
Кроме того для гребца была введена персональная система оценки показателей эффективности и расширен круг обязанностей, чтобы повысить его ответственность.
На следующий год немецкая команда опять убедительно победила с отрывом в 2 км. В результате очередного поражения, топ-менеджментом русской компании была нанята консалтинговая компания по аудиту и оценке эффективности команды.
Было принято решение расформировать гребную команду... Гребец, как основной виновник неэффективности команды был уволен, все плановые инвестиции на 2019-2020 годы в новую лодку и весла были отменены. Рулевым была объявлена благодарность, а сэкономленные деньги были выплачены топ-менеджменту в качестве премии."
Вот вам пример непозитивного менеджмента 🤗.
3.01
Обсудили анекдот.
А неугомонный Сергей Мазур подогнал новый ролик:
Вот я и подготовил 20ое занятие на тему "Team Management". Естественно я не пытаюсь раскрыть всю тему за 35 минут, но как обычно даю кучу наводок, ссылок и зацепок в какую сторону копать.
https://youtu.be/tzZQvx6aE3g
План занятия:
1. Группа или команда?
2. Распределение обязанностей и ответственности в команде
3. Ментор или коуч?
4. Характеристика команды и ее членов
5. Вопросы-ответы
Все как было бесплатно, без регистрации и подобного
4.01
Вспомнили Джобса и Якокку. Рустам погрустил, что в чатике всё ещё не 3000.
5.01
День тишины.
6.01
День тишины.
7.01
День тишины.
8.01
Рустам всё ещё грустит, что не 3000.
9.01
Всё ещё грустим, что не 3000.
Лучше бы поделились каким-нибудь годным чтивом, которым развлекали себя в выходные. Наверняка не только оливьешечку с коньяком кушали:₽
https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/ нашел для себя причину не любить скрам
Вастрика читал (https://vas3k.ru/)
Документацию к микротику
А Витя играл в приставку. Обсудили слегка игры.
блин вы че тут флудильню устроили. Давайте че нить тимлидское обсуждайте
Но всё-равно продолжили обсуждать игры.
Про лазертаг и сотрудников https://thedailywtf.com/articles/Anything-You-Can-Do-Lyle-Can-Do-Better
https://thedailywtf.com/articles/Special-Delivery - какая-то ссылка. Я не осилил, но просили сохранять ссылки:)
10.01
Этот день можно считать началом обсуждения статей на хабре. Дальше их будет много.
От Вити Каша на завтрак https://m.habr.com/ru/company/lanit/blog/481584/
Управляя коллективом, нарушьте все правила.
Если ответы на эти вопросы вас интересуют, то вам стоит почитать книгу Маркуса Бакингема и Курта Коффмана «Сначала нарушьте все правила: Что лучшие в мире менеджеры делают по-другому». Эта книга могла бы стать для меня настольной, но перечитывать нет времени, поэтому я сделал выжимку, которой и хочу с вами поделиться.
Вот про чтение хорошее https://pedsovet.org/beta/article/umenie-citat
Решили считать число чатлан в римской нотации.
Вот мы тут цифры в буквы складываем, а тем временем https://www.kommersant.ru/doc/4215723 - Чувак из WoT организует партию в России.
Обсудили это дело.
Ну почему в Jira за чуть ли не 20 лет так и не сделали подзапросов, ну хоть самых примитивных? Ну каким местом там вообще думают продакты?
Риторический вопрос, но решили, а чего бы не обсудить Джиру. Обсуждать джиру - это круто:)
Ну, вот я и говорю, Jira - редкостное дерьмо.
Но на самом деле не такое уж и дерьмо:)
Раз в месяц, кмк, мы обсуждаем джиру:)
Как-то давно прочёл такую мысль: ЭВМ решают те проблемы и задачи, которых до появления ЭВМ просто не было.
Переложите это на джиру и вакансии и все станет ясно
Скажите есть хорошие статьи/руководства/наблюдение про то как работать с индусами? Теперь когда вы отсмеялись - речь не про удалённых индусов а здесь в EU, то есть они вполне себе, но всё же )
11.01
А чо там с моно, господа сишарперы?
Отгадайте с 3-х раз, как называется юрлицо, которое ищет backender на 80 тыс рублей?
Немного обсудили и то и другое. Но совсем немного.
Во, кстати. А есть ли тут, кто умеет скорочтение?
Обсудили и это. Мне обещали подогнать методички от древних скорочиталей. Говорят, что работают. Попробую - расскажу.
12.01
Продолжили за скорочтение, но не долго.
13.01
https://m.habr.com/ru/post/483592/
Я уже забыл, что там было. Автор скрыл публикацию. Вот всегда корю себя за то, что не пишу краткое содержание каждый день за прошедший день.
А вот пока писал-читал - вспомнил. Статья была про то, что разработчики зажрались, рынок перегрет и вот это всё. Что-то в статье было по делу, что-то не очень по делу.
На мой скромный взгляд вышеприведенная @vfabr статья пытается донести сказанное Виктором ранее (не буду говорить где именно). Автор уповает именно на то, что в современной IT-индустрии у разработчиков отсутствует достаточно экспертизы (или попросту не "созревает", ухватываясь то за одну технологию, то за другую), и в современных реалиях видно тенденцию, когда dev становится тимлидом или СТО слишком рано. Да, у него есть опыт в компании, который на взгляд вышестоящего руководства подходит под критерии тимлида/СТО, но на деле недостает экспертизы в том стеке, в котором он работает.
У меня даже есть знакомый, который сетует на то, что так называемых middle или senior приходится заставлять переучивать по причине, что они недостаточно хорошо понимают стек технологий, в котором они работают.
Очень разные позиции на этот счёт имеются. У нанимающих и у нанимаемых:) Что логично по сути. Но нужно смотреть с разных сторон конечно же.
В итоге плавно перешли на обсуждение, за что много платить это ок, а за что не ок. Сколько эту тему поднимаем, столько достаточно острых разговоров имеем. Также плавно перешли к обсуждению зон ответственности и полномочиям.
Добрый день! У кого как с оплатой труда тимлидов и веткой развития для них? Есть ли отдельные тимлидские грейды? Кто получает больше: тимлид или senior?
Начали обсуждать важную тимлидскую тему. В спорте тренер должен играть лучше всех, кто на поле играет?
Представили Тарасову, прыгующую аксель. Завораживает, наверняка. Жаль, давно не прыгает:)
Сколько бы не повторяли на коференциях банальную шутеечку про "взять хорошего девелопера и сделать из него хреновго менеджера" - слушатели похихикают, покивают головой, потом вренутся в свою контору и именно так и сделают всё-равно.
Обсудили воспитание джунов. Дорого это или не очень.
https://www.leaguenetwork.com/great-athletes-make-great-coaches/ тут из самой ссылки всё понятно
https://www.elitedaily.com/sports/amazing-athletes-flop-coaches/1339816 - и тут
Короче, чтобы стать плюс-минус компетентным менеджером, нужно проинвестировать только в чтение 3-4 тысячи часов. И это не считая практики НЕ ПРОГРАММИРОВАНИЯ.
Чтобы стать плюс-минус хорошим девелопером, примерно столько же нужно проинвестировать в чтение совсем другой литературы, и это не считая практики НЕ УПРАВЛЕНИЯ.
Что то, что это - это нагрузка примерно на 120% от рабочего времени. В сутках просто столько часов нет, чтобы из хорошего девелопера делать хорошего менеджера.
Что вы всё про спорт. Давайте лучше обсудим, должен ли дирижёр уметь играть на всех инструментах из оркестра. И, желательно, на уровне лауреата международных конкурсов - ведь ЕМУ ЖЕ НАДО СОБЕСЕДОВАТЬ!
https://www.ted.com/talks/itay_talgam_lead_like_the_great_conductors
Слегка прошлись по идее - не всё, что написано в книжках - хорошо и стоит сразу применять.
Можно стать хорошим менеджером если читать чатик тимлидов?
Господа менеджеры. Вброшу слегонца.
Мне тут сказали, что планирование по story-points это то-же самое, что планирование по нормо-часам, просто название более модное и скрам-покер сбоку прикрутить можно. Что считаете? Все действительно так или есть разительные отличия? Уверен, что @vfabr способен ответить на этот вопрос)
Нашли что и на это ответить:)
Витя: Мое мнение такое: в зависимости от контекста есть временной интервал в который можно запихнуть кусок работы, при этом этот кусок будет не большой и не маленький, а очень удобный. Нижнюю границу куска удобно взять за интервал временной, он и есть поинт. Поинт нельзя дробить, поэтому задачи не получается ставить очень мелкими. Поинт может быть и час и день, надо смотреть на специфику. Для программистов норм начинать с 4 часов.
Снова немного обсудили про оценки задач.
а кто скажет разнице между PO и PM?
Обсудили и это. Мы ж специалисты.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html - про сторипойнты в части оценок
Вообще много про оценки говорим. Такая тема.
Поискали рецепт хороших оценок. Нормально делай - нормально будет.
Про декомпозицию тоже поговорили.
https://system-school.timepad.ru/event/1231049/- - конфа по системному мышлению.
Очень долгий день.
14.01
Внезапно вернулись к обсуждению спортивных тренеров.
хватит флудить, давайте обсудим такое явление как забивание на техдолг в командах, разделяющих один и тот же проект)
Норм тема, но не взлетела почему-то.
Правда в итоге ушло всё опять в оценки и декомпозицию.
https://ronjeffries.com/categories/estimation/ - про оценки.
15.01
. Зачем вообще нужен скрам мастер?
Обсудили. Вспомнили про штатных психологов.
У меня вопрос есть. Он похож на риторический, но я бы хотел всё-таки получить на него как можно более точный ответ. Или отсылку к месту, где я могу такой ответ найти. Как отличить процесс от события? Вот интуитивно мне кажется, что код ревью - это процесс, и с ним необходимо работать как с процессом. Но обосновать я это не могу.
Тимлид, по моему мнению, это как раз такой социально-технических арбитр. Он настолько крут, что раздав все обязанности людям, следит за соблюдением правил и договоренностей и по факту просто решает, какие события соответствуют духу и букве правил. Т.е. не тимлид делает архитектуру, а следит, чтобы тот кто делает не нарушал договоренностей и архитектура соответствовала требованиям. Не управляет людьми, а следит за соблюдением всеми признанных процессов и правил. Не лечит людей в команде "психологически", а следит за соблюдением правил общежития и поддержанием культуры принятой в компании.
https://biz.mann-ivanov-ferber.ru/2018/06/05/kto-takoj-skram-master-i-chto-vxodit-v-ego-obyazannosti/ - кто такой скраммастер
Плотно про скраммастерам прошлись.
Возможно логика такова - если изначально команда настолько не взрослая, что им нужна нянька в виде скрам-мастера, то и ответсвенность им не нужна и даже вредна, ОНИЖЫДЕТИ!11
https://space.productsense.io/podcast/make-sense-75-o-menedzhmente-3-0-izmenenii-slozhnyh-sistem-i-upravlenii-lyudmi-s-antonom-zotinym - про менеджмент 3.0
https://habr.com/ru/post/484020/ в продолжении разговора о спринтах, сроках, сраках
Нее вот получче https://m.habr.com/ru/post/484008/ - что такое быть тимлидом
16.01
Продолжили обсуждать статьи. Прям зацепило.
https://habr.com/ru/post/484092/ - про "кое-как одетых принцев и дворян". Снова про разработчиков и баблосы.
Витя предложил искать когнитивные искажения у авторов таких статей.
Прочитал. Не думаю, что по данной статье модно сделать вывод о наличии/отсутствии у автора когнитивных искажений. Вероятно, он несколько преувеличивает количество людей которые способны начать собственное дело, но не делают это в силу каких-то причин (как объективных, так и нет).
Внезапно переключились на юниттесты. А потом обратно.
Обязательная функция тимлида решать проблемы команды, чтобы команда и компания работали как часы. Но тимлид тоже человек и его часы иногда сбоят: недосып, болезни, выгорание, хандра, а сроки горят, задачи копятся, возникают конфликты. Как восстановить энергию, гормональный фон, перестать конфликтовать, понять себя и окружающих в кратком курсе психологии от Андрея Макарова.
https://habr.com/ru/company/oleg-bunin/blog/473440/
А потом опять на юниттесты.
Ребята, подскажите как один репозитории на 5 поделить, алгоритм действий, чтобы не накосячить. Один за одним лучше делать, и код в старом удалять сразу?
Накидали вариантов.
Надо просто взять и попробовать поделить, при этом никак не воздействуя на текущий репозиторий
я бы склонировал репу 5 раз, а потом в каждой копии отрезал лишнее :)
17.01
Нашёл побольше https://felixit.blog/2018/08/16/elita/ - всё в ту же калитку про разработчиков зажравшихся.
https://m.habr.com/ru/company/parallels/blog/484160/ добью вас танцем - почему Россия теряет ИТ-специалистов.
Обсудили пару статей
Насколько, по вашему мнению, полезно иметь программисту и его производным литературную культуру? Стихи там, переживания героя? Может ли быть это полезно в работе?
В блоге codinghorror.com Джеффа Этвуда, ко-фаундера стэковерфло, можно найти немало статей с "writing" в названии:
Coding: It's just writing
Is writing more important than programming
How to write without writing
И тд.
В книге "Веревка достаточной длины, чтобы выстрелить себе в ногу" упоминается исследование, которое показало, что программы студентов филологического факультета легче читать и они более ясно структурированы по сравнению с работами студентов Computer Science направления.
писать красиво и писать красиво код это немножко разные вещи)
Всплыли результаты встречи СТО в Скаенге в конце прошлого года. Немного про это поговорили.
18.01
Всем привет. Мне помнилось тут был кто-то с авито?
И правда, был.
19.01
А есть у кого позитивный опыт внедрения OKR в небольшой компании с точки зрения рядового сотрудника?
Негативный есть
20.01
Нет :) Хочется понимать чего ждать и как я, как рядовой сотрудник, могу постараться помочь своему лиду и при этом не послать все к черту через месяц 🙃 - это всё про ОКР
У нас главной проблемой было то, что целью ставилось то, что не в силах было быть решено одним человеком/командой. В итоге либо фальшивая цель, к которой все, включая офис менеджера, примазаны, либо глубоко демотивирующая недостижимая фигня
Спасибо, кажется, что с завязкой на материальнуб составляющую проблемы быть не должно - у нас нет премий в принципе, только оклады. Остается верить, что не привяжут к этому различные повышения. Про цели понял, спасибо.
В переводе книги "THE BEGINNER'S GUIDE TO" Felipe Castro (https://scrumtrek.ru/blog/the-beginners-guide-to-okr-1/), предлагается на первое время ставить цели на 100% достижимые, чтобы привыкнуть немного жить с OKR, не практиковали такое?
Поговорили много про ОКР. Как обычно. Ибо не первый раз:)
Очень плотно обсуждали ОКР. Тут надо читать. Слишком много тредов и мыслей.
https://medium.com/@leematos/why-you-shouldnt-use-okrs-6c52a7bb8702 из заголовка понятно, ага
кстати, вот недурно, кмк. https://habr.com/ru/post/484590/ про то, как правильно ставить планку качества собственной работы - чтобы пацанам было не стыдно показать.
21.01
https://m.habr.com/ru/post/484646/
Разыскивается раб лампы. А потом по совету таких джинов, начинаются "улучшения" - как девочка искала IT-волшебника.
Обсудили статью. Есть здравые мысли, но и нездравые тоже есть. Впрочем, как всегда.
Работодатель, который будет в вакансии доносить 3 простых месседжа:
- мы не жадные
- мы не мудаки
- у нас нет херни
порвёт рынок труда
Опять поговорили про рынок, найм и позиционирование. С этого момента начали говорить про именование веток в репозиториях.
22.01
Добрый день, коллеги. Подскажите, пожалуйста, как лучше всего организовать стейджинг, когда нельзя допускать чтобы работа тестировщика влияла на процессы в боевой системе, а также в стейджинге нужны максимально актуальные данные (с допустимым запозданием минут в 10)? Кроме того, структура базы данных на стейджинге может быть более новая, чем на проде, и может быть даже без обратной совместимости (например, на стейджинге уже применены новые миграции, которые меняют данные, а на проде ещё старая схема БД).
Обсудили. Но так себе. На самом деле - это вечная проблема. Как сделать нормальный стейджинг. Каждый кривляется по своему.
Всем массовый привет!
Подскажите пожалуйста, мы хотим на уровне компании (IT-компания 150 человек) внедрить какую-то общую систему для управления проектами, кто какие системы использует для этих целей?
У Олега всегда есть рецепт:
Просто сделайте всё не как у вас сейчас, а с точностью до наоборот, то есть в соответствии с лучшими (да и просто разумными) практиками.
Годами из чата в чат кочуют одни и те же вопросы, от людей, которые сговорились никогда в жизни не покупать книжку про https://databaserefactoring.com/ - это к первому вопросу.
В вопросе про "систему управления" оказался спрятан совсем другой вопрос - "как кто пробовал", потому что хочется сравнить. Полдня ушло на то, чтобы выяснить, что вопрос на самом деле другой.
У кого есть джира, поделитесь скриншотом странички, на которую можно посмотреть и сразу видно, кто из 25 команд/тимлидов молодец, а кто нет...
Снова джира, ага.
И снова про декомпозицию и обмен мнениями, как таски заводить, чтобы всё было видно.
23.01
Лучше иметь плоскую команду квалифицированных девелоперов, которым хороший инструмент не даст игнорировать архитектурные аспекты, чем иерархию из главных архитекторов, не главных, продактов и техлидов, которые в конфлю это пытаются из спейса в спейс переложить.
А девелоперам в половину спейсов может даже доступ закрыт при этом.
Не отпускают нас трекеры и всякие джиры. И конфлюенсы и пр.
Code-review, Design-review.
Местами грубо про Аджайл, про флоу тасок.
Нарисуйте на бумажке вашу систему и ретроспективно по ней прогоните все фейлы за последние полгода. И подумайте, где можно было бы их с большей вероятностью вернуть в начале, где задачи бы либо умерли, либо видоизменились
Вспомнили ответственность, архитектурные комитеты, групповое принятие решений. Кучу всего в одну кучу.
И снова Сергей Мазур
Всем привет! Продолжаю делиться видео со своих занятий для IT management. 21ое занятие получилось почти 45 минут. НО! Обсудили и затронули несколько больших и крайне интересных тем: как проводить стендап в ресурсной команде, что такое критический путь, что такое диаграмма Ганта и сетевая диаграмма, оценка задач по трем точкам, как вести проекты по методу критического пути.
Согласитесь, жирно!
https://youtu.be/FWLhZb5rLqE
24.01
https://m.habr.com/ru/post/484932/ - двойственная природа требований к ПО.
Тимлиды пишут. Прав ли автор? Может что-то упускает? Согласны ли вы, а если нет то с чем не согласны?
Попробовали обсудить.
25.01
Если вдруг кто по хайрингу интересуется, можно глянуть, как это делают в Stripe https://stripe.com/atlas/guides/scaling-eng Особенно интересно будет глянуть на число этапов от резюме до оффера. ну и в целом там есть что полистать, кмк
26.01
https://vc.ru/learn/101011-samaya-bolshaya-podborka-po-prokachke-soft-skills-hvatit-na-vsyu-zhizn - вот уж действительно хватит на всю жизнь:) - очень большая подборка. Есть по делу, но есть и мусор.
27.01
А в чате сидят одни тимлиды - менеджеры? А то мне даже как-то некомфортно))
а давайте поговорим о фейлах интегрирования новой технологий в стек продуктов, над которыми работали/работаете?
Ну вот, например, была ситуация в одном из чатов недавно: спорили о том, стоит ли в продакшн сразу внедрять новую технологию, и тем самым в результате мнения разошлись: кто-то говорил, что СРАЗУ В ПРОД!, кто-то гвоорил НЕТ, ТАК НЕЛЬЗЯ. Меня тут гложет чистое любопытство: в каких случаях можно вкатывать новую технологию в прод, а в каких нельзя?
Я вот, например, считаю, что стоит учитывать риски внедрения., и лучше вначале обкатать на тестовом (может я тупица?) Но ваше мнение тоже хочу услышать 🧐
(возможно это уже было, не бейте меня!)
И сели про это говорить. Последовательно вспоминали разные моменты и технологии, и подходы.
vc.ru (https://bit.ly/2viCSpI)
Headz.io: помогаем разработчикам найти работу без спама, ботов и чатов
Света Петровичева героически отбивалась на тему найма и их инструмента по подбору.
Ну, все пытаются помочь...
Так и быть, делюсь в очередной раз волшебным рецептом найма быстрого и эффективного, так называемым "Наймом Без Мудаков":
1. Убедитесь, что не работаете в мудацкой компании, ибо звать кого-то работать в мудацкую - большой грех.
2. Посчитайте, сколько у вас друзей и знакомых в сфере ИТ нужных вам специальностей.
3. Если меньше, чем 36 - развивайте нетворкинг. Если больше 360 - вы Бунин.
4. При среднем сроке работы на одном месте меньше 3-х лет (36 месяцев) - от 1 до 10 ваших друзей и знакомых меняют работу каждый месяц.
5. При среднем кол-ве мудацких компаний, ещё больше, в 3-6 раз, готовы рассмотреть хорошее предложение.
6. КЛЮЧЕВОЙ ПУНКТ: пишете в своём твитере/фейсбуке/телеге - ГО К НАМ, Я СОЗДАЛ!
И попросите это сделать ваших коллег. Если отказываются - см. п. 1.
7. Если никто из друзей и знакомых к вам не пришёл, поздравляю... Мудак - это ВЫ.
Возможно, это было бы интересно если привлечь к такому скринингу реальных техлидов крупных проектов, чтобы разные техлиды оценили одного кандидата и проставили ему "оценки". Но это не нужно ни техлидам, ни кандидату.
Мы не нашли эту проблему у CTO, все хотели оценивать самостоятельно кандидатов, поэтому мы топим за расширение воронки уже подходящими кандидатами под вакансию, сейчас мы находимся в состоянии MVP, и, конечно, на всех этапах намерены получать фидбек от пользователей, чтобы наращивать функционал платформы
28.01
У меня тут сложный вопрос. А можно где-нибудь подсмотреть себе план обучения, чтобы не тыкать во всё подряд? Я пока пытаюсь бессистемно разобраться в том, где понимаю плохо (когда полностью сменил стек, получается быстрее, но всё же). Когда ищешь что-то конкретное, это понятно, но условно качаться в тимлида/CTO гораздо сложнее.
Зависит от бэкенда, можно попробовать почитать материалы от Lightbend - они не очень громозкие, но расказывают о способах построения бэкенда как раз в разрезе скалы:
https://www.lightbend.com/learn
начни с https://martinfowler.com/architecture/
И добавь книги Clean Architecture, Release It 2.0
Если не привязываться к языкам, что чо-нибудь вроде https://microservices.io/. https://www.distributed-systems.net/index.php/books/ds3/. Орейли «Высоконагруженные системы», у того же орейли есть «Designing Data Intensive Applications”
Вот может показаться странным, но чтобы лучше и быстрее научится проектировать, нужно работать с уже готовыми системами. Так проще видеть результаты. А ещё чтобы проектировать работающие системы нужно обязательно чтобы была нагрузка. Потому что в конечном итоге все упирается в дефицит ресурсов. Т.е. если вы все время делаете новые системы без повышенной нагрузки, то делать хорошие АПК вы не научитесь. А если ковыряетесь со старыми нагруженными системами, то учится проектировать ПО гораздо проще. Нагрузка не обязана быть большой, ее можно имитировать слабым железом, отчасти.
Понять по тому, как система не позволяет тебе получить, то что ты хочешь 🤓 если система позволяет легко и быстро решать все проблемы и задачи, то она хорошо спроектирована. Если же все время ты борешься с системой как "якодзун таканахана", то система спроектированна неправильно. Ведь проектирование связано с фактической задачей и не может существовать в вакууме, по моему мнению
http://highload.guide/
https://m.youtube.com/playlist?list=PLrCZzMib1e9qozAkJm0-IyBO2pkUdBLlM
https://m.youtube.com/watch?v=KmIE5K6adus - в описании ещё две части
29.01
Немного обсудили материалы.
Так, я че-то не догоняю, чем отличается кластер под лоадбалансером от шардирования?
Поговорили про это. Про шины, про ESB, про шарды и кластеры, про гейтвеи.
Собрали таки 3000 читателей:)
https://m.facebook.com/story.php?story_fbid=10156435621501511&id=726011510 Морейнис традиционно точно описал расклады при поиске отличных людей. Между тем, про это, кстати, регулярно говорит Олег;)
Обсудили немного про #1
Поговорили про Go, Kotlin и пр. Вспомнили фабрики программного обеспечения.
30.01
https://m.habr.com/ru/post/486174/ - у меня нулевая текучка.
Поржали над корейским завтраком и пр.
Попро��овали выиграть конкурс от Подлодки на лучшую рифму к слову "Тимлид"
кто какие брокеры использует: кафка, кролик, амку, натс. У кого-то есть опыт перехода с одного на другой, конкретный опыт, что стало лучше, что хуже? Что нужно: стабильная работа при внезапном образование больших очередей, легкость масштабирования, ну и конечно нельзя профукать сообщение.
Поговорили и про это. Имхо стало больше технических тем подниматься в чатике.
31.01
С Александром Черным из Pandao обсуждаем работу руководителя, обратную связь, найм и удалённую работу со спецификой в мобилу в 206 выпуске The Art Of Programming, http://bit.ly/TAOP206share #TeamLeadConf2020
а кто как пишет автотесты UI на десктоп приложения? Кто-то работал с Microsoft WinAppDriver? Надо автоматизировать UI WPF приложения.
И сразу второй вопрос в догонку, автотесты в случае с Selenium-like инструментами должны быть обязательно на той же машине, где и приложение? Или можно как то получать xpath элементов у приложения по TightVNC cоединению например?
Тегайте меня пожалуйста при ответе или пишите в личку!
https://github.com/microsoft/WinAppDriver
https://github.com/microsoft/playwright
Запустил опросник от new.hr. Они делают аналитику и делятся.
https://vc.ru/hr/82631-issledovanie-rynka-analitikov
https://vc.ru/hr/71793-analitika-zarplat-dlya-hantinga-2019g
Кира отбивалась за опросник. Но досталось явно меньше, чем Свете в прошлый раз. Ичары не боятся тимлидов:))))
Кратко итоги:
- Стало больше технических разговоров.
- Стали больше молчать по целому дню:)
- К разговорам подключились новые участники.
- А зима всё не приходит в нерезиновую.