Увидеть новый и пока мало кому известный язык программирования в маленьком стартапе или пет-проекте у друзей — дело обыденное. Спросишь, зачем его взяли, скажут, что просто изучили из любопытства, понравилось и решили поэкспериментировать, потому что устали от вечных Java/.Net/JS на работе.

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

У Wrike, где около 400 разработчиков, другой подход. Они не закрыли глаза на недостатки JavaScript и даже не выбрали компромисс, вроде Flow или TypeScript — а пошли совсем радикальным путем. Переписали фронт на язык, который тогда вряд ли знала и тысяча человек, и, кажется, до сих пор абсолютно в себе уверены.
Wrike занял почетное третье место среди medium-компаний в рейтинге лучших работодателей в ИТ «Моего круга» со средней оценкой 4.82. В топ самых высоко оцениваемых качеств компании входят: социальный пакет, комфортные условия труда, отношения с коллегами, адекватная зарплата и профессиональный рост.






— Wrike основал Андрей Филев в 2007 году в Санкт-Петербурге. Потом он начал развивать бизнес в Америке, в Кремниевой долине. Тогда это была совершенно другая компания, а сейчас мы сильно выросли.

В начале у Андрея была аутсорсинговая компания. В ней начали искать софт, который позволил бы более эффективно работать — управлять временем и ресурсами. По-настоящему классного инструмента на тот момент не нашлось, и появилась идея создать свой. Тогда и родился Wrike.

Мы начинали с простых вещей, но постепенно продукт стал расти. Это было 12 лет назад, и можно сказать, что мы приняли участие в формировании рынка подобных work management-систем. Сейчас Wrike используют свыше 18 000 компаний по всему миру.

— А та аутсорсинговая компания до сих пор существует?

Да, называется Murano Software. Но она к нам не имеет отношения. Wrike — полноценная компания одного продукта, которая была экспериментом в рамках аутсорсинговой компании, но очень быстро взлетела и отделилась.

— Там до сих пор им пользуются?

Да, до сих пор.

Что такое Wrike


Wrike — это платформа для управления проектами и совместной работы в очень широком смысле: от личного to-do листа вплоть до системы, которая подходит для огромных компаний.

Внутри можно создавать проекты с множеством задач и подзадач, настраивать отчеты для сбора данных, выводить диаграммы Ганта, отслеживать задачи в календаре, редактировать их одновременно с другими участниками. Дополнения Wrike помогают управлять загруженностью команды в режиме реального времени или проводить сложные многоканальные маркетинговые кампании. Есть API для интеграции в другие инструменты. Есть расширения, например, для Adobe Creative Cloud. Оно позволяет просматривать и комментировать файлы не выходя из системы.

Wrike не стремится сделать акцент на определенной функции, индустрии или профессии. Он позиционируется, как универсальный инструмент для всего — вплоть до замены почтовой системы, мессенджера, базы знаний, баг-трекера и многого другого.

— Расфокусировка на всех и для всего не делает хуже отдельные части?

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

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

— То есть, можно взять баг-трекер быстрее, мессенджер быстрее, но это будет пять разных инструментов и синхронизироваться между ними сложно.



— Но тогда и конкурировать приходится со всеми. Atlassian с одной стороны. Slack как мессенджер — с другой.

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

— Но компаний, которые конкурировали бы с нами по всем пунктам, на самом деле, не так много.

— Atlassian разве не такой?

— Он больше заточен на ИТ-рынок. Например, для дизайнеров Jira слишком сложная.
Ее очень сложно кастомизировать. Есть даже профессия — Jira Setup Manager. Мы же стараемся делать так, чтобы ты зашел на сайт, взял бесплатный аккаунт и все — с первого дня можешь использовать без проблем.

— Но вы же говорите, что тоже тесно работаете с клиентами и тоже направляете менеджеров которые, налаживают процессы.

Да, у нас есть команда Customer Success и Deployment-менеджеров, а также целая система туров, гайдов, электронных книг и всякой документации. Есть менеджеры, которые помогут настроить Wrike уже под готовые процессы. Иногда они работают с крупными клиентами one-to-one. Иногда сразу со многими (например, записывая вебинары). Даже если человек зарегистрировал триал и не разобрался в продукте, у него будет возможность пообщаться вживую с кем-то из райкеров и понять, как что работает.

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

— Случалось, что с кем-то из больших клиентов было очень сложно?

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

