Connect with us

Программирование

Я идиот: стратегия успешного идиотизма в разработке

Разработчик Ричард Тертон выступил на конференции RWDevCon и рассказал, почему нам всем нужно понять, что мы идиоты, чтобы успешно работать вместе.

Анна Гуляева

Опубликовано

/

     
     

Разработчик Ричард Тертон выступил на конференции RWDevCon и рассказал, почему нам всем нужно понять, что мы идиоты (подсказка – чтобы успешно работать вместе).

Привет. Меня зовут Рич и я идиот. Сегодня я хочу рассказать вам три вещи: что я идиот, что вы, возможно, идиот и как быть идиотом.

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

Шаг 1: Я идиот

Я слева

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

Все признаки идиота

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

Я постоянно путаюсь в самых базовых и простых вещах в жизни. Вот вам пример: у меня две маленьких дочери и у них есть по два ящика для одежды. Я работаю из дома, поэтому я занимаюсь стиркой, пока Xcode восстанавливается после сбоя или делает что-то ещё. Итак, после стирки я раскладываю вещи по двум ящикам. Один ящик – для верха, другой – для низа. Футболка – это верх. Леггинсы – это низ.

А платье? Платье – это верх или низ? Я не знаю. Наука не знает. Каждый раз я даю разный ответ на этот вопрос, поэтому мои дети каждый раз так долго переодеваются.

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

Этот пес знает больше, чем я

У меня нет образования программиста. Я был биохимиком, затем я был поваром, затем я снова стал биохимиком. Я пытался излечить рак. Это было сложно. Затем я работал над реестром костного мозга в банке крови и подумал: “Я вроде бы хочу быть программистом”. Но я не мог получить работу, потому что никогда не программировал. Единственной возможностью для меня было получить работу в компании, которая разработала собственный язык программирования – все кандидаты на должность не знали, как на нем писать.

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

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

  1. Я не знаю, что такое двоичная сортировка.
  2. Я левша, поэтому когда я пишу на доске, всё стирается.
  3. На самом деле, три проблемы, потому что мой почерк нечитаем.

Когда я работаю над кодом, я постоянно совершаю одни и те же ошибки. Например, операторы greater-than и less-than. Я постоянно их путаю, хотя знаю правило про голодного крокодила. Оно просто не появляется у меня в мозге в нужный момент. То же самое с минимумом и максимумом.

Сейчас я работаю с суперумными людьми в агентстве MartianCraft. Я не знаю, слышали ли вы о нем, но люди, основавшие MartianCraft, пишут книги о создании iOS-приложений. Вы легко можете представить, как иногда я чувствую, что мне там не место, ведь эти люди могут использовать операторы greater-than и less-than правильно с первого раза.

Но это нормально. Если вы думаете, что вы лучший человек в комнате, вы либо неправы, либо вы в неправильной комнате. Если я работаю или общаюсь на конференции/в Twitter/в Slack и думаю: “О, этот человек намного умнее и лучше меня” – это отлично! Это мой шанс узнать что-то новое.

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

Шаг 2: мы все идиоты

Надеюсь, я донес свою первую мысль. Теперь более сложная часть: мне нужно убедить вас, что вы идиот. Я сделаю это, показав вам некоторые цитаты от людей, которых я называю “высокоэффективными идиотами”. Я надеюсь, что некоторые цитаты заставят вас подумать: “Да, я был в такой ситуации”. И может быть, вы начнете думать, что и вы идиот.

У всех нас было так, что целый день вы пытаетесь что-то сделать, но оно не работает и не работает. Затем вы резко понимаете, что происходит, и чувствуете себя гением! Этот переход и это чувство… Это главная причина, по которой я люблю свою работу. Переход от состояния гения к состоянию идиота не так приятен; но я думаю, что однажды Уильям Шекспир сказал: “Жизнь – это американские горки, вы просто должны на ней ехать”.

