Комментарии 25

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


Правда сейчас работаю с менеджерами, которые не программисты, и это порой приводит к таким феерическим диалогам… Когда над тобой сидит человек, для которого работа над программным проектом все равно что копание канавы («копай, не отвлекайся!») это подчас сильно демотивирует.

На самом деле кое-что общее всё же есть… Если посмотреть попристальнее, скажем, на стандарты менеджмента — ну, например, на стандарт ISO 9001, то можно увидеть, что там — почти такое же программирование :)


И проектирование общей структуры процессов есть, и кодирование последовательности исполнения процессов — тоже. Только язык программирования — не Java и не C++, а некий DSL на основе "обычного бюрократического" :) А за фазой разработки там следуют фазы деплоймента… и мониторинга… и отладка тоже предусмотрена… :)


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

На самом деле кое-что общее всё же есть…

Абсолютно ничего общего. Люди — это не код.

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

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

А почему "не имеет"?
Есть регламентация, и есть следующая за ней реализация.
Точно так же как есть кодинг, а потом деплоймент… и эксплуатация… :)


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


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


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


Но это же не значит, что общего ничего нет? :)

Когда над тобой сидит человек, для которого работа над программным проектом все равно что копание канавы

Классика же

«копай, не отвлекайся!»


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

Очень знакомо. Любая попытка разговора или обсуждения проблемы (рабочей!) пресекается немедленно. Особенно как-то доставило то, что я всегда приходил на работу до начала рабочего дня, а уходил позже всех на 1-3 часа.


Через год опоздал один раз на работу на 40 минут. Мне устроили такую головомойку, что до сих пор вспоминаю...

> Размышления о карьере разработчика
> Развивайтесь в направлении управленца

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

При следовании советам автора стоит иметь в виду:

1. При переходе в менеджеры количество конкурентов увеличивается.
2. Зарплата, зачастую, уменьшается.
К 40 годам все программисты оставшиеся программистами и не ставшие управленцами понимаюn что программирование это и есть копание канавы.
Что все эти ООП, SQL, UML, Git, и еще миллион терминов это все аналоги того что ты копаешь канаву в песке, суглинке или скале и используешь то ли лопату за 100 руб. то ли за 100$ или рулишь экскаватором.
А в 50 тебе пофиг что можно и в скале копать канаву совочком и не важно что очень медленно, деньги платя за процесс.
К 40 годам все N оставшиеся N и не ставшие M понимают что N это и есть копание канавы.

Я вам пофиксил, не благодарите.
К 40 годам все программисты оставшиеся программистами и не ставшие управленцами понимаюn что программирование это и есть копание канавы.

Хм. 40 лет я уже достиг. Управленцем не стал. Но вот чтобы сравнивать программирование с копанием канавы я до такого пока не дошёл и не уверен что когда-то дойду.


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

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

Есть еще конечно CTO, но там написание кода и вовсе попадает сугубо на задворки.

Если кто-то идёт в разработку, не осознавая этого — ну, сам себе злобный буратино. Таким действительно можно потом советовать «идите в менеджеры» и писать об этом статьи.
1) В менеджеры идти весьма спорно. Ибо ты тогда будешь конкурировать с теми, кто изначально шел из продаж, управления и умеет подвешенный язык и умеет про деньги и профит. И там это гораздо выгоднее, чем техническая грамотность.

2) В Тим-лиды, архитекторы, СТО — как-то более ценно для тебя идет.
<...>карьерный рост в ИТ сегодня
<...> Поговорим о любых руководителях в сфере разработки <...>

Наверное мне одному это мозолит глаза, но:
«ИТ» ≠ «Разаботка» --> «Разработка» ∈ «ИТ»

Где найти на это время? <...>
Кто-то умудряется «халтурить» прямо на рабочем месте в рабочее время, <...> Кто-то делает это поздними вечерами и на выходных, <...> Первый путь может привести к подпорченной репутации, <...> Второй путь чреват истощением организма, <...>

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

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


И огорчаются, что если вдруг какой катаклизм — так разработчику намного проще себе новое применение найти, нежели руководителю...


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

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

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

Прямо вот к 30 годам и почти наверняка? И вот прямо любой? И кем они тогда руководят? Друг-другом?


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

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


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

Согласна про 30 и финансы. В регионах всякие там CFO и другие должности вообще не встретишь почти, почти все штаб квартиры банков находятся в Москве. На удаленке тоже не особо поработаешь. Так к 30 и будешь каким-то небольшим отделом руководить. Ну так и в программировании тим лидом не так сложно стать в текущих agile процессах.

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

Если начать работать, например, в сфере финансов, то в 30 лет вы почти наверняка будете руководителем.

Т.е. если у нас на рынке сейчас есть, условно, 10 тысяч молодых сотрудников в сфере финансов, то через 10 лет у нас будет 10 тысяч руководителей в сфере финансов? Что-то очень сильно сомневаюсь.
Советы ТС (и комментаторов) по литературе для прокачивания «soft skill» (3-5 книг, не более)?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 января 2015

Местоположение

Россия

Численность

31–50 человек

Дата регистрации

20 декабря 2017

Блог на Хабре