Developer кто это в программировании

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

В первой части мы рассмотрели вопрос о том, какими вообще бывают IT-шники, и составили список разновидностей специалистов, которых планируем рассмотреть. Список далеко не полный, видов специализации на самом деле больше. Например, мне напомнили, что есть ещё data team (data engineer, data analyst, data science и business intelligence developer/analyst), это важные для современного бизнеса специализации, попробую рассмотреть и их, но потом.

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

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

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

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

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

Программировать можно на разных языках. Можно писать низкоуровневый код на С для каких-нибудь микроконтроллеров, которые используются, например, в промышленных станках либо коммутационном оборудовании. Можно писать на языке С++, например, занимаясь системным программированием, дописывая кусочек того же Linux. Можно писать на PHP, разрабатывая, например, сайт. Можно использовать Go, реализуя функционал распределенных вычислений для обработки каких-то очень больших данных. Можно писать на VB, делая всё то же самое, что и на C#, так как это одна и та же платформа .Net. А можно писать на том же самом VB (на самом деле VBA) макросы в MS Office. Есть ещё разновидности SQL для написания запросов в базы данных, причём у каждой базы свой диалект этого самого SQL. Для PostgeSQL свой SQL и свои методы оптимизации, для Oracle — свой, для MS SQL Server — свой.

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

Не стоит делать большой упор на знание конкретных языков. По опыту нашей компании разработчик на PHP осваивает Python где-то за две недели. Языки близкие. Разработчик на 1С пересаживается на Python за месяц. Единственное, мы знаем, как их обучать.

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

Ситуация сильно меняется, когда система либо очень большая, либо очень сложная. Тогда появляются уже младшие (junior), средние (middle), старшие (senior) программисты, технические лидеры, лидеры команд, архитекторы и другие ответвления от «просто» программистов. Иными словами, срабатывает масштабный фактор. Поэтому нельзя ставить знак равенства между программистом, который пишет интернет-магазины и middle developer, который на том же стеке технологий реализует внутренний корпоративный портал для большой организации.

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

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

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

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

Однако рассматривать стоит именно опыт коммерческой разработки, а не учебной либо «пет-проектов» (проект, как домашний «питомец»), и смотреть на те задачи, которые решал конкретный человек. Если 10 лет производить по одному «лендосу» в день-два, то выше уровня младшего программиста подняться всё равно не получится. Для роста нужен масштаб проекта.

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

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

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

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

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

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

Иными словами, интернет-магазин и корпоративный сайт вам сейчас и стажёр соберёт. Сегодня это технически несложное мероприятие. А качество итогового продукта зависит больше от UI/UX специалиста, чем от программиста.

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

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

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

Что такое задача среднего уровня? Например, нам нужен web-сервис для управления работой точек аренды велосипедов в парках. Реализовать весь этот сервис — задача среднего уровня. Почему так? Потому, что можно взять MVC-фреймворк (Model-View-Controller — популярная схема построения приложений), где уже продумана архитектура, решена основная масса типовых, но сложных технических проблем, создана документация по конфигурированию и доработке.

Вот именно такую задачу middle developer должен мочь правильно оценить и реализовать в срок без помощи других программистов, то есть «самостоятельно». Зачем пришлось брать самостоятельность в кавычки? Потому, что разработчик все равно будет работать в команде с UI/UX-специалистом, руководителем проекта, QA-специалистом и другими специалистами, по необходимости.

Если у middle developer много проектов, которые он выполняет «в одного», то появляется замечательная возможность получать обратную связь от окружающего мира, чтобы понимать, что ты делаешь не так. Однако для этого нужно задуматься о том, как сократить количество ошибок, которые доходят до QA, а потом до пользователя, задуматься о том, как разработанный функционал попадёт на продуктив (среда, в которой работают конечные пользователи), будет ли его легко администрировать, задуматься о том, а как это всё будет поддерживать служба поддержки пользователей, как они будут разбирать инциденты, насколько гибко и быстро они смогут компенсировать ошибки системы и много другое.

Фактически, когда у специалиста уровень осознанности вырастает настолько, что он начинает понимать, что он не только «индивидуальность», но и часть окружающего его мира (в том числе и систем, что его окружают), можно говорить о начальной стадии перехода к следующему уровню профессионального мастерства.

Что отличает старшего программиста от обычного программиста? Далеко не уровень «хард-скилов» (технических компетенций), а уровень мышления человека. Совершенное знание языков программирования и инструментов разработки не сделает человека старшим программистом.

Почему такое получается? Старший программист уже воспринимает систему целиком и может находить оптимальные пути реализации, исходя из общего понимания системы. Ещё он обладает коммуникационными навыками для того, чтобы объяснить/договориться с бизнес-аналитиками, UI/UX, QA, руководителем проекта и другими участниками команды о новом для них способе реализации.

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

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

Ещё такие люди являются хорошими наставниками. Именно наставниками, а не руководителями. Они умеют помогать людям вырасти. В том числе и до своего уровня. Конкуренция их не пугает, скорее они будут радоваться новому соратнику.

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

Иногда говорят, что в IT основная рабочая сила это — middle developer. Возможно. Но основная движущая сила — это senior developer. Без их работы техническая часть сложного проекта может просто не сдвинуться с места вне зависимости от количества middle developer.

Мы с вами прошлись по цепочке junior, middle, senior, но фактически не рассматривали «хард-скилы» и не говорили о языках программирования, совсем ничего не сказали про понимание ООП, паттерны проектирования (ну, только MVC упомянули), методы рефакторинга, приёмы построения архитектуры и другом. Почему так?

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