Следующий твит принадлежит Алексису, который выступал до меня. “Никто на самом деле не знает, как кодить, мы все просто бродим, бесплодно молясь об освобождении”. Очень поэтично, не так ли? У вас, скорее всего, были дни, когда вы просто перебирали случайные вещи, чтобы решить проблему. Затем, внезапно, вы всё исправляете. Вы просто делаете это и движетесь дальше.

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

Отличная цитата. “Самый важный навык для программистов – чувствовать себя комфортно, не зная, что вы делаете”. Почти каждый раз, когда я что-то начинаю, я очень комфортно чувствую себя в этой ситуации.

Когда Swift только появился, я начинал новый проект на работе и подумал: “Я сделаю его на Swift! Какая отличная возможность.” Итак, я создаю новый проект, выбираю язык и появляется Swift. Но…как с ним работать? Я не знаю! Это нормально, так вы учитесь чему-то новому.

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

Готовы вступить в клуб?

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

Если вы все ещё не верите мне, вы, возможно, находитесь в фазе риска на этом графике.

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

Шаг 3: как быть идиотом

Первый шаг к успеху – всегда помнить о том, что вы идиот. Не давайте своему идиотскому мозгу много задач. Не пытайтесь запомнить всё. Делайте записи. Используйте список задач. Используйте диспетчер сниппетов.

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

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

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

Пишите для идиотов

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

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

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

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

Я пишу для этого идиота

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

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

Джеймс Джойс не знал, как быть идиотом

Возможно, вы делаете всё неправильно

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

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

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

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

Не будьте умным

Есть и другой вопрос, который вы должны постоянно задавать себе: “Становлюсь ли я слишком умным?” У меня есть цитаты об этом:

Умный код нельзя исправить.

Умный код – это как съесть целый луковый цветок из Outback. Вы будете гордиться собой, но позже вы за это заплатите.

Умный код – это не добродетель. Прошлым летом я работал над образовательными материалами для людей, которые хотят изучать Swift с нулевым знанием о программировании. Было интересно вернуться к основам со всеми знаниями, которые я накопил в своей голове. Что такое переменная, что такое константа? Как сказать компьютеру, что нужно сделать? И Swift позволяет вам выразить эти идеи очень-очень просто.

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

Целые блоги заполнены такими вещами. Можете ли вы сказать, что делает этот код? Сможете ли вы сделать это снова через три месяца? Даже этот код в замешательстве – посмотрите на это лицо в середине.

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

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

Просите о помощи

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

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

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

Если вы работаете в одиночку или ваши коллеги не помогают вам, вы можете задать вопросы на Stack Overflow. Чтобы задавать вопросы на таком сайте, вы должны использовать свой идиотизм. Вам нужно понятно всё объяснить и не использовать ненужных деталей. Представьте, что этот вопрос прочитают идиоты. И много идиотов попытаются ответить на ваш вопрос.

Помогайте другим

Как идиоту успешно ответить на вопрос? Используйте свой идиотизм.

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

Этот утенок научился плавать (и кодить), задавая вопросы отзывчивым идиотам на Stack Overflow

И, конечно, вы можете не знать ответ на вопрос. Это нормально. Вы можете провести небольшое исследование и попытаться найти ответ самостоятельно. Я узнал так много разных вещей на Stack Overflow таким образом! И это гораздо эффективнее, чем просто создание проекта, потому что проект обычно задействует меньше областей знания.

Будьте идиотом

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

  1. Общайтесь понятно
  2. Помогайте друг другу

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

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

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
5 комментариев

5 Comments

  1. Konstantin Konopko

    01.08.2017 at 18:27

    Статья отличная! Но уберите функцию Поделиться при выделении текста — я просто читаю выделяя текст, чтобы пометить где остановился.

You must be logged in to post a comment Login

Leave a Reply

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

Опубликовано

/

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

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

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

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

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

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

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

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

Правка 3: Использование Optionals вместо null

