Делать продукты для программистов приятно и просто

JetBrains

Andrey Ivanov, JetBrains COO

Многие удивляются, узнав, что компания JetBrains создана нашими соотечественниками. На сегодняшний день эти ребята успели заработать прекрасную репутацию, создавая продукты, которые можно определить как «программы для программеров». Инвесторы сетуют, что JetBrains не берет денег и не желает превращаться в огромную корпорацию. Конкуренты не стесняются «заимствовать» решения JetBrains, перетаскивая их в свои разработки. Но что происходит в самой JetBrains, что за люди стоят за созданием компании и таких продуктов, как IntelliJ IDEA? Подробно об этом и многом другом рассказал нам COO компании Андрей Иванов.

Правильная IDE

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

Делать продукты для программистов приятно и просто. Потому что понятно. Хотя, конечно, приходится решать сложные технические задачи.

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

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

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

Как люди переходят на Mac? Просто «так получается». Само. Посидел ты за Mac’ом пять минут, попробовал, поработал, и уже хочется его купить. Нужно делать такие же IDE. Чтобы к тебе пришел товарищ, сказал: «Дай покажу, как я это делаю», ты посидел пять минут в IDE, попрограммировал и тебе бы захотелось переключиться.

Создание IntelliJ IDEA

Нашим первым продуктом был Renamer — небольшая программа, которая позволяла делать самый простой рефакторинг — переименование для программ на языке Java. То есть переименовываем класс, пакет, метод или переменную — и все ссылки на него тоже переименовываются. Программа также позволяла перемещать классы между пакетами. Вторым продуктом был CodeSearch — это был плагин к JBuilder (популярной в то время IDE от Borland), который позволял быстро и точно находить все использования данного символа (метода, класса) во всей программе. Однако с самого начала целью было создание полноценной IDE — эти два продукта было решено выпустить по пути, чтобы получить какой-то опыт и обратную связь от пользователей.

Следующий наш продукт, который был и до сих пор остается флагманским, — IntelliJ IDEA. Долгое время нам хватало и этого, ведь IDE такого класса на рынке просто не было (с таким набором функциональности). JBuilder безнадежно проигрывал, а в компании Borland тогда происходили такие процессы… словом, было понятно, что долго он не протянет. Хотя он протянул значительно дольше, чем можно было предсказать. Лет пять это была «компания-зомби». В общем, все было замечательно, пока не появилась Eclipse.

Чтобы конкурировать с бесплатным продуктом, мы выделили платформу, сделали community edition (Open Source), а поверх платформы создать продукты для разных ниш.

По сути, мы и сами решили в каком-то смысле пойти по пути Eclipse. В итоге у нас появились точечные IDE: PyCharm для Python, RubyMine для Ruby, WebStorm для JavaScript, PhpStorm для PHP. Последний, к слову, через какое-то время вообще может стать самым продаваемым продуктом. PHP-программисты не избалованы хорошим IDE, а тут…

Все они базируются на платформе, которая выделена из IDEA. Одним словом, community edition и платформа — это довольно близкие вещи. Все остальное — надстройки. Ultimate Edition — своего рода сумма перечисленных продуктов.

Как пережить затмение

Знаете, как создавали Eclipse? Команда из Швейцарии, которой руководил Эрих Гамма, на деньги IBM (но тогда частью IBM она еще не была) с нуля построила сначала платформу, а потом, поверх этой платформы, среду разработки.

Эрих Гамма тогда был легендой, потому что как соавтор написал книгу Design Patterns: Elements of Reusable Object-Oriented Software («Приемы объектно-ориентированного проектирования. Паттерны проектирования»). Ее авторами были так называемые Gang of Four (Ричард Хелм, Ральф Джонсон, Джон Влиссидес и Эрих Гамма).

Создатели компании много с ними общались, рассказывали, мол, какие идеи! Посмотрите, у нас Eclipse копировала! Это никого не волновало, Дмитриев всегда ратовал за то, что идеи должны «гулять» в свободном доступе, это приводит к развитию индустрии.

Eclipse была для IBM комплементарным продуктом. Приведу пример: авиабилеты в Лас-Вегас стоят очень дешево. Потому что туристы оставляют столько денег, что прибыль будет несравнима с тем, сколько вы затрачиваете на авиабилеты. У IBM был похожий подход к Eclipse: давайте вложим огромные деньги в разработку, бесплатно всех подсадим, и люди, которые сядут на эту платформу, окажутся каким-то образом связаны с нами, будут заказывать другие продукты.

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

JetBrains пришлось диверсифицировать продукты, придумывать новые направления. Теперь, когда мы возвращаемся к тем временам и вспоминаем, мы думаем, что это хорошо. Это дало определенный толчок: теперь мы не компания одного продукта, а компания пятнадцати продуктов.

