Что такое мидл

Кто такой мидл? И как им стать?

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

Что значит быть мидл-разработчиком?

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

А чем мидл отличатся от джуна?

Главным требованием к мидл-разработчику является способность самостоятельно решать задачи. Будучи мидлом, ты уже знаком со стандартными шаблонами и решениями при построении приложения в своей области, понимаешь, зачем они нужны и умеешь их применять. Над тобой уже не сидит твой куратор — ты становишься более самостоятельным в сфере разработки. Мидл уже понимает, что работает в команде и взаимодействие — залог успеха. И конечно же деньги и опыт. Джун получает мало денег, но много опыта и подсказок благодаря куратору, а мидл — немного больше денег и опыт, но уже немного другой — собственный.

Характеристики, которые присущи мидлу:

• целеустремленность
• трудолюбие, ведь работать придется много
• мидл рассматривается в коллективе как ценный сотрудник
• креативный и нестандартный подход к решению тасков

Переход от джуна к мидлу занимает в среднем от 1 до 3 лет. В реальной жизни мидла можно сравнить с подростком, который считает, что он знает все лучше остальных. Эта стадия характеризуется тем, что мидл рассчитывает на то, что он знает все, что ему нужно знать и учить что-то новое нет нужды. Но с другой стороны, имея определенные навыки и знания, соответственно, как и подросток, мидл начинает креативить и экспериментировать.

Возьмут ли тебя в компанию мидлом?

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

Предыдущий

Junior, Middle, Senior в разработке — кто есть кто и как перейти на уровень выше

Junior зарабатывает от 40 000 ₽, Middle от 100 000 ₽, а Senior от 250 000 ₽ и выше.

Виктория Земскова
Автор статьи
29 марта 2022 в 16:59

Четкой границы между младшим (junior), средним (middle) и старшим специалистом (senior) в IT нет. В одной компании разработчик может быть крепким сеньором, а при переходе в другую компанию стать мидлом, но с сохранением заработной платы и даже ее повышением, потому что в другой компании уровни считаются иначе.

Рассказываем, в чём разница между junior, middle и senior, как понять, что вы уже не джуниор или что мидлу пора становиться сеньором. И что нужно сделать, чтобы продвигаться по карьерной лестнице.

Junior — первая ступень в разработке

Джуниор (junior) — это младший специалист. Он знает теорию, освоил синтаксис одного языка программирования и может писать на нём код. Если джуниор не умеет писать код, то это стажер.

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

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

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

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

Опыт. Год — полтора реальной разработки.

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

Софт-скилы (личностные качества). Восприятие критики, умение слушать, открытость новому, адаптируемость и обучаемость.

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

Станьте Java-разработчиком в два раза быстрее
Ускоренный курс для тех, кто хочет быстрее перейти на удаленку

Ответственность. Минимальная.

Зарплата. 40 000 ₽ — 100 000 ₽.

Пример вакансии стажера / backend-разработчика уровня junior на хедхантере

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

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

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

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

Сколько это займет времени. Зависит от компании: где-то разработчик остается на позиции джуниора два — три года, а в другой — перейдет на новый уровень за год. Разработчик тоже влияет на развитие своей карьеры. Джуниоры с опытом 10–15 лет не редкость, если специалист не хочет развиваться в профессии и брать больше ответственности.

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

Middle — крепкий середнячок

Мидл (middle) — средний специалист. Это основной разработчик, который выполняет поставленные задачи почти без ошибок. Знает языки программирования и использует дополнительные технологии — например, backend-разработчик погружается во фронтенд и учит Angular. Мидлу не нужна проверка кода, наоборот, он сам проверяет его и исправляет, чтобы тот стал простым и понятным.

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

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

Опыт. От двух до семи лет.

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

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

Задачи. Решает бизнес-задачи, которые закрывают конкретную проблему. Ему по силам изменить существующий сервис, добавить новые страницы интерфейса или функции API (протокол, с помощью которого программы общаются между собой и обмениваются информацией). Если говорить о тестировании, мидл умеет писать автотесты (программы для автоматического тестирования приложений) с нуля,без копирования кода, полностью самостоятельно. Мидл способен закрывать, не срывая сроков, 80% поставленных задач.

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

Зарплата. От 100 000 ₽ до 300 000 ₽.

Пример вакансии Python-разработчика уровня middle, от 160 000 ₽ до 260 000 ₽ на хедхантере

Что делать, чтобы перейти на следующий уровень. Для этого программисту нужно изучать новые технологии — например, мультиоблачные среды или блокчейн-технологии. Читать и анализировать исходный код популярных проектов: Facebook (организация признана экстремистской и запрещена на территории России), Uber, Netflix или «ВКонтакте». Изучать разные системы управления баз данных.

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

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