Одна из лучших функций Java 8 – это класс Optional, который представляет собой объект, который может существовать или не существовать.

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

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

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

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

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

 

Комментарии
Продолжить чтение

Новости

Физтехи стали чемпионами России по программированию

2-3 декабря 2017 года команда МФТИ MIPT Cryptozoology в составе Александра Останина, Александра Голованова, Никиты Уварова завоевали абсолютное первое место в полуфинале чемпионата мира по программированию ACM ICPC.

AppTractor

Опубликовано

/

Автор:

В минувшие выходные на четырёх площадках России и СНГ состоялся полуфинал международного студенческого чемпионата мира по программированию ACM ICPC — Northern Eurasia Regional Contest. Более 300 команд собрались в университетах Санкт-Петербурга, Барнаула, Тбилиси и Алматы, чтобы побороться за победу на финале в Пекине.

Правила соревнования традиционны для всех этапов чемпионата по программированию ACM ICPC: у участников есть пять часов для решения 12 задач. При оценке результатов оценивается не только правильное решение задачи, но и время, затраченное на неё — победителем становится та команда, которая смогла выполнить наибольшее количество задач за наименьшее количество времени.

В Университет ИТМО приехали 128 команд. Рекордное количество команд представил Физтех — на полуфинал приехали целых семь!

В этом году абсолютным лидером полуфинала NEERC стала команда МФТИ Cryptozoology в составе Александра Останина, Александра Голованова, Никиты Уварова, тренер Михаил Тихомиров, руководитель Алексей Малеев. Первое место в полуфинале чемпионата студенты МФТИ занимают впервые. Ранее, в октябре, эта же команда заняла первое место в 1/4 чемпионата, завоевав титул чемпионов Москвы.

Ребята смогли решить 10 из 12 задач. Как отмечает Олег Христенко, комментатор онлайн-трансляции чемпионата, один из тренеров Центра развития ИТ-образования, команда шла «правильной дорогой», решая задачи в порядке сложности.

«Задачи были хорошие, некоторые было просто решить, некоторые не очень. Вообще надеемся на золотую медаль в этом году», — комментирует победу Александр Голованов.

«Очень приятно, что в этот раз победу одержали, от себя могу добавить, что они много тренировались, в частности, уже в этом учебном году отработали с полной отдачей на сборах в Петрозаводске, Барселоне и Долгопрудном. Это отличный результат, очередной шаг признания высокого уровня подготовки студентов МФТИ в области Computer Science», – говорит директор Центра развития ИТ-образования, Алексей Малеев.

По итогам соревнования в финал прошли 16 команд, 14 (88%) из которых принимали участие в тренировочных сборах Moscow Workshops ACM ICPC в этом учебном году. Все они поедут на финал, который состоится 20-25 апреля в Пекине.

Комментарии
Продолжить чтение

Программирование

Программирование это новый пузырь?

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

Анна Гуляева

Опубликовано

/

Моя подруга недавно задала вопрос, который я слышал много раз в разных вариациях:

Не кажется ли вам, что некоторые низкоуровневые профессии программистов вымрут как птицы додо? Сейчас это похоже на большой пузырь, который рано или поздно лопнет. Мне кажется, что одна из причин “престижности” технологических и связанных с наукой (на низком уровне) профессий заключается в нелепом жаргоне индустрии и всеобщей компьютерной неграмотности, и оба этих фактора исчезнут в следующие десять лет […]

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

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

Движение к коммодификации

Страх того, что алгоритмы заменят людей на работе, — не нов и не беспричинен. В любой области, а особенно в технологии, силы рынка подталкивают корпорации к автоматизации и коммодификации. Один из способов изображения этого явления — циклы хайпа Gartner.

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

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

В этой метафоре «машиной» является язык программирования. Этот профессор спрашивал: вы хотите делать сайты на JavaScript или вы хотите создавать движок V8 для JavaScript?