Схожая конкуренция у нас возникла и на рынке IDE под Mac. Для этой платформы мы выпускаем среду AppCode. Это та область, где нужны маркетинговые усилия, нужно как-то убедить людей попробовать. Ведь XCode такой родной, его сама Apple предлагает — как же с него уйти…

Плюс все приложения, основанные на платформе IDEA, написаны на Java. А писать под Mac на Java — рискованное занятие по ряду причин. Программа выглядит не так, как остальные Mac’овские программы, плюс постоянно идет возня — до какой степени поддерживается JDK, какие взаимоотношения у Apple и Oracle. Но наш AppCode, конечно, лучше XCode :).

Другие продукты JetBrains

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

Следующая категория продуктов — инструменты, поддерживающие командную разработку.

TeamCity — продукт, поддерживающий непрерывную интеграцию (continuous integration) — практику разработки ПО, заключающуюся в выполнении частых автоматизированных сборок проекта для скорейшего обнаружения в нем интеграционных проблем. Для небольших команд TeamCity доступен бесплатно.

Достаточно долго у нас существует такая «штука» — MPS (Meta Programming System). Также довольно давно появилась книга Кшиштофа Чернецки «Generative Programming». В книге была изложена следующая мысль: если мы хотим превратить программирование в нечто подобное промышленной разработке для автомобилей, нужно наладить своего рода «конус» производителей. Компонент и компания, которая из этого компонента собирает компоненты более высокого уровня. И так вплоть до продуктов. Если мы сумеем все это выстроить, программирование станет генеративным, можно будет описывать то, что хотите, с помощью неких DSL, очень близких по семантике к человеческому языку и к языку домена. Описывать, а после запускать генератор и получать готовую программу.

Эта идея получила множество разных воплощений, не только от компании JetBrains. К примеру, в моей «прошлой жизни» в Borland, в конце моего там пребывания, ребята разрабатывали такую штуку для Eclipse — Generating Modeling Framework. Они пытались сделать это для диаграмм, чтобы можно было описать диаграмму и она бы сгенерировалась.

Возвращаясь к MPS — идея его создать принадлежала Сергею Дмитриеву. Некое подобие генеративного программирования, свой подход он тогда называл Language Oriented Programming. Мысль была следующая: прежде чем писать программу в каком-то домене, вы создаете язык, который описывает этот домен, описываете правила, по которым конструкции этого языка генерятся в языки более низких уровней, а потом уже программируете. После такой предварительной работы дальнейшее программирование очень простое.

Был построен некий изначальный стек языков: внизу «лежала» Java, но над ней были некоторые надстройки. И в какой-то момент возникло желание и потребность доказать состоятельность этой концепции, не только как академического изыска, но и как работающей системы, в рамках которой можно создать реальное промышленное приложение. Так и появился YouTrack, очень интересный продукт для багтрекинга и управления проектами.

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

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

Сейчас Kotlin — проект уже достаточно зрелый, над ним работает команда из восьми человек. Релиза пока не было, и публично мы анонсировали его совсем недавно. В общем-то, до того, как люди смогут писать на Kotlin свои программы, я думаю, пройдет еще года полтора.

При этом интересно, что JVM — виртуальная машина, на которой исполняются скомпилированные программы на Java, — развивается значительно быстрее, чем сам язык. В версии 7, например, в JVM появилась инструкция invokedynamic, которая никак не используется компилятором языка Java и предназначена для разработчиков компиляторов других языков. Поэтому многие создаваемые языки — в том числе Kotlin — компилируются в JVM.

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

Хотелось сделать лаконичный язык. Известно, что программисты тратят много времени на чтение кода, поэтому конструкции, доступные в языке программирования, должны позволять писать программы кратко и понятно. Java считается многословным языком, мы стараемся улучшить ситуацию.

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

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

Kotlin — Open Source проект, можно принять участие в его разработке. В JetBrains над проектом работает команда из восьми человек. На сегодняшний день выпущено несколько промежуточных ранних релизов компилятора и плагина к IDE. Уже сейчас можно пробовать Kotlin в деле, хотя пока это лучше делать на тестовых примерах.

Программируют все

Говоря формально, JetBrains — компания не отечественная. Корни у нее не только российские. RnD и все остальное — наше. Примерно 90% сотрудников — русские. Но номинально штаб-квартира находится в Чехии. JetBrains изначально существовала как чешская компания — это простое стечение обстоятельств.

Началось все с компании TogetherSoft, команда которой появилась в Питере. В середине 90-х из Германии в Питер приехал Дитрих Каризиус — с идеей продукта. Он заключил контракт с Николаем Григорьевичем Пунтиковым, который сейчас руководит оргкомитетом конференции SECR, а тогда еще только начинал компанию StarSoft. Они и собрали команду.

