Какие бывают программисты: О типах программистов: специализация и мотивация

Восемь различных типов программистов / Блог компании Alconost / Хабр

Кадр из фильма Kingsman

Уверены, в этой статье вы точно узнаете своих сотрудников, а возможно, и себя. Шведский предприниматель и разработчик Дэвид Эльбе описал восемь типов программистов, с которыми ему приходилось иметь дело за последние 10 лет работы в проектах по веб-разработке. Какие типы лучше всего объединить в команду и какой код от них ждать — читайте в переводе от Alconost.

1. Агент 007

Кадр из мультфильма “Пингвины Мадагаскара”
Быстро вникает в ваши проблемы и решает их. Не очень заботится о качестве кода. Ему не придет в голову исправлять отступы в чужом коде. Если необходимо, «воспользуется скотчем».

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

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

Плохо срабатывается с Перфекционистом.

2. Господин 90 %

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

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

Не уживается с тестерами, но отлично соблюдает дедлайны. Объедините такого программиста в одну команду с Агентом 007. Это будет хорошая команда.

3. Любитель переписывать код

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

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

Если дать такому программисту существующий проект на PHP и MySQL, он начнет переписывать его на Go и базе данных, не поддерживающей SQL. И только потом он спросит, какую проблему необходимо было решить.

4. Перфекционист

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

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

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

5. Кодер-копипастер

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

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

6. Экспериментатор

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

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

Хорошо срабатывается с Любителем переписывать код.

7. Спагетти-кодер

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

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

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

8. Псевдокодер

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

if
  price of beer is less than 10
then
  do order drink
else
  exit foobar

В действительности это выглядит так, как будто он разговаривает с ребенком: «Ой, какой милашка! Принеси мамочке вон тот красный мячик! Умница, хороший программист!»

Ну как, узнали себя в каком-то из типов?

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Четыре типажа программистов / Хабр

Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

Некогда, забавы для и пользы ради, я подрабатывал в одном неплохом кадровом агентстве — собеседовал приходящих программистов на предмет знания C#/.NET. В мои обязанности не входило полное техническое интервью — скорее, начальный скрининг кандидатов чтобы понять who is who, отфильтровать совсем уж ужас и в случае чего дать советы что почитать и как усовершенствовать навыки. И был у того кадрового агентства один интересный клиент. Он у всех на слуху, но тогда мне про него мало что сказали — я только понял, что вроде как ищет он rock stars — высококвалифицированных разработчиков, при том независимо от используемых технологий. После того, как я порекомендовал для них несколько человек — со мной связалась заместитель ген. директора и пригласила на встречу, ибо мои рекомендации не совсем устраивали заказчика. Так я познакомился с учредителем. Там мне была рассказана очень интересная история о том, зачем им нужны rock stars и как это всё вместе работает. Оказалось что вовсе не rock stars нужны. Нужны, как дал мне понять руководитель — люди с крепкими фундаментальными знаниями (алгоритмы, проектирование, операционные системы, сетевые технологии), которые будут готовы к росту и развитию. И вот они их берут и развивают, а затем отправляют реализовывать довольно сложные аутсорс-проекты. Заодно мне рассказали какие проблемы в этом плане испытывает компания. Я ушел в раздумьях и довольно долго катал в голове эту бизнес-модель, равно как и мысли о российской IT-индустрии в целом и политике работы с кадровым составом в частности.

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

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

Линейный программист

Соль индустрии IT-шной. На таких людях, говорят, мир держится. Он же «хомячок». Он же «гребец на галере», но я предпочитаю избегать таких ярлыков, поэтому просто — «линейный программист». Он не хватает звезд с неба, не пишет своих компиляторов и СУБД. Ну максимум — сделает пару инструментов, чтобы облегчить себе жизнь, в остальном — просто решает рабочие задачи. Редко меняет место работы. Усидчив. К работе относится как к работе, без особого энтузиазма. В меру ленив. Дисциплинирован (но бывают исключения), однако без надлежащего управления быстро «расхлябывается» и теряет фокус. Управлять такими людьми можно по стандартным методикам — описанным например в книге Дж. Рейнвотера — Как пасти котов. Квалификация может варьироваться и определяется исключительно опытом и количеством проектов, в которых линейный программист принял участие. Иногда квалифицированные линейные программисты попадают на минимальные управленческие должности — их нарекают team lead и тут-то вышеуказанная книга им и пригождается. Но самая главная особенность линейного программиста — весьма частое отсутствие желания развиваться и экспериментировать. Он прекрасно решит даже очень нудную задачу, которую вы ему предложите, если та не будет слишком сложной. Он выберет как можно более быстрый и прямолинейный инструмент из тех, что знает. Развитие для этих людей носит спорадический характер и в основном идет «вширь»: изучить новый фреймворк или новый инструмент, который поможет лучше решать повседневные рабочие задачи. Или «пришел заказчик, который использует вот такую штуку — ну что уж, будем разбираться». Примечательно, что знания полученные в результате спорадического развития отдельных линейных программистов как раз и составляют опыт аутсорс-компании. Однако, двигать горы и исследовать окружающий мир «вглубь» самостоятельно линейного программиста чаще всего просто не тянет. Например изучать новый, хайповый язык программирования ему просто не интересно. Только если новый язык помогает в решении повседневных задач. И уж тем более разрабатывать свой язык — увольте. И это — нормально. Хуже всего то, что линейные программисты «каменеют» когда долго сидят на одном месте. То есть если у вас есть человек, который стабильно занимается концептуально одними и теми же проектами на протяжении 3-5 лет — то очень маловероятно, что он сменит типаж и будет развиваться «вглубь». Но вот раньше этого эмпирического срока — все возможно и зависит от бэкграунда.

Бэкграунд: разный. В «линейных программистах» могут оказаться и люди, прошедшие онлайн-курсы, и выпускники ВУЗов, некоторые олимпиадники, бывшие ученые технических направлений и даже люди из концептуально другой профессии (известны случаи когда дальнобойщики становились разработчиками на PHP). Важно понимать, что линейный программист — само по себе является бэкграундом и почвой для прыжка в другой типаж. Но! Прыгнет человек или нет — зависит прежде всего от его личных желаний, а не от навыков. Наличие того или иного бэкграунда определяет лишь направление потенциального прыжка, а не его вероятность! А вот вероятность прыжка с течением времени резко падает. Однако если вам нужен верный сотрудник на долгосрочный контракт — научитесь выявлять желающих «прыгнуть» заранее. Сбежит с проекта — будет неприятно.

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

