Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!

Для начала несколько слов обо мне

Меня зовут Виталий Шароватов. Сейчас я – тимлид команды из 12 разработчиков в подразделении мобильного веба в Badoo. Уже полтора года я живу в Лондоне. Но на этой должности я оказался в результате довольно долгого пути, историю которого я расскажу далее.

Мне 32 года, общий опыт работы в индустрии — почти 15 лет. Начинал я, как и многие, с фриланса. Много и плодотворно занимался серверным программированием, немного – системным администрированием.

• Программировать начал с PHP 4, потом был PHP 5, писал на C# для ASP.NET MVC и ASP.NET Web Forms, писал на VBScript в ASP.
• Построил несколько систем с IE ActiveX-компонентами, интегрирующих клиентский код с разными устройствами (сканерами паспортов, сканерами штрихкодов, принтерами наклеек и так далее).
• Построил сеть, объединяющую три географически разделённых офиса на D-Link’ах DFL с дублированием канала и VPN.
• Администрировал Exchange, Windows 2003 AD.

Но больше всего я любил клиентскую разработку.

RealRussia. 2007–2012

Впервые я стал тимлидом в RealRussia. Это британская компания, занимающаяся въездным туризмом в Россию. Сначала она занималась только организацией получения российских туристических и бизнес-виз для англичан, но за время моей работы были созданы сервис заказа билетов на поезда, интегрированный с системой «Экспресс-3» и РЖД, сервис заказа отелей, а также полноценные интегрированные Workflow-бэкенды для обслуживания всех процессов.

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

Мне повезло, что рынок труда разработчиков на тот момент был наполнен предложениями, и нам удавалось нанимать людей, очень похожих на меня: у них было такое же отношение к работе (ответственность и проактивность), они относились практически к такому же личностному типу (по натуре я довольно энергичный, и с тяжёлыми на подъём коллегами мне было бы трудно сработаться). Работать в таком коллективе было очень просто, я не видел в этом какого-то вызова.

К тому же в то время я ещё не был уверен, что мне хочется заниматься руководством. Я был достаточно юн и хотел сосредоточиться на работе с JavaScript, поэтому через несколько лет работы тимлидом в RealRussia я переехал из города Волжский (Волгоградская область) в Москву и устроился в Mail.Ru Group на должность фронтенд-разработчика.

Mail.Ru Group. 2012–2015

После ухода из RealRussia я хотел найти какой-нибудь highload-проект, в котором было бы достаточно технических и организационных вызовов. В результате я стал фронтенд-разработчиком в проекте «Мой Мир», где занимался обычной продуктовой разработкой, а через некоторое время мне предложили работать над мобильной версией проекта.

Зная, что во всём мире уже давно очевиден тренд роста мобильного потребления контента, я, конечно же, согласился. Мои обязанности заключались во всё той же классической продуктовой разработке. Из интересного технически — в тот период я провёл исследование и реализовал полноценную поддержку работы сайта в Opera Mini.

Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными. Однако дальнейших возможностей роста в проекте я не видел, да и сама атмосфера и стиль управления мне не совсем подходили, времени на технические задачи стало меньше, а заметных результатов в управлении достичь не получалось.

Для меня всегда было важно видеть возможности роста, брать на себя больше ответственности и добиваться результатов. Поэтому, пройдя собеседование в Badoo, я снова решил отказаться от управления и вернуться на шаг назад – к должности разработчика. Я видел, что в этой компании я смогу пойти дальше.

Badoo. 2015–наши дни

В Badoo очень развита культура роста сотрудников внутри компании: Head of product вырос за несколько лет из Paralegal, CTO – из разработчика, большинство Heads of departments тоже выросли из разработчиков. Что уж говорить про тимлидов! Меня, как и многих других приходящих в компанию разработчиков, мотивированных перспективами роста и вызовами, не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа.

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

И сейчас я поделюсь с вами теми необычными знаниями, чувствами и опытом, которые я получил и испытал за эти годы. Ведь я не одинок на своём пути: многим разработчикам на определённом этапе своей карьеры приходится отвечать на вопрос: «Стоит ли мне становиться тимлидом?»

Расскажу, что вас ждёт, если вы решитесь. Начинаем с главных особенностей должности тимлида.

Особенности

Особенность №1. Ты и один, и не один

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

Неожиданно результаты работы всей команды становятся твоими собственными результатами. Я очень странно себя чувствовал первое время, заполняя свой отчёт по результатам месяца и внося в него что-то вроде «сделано столько-то продуктовых фичей», словно всё это сделал лично я.