Senior — самый опытный в команде

Сеньор (senior) — старший разработчик. Уровень зависит не только от стажа в программировании. Если разработчик 10 лет занимается одинаковыми задачами, вырасти в сеньора не получится.

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

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

Опыт. От пяти до семи лет.

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

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

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

Ответственность. Отвечает за весь проект и работу всей команды: за архитектуру, скорость и эффективность кода.

Зарплата. От 250 000 ₽ и выше, верхней границы нет.

Пример вакансии PHP-разработчика уровня senior, от 250 000 ₽ до 700 000 ₽ на хедхантере

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

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

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

Куда может развиваться сеньор

Техлид (Tech Lead), он же CTO — Chief Technical/Technology Officer, или CIO — Chief Information Officer, директор по информационным технологиям. Это человек, который строит архитектуру для всей команды. Это самый сильный разработчик в команде. Выбирает техническое решение задачи: предлагает использовать определенные фреймворки, технологии и библиотеки. Он же проверяет код и решает самые сложные или ответственные технические задачи. Например, принимает решение об автоматизации работы с облачным провайдером и рассчитывает ROI (окупаемость инвестиций) этой автоматизации.

Тимлид (Team Lead) — одновременно опытный программист и хороший менеджер. Связующее звено между командой и менеджером проектов. Тимлид следит, чтобы у каждого сотрудника была задача и он понимал, как ее делать. В половине случаев тимлид занят менеджерской работой: согласует, раздает задачи и права пользователям, следит за загрузкой программистов, распределяет задания.

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

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

Как пройти путь от программиста-одиночки до руководителя отдела IT в 500 человек

Павел Щербинин — технический директор в «Яндекс.Практикуме», руководитель отдела в 500 человек, экс-вице-президент по технологиям в «СберМаркете» в интервью Skypro рассказал о своей карьере в разработке.

Павел, расскажите о своём образовании.

У меня высшее профильное образование. Я учился в Ступинском филиале Московского авиационно-технического института имени Циолковского (МАТИ), на факультете автоматизированных систем управления.

Какой была ваша первая стажировка или работа? Чему она вас научила?

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

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

Что, по вашему мнению, больше всего оказало влияние на вашу карьеру в IT?

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

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

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

Корпоративная IT-иерархия или кто такие Джун, Мидл и Сеньор?

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

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

Грейдинг в IT

Всего в IT выделяют три вида грейда:

1. Junior (джун) – начинающий специалист, решающий простые и зачастую рутинные задачи, под кураторством более опытного специалиста.
2. Middle (мидл) – более смышленый работник, которому доверяют написание кода, но также под наблюдением профессионалов.
3. Senior (сеньор) – настоящий профи, решающий наиболее сложные задачи, и присматривающий за джунами и мидлами.

Это стандартная трактовка каждого уровня грейда. Многие компании используют свои определения и требования к специалистам.

Джун (Junior)

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

Основные профессиональные качества джуна:

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

В среднем требуется 7 месяцев, чтобы Junior стал на уровень выше – Junior+. “+” демонстрирует наличие начального опыта работы и умение самостоятельно решать примитивные задачи.

Мидл (Middle)

Специалист с опытом работы от 2 до 4 лет – мидл. Это твердый “середнячок”, которому доверяют объемные части проекта. Он знает полный масштаб архитектуры и понимает, что делать со своими знаниями.

Основные профессиональные качества джуна:

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

Здесь также возможно повышение: middle+ – специалист, знающий фреймворк, с которым работает, и изучающий дополнительные, а также middle++ – специалист, способный напрямую общаться с заказчиками и самостоятельно вести небольшие проекты.

Сеньор (Senior)

Профессионал с многолетним стажем – сеньор. Он же управляет проектами и ведет целую команду. В послужном списке – прокачанные soft и hard skills.

Основные профессиональные качества сеньора:

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

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

Вывод

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

Больше интересных новостей

Java и MySQL база данных / Разработка приложения на JavaFx

Кто такие хакеры и чем они занимаются?

Изучение Vue JS в одной статье! Разработка приложения на Vue

Java vs Kotlin: кто же круче?

Junior, Middle, Senior, Lead — в чем разница и куда дальше?

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

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

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

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

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

Интерн

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

1. Хороший английский.
2. Понимание выбранного инструмента и умение им пользоваться.