Сильные стороны: усидчивость, ответственность, коммуникабельность (раз на раз), полная контролируемость, спокойное поведение в стрессовых для проекта ситуациях

Слабые стороны: сложные и/или нестандартные задачи, абстракции, поведение в стрессовых для компании ситуациях, говнокод опять же

Собеседование: стоит уделить внимание психологии: усидчивость, дисциплинированность, коммуникативные навыки, стремления, вот это всё. Так же имеет смысл поговорить о предыдущем опыте и посмотреть в резюме. Дать стандартное тестовое задание а-ля «написать чат на web sockets», смотреть на сроки выполнения, «вылизанность» задачи и адекватность подобранных инструментов. Хорошо идут технические вопросы на знание языков, протоколов, паттернов и стандартных бибилотек. Плюсом будет если соискатель уже имеет опыт конкретно с вашим набором фреймворков, но если нет — не беда. Если все остальное в порядке — разберется. Это его работа.

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

Rock star (Software Scientist)

Концентрированный исследователь. Такие больше похоже на классических ученых, но только от IT. Им интересны алгоритмы, теоретические исследования, концептуально новые направления в индустрии, но прежде всего — им интересно экспериментировать. Ради этих экспериментов их и нанимают, собственно. Они готовы часами копаться в сложных штуках и решать задачи, постановка которых другим людям даже не понятна. Они — эксперты в сложных вопросах. Они точно знают в каких случаях q-sort стоит заменить на heap sort и чем они отличаются, или может быть какие алгоритмы кластеризации подойдут для анализа потока биржевых котировок, а иные знают какие оптимизации используются внутри g++ и как они помогают жить. Костяк таких людей, например, способен разработать новый язык программирования и компилятор к нему. Или значительно улучшить какую-бы то ни было существующую систему. Еще они часто предрасположены к функциональному программированию. Ни на что не намекаю — просто статистическая закономерность. Кстати, говнокодить rock stars могут (особливо на стадии прототипирования идей), но в массе своей не допускают плохой код до финальных версий разрабатываемых ими вещей, стараются сделать все красиво, с комментариями и удобными программными интерфейсами.

Но.

Как всегда есть «но», которое все портит. Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им. За ваши деньги. И при том — за большие деньги. И при том — не факт что будет какой-то результат. То, что ваши задачи совпали с задачами, которые интересны rock star — очень и очень большая удача и счастливое стечение обстоятельств, не более. Но если завтра rock star-у взбредет в голову контрибьютить в GHC вместо улучшения вашей сборки MySQL — то у вас будет ограниченное количество времени чтобы быстро и решительно его уволить. При попытке заставить оного вернуться к своим задачам — получите, в зависимости от темперамента и ваших soft skills, или конфликты или тихий провал сроков. Ну хорошо хорошо, чтобы людей так капитально разворачивало — это бывает редко и происходит постепенно, да. А вот обратная ситуация — если пересадить rock star с улучшения вашей сборки MySQL на улучшение GHC против его желания — бывает достаточно часто. И, как нетрудно заметить, приводит к аналогичным последствиям. И именно это обстоятельство делает rock star категорически неприемлемым для аутсорса.

Именно поэтому rock stars лучше всего чувствуют себя в продуктовых компаниях (например JetBrains), где им дают полную свободу в рамках одного продукта и полностью исключают внезапную смену скоупа задач (разве что только через увольнение). Люди получают возможность заниматься теми задачами, которые им интересны, самореализовываться, раскрываться и их при этом особо никто не дергает. Получается хорошая штука — окей, идет в релиз. Нет? Ну и черт с ним. В таких условиях rock stars пускают корни, живут весьма долго (до десятка лет) и им хорошо.

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

Есть другой замечательный пример работы с rock stars — это Google, в котором rock star-у дают возможность заниматься тем, что он хочет. Google их кормит, поит, одевает и защищает от внешних угроз. Взамен — все, что rock star наизобретает — будет принадлежать и продвигаться Google, превращаясь в его продукты. Fair enough. Эдакие посевные инвестиции в отдельно взятой компании.

Бэкграунд: лицей или другая хорошая школа, высшее образование в хорошем ВУЗе по IT-специальности или же математике. Круглый (хотя бы овальный) отличник. Вероятно, участие в серьезной научно-исследовательской деятельности (научные публикации как плюс) и/или олимпиадное программирование прямо со школы.

Ценит: покой (пока решает задачу), свободный ненормированный график с возможностью удаленной работы, адекватность менеджмента, возможность поработать с другими rock stars, сложные, интересные и нестандартные задачи, стабильное финансирование. Офисные плюшки или воспринимает как должное или игнорирует напрочь, но в целом не испытывает к ним особого пиетета.

Сильные стороны: сложные задачи, исследовательская деятельность, нередко проектирование.

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

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

Чего спрашивать не стоит: не задавайте глупых вопросов. К глупым вопросам относится: детали реализации чего-либо а-ля «а что делает HTTP-заголовок Content-Length?», вопросы про коммуникативные навыки и прочая психология (да, rock stars могут обладать абсолютно мерзким характером — но что поделаешь, такова плата за них), и уж тем более не заикайтесь и даже не думайте проверять стрессоустойчивость. Пунктуальность проверяйте только на уровне «не пропадает на неделю и ладно».

Делец (Software Engineer)

Редкий зверь в наших краях. Его иногда называют «ориентированный на результат», «любой каприз за ваши деньги». Эдакий линейный программист, который неожиданно (а на самом деле — предсказуемо) обзавелся самостоятельностью, самомотивацией и начавший расти туда, куда считает нужным. Это не rock star, потому что его не интересуют глубокие и абстрактные задачи. Его интересуют работающие инструменты, приносящие конкретную, ощутимую пользу, которую можно потрогать руками здесь и сейчас (зачастую — в виде хрустящих купюр в кармане, но об этом позже). Если работающего инструмента нет — делец делает его для себя сам. Очень любит конкретику в постановках задач, в технологиях и — что самое важное — в общении. Про таких еще говорят «строгий, но справедливый». Коммуникативные навыки хорошие. Политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Делец таков не от хорошей жизни, потому как грубиянов и молчунов суровая реальность дельца быстро ставит на место. Будешь грубить — угрохаешь репутацию. Будешь молчать — не получишь заказы. Не будешь избегать и разрешать конфликты, лезть на рожон — останешься без денег. Материалист. Работает с теми задачами, которые ставит для него объективная реальность. Если чего-то не понимает — спрашивает и добивается конкретного ответа. Его хлеб — тщательно подобранный или разработанный собственноручно инструментарий, опыт, умение разбираться во всякой гадости в приемлемые сроки и работа на скорость и на качество. Инструментарий подбирает сам или посоветовавшись с другими дельцами — и не дай вам б-же дать ему совет в этот момент. Ответственный. Хороший делец не срывает сроки и обеспечивает рабочий и поддерживаемый продукт. К говнокоду относится как к одному из инструментов. Может занять технического долга, если это уместно и полезно в конкретной ситуации, учитывая специфику проекта. Сведущ в менеджменте. Нередко понимает в нем больше, чем непосредственный начальник. На основании этого может рекомендовать ad-hoc управленческие решения. Из профессиональных изъянов стоит отметить невнимательность к мелочам, но и это у хороших дельцов лечится.

