Вопрос к Симонову: чем угостить программиста зожника, он пиццу не ест?

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

Правильный стиль руководства
anonymous poll

Снимаем все блокеры с сотрудников и даём им возможность проявить себя на примере задач – 25
👍👍👍👍👍👍👍 69%

Мои сотрудник - воины Аллаха. Куда пошлю, туда и бегут! – 9
👍👍👍 25%

Фломастеры, - им незачем думать! Надо только выполнять. – 1
▫️ 3%

Другое... – 1
▫️ 3%

👥 36 people voted so far.

За персональные данные и GDPR

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

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

Алексей Катаев из SkyEng пишет про качество видеосвязи

Ребята, привет! TLDR: Нам нужна помощь с WebRTC!

А теперь подробнее. Многие из вас знают, что видеосвязь — один из самых важных компонентов интерактивной платформы в Skyeng. В июле мы запустили проект по "улучшению видеосвязи": сгенерировали десятки гипотез, начали замерять всевозможные метрики, провели кучу экспериментов. Все, что нам удалось за несколько месяцев — снизить долю "негативных оценок" с 4% до 3.5%, а также поднять ее до 6% во время проведения экспериментов 😂. Сразу скажу: мы не используем сторонние решения, потому что это дорого и не вписывается в нашу unit-экономику. Мы используем WebRTC (Janus) и собственные видеосервера в четырех различных датацентрах. Сейчас проект по улучшению немного затормозился, гипотезы практически иссякли, а хочется сделать видео лучше, чем у гугла.

Есть ли среди ваших друзей крутые ребята, которые готовы пообщаться и подсказать, не упускаем ли мы что-то из виду? Мы в свою очередь расскажем о том, как у нас все выстроено, что-то может оказаться полезным.

Вот наши основные вопросы:
1) Какие метрики использовать при измерении качества сервиса (продуктовые и технические)?
2) Топ-3 причины проблем с видеосвязью и как с ними бороться
3) Рассказать о нашем опыте и получить фидбек

Push-сервер для мобилок
anonymous poll

Используем стороннее SAAS для пушей – 13
👍👍👍👍👍👍👍 65%

Подняли себе решение на своей железке – 7
👍👍👍👍 35%

👥 20 people voted so far.

@sbase пишет цинично про Agile и разработку:

Agile это система ценностей... Но настоящему программисту на эти ценности в целом глубоко пофиг. Как впрочем пофиг и на ценности компании, и на цели компании. Ему интересно придумывать крутые штуки, которые классно работают. И хорошо, чтобы за это еще и хорошо платили.

Если программист не настоящий, то ему тоже пофиг на ценности, у него поставлена цель - сделать объем работы, и если он успевает, то он получит деньги. Но он ленивый, поэтому не хочет переделывать, и делает сразу правильно. Еще раз:  Он он не любит переделывать! Это значит, если вы будете метаться с целями, он выкинет вас и сам будет выяснять что нужно клиенту, просто чтобы не переделывать.

А если в компании нет программистов? То 90% будут просто теми, кто работает за деньги, 9% тех кто за личные достижения (чтобы сказать "Я это сделал!", и 1% тех кому больше всех надо и он думает про Клиента и про его потребности и пытается что-то изменить и улучшить.

Но вы никогда не узнаете, кто из них кто. Люди говорят то, что от них хотят услышать и действуют так как их измеряют. Поэтому просто создайте условия для работы (чтобы не отвлекало), задайте цель, ограничьте выбор и не дергайте. Настоящий инженер сделает все правильно. И тогда у вас будет идеальная машинка для производства  денег.

Внимание! Не пытайтесь это делать, если ваши люди не эксперты своего дела, потеряете время и деньги.

Юрий Синодов пишет про то, в какое могущественное время мы живём, но променяли его на чечевичную похлёбку:

Поражает рост количества людей сидящих что в России, что за рубежом на расстоянии вытянутой руки от мегачуваков современнности, делающих Яндексы, Гуглы, Фейсбуки, лечащих рак, делающих IT-системы влияющие на жизнь государств и так далее.

Истории, в которые, только скажи — и ты войдёшь тоже и будешь как минимум частью этого, а то и ответственным за всё это.

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

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

Как админы в Яндексе определяют при найме - норм админ или так себе?

Если кандидат мог бы быть ещё более параноидальным, но нет, значит недостаточно админ. Они тогда говорят: "из вас получится отличный разработчик!" :)))

Настоящий админ - всегда параноик до мозга и костей. Он не доверят пароль даже самому себе!

Обязанности техдира

Техдир всегда работает в трёх командах:

1 команда - его собственная. Он там всё настраивает и работа ведётся так или почти так, как он хочет.

2 команда - это команда, где он, проджекты и продакты, являющиеся входным окном для бизнеса преобразовывают поток задач от бизнеса в технические задачи: продуктовая проработка, архитектурные корректировки, технические декомпозиции  и пр и пр. Здесь рулит не столько техдир, сколько все договариваются друг с другом.

