Паттерны, только не программирования
Что-то стало модно в последнее время писать о том, какой должна быть идеальная компания, и какие практики в ней должны присутствовать, чтобы было freaking awesome, ну, или хотя бы super awesome.
В свете этих рассказов захотелось написать и про нас, то бишь Mochi Media. Про то, почему люди с большой неохотой уходят от нас. Почему почти все из них уходят делать собственные стартапы. Почему после этой компании действительно не хочется идти куда-то еще.
1. У нас работают люди, уважающие (любящие?) друг друга.
Банальные слова, но это первая компания, в которой я говорю это без тени сомнения или лукавства. Несколько примеров.
В мой последний приез обсуждали новую систему сбора и анализа логов. Спокойно и обстоятельно, аргументируя - короче, вполне себе такая научная беседа, только на техническую тему. Только камина и стаканчика грога не хватало для пущей атмосферности.
А в тот же день я спрашиваю нашего VP of Engineering: "Емэд, вы вообще хоть иногда в конторе ругаетесь? Ну, если там не согласны с чем-то, или если кто-то очень сильно накосячил, или еще чего-нибудь?". "Нет, - говорит, - самый серьезный файтинг - это то, что у нас сегодня на митинге было, когда ETL обсуждали".
Понимаете? Здесь даже сарказма не высказывается в чей-либо адрес, не говоря уж об открытой агрессии. Но что еще ужаснее - их не возникает! Никакого самоконтроля не требуется - это просто сложившаяся корпоративная культура, всем уже просто привычно общаться на этой волне. Делает ли народ над собой усилия в каких-то ситуациях? Наверное, да, но, похоже, крайне редко.
Тогда я спросил Емэда, как им удалось этого достичь. Не то чтобы ожидал услышать какой-то супер-секрет хаеринга, но мало ли. Но нет, все очень просто. "Well, we don't hire jerks. And, of course, we don't hire people who are bad in what they are doing."
Были ли исключения? Да, были, конечно. Незадолго до меня ушло несколько человек - они были проблемой именно в человеческом плане, хотя и эффективно работали. Кто-то бы сказал: "А, ладно, зато они дело хорошо делают". А нет, не ладно. Коллектив способен развалиться от одного-единственного деструктивного человека. Да, наверное, ребятам было неприятно просить их уйти, но такие вещи случаются.
С профессионализмом тоже все понятно. Со мной работают такие люди, что мне постоянно бывает стыдно, насколько я хуже их, и возникает лютое желание тянуться к этой планке. Отличная мотивация, кстати. Заодно прокачивает здоровое честолюбие.
Совместные походы в кино/на пикник/на обед и прочие общие мероприятия уже даже не в счет - это даже не тимбилдинг, это что-то органически выросшее из сложившихся между людьми отношений. Некоторые - так вообще поженились, встретившись в компании. Новеньким многие говорят "Welcome to the family!" И это не бравада - они, похоже, и правда так думают. Народ постоянно делится рабочими и нерабочими достижениями, часто проводит время вместе (с супругами и детьми и без них). Большинство бывших сотрудников приходит на мероприятия в компании, часто проводит свободное время с сотрудниками нынешними.
Короче, не бойтесь розовых соплей в компании и мира-дружбы-жвачки. Это работает, и это офигенно. И если нет постоянного чувства уважения ко всем сотрудникам без исключения - значит, что-то неправильно, и можно что-то сделать лучше.
2. Здесь терпимо относятся к косякам.
За свою недолгую карьеру программиста я как-то уже на всякое насмотрелся. За факапы штрафовали третью зарплаты, вызывали на ковер к начальству, наконец, выдавали розовую маечку... здесь нет даже маечек. Если говоришь кому-то: "у нас навернулся сервер X или приложение Y", в ответ услышишь максимум: "How can I help?".
После того, как косяк наконец поправлен, всех участников благодарят за участие в починке (Эффективным Менеджерам™ на заметку, это очень психологически важный момент), иногда - собираются вместе и устраивают мозговой штурм, как предупредить подобные проблемы в будущем (поменять базу данных, переделать архитектуру приложения, обновить документацию, формализовать какой-нибудь процесс работы).
Не могу сказать, что мы стали менее хуже косячить (мы никогда не косячили более лучше, по крайней мере, все то время, пока я в компании). Но серьезные проблемы и downtime'ы у нас возникают редко. А, что еще важнее - совершенно другое отношение к возникшим проблемам. Раньше у меня любой outage вызывал приступ паники ("что же делать, что же делать?!"), и никакого конструктива о том, как пофиксить проблему, в голове первые полчаса не появлялось. Диагноз был тем серьезнее, чем масштабнее был факап. Сейчас же - да, мне неприятно, да, я фрустрирую, но мозг тут же начинает думать в направлении решения проблемы.
И бесплатный бонус - чья бы вина ни была в возникшей проблеме, не будет дурацких разборов полетов, нравоучений и анальных наказаний. Если вы взяли на работу ответственного человека, самым серьезным наказанием для него будет осознание собственной вины.
Не знаю, были ли случаи, когда в компании кто-то косячил так часто, чтобы его приходилось увольнять. Не при мне, по крайней мере. Значит, либо степень ответственности как-то выявляется при найме работника (референсы, испытательный срок), либо даже люди, недостаточно собранные, становятся здесь ответственнее к своей работе. Скорее всего - обе вещи одновременно.
3. Автоматизация, тесты, документация и прочие годные инженерные практики
В последние года 2 или 3 стало популярно говорить о DevOps. После рассказов Гитхаба о Hubot'е народ стал массово заводить себе чат-ботов. Везде массовое увлечение unit- и integration-тестированием.
А я сидел и удивлялся, до чего же у нас прошаренные боссы. Дело в том, что у нас все эти девопсы с хаботами были на момент моего прихода уже хрен знает сколько времени. И CI уже был, тогда Хадсон еще не сменил свою фамилию на Дженкинс. И конфигурацию системы хранили в puppet'е. И деплоили при помощи самописной библиотеки. И куча служебных скриптов: просмотр логов со всех машин по заданному приложению, удаленный remsh на любую erlang-ноду, etc. И даже чат-бот свой уже давно был, с южным именем: juanita.
Уже несколько лет здесь правило: новый функционал - пиши тесты. Поэтому - минимум legacy кода, который боишься сломать. Есть куски, в которые боишься лезть (эрланг-модуль, создающий другой модуль, раздербанивающий его на бинарные куски и вставляющий в него какие-нибудь данные, by Bob Ippolito), но в работе которых ты уверен - потому что на эти куски есть тесты. Наконец, есть даже небольшие фреймворки для более простого тестирования, самописные и стыре^W опенсорсные.
Документация - вечно больная тема. Ее никогда не бывает достаточно, и она никогда не бывает достаточно упорядоченной, удобной и прозрачной. Мы не исключение, но - пишем, обновляем. В очень многих случаях помогает.
Кстати, нигде больше не видел подобной практики. Раз в месяц у нас устраивают день документации и тестов. Это значит, сидим и пишем какие-нибудь доки или улучшаем покрытие кода. На свой выбор, вкус и цвет.
Мониторим все уже черти с какого года. И СМСки исправно приходят, если что-то падает, либо нагрузка где-то слишком большая (очереди там выросли, например). И новые метрики понемногу добавляем, исходя из них потом покупаем новое железо, либо перегруппируем приложения по существующему.
4. Мы делаем все, чтобы не задерживаться на старом legacy. Пробуем новые технологии, рефакторим, переписываем, улучшаем. В пределах разумного.
Еще одна больная тема. Обычно слышишь: да, у нас тут в коде лапша, а здесь жуткий перфоманс, но у нас в бэклоге 100500 новых фич для разработки, а багов и того больше. Когда-нибудь и до этого доберемся. (Иногда еще добавляют: "а если у тебя свободного времени много - бери и делай что-то из нужного, у нас графики").
Что означает: никогда это место переписано не будет. Если только не попадает все к чертям от чрезмерной нагрузки. А если найдется критичный баг - вставят штук пятьдесят if'ов. А чо, все равно лапша, а переписывать времени нет.
Или, наоборот, другая крайность. Приходит новый человек и сразу начинает: а вот сюда бы Redis лучше подошел, а вот там код медленный какой-то... ой, мать моя женщина, что это за нафиг, я срочно переписываю вот это и это приложения! Этакий хомо улучшателис.
Например, меня тренировали на рефакторинговых задачах (впрочем, не только - и новые функционалы писал, и тесты делал - всего понемногу). Да и сейчас народ временами переписывает некоторые куски потихоньку. В качестве приятного побочного продукта появляются такие штуки, как statebox или recordset.
Раньше хранили статистику в Vertica, сейчас почти целиком перешли на HBase. Почти везде заменили Mnesia на Riak (и заменим до конца, как только оттестируем работу Secondary Indexes в риаке). Несколько приложений серьезно переписали при мне, одно я лично переписывал почти с нуля, поменяв архитектуру.
И, само собой, никто не запрещает, а только приветствует деятельность такого рода в свободное время, если есть желание. Впрочем, свободное время тут будет следующим пунктом.
UPD (спасибо _slw за замечание): Для большей наглядности, посмотрел в багтрекер. На каждую сотню тикетов минимум 4-5 - рефакторинг, иногда около десятка (но в этой сотне вообще все задачи: инженерные, хозяйственные, юридические, организационные). Из лично моих выполеннных задач, рефакторинг или переписывание - чуть меньше трети.
5. 20% of your working time for your own projects
Что угодно. Сайд-проекты для будущего стартапа, интересные опенсорсные проекты, или работа над существующими компании.
Когда я делал доклад об опенсорсе на ULCAMP::DEV, эта тема вызвала много вопросов. Зачем отрезать кусок рабочего времени для этого? Пусть человек пишет в опенсорс в свое свободное время, а в рабочее - работу работает. И тогда единственные хороший ответ, пришедший мне в голову был - чтобы человек не варился в одном и том же контексте, а занимался разными задачами: это развивает гибкость ума, это помогает на некоторые проблемы по-другому смотреть, наконец, это же интереснее! И потом, в работе тоже бывают белые и черные полосы. Иногда рутина тянется месяцами, а вот интересный сторонний проект мог бы мотивировать, держать в тонусе.
А потом, много позже, пришло в голову: у нас в конторе больше чем у половины сотрудников есть семьи. Жены или мужья, дети, родители. А еще друзья, хобби. Какие там сайд-проекты? У людей бывает жизнь столь насыщенная, что на сон время жалко тратить. И это офигенный жест со стороны компании - дать человеку время на то, чтобы работать над интересными ему вещами.
Наконец, не забывайте: GMail был всего лишь сайд-проектом. Один этот проект, ящетаю, оправдал эти 20% свободного времени для гугловцев (у них тоже есть такая практика; наверняка у нас собезъянничали :P). Когда-нибудь и у нас появится свой GMail, после которого скажут: один этот проект с лихвой окупил все те часы.
6. Мы не злоупотребляем менеджментом и формализмом
Едва ли не с момента найма первого инженера у нас есть "летучки", они же standup meetings (сейчас заменили на standup emails - команда распределенная, да и народ нередко работает из дома). По понедельникам быстро, в течение получаса, проводим итоги прошлой недели.
Иерархии же типа product owner, scrum master и всех этих прочих штук - нет. Дело в том, что топ-менеджмент постоянно посвящает нас в новые идеи, направления развития, достижения, и прочее. Мы уже в курсе, что нам нужно делать. Если иногда есть сомнения - идем и советуемся с тем самым топ-менеджментом.
Вроде бы, народ в свое время пробовал SCRUM, но быстро от него отказался. То ли в силу небольшого числа инженеров (шестеро^W уже пятеро в Штатах, пятеро на Тайвани, один в Нидерландах и покорный слуга в России), то ли в силу слаженности команды, но мы тратим меньше часа времени на планирование ближайшей недели-двух, без формализации всего процесса. Я процентов на 50-70 знаю, чем буду заниматься в ближайшие год-полтора; если мне не подкидывать задачи извне - дел все равно хватит, достаточно важных.
Вообще, близость разработки и менеджмента у нас кажется мне иногда феноменальной. Вероятно, дело в том самом пресловутом уважении (см. пункт 1) и в постоянной коммуникации (причем не в формате "начальник-подчиненный", а в порядке "сотрудник-сотрудник"). Мы всерьез относимся к их бизнес-требованиям, а они, в свою очередь - к нашим техническим сложностям, целям и средствам.
Как-то так. Почти все, кто уходит, говорят, что это лучшая компания, в которой им доводилось работать. Многие вырастают здесь до собственных стартапов. Многие работают года по 3-4 (это нонсенс для Силиконовой Долины, там принято менять работу раз в год).
TL;DR: Ничего нового я тут не сказал. Просто люди, основавшие компанию, не только классные специалисты и просто умные чуваки, но и очень хорошие люди. И набирали себе в команду таких же. И теперь мы делаем так же.
В конце я, наверное, должен был написать "P.S. We are hiring!"
Но не так уж мы и hiring. Сейчас на джоб-борде всего 3 вакансии, все в Сан-Франциско. Но если очень хочется - может, мой предыдущий пост поможет.
В свете этих рассказов захотелось написать и про нас, то бишь Mochi Media. Про то, почему люди с большой неохотой уходят от нас. Почему почти все из них уходят делать собственные стартапы. Почему после этой компании действительно не хочется идти куда-то еще.
1. У нас работают люди, уважающие (любящие?) друг друга.
Банальные слова, но это первая компания, в которой я говорю это без тени сомнения или лукавства. Несколько примеров.
В мой последний приез обсуждали новую систему сбора и анализа логов. Спокойно и обстоятельно, аргументируя - короче, вполне себе такая научная беседа, только на техническую тему. Только камина и стаканчика грога не хватало для пущей атмосферности.
А в тот же день я спрашиваю нашего VP of Engineering: "Емэд, вы вообще хоть иногда в конторе ругаетесь? Ну, если там не согласны с чем-то, или если кто-то очень сильно накосячил, или еще чего-нибудь?". "Нет, - говорит, - самый серьезный файтинг - это то, что у нас сегодня на митинге было, когда ETL обсуждали".
Понимаете? Здесь даже сарказма не высказывается в чей-либо адрес, не говоря уж об открытой агрессии. Но что еще ужаснее - их не возникает! Никакого самоконтроля не требуется - это просто сложившаяся корпоративная культура, всем уже просто привычно общаться на этой волне. Делает ли народ над собой усилия в каких-то ситуациях? Наверное, да, но, похоже, крайне редко.
Тогда я спросил Емэда, как им удалось этого достичь. Не то чтобы ожидал услышать какой-то супер-секрет хаеринга, но мало ли. Но нет, все очень просто. "Well, we don't hire jerks. And, of course, we don't hire people who are bad in what they are doing."
Были ли исключения? Да, были, конечно. Незадолго до меня ушло несколько человек - они были проблемой именно в человеческом плане, хотя и эффективно работали. Кто-то бы сказал: "А, ладно, зато они дело хорошо делают". А нет, не ладно. Коллектив способен развалиться от одного-единственного деструктивного человека. Да, наверное, ребятам было неприятно просить их уйти, но такие вещи случаются.
С профессионализмом тоже все понятно. Со мной работают такие люди, что мне постоянно бывает стыдно, насколько я хуже их, и возникает лютое желание тянуться к этой планке. Отличная мотивация, кстати. Заодно прокачивает здоровое честолюбие.
Совместные походы в кино/на пикник/на обед и прочие общие мероприятия уже даже не в счет - это даже не тимбилдинг, это что-то органически выросшее из сложившихся между людьми отношений. Некоторые - так вообще поженились, встретившись в компании. Новеньким многие говорят "Welcome to the family!" И это не бравада - они, похоже, и правда так думают. Народ постоянно делится рабочими и нерабочими достижениями, часто проводит время вместе (с супругами и детьми и без них). Большинство бывших сотрудников приходит на мероприятия в компании, часто проводит свободное время с сотрудниками нынешними.
Короче, не бойтесь розовых соплей в компании и мира-дружбы-жвачки. Это работает, и это офигенно. И если нет постоянного чувства уважения ко всем сотрудникам без исключения - значит, что-то неправильно, и можно что-то сделать лучше.
2. Здесь терпимо относятся к косякам.
За свою недолгую карьеру программиста я как-то уже на всякое насмотрелся. За факапы штрафовали третью зарплаты, вызывали на ковер к начальству, наконец, выдавали розовую маечку... здесь нет даже маечек. Если говоришь кому-то: "у нас навернулся сервер X или приложение Y", в ответ услышишь максимум: "How can I help?".
После того, как косяк наконец поправлен, всех участников благодарят за участие в починке (Эффективным Менеджерам™ на заметку, это очень психологически важный момент), иногда - собираются вместе и устраивают мозговой штурм, как предупредить подобные проблемы в будущем (поменять базу данных, переделать архитектуру приложения, обновить документацию, формализовать какой-нибудь процесс работы).
Не могу сказать, что мы стали менее хуже косячить (мы никогда не косячили более лучше, по крайней мере, все то время, пока я в компании). Но серьезные проблемы и downtime'ы у нас возникают редко. А, что еще важнее - совершенно другое отношение к возникшим проблемам. Раньше у меня любой outage вызывал приступ паники ("что же делать, что же делать?!"), и никакого конструктива о том, как пофиксить проблему, в голове первые полчаса не появлялось. Диагноз был тем серьезнее, чем масштабнее был факап. Сейчас же - да, мне неприятно, да, я фрустрирую, но мозг тут же начинает думать в направлении решения проблемы.
И бесплатный бонус - чья бы вина ни была в возникшей проблеме, не будет дурацких разборов полетов, нравоучений и анальных наказаний. Если вы взяли на работу ответственного человека, самым серьезным наказанием для него будет осознание собственной вины.
Не знаю, были ли случаи, когда в компании кто-то косячил так часто, чтобы его приходилось увольнять. Не при мне, по крайней мере. Значит, либо степень ответственности как-то выявляется при найме работника (референсы, испытательный срок), либо даже люди, недостаточно собранные, становятся здесь ответственнее к своей работе. Скорее всего - обе вещи одновременно.
3. Автоматизация, тесты, документация и прочие годные инженерные практики
В последние года 2 или 3 стало популярно говорить о DevOps. После рассказов Гитхаба о Hubot'е народ стал массово заводить себе чат-ботов. Везде массовое увлечение unit- и integration-тестированием.
А я сидел и удивлялся, до чего же у нас прошаренные боссы. Дело в том, что у нас все эти девопсы с хаботами были на момент моего прихода уже хрен знает сколько времени. И CI уже был, тогда Хадсон еще не сменил свою фамилию на Дженкинс. И конфигурацию системы хранили в puppet'е. И деплоили при помощи самописной библиотеки. И куча служебных скриптов: просмотр логов со всех машин по заданному приложению, удаленный remsh на любую erlang-ноду, etc. И даже чат-бот свой уже давно был, с южным именем: juanita.
Уже несколько лет здесь правило: новый функционал - пиши тесты. Поэтому - минимум legacy кода, который боишься сломать. Есть куски, в которые боишься лезть (эрланг-модуль, создающий другой модуль, раздербанивающий его на бинарные куски и вставляющий в него какие-нибудь данные, by Bob Ippolito), но в работе которых ты уверен - потому что на эти куски есть тесты. Наконец, есть даже небольшие фреймворки для более простого тестирования, самописные и стыре^W опенсорсные.
Документация - вечно больная тема. Ее никогда не бывает достаточно, и она никогда не бывает достаточно упорядоченной, удобной и прозрачной. Мы не исключение, но - пишем, обновляем. В очень многих случаях помогает.
Кстати, нигде больше не видел подобной практики. Раз в месяц у нас устраивают день документации и тестов. Это значит, сидим и пишем какие-нибудь доки или улучшаем покрытие кода. На свой выбор, вкус и цвет.
Мониторим все уже черти с какого года. И СМСки исправно приходят, если что-то падает, либо нагрузка где-то слишком большая (очереди там выросли, например). И новые метрики понемногу добавляем, исходя из них потом покупаем новое железо, либо перегруппируем приложения по существующему.
4. Мы делаем все, чтобы не задерживаться на старом legacy. Пробуем новые технологии, рефакторим, переписываем, улучшаем. В пределах разумного.
Еще одна больная тема. Обычно слышишь: да, у нас тут в коде лапша, а здесь жуткий перфоманс, но у нас в бэклоге 100500 новых фич для разработки, а багов и того больше. Когда-нибудь и до этого доберемся. (Иногда еще добавляют: "а если у тебя свободного времени много - бери и делай что-то из нужного, у нас графики").
Что означает: никогда это место переписано не будет. Если только не попадает все к чертям от чрезмерной нагрузки. А если найдется критичный баг - вставят штук пятьдесят if'ов. А чо, все равно лапша, а переписывать времени нет.
Или, наоборот, другая крайность. Приходит новый человек и сразу начинает: а вот сюда бы Redis лучше подошел, а вот там код медленный какой-то... ой, мать моя женщина, что это за нафиг, я срочно переписываю вот это и это приложения! Этакий хомо улучшателис.
Например, меня тренировали на рефакторинговых задачах (впрочем, не только - и новые функционалы писал, и тесты делал - всего понемногу). Да и сейчас народ временами переписывает некоторые куски потихоньку. В качестве приятного побочного продукта появляются такие штуки, как statebox или recordset.
Раньше хранили статистику в Vertica, сейчас почти целиком перешли на HBase. Почти везде заменили Mnesia на Riak (и заменим до конца, как только оттестируем работу Secondary Indexes в риаке). Несколько приложений серьезно переписали при мне, одно я лично переписывал почти с нуля, поменяв архитектуру.
И, само собой, никто не запрещает, а только приветствует деятельность такого рода в свободное время, если есть желание. Впрочем, свободное время тут будет следующим пунктом.
UPD (спасибо _slw за замечание): Для большей наглядности, посмотрел в багтрекер. На каждую сотню тикетов минимум 4-5 - рефакторинг, иногда около десятка (но в этой сотне вообще все задачи: инженерные, хозяйственные, юридические, организационные). Из лично моих выполеннных задач, рефакторинг или переписывание - чуть меньше трети.
5. 20% of your working time for your own projects
Что угодно. Сайд-проекты для будущего стартапа, интересные опенсорсные проекты, или работа над существующими компании.
Когда я делал доклад об опенсорсе на ULCAMP::DEV, эта тема вызвала много вопросов. Зачем отрезать кусок рабочего времени для этого? Пусть человек пишет в опенсорс в свое свободное время, а в рабочее - работу работает. И тогда единственные хороший ответ, пришедший мне в голову был - чтобы человек не варился в одном и том же контексте, а занимался разными задачами: это развивает гибкость ума, это помогает на некоторые проблемы по-другому смотреть, наконец, это же интереснее! И потом, в работе тоже бывают белые и черные полосы. Иногда рутина тянется месяцами, а вот интересный сторонний проект мог бы мотивировать, держать в тонусе.
А потом, много позже, пришло в голову: у нас в конторе больше чем у половины сотрудников есть семьи. Жены или мужья, дети, родители. А еще друзья, хобби. Какие там сайд-проекты? У людей бывает жизнь столь насыщенная, что на сон время жалко тратить. И это офигенный жест со стороны компании - дать человеку время на то, чтобы работать над интересными ему вещами.
Наконец, не забывайте: GMail был всего лишь сайд-проектом. Один этот проект, ящетаю, оправдал эти 20% свободного времени для гугловцев (у них тоже есть такая практика; наверняка у нас собезъянничали :P). Когда-нибудь и у нас появится свой GMail, после которого скажут: один этот проект с лихвой окупил все те часы.
6. Мы не злоупотребляем менеджментом и формализмом
Едва ли не с момента найма первого инженера у нас есть "летучки", они же standup meetings (сейчас заменили на standup emails - команда распределенная, да и народ нередко работает из дома). По понедельникам быстро, в течение получаса, проводим итоги прошлой недели.
Иерархии же типа product owner, scrum master и всех этих прочих штук - нет. Дело в том, что топ-менеджмент постоянно посвящает нас в новые идеи, направления развития, достижения, и прочее. Мы уже в курсе, что нам нужно делать. Если иногда есть сомнения - идем и советуемся с тем самым топ-менеджментом.
Вроде бы, народ в свое время пробовал SCRUM, но быстро от него отказался. То ли в силу небольшого числа инженеров (шестеро^W уже пятеро в Штатах, пятеро на Тайвани, один в Нидерландах и покорный слуга в России), то ли в силу слаженности команды, но мы тратим меньше часа времени на планирование ближайшей недели-двух, без формализации всего процесса. Я процентов на 50-70 знаю, чем буду заниматься в ближайшие год-полтора; если мне не подкидывать задачи извне - дел все равно хватит, достаточно важных.
Вообще, близость разработки и менеджмента у нас кажется мне иногда феноменальной. Вероятно, дело в том самом пресловутом уважении (см. пункт 1) и в постоянной коммуникации (причем не в формате "начальник-подчиненный", а в порядке "сотрудник-сотрудник"). Мы всерьез относимся к их бизнес-требованиям, а они, в свою очередь - к нашим техническим сложностям, целям и средствам.
Как-то так. Почти все, кто уходит, говорят, что это лучшая компания, в которой им доводилось работать. Многие вырастают здесь до собственных стартапов. Многие работают года по 3-4 (это нонсенс для Силиконовой Долины, там принято менять работу раз в год).
TL;DR: Ничего нового я тут не сказал. Просто люди, основавшие компанию, не только классные специалисты и просто умные чуваки, но и очень хорошие люди. И набирали себе в команду таких же. И теперь мы делаем так же.
В конце я, наверное, должен был написать "P.S. We are hiring!"
Но не так уж мы и hiring. Сейчас на джоб-борде всего 3 вакансии, все в Сан-Франциско. Но если очень хочется - может, мой предыдущий пост поможет.