Создание веб-сайтов уже автоматизировано при помощи WordPress и других сервисов. С другой стороны, у V8 появляются конкуренты, некоторые из которых решают открытые вопросы. Языки приходят и уходят (сколько сейчас открыто вакансий для Fortran?), но всегда будут люди, создающие следующий язык. К счастью для нас, все реализации пишутся на языках программирования. Путь «оператора машины» в программировании делает вас «создателем машины» в том смысле, который оказался неверным для работников сталелитейных заводом в прошлом.

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

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

Кто автоматизирует кого?

AWS, Heroku и другие аналогичные хостинговые платформы навсегда изменили роль системного администратора и DevOps-инженера. Раньше интернет-бизнесу был необходим свой “мастер серверов”. Кто-то, кто был подкован в Linux, мог настроить сервер Apache или NGINX, подключить все физические компоненты и сделать все необходимое для того, чтобы сервер стал доступным в публичном вебе. Хотя некоторые люди по-прежнему применяют этот навык в работе, AWS делают некоторые из этих навыков устаревшими, особенно на уровне небольшого опыта и размещения оборудования. В Amazon, Netflix и Google существуют хорошо оплачиваемые вакансии для людей с глубокими знаниями в инфраструктуре сетей, но спрос в малом и среднем бизнесе на таких людей значительно упал.

Инструменты бизнес-аналитики, такие как SalesForce, Tableau и SpotFire также начали занимать пространство, которое исторически занимали инженеры. Эти системы сократили потребность в штатных администраторах баз данных, но они увеличили спрос на понимание SQL. Они сократили потребность во внутренней технологии отчетности, но увеличили спрос на «инженеров интеграции», которые автоматизируют поток данных к сторонним платформам. Ранее этим полем правили Excel и таблицы, а теперь оно перешло к языкам вроде Python и R, а также SQL для управления данными. Некоторые профессии исчезли, но в целом спрос на разработчиков программ вырос.

Data Science — это ещё один интересный пример коммодификации, более близкой к программированию. Scikit.learn, Tensorflow и PyTorch — это библиотеки, которые упрощают людям задачу создания приложений с машинным обучением, устраняя необходимость создания алгоритмов с нуля. На самом деле, теперь возможно провести набор данных через многие алгоритмы машинного обучения с разными параметрами, практически не понимая работу этих алгоритмом (это неправильно, но возможно). Компании бизнес-аналитики, вероятно, будут пытаться интегрировать эти алгоритмы в свои инструменты в следующие несколько лет.

Во многом Data Science сейчас похожа на веб-разработку 5–8 лет назад. Это популярная область, в которую вы можете попасть с небольшим количеством знаний из-за «разрыва в навыках». Программы по веб-разработке закрываются, а программы по data science появляются на их месте. Kaplan, которая купила первый лагерь по веб-рзработке Dev Bootcamp и основала лагерь по data science Metis, решила закрыть Dev BootCamp и поддерживать Metis.

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

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

В этом контексте нельзя проигнорировать и физический аспект. Как сказал Майк Актон: «Программное обеспечение — это не платформа, аппаратное — платформа». Разработчикам стоит немного изучить компьютерную архитектуру и электротехнику. Большой переворот случится при появлении потребительского квантового компьютера, он изменит многое в профессиональном программировании.

Квантовые компьютеры пока далеки от нас, но растущий интерес к графическим процессорам и движение к параллелизации — это неминуемый сдвиг. Скорости работы процессоров остаются неизменными уже несколько лет, а за это время возникла потребность в машинном обучении. Желание работать с OpenMP, OpenCL, Go, CUDA и другими языками и фреймворками параллельной обработки данных никуда не денется и будет только нарастать. В ближайшем будущем параллелизация станет всеобщим требованием и выйдет за пределы ниш операционных систем, инфраструктуры и видеоигр.

Все учатся кодить