Требование к знанию английского у нас, на самом деле, общее для всех. DataArt — международная организация, большинство заказчиков находятся в США и Западной Европе, и даже внутренние коммуникации уже все больше на английском. Если человек — грамотный технический специалист, мы поможем ему разговориться и подтянуть язык — для этого есть корпоративные курсы и куча дополнительных инициатив. Но если человек без технического опыта (а интерн — как раз такой) еще и слабо знает английский, ему нужно обладать уникальными качествами, которые перекроют оба этих недостатка.

Про инструмент мысль тоже, мне кажется, простая. Если вы приходите на роль программиста, инструмент для вас — язык программирования со средствами разработки, которыми нужно уметь пользоваться. Если потенциальный интерн хочет разрабатывать на .NET, но не может объяснить, что делает CLR, чем «Equals» отличается от «==» или реализовать простейший алгоритм — шансов у него нет никаких. Приходить с нулевыми знаниями и надеяться, что всему научат на месте, параллельно выплачивая зарплату, бесполезно — слишком большой конкурс. За плечами многих кандидатов профессиональные курсы, они с легкостью отвечают на все теоретические вопросы и даже имеют опыт программирования «для себя». Конечно, таких людей берут в первую очередь.

Junior

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

Для джуна важны следующие качества:

1. Желание развиваться и учиться (а на своих ошибках — особенно).
2. Энергия и целеустремленность.
3. Способность спокойно относиться к критике.

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

Middle

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

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

Senior

Синьор — опытный разработчик, повидавший много кода, набивший кучу шишек и сумевший сделать из этого правильные выводы. Основная задача синьора — принимать правильные технологические решения в проекте. «Правильные» — это такие, которые приносят максимальную пользу бизнесу и минимизируют затраты. Хороший синьор не только понимает, что разрабатывает команда, но думает, какие задачи должно решить готовое приложение. Разрабатывая площадку для аукциона, синьор всегда задается вопросом о пиковой нагрузке и старается предусмотреть попытки конкурентной записи в таблицы БД. Он заранее думает об узких местах системы, о возможности ее масштабирования, помнит об уязвимостях и проблемах, вызванных неправильным использованием инструментов.

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

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

• Способность решать несколько более сложные задачи, делать это быстрее или лучше, чем средний разработчик, не имеет практически ничего общего с синьорностью. В нашей классификации человек, который это умеет, называется «Strong Middle».
• Звание синьора невозможно получить быстро. Нужно наработать обширный опыт и понять, что отличает хорошо сделанный продукт от тяп-ляп-разработки, как проявляет себя технический долг, сколько стоит рефакторинг, зачем на самом деле нужны паттерны и так ли необходимы бесконечные уровни абстракции. Необходимо самостоятельно принять важные решения и дать им пройти испытание временем, иначе оценить их не получится.
• Синьору необходимы хорошие коммуникативные навыки, потому что он должен не только предложить правильное решение, но и убедить в своей правоте заказчика и команду. Если вы не смогли отстоять хорошее решение и вместо него было принято плохое, винить в этом придется самого себя. Вариант «я же говорил» на уровне Senior уже не работает. С командой то же самое — мало знать, как надо, нужно еще и уметь это доходчиво объяснить. Тогда команда быстро растет и набирается опыта, избегая болезненных ошибок. Авторитарный подход («делайте, как я сказал») зачастую приводит к внутренним конфликтам, и ситуацию на проекте отнюдь не улучшает — нужно стараться этого избегать.
• Синьор не может обойтись без понимания устройства библиотек и фреймворков. Если инструмент разработки для вас — черный ящик, и вы составляете приложение из готовых частей, не зная, что у каждой из них под капотом, продукт всегда будет неустойчивым и непредсказуемым.

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

Что дальше?

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

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

Куда же развиваться синьорам? Многие программисты любят рассуждать о «потолке» — когда внутренний рейт (т.е. деньги, которые вы получаете за заработу) приближается к внешнему (счету, выставленному клиенту) с минимальной маржинальностью. Они считают, что в этом случае дальнейший рост специалиста становится нецелесообразным для работодателя. Однако это не так, есть множество способов и дальше увеличивать свою ценность. Поэтому позицию Senior Developer стоит рассматривать не как карьерное плато, а как плацдарм для дальнейшего развития, например, в одном из следующих направлений:

Технический эксперт

Статус технического эксперта подразумевает глубокое знание отдельной и специфической области. Например, можно быть экспертом в Azure/AWS и знать разнообразные сервисы, которые предоставляют эти платформы. Уметь делать Machine Learning или Computer Vision, знать все про уязвимости в вебе, понимать, как работают криптовалюты или правильно готовить Sharepoint. Такие задачи встречаются не каждый день, но когда появляются, наступает звездный час технических экспертов. Без них подобные проекты были бы просто невозможны, и компания зачастую готова доплачивать за эти уникальные знания.

