Рубрика «разработчик»

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

Нужно ли планировать этапы работ, делать приоритизацию, тестировать фичи? Безусловно да. Должны ли эти этапы быть обязательными в SDLC? На мой взгляд, нет.

Фича, которая занимает квартал и вовлекает 5-6 человек в одной компании, может быть сделана за две недели одним разработчиком в другой.Читать полностью »

Каждый из нас хотя бы раз задумывался, почему после рабочего дня спина ноет, глаза красные, а мысли путаются. Я решил покопаться глубже в тему эргономики рабочего места разработчика — от кресла и монитора до света, клавиатуры и даже крошечных скриптов, которые помогают отслеживать «здоровье» сидячего образа жизни. Это не будет сухой теорией: я покажу исследования, реальные советы и даже куски кода, которые можно прикрутить к своему workflow.

Читать полностью »

IT-менторы говорят своим ученикам подделывать документы: Паспорта РФ, выписки об опыте работы с госуслуг СТД-Р, договоры ГПХ и так далее (пруфы и скрины в статье!). И я не говорю про накрутку опыта, которая уже стала базой в IT-сфере.

Каждый 3-й кандидат крутит опыт, пишет кучу бесполезных ключевых слов в резюме, чтобы попасть в топ поисковой выдачи в hh.ru, либо быть первым в списке откликнувшихся, но далеко не каждый подделывает документы, что в некоторых ситуациях является УГОЛОВНО наказуемым!

Во что превратилось менторство?

Менторство очень сильно эволюционировалоЧитать полностью »

Изображение сгенерировано при помощи ИИ Midjourney

Изображение сгенерировано при помощи ИИ Midjourney

Читать полностью »

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

Что делать, если в трудовой пусто? Вы работали на фрилансе, были оформлены по ИП/ГПХ, получали серую/черную зарплату или даже принимали платежи в криптовалюте (разумеется, до запрещающего это закона). Опыт  —  есть, компетенции тоже, но суровый найм требует корочку, поэтому от очередной вакансии приходится отказаться… Или нет?


Читать полностью »

Я стал аналитиком, потому что не смог быть программистом - 1

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

Читать полностью »

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

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

Зачем они соглашаются? Во-первых, потому что они росли всегда и останавливаться страшно. Во-вторых — это часто единственная возможность повышения.

Что мы поменяли у себя в разработке Газпромбанка:

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

Куда можно расти? В хеда профессии — эксперта, к которому может обратиться каждый в компании. Это как Стив Возняк в Apple.

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

Наш опыт, как не надо растить тимлидов (не делайте как мы) - 1

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

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

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

Где именно лежит граница между зарплатными грейдами: как это устроено у нас - 1

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

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

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

Я - Дмитрий Симонов, основатель Техдирского Клуба, опубликовавшего и поддерживающего оригинальный список проблем, связанных с политизированным Open Source.

На текущий момент в списке:

  • 36 записей опасных изменений в OpenSource

  • 10 записей о заблокированном доступе

Дисклеймер:

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

  • Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js