Нельзя забывать, что мы работаем в области «информационных технологий», то есть области сбора, хранения и обработки информации. Поэтому умение видеть потоки информации в системе, умение оперировать и изменять потоки информации в системе (целиком) будут определять итоговый уровень специалиста. Не важно, программист это, аналитик, руководитель проекта, QA, UI/UX либо ещё кто-то.

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

Теперь для простоты понимания:

Junior. Уже обладает базовыми знаниями и компетенциями. Но требует присутствие наставника при своей работе.

Middle. Способен самостоятельно решать стандартные задачи небольшой либо средней сложности. Способен решать небольшие нетиповые задачи.

Senior. Способен воспринимать систему целиком, способен находить оптимальные пути реализации. Имеет развитые коммуникационные навыки, умеет объяснять, убеждать и договариваться. Хорошо проявляет себя в качестве наставника. Может решать большие и сложные задачи как своими руками лично, так и руками middle и junior.

Мы рассмотрели этот вопрос на программистах и не будем его касаться с QC/QA, UI/UX, руководителями проектов, аналитиками, архитекторами, системными администраторами, devops и другими сотрудниками.

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

Так же мы разобрались откуда берётся деление специалистов по уровням, рассмотрев цепочку младший (junior), средний (middle), старший (senior) на примере программистов. Таким же образом растут системные администраторы, QC/QA специалисты, менеджеры проектов, владельцы продуктов и другие. Это умение охватить своим восприятием систему целиком, управлять потоками информации внутри системы и управлять развитием систем

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Про что текст

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

Группы ролей

Роли в ИТ можно разделить по нескольким срезам:

• по активности;
• по ответственности;
• по загруженности.

Разделение по активности

• производители;
• управленцы;
• проверяющие.

Разделение по ответственности

• без ответсвенности
• с ответственностью за качество
• с финансовой ответственностью

Разделение по назначению

• нанимаемые на позицию;
• взращиваемые в коллективе.

Описание ролей

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

Developer

• занимается производством программных алгоритмов;
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

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

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

Данная роль часто сегментируется по разделению ответственности:

• Back-end developer — разработчик программно-аппаратной части комплексного ПО;
• Front-end developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

Так же, роль сегментируется по платформам, под которые ведётся разработка, например:

• Web;
• Mobile;
• Server-Side;

User Experience Designer (UX)

• занимается производством карт пользовательского опыта;
• несёт ответственности за применение результата, но не несёт ответственность по финансовым рискам;
• нанимается на позицию.

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

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

User Interface Designer (UI)

• занимается производством графической составляющей интерфейсов;
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

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

Quality Assurance (QA)

• занимается проверкой результата
• не несёт ответственности за применение результата и по финансовым рискам;
• нанимается на позицию.

QA занимается тестированием всего, как бы странно это не звучало.

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

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

Human Resource (HR)

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

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

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

Team Leader

• отвечает за работу группы специалистов;
• несёт ответственности за командную работу, не несёт финансовых рисков;
• взращивается в коллективе.

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

Это важно понимать:

1. Team Leader всегда взращивается в среде, это единственный способ заработать авторитет в группе людей; нет авторитета, никто не будет слушать Team Leader, процессы будут идти своим путём;
2. Можно процесс взращивания ускорить, наняв одного из опытных Team Leader, но в коллектив он должен попасть сперва как рядовой специалист, заработать авторитет, только потом перейти на целевую позицию;
3. Роль больше не про управление командой, не про производство, а про решение проблем в работе команды, налаживание коммуникации внутри команды, выстраивание комфортных условий производства;
4. Team Leader обязан обладать аналитическими навыками и системным взглядом; просто делать, чтобы всем было “хорошо” не достаточно, основная задача — постоянное измерение внутренних метрик команды, как социальных, так и производственных, изменение процессов для повышение результативности.

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

Tech Leader

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

Особенностей всех ролей, в названии которых есть слово Leader, является то, что все они взращиваются в коллективе (см. выше).

Но данную роль я решил выделить, так как, на практике, её чаще всего путают с ролью Team Leader.

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

Tech Leader касается следующих аспектов работы команды:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

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

Scrum Master

С появление терминов Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики/опыта, к командам разработки стали прикреплять роль Scram Master.

• отвечает за грамотный применения той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще);
• несёт частичную ответственность за результат, но не несёт ответственность по финансовым рискам;
• нанимается на позицию.

Почему я решил описать данную роль? Так сложилось, что эту роль часто путают с Project Manager.

Давайте проясним ситуацию. Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правиал методологии, контролирует их выполнение.

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

Project Manager (PjM)

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

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager`а, ведётся (ставятся задачи), контролируется (контроль качества и эффективности), и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом. Когда скорость реализации быстрее планируемых сроков проекта, проектный фонд утилизируется не полностью, остаётся часть денег, которые по результату успешной сдачи проекта распределяется на премии участников. Распределением также занимается Project Manager.

Кто есть кто в IT. Чем занимаются PM-ы, frontend- и backend-девелоперы и QA

Hey! Все мы заглянули сюда, потому что нас заинтересовала работа в IT-сфере. Но вместо того, чтобы тыкать в первую попавшуюся IT специальность, возможно, стоит немного рассмотреть перечень возможных направлений в IT компании? Это вторая часть, моего небольшого обзора. В первой мы рассмотрели такие специальности, как Recruiter, HR, System admin, DBA, DevOps. Сегодня мы рассмотрим специальности, которые являются «костяками» любой команды и, соответственно, проекта.Если где-то что-то напутаю, сильно не ругайте, а лучше поправьте в комментах: я на всё смотрю со стороны Java-разработчика и нюансов всех специальностей могу попросту не знать.

Программист, кодер, девелопер (разработчик): сходства и отличия этих ролей?

Чем отличается продавец от менеджера по продажам от кассира от мерчендайзера?
Чем отличается клининг менеджер от мастера чистоты или от уборщика?

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