Пять Пугающих Тенденций Современного Развития

Привычка – страшная сила.

Это заставляет сопротивляться переменам и мешает развитию.

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

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

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

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

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

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

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

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

Егор Бугаенко — основатель Zerocracy, разработчик Cactoos, Takes Framework, JCabi и других проектов с открытым исходным кодом.

Написал серию книг «Элегантные предметы» и провел провокационную программу.

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

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

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

То есть сделать приложение, которое будет доступно в Apple Store. Мне было интересно, как собрать приложение в один пакет, то есть не просто рисовать какие-то кнопки на экране, а делать ровно бесшовное приложение .

Очевидно, что код, например, на Swift и продукт в мобильном телефоне — это две совершенно разные вещи: первая очень маленькая, а вторая очень большая и включает в себя такие вопросы:

• Юнит-тесты;
• статический анализ;
• Непрерывная интеграция;
• управление зависимостями;
• Непрерывная доставка;
• Промежуточная среда;
• процесс одобрения приложений в Apple Store;
• процесс сборки брака с производства и т.д.

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

Я нашла такого специалиста, но он мне сказал: «Почему ты об этом думаешь? Сначала нарисуйте приложение.

Что такое непрерывная интеграция? Подождите пока с Unit-тестами — сделайте так, чтобы всё работало.

Какой конвейер доставки? Почему TestFlight — используйте симулятор».

Наверняка он хороший программист, но в голове у него, по-моему, все перевернуто с ног на голову .

Он считает, что код важен, а вся остальная упаковка второстепенна.

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

Почему-то многие разработчики считают, что сам код важен, а сборка - это то, что делает DevOps -инженер или кто-нибудь еще.

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

В конечном итоге вы попадаете в проект, где пишете код, не зная, как все заканчивается в производстве.

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

Сначала развертывание, потом код

.

То есть я проектирую книгу, прежде чем писать.

Сначала я делаю make-файл, который собирает всю книгу из LaTeX-файлов прямо из командной строки, готовя тексты, картинки и обложку.

Я трачу много времени и пытаюсь скомпилировать всю книгу в PDF-файл одной командой.

Я уделяю много внимания тому, как это будет выглядеть, где расположены отступы, какие текстовые блоки и расстояние между ними, как будут нумероваться страницы.

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

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

Я думаю, что это правильнее сначала развернуть, потом код .

Позвольте мне привести вам еще один пример.

Один начинающий разработчик вызвался сделать вместе с нами проект с открытым исходным кодом.

Он выбрал Flutter, сделал первую итерацию, запустил, сказал, что все отлично и отлично работает, и предложил посмотреть.

Мы спрашиваем: «Как что-то попробовать? Вот iPhone — куда мне нажатьЭ» На что он начал объяснять куда идти, что загрузка - процесс долгий.

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

Я не работал с Flutter и не очень хотел, но хотелось побыстрее исправить кое-что, что заметил.

Я спросил, как я могу это сделать, куда и как отправить пул-реквест. Открываю репозиторий, файл readme: «Это классное приложение… нажимаем скачать…».

Инструкция была сложная и непонятная, я снова спросил, как все это развернуть на своем компьютере.

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

Этот парень ушел, чтобы все это описать, и так и не вернулся.

Эта ситуация показывает, что у него хорошие качества как программиста – он смог запустить приложение.

Но его качества как человека, видящего проект в целом, оставляют желать лучшего.

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

Этот программист не получил никакой обратной связи от окружающих; он работал одиночкой.

По моему мнению сейчас быть одному неправильно .

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

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

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

Должна быть возможность написать make/build/etc в командной строке.

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

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

Только 20-30% программистов имеют собственное опубликованное приложение, но оно должно быть у каждого.

Если вы считаете себя востребованным программистом и хотите быть востребованным программистом, я бы рекомендовал сделать собственное мобильное приложение и пройти весь цикл его вывода на рынок: тестирование в Apple Store, CI, упаковка и все остальное.

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

Посмотрите, как вы работаете с маркетом, попробуйте и поймете, какие вы программисты.

Я считаю, что плохой программист — это тот, у кого нет любимых проектов.

Это страх увидеть весь цикл.

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

Сколько кода вы можете написать за 100 долларов?

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

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

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

Время штатных разработчиков с фиксированной оплатой заканчивается.

Я знаю примеры таких проектов, которые сначала много лет писали на C++, а потом поняли, что нужно писать на Java. И те же люди, в том же офисе, за те же деньги инвестора переключаются, переучиваются полгода и шатко начинают писать на Java. Это подход из прошлого.

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

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