Индустриальный эксперт

DataArt старается развиваться в определенных доменных областях (путешествия, финансы, здравоохранение и т. п.). В каждом проекте программисты не только приобретают собственно технические знания, но и получают возможность заглянуть в бизнес заказчика, понять, как устроена индустрия, узнать характерные для нее проблемы и решения. Чего стоит построить свою платежную систему вроде PayPal? Зачем нужна система Sabre? Или что такое HIPAA и какие ограничения она накладывает на разработку решений в области здравоохранения в США? Люди, которые обладают подобными знаниями, зачастую формируют костяк проекта и приносят компании и клиенту огромную дополнительную пользу. Поэтому их компенсация (т. е. деньги, которые они получают за работу) может превышать внешний рейт — компании сами готовы доплачивать таким людям сверх счета, выставленного заказчику проекта.

Фронтмен

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

Тимлид

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

Архитектор

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

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

Дополнительно: работа без посредников

Я хочу отдельно написать о работе без посредников, которую некоторые воспринимают как Святой Грааль для программиста. Казалось бы, все логично: находим заказчика, предоставляем ему свои услуги напрямую, весь рейт забираем себе — профит! Однако нужно понимать, что, кроме прибылей, на программиста в этом случае падают все сопутствующие риски. Нужно внимательно читать пункт контракта об ответственности сторон, знать законодательную и налоговую базу, придумывать механизм получения денег, действовать, если клиент не заплатил или неожиданно свернул работу.

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

По этому поводу можно отдельную статью писать, но не привести мою любимую цитату с «Баша» я просто не могу:

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

На этом мне хочется закончить на сегодня, если есть новые идеи для статей — пишите!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 2

До обраного В обраному 3

Схожі статті

Як IT-спеціалісти першу роботу здобували. Сисадмін на заводі, Junior C++ за $200 і працівник НДІ

Анна Соха 22 червня 2020

Шлях стажера: Microsoft

Oleksandr Sochka 13 червня 2017

Шлях стажера: ELEKS

Ostap Kharysh 21 лютого 2018

Найкращі коментарі пропустити

Ничто не выдавало в авторе «погонщика». кроме последнего абзаца.

Дополнительно: работа без посредников

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

Хорошо, что я его тогда не послушал.

Суспільство без кольорової диференціації штанів не має цілі.

В дополнение к абзацу «Дополнительно: работа без посредников» — bash.im/quote/268537 =)

А вам не кажется, что требование к джуну

способность самостоятельно выполнять технические задачи

немножко перебор. Тем более, что вы нигде не пишете «под контролем старших товарищей».

101 коментар

Serhii Vasylenko Developer Experience Engineer в Grammarly 25.06.2019 17:09

Александр, спасибо за статью! Мне кажется, что она подходит и для градации operation engineers (или как нас еще называют — devops — хотя мы и не методология).

Все это ерунда. Автор выдает желаемое за действительное. По собственному опыту и не только, со всей ответственностью заявляю, что когда контора нанимает сениора, она даже не думает зачем и для чего. Видать для них это круто и модно. Никто его не слушает, ни ПМ ни заказчик. Относятся к нему примерно так же, как и к джуну. Когда ты уже окончательно достаешь руководство со своими предложениями/предостережениями и доказательствами, то в лучшем случае тебе скажут, чтобы ты заткнулся, мол тебя наняли не думать, а код писать. А в худшем случае, тебя уволят на хрен, при чем мгновенно и будут на твое место искать уже мидла, а то и джуна. Пока господа ПМ и всякие там СЕО и СТО не поймут, что вся ответственность по всем вопросам лежит на них, а не на на программистах, то всегда и будут «талантливые менеджеры» чмырить технарей. И эта статье прямое этому подтверждение. Поэтому многие толковые сениоры, которые не хотят идти на конфликт и что-то кому-то доказывать и объяснять, через пару месяцев своей работы на вопрос коллеги, что ты думаешь о нашем проекте, отвечает «мне по..уй!». И это реальность, а не фантазии и теоретические измышления.

Сергій Несходовський Chief Technology Officer в Sweet Stack digital 11.05.2019 12:03

Странная у вас контора, однако.

Совершенно верно описал.
И, причем, так везде и есть в реале.

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

Oleg Kariakin Senior Java Developer 05.02.2018 13:25

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

Хотя по определению все трое являются разработчиками и если в JIRA написана херня, а PO нет, то и толку не будет. Разработчик не бизнес-аналитик и не будет вдумываться в тонкости бизнеса и сферы, он делает то, что написано в задаче.

