IT для неайтишников: Какими бывают IT-шники? Часть 2

Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Вторая часть статьи посвящена программистам, с ними тоже не всё так просто. Рассказывать буду простым языком, идя от простого к сложному.

Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и один из идеологов концепции IT~BP — IT бизнес-партнёрства https://itbp.org.

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на 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 не стоит на месте и постоянно развивается. Здесь, как и в зазеркалье из «Алиса в стране чудес», для того, чтобы стоять на месте, нужно весьма быстро бежать.

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

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

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

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

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

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

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

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

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

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

Стоит обратить внимание на масштабный фактор. В больших и средних проектах такой человек участвовать может только под надзором. Но он может самостоятельно делать мелкие проекты, типа «лендосов», корпоративных сайтов, интернет-магазинов, небольших 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 либо ещё кто-то.

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

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

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

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

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

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

Полезные материалы по теме: