Бирман вот пишет про правильных верстальщиков — https://ilyabirman.ru/meanwhile/all/plohoy-i-horoshiy-verstalschiki/.
Полностью согласен: самый ценный исполнитель — тот, кто сам принимает (правильные) решения. Не ходите к менеджеру и дизайнеру с вопросами — пусть менеджер и дизайнер ходят к вам.
Полностью согласен: самый ценный исполнитель — тот, кто сам принимает (правильные) решения. Не ходите к менеджеру и дизайнеру с вопросами — пусть менеджер и дизайнер ходят к вам.
ilyabirman.ru
Плохой и хороший верстальщики
Коля Товеровский написал про плохого верстальщика, который не в состоянии сделать как на макете...
Мой любимый таск-трекер
Менеджеры могут спорить про выбор таск-трекера не меньше, чем программисты — про редакторы кода. В этой заметке я расскажу про мой любимый рецепт. Рецепт кажется универсальным — я не смог придумать ни одной маленькой команды, которой он бы не подошёл. Если вам не подходит — напишите в личку пожалуйста.
Свои требования к трекеру я построил вокруг удобства пользователей. Хотелось как у дизайнеров — когда интерфейса нет, а задача выполняется. Поэтому я остановился прямо на встроенном в гитхаб задачнике — с ним программисты работают с задачами там же, где ревьюят код и читают документацию.
Для небольшой команды достаточно стоковой функциональности гитхаба — двух состояний задачи (открыта\закрыта), назначения ответственного и возможности писать комменты. Для планирования спринтов идеально подходит другая встроенная фича — майлстоуны.
Для нас в mtrl.ai было еще два ограничения — неудобно ставить задачи, которые касаются нескольких репозиториев (к примеру одна фича затрагивает несколько микросервисов), и очень хотелось показывать статусы задач для бизнеса.
Первую проблему решили тем, что создали отдельный административный проект. Проект так и назвали - a. a содержит общие вещи для всех репозиториев — задачи, планы на спринт и всю документацию.
Для второй задачи — прозрачности — мы просто подключили гитхаб к трелло, где до этого хранили беклог. Раз в неделю при планировании спринта перетаскиваем выполненные задачи в колонку Done, а новые — в колонку WIP. Каждая карточка в трелло ссылается на задачу в гитхабе, так что если вы авторизованы в обоих системах, проверка статусов занимает 3 минуты.
Бизнес в одном месте видит продуктовый беклог и статусы задач, а значит мы живем в единой системе координат.
#гитхаб
Менеджеры могут спорить про выбор таск-трекера не меньше, чем программисты — про редакторы кода. В этой заметке я расскажу про мой любимый рецепт. Рецепт кажется универсальным — я не смог придумать ни одной маленькой команды, которой он бы не подошёл. Если вам не подходит — напишите в личку пожалуйста.
Свои требования к трекеру я построил вокруг удобства пользователей. Хотелось как у дизайнеров — когда интерфейса нет, а задача выполняется. Поэтому я остановился прямо на встроенном в гитхаб задачнике — с ним программисты работают с задачами там же, где ревьюят код и читают документацию.
Для небольшой команды достаточно стоковой функциональности гитхаба — двух состояний задачи (открыта\закрыта), назначения ответственного и возможности писать комменты. Для планирования спринтов идеально подходит другая встроенная фича — майлстоуны.
Для нас в mtrl.ai было еще два ограничения — неудобно ставить задачи, которые касаются нескольких репозиториев (к примеру одна фича затрагивает несколько микросервисов), и очень хотелось показывать статусы задач для бизнеса.
Первую проблему решили тем, что создали отдельный административный проект. Проект так и назвали - a. a содержит общие вещи для всех репозиториев — задачи, планы на спринт и всю документацию.
Для второй задачи — прозрачности — мы просто подключили гитхаб к трелло, где до этого хранили беклог. Раз в неделю при планировании спринта перетаскиваем выполненные задачи в колонку Done, а новые — в колонку WIP. Каждая карточка в трелло ссылается на задачу в гитхабе, так что если вы авторизованы в обоих системах, проверка статусов занимает 3 минуты.
Бизнес в одном месте видит продуктовый беклог и статусы задач, а значит мы живем в единой системе координат.
#гитхаб
Вышла вторая версия терминала на электроне — Hyper. Одно из основных достижений, по словам разработчиков — теперь терминал нормально переваривает много потоковых данных.
Терминал. Зависал. От данных.
Чувствую себя старым брюзгой, но как-то грустно наблюдать за индустрией, которая сама себе придумывает проблемы, чтобы героически их решать.
Терминал, который зависает, если вывести много текста? База данных, в которой нет реляционности? Бекенд на языке, который может работать только в один поток? Пожалуйста!
И ведь эти же прекрасные разработчики могли пойти и сделать что-нибудь полезное — законтрибьютить в iTerm, к примеру. Или даже в vscode, все равно через 5 лет других редакторов не останется.
Терминал. Зависал. От данных.
Чувствую себя старым брюзгой, но как-то грустно наблюдать за индустрией, которая сама себе придумывает проблемы, чтобы героически их решать.
Терминал, который зависает, если вывести много текста? База данных, в которой нет реляционности? Бекенд на языке, который может работать только в один поток? Пожалуйста!
И ведь эти же прекрасные разработчики могли пойти и сделать что-нибудь полезное — законтрибьютить в iTerm, к примеру. Или даже в vscode, все равно через 5 лет других редакторов не останется.
Вики Ивелума
Ивелум — софтовая компания, которая не побоялась выложить внутренние документы в открытый доступ. Документы касаются всего — от устройства на работу до особенностей написания сообщений к коммитам.
Мотив понятен — такая документация дает полную прозрачность для потенциальных сотрудников: еще не пришел в компанию, а уже знаешь, что тебя ждет.
Вот пара интересных мест:
— Еженедельные отчеты всех сотрудников.
— Процесс разработки — методология, тестирование, общение с заказчиком.
— Порядок реакции на инциденты в продакшене.
Полностью — тут.
Если вы начинаете систематизировать происходящее внутри вашей команды, возьмите вики Ивелума за основу.
Ивелум — софтовая компания, которая не побоялась выложить внутренние документы в открытый доступ. Документы касаются всего — от устройства на работу до особенностей написания сообщений к коммитам.
Мотив понятен — такая документация дает полную прозрачность для потенциальных сотрудников: еще не пришел в компанию, а уже знаешь, что тебя ждет.
Вот пара интересных мест:
— Еженедельные отчеты всех сотрудников.
— Процесс разработки — методология, тестирование, общение с заказчиком.
— Порядок реакции на инциденты в продакшене.
Полностью — тут.
Если вы начинаете систематизировать происходящее внутри вашей команды, возьмите вики Ивелума за основу.
Сервис: Google Tag Manager
Если вы вдруг работаете с вебом, и до сих пор не знаете про Google Tag Manager — эта заметка для вас. GTM — это фундаментальный инструмент для управления интеграциями с внешними системами.
Вот представьте ситуацию, вы — маркетолог, подключаете новый канал (к примеру Фейсбук), а он требует установки какого-то кода на сайт (к примеру Фейсбук-пикселя). Если у вас на сайте нет ГТМ — приходится идти к айтишникам, а у них еще 100 задач, спринт и вообще не до вас. Если ГТМ установлен — вы просто идете в его интерфейс, копируете код и все моментально появляется на сайте.
Или вы — аналитик, для проверки новой гипотезы хотите измерить количество нажатий на определенную кнопку. В ГТМ вы просто создаете новое событие, и данные сами собой записываются в Google Analytics (или куда там вам надо).
GTM — полностью бесплатный сервис, имеет в комплекте пачку готовых интеграций и позволяет легко устанавливать свои. Из минусов — только Material design и традиционная для Гугла отвратительная документация. Альтернативы есть, но какие-то невнятные и платные.
tagmanager.google.com
Если вы вдруг работаете с вебом, и до сих пор не знаете про Google Tag Manager — эта заметка для вас. GTM — это фундаментальный инструмент для управления интеграциями с внешними системами.
Вот представьте ситуацию, вы — маркетолог, подключаете новый канал (к примеру Фейсбук), а он требует установки какого-то кода на сайт (к примеру Фейсбук-пикселя). Если у вас на сайте нет ГТМ — приходится идти к айтишникам, а у них еще 100 задач, спринт и вообще не до вас. Если ГТМ установлен — вы просто идете в его интерфейс, копируете код и все моментально появляется на сайте.
Или вы — аналитик, для проверки новой гипотезы хотите измерить количество нажатий на определенную кнопку. В ГТМ вы просто создаете новое событие, и данные сами собой записываются в Google Analytics (или куда там вам надо).
GTM — полностью бесплатный сервис, имеет в комплекте пачку готовых интеграций и позволяет легко устанавливать свои. Из минусов — только Material design и традиционная для Гугла отвратительная документация. Альтернативы есть, но какие-то невнятные и платные.
tagmanager.google.com
Две пробные недели
Когда-то я честно украл у МИФа классную практику найма — две испытательные недели. Всем программистам, которые выполнили тестовое задание, я предлагаю поработать в свободном режиме над боевыми задачами, на правах полноценного участника команды.
Получается, что ребятам не нужно увольняться с текущего места работы, чтобы проверить себя на совместимость с нашими требованиями. Никаких сложных решений: не срослось, так не срослось.
Со своей стороны новый программист точно так же оценивает будущую команду — когда нет никаких обязательств, очень легко делать это беспристрастно. Всегда можно встать и уйти, поняв, что что-то не нравится.
Двух недель достаточно, чтобы оценить все аспекты — стиль общения и кодирования, уровень документации и автоматизации. Успеваешь составить представление о том, что происходит на код-ревью, как пишутся тесты и проверяются результаты.
Мы предельно упростили процесс выхода на эти две недели — достаточно прислать скан подписанного НДА. Сразу после этого на почту падает приглашение в нашу команду на гитхабе (все общение там) и пара пристрелочных задач.
В обычном офисе с теми же целями можно походить и пообщаться с коллегами, выйти в курилку. А в распределенной команде лучше поработать пару недель и увидеть все своими глазами.
#работамечты
Когда-то я честно украл у МИФа классную практику найма — две испытательные недели. Всем программистам, которые выполнили тестовое задание, я предлагаю поработать в свободном режиме над боевыми задачами, на правах полноценного участника команды.
Получается, что ребятам не нужно увольняться с текущего места работы, чтобы проверить себя на совместимость с нашими требованиями. Никаких сложных решений: не срослось, так не срослось.
Со своей стороны новый программист точно так же оценивает будущую команду — когда нет никаких обязательств, очень легко делать это беспристрастно. Всегда можно встать и уйти, поняв, что что-то не нравится.
Двух недель достаточно, чтобы оценить все аспекты — стиль общения и кодирования, уровень документации и автоматизации. Успеваешь составить представление о том, что происходит на код-ревью, как пишутся тесты и проверяются результаты.
Мы предельно упростили процесс выхода на эти две недели — достаточно прислать скан подписанного НДА. Сразу после этого на почту падает приглашение в нашу команду на гитхабе (все общение там) и пара пристрелочных задач.
В обычном офисе с теми же целями можно походить и пообщаться с коллегами, выйти в курилку. А в распределенной команде лучше поработать пару недель и увидеть все своими глазами.
#работамечты
Как я подбираю книги
Как и многие другие, я стараюсь читать как можно больше полезных книг. Чтобы не повторяться и не читать книжный шлак, у меня есть два простых правила.
💎Не выбирать книги в интернет-магазине💎
На сайтах издательств или в постах на лайфхакере «10 книг, которые изменят вашу жизнь» новых знаний не найти — эти списки нацелены на людей в состоянии потребителя. Потребитель не ищет знания, а решает сиюминутные проблемы — как добиться повышения на работе, помириться с женой, или заработать сто тысяч, не вставая с дивана.
Бизнес-книги, полные воды, появляются потому, что их покупают.
А интернет-магазин, в свою очередь, выкладывает то, что продается — яркие обложки с громкими названиями. Чтобы не вестись на громкие названия, я подбираю книги по советам друзей, из блогов и фейсбучка, обходя стороной интернет-магазины.
💎Смело выбрасывать💎
Перед покупкой я формирую ожидания, и если книга не справляется — выбрасываю без сожаления.
От «Организаций будущего» я ожидал описания оргструктур по Друкеру, и бросил, распознав книгу о холакратии — организации без менеджеров, которую безуспешно пытался внедрить Тони Шей в Запосе. «Чеклист» Атула Гаванде я выбросил после пассажа о том, как автор, управляя Боингом-777 «переключился на нейтраль и стал ждать очереди на взлет».
Книга — такой же товар на рынке. Если, вернувшись из магазина, я обнаружу что свежекупленные яйца протухли, я не буду делать омлет, а выброшу контейнер в мусорку.
Как и многие другие, я стараюсь читать как можно больше полезных книг. Чтобы не повторяться и не читать книжный шлак, у меня есть два простых правила.
💎Не выбирать книги в интернет-магазине💎
На сайтах издательств или в постах на лайфхакере «10 книг, которые изменят вашу жизнь» новых знаний не найти — эти списки нацелены на людей в состоянии потребителя. Потребитель не ищет знания, а решает сиюминутные проблемы — как добиться повышения на работе, помириться с женой, или заработать сто тысяч, не вставая с дивана.
Бизнес-книги, полные воды, появляются потому, что их покупают.
А интернет-магазин, в свою очередь, выкладывает то, что продается — яркие обложки с громкими названиями. Чтобы не вестись на громкие названия, я подбираю книги по советам друзей, из блогов и фейсбучка, обходя стороной интернет-магазины.
💎Смело выбрасывать💎
Перед покупкой я формирую ожидания, и если книга не справляется — выбрасываю без сожаления.
От «Организаций будущего» я ожидал описания оргструктур по Друкеру, и бросил, распознав книгу о холакратии — организации без менеджеров, которую безуспешно пытался внедрить Тони Шей в Запосе. «Чеклист» Атула Гаванде я выбросил после пассажа о том, как автор, управляя Боингом-777 «переключился на нейтраль и стал ждать очереди на взлет».
Книга — такой же товар на рынке. Если, вернувшись из магазина, я обнаружу что свежекупленные яйца протухли, я не буду делать омлет, а выброшу контейнер в мусорку.
Opbeat закрывается
Грустная новость: закрывается Opbeat — гибрид Sentry и New Relic для энтузиастов. Гибрид — потому что умел мониторить производительность приложений и фиксировать ошибки. Для энтузиастов — потому что имел офигенный бесплатный тариф, которого хватало для небольших проектов.
Закрытие прошло как-то странно, не было ни постов в блоге, ни уведомлений — просто пришел Final Reminder. На замену предлагают Elastic APM, который тянет за собой целый огород из всех продуктов Эластика, а вместо нормальной SaaS версии предлагает жутко энтерпрайзный Elastic Cloud.
Немного напоминает поглощение и закрытие Kadira для Метеора — там тоже взамен готового решения предложили кучу исходников, которые непонятно было как запускать. Однако у разработчиков Метеора была понятная цель — всех загоняли на свою хостинговую платформу, со встроеной Кадирой.
Цели Эластика я не очень понимаю. Кому мешала SaaS-версия? Почему никто не тестировал другие тарифы или модели монетизации?
А пока ждем, когда провайдеры hosted ELK подтянут к себе новую функциональность, и юзаем Датадог и Сентри.
Грустная новость: закрывается Opbeat — гибрид Sentry и New Relic для энтузиастов. Гибрид — потому что умел мониторить производительность приложений и фиксировать ошибки. Для энтузиастов — потому что имел офигенный бесплатный тариф, которого хватало для небольших проектов.
Закрытие прошло как-то странно, не было ни постов в блоге, ни уведомлений — просто пришел Final Reminder. На замену предлагают Elastic APM, который тянет за собой целый огород из всех продуктов Эластика, а вместо нормальной SaaS версии предлагает жутко энтерпрайзный Elastic Cloud.
Немного напоминает поглощение и закрытие Kadira для Метеора — там тоже взамен готового решения предложили кучу исходников, которые непонятно было как запускать. Однако у разработчиков Метеора была понятная цель — всех загоняли на свою хостинговую платформу, со встроеной Кадирой.
Цели Эластика я не очень понимаю. Кому мешала SaaS-версия? Почему никто не тестировал другие тарифы или модели монетизации?
А пока ждем, когда провайдеры hosted ELK подтянут к себе новую функциональность, и юзаем Датадог и Сентри.
Сергей Шабалин рассказывает о прекрасном правиле: никогда не говори «я же говорил». Для удаленной команды и долгосрочных отношений — вообще мастхев.
http://shabalinsergey.ru/all/ne-govorit-ya-uzhe-govoril/
http://shabalinsergey.ru/all/ne-govorit-ya-uzhe-govoril/
Рассказал про три варианта карьерного роста для тех, кто уже достиг уровня миддла — https://xn--r1a.website/iv?url=https://borshev.com/middle-way/&rhash=5ef08d16e14be6
t.me
Программистам: три варианта развития мидла
Итак, ты научился не проебывать дедлайны, тестировать свой код и проходить код-ревью за одну итерацию. Это значит что ты — мидл, и пора задуматься о перспективах дальнейшего карьерного роста. Их на самом деле всего три: ничего не делать, стать синьором или податься…
Пацан сказал → пацан сделал
Если приглядеться, то куча людей вокруг нас не имеют простого навыка — пообещать «написать в среду» и написать в среду. Работать с такими людьми — дорого: куча энергии и внимания уходит на банальный контроль того, что порученные задачи действительно делаются.
«Пацан сказал → пацан сделал», без шуток — самый важный критерий для оценки людей в команде. Эмпатия, умение фокусироваться над задачей, планировать время и вести переговоры — все эти навыки имеют одну проекцию во внешнем мире: умение выполнять обещания.
Если новый сотрудник нарушает обещания — это даже не звонок, а тревожный гонг. Человек, не умеющий управлять временем создает кучу неудобств — опаздывает на встречи, сдает хуйню вместо результатов, вынуждает работать над особыми формами мотивации.
Выполняющему обещания коллеге, наоборот, можно поручить что угодно. С ним я уверен, что даже если обещание не выполнится (всякое бывает), я узнаю об этом максимально быстро. Такого коллегу не нужно пинговать раз в два дня, не нужно объяснять банальных вещей того, что на письма нужно отвечать, а не игнорировать.
Команды без менеджера (или иной формы принуждения) могут существовать только там, где пацаны говорят, а потом делают, что сказали.
Если приглядеться, то куча людей вокруг нас не имеют простого навыка — пообещать «написать в среду» и написать в среду. Работать с такими людьми — дорого: куча энергии и внимания уходит на банальный контроль того, что порученные задачи действительно делаются.
«Пацан сказал → пацан сделал», без шуток — самый важный критерий для оценки людей в команде. Эмпатия, умение фокусироваться над задачей, планировать время и вести переговоры — все эти навыки имеют одну проекцию во внешнем мире: умение выполнять обещания.
Если новый сотрудник нарушает обещания — это даже не звонок, а тревожный гонг. Человек, не умеющий управлять временем создает кучу неудобств — опаздывает на встречи, сдает хуйню вместо результатов, вынуждает работать над особыми формами мотивации.
Выполняющему обещания коллеге, наоборот, можно поручить что угодно. С ним я уверен, что даже если обещание не выполнится (всякое бывает), я узнаю об этом максимально быстро. Такого коллегу не нужно пинговать раз в два дня, не нужно объяснять банальных вещей того, что на письма нужно отвечать, а не игнорировать.
Команды без менеджера (или иной формы принуждения) могут существовать только там, где пацаны говорят, а потом делают, что сказали.
Методологии разработки
Есть методологии вроде скрама, которые описывают каждый шаг, который нужно делать, чтобы прийти к результату — ежедневные встречи, берндаун-чарты, сторипоинты, вот это все.
Есть методологии, пришедшие к нам из менее развитых областей, суть которых сводится к тому, как правильно и с какой регулярностью программистов нужно пи́здить.
Но почему-то ни одна методология не рассказывает, что для достижения хорошего результата можно просто нанять ответственных людей и не ебать им мозги.
Наверное потому, что это тяжело описать: как правильно расставаться с безответственными, как заинтересовать ответственных. Как, в конце концов, построить организацию, из которой не хочется сбежать через 3 месяца.
По-моему, самая лучшая методология разработки — создать контекст, который выдавливает из себя безответственных людей и притягивает ответственных. А затем не мешать им работать.
Есть методологии вроде скрама, которые описывают каждый шаг, который нужно делать, чтобы прийти к результату — ежедневные встречи, берндаун-чарты, сторипоинты, вот это все.
Есть методологии, пришедшие к нам из менее развитых областей, суть которых сводится к тому, как правильно и с какой регулярностью программистов нужно пи́здить.
Но почему-то ни одна методология не рассказывает, что для достижения хорошего результата можно просто нанять ответственных людей и не ебать им мозги.
Наверное потому, что это тяжело описать: как правильно расставаться с безответственными, как заинтересовать ответственных. Как, в конце концов, построить организацию, из которой не хочется сбежать через 3 месяца.
По-моему, самая лучшая методология разработки — создать контекст, который выдавливает из себя безответственных людей и притягивает ответственных. А затем не мешать им работать.
Аркадий Фомич дело говорит — чтобы нанимать лучших, нужно создавать такие условия, в которых будет понятен их рост на рынке труда.
К примеру, дать громкий проект, который хочется положить в портфолио. Или адаптировать у себя радикально новые технологии, о которых все заговорят только через год.
К примеру, дать громкий проект, который хочется положить в портфолио. Или адаптировать у себя радикально новые технологии, о которых все заговорят только через год.
Forwarded from Тёмная сторона / Темнографика
Что нужно поколению Z от работы?
1. Deloitte провел исследование разницы в отношениях миллениалов и поколения Z к работе и будущему. Миллениалы – родившиеся с 1983 по 1994 год, поколение Z – с 1995 по 1999. Я обратил внимание на два слайда. Количество миллениалов, собирающихся сменить работу в течение двух лет – 43%, количество людей в поколении Z с теми же целями – 61%. Люди из поколения Z думают, что у них меньше перспектив в жизни и карьере: на 32% меньше, чем у миллениалов, и на 43-46% меньше, чем у предыдущих поколений. Дальше в отчете делаются выводы, что поколение Z бла-бла-бла что-то там. Но мне кажется, что "нет ничего нового под солнцем", а все это проявление других, но древних как мир истин.
2. Молодое поколение более остро чувствует, что радужные перспективы достанутся не всем. Они еще готовы ради этих перспектив суетиться – хотя, ничего, кроме более быстрого перебора рабочих мест, большинство из них придумать не может.
3. Чем взрослее это поколение становится, тем больше люди смиряются с тем, что у них уже есть. Зачем менять работу, если на другое работе будет почти то же самое? Давайте убедим себя, что у нас и так все хорошо – ведь у нас есть квартира и машина, семья и дети, и с работу нас еще не выгнали.
4. Кроме общих соображений по поводу того, "в чем смысл жизни", и "перспективы надо искать и создавать еще в молодости" – напрашивается еще один более конструктивный вывод. Если мы хотим привлекать к себе на работу молодежь – не надо обещать им пожизненной карьеры в своей компании. Наоборот, надо манить их перспективами научиться у нас чему-то настолько полезному, чтобы в течение пары лет они могли упорхнуть от нас куда-нибудь повыше.
Ссылка на полный текст исследования: https://documents.deloitte.com/insights/2018DeloitteMillennialSurvey
1. Deloitte провел исследование разницы в отношениях миллениалов и поколения Z к работе и будущему. Миллениалы – родившиеся с 1983 по 1994 год, поколение Z – с 1995 по 1999. Я обратил внимание на два слайда. Количество миллениалов, собирающихся сменить работу в течение двух лет – 43%, количество людей в поколении Z с теми же целями – 61%. Люди из поколения Z думают, что у них меньше перспектив в жизни и карьере: на 32% меньше, чем у миллениалов, и на 43-46% меньше, чем у предыдущих поколений. Дальше в отчете делаются выводы, что поколение Z бла-бла-бла что-то там. Но мне кажется, что "нет ничего нового под солнцем", а все это проявление других, но древних как мир истин.
2. Молодое поколение более остро чувствует, что радужные перспективы достанутся не всем. Они еще готовы ради этих перспектив суетиться – хотя, ничего, кроме более быстрого перебора рабочих мест, большинство из них придумать не может.
3. Чем взрослее это поколение становится, тем больше люди смиряются с тем, что у них уже есть. Зачем менять работу, если на другое работе будет почти то же самое? Давайте убедим себя, что у нас и так все хорошо – ведь у нас есть квартира и машина, семья и дети, и с работу нас еще не выгнали.
4. Кроме общих соображений по поводу того, "в чем смысл жизни", и "перспективы надо искать и создавать еще в молодости" – напрашивается еще один более конструктивный вывод. Если мы хотим привлекать к себе на работу молодежь – не надо обещать им пожизненной карьеры в своей компании. Наоборот, надо манить их перспективами научиться у нас чему-то настолько полезному, чтобы в течение пары лет они могли упорхнуть от нас куда-нибудь повыше.
Ссылка на полный текст исследования: https://documents.deloitte.com/insights/2018DeloitteMillennialSurvey
Namecheap включил бесплатный WhoisGuard
WhoisGuard — это сервис, который защищает от спамеров ваши контакты: домен остается зарегистрированным на вас, но никто об этом не может узнать.
В рунете это давно уже включено по умолчанию на законодательном уровне, а теперь появилась возможность получить это бесплатно от одного из самых дешевых (и понятных) мировых регистраторов.
WhoisGuard — это сервис, который защищает от спамеров ваши контакты: домен остается зарегистрированным на вас, но никто об этом не может узнать.
В рунете это давно уже включено по умолчанию на законодательном уровне, а теперь появилась возможность получить это бесплатно от одного из самых дешевых (и понятных) мировых регистраторов.
Следующий раунд борьбы Телеграма с Роскомнадзором
Сегодня вышло обновление телеграма. Официально оно содержит обновления для GPDR, неофициально — поддержку нового формата прокси — MTProto.
MTProto — нативный для телеги формат передачи данных: примерно такие сервера Дуров разворачивает пачками на разных площадках, чтобы обходить блокировки.
Выпуск прокси в паблик — очевидный шаг к децентрализации: теперь каждый может развернуть у себя сервер, который разрешает пользоваться телеграмом всему ближнему кругу. Пользователи даже могут выбирать, к чьему прокси подключаться.
С моего дивана это кажется ещё одним шагом в сторону пропасти^W DPI — такие действия вынуждают Роскомнадзор перейти от тупой блокировки IP-адресов к полноценному автоматическому изучению вашего трафика.
Это значит, что у каждого провайдера поселится специальный неебически дорогой робот, который будет решать: ага, этот пакет похож на телеграм, в жопу его. Вот там порнуху смотрят — ну пусть посмотрят. Так, а здесь что-то много трафика в Финляндию, не пойму что передают — замедлим до 32кбит/с, пусть шифруются, кек.
О том, как живут люди с DPI в Иране, можно почитать грустный тредик на гитхабе.
Тяжело придётся небольшим разработчикам, у которых вся облачная инфраструктура, включая девопс — заемная, и находится за границей. Придётся мигрировать на корявые коробочные решения, вроде гитлаба и ютрека, платить деньги за хостинг и зарплату админам.
Ну а я пойду приближать эпоху Золотого Щита, и поднимать MTProto в дополнение к SOCKS для всех, с кем хочу поддерживать связь.
Сегодня вышло обновление телеграма. Официально оно содержит обновления для GPDR, неофициально — поддержку нового формата прокси — MTProto.
MTProto — нативный для телеги формат передачи данных: примерно такие сервера Дуров разворачивает пачками на разных площадках, чтобы обходить блокировки.
Выпуск прокси в паблик — очевидный шаг к децентрализации: теперь каждый может развернуть у себя сервер, который разрешает пользоваться телеграмом всему ближнему кругу. Пользователи даже могут выбирать, к чьему прокси подключаться.
С моего дивана это кажется ещё одним шагом в сторону пропасти^W DPI — такие действия вынуждают Роскомнадзор перейти от тупой блокировки IP-адресов к полноценному автоматическому изучению вашего трафика.
Это значит, что у каждого провайдера поселится специальный неебически дорогой робот, который будет решать: ага, этот пакет похож на телеграм, в жопу его. Вот там порнуху смотрят — ну пусть посмотрят. Так, а здесь что-то много трафика в Финляндию, не пойму что передают — замедлим до 32кбит/с, пусть шифруются, кек.
О том, как живут люди с DPI в Иране, можно почитать грустный тредик на гитхабе.
Тяжело придётся небольшим разработчикам, у которых вся облачная инфраструктура, включая девопс — заемная, и находится за границей. Придётся мигрировать на корявые коробочные решения, вроде гитлаба и ютрека, платить деньги за хостинг и зарплату админам.
Ну а я пойду приближать эпоху Золотого Щита, и поднимать MTProto в дополнение к SOCKS для всех, с кем хочу поддерживать связь.
И еще вакансии
Мы в mtrl.ai растём на 20% каждый месяц. Задач становится все больше, поэтому мы открываем новый набор. Кто нужен:
— Дизайнер-продуктолог, Москва. Работа удаленная, но два-три дня в неделю нужно появляться в офисе.
— Ведущий питонист, обязательна терпимость к JS желание стать фулл-стеком.
— Джуниор-фуллстек. Если вы знаете про TDD в питоне и можете отличить vue от реакта — после года у нас начнете стоить как крутой мидл.
Продуктолог получает полный доступ к цифрам, быстрых разработчиков и крутых эдвайзеров.
Программисты — удаленную работу без менеджеров, и проект с хорошим кодом на ультрасовременном стеке.
Вы будете работать над e-коммерсом с полностью автоматической логистикой, который скоро захватит рынок стройматериалов. Ответственность и свобода в принятии решений прилагается.
Мы в mtrl.ai растём на 20% каждый месяц. Задач становится все больше, поэтому мы открываем новый набор. Кто нужен:
— Дизайнер-продуктолог, Москва. Работа удаленная, но два-три дня в неделю нужно появляться в офисе.
— Ведущий питонист, обязательна терпимость к JS желание стать фулл-стеком.
— Джуниор-фуллстек. Если вы знаете про TDD в питоне и можете отличить vue от реакта — после года у нас начнете стоить как крутой мидл.
Продуктолог получает полный доступ к цифрам, быстрых разработчиков и крутых эдвайзеров.
Программисты — удаленную работу без менеджеров, и проект с хорошим кодом на ультрасовременном стеке.
Вы будете работать над e-коммерсом с полностью автоматической логистикой, который скоро захватит рынок стройматериалов. Ответственность и свобода в принятии решений прилагается.
Тупое правило менеджера
Ещё в студии я познакомился с простым правилом управления любым проектом:
Если прошло 50% времени, проверь — выполнена ли половина работы
У многих людей в мозгу есть баг: к началу второй половины срока они обычно не осознают, что первая половина уже упущена. Грубо говоря, если вы пообещали сделать что-то через неделю, и прошло три дня, то без внешнего воздействия у вас не возникает ощущение «ааа, только половина времени осталась, пойду хуячить». Скорее будет «ой, да еще 4 дня есть, пойду погуляю».
Зато, если к вам подойти и рассказать об ушедшей половине, начинает работать магия, которая обычно включается только перед дедлайном — откидываются ненужные требования, игнорируются редкие юзкейсы, придумываются неожиданные творческие решения и т.д.
Кстати, этот вопрос можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок.
#тупое_правило
Ещё в студии я познакомился с простым правилом управления любым проектом:
Если прошло 50% времени, проверь — выполнена ли половина работы
У многих людей в мозгу есть баг: к началу второй половины срока они обычно не осознают, что первая половина уже упущена. Грубо говоря, если вы пообещали сделать что-то через неделю, и прошло три дня, то без внешнего воздействия у вас не возникает ощущение «ааа, только половина времени осталась, пойду хуячить». Скорее будет «ой, да еще 4 дня есть, пойду погуляю».
Зато, если к вам подойти и рассказать об ушедшей половине, начинает работать магия, которая обычно включается только перед дедлайном — откидываются ненужные требования, игнорируются редкие юзкейсы, придумываются неожиданные творческие решения и т.д.
Кстати, этот вопрос можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок.
#тупое_правило
Вот тут чувак анализирует вакансии в стартапах США для программистов Руби. Говорит, что спрос еще есть.
Немного смущает формулировка «еще» — кажется, что легкие в освоении MVC-решения на скриптовых языках будут жить еще долго: все-таки с ними приятно начинать бекендные проекты. На их стороне стороне документация, стабильность, количество батареек и легкость тестирования, а как следствие — очень высокая скорость разработки на одного программиста.
Кстати, на втором месте в том обзоре — моя любимая Django.
А как вы думаете, что стоит учить джуниору, чтобы найти работу в крутом айти-стартапе?
Немного смущает формулировка «еще» — кажется, что легкие в освоении MVC-решения на скриптовых языках будут жить еще долго: все-таки с ними приятно начинать бекендные проекты. На их стороне стороне документация, стабильность, количество батареек и легкость тестирования, а как следствие — очень высокая скорость разработки на одного программиста.
Кстати, на втором месте в том обзоре — моя любимая Django.
А как вы думаете, что стоит учить джуниору, чтобы найти работу в крутом айти-стартапе?
FEDOR BORSHEV via @vote
Что учить джуниору, чтобы найти работу в крутом ИТ-стартапе?
anonymous poll
Node.js😱 – 131
👍👍👍👍👍👍👍 58%
Джанго – 69
👍👍👍👍 31%
Рельсы – 25
👍 11%
👥 225 people voted so far.
anonymous poll
Node.js😱 – 131
👍👍👍👍👍👍👍 58%
Джанго – 69
👍👍👍👍 31%
Рельсы – 25
👍 11%
👥 225 people voted so far.
Фичреквесты, которые не стоит выполнять
Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.
Система рассылки счетов и контроля оплаты скорее всего начиналась как просьба бухгалтера покрасить все безналичные заказы в красный цвет. Интерфейс сбора обратной связи начинался с просьбы выгрузить заказы в эксель, «чтобы менеджеры видели, куда звонить»
Чтобы сырые фичи не уходили в работу, посередине между бизнесом и программистами всегда должен стоять человек, который преобразует сырые пользовательские запросы в задачи, которые приносят пользу.
Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:
— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным
Сделайте так, чтобы среди тех, кто обсуждает эти задачи, был хотя бы один человек, способный спросить «зачем?». Если вы не будете задавать такой вопрос каждой новой фиче, то ваш продукт раздуется до таких размеров, что действительно важным вещам просто не найдется места среди пяти разных выгрузок и выделений красным.
#чтобычто
Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.
Система рассылки счетов и контроля оплаты скорее всего начиналась как просьба бухгалтера покрасить все безналичные заказы в красный цвет. Интерфейс сбора обратной связи начинался с просьбы выгрузить заказы в эксель, «чтобы менеджеры видели, куда звонить»
Чтобы сырые фичи не уходили в работу, посередине между бизнесом и программистами всегда должен стоять человек, который преобразует сырые пользовательские запросы в задачи, которые приносят пользу.
Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:
— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным
Сделайте так, чтобы среди тех, кто обсуждает эти задачи, был хотя бы один человек, способный спросить «зачем?». Если вы не будете задавать такой вопрос каждой новой фиче, то ваш продукт раздуется до таких размеров, что действительно важным вещам просто не найдется места среди пяти разных выгрузок и выделений красным.
#чтобычто