Ок, допустим senior такой инициативный и будет предлагать свои задачи по масштабируемости/расширяемости и тд. как это затащить в борд? Согласится ли менеджер и PO с этим? В этом случае senior должен доказать целесообразность тех или иных задач и трат. Оно ему надо? Проект не его, прибыли он ему не приносит — нафига создавать себе лишние проблемы. Вдобавок, как правило, существует лобби со стороны заказчика, которые яро сопротивляются любым изменениям. Т.е. хотят ничего не менять, но запилить новые фичи побыстрее.

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

Євген Козлов Front-end developer в SoftServe 05.02.2018 13:42

Оно ему надо? Проект не его, прибыли он ему не приносит — нафига создавать себе лишние проблемы.

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

Oleg Kariakin Senior Java Developer 05.02.2018 14:16

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

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

Поэтому считаю разумным спокойно грести и не выступать.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 23:27

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

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

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:48

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

Как насчёт конторы Интел? Достаточно ли крупный игрок? Мелкософт? Аппле? ХП? Циско? Нокия? Фольксваген? Тойота? Кого-то ещё забыл? Имя им легион все «созданные специально для освоения бюджета отдельно взятого» (к) (тм)

Євген Козлов Front-end developer в SoftServe 06.02.2018 09:29

а шо с ними? ну, кроме теорий заговора, типа «каждая следующая винда требует всё больше ресурсов»(на самом деле нет)?

Іван Довгай PHP Developer 13.02.2018 16:12

Когда то давно читал о том что майкрософт вставляла то ли в винрар то ли в какой то другой архиватор пустые циклы. Зачем — непонятно

Іван Довгай PHP Developer 14.02.2018 09:03

Нет, они потом ещё сами признали что так сделали.

Artem Trofimov Software development engineer в Oracle 05.02.2018 11:01

Спасибо, Александр, за подготовленный материал. Добавлю ссылку на замечательное выступление (2017г.) Рэндала Кутника из нетфликса о пути становления разработчика вообще и значении senior в частности www.youtube.com/watch?v=yIPbE7BssOs

Dima Meshkov Sr Developer в K+K 05.02.2018 10:56

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

Max Shnurenok .NET Architect в LogiqApps AS 05.02.2018 12:17

Почему? Если логика типовая, то действительно должен.

Все галеры бодишопы. Так устроен мир вообще. Купили джуна , а клиенту продают мидла. Все дело в деньгах. Бывало даже такое , если клиент сам хочет протестировать — то кандидата готовят по вопросам, которые клиент может спросить.. Это и не хорошо и не плохо.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 23:05

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

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:53

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

И заработать денег. Даже здесь на ДОУ были статьи из которых написано что на синьорах не зарабатывают.

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

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

Хотя таки да чисто технически проект видимо таки угробят опыт это фактами подтверждает.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 06.02.2018 08:59

Зачем их в таком случае вообще берут?

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

Добавлю — вчорашній джун може стати завтрашнім мідлов, на котрих вже заробляють

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 11:54

а може і не стати (к) (тм)

Lev Pasichnyi Senior DevOps Engineer в Avenga 03.02.2018 22:35

можно закончить owner-ом, сделать компанию и стричь купоны.

Oleksandr Merkulov asterisk guru 03.02.2018 07:29

А вам не кажется, что требование к джуну

способность самостоятельно выполнять технические задачи

немножко перебор. Тем более, что вы нигде не пишете «под контролем старших товарищей».

Александр Липских Oracle Developer в UNITY-BARS 03.02.2018 15:44

немножко перебор.

Чего вдруг?
Вопрос разве что в сложности задач.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 12:48

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

Честно? Ну вот не кажется. У нас джуниоры работают в реальных проектах, вместе со всеми, их работа также оплачивается клиентом. Заказчики и так зачастую пугаются фразы «джуниор разработчик», и убедить их хотя бы попробовать — не так легко. Поэтому джуниор, который хочет чего-то добиться, должен постоянно превосходить ожидания. А в такой формулировке, как вы говорите. Какую пользу проекту может принести разработчик, неспособный самостоятельно выполнить хотя бы простые технические задачи? Зачем он такой нужен?
Понятное дело, задачи у джуна совсем не такие, как у миддла и синьора. Конечно же, его никогда не закинут на проект, где вокруг сплошь незнакомые технологии. Разумеется, всегда есть люди, готовые помочь и подстраховать. Но бесконечно рассчитывать на помощь «старших товарищей» — это очень слабая стратегия. Поэтому лучше я немного завышу планку, чтобы люди, ориентируясь на неё, легче справлялись с реальными задачами, чем создам ложное ощущение, будто к джуну особых требований нет.
Если человек хороший, но немного не дотягивает — у нас есть практикантская программа как раз для этого, где опытный ментор всегда научит и подскажет, но это по нашей классификации — интерн.

