Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

Когда я впервые стал тимлидом, я стал активно посещать конференции и читать умные книги об управлении командой. Однако в моей работе после этого менялось немногое. Я читал о том, каким я должен быть, в чём должен развиваться, но мне было неясно, что конкретно для этого нужно делать.

Мне пришлось не раз и не два наступить на одни и те же грабли, прежде чем я разобрался, что мешает наладить и улучшить мою работу. Поэтому для выступления на Saint TeamLead Conf я решил собрать из своего нынешнего опыта советы, которых мне не хватало на старте моей карьеры управленца. Эти вещи сильно упростили бы мне жизнь, если бы я знал о них раньше. 

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

Кто из нас не ронял продакшн, не обнаруживал, что база побилась, а бэкапов нет, не обваливал работу системы перед демо коммитом «ну сейчас рюшечку поправлю только, она же точно ничего не поломает», не выкатывал на всю аудиторию мобильное приложение со 100%-воспроизводящимся критичным багом, не обнаруживал продакшн-сервер взломанным, да мало ли бывает замечательных действий… Некомфортная ситуация влияет на наше состояние, не дает принимать взвешенные решения, заставляет поступать так, как в спокойной обстановке мы бы не поступили — только диву даешься, как же вот этого не увидел или вот этого не сделал. И хочется разобраться, что же происходит, понять, как лучше в следующий раз и вообще научиться с ним справляться. Как? В статье мы с AlbinoKoala систематизировали свой опыт и даже прочитали митап перед коллегами.