В Airbnb, например, используют платформу в очень необычных кейсах. Каждая квартира и, каждый человек, который ее арендует— это отдельный проект в Wrike.

Или автомобильная компания Coil [название изменено]. У них покупатели заказывают запчасти. Давать этим людям аккаунты Wrike — так себе идея. Не будешь же каждому владельцу Coil делать свою учетную запись. Но компания очень хотела, чтобы была удобная возможность работать с клиентами.

Мы, конечно, не сказали, что прямо сейчас для них сделаем такую фичу. Но менеджеры поняли, что она улучшит продукт в целом. Так появились «внешние формы запросов», для людей, у которых нет аккаунта Wrike.

— Получилось, вы делали для Coil [название изменено], а подошло и всем остальным?

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


Внутренняя структура Wrike




Мы работаем по Scrum. Компания разделена на команды по фичам — примерно по 10 человек. Они разного состава, но в каждой есть бэкенд, фронтенд, скрам-мастер, QA, автоматизатор QA, UX-дизайнер, продакт оунер, продуктовый аналитик (аналитики иногда бывают на несколько команд). Такой состав полнофункционален и может сделать фичу от и до.

Есть внутренние команды, которые делают фреймворки, компоненты, дизайн-киты, занимаются переходом с одной версии языка программирования на другую.

Некоторые команды являются общими для всей компании. Например, это SysOps, которые занимаются серверной инфраструктурой, и DevOps — они занимаются деплоем и доставкой продукта. Релизы у нас от одного до 3 раз в сутки.

Еще частично используем уже известную всем структуру Spotify с гильдиями. Например, фронтенд, где состоят фронтендеры из всех команд. Есть фронтенд-лиды, которые занимаются менеджментом, архитектурой. И есть лиды гильдий.

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

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

— А в каком офисе что делается?

— В Питере и Воронеже инженерные r’n’d офисы. В Питере у нас 400 человек, в Воронеже — 40. Есть офисы в Сан-Хосе, Сан-Диего. В этом году откроется офис в Праге. Недавно расширили офис в Дублине. В январе этого года открылся офис в Мельбурне, в Австралии.



— В американских офисах у нас отдел продаж, маркетинг, менеджеры (CSM). В Дублине тоже CSM и продажи. Есть еще команда аналитиков. В Петербурге — самый большой и объединяющий офис. Здесь у нас менеджеры по работе с клиентами, продакт-менеджеры, аналитики, дизайнеры, разработка и бэк-офис.

— Все работают в офисах или вы открыты к удаленке?

— Удаленные скрам-команды — это очень сложно. Нам хочется, чтобы люди были рядом и контактировали между собой. В департаментах, которые могут предполагать удаленную работу (например, Customer Support), мы ребят не сильно ограничиваем.

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

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

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

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

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

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

Может, конечно, у разработчиков не true British accent и нет Оксфорда за плечами, но изъясниться и прочесть что-нибудь они обычно могут.


Почему Dart лучше JavaScript и TypeScript





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

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

Бывает, что-то падает. Иногда мы понимаем, что два года назад были глупее. Но это естественно с точки зрения инженера. А как иначе?

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

— Да, я иногда говорю, что нам надо сесть и порефакторить, а то стрельнет так, что все отстрелит. Садимся и рефакторим. Мешает архитектура — делаем архитектуру.

— Что у вас за стек?

— На бэкенде Java. База данных SQL. На фронтенде интересная штука. Когда-то давно у нас был JavaScript, но мы поняли, что он вообще не масштабируется и выбрали Dart.

— Что-что выбрали??

— Dart. Да, это нормальная реакция. Типизированный язык от Google, которому сейчас уже почти семь лет. Мы наверное самые главные евангелисты этого стека в России.

— Самые главные или единственные?

— Кстати, сейчас он активно развивается. Гугл запустил Flutter — это такой мобильный фреймворк, написанный как раз на Dart. Есть Russian Dart Community, которое мы создали и поддерживаем. Там уже около полутора тысяч человек. Конечно, по меркам JavaScript это не особо внушительно, но и немало.

В декабре прошлого года мы организовали конференцию DartUp — был огромный зал и пришло много людей. И многие реально используют Dart в продакшене. Язык постепенно развивается, и это очень круто.

— Так что мы сейчас на коне. Говорить «в мире», наверное, претенциозно, но, на самом деле, так и есть. DartUp — это самая большая конференция по Дарту в мире. Даже больше, чем у Google.

— На конференции было около трехсот человек. Хотя еще два года назад казалось, что мы одни в поле воины.