То же самое относится и к проблемам. Ты уже не можешь сказать: «А, это Саня (Лёха, Андрюха) допустил баг!» Нет, за этот баг теперь отвечаешь именно ты вне зависимости от того, кто писал код.

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

Особенность №2. Неопределённость

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

Люди — не роботы, они могут болеть, уставать, терять мотивацию, быть счастливыми, злыми, грустными, могут конфликтовать, забывать что-то, могут быть очень продуктивными или наоборот. И раз ты отвечаешь за команду, то должен как минимум поддерживать её производительность. Нужно принять тот факт, что всё контролировать просто невозможно. Техническому специалисту осознать и принять это особенно сложно. Получается, что ты несёшь ответственность за результат и проблемы, но контролировать все факторы не можешь.

Особенность №3. Все разные

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

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

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

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

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

Ещё один пример в качестве иллюстрации. Программист всегда очень тщательно проводит ревью кода, искренне любит делать ревью «правильно», тратя на анализ кода по несколько часов, чтобы вникнуть во все детали. Но как тимлид ты знаешь, что для многих задач такая тщательность ревью просто избыточна. Станешь ли ты пытаться изменить подход своего сотрудника, попытаешься заставить его прекратить делать любимое дело и нанесёшь тем самым удар по его мотивации? Или лучше будет направить его усилия на ревью тикетов, где его страсть к такой работе принесёт максимальную выгоду?

Особенность №4. Нехватка знаний и опыта

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

Затем нужно научиться формировать эту атмосферу, создавать командный дух.

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

Когда начинаешь читать литературу по менеджменту, поражаешься тому, «насколько глубока кроличья нора»: как мало ты знаешь и как остро стоит проблема освоения нужных навыков. И, учитывая огромное количество информации по этой теме, очень трудно понять, с чего начать самообразование.

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

Особенность №5. Нехватка времени

Нужно быть готовым к тому, что никогда не будет хватать времени, чтобы сделать всё – всегда будет оставаться что-то, что нужно сделать.

А новый уровень неопределённости всегда влечёт за собой множество новых задач, которые необходимо срочно решить. Запросы от других команд, когда что-то идёт не так, эскалация проблем от разработчиков, административные вопросы и так далее.
Одна только поддержка текущих процессов разработки отнимает кучу времени. И чем больше людей в команде — тем больше времени: раз в две недели индивидуальные встречи с каждым сотрудником, kick-off-встречи и VQA, планёрки, ретроспективы, месячные оценки.

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

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

• Доверие. Ты понимаешь, что твоё задание по каким-то причинам может быть не выполнено вовремя (или вообще не выполнено). Все мы — живые люди, разработчики могут болеть, их производительность может снизиться, может случиться что-то ещё. Всегда есть риск.

• Техническая экспертиза. Есть вероятность, что в каком-то вопросе ты сильнее (или имеешь больше опыта), чем разработчик, которому ты ставишь задачу. Но ты не можешь делать всё сам не только по причине отсутствия времени – делегировать разработчикам сложные задачи необходимо для их роста и развития.

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

Особенность №6. Отвлекающие факторы

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

Однако этот навык сам по себе иногда становится проблемой. Привыкнув к частому переключению между делами, мозгу становится очень трудно сосредоточиться на чём-то одном, когда это необходимо. Начинает ощущаться почти физический дискомфорт из-за того, что не нужно переключать внимание, и ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры. Когда мне приходится фокусироваться на чём-то долгое время, я использую технику Pomodoro — какое-то время фокусируюсь полностью, а потом позволяю себе отвлечься на что-нибудь. Таким образом убирается психологический дискомфорт от того, что не удалось удержать внимание, – отвлечение фактически легитимизируется.

Из-за отвлекающих факторов поначалу ещё труднее планировать своё время, что может привести к работе без отдыха и сна. Ты думаешь: «Я только начинаю, поэтому должен быть максимально продуктивен. Поработаю пока по 11–14 часов день, чтобы быстрее достичь цели», работаешь в таком режиме месяц, два, три, «выгораешь», заболеваешь на несколько дней, а затем вновь вступаешь на этот порочный круг. Я через это прошёл и после нескольких циклов «переработка – «выгорание» – восстановление – переработка» заметил, что моя производительность всё больше и больше снижается.

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

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

Особенность №7. Компромиссы