В 1998 году, когда начался кризис, американцы, получившие долю в Together, решили, что хороших программистов срочно нужно вывозить из Питера в Европу. Рассматривали в качестве варианта Германию, но в итоге выбрали Чехию.

Топовая команда TogetherSoft (около 50 человек) уехала в Прагу в 1999 году.Среди них были и и три будущих основателя JetBrains: Сергей Дмитриев, Валентин Кипятков и Евгений Беляев.

TogetherSoft тоже занималась разработкой продуктов для девелоперов.TogetherSoft делала modeling tools. Тогда была мода на средства моделирования, причем стандартов вроде UML еще не было. Разные гуру придумывали различные методологии, которые друг от друга отличались, например, тем, как рисовать классы.

Какое-то время мы поработали там все вместе. В конце 1999 года под руководством Сергея был выпущен TogetherJ 3.0 — существенно обновленная версия продукта, разработка которой заняла почти два года. Примерно в это же время TogetherSoft получила серьезные инвестиции. При этом у Сергея давно была мысль сделать свой бизнес, зрела идея продукта. Было понятно, что нужно либо уходить, либо связывать себя с TogetherSoft еще на несколько лет. Ребята выбрали первое. Сергей ушел из компании в феврале. Это было в Праге, где он сел и начал программировать. Месяца через три к нему присоединился Женя, а потом, еще месяцев через пять, — Валя. Я после этого возглавил разработку продуктов Together и занимался этим еще шесть лет — сначала в TogetherSoft, а потом в Borland.

JetBrains — это компания, где программируют все. Кроме разве что бухгалтерии. Вот у нас есть два CEO (да, такая оригинальная концепция, не один CEO, а сразу двое), они оба активно программируют. На мой вкус, это занятие более интересное, чем руководство.

Кстати, в JetBrains даже мне пришлось писать какие-то куски кода. Когда я пришел в компанию, Дмитриев сказал мне: «Андрей, извини, я понимаю, ты десять лет редактора, кроме Word, не видел, но у нас все программируют. Сделай вот эту систему». Я запрограммировал систему release-management’а. На это у меня ушло какое-то время, и после меня оставили в покое. Сейчас я опять не программирую, но было дело, вспомнил, как это.

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

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

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

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

Если не ставить задачу заработать миллион долларов и купить шесть домов на Канарах, не ставить задачу выйти на IPO (потому что все выходят), возникает вопрос «А зачем?» Того оборота и той прибыли, которую JetBrains имеет сейчас, хватает на то, чтобы решать все задачи, которые перед нами встают. А также на то, чтобы все люди, работающие в компании, считали, что у них все хорошо. Нет никаких движущих механизмов, чтобы терять нашу свободу и культуру ради денег.

Я регулярно общаюсь с людьми, которые хотят что-то сделать — куда-то вложиться, что-то купить. Я объясняю им то, о чем сказал выше… но многие не понимают. «У тебя же могло быть в десять раз больше!» — говорят они.

В истории есть всего один-два примера, когда выход на IPO не принес компании вреда. Сейчас я говорю вещи «не общеупотребительные», но все же. После IPO появляются факторы (связанные не с продуктами и технологиями, а уже с предсказаниями аналитиков и так далее), влияющие на решения, принимаемые в компании.

Закат Borland

Borland — компания с продолжительной и драматичной историей. Впервые она заявила о себе в ноябре 1983 года, выпустив Turbo Pascal. Фактически это была первая на рынке IDE. Многие поколения учились программировать, пользуясь этой средой разработки.

Есть такое выражение: «если не можешь быть хорошим примером, придется служить предостережением». Borland удалось и то и другое.

У Borland было две «вредные» привычки. Первая — расширяться, покупая компании, причем не особо задумываясь о том, как покупка «впишется» в текущую продуктовую линейку. Так, в 1991 году, уже имея в своей линейке успешную систему управления базами данных Paradox, Borland приобрела Ashton Tate с их продуктом dBase, что впоследствии стоило рынка обоим продуктам. Вторая — уходить от производства инструментов для разработчика в более популярные, с точки зрения аналитиков, области.

В середине 90-х компания сменила название на Inprise и чуть не закончила свое существование. Спасли ее инструменты разработки — Delphi и позднее JBuilder. Затем Borland опять начала покупать компании — среди прочих в 2003 году так была куплена и американская компания TogetherSoft, основной центр разработки которой находился в Санкт-Петербурге. В результате этой покупки образовался российский филиал Borland.

Занимался питерский филиал вначале тем же, чем и до покупки, — продуктами линейки Together (для одновременной разработки кода и UML-диаграмм), а также интегрировал функциональность Together с продуктами Borland.