Веб-сайты повсеместны. Опрос Stack Overflow 2017 года показывает, что около 15% профессиональных разработчиков работают в компаниях, связанных с интернетом или веб-сервисами. Бюро статистики труда ожидает ускорение роста в веб-разработке (24% между 2014 и 2024). Благодаря видимости отрасли, многие сосредоточены на «сокращении разрыва в навыках». Лагери программирования обучают практически только веб-разработке, а онлайн-курсы по этой теме заполнили Udemy, Udacity, Coursera и другие платформы.

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

Изменение спроса на определенные технологии — это не новость. Языки и фреймворки всегда то набирают силу, то теряют популярность. Веб-разработка в своей текущей инкарнации (JS — король) рано или поздно пройдет путь веб-разработки в начале 2000-х (помните Flash?). Новым является то, что многие люди изучают исключительно современные фреймворки веб-разработки. Прежде чем вы назовете себя React-разработчиком, вспомните, что были люди, которые идентифицировали себя как Flash-разработчиков. Полагаться на определенный язык, фреймворк или технологию в своей карьере рискованно. Конечно, сложно предсказать, какие технологии останутся релевантными, но если вы собираетесь пойти ва-банк, я рекомендую положиться на эффект Линди и выбрать что-то вроде C, который уже перенес испытание временем.

У следующего поколения будет такой уровень врожденной технологической грамотности, которого нет у поколения X и миллениалов. Одним результатом этого станет то, что CMS будут использоваться по умолчанию. Сами инструменты станут лучше, и молодые сотрудники будут лучше ими пользоваться. Эта комбинация определенно снизит ценность низкоуровневых навыков IT и веб-разработки, когда молодые специалисты войдут на рынок труда. Школы следуют за этим трендом, предлагая курсы программирования и информатики, и образованные ученики смогут сразу после окончания стать стажерами-программистами.

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

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

Число людей с образованием в информатике и программировании продолжает расти. Университет Пердью сообщает, что количество заявлений на направление информатики удвоилось за пять лет. Корнелл сообщает об аналогичном росте числа выпускников по этому направлению. Этот тренд неудивителен в свете распространения ПО. Молодые люди не представляют будущего без компьютеров, поэтому хотят изучать то, что даст им уверенность в трудоустройстве.

Редкость и ожидание

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

Как и Эрик Эллиотт, я считаю, что существует много хороших вариантов попасть в программирование, и степень бакалавра для некоторых может быть не лучшим вариантом. В то же время я согласен с Уильямом Бейном о том, что базовые навыки критически важны для долговременной карьеры, и эту информацию пока сложно найти вне университета. Ранее я писал о том, какие навыки я считаю фундаментальными для будущих инженеров, и поэтому я присоединился к школе Bradfield.

Школ программирования становится больше – и это не просто так. Вы можете многое узнать о программировании без знаний о большом «О», неясных структурах данных и деталей об алгоритмах. Иногда выпускники Стэнфорда соперничают с выпускниками Hack Reactor, но это верно только для одной или двух областей. Выпускники курсов программирования пока не работают в области встроенных систем, криптографии, безопасности, робототехники, инфраструктуры сетей или в разработке и исследовании искусственного интеллекта. Хотя эти области быстро растут.

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

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

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

Бимодальные распределения заработной платы

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

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

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

Зарплаты мобильных разработчиков 2017: деньги, платформы, стаж и регионы

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

Комментарии
Продолжить чтение

Новости

Самые популярные языки программирования 2017

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

Леонид Боголюбов

Опубликовано

/

TIOBE (The Importance of Being Earnest), один из самых популярных рейтингов языков программирования, опубликовал данные за ноябрь 2017 года и, соответственно, весь год целиком. По данным компании, Java остается самым популярным языком программирования, а за ней следуют С и C++.

С другой стороны, PYPL (PopularitY of Programming Language), еще один рейтинг, так же определи Java как лидера, но на вторые места поставил Python и PHP.

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

Вот весь рейтинг за 2017 год:

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.