Влад Соломенюк Senior UI/UX Designer в EProcurement 06.02.2018 16:24

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

если есть новые идеи для статей — пишите!

Да, есть. Напишите про работу без посредников. А то вы так написали, как-будто надо столько всего знать, особенно какие-то «механизмы», а по факту — сиди и работай.

Pavlo Bida Test Automation Engineer 02.02.2018 23:40

А як же роки досвіду, мінімально необхідні для того чи іншого тайтлу?
Чи то все видумки компаній для стримання надто амбітних хлопців та дівчат?

Eugene Nyukers IT Professional 02.02.2018 18:35

Помогите меня определить в классификацию. Опыт есть, но другой. Английский средний, но не профильный. Кем я могу?

Victor Musienkо Senior Engineer в Noibu.com 02.02.2018 18:35

кем-то другим можете быть

Дмитро Python Tech Lead в Amplio 02.02.2018 18:04

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

Апворк забирает Механизмов для получения денег придумывать не нужно.
Сколько забирает датаарт? 60%?

Victor Musienkо Senior Engineer в Noibu.com 02.02.2018 18:35

а сколько Intellias?

Дмитро Python Tech Lead в Amplio 02.02.2018 18:43

думаю столько же

Дмитрий Мирошник Lead QA Automation Engineer 04.02.2018 04:02

Я думаю, тут немного другой расклад. В случае, если проекту не заплатили денег, вовлечённая в проект команда со стороны галеры получит денег с общего котла галеры. Вот именно с этих 60%, но другого проекта. По крайней мере, так стараются поступать все известные мне более-менее вменяемые крупные галеры.
В случае, если Васе Пупкину, работающему через апворк, не заплатили денег, пойдёт ли апворк забирать деньги у заказчика? Или просто предложит Васе лично разбираться с заказчиком, а в случае успеха отдать положенный % апворку?
Или, к примеру, как поступит апворк в случае claim’а типа «да он мне вообще не тот проект написал!» А исходнички уже, разумеется, у заказчика. Оплатит ли апворк Васе юриста в стране заказчика, чтобы доказать, что проект соответствует техзаданию и имело место нарушение контракта? Или опять-таки предложит бодаться самостоятельно и за свой счёт, а в случае победы перевести % за посредничество?

Slava Ruby on Rails developer 05.02.2018 05:58

Я думаю, тут немного другой расклад. В случае, если проекту не заплатили денег, вовлечённая в проект команда со стороны галеры получит денег с общего котла галеры. Вот именно с этих 60%, но другого проекта. По крайней мере, так стараются поступать все известные мне более-менее вменяемые крупные галеры.

Вы так говорите, как будто это ядерная физика какая-то. Вася Пупкин, точно также как и компания, покрывает риски засчет дополученных 60% с каждого из других нормальных заказчиков. А если работать только с западными клиентами и забыть о рынке СНГ, то таких заказчиков будет 95%, если не больше. В итоге денег Вася заработает намного больше. Так в чем прикол?

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

Євген Козлов Front-end developer в SoftServe 05.02.2018 12:52

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

Oleksandr Merkulov asterisk guru 05.02.2018 18:44

Фриланс не настолько рисковое дело. Если придерживаться неких правил вполне стандартных, то невыплаченные деньги составляют меньше 1%(по моей статистике)

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:57

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

Oleksandr Merkulov asterisk guru 05.02.2018 18:41

Да, апворк заплатит. У меня вот сейчас странный клиент, у него постоянно не проходят платежи(каждую вторую-третью неделю). Апворк — платит, за почасовку. Вне зависимости от того, что они там обсуждают с клиентом насчет оплаты. Просто приходит письмо, что платеж неудался, не работайте временно.Потом письмо, что ваши часы elegible и оплачены апворком, потом приходит письмо о востановлении метода платежа и включении контракта.
Более того, даже если ваши часы совершенная ерунда, если вы соответсвуете формальным правилам — у вас корректное memo и activity, апворк вам заплатит. Другой вопрос, что потом будет в отзыве от клиента. И да, дальше апворк бодается с заказчиком своими юристами.

Апворк может и не самая дешевая биржа(до 20% комисии), но уж hourly protection у них работает. Кроме случая ворованной карты.

Ivan Voloshchuk сплавился по Днепру в Worldwide Downshifter Corp. 05.02.2018 19:12

Апворк может и не самая дешевая биржа(до 20% комисии), но уж hourly protection у них работает. Кроме случая ворованной карты.

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