Крутое описание — не правда ли? В чем же подвох? Подвоха тут два. Первый заключается в том, что делец не терпит над собой никакого начальства, особенно если оно менее квалифицированно чем сам делец. Во многом это обусловлено той самой осведомленностью о способах менеджмента. Ну еще и тем, что делец сам прекрасно понимает как делаются деньги в IT-индустрии. Как следствие — делец не подчиняется приказам. Делец сотрудничает в рамках контрактов. Любая попытка заставить дельца делать что-либо за пределами контракта (если не формально подписанного — то хотя бы устно оговоренного) — ведет к вежливому отказу в лучшем случае или к расторжению контракта в худшем. Если делец не подписывался отсылать вам ежедневные отчеты — он этого делать не будет. Если не подписывался тратить на вас 8 часов в день (при наличии сроков сдачи задания) — то он этого делать не будет. Если не подписывался на правки по проекту — ну вы поняли. Однако если вы выкупаете оптом какое-то кол-во рабочего времени дельца (без конкретных сроков и конкретных задач), то он с радостью будет выслушивать ваши стенания, невнятные требования, поддакивать и участвовать в любой корпоративной шизе — ну а что? Уплочено же. Любой каприз за ваши деньги.

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

Долгосрочными контрактами на маленькие ежемесячные суммы его не заманишь. Только на большие — выкупайте рабочее время оптом, да. Как следствие — делец часто меняет место работы (в той мере, в которой для него существует это понятие). Засидишься — станешь линейным программистом. Как следствие — квалифицирован решать довольно широкий спектр задач. Помните — хороший делец всегда стоит своих денег. А если вы не дадите ему достаточно денег — делец попытается реквизировать рычаги управления. Разными способами — от наглого увода заказчика и команды (если у него есть такие полномочия), до честного разговора по душам. Если это не удастся — он вас быстро и решительно покинет, потому как а зачем? Хорошие дельцы заканчивают открытием собственных компаний, но, как было сказано выше, дельцов в нашей стране в принципе мало.

Бэкграунд: часто самоучка. Занимается программированием потому что интересно. Высшее образование наличествует, но стоит смотреть на репутацию учебного заведения. Если учебное заведение серьезное — то троечник. Ибо как работает с первого курса. Да и вообще изучению всяких наук предпочитает по-скорее добраться до реальной работы. Очень часто фрилансит. У некоторых дельцов проблемы с фундаментальными знаниями. Однако если это точно делец — то эти проблемы легко решаются.

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

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

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

Собеседование: хорошего дельца найти трудно. Ваш друг — репутация. Посмотрите резюме, не поленитесь связаться с человеком, который сотрудничал с соискателем ранее. Если речь идет об удаленной работе — посмотрите что у соискателя с доступностью. Как быстро он отвечает на почту и сообщения, телефонные звонки. Если лично — насколько пунктуален по назначенным встречам. Дальше расспросите о знаниях требуемой технологии. Но только так — без фанатизма. Конечно неплохо если делец точно знает какой адрес в памяти у функции закрытия подключения в проприетарной библиотеке, которую вы используете — но поверьте, это не то, что следует спрашивать. Неплохо будет попросить примеры проектов, которые делец уже реализовал на вашем стеке/с использованием вашей технологии. У хорошего дельца всегда найдется что показать и рассказать. Задачи на проектирование и «как решить вот эту проблему с заданной технологией» идут на ура, особенно если приправлять проектными деталями (например решить задачу в условиях когда заказчик требует релиза каждую неделю и т.п.).

Чего спрашивать не стоит: алгоритмические вопросы, математика, задачки на внимательность и прочая чепуха, которую спрашивают у rock stars. Разве что только на уровне концепции. Ну то есть делец может в общих чертах знать что такое, скажем, бикубическая интерполяция, но не заставляйте его реализовывать её на бумаге или на компьютере без интернета — будете справедливо (но вежливо) посланы. Отдельным пунктом следует упомянуть тестовое задание. Не давайте стандартных тестовых заданий: хороший делец таких заданий за всю жизнь переделал столько, что вам и не снилось и еще одно ему вот вообще не нужно. Далее. Смиритесь с тем фактом, что тестовое задание — это трата рабочего времени дельца. Приготовьтесь к тому, что оно будет платным. Предложите заключить NDA, временный контракт и сделать, например, коммит с фиксом бага для какого-нибудь вашего продукта или какой-либо системы с условием оплаты по выполнению и оговоренными требованиями к качеству. Это — самый эффективный метод. Не забудьте рассказать как настроить окружение. У хорошего дельца это не займет много времени, но бывают казусы.

Пассажир (business bullshitter)

У этого типажа много «ласковых» названий в народе. Наименее квалифицированные коллеги ему подчиняются, более квалифицированные его не любят. Начальники таких обожают и дальше я объясню почему. Кратко: пассажир харизматичен. Всё. Много и красиво говорит, но катастрофически мало (или некачественно) делает. Повышенная коммуникабельность — его хлеб и зачастую пассажир попадает на менеджерские должности, так как не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить начальника что именно он и должен руководить проектом. Во всем он демонстрирует серьезность, рвение и уверенность в себе, стремится порешать любую проблему, организовать совещание и обсудить, обязательно учитывая мнение команды. Со стороны может показаться что у него шило в известном месте. Он почти всегда на связи, всем отвечает на письма, показательно вежлив (так, что врезать порой хочется извините вырвалось) и может найти подход хоть к самому дьяволу. Один только минус — техническая квалификация. По правде говоря, ему не очень нравится программирование (вплоть до отвращения), но очень нравится покомандовать. Поэтому слабую техническую квалификацию (или её полное отсутствие) он часто «замазывает» красивыми словами, показным участием, заинтересованностью, дружелюбием и коммуникабельностью. Одна из самых страшных ошибок — ставить таких людей на средние менеджерские должности в командах. Как только вы это сделали — всё. Вы больше не получите достоверных данных о том, что происходит внутри команды с технической точки зрения. У вас будет красиво представленный бриф по происодящему, но те места, которые пассажир не понимает на техническом уровне будут из него исключены. А это в 90% случаев — скрытые проблемы и разнообразные детонаторы.

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