Постепенно американское руководство, довольное результатом работы питерских команд и их относительно низкой ценой, начало переводить в Питер разработку и других своих продуктов. К 2006 году практически все продукты Borland имели команды в Питере.

К сожалению, «переварить» эти покупки компания не смогла. Как и в случае с базами данных, возникла внутренняя конкуренция (Together Control Center, например, была в том числе прямым конкурентом JBuilder). С 2003 по 2006 год, пока я работал в Borland, компания пыталась наладить ситуацию, но она, к сожалению, ухудшалась. При этом высшее руководство, далекое от программирования и технологий, совершало ошибку за ошибкой, усугубляя и без того сложное положение. В компании процветала «политика», сильные программисты один за другим покидали компанию. В качестве основного средства решения проблем применялось сокращение расходов.

Borland была компанией с достаточно высокой структурой. Была вертикаль от CEO до программиста из, скажем, пяти менеджеров разного уровня, у которых было по одному подчиненному. CEO, COO, senior vice president, просто vice president, senior director, director, project manager, и уже у него три программиста.

В 2006 году Borland начала сокращаться, и американцы поступили честно — в марте они сообщили нам, что филиал будет полностью закрыт к сентябрю. У руководства филиала было время на то, чтобы подготовить для людей отходные пути.

Мы считали себя элитной компанией, подобных которой в Питере нет. Поэтому мы не стали посылать людей на интервью куда-то в компании, которых не было в городе, но попытались привезти эти новые компании к нам. Так мы привезли в Питер Google и «Яндекс».

Сначала нам удалось договориться о встрече с командой Google, которая занималась созданием новых офисов. Удалось привезти их в Питер. Они проинтервьюировали наших топ-инженеров и забрали к себе десяток самых сильных. Из них сделали Google Санкт-Петербург. Ребята и сейчас почти все там работают.

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

Передо мной лично встал выбор: Google или «Яндекс». Я выбрал последних и проработал там год-полтора. За это время мы сделали филиал, он заработал, но настала какая-то точка насыщения, после чего я решил «поиграть» в свой бизнес.

Кстати, директора филиала там до сих пор нет. В тот момент, когда филиал появился и начал работать, оказалось, что руководитель там не нужен, они и так управлялись со всем нормально.

В мире IDEй

Единственный элемент процесса, который сейчас присутствует в JetBrains, — это стандартный stand-up meeting. Команда раз в день 15–20 минут общается и обсуждает текущее положение дел в проекте. Это пришло из подхода гибкой методологии разработки (Agile). В остальном процесс поддерживается tool’ингом (программными инструментами): есть постоянные сборки в Continuous integration, есть какие-то peer review, когда люди смотрят, что они наделали.

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

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

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

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

Плюс существует такая вещь — 80/20 проект. Суть в том, что 20% рабочего времени — фактически день в неделю — сотрудник может тратить не на основной проект, а на что-то ему интересное и полезное для компании. Это может быть разработка прототипа нового продукта компании, участие в Open Source проекте или преподавание.

Работа в JetBrains практически ничем не регламентируется. Офис действует 24 часа, всю неделю, так как у нас есть люди, которым комфортно работать по ночам.

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

Очень много людей, которые начинают работать в JetBrains, приходят из вузов.Есть несколько образовательных проектов, часть из которых в JetBrains привел я, часть были изначально. Компания давно и удачно сотрудничает с кафедрой системного программирования матмеха СПбГУ. Получается, что если мы набираем 40 человек в год, то 20 из них будут из наших образовательных проектов.

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

У нас в компании очень плоская структура. Есть два уровня управления. Это руководители проектов, которые отвечают за конкретные продукты, и руководство компании — руководители отделов, CTO, COO, CEO, которые отвечают за компанию в целом.

Доступ к руководству компании у нас очень прост, и если у человека появляется какая-то идея, он может на следующее утро рассказать ее CEO на кухне компании (ну или кому-то еще из руководства). Если идея действительно стоящая, то завтра же он сможет стать проджект-менеджером этого проекта и начать работу.

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

Скажем, есть компания, где работает 50 студентов. И один из них ходит и своему непосредственному руководителю постоянно говорит: «Ой, а я так хочу быть менеджером!» Ну раз хочешь — будь. И люди начинают строить карьеру плохого менеджера, в плохой конторе, руководя плохими программистами, работающими над плохими задачами.

Менеджер тоже профессия. Она другая, хотя и требует, в общем-то, похожего (но чуть иного) набора skills. В нее лучше уходить, имея достаточный опыт работы программистом, точно осознавая, что тебе нужно.

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

Впервые опубликовано в журнале “Хакер”.