Oleksandr Merkulov asterisk guru 05.02.2018 19:25

За последние годы мне не выплатили ВСЕГО — прошлый год 0.28% из них по моей вине 0.08%, позапрошлый год — 0.35%, по моей вине — 0. Для сравнения, биржевые проценты 8.5%/5.1%, коммисии вывода в этом году 2%+5%(налог на спрощенной)+курсовая разница порядка процента. Тоесть риски невыплат можно считать нулевыми.

Євген Козлов Front-end developer в SoftServe 05.02.2018 21:11

это первый год? или какой там стаж?

Oleksandr Merkulov asterisk guru 05.02.2018 22:11

15 лет в области, 10+ лет фриланса.

Як гадаєте — коли на Upwork (та йому подібні сайти) варто працювати для Additional income, а коли вже варто міняти фултайм на дистанційну роботу?

Oleksandr Merkulov asterisk guru 05.02.2018 22:13

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

«Коли» — мається на увазі в роках досвіду (приблизно).

Oleksandr Merkulov asterisk guru 06.02.2018 11:47

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

Так і приблизно гадав 🙂

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

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 10:38

Я приведу пример. Допустим, у заказчика на фронтэнде испольуется какой-нибудь очень хитрый фреймворк, вокруг которого все построено. Человек с ним досконально разобрался, и замечательно решает все возникающие вопросы. Будет ли он там синьором? Скорее всего — да. А потом проект закончится, человек уйдет искать работу, и его будут оценивать на джуна, потому что он никогда не работал с реактом или ангуляром, а про тот хитрый фреймворк интервьюеры даже не слышали. Значит ли это на самом деле, что человек — джун? Ответ не так очевиден. С моей точки зрения, это, скорее, вопрос стратегии профессионального развития. Есть какая-то общая база знаний, которая везде используется. Таким знаниям легко найти применение, но очень много заработать на них сложно — собственно потому, что это умеет практически каждый. А есть узкие специальные навыки, которые сильно ценятся на конкретном проекте, но потом им может быть сложно найти применение где-то еще. Нахождение баланса между первым и вторым — задача, к решению которой нужно подходить ответственно и осознанно.
Что до погружение в бизнес-проблемы клиента, то я считаю это совершенно необходимым навыком. Разработчики, которые пишут код ради кода, не видят «большой картинки» и ценят в работе превыше всего изящность программных решений, превращаются со временем в «архитектурных астронавтов» (как их называл Джоэль Спольски). Знания интерфейсов, фреймворков и методов ничего не стоят, если не позволяют вам решать задачи бизнеса быстрее и лучше. Если человек не понимает, чем отличается интерфейс от абстрактного класса — значит его решения, скорее всего, будут слабыми и ненадежными, а, значит, он не решает проблемы бизнеса, а множит их — это никак не синьор.

Олександр Шпак Oarsman в Self Employed 03.02.2018 11:16

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

Реготнув трохи. Розробникам драйверів на Сі розкажіть, що вони не вирішують проблеми бізнесу та не сіньори а так собі. Або тим, хто пише ядра ОС.
Наприклад, я не бачу взагалі різниці між класом, інтерфейсом, абстрактним класом, прототипом. Це лише одні із способів організації різних абстракцій та взаємодії між ними. «Абстрактний клас» можна зробити навіть в не ООП мовах. Наприклад, в CSS можна використовувати аналогічний підхід. А «інтерфейс» то взагалі можна організувати на JSON або XML. Тому що інтерфейс — підхід, а не конкретна реалізація конкретної мови програмування.
А тепер уявіть собі діалог

• В чому різниця між абстрактним класом та інтерфейом?
• Не бачу особливо різниці

• Ви нам не підходите

Max Shnurenok .NET Architect в LogiqApps AS 03.02.2018 11:59

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

Олександр Шпак Oarsman в Self Employed 03.02.2018 12:20

Співбесіда — це місце, де покидьки міряються своїм ПВВ. Задача одних — довести своє звання сіньора, а інших — довести, що сіньори — паперові. 😉

Ievgen Safronenko Senior Software Engineer в zooplus 03.02.2018 13:34

вы как то не правильно написали МПХ

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 12:18

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

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

Если кто-то оплачивает вашу работу — значит, есть план, как на этом заработать (даже если ПО с виду бесплатное). То есть это бизнес, и вы решаете какую-то его проблему 🙂 Чем лучше вы понимаете, какую именно, тем больше у вас возможностей увеличивать свою ценность. Разработка драйверов является неотъемлемой частью вывода устройства на рынок, поэтому каким образом вы пришли к выводу, что она не влияет на бизнес — непонятно.