— Это все любопытно, но как работать на таком масштабном проекте, если не наймешь людей, нет ни библиотек, ни фреймворков.

— Это заблуждение. Недавно мы взяли в команду человека, для которого Dart вообще был первым языком программирования.

— В Dart все есть. Это язык из разряда C# и Java — там все что нужно, встроено. И это вообще неправда, что там все пусто и катаются перекати поле. Там встроено даже больше, чем в некоторых двадцатилетних языках. Библиотеки, инструменты, поддержка фреймворков — Angular там тоже есть.

Конечно, нет инфраструктуры, как на JS. Но проблема в том, что, когда люди пишут миллионы библиотек, получаются миллионы плохих библиотек. И, может, только сто нормальных.

А если библиотеки пишет Google, который использует Dart в AdWords и AdSense, то среднее качество гораздо выше.

Прелесть языка в том, что он простой и Си-подобный. То есть мы нанимаем разработчиков на C++, C#, Java, JavaScript — кого угодно. Мы не требуем знания Dart. Естественно, на улице не найти дарт-разработчика.

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

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

— Но люди не начинают писать как на своем старом языке? Те же JS-ники пришли с динамического языка на статический.

— Поэтому у нас процесс отбора не самый простой. Но справедливый и честный.

— Ок, почему язык хорош?

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

На Dart если что-то напишешь неправильно, сразу это поймешь. В нем более раннее обнаружение ошибок, которое позволяет даже не тестируя код понимать, работает он или нет.

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

Сейчас на свете два языка, которые позволяют писать под все платформы —под мобильные, под бэкенд, под десктоп, под веб. Это JS и Dart. У JS минусов известно сколько. А у Dart огромный плюс — типизация.

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



— Теперь не жалеете что, например, TypeScript не выбрали?

— Не теперь, а в принципе не жалеем. Я советую посмотреть доклад Виктора Логова из JetBrains на конференции HolyJS [Вероятно, спикер перепутал имя, и речь шла о докладе Антона Лобова].

Они делают поддержку TypeScript в своих продуктах, и он там просто разносит TS по полочкам, аргументированно. И после этого вообще нет желания его брать. Складывается ощущение, что фичи в нем появляются по принципу «Давайте вот это добавим? А давайте».

— Чтобы я поверил, расскажите что плохо в Дарте? Не может быть, что все идеально.

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

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

— После опыта с Dart вы не захотели Java заменить на Go?

— Зачем? Dart мы выбрали по определённым параметрам. Это было взвешенное решение.

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

— Мы экспериментируем с разными технологиями. Если в какой то момент поймём, что Go работает лучше, то попробуем.

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

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


Найм инженеров, а не знатоков языка




— Кем надо быть, чтобы к вам попасть?

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

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

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

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

— Мы ищем людей, которым не все равно, которые заинтересованы двигаться вперед.



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

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

— На собеседовании разработчик будет писать код?

— Да, я знаю, это сейчас очень обсуждаемо.

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

Если человек говорит: «Я React-программист», — это уже звучит странно. То есть если не React, ты не разберешься?

Мы стараемся давать задачи, которые сами делаем каждый день. Они не требуют суперзнаний о предметной области. Мы не спрашиваем, что такое замыкание в JS. Можем спросить: «Вот у тебя есть Jira и Wrike. Как ты синхронизируешь данные между ними?»

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

— Если пришел человек с гениальным инженерным мышлением и решил задачу так, что вам очень нравится, но у него нет «горящих глаз и вот этого всего», он попадет в компанию?

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

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



— В банках скучно. А у вас весело?

— Пока даже чересчур.

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

— Задачи между командами сильно отличаются?

— Специфика бывает совсем разная. Одна команда делает Gantt-чарт. У них там Canvas, своя логика. Команда, которая делает одновременное редактирование задач, как в Google Документах — там и математика, и Dart на бэкенде. От команды к команде стек один, но применение совершенно разное.

— Если человек говорит, что устал в своей команде и хочет что-то другое, получит ли он это от простого перехода?

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

— Как так получилось? Большая компания, 400 человек в офисе. Как они сдружились?

— Это вопрос подбора и культуры. Про культуру тяжело говорить — это эфемерные вещи. Ты их чувствуешь, но описать словами не можешь. Во время подбора есть этап Cultural fit, когда мы смотрим, насколько человек подходит команде.

— Что там за критерий. Как вы определяете, подходит или нет?

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