3 команд - это собственно бизнес, где техдир вполне себе рядовой член команды. где он подчиняется.

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

Ну и конечно, если техдир не понимает, что работает в нескольких командах, - это уже само по себе боль.

Если же у нас ситуация, когда техдир не умеет полноценно собирать команды, - болей прибавляется. Я видел  много людей, которые по массе причине не умели или не могли или даже не имели прав формировать свои команды.

Важно общать вниание на переток задач от бизнеса, через команду с продактами (если такая вообще есть) в техническую часть, - это очень болезненная тема. Зачастую даже если попросить техническую команду, техдира с продактами и бизнес просто перечислить актуальные задачи, показания будут очень сильно отличаться. Бизнес и технари в принципе оперируют даже разными тикет-системами.

Чем занимается техдир в трёх своих командах?

* В технической команде это - курирование технической части.

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

* В работе с бизнесом - это вопросы стратегического успевания за хотелками бизнеса.

Если этого нет, значит кто-то является придатком кого-то. Либо бизнес - по сути придаток к технической команде и активно не развивается.

Либо наоборот, - технари являются "фломастерами" бизнеса. ("Фломастер"=тупой исполнитель, у которого нет и не может быть своего собственного мнения)

Английский язык в работе техдира/тимлида
anonymous poll

Востребован – 48
👍👍👍👍👍👍👍 72%

Нельзя обойтись – 17
👍👍 25%

Может пригодиться – 2
▫️ 3%

👥 67 people voted so far.

Есть два равновеликих техдира/тимлида. Отличаются только знанием английского языка. Кого взять?
anonymous poll

Знающего английский – 42
👍👍👍👍👍👍👍 95%

Так как кроме английского ничем не отличаются, кинуть монетку! – 2
▫️ 5%

Незнающего английский
▫️ 0%

👥 44 people voted so far.

fb.com/marine.a.sim про agile в продажах

Узнал от Марины, что Agile активно используют в продажах. Она как раз помогает всем, развивая и стартапы и большие компании под руководством самого Джефа Сазерленда (это автор Скрама, если кто не в курсе).

Есть тренинг на русском в Москве, на котором ещё остались места. Велком! https://goo.gl/pLHkRa

Разрабатываем фичи как?
anonymous poll

Костыльно: быстро-быстро выкатываем и тестируем в продакшне! Но у бизнеса есть шанс добежать до денег. – 32
👍👍👍👍👍👍👍 73%

Перфекционно: тщательно делаем и никогда не сдаём! Но зато качественно! – 12
👍👍👍 27%

👥 44 people voted so far.

Кое-что о разработке фич

Архитектура проекта в упрощённом понимании представляет собой пути движения информации между компонентами. Например:
* http-запрос от мобилки к бекенду,
* от бекенда sql запрос к бд,
* потом обратно информация из бд в бекенд
* а бекенд шлёт ответ мобилке.

Но тут бизнес говорит, - а давайте пошлём пуш на мобилку! Это же дёшево и быстро? Сделайте вне очереди и выкатите к обеду!

Сам пуш послать - действительно плёвое дело. Час работы. Ну два. Дешёвая простая фича. Верно?

Но для посылки пуша нужен сервис отсылки пушей. Нужно интеграция с, например, Firebase. Это уже не час-два, а чуть дольше. В результате бизнес получает свою фичу не через час-два, а в лучшем случае через день.

Сначала модифицируем архитектуру, добавляя интеграцию с пуш-сервером, тестируем устойчивость интеграции и выкатываем в продакшн.

После этого пилим простую фичу посылки пушей.

Разработка перестала быть предсказуемой. Более того, на этой задаче невозможно "срезать угол" и "закостылить".

Где подвох?

Гордость и предубеждение

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

В качестве очевидного примера приведу японскую песенку с симпатичной мелодией и реально классным текстом. А российский вариант перевода не могут терпеть вообще все из-за специфики исполнителя! Специально не пишу, что это за песня на русском и кто исполнитель.

Про мои любимые CLI интерфейсы пишет Jeff Dickey

1. Пишите удобный хелп и снабдите скрипты автокомплитом
2. Используйте не только нумерованные аргументы, но и именованные
3. Дайте возможность посмотреть версию скрипта
4. Используйте stdout и stderr по корректным назначениям
5. Сделайте подробный вывод ошибок
6. Пусть в ваш скрипт будет немного шоуменом
7. Добавляйте интерактивные фишечки
8. Таблички тоже ни кто не запрещает выводить удобно-понятно
9. Скриптик должен быть шустрым
10. Чаще выкладывайте скриптики в опен-сорс
11. Если скриптик со сложной ветвистой логикой, не забывайте продумать удобные параметры для суб-команд
12. Хорошим тоном будет соблюдение XDG-спецификации

https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46

Tmux
anonymous poll

Что это? – 23
👍👍👍👍👍👍👍 36%

Да, знаю, использую регулярно его (или аналог). – 21
👍👍👍👍👍👍 33%

Знаю, но не использую – 20
👍👍👍👍👍👍 31%

👥 64 people voted so far.