Олександр Шпак Oarsman в Self Employed 03.02.2018 12:24

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

Ні, це ви спочатку поясність свої слова

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

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

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 13:04

Ну так у нас, вроде как, даже никакого противоречия нет. Я уже выше писал, что

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

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

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

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

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

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

Дмитрий Мирошник Lead QA Automation Engineer 04.02.2018 04:28

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

Не соглашусь. Видите ли, PO не обязательно будет технически подкован и совсем уж необязательно он будет технически подкован в используемых фреймворках. Задача PO — сформировать пул приоретизированных user stories. Таким образом, PO говорит Вам ЧТО делать, но не КАК делать. Ответ на последний вопрос — исключительно в Ваших руках. Пользуясь Вашеми аналогиями, PO — это не штурман, который надиктовывает Вам повороты. Если у Вас есть такой PO — это счастье, поскольку Ваш проект в этом случае могут выполнить несколько джунов и неплохой миддл как тим лид и код ревьювер. Но обычно PO — это скорее человек, который каждый день ездил на работу по марштуту Вашей гонки. эдак лет 10 назад. Надиктовывать Вам повороты он не может, патамуша у него карты нет. Всё, что он может — это сказать «на этой развилке двигаемся прямо, тут дорога лучше. Ну или была когда-то лучше :)». То есть, его роль — скорее навигатор, который может подсказать Вам, где повернуть, чтобы Вы не заблудились в лабиринте бизнес-домена.
Пользуясь приведенным выше примером, PO скажет «нам нужно хранить данные о транзакциях в БД это приоритет № 1», а вот упомянуть, что эта БД должна, к примеру, поддерживать транзакционную модель и в случае неуспешной транзакции иметь возможность роллбэка, чтобы не испортить связность данных — об этом он не скажет, он и слов-то таких не знает. Это должны продумать Вы сами, пользуясь, в том числе, знаниями бизнес-домена, чтобы ответить себе на вопрос «а как повлияет на бизнес неуспешная транзакция? Что им важнее: сохранить хоть какую-то часть этой транзакции или сохранить связность данных, потому что БД нужна, чтобы в будущем иметь возможность получать сводные аналитические отчёты». Если Вы этот вопрос себе задали только тогда, когда PO вам сказал, что отчёты — это приоритет № 1 — Вы в лучшем случае потеряете несколько недель, пытаясь вычистить из разросшейся на несколько сотен гигов продакшен базы несвязные данные, переписывая код на другую модель хранения неуспешных транзакций, чтобы исключить несвязные данные в будущем, перестраивая индексы ну и т.д. В худшем случае — Вы завалите проект, потому что его архитектура попросту не предусматривает тех изменений, которые внезапно потребовались. It’s a scrum, baby 🙂
Поэтому хотя бы базовые знания бизнес-домена для программиста выше миддла — обязательны. Иначе получится набор майоров без маршала: свой участок фронта держим, а что на соседнем — без дупля, поэтому радостно попали в окружение, поскольку майор, отвечающий за соседний участок, абсолютно тактически оправданно приказал оставить данный участок. А тому, со своей колокольни, абсолютно неинтересно, что творится на Вашем участке фронта: зачем это ему, у него свой участок есть.
Узкое тактическое мышление — это прекрасно для миддла. А выше — необходимы хотя бы базовые навыки стратегического мышления. А в лиды без оного лучше вообще не соваться.

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

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

Поэтому хотя бы базовые знания бизнес-домена для программиста выше миддла — обязательны.

За последние пару лет я занимался разработкой интернет-магазина, системой распределения человеческих ресурсов на проектах, приложением для клинических исследований в психиатрии, толковым словарём голландского языка, системой учёта оператора мобильной связи.
Общего между этими бизнес-доменами — ничего.
Вникать в каждый?
Зачем? Каждый из этих проектов уникален, завтра зайдёт приложение для туристических операторов, или приложение для измерения уровня глюкозы в крови. Чем мне поможет знание бизнес-доменов предыдущих проектов?
Проект — это по-хорошему Дальше всё, следующий, от другого заказчика с другой бизнес-логикой.
Будем в этих условиях измерять уровень моей «сеньйорности» глубиной погружения в бизнес-процессы каждого кастомера?
Я ещё понимаю для энтерпрайз решений, которые поддерживаются по 10 лет и там люди годами сидят. И более того, если переходят на другой проект другого заказчика, там всё похожее, т.к. все крупные корпорации внутри похожи.
Но приложение на телефон для покупок алкоголя похоже по своей логике на приложение-словарь не больше, чем рысь на черепаху.