Сейчас мы вам расскажем про одну свежую работу, сделанную при участии компании Inflazome (http://inflazome.com/). Эта компания зарегистрирована в Ирландии, штаб-квартира в Дублине. Inflazome разрабатывает лекарства, специализируясь на воспалительных заболеваниях. Финансировалась работа несколькими испанскими грантами. Мы знаем, некоторые люди с недоверием относятся к исследованиям, которые спонсируют биотех-компании, но здесь не совсем тот случай. Все-таки работа была проведена за счет грантов.

Все исследование можно рассказать в двух предложениях: ученые создали мышиную линию, в которой нокаутирован ген NLRP3. В результате этого мыши жили примерно на 30% дольше, чем контрольные, и оставались более здоровыми. Вот посмотрите на график выживаемости. WT, голубая линия — wild type, мыши дикого типа, NLRP3-/-, красная линия — мыши с нокаутированным геном NLRP3. Правда мы точно не поняли но всего было около 60 мышей, но это не точно. Написали авторам, чтобы узнать наверняка.



И тут мы должны немного подумать. Ученые наконец-то нашли лишний ген, и если этот ген вырубить, можно продлить жизнь мышам на сколько-то процентов? Может, мне тоже вырубить себе этот ген?

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

Исходя из моего опыта, сразу хочу сказать, — описанные в статье переживания характерны, в первую очередь, для тиреоидита – повышенного титра антител к гормонам щитовидной железы.

Щитовидная железа и ее гормоны (отчасти и гормоны гипофиза) отвечают за темп психической деятельности. То, что произошло с masterdak связано со стремительным увеличением темпа психической деятельности, который в психиатрии называют маниакальным состоянием, манией или гипоманией. Эти термины пациенту наверняка приходилось слышать, точно также как и понятие «наплыв мыслей».

Чуть менее года назад я всерьез решил подтянуть английский, изучая его самостоятельно всеми доступными методами: прослушивание новостей, подкастов и книг, чтение художественной литературы, в том числе и в слух, ведение дневника и, конечно же, с помощью различных программ. Столкнувшись с последними, я понял, что можно написать аналоги как минимум не хуже. Что у меня в итоге получилось — под котом.

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

Посмотрите, например, на результат работы всего 251 байта JavaScript:


Ну, давайте разбираться, как это работает!

Недавно мне довелось побывать на встрече участников проекта FreeCodeCamp в Сан-Франциско. Если кто не знает, Free Code Camp — это сообщество, нацеленное на изучение JavaScript и веб-программирования. Там один человек, который готовился к собеседованиям на позицию фронтенд-разработчика, попросил меня подсказать, какие вопросы по JavaScript стоит проработать. Я немного погуглил, но не смог найти подходящего списка вопросов, на который я бы мог дать ссылку и сказать: «Разбери эти вопросы и работа твоя». Некоторые списки были близки к тому, что мне хотелось найти, некоторые выглядели очень уж простыми, но все они были либо неполными, либо содержали вопросы, которые вряд ли кто станет задавать на реальном собеседовании.

В конце января мы публиковали перевод на тему «Как я успешно прошел шесть собеседований в Кремниевой долине». Пришло время поделиться продолжением, где речь пойдет о более животрепещущей теме — о деньгах и о том, как получить больше.

«В течение недели мне предложили должность инженера-программиста в Google, Facebook, Amazon, Apple, LinkedIn и Yelp. Вот как я проходил у них собеседование.


Что если я скажу вам… что собеседования не так страшны, как кажется?

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

У каждого могут быть свои мотивы переехать в Армению, но есть несколько причин, которые заинтересуют каждого.

1. Большие показатели маленькой страны

В Армении проживает меньше 3 миллионов людей, в Ереване чуть больше миллиона, из них более 22 тысяч работает в IT секторе, это каждый 18-ый трудящийся. При этом еще около 3 тысяч вакансий остается незакрытыми.

Доля IT-сектора в ВВП Армении в 2017 году составила 7% и продолжает расти. По этому показателю Армения стоит на одном уровне с Эстонией, обходит США.

Всем привет, я снова выхожу на связь и посмотрите с чем! На фото — очень редкий (на 1989г. было выпущено 56 штук) сканирующий электронный микроскоп производства компании TESLA, выставленный в техническом музее г. Брно. Сверхвысоковакуумная колонна, катод с холодной полевой эмиссией позволили достичь гарантированного разрешения в 5нм и увеличения 500000x.



Мне удалось заполучить в свой гараж точно такой же микроскоп, пролежавший с 1990 года в нераспакованном виде. Обзор и все подробности процесса распаковки — под катом.

Привет всем!

Сегодня вашему вниманию предлагается перевод по-своему незаменимой статьи, которая поможет вам правильно подойти даже к самому коварному и нетривиальному ТЗ, которого вы на первый взгляд в упор не понимаете. Главное — не сдаваться и толково формулировать вопросы. Господин Джастин Фуллер из «Бэнк оф Америка» любезно излагает, как это правильно делается.



Приятного чтения!

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

Привет, Хабр! Представляю вашему вниманию перевод статьи Cutting Through the Complexity: A Roadmap for Effective Collaboration.

Сотрудничество привлекательно в своей концепции, но сложно на практике. Хоть и существуют крупные онлайн ресурсы для поддержки совместных усилий, например Community Tool Box, Intersector Project и NewNetworkLeader.org, факт остается фактом: мы, люди, просто не очень хорошо делаем «мы-работу». И тем не менее, большинство изменило своё мнение, и признаёт, что для решения сложных социальных и экологических проблем, с которыми мы сталкиваемся, мы должны научиться взаимодействию между организациями, секторами, сетями и взаимодействию с учётом наших различий во взглядах и подходах. Эффективное сотрудничество должно стать реальностью, а не только стремлением.

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

Основываясь на многих работах, мы разработали дорожную карту, которая преодолевает все эти сложности. Мы тестировали и совершенствовали эту структуру в течение многих лет в разных областях, и мы склонны применять её в духе статистика Джорджа Бокса, который, сказал: «Все модели ошибочны. Некоторые модели полезны». Мы нашли эту дорожную карту полезной и надеемся, что и другим она тоже будет полезна.

За последний месяц я провел 71 обучающий скайп-звонок с самыми разными компаниями. Задачей было внедрить разрабатываемую нами систему управления проектами. Запрос у всех согласившихся на такой формат примерно один и тот же — “Как втянуть команду в систему ведения проектом и в сам проект?”. Или проще говоря: “Как сделать так, чтобы все работали?”.

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



В этой статье — 10 ключевых рекомендаций по затягиванию команды в проект. Все высказанные ниже идеи подходят для работы в любой системе, но некоторые примеры приведены с интерфейсами нашего YouGile.

Важный факт — участники компаний после часового скайпа работали в нашей системе в 8.5 раз активнее в сравнении со средним пользователем. И в 2.3 раза активнее в сравнении с теми, кто согласился на скайп, но позднее отменил мероприятие.

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

Мы в Яндексе не только много работаем с фронтендом, но и делимся своим опытом с другими. За шесть лет преподавательской практики мы запустили разные форматы обучения, о которых сегодня расскажем читателям Хабра.

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

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

Я читал и читаю довольно много книг. Хорошие книги, которые мне понравилось, записываю, чтобы потом порекомендовать. Я решил сделать небольшую подборку must have книг, которые должен прочитать каждый начинающий руководитель. Одно из требований, чтобы эти книги были не только полезными, но и интересными. Книги должны заинтересовать человека развиваться в управлении, ни в коем случае не демотивировать.

предыдущие главы

20 Смещение и разброс: Два основных источника ошибок

замечание переводчика До изменения, данная глава называлась "Систематические и случайные: Два основных источника ошибок", т. е. я использовал термины "случайной ошибки" и "систематической ошибки" для перевода bias и variance. Однако, форумчанин робот@Phaker в комментарии справедливо заметил, что в области машинного обучения в русскоязычной терминологии для данных терминов закрепляются понятия "смещение" и "разброс". Я посмотрел работы К.В. Воронцова, который заслужено является одним из авторитетов в области машинного обучения в России и ресурсы профессионального сообщества, и согласился с замечанием робот@Phaker. Несмотря на то, что с моей точки зрения, между "смещением" (bias) и "разбросом" (variance) при обучении алгоритмов и "систематической ошибкой" и "случайной ошибкой" физического эксперимента существует глубокая содержательная аналогия, кроме того они одинаково выражаются математически, все же правильно использовать устоявшиеся в данной области термины. Поэтому я переработал перевод данной и последующих глав, заменив "Систематическую и Случайные ошибки" на "Смещение и Разброс" и буду придерживаться этого подхода в дальнейшем.

Привет, Хабр!

Этим постом начинается разбор задачек по алгоритмам, которые крупные IT-компании (Mail.Ru Group, Google и т.п.) так любят давать кандидатам на собеседованиях (если плохо пройти собеседование по алгоритмам, то шансы устроиться на работу в компанию мечты, увы, стремятся к нулю). В первую очередь этот пост полезен для тех, кто не имеет опыта олимпиадного программирования или тяжеловесных курсов по типу ШАДа или ЛКШ, в которых тематика алгоритмов разобрана достаточно серьезно, или же для тех, кто хочет освежить свои знания в какой-то определенной области.

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

Повествование будет разбито на разные темы, и начнем мы с генерирования множеств с определенной структурой.

Человеческие эмоции, как и любое другое явление, управляются определенными механизмами и законами, в данном случае, человеческого организма, а точнее мозга. Когда вы видите плачущего человека, то понимаете, что он опечален (горюет, грустит и т.д.). Понимая это, вы можете либо пройти мимо, либо сопереживать этому человеку. Умение сопереживать часто именуют эмпатией, и оно не является дефолтной настройкой нашего мозга с рождения. Его необходимо развивать. У кого-то это протекает быстрее и естественнее, у кого-то наоборот эмпатия притупляется. Кто-то может расплакаться при просмотре фильма «Хатико», а кто-то и бровью не поведет при просмотре документалки об Освенциме. Любой навык человека зависит от состояния систем его организма, от влияния родителей, общества в целом и прочего.

Ученые решили исследовать эмпатию и выбрали для этого самых подходящих испытуемых — подростков, ибо у них подобные навыки еще не сформированы полностью. Можно ли ускорить развитие эмпатии, можно ли ее «привить», и какие процессы протекают в головном мозге в момент сопереживания? Инструментом для поиска ответов послужила видеоигра, разработанная учеными специально для этого исследования. Какие результаты показали испытания мы узнаем благодаря отчету ученых. Поехали.

Навыки, которые IT-специалисты применяют в работе, делятся на два типа – hard skills («жёсткие навыки») и soft skills («гибкие навыки»). Первые – это профессиональные умения, которыми инженеры пользуются, решая технические задачи. Это, например, владение Java или знание Big Data-стека.

А что насчет вторых? Soft skills – это комплекс неспециализированных навыков, которые не менее важны в работе. Что это за умения, зачем они нужны айтишнику, как их развивать, почему инженеры с прокаченными «гибкими навыками» становятся все более востребованными, объясняет тимлид одной из команд тестировщиков EPAM и тренер в области soft skills Сергей Атрощенков.