Бэкграунд: «лидер класса», «альфа-самец» в университете (жалко что не проверишь никак). Мистер обаяние. Образование может быть разным. Однако имейте в виду, что оценки могли получаться так же через ораторский навык. Программированием мог начать заниматься потому что интересно, но с таким обаянием у него были вещи в жизни и по-важнее. Нередко имеет свой персональный web-сайт на отдельном домене. Сделал его сам.

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

Сильные стороны: коммуникабельность, способность убеждать, способность доносить информацию красочно, с шутками-прибаутками, про стрессоустойчивость лучше спрашивать отдельно

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

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

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

Выводы

Отдельной строкой стоит заметить, что четкой границы между этими типажами нет. Человек вполне может находиться где-то между дельцом и rock star, или rock star может дрейфовать в сторону пассажира. А прямо сейчас какой-нибудь линейный программист может перепрыгивать в дельца, увольняясь с уютной галеры и заводя аккаунт на UpWork. Поздравим же его с этим! Однако концептуально я склонен считать, что стабильно и в долгосрочной перспективе любой программист плотно обосновывается в одном из этих четырех типажей.

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

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

Спасибо за внимание! Хороших вам кадров!

16 типов программистов, или Разработчики – это не одинаковые роботы / Хабр

Часто можно услышать такие слова, как “впишется / не впишется в коллектив” в адрес того или иного разработчика. У кого-то это вызывает возмущение, у кого-то руки опускаются после очередного отказа на собеседовании или при внезапном увольнении. Да и с обратной стороны баррикад этот вопрос не дает людям покоя. А в последнее время на фоне всей этой ситуации с коронавирусом пошли слухи о массовых сокращениях и я решил поговорить немного на тему управления коллективом.

Задумывались ли вы, по каким принципам вы выбираете себе сотрудников? Кого нанять, кого уволить, кого перевести в другое место? Ну то есть помимо чисто технических знаний? Интуиция? Если да, то это как-то странно, должны же быть какие-то более систематизированные соображения на этот счет…

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

Прежде, чем начать, предупреждение

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

№1. “Невидимка”

Он как бы есть, но как бы и нет. Часто он будет “непризнанным лидером” в коллективе – вроде бы и код пишет, вроде бы и полезные идеи предлагает, может быть даже тасок закрывает больше других… Но тимлидом делают кого-то другого, на конференции отправляют кого-то другого, новый монитор покупают кому-то другому, и этот программист начинает всем доказывать, что он круче всех, чтобы его заметили. Причем эти доказывания быстро утекают из рабочих обязанностей в какие-то словесные дуэли с коллегами и соревнования разного рода. Но честные ли они будут? Может быть. Но скорее нет. Он часто будет сам придумывать правила игры и жульничать, только чтобы победить. Хотя возможность показать себя в сложной ситуации ему тоже будет на руку. А если его не заметят – он будет придумывать все новые способы стать “круче” окружающих.

(+): Ему можно дать невыполнимую задачу и он ее решит из принципа, чтобы показать, что он может.

(–): Склонен совершать необдуманные поступки, нуждается в присматривании.

№2. “Одержимый”

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

(+): Может быть классным евангелистом и продвигать действительно полезные идеи.

(–): Неуправляемый. Тут скорее “вы с ним”, чем “он с вами”.

№3. “Рецидивист”

Совершает преступления против человечества – использует все возможные антипаттерны программирования, его код похож на доширак из костылей. Ему даже самому может быть тошно, даже если он никому этого не говорит. Рано или поздно проект становится тяжело поддерживать. Что можно в этой ситуации сделать? — Правильно, написать больше костылей, чтобы хоть как-то, но работало. Это позволит ему писать еще больше костылей, еще сильнее увязая в этой пучине.

(+): Внедрит все необходимые решения.

(–): В одиночку может увеличить технический долг проекта до бесконечности.

№4. “Гений”

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

(+): Если вам нужно изобрести что-то новое – вы пришли по адресу.

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

№5. “Гладиатор”

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

(+): С легкостью принимает непопулярные решения, берется за грязную работу.

(–): Может внести хаос в коллектив, если подставит полезного сотрудника.

№6. “Творец”

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

(+): Ценный кадр, который не просто решает задачи, но и делает это хорошо.

(–): Часто становится жертвой корпоративных игр, нуждается в покровительстве.

№7. “Философ”

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

(+): Может быть сильным специалистом с широким кругозором.

(–): Не может работать в рамках системы, особенно в долгосрочных проектах.

№8. “Узник”

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

(+): Может работать в действительно тяжелых условиях, решителен.

(–): Часто груб, нужно следить за ним и разруливать конфликты.

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

№9. “Мученик”

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

(+): Станет центром спокойствия в условиях бури, очень стабильный сотрудник.

(–): Инициативы от него не ждите.

№10. “Беспомощный”

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

(+): Есть потенциал, может стать полезным и лояльным сотрудником.

(–): Требует вложений в себя.

№11. “Заглаживающий вину”

Этот персонаж часто будет оправдываться. За свои нехорошие действия или за подчиненных, но будет. Самая частая ситуация – нагородить костылей, сделать ужасный в плане поддержки проект, который коллегам стыдно показать, и защитить его словами, что “он решает задачи бизнеса”. Формально вы к его аргументам не подкопаетесь – ведь действительно задачи решает, да и на встречу в любых переговорах он идет, но вот побочные эффекты от его бесконечных спорных решений будут лезть из всех щелей, хотя на них всегда найдутся оправдания или контраргументы в виде объективно полезных дел.

(+): Может быть хорошим буфером между конфликтующими по интересам сторонами.

(–): Часто за ним приходится многое переделывать, поскольку нехорошие действия компенсируются только в моральном плане, но не по факту.