Компании, расположенной в Москве, будет неинтересно и невыгодно переобучать людей, например, с iOS на Android или с C++ на Java. Проще нанять новых специалистов, которые придут как фрилансеры, выполнят задачу и уйдут. Думаю, будет популярен такой формат проектов: временные проекты, где фрилансеры собираются вместе, отрабатывают свои задачи — один специалист в этом, другой в том — и уходят. Эта новая эра ожидает от программистов:

• Возможность понять, чего ты стоишь.

  То есть дайте оценку, сколько стоит ваш рабочий час, какую ценность вы за него создадите.

• Возможность работать во временных условиях.

• Умение продавать себя, правильно себя презентовать.

  Разработчик-фрилансер на мировом рынке должен иметь «торговое преимущество» и цену.

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

Собственные проекты станут основным индикатором стоимости на рынке , а не там, где вы 5 лет подряд улучшали программное обеспечение, доставшееся вам в наследство.

Вы создаете проект Pet с нуля, и не имеет значения, о чем он, насколько он сложен и сколько его загрузок в Apple Store. Может быть 0 лайков и 2 скачивания, но это добротный проект, созданный вами самими.

Для меня как работодателя такие люди более ценны, чем те, кто много лет работает в офисе и имеет резюме у одного-двух работодателей.

Мне сложно понять, что делать с этим человеком, как его оценивать.

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

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

Поэтому рекомендация посчитайте свои деньги, попробуйте работать по договорам .

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

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

Ищите альтернативы, смотрите, пробуйте, продавайте .

Сначала тебя не купят, будут проблемы - много проблем! Но решив эти проблемы, вы станете более востребованным программистом более высокого уровня.

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

Иногда меня просят выполнить определенные задачи в качестве эксперта.

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

Чаще всего люди просто хотят дешевле, например 50, а не 100 долларов в час.

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

Тогда я соглашаюсь и просто умножаю количество часов на 2. В результате получаю столько, сколько хотелось изначально.

Я знаю свою реальную стоимость и скорость работы.

Клиенты не готовы к суммам $100–500 в час; для них 20 – это уже слишком много, так как они привыкли к формату полной занятости.

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

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

И они платят за эти 8 часов, а заказчик думает, что это 8 часов работы.

Это система двойного обмана: они рады быть обманутыми, а мы их обманываем.

Вот почему я использую коэффициент умножения.

Даже если я буду работать за 20, то я сделаю за 3 недели то, что реально могу сделать за 2 часа.

Обучайте своих клиентов и учитесь считать деньги сами.

Хорошие программисты пишут код, лучшие пишут билеты

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

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

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

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

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

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

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

а потом идем и делаем.

Потом проходит 2-3 недели, и мы уже не помним, о чем договаривались.

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

Я думаю, причина в страхе перед билетными системами.

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

Людям проще сказать: «Давайте поговорим! Мы соберёмся, сядем вместе и всё решим.

Мы поймём друг друга через 3 часа, а потом я пойду кодить.

Я запомню, о чем мы договорились, и все запрограммирую».

Давай забудем – ничего страшного, мы еще встретимся.

И так мы как-нибудь переживем от митинга до митинга.

Это не правильно.

Мы, как программисты, должны конвертировать любое неформальное общение в билеты.

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

Неумение программиста структурировать работу в тикеты может говорить о его низкой квалификации.

Я считаю, что есть два типа развития:

• Постоянное развитие - программирование с 9 утра до 17 вечера: пришел, включил компьютер, сделал что-то тут, там, обед, еще кодирование, конец дня - да ладно, продолжу завтра.

  То есть программируем, пока есть силы, время и силы.

• Постепенное развитие другой: есть задание № 13, я его выполню, а потом посмотрю, какое задание будет следующим.

  В таком виде задание (тикет) всегда будет выполнено.

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

Я люблю программировать, утром включаю компьютер и иду.

Потом замедляюсь - остановимся, давайте разобьем на задачи, решим, от какой задачи к какой перейдем.

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

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

Обычно люди работают в обе стороны.

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

Некоторые ошибочно полагают, что инкрементная разработка обязательно означает задачу длительностью 2 недели, и что тикет должен заканчиваться пул-реквестом на 5 тысяч измененных строк.

Это не постепенное развитие.

Инкрементная — задача на 0,5-2 часа, а в конце пул-реквест на 50-100 строк кода.

Непрерывное же наоборот — вы работаете долго-долго (днями, неделями) и мало производите.

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

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

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

Приведу пример из жизни.

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

Он несколько раз разговаривал по телефону с одним из наших архитекторов.

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

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

Мы не будем поднимать логи телефонных разговоров.

Это всего лишь ошибка архитектора.

Клиенту это знать не обязательно.

Клиент — хаотичное, недисциплинированное существо, плохо понимающее процесс разработки.

Вот каким он должен быть.

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

Какой язык программирования следует выучить в первую очередь? Английский!

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