— Если человек сказал, но вам не понравилось, чего он хочет?

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

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

— То есть плохо, если человек ничего не ответит?

— Нет. Мы не поставим на нем крест. Все люди чего-то хотят.



— Я просто пытаюсь понять, можно ли не пройти этот этап собеседования?

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

— Вот еще почему можно не пройти. Wrike — это safe place. Тот же Google говорил, что один и самых ключевых критериев успешной команды — это психологическая безопасность. Я могу брать на себя ответственность только если знаю, что я в безопасности.

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

— Людей надо критиковать, чтобы они учились?

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

Комментарии (75)


  1. fedorez
    07.03.2019 16:19

    Компания описана симпатично, но… С точки зрения разработчика. Вот сидишь ты несколько лет на непопулярном стеке… А случись что — куда бежать и кому ты с этими знаниями нужен? Переезд к ближайшей вакансии в соседнюю область/столицу? Обратно в джуны? Или петпроекты на чём-то популярном на всякий случай качать?
    Небезопасно как-то.


    1. Zibx
      07.03.2019 16:29

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


      1. M_AJ
        07.03.2019 17:06

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


        1. bunopus
          07.03.2019 17:07

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


          1. M_AJ
            07.03.2019 17:55

            Честно, сначала я подумал, что мне показалось, перепроверил ещё раз, и правда 1С. Я конечно понимаю, что компания это большая, и 28 лет по меркам IT это почти вечность, но откуда все-таки такая уверенность в ней? Не в С, Java, или даже SAP, а именно в 1С.


            1. bunopus
              07.03.2019 18:13

              Если говорить о России — почти весь средний и даже большой бизнес сидит на 1С в каком-то виде. И там всегда нужны руки


        1. Zibx
          07.03.2019 17:51

          Никто не заставляет идти на галеры. Там где нужны структуры и вот это всё — тоже дефицит кадров и задачи сами себя не закроют.


          1. M_AJ
            07.03.2019 18:40

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


          1. Evgenym
            07.03.2019 18:40

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


            1. fedorez
              07.03.2019 19:43

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

              А вообще в it и офисах пошло от мемасиков из классических картин с соответствующими надписями — сюжет обычно включал измученных гребцов и надсмотрщика с кнутом.


            1. Zibx
              07.03.2019 20:27

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


            1. nikbond
              07.03.2019 21:25

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



        1. abmanimenja
          09.03.2019 02:15

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


          Компании бывают разные (пример — как раз в статье).
          А раз так, то подумайте — зачем вам «большинство компаний»? Лично вам же достаточно ровно одной?

          По вашей логике выходит, что всем до единого программистам изучать нужно только JS+PHP+Java так как это самые популярные стеки?

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

          Сколько помогал набирать персонал (технические собеседования) — почти всегда брали сотрудника всего лишь за знание «более-менее смежного стека» или «более-менее смежного направления разработки». Ибо почти не бывает 100% совпадений на практике.


      1. JustDont
        07.03.2019 19:48

        Базовый скилл качают все. Сидит Вася со своим офигенным (нет) Дартом, и сидит Петя со своим ужасным-отстойным JS или там TS. И через пару лет у них обоих прирос базовый скилл, но вот у Пети еще и опыт в популярном стеке, а у Васи нифига.


        1. Arbane
          08.03.2019 22:56

          Это как изучать как чиеить Мерседесы и Лады; с Мерседесом вы найдете работу везде. Но всегда популярным может стать Фольксваген… Я к чему: возмет котлин или нью скрипт и взорвет фронтэнд, а вы ничего не можете… Есть всегда спрос и на тех кто Реакт-программист или Ангуляр-программист; и на тех кто Программист. Разницы в деньгах незамечено.


          1. JustDont
            08.03.2019 23:02

            Конечно, всё так.

            Но пока никакой новый инструмент Х фронтэнд не взорвал — у «просто программиста» будет несколько меньше путей, чем у «реакт-программиста» (при равном общем скилле). Разница в деньгах скорее всего особой роли играть не будет, а вот разница в объеме хороших вакансий, где тебя вот прям ждут — да.


        1. abmanimenja
          09.03.2019 02:22

          И через пару лет у них обоих прирос базовый скилл, но вот у Пети еще и опыт в популярном стеке, а у Васи нифига.

          А Вася, если не бил баклуши — пойдет в тимлиды и будет уже сам выбирать технологии, а не подстраиваться под готовые.

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


          1. JustDont
            09.03.2019 02:55

            А Вася, если не бил баклуши — пойдет в тимлиды и будет уже сам выбирать технологии, а не подстраиваться под готовые.

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

            То, что вы возводите в абсолют

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


            1. abmanimenja
              09.03.2019 04:24

              Я писал о том, что при прочих равных у человека с опытом в распространенном тех стеке — больше возможностей (в основном к трудоустройству).


              Вот это и есть «возводить в абсолют».
              По вашей логике — учить следует только PHP+JS (возможно, Java) — это ж «больше возможностей по трудоустройству».

              Нет никаких «прочих равных» в реальности.

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

              С точки зрения статистики — у вас всё верно написано.
              С точки зрения конкретного человека — ему не нужны все эти 100 500 фирм, где можно писать на JS. Он же не сможет работать во всех сразу.


    1. bunopus
      07.03.2019 17:06
      +1

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


      1. vanyas
        07.03.2019 18:41
        +2

        Тут надо уточнить, что работа всегда будет в России, а соберись ты за границу, кому ты нужен с 1С?


        1. limita
          08.03.2019 14:54

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


        1. abmanimenja
          08.03.2019 15:00

          Тут надо уточнить, что работа всегда будет в России, а соберись ты за границу, кому ты нужен с 1С?


          Если ты собираешься за границу, то готовишься к этому.

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

          Куда важнее не конкретный язык, а алгоритмы/парадигмы/паттерны.

          Автор этих строк:
          15 лет с 1С.
          На Go начал программировать через 40 минут после ознакомления с синтаксисом.
          На Dart — через пару дней после ознакомления с синтаксисом.
          Через пару месяцев был готов веб-сайт интернет-магазина (коммерческая разработка за вполне «взрослую» денежку) — да, я знаю про готовые решения, первая версия была построена на базе CMS, вторая — уже самостоятельно «запрограммирована».
          Затем пошло-полетело.

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

          P.S.:
          Речь, разумеется, не о джуне.


    1. a-tk
      07.03.2019 17:29

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


      1. staticlab
        07.03.2019 17:42

        А в нюансах работы JS/TS быстро получится разобраться?


        1. a-tk
          07.03.2019 18:41
          +1

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


          1. staticlab
            08.03.2019 11:53

            Да собственно там из важных особенностей только прототипы и this, но после ООП-шного Дарта со строгой типизацией, мне кажется, может быть психологически больно переходить на функционально-мультипарадигменный TS или тем более JS.


            1. JustDont
              08.03.2019 12:35
              +1

              Да нет, перейти несложно, но любителя ООП можно угадать по его коду на JS/TS, как говорится, «с трех нот». Я, собственно, как бывший явист, сам до сих пор так пишу — классовым и немного квадратно-гнездовым способом. Хотя и знаю, что можно по-другому, и как именно. Но — как говорится, один раз ООП, и дальше уже всё ООП.


              1. staticlab
                08.03.2019 18:46

                Заметны отличия даже у ангулярщика, пишущего на реакте.


                1. a-tk
                  08.03.2019 18:53

                  Программист на *** на любом языке пишет на ***.
                  Я впервые услышал эту фразу применительно к Lisp-у, но жизнь показывает, что сюда можно подставить абсолютно любой язык.


                  1. M_AJ
                    09.03.2019 10:01

                    Я думал это из мини-анекдота:
                    "Могу программировать на Fortran на любом языке программирования".


      1. M_AJ
        07.03.2019 18:02

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


        1. a-tk
          07.03.2019 18:40

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


        1. abmanimenja
          09.03.2019 13:47

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

          Мало ли о чем они мечтают.
          Они еще и ищут, чтобы за копейки при этом.

          Но это невозможно.
          Так же как и трудно найти специалиста 100% подходящего под стек.

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


      1. yudinetz
        08.03.2019 10:44

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


  1. VIkrom
    07.03.2019 17:49

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

    Почему не подойдет? Профессионал заинтересован в том что делает с десяти до шести.


    1. a-tk
      07.03.2019 18:43
      +2

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


    1. yudinetz
      08.03.2019 10:45

      Читайте между строк — ищут гребцов к себе на галеру, чтобы работали больше, а платить им меньше


    1. abmanimenja
      09.03.2019 13:48

      Почему не подойдет? Профессионал заинтересован в том что делает с десяти до шести.


      Вы акцент не там увидели.

      Ключевой момент тут:
      но тебе все равно, что пилить, лишь бы работать с десяти до шести и получать деньги


      1. VIkrom
        09.03.2019 17:19

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


        1. abmanimenja
          09.03.2019 20:10

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

          Где вы видели таких идеальных людей-профессионалов? В кино?
          При прочих равных — если человеку интересно — он работает лучше.


          1. VIkrom
            10.03.2019 09:08

            Человек уже пришел к вам на проект, значит ему в какой-то степени интересно. В ИТ у работника сейчас есть выбор, чтобы не занимать тем, к чему душа вообще не лежит.


            1. abmanimenja
              10.03.2019 12:01

              в какой-то степени интересно

              В какой?
              В ИТ у работника сейчас есть выбор, чтобы не занимать тем, к чему душа вообще не лежит.

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


        1. abmanimenja
          10.03.2019 09:04

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

          Отнюдь.

          Зачастую нужны просто рабочие лошадки без выкрутасов. Это просто другая фирма, другая организация труда.

          В частности, я как работодатель предпочитаю нанимать «без горящих глаз».

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


          1. VIkrom
            10.03.2019 09:17

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


            1. abmanimenja
              10.03.2019 12:03

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

              Гы. С сеньорами таких проблем как раз нет.
              Но 100% сеньоров не наймешь.


  1. a-tk
    07.03.2019 18:44
    +1

    Хотелось бы спросить, какое отношение в обозначенной организации к овертаймам.


    1. Wriketeam
      07.03.2019 19:15

      Овертаймы бывают разного рода. Если команда не вписывается в спринт и кто-то начинает овертаймить, то отношение – как к ошибке в оценке или как с сбою в процессах, такие вещи не поощряются внутри команды, но иногда происходят. Есть личные инициативы людей – сделать что-то за пределами скоупа, или, скажем, написать статью на хабр или поработать над интерактивом для конференции, где компания участвует со стендом, то такие вещи мы приветствуем. В целом, все согласованные заранее овертаймы в компании компенсируются. Но вообще мы за work-life balance.


      1. a-tk
        08.03.2019 23:06

        А практикуете ли вы время на поиски новых путей, прототипирование идей, экспериментирование в рабочее время по предварительному согласованию по длительности кванта и примерному направлению?


        1. bunopus
          08.03.2019 23:41

          Конечно


  1. Shoom3301
    07.03.2019 19:40

    Интересно, почему google разрабатывает тот же Angular на typescript, а не на Dart?


    1. JustDont
      07.03.2019 19:52

      <sarcasm>
      Наверное они просто тот самый доклад Виктора Логова из JetBrains не слышали.
      </sarcasm>

      А если серьезно, вся часть про «почему Dart?» просто звучит как «ну вот просто в свое время взяли Dart, но не скажешь же так на интервью». И понятно, почему теперь с него не слезть — но опять же не скажешь же на интервью, что «ну не будем же мы продукт переписывать, даже если нам не всё нравится». Несолидно. Остаётся улыбаться и махать.


      1. Wriketeam
        07.03.2019 20:00

        Очень много наших подробных статей habr.com/ru/company/wrike
        докладов www.youtube.com/channel/UCu-RrZ8JmADlGZGO8d3OW5w/videos
        и прочих материалов (https://github.com/rudart/community/blob/master/ru_resources.md), почему Wrike использует Dart.

        Это если по существу и без сарказма отвечать.


        1. JustDont
          07.03.2019 20:14

          Если по существу и без сарказма, то я могу набрать в гугле «язык для Y», ткнуть в первую попавшуюся ссылку, а потом практически бесконечно фонтанировать докладами о том, как выбранный мной язык офигенен и хорош. Доклады — это красочное переливание воды. Если же без воды — это должен быть очень сухой и короткий сравнительный анализ сильных и слабых сторон множества инструментов в контексте «нам нужно сделать штуку Х с обязательными фичами A, B, C, и учесть прогнозируемые нами риски K, L, и M».

          Если вы ничего не сравниваете, а рассказываете про то, какой крутой инструмент Х — это вода. Если вы сравниваете, но по сферическим в вакууме показателям, которые сами же недавно и придумали (и ранжировку по ним тоже придумали) — это вода.

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


          1. Wriketeam
            07.03.2019 20:22

            Есть задача, есть инструмент. Инструмент хорошо подходит для решения задач, остальное лирика. На данный момент дарт нас устраивает. Сравнивать языки и фреймворки в вакууме лично я не вижу смысла. Вот, например, статья на эту тему от нашего коллеги habr.com/ru/company/wrike/blog/433060


            1. JustDont
              07.03.2019 20:24

              Инструмент хорошо подходит для решения задач, остальное лирика.

              Так вот именно. О чем я и говорю.

              Не «смотрите, какой TS отстой, там доклад был», а «нас пока и с дартом всё устраивает». Второе — банальная реальность. Первое — «улыбаемся и машем».


    1. bunopus
      08.03.2019 23:47

      Ну почему же, есть https://webdev.dartlang.org/angular, он разрабатывается на Dart


  1. maxzh83
    07.03.2019 21:30
    +2

    Как нанимать людей в огромную компанию с непопулярным стеком.

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


  1. morsic
    07.03.2019 22:26

    >доклад Виктора Логова из JetBrains на конференции HolyJS
    А есть ссылка? А то сегодня меня прокляли боги гугла, не могу найти :(


    1. justboris
      08.03.2019 14:50

      Я думаю, имелся в виду вот этот доклад: www.youtube.com/watch?v=srqqwuqzYMM

      Каким образом Андрей Старовойт превратился в Виктора Логова – загадка.


      1. princed
        08.03.2019 17:51

        Скорее всего, это был Антон Лобов: 2017.holyjs-moscow.ru/talks/6jek48yvww8emsqamakmia (запись доклада, похоже, отсутствует).


        1. justboris
          08.03.2019 19:04

          Доклад можно посмотреть в архиве трансляции. Ссылка с таймкодом: https://youtu.be/spIfirNCeVs?t=6556


          Доклад в основном о боли разработчика IDE и поддержки автоматических рефакторингов. Тема неудобства для разработчика там не раскрыта вообще.


          Складывается ощущение, что фичи в нем появляются по принципу «Давайте вот это добавим? А давайте».

          Вот этот вывод в статье из доклада вообще никак не следует. Это личная фантазия автора.


        1. morsic
          08.03.2019 19:12

          Спасибо!


    1. bunopus
      08.03.2019 23:48

      Это действительно Антон Лобов. Как он превратился в Виктора Логова — вопрос редактуры :-|


  1. sved
    08.03.2019 12:35
    +1

    Имхо, это глубоко ошибочное мнение считать, что если google создал библиотеку, то её качество выше. Из моего опыта в Java мире самые лучшие фреймворки и библиотеки приходят из open-source community, а вовсе не из недр каких либо компаний (не важно гугл или нет).

    Более того, решения от гугла часто оказываются менее эффективными, ибо многие «архитекторы» с маленьким разработческим опытом выбирают по принципу «раз гугл, значит круто». Взять, к примеру, откровенно провальные protobuf и GWT.

    Ну по-поводу «профи на любом языке напишет»: это просто смешно. Знание языка — это от силы 1% скилов. Остальное это знание библиотек, инструментов, навыки работы с IDE, знания специфических паттернов и прочее, прочее, прочее.
    Более того: и язык за полгода не освоить. Спецификация даже простой джавы это несколько сотен страниц. Все базовые классы JDK я и за 15 лет ещё не все узнал. Бывает, что занимаюсь велосипедами, когда уже есть готовое решение в JDK. Что уж говорит про новичков — тут и гугление не поможет.


    1. abmanimenja
      09.03.2019 00:51
      +2

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

      Исходный посыл был другой. Вы искажаете смысл.

      Говорилось о том, что среднее качество кода выше у Google. Что логично, так как они могут себе позволить и нанимают в среднем более квалифицированных.

      Вы же говорите о лучших представителях библиотек/фрейморков.
      Среднее в Google < Наилучшее в мире.

      В статье-то сказано о:
      Среднее в Google > Среднего в мире.

      Из моего опыта в Java мире самые лучшие фреймворки и библиотеки приходят из open-source community, а вовсе не из недр каких либо компаний (не важно гугл или нет).


      Google разве не публикует свое в open-source и не пользуется силами сообщества?
      Скажем, Go активно пилится с участием «общественных» commit-ов.

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

      Сделать что-либо путное серьезное чисто как хобби? Вы серьезно? Как исключение это возможно, но типично как раз иное — за зарплату.

      То, что код публикуется и принимаются изменения от всех желающих не делает библиотеку/фреймворк созданной исключительно силой сообщество. В сообществе — большинство (подавляющее) — потребители.

      Эти вещи пришли из реального мира и разработаны за зарплату.

      Да хоть тот же Linux возьмите — львиная доля доработок на сегодня делается сотрудниками корпораций в рабочее время.


      1. sved
        09.03.2019 04:35
        -2

        Среднее в Google > Среднего в мире.

        Не совсем, так точнее: Open Source >> среднее в Google > среднее в средней компании

        Google разве не публикует свое в open-source и не пользуется силами сообщества


        Желательно чтобы проект изначально создавался силами Open Source. Например webkit изначально создавался энтузиастами, а затем дорабатывался организациями, не наоборот.

        Использует сообщество для поиска и исправления багов. Взаимовыгодное дело.


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

        Сделать что-либо путное серьезное чисто как хобби? Вы серьезно? Как исключение это возможно, но типично как раз иное — за зарплату.

        Мммм… я даже не знаю что ответить. Вы точно разрабатывали что-то? Вы пользовались линуксом, VLC, apache, Libre Office, 7-zip, ffmpeg? Предполагаю что это некий троллинг.

        Да хоть тот же Linux возьмите — львиная доля доработок на сегодня делается сотрудниками корпораций в рабочее время.


        Ядро линукса наполовину состоит из драйверов. Неудивительно, что разработчики оборудования активно контрибутят.


        1. abmanimenja
          09.03.2019 12:02
          +2

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

          Apple же?
          And then, on June 7, 2005, Bertrand Serlet stepped onto the stage at WWDC and announced something no one really saw coming — the soul of Apple’s little upstart browser, Safari, was being open sourced. And it was called WebKit.


          1. sved
            09.03.2019 12:26

            Webkit основан на KHTML который был в Konqueror-е


            1. abmanimenja
              09.03.2019 12:58
              +1

              И? С чего вы решили, что KHTML разрабатывался бесплатно?

              Ну а кем работали авторы изначального KHTML вы знаете? Я-то вот знаю где Torben Weis получал финансовую поддержку, когда работал над этим проектом (даю подсказку — университет).
              Знаю и кто платил Lars'у Knoll'у, когда тот перерабатывал проект (даю подсказку — знаете как финансируется Qt? )


        1. abmanimenja
          09.03.2019 12:14

          Ядро линукса наполовину состоит из драйверов. Неудивительно, что разработчики оборудования активно контрибутят.

          www.itweek.ru/foss/article/detail.php?ID=109200
          70--95% программистов трудились над Linux в корпорациях и получали за это зарплату. “Более 70% вклада в развитие ядра внесли программисты, работающие в таких компаниях, как IBM, Intel, The Linux Foundation, MIPS Technology, MontaVista, Movial, NetApp, Novell и Red Hat”.

          Какое железо делает Novell или Red Hat?
          А как много ли драйверов под свое железо добавляет в Linux фирма IBM?
          А что именно сделали в Linux ребята из NetApp? Какие драйвера? Код же открыт.
          Ну а Intel? Да, они делают и драйвера, но далеко не только драйвера.
          Просто прочитайте исходники (коммиты) и перестаньте вводить людей в заблуждение.


        1. abmanimenja
          09.03.2019 12:49

          VLC, apache, Libre Office, 7-zip, ffmpeg? Предполагаю что это некий троллинг.

          В смысле, с вашей стороны троллинг?
          LibreOffice происходит от OpenOffice, а тот от StarOffice. Который вполне себе фирмой создавался. Ну а сейчас:
          Разрабатывается сообществом из более чем 480 программистов под эгидой некоммерческого фонда The Document Foundation за счёт пожертвований отдельных лиц и организаций.

          Мне выделить насчет пожертвований bold'ом или так понятно?

          7-zip — алгоритм придумать это было сложно, согласен. Но как программа — он прост и вполне в одиночку потянуть.

          Apache? Изначально создан в «Национальном центре суперкомпьютерных приложений» в США. Да, за зарплату. Сейчас финансируется Apache Foundation.

          В ffmpeg — очень много кода университетских сотрудников. Это же не секрет. Просто поглядите на исходники. Это часть их исследований по алгоритмам сжатия. Но университет им тоже платит (гранты, зарплаты)

          VLC, да действительно — что ж, исключения бывают.

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


  1. andrsam
    08.03.2019 16:03

    Применяется ли у вас тщательный контроль производительности каждого сотрудника через сопоставление тимлидом желаемого и фактического времени выполнения задачи(претензии вида «я это сделаю за час… ты это делаешь за два часа»)?


    1. bunopus
      08.03.2019 23:44

      Нет, а зачем?