№12. “Бездельник”

Это тот самый вайтишник, который пришел за деньгами. Для него разработка – это смузи, макбуки, всякие технологичные игрушки и, конечно, деньги. Много денег. И развлечений, которые на них можно себе позволить. Проблема его в том, что он ничего не делает. Он не развивается, не создает ничего нового. Его можно привлечь конфеткой, но вот пользы от этого будет немного. Он хочет все и сразу, быстро истощается, часто увольняется. Вырастить из него узкоспециализированного профессионала будет невероятно сложно.

(+): Легко нанять, закрыть им горящую вакансию, не требующую глубоких знаний.

(–): Может быстро выдохнуться, начнет требовать больше, чем делает.

№13. “Лох”

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

(+): “Удобный”, покладистый сотрудник. Будет работать столько, сколько скажут.

(–): Будет истощаться, нужно со стороны следить, чтобы он не перегорел.

№14. “Потребитель”

Лояльность компании? Да вы шутите! Этот герой мыслит в категориях более приземленных. Если ему тепло и хорошо – он доволен. Если не хорошо – плюнет на всех не задумываясь и уйдет. Он может иметь хорошие навыки, но работать будет по часам: сколько заплатили – столько и поработал. Свое получил – ушел. Что-то не сделал? А в ТЗ оно было? Нет? Ну и все, вопрос закрыт. Переработки, особенно не оплачиваемые, быстро заставят его задуматься о том, чтобы вас покинуть. Да и вообще он не то, чтобы очень любил работать. Скорее он будет делать свою работу как попало, лишь бы получить свою награду и пойти ее тратить.

(+): Очень предсказуемый.

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

№15. “Конформист”

Ну мы тут в компании уже 20 лет так делаем, вроде все работает, так чего менять то? Как вы уже догадались, перемены – это не самая любимая вещь у такого программиста. Он будет сидеть на устаревшем стеке не потому, что он и правда так хорош, или потому, что на переписывание легаси нет денег, а скорее по привычке. Или даже из страха, что что-то поменяется. У таких разработчиков часто бывает страх, что молодые их “подсидят”, и если такой персонаж окажется у руля, то он будет плавать в древних решениях как рыба в воде, не допуская ничего нового, а молодые будут в этом болоте как без рук. И, надо сказать, что сидеть он так может очень долго. Иногда это хорошо, но иногда он может тормозить развитие в компании.

(+): Может быть “хранителем” старых и долгоживущих проектов, которые нужно поддерживать.

(–): Абсолютно несовместим с новыми технологиями.

№16. “Жертва”

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

(+): Может стабильно работать, не имеет каких-то неадекватных требований.

(–): Нуждается в защите и покровительстве.

Комбинации моделей поведения

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

Откуда взялся именно этот набор типажей?

Возможно вы уже задались вопросом о том, насколько этот набор универсальный. Ведь если заменить слово “программист” на другое название профессии, то поменяется не очень многое. И да, в этом вы правы. Данные типажи – это часть ядра “Пирамиды адаптации” — более глобальной и универсальной схемы, которую я разрабатываю в последнее время. Она описывает принципы, по которым человек адаптируется в обществе и связывает все эти модели поведения в единую схему. Если вы интересуетесь свежими идеями в психологии и социологии, то приглашаю вас ознакомиться с одноименной книгой, почитать PDF версию которой можно бесплатно по ссылке. Но это так, к слову.

А что вы думаете по этому поводу?

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

UPD:

Предполагалось, что статья заставит некоторых людей задуматься о том, что разработчики в их команде – простые люди. Они не плохие, не хорошие — они разные. Где-то они сильные, где-то слабые, где-то они могут сделать многое, а где-то они беспомощны и нуждаются в поддержке. Можно, конечно, закрывать глаза и называть вещи не своими именами, но это не изменит того факта, что ваши разработчики – это не одинаковые роботы и не всегда они смогут сработаться или хорошо вольются в проект. И не всегда они смогут измениться по вашему желанию. Это стоит учитывать при управлении коллективом, и когда я призывал поделиться опытом, как вы налаживаете работу программистов с разными типажами, я как-то думал, что больше людей задаются этим вопросом. Видимо это было ошибкой. Люди увидели исключительно классификацию, хотя этот набор персонажей должен был стать лишь иллюстрацией разных моделей поведения и подтолкнуть к размышлениям и обмену опытом.

Классификация разработчиков по рангам боевых искусств / Хабр

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

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

Толкование значений

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

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

Трёхсторонний подход

Для ясности каждый термин получит три характеристики:

1. Уровень мастерства

Описание уровня квалификации для этого термина, в моей интерпретации.

2. Параллель с рангами боевых искусств

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

3. Пример кода

Пример того, как человек этого уровня должен подойти к простой программистской задаче. Определение тут тривиальное и не задумывалось как реалистичный пример. Цель — сравнить и обсудить уровень квалификации. Простотой пример подобран так, чтобы подойти специалисту любого уровня. Вот какую проблему мы рассмотрим:

Вычислить сумму целых чисел

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

Я буду использовать Ruby для тривиальных примеров реализации. Код достаточно прост: он понятен, даже если вы не знаете Ruby.

3. Список

Обсуждаемые существительные:

• Новичок
• Кодер
• (Хакер)
• Программист
• Исследователь (computer scientist)
• Разработчик программного обеспечения
• Инженер программного обеспечения
• Архитектор программного обеспечения

Итак, начнём.

Когда я жил в Италии в юности — около 20 килограммов назад — то несколько лет практиковал дзюдо и кунг-фу. Тогда я узнал, что во многих боевых искусствах уровню мастерства соответствует цвет пояса. Обычно цвет изменяется от белого к чёрному, где уровень опыта соответствует темноте пояса.

Новичок носит белый пояс, потому что у него нет опыта. Белый цвет означает «новый и чистый». По мере тренировки пояс темнеет, демонстрируя прогресс. Цвет олицетворяет грязь, накопленную с тяжёлой работой и потом. Мастер боевых искусств с многолетним опытом в конечном итоге достигает чёрного пояса, который означает высокий уровень знаний и навыков.

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

Почему мы говорим о боевых искусствах?

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

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

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

Новичок: белый пояс

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

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

Мощные инструменты — это не то, что надёжные навыки

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

Вот как это делается под *nix:

$ gem install rails

…

$ rails new website

…

$ cd website

$ bin/rails server

...

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

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

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