В ИТ-сфере есть русскоязычное сообщество, с которым, мне кажется, нужно бороться всеми силами.

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

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

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

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

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

Так или иначе, этот рынок придет, пусть даже через 5-10-15 лет, и вы просто можете оказаться позади.

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

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

Людям это нравится – им это нравится, потому что язык понятен.

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

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

Для улучшения вашего уровня английского я могу порекомендовать следующее.

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

.

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

Это помогает выучить настоящий английский.

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

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

Посмотрите фильм – это настоящий английский.

Включаем субтитры и смотрим только интересные фильмы.

Не смотрите фильмы в учебных целях, выбирайте те, которые вам нравятся, и учитесь на них.

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

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

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

Последнее и самое главное - Напишите на английском .

Ведите Twitter, блог, Telegram-канал на английском языке.

Сначала вас никто не будет читать, потому что ваш английский будет сломан.

Но в конечном итоге вы серьезно поднимете свой профессиональный уровень.

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

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

Через 5-10 лет английский станет доминирующим языком на рынке.

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

Поэтому читайте, смотрите и пишите на английском языке.

Пусть сломается – это не так страшно.

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

Нет подписчиков на GitHub — вы не настоящий программист

Весь остальной код будет в открытом формате, это неизбежно.

Написание кода, упаковка и публикация — это только полдела.

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

Стать разработчиком с открытым исходным кодом сложно.

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

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

Даже сейчас посмотрите на свое приложение — какая часть кода взята из открытого исходного кода, а сколько вы написали сами? Фреймворки, библиотеки, пакеты, образы — всё это собрано из различных открытых источников.

Я думаю, мы станем ассемблерами — ассемблерами, а не программистами.

Кодирование как таковое займет меньше времени и будет менее необходимым.

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

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

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

Сейчас у меня 2300 подписчиков на GitHub — это довольно много, но это результат 6 лет работы.

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

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

В этом сообществе никто никого не уважает только из-за его полномочий.

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

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

Мы начинали новый проект, и нам нужно было найти несколько экспертов в конкретной сфере.

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

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

Однако архитектор развел руками – он не знал, как это сделать.

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

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

Достаточно будет использовать силу вашего сообщества.

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

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

У Егора Бугаенко широкий кругозор, он может мотивировать развиваться в разных направлениях.

Егор уже выступал на DevOpsConf Russia о качестве , что, мол, не главное, на Конференция качества о качественной разработке в распределенных командах.

В сентябре на Saint TeamLead Conf вместе с Егором Давайте обсудим все более популярная тема микроменеджмента.

Хотите быть в курсе наших грандиозных планов и новых публикаций - выберите список и подпишитесь.

Пишем только по делу.

Войти , Пожалуйста.

Сначала развертывание, потом код — вы согласны? 45,1% Да.

465 54,9% № 566 Проголосовал 1031 пользователь.

199 пользователей воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Код или билеты? 12,1% Хороший код расскажет вам все без каких-либо билетов.

133 19,84% Код без билетов и документации бесполезен.

218 68,06% Нужны меры, во всем могут быть исключения.

748 Проголосовали 1099 пользователей.

137 пользователей воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

У вас есть любимый проект? 30,65% Да, и более одного.

305 14,57% Один раз делал, но не выстрелило, поэтому забросил.

145 38,79% Идей много, но ни одной промышленной реализации.

386 15,98% Теперь серьезно задумаюсь над тем, чтобы начать.

Проголосовали 159 995 пользователей.

235 пользователей воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Вносите вклад в открытый исходный код? 3,31% Да, я соавтор популярного продукта.

36 1,84% Да, я регулярно участвую в нескольких проектах.

20 30,24% Иногда я отправляю запросы на включение проектов, которыми пользуюсь сам.

Теги: #Карьера в ИТ-индустрии #Управление проектами #teamleadconf #appsconf #Openshift

• Фонд H&M Выделил 1 Миллион Евро На Привлечение Инновационных Проектов В Индустрию Моды

  19 Oct, 24

• Интересные Документы О Монополии Microsoft

  19 Oct, 24

• Планета Wordpress – Теперь На Русском Языке.

  19 Oct, 24

• 3 Причины, Почему Неудача — Ключ К Успеху

  19 Oct, 24

• Htc Hero В России: Продажи Снова Отложены

  19 Oct, 24

• Гений 19 Века И Его Невероятное Творение

  19 Oct, 24

• 10 Онлайн-Мероприятий, На Которые Можно Пойти Второго Мая

  19 Oct, 24

• Поезд «Сапсан» Прибыл В Санкт-Петербург По Расписанию

  19 Oct, 24

• Используете Ли Вы Аутентификацию Openid На Своем Сайте?

  19 Oct, 24

• Menuetos: Ос На Дискете

  19 Oct, 24