Из-за всё той же нехватки времени постоянно приходится идти на компромиссы, выбирать приоритетные задачи и проблемы. Есть известный метод: сортируйте задачи по срочности, важности и по срочности + важности и действуйте в соответствии с получившимися списками. Но что делать, если даже список «срочно + важно» так велик, что не удаётся с ним разобраться в разумный срок?

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

Прежде чем заработала моя интуиция, я придерживался простого критерия «наименьшего из зол». Выбирая из двух задач, я спрашивал себя: что потеряет компания/ команда, если не будет выполнена одна из них?

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

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

Особенность №8. Политика компании

Главная цель расстановки приоритетов — оставаться как можно более эффективным в любых условиях.

И одно из условий, с которым постоянно сталкивается тимлид, — соблюдение баланса интересов компании в целом и своей команды в частности. Приходится постоянно быть «зонтиком», «фильтром», посредником, находиться под давлением со всех сторон, но действовать при этом исключительно в соответствии с приоритетами.

В моей практике была ситуация: очень квалифицированный и опытный QA-инженер требовал от разработчиков излишне высокого качества кода, а те не спорили с ним, а беспрекословно исправляли все баги, даже те, которые могли бы быть исправлены после развёртывания фичи (или которые вовсе не нужно было трогать). Мне в этом случае нужно было заметить проблему, обсудить и зафиксировать стандарт качества с product-менеджерами и техническими экспертами (разработчиками нашей команды и других отделов), выработать правила приоритезации багов, зафиксировать процесс исправления багов в соответствии с приоритетам в рамках принятого стандарта качества, а дальше следить, чтобы «проявления характера» (QA-инженер был очень настойчив) не мешали функционированию спроектированного процесса.

«В комплекте» с должностью тимлид получает очень высокий уровень ответственности за осуществление контроля над реализацией стратегии, над протеканием процессов и мотивацией. И действуя в соответствии с выбранной стратегией, нужно быть готовым получать обратную связь – как позитивную, так и негативную.

Особенность №9. Ты в ответе за всё

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

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

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

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

Результаты

Результат №1. Демотивация и мотивация

Я столкнулся с несколькими видами демотивации, и вы тоже можете с ними столкнуться.

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

Для меня ключевым фактором принятия окончательного решения стать тимлидом было чёткое видение того, что в компании нет потолка роста, и мне дадут столько ответственности, сколько я смогу и захочу на себя взять (и обязательно добиться результатов). В таких условиях хочется работать больше и продуктивнее, и демотивационные факторы нисколько не сдвигают чашу весов в свою сторону.
Ещё одна демотивационная вещь, с которой я столкнулся: все процессы идут настолько постепенно, что никогда не удастся всё улучшить в один присест.

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

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

В работе тимлида достаточно демотивирующих факторов. Но вряд ли люди становились бы тимлидами, если бы не было чего-то хорошего.

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

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

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

Результат №2. Победы

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

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

Поверьте, невероятно приятно в ответ на такую заботу получать положительную обратную связь со всех уровней.

Заключение и текущие достижения

Прошло больше года с тех пор, как я стал тимлидом в Badoo. И вот результаты команды мобильного веба.

• Команда выросла с четырёх до 12 разработчиков (лишь один разработчик за это время ушёл от нас по семейным обстоятельствам), все они имеют чёткий план роста и развития внутри команды и компании.
• Год назад мы доставляли в среднем одну фичу в неделю (иногда – меньше), теперь — до десяти фич в неделю. Кроме того, мы фиксим кучу багов, стали релизиться раз в день и чаще (а раньше релизились раз в одну – две недели), нагнали отставание в 200 продуктовых фич, ежедневно релизим что-то без QA (и нет, это не означает плохое качество фич).
• Была достигнута поставленная цель стать экспериментальной платформой — мы быстро проводим важные А/В-тестирования, на основании результатов которых другие команды выбирают, какой вариант идей продуктовых менеджеров стоит реализовать.

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

Если вы, несмотря на все «но», выбираете управление и начинаете с роли тимлида, я искренне желаю вам удачи! Учитесь, развивайтесь, каждый день спрашивайте себя: что можно было сделать лучше? что идёт не так? Будьте готовы к негативной обратной связи и воспринимайте её как инструмент роста; будьте честны с собой и сотрудниками, помогайте им развиваться и расти; научитесь находить удовольствие в построении островков порядка в море хаоса и неопределённости — и всё получится. Надеюсь, мой опыт будет вам полезен и, конечно, с удовольствием отвечу на любые вопросы.

P. S. Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.

iOS-разработчик: [описание]
Android-разработчик: [описание]

Автор:

Источник