Пример

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

array.inject(0){|sum,x| sum + x }

Конечно, это работает. Вот пример:

$ irb
2.4.2 :001 > array=[1,2,3]
 => [1, 2, 3] 
2.4.2 :002 > array.inject (0){|sum, x| sum + x }
 => 6

Это может работать у новичка, но он не понимает особенностей этого кода. Насколько он читаем? Насколько быстро выполняется по сравнению с другими вариантами? Легко ли его поддерживать? Почему он работает? Что именно произойдёт при выполнении этой строки? Сколько используется процессорного времени? Определены ли переменные sum и x после выполнения этой строки?

Начинающий разработчик на Ruby не знает ответов на большинство из этих вопросов.

Кодер: жёлтый пояс

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

Первый необходимый шаг

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

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

В отрасли кодеру обычно присваивают должность вроде «младшего разработчика» (jr. developer) или стажёра (developer in training).

Пример

Я думаю, что «Ruby-кодер» сможет придумать большинство нижеперечисленных методов вычисления суммы массива целых чисел и понять разницу между ними:

$ irb
2.4.2 :001 > array=[1,2,3]
 => [1,2,3]
2.4.2 :002 > array.inject (0){|sum, x| sum + x }
 => 6
2.4.2 :003 > sum=0;array.each { |x| sum+= x }
 => 6
2.4.2 :004 > array. sum
 => 6
2.4.2 :005 > array.inject(0, :+)
 => 6
2.4.2 :006 > array.reduce(0, :+)
 => 6
2.4.2 :007 > eval array.join '+'
 => 6

Если вам интересно, некоторые из этих методов ужасны, но они работают.

Хакер: джинсы без пояса

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

Не главный навык

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

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

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

Много видов «хакеров»

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

1. Компьютерный эксперт, который придерживается субкультуры технологий и программирования.
2. Человек, который может поставить под угрозу компьютерную безопасность из вредоносных (black-hat) или исследовательских (white-hat) целей.
3. Разработчик, который выполняет работу самым быстрым и грязным способом.
4. Человек, который изучает, экспериментирует или исследует телекоммуникационные системы, оборудование и системы, подключенные к телефонным сетям. Таких хакеров также называют фрикерами (phreaker).
5. Квалифицированный инженер, работающий очень близко к железу, чтобы получить лучший контроль над системой ради хорошего дела (т.е. чтобы выжать больше производительности из оборудования) или для вредоносных целей (т.е. чтобы использовать дыры в безопасности и найти способ обойти защиту операционной системы).

Некоторые примеры

Тип 3

Хакер типа 3 может выбрать такой вариант суммирования массива целых чисел:

$ irb

2.4.2 :001 > ‘echo «1 2 3» / bc’.to_i

=> 6

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

Тип 5

Хакеры типа 5 работают на очень низком уровне. Такие навыки нелегко приобрести и они могут быть очень ценными, если вы пытаетесь настроить защиту программного обеспечения или создать чрезвычайно высокопроизводительные приложения. Я никогда не был «хакером», но я программировал на низком уровне (C и ассемблер) и по-прежнему в глубине души считаю себя специалистом по низкоуровневому программированию.

Хакеры 5-го типа могут быть фантастическими уличными бойцами, с безумными навыками, которые утрут нос многим профессиональным программистам на некоторых специализированных задачах. Такие «хакеры» могли бы суммировать массив целых чисел с помощью ассемблера примерно так.

Программист: оранжевый пояс

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

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

С точки зрения должности, программистов часто именуют «разработчиками программного обеспечения» (Software Developer) или «инженерами-программистами» (Software Engineer).

В простом примере суммы массива целых чисел программист может написать код таким образом:

#!/usr/bin/env ruby
 
if ARGV.size==0
  puts "Usage: "
  puts "   sum [список целых чисел, разделённых пробелами]"
else
  puts ARGV.sum{|x| x.to_i}
end

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

$./sum

Usage:

sum [список целых чисел, разделённых пробелами]

$ sum 1 2 3

6

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

Исследователь: зелёный пояс

Исследователь (computer scientist) изучал информатику или в школе, или на работе. Он имеет хорошее понимание таких понятий:

• Основание Base-N (N = 2, 10, 16)
• Бинарные операции
• Булева логика
• Алгоритмическая сложность и нотация big-O
• Структуры данных (массивы, связанные списки, B-деревья, красно-чёрные деревья, очереди, стеки, хэш-таблицы, кучи, наборы, графы)
• Алгоритмы сортировки и когда их использовать
  • Базовое понимание NP-полноты

• Основные многопоточные алгоритмы
• Управление памятью и сборка мусора (только то, что ваш язык программирования сам заботится об управлении памятью, не значит, что можно пропустить эту тему)
• Указатели (нужно хотя бы понять концепцию, даже если вы не кодируете на C) и разницу между передачей параметров по значению или ссылке.
• Концепции ООП (интерфейсы, наследование, конструкторы, деструкторы, классы, объекты, абстракции, инкапсуляция, полиморфизм и т.д…)
• Объектно-ориентированный дизайн и шаблоны
• Рекурсия
• Некоторые основные понятия о динамическом программировании, жадных алгоритмах и амортизационном анализе, алгоритмах сравнения строк и аппроксимации

У исследователя степень по Computer Science или он много лет работал разработчиком, изучая прикладную информатику на работе. Как вы знаете, я не считаю, что для успешной карьеры разработчика необходима степень CS.

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

Учёный, вероятно, напишет такой же код для суммы чисел, как и программист. Разница в том, что учёный может сразу сказать, что сложность этого алгоритма O(n) времени. Как уже упоминалось, это элементарный пример, но вы уловили мысль.

Разработчик программного обеспечения: синий пояс

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

• Пишет более чистый, структурированный, поддерживаемый, документированный и читаемый код.
• Допускает меньше ошибок.
• Работает быстрее.
• Лучше работает в команде и понимает ценность процессов разработки.
• Лучше находит и оптимизирует узкие места кода и программных систем.
• Имеет больше опыта.

Пример

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

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

На Ruby основное приложение с использованием Sinatra может выглядеть примерно так:

require 'sinatra'
require "sinatra/config_file"
 
# Load the server configuration from config.yml:
config_file 'config.yml'
 
#
# EndPoints:
#
# /sum/n1 n2 n3 n4 ...
# Return:
#     {result: [sum of n1,n2,n3,n4,...]}
#
# Example:
#    $ curl http://localhost:8080/sum/1 2 3 4
#    {"result":"10"}
#
get '/sum/:numbers' do |numbers|
    {result: numbers.split(" ").collect{ |x| x.to_i}.sum}.to_json
end

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

Инженер-программист: коричневый пояс

Разница между разработчиком (software developer) и инженером-программистом (software engineer) тонкая; я это полностью признаю. Эти термины обычно используются как синонимы. Тем не менее, я предполагают, что инженер-программист — специалист, имеющий знания в области информатики и большой опыт в качестве разработчика программного обеспечения. Основные отличия:

• Возможность создания более масштабируемых систем.
• Долговечность. Они работают дольше и с меньшим количеством проблем.
• Меньше ошибок и лучшее качество кода.
• Умение выступать в роли технического руководителя проекта и команды.
• Отличные навыки сотрудничества и общения.
• Достаточное знание архитектуры программного обеспечения для выполнения работы.

В компаниях у таких разработчиков могут быть должности «старший разработчик» (senior developer) или «ведущий разработчик» (principal developer).

Пример

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

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

Пример становится глупым

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

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

Вы можете переместить список чисел в тело запроса, но тогда он больше не будет RESTFUL API, и запрос больше не будет кэшироваться. В этот момент возникнет соблазн изменить запрос на POST, но так он никогда не станет кэшируемым. В любом случае, обсуждение может продолжаться и продолжаться.

Критическая часть

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

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

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

Архитектор программного обеспечения: чёрный пояс

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

Пример

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

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

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

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

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

Какое программирование самое востребованное в 2019 году — статьи на Skillbox

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

Одно из разноплановых направлений. Здесь работают с JavaScript, PHP, Python, Java и Ruby, а также используют «язык структурированных запросов» SQL. Веб-разработка купается во внимании новичков-программистов. Но и конкуренция здесь высокая: чтобы оставаться на плаву, нужно постоянно следить за тенденциями.

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

Это направление считают самым перспективным. Смартфоны есть у всех, и их возможности непрерывно растут. Языки создания мобильных приложений: Java и Kotlin для Android, Swift для Apple, а также Python, JavaScript, C#.

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

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

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

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

Языки десктопа зависят от операционной системы:

• для Linux и кроссплатформенных приложений — C++;
• для macOS — Swift и Objective-C;
• для Windows — C#.

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

Не так давно по геймдеву сходили с ума все поголовно — он был на пике роста популярности. Сегодня страсти улеглись, но это по-прежнему уважаемая и интересная область интернет-технологий. Годовой оборот рынка в 2017 году оценили в 100 миллиардов долларов. Языки геймдева: С++, C#, Lua и JavaScript для браузерных игр.

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

Тоже модное сегодня направление в IT, которое выходит далеко за его пределы. Хранение, обработка и анализ больших данных есть в любой сфере экономики. Поэтому Data Science находится на стыке интернет-технологий и бизнеса.

Специалисту по Big Data необходимы серьезные знания математического анализа, статистики, машинного и глубокого обучения, текстовой аналитики. Языки программирования, на которых «говорят» здесь, — R, SAS и Python.

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

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

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

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

Интернету вещей пророчат большое будущее и активное развитие в ближайшее время. Аналитики компании Ericsson прогнозируют среднегодовой темп роста в размере 23% до 2021 года.

Интернет вещей — это создание smart-устройств, подключенных к сети умного города или дома.

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

Программные продукты для компаний из трендов не уйдут: наоборот, появляются новые и конкурируют между собой. Популярные в России — «Мегаплан», amoCRM, «Битрикс24», 1С. Лидеры международного рынка: SAP, Salesforce, Microsoft Dynamics CRM, Siebel Oracle CRM и другие.

SaaS — решения для менеджеров, PaaS — ПО для разработчиков, IaaS — сетевые ресурсы в качестве виртуальных машин и хранения данных

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

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

Парадигмы программирования: что это такое и в чём различия | GeekBrains

Как новичку разобраться в многообразии подходов

https://d2xzmw6cctk25h.cloudfront.net/post/1106/og_image/9e7d7916e93fd701e8ca8a0163da017c.png

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

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

Объектно-ориентированное программирование

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

Новичков зачастую пугает аббревиатура ООП, но освоить парадигму объектно-ориентированного программирования не так сложно, как кажется. В своё время эта идея оказалась вирусной: создавать объекты, принадлежащие классам, а также использовать методы в качестве действий, которые может выполнить объект или которые можно произвести над ним. Много специалистов по Computer Science придерживаются такого подхода. Большое преимущество здесь в том, что программисту, использующему ООП, легко разобраться, что происходит в программе. Достаточно посмотреть, какие действия производит каждый из объектов.

Легче всего использовать ООП в Python, посложнее — в C++. Но если в этих языках у программиста ещё есть возможность увильнуть от ООП (например, для Python вполне подходит функциональное программирование), то в Java и C# всегда необходимо создавать классы, одних функций недостаточно.

Функциональное программирование

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

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

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

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

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

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

Процедурное программирование

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

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

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

Метапрограммирование

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

Обобщённое программирование

В этой парадигме программист создаёт обобщённые представления для классов и функций. То есть не просто классы, которые могут наследоваться (как в ООП), а шаблоны функций или классов (если применить такой подход в C++). Изначально у них отсутствуют требования типа данных для входных параметров, поэтому шаблоны можно сделать более универсальными.

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

Логическое программирование

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

Возможность применить эту парадигму заложена в языке Prolog — он позволяет вводить предложения в виде фактов и набора правил. Разработку Prolog начали ещё в 1970 году, и целью было понять естественный язык. Логика используется как средство формализовать его семантику. Если располагать фактической информацией о предметной области, можно автоматизировать выдачу информации по схеме «вопрос — ответ».

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

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

Самоизоляция заканчивается — самое время освоить новую профессию, чтобы начать карьеру мечты и уверенно смотреть в будущее! Мы хотим помочь вам и с 1 по 10 июля 2020 г. дарим скидку 40% почти на все программы обучения GeekBrains. Будьте здоровы и успешны! 🙂

Как найти свою первую работу программистом?

Недавно мы с Алексеем Паршуковым, Unit Lead в SkyEng, ex-CTO DocDoc, проводили вебинар «Быстрый старт в Программировании с нуля» и обсудили различия в изучении языков программирования, суть профессии программиста, как устроиться на работу и какие бывают работодатели. Посмотреть вебинар вы можете по ссылке, а статью по нему прочитать прямо сейчас 🙂

Что такое работа программистом?

У профессии программиста есть очевидные плюсы, о которых всем известно:

• Хорошие зарплаты

От 100 т.р. по регионам России, 250-300 т.р в Москве, за рубежом от 10 тысяч долларов.;

• Гибкий график

Разработчик — это преимущественно удаленная работа;

• Востребованность на международном рынке

Это одна из самых простых профессий для иммиграции.

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

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

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

Как понять, подходит ли вам работа программистом?

Здесь не так важно, какое у вас образование, закончили ли вы институт по профессии. Главное, чтобы у вас была сильно развита усидчивость. Почему это так важно?

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

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

Чем занимается программист? — CareerExplorer

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

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

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

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

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

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

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

-Написание подробных функциональных спецификаций для процесса разработки аппаратного обеспечения
-Создание, тестирование и изменение прототипов продуктов с использованием моделей
-Проектирование, анализ, тестирование характеристик электрического / электронного / компьютерного оборудования
-Оценка интерфейса между аппаратным и программным обеспечением
-Оценка работоспособности и требования к производительности
-Подготовка проектов, определение спецификаций и определение рабочих планов
-Проектирование и разработка ЦП / поддержка логики / микропроцессоров / схем / дисководов
-Мониторинг функционирования и внесение необходимых изменений
-Мониторинг процессов на соответствие стандартам
-Рекомендовать технические изменения дизайна или процесса для повышения производительности
— Хранение, извлечение и обработка данных для анализа
— Анализ потребностей пользователей и рекомендация подходящего оборудования

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

— Инженер по автоматизации
— Компьютерный архитектор
— Инженер по вычислительной технике
— Разработчик компьютерного оборудования
— Разработчик компьютерного оборудования
— Инженер по установке компьютеров
— Инженер по электронике
— Инженер по обслуживанию на местах
— Инженер по проектированию аппаратного обеспечения
— Инженер по аппаратному обеспечению
— Консультант по информационным технологиям (Консультант по информационным технологиям)
— Сетевой инженер
— Системный инженер
— Системный интегратор
— Телекоммуникационный инженер

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

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

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

Карьера, связанная с веб-разработчиком

-Front End Web Developer
-Internet Architect
-PHP Web Developer
-Usability Specialist
-User Experience Designer
-User Interface Developer
-Web Applications Developer
-Web Architect
-Web Page Developer
-Web Programmer
-Website Разработчик
-Специалист по веб-сайтам
-Веб-специалист
-Вебмастер

Различные задания для веб-разработчиков

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

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

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

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

Карьера, связанная с разработчиком программного обеспечения

-Database Designer
-Database Developer
-Game Developer
-Video Game Engineer
-Information Architect
-Information Systems Analyst
-Information Technology Analyst (IT Analyst)
-Information Technology Consultant (IT Consultant)
-Interface Designer
— Software Analyst
— Архитектор программных приложений
— Разработчик программных приложений
— Разработчик программных приложений
— Инженер программных приложений
— Специалист по программным приложениям
— Компьютерный специалист по программному обеспечению
— Разработчик программного обеспечения
— Разработчик программного обеспечения
— Инженер по разработке программного обеспечения
— Системы программного обеспечения Инженер
— Системный аналитик Программист
— Инженер по удобству использования
— Дизайнер пользовательского интерфейса
— Программист программных приложений

Различные рабочие задания для разработчиков программного обеспечения

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

Разработчики баз данных
База данных (организованный набор данных) собирает, упорядочивает, сортирует и извлекает связанные части информации.Он запускается за кулисами пользовательского программного обеспечения и веб-сайтов и обычно хранится и доступен в электронном виде из компьютерной системы.

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

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

Карьера, связанная с разработчиком баз данных

— Администратор базы данных (DBA)
— Администратор сети
— Архитектор данных
— Аналитик проектирования базы данных
— Аналитик базы данных
— Координатор базы данных
— Аналитик проектирования базы данных
— Дизайнер баз данных
— Инженер базы данных
— Специалист по системе управления базами данных (Специалист по СУБД )
-Database Manager
-Database Modeler
-Database Programmer

Различные задания для разработчиков баз данных

-Проектирование и разработка программ баз данных
-Создание баз данных для хранения электронных данных
-Работа в составе проектной группы по координации разработки баз данных
-Разработка модели данных, описывающей элементы данных и их использование
-Анализ существующих баз данных и потребностей в данных клиенты для разработки систем
-Используйте определенные языки программирования и коды
-Следите за процессами внедрения новых баз данных
-Устраняйте неполадки и предлагайте решения для любых ошибок в новых приложениях баз данных
-Используйте новые и появляющиеся технологии
-Используйте навыки SQL
-Тест программы или базы данных и внести необходимые изменения
-Обновить информацию базы данных компьютера

Читать далее

.

Сколько инженеров-программистов в США и в мире?

Сколько разработчиков программного обеспечения в мире?

По данным Evans Data Corporation , в 2019 году в мире насчитывалось 26,4 миллиона разработчиков программного обеспечения, и ожидается, что их число вырастет в 2023 году до 27,7 миллиона и 28,7 миллиона в 2024 году. США лидируют. Позиция по количеству разработчиков ПО достигла 4,2 млн. человек.

Согласно расчетам IDC , в 2018 году количество разработчиков программного обеспечения в мире выросло до 22,3 миллиона, тогда как в 2014 году программистов было всего 18,5 миллиона.

Slashdata представила свою статистику, согласно которой в 2019 году в мире было 18,9 миллиона разработчиков программного обеспечения, и это число достигнет 45 миллионов в 2030 году.

9007

Количество разработчиков программного обеспечения в мире

Руководство по расценкам офшорных разработчиков

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

Сколько инженеров-программистов в США?

Evans Data Corporation сообщила, что в Северной Америке насчитывалось около 4,4 миллиона инженеров-программистов в 2016 году .

По данным DataUSA, количество людей, занятых в качестве разработчиков программного обеспечения, приложений и системного программного обеспечения в США, достигло 1,36 миллиона в 2017 году .

Don’t Quit Your Day Job дает оценку довольно близкую к Evans Data Corporation — 4,2 миллиона разработчиков программного обеспечения в США по состоянию на 2019 года. Это было вычислено при попытке выяснить, сколько разработчиков в разных штатах США.

Количество разработчиков программного обеспечения в США по разным источникам

.