а) супер С++ гуру, щелкающий накидываемые задачи (в англоязычной терминологии "developer")
б) специалист, видящий проблемы и решения по данному проекту, могущий выдать задачи (в англоязычной терминологии "engineer")
...
2) И можно ли составить конкретный план чтоб приблизиться к нему к 31.12.2021?
Хочу понять, что думаете на тему определения супер спеца. Делали ли конкретные шаги, если да, то какие, чтобы им становиться.
Подробней:
Недавно заводил топик про мнение о развитие в руководителя "Жизнь после сеньора".
Спасибо за ответы, поразмышлял.
Также прочитал топик "Советы тех, кому от 40+..."
Сейчас хочу усилить фланг размышлениями о развитие в спеца.
Да, в теме "40+" были советы, что "стало больше, интересней".
Воспринял это как общие выводы.
Моя текущая точка:
30 лет, семья, 5 лет опыта С++.
Достаточно ли мне работать с интересом, как советовали в той же теме, и автоматом это будет приводить к наращиванию скилла?
Или нужно задаваться какими то ориентирами и шагами.
Работа интересная.
Есть направления по текущему С++17 проекту: 1) Поддержка, развитие функционала
2) Общение со смежными сервисами — уточнения по проекту, вопросы смежным сервисам
3) Общение с аналитиком — какие приходят запросы от смежных сервисов для наращивания нашего функционала и пойдем ли навстречу, как это трансформирует нашу архитектуру, не нарушиться ли идеология сервиса
4) Возможное усиление джуном — онбординг, рассказ про проект
5) Расширением кругозора — вообще зачем нужен сервис в рамках большого видения взаимодействия с другими
6) Совершенствование мониторинга — на пути к использованию ELK + graphana для отображение метрик сервиса. Плюс, выявление новых метрик для внедрения.
Как видите, какую-то часть рабочего времени приходится "не работать инструментом", а "проводить в коммуникации". Это нормально?
К примеру, недавно вообще 1 работал. На мне была и разработка в "пожарном режиме" и общение с другими и попытка выставление приоритетов...
Сейчас ввожу в курс дела пришедшего аналитика, который быстро включается и берет на себя коммуникацию. Считаю, что этим вкладом в него вкладываюсь и в себя.
Что будет меньше общения со смежными сервисами. Что аналитик будет проксировать и выдавать мне выжимку, приоритезируя запросы, смотря и выстраивая планирование активностей по нашему сервису.
Чтобы у меня пропадал "пожарный режим" в том числе.
A>1) Кто такой супер сеньор?
Синьор — это господин, обращение к человеку, которого вы уважаете, человеку образованному или при чинах.
На следующем собрании вырази глубину своего уважения к своему начальству: супер-господин Иванов высказал очень интересную мысль..., Или: извините супер-госпожа Петрова, почему задерживается зарплата?
Здравствуйте, namespace, Вы писали:
A>>1) Кто такой супер сеньор? N>Синьор — это господин, обращение к человеку, которого вы уважаете, человеку образованному или при чинах.
Вот сеньор
N>На следующем собрании вырази глубину своего уважения к своему начальству: супер-господин Иванов высказал очень интересную мысль..., Или: извините супер-госпожа Петрова, почему задерживается зарплата?
А можно как в Литве (ну вроде бы так): понас Ивано ввысказал очень интересную мысль... Или: извините супер-панеле (или супер-пониа) Петрова, почему задерживается зарплата?
Здравствуйте, avovana, Вы писали:
A>Хочу понять, что думаете на тему определения супер-спеца. Делали ли конкретные шаги, если да, то какие, чтобы им становиться.
Я не хочу быть никаким супер-спецом. Хочу быть обычным, средним человеком.
И прожить обычную человеческую жизнь с семьей, детьми, друзьями.
Зачем ты хочешь стать этим самым супер-спецом, чего тебе не хватает-то?
Здравствуйте, avovana, Вы писали: A>1) Кто такой супер сеньор?
Гугл утверждает, что это либо:
собачий корм
либо
вот такой занятный перец
A>2) И можно ли составить конкретный план чтоб приблизиться к нему к 31.12.2021?
Ну я даже не знаю... собачий корм из людей, это уже фашистами какими-то попахивает, так что я предположу, что ты хочешь стать таким занятным перцем в шляпе. Мне кажется, это не сложно и тебе всего-то надо а) найти и купить такую прикольную шляпу, б) найти приличного парикмахера, который поможет отрастить столь зачетные усы.
Здравствуйте, kaa.python, Вы писали:
KP>Удачи с превращением в супер-сеньора в 2021 году!
Хорошо, переформулирую так:
Какие действия нужно делать, чтобы становиться более лучшим тех специалистом от года к году?
Достаточно на работе с интересом решать задачи и читать статьи, книги?
Входит ли в вотчину тех специалиста общение, если да, то в какой пропорции от основного времени?
Здравствуйте, bnk, Вы писали:
bnk>Зачем ты хочешь стать этим самым супер-спецом, чего тебе не хватает-то?
Похоже, заголовок оказался слишком броским)
Если проще:
Как улучшаться в своей профессии?
Нормально работать?
Читать статьи на so.
Читать блоги по С++.
Читать книги про С++.
И этого достаточно для углубления?
Но вот не знал бы ELK, не думал бы, что можно классно логи собирать, метрики и отображать.
То есть, одних плюсов может и не хватить для построения надежной системы/продукта?
Приводил ссылки на курсы по архитектуре, которые на днях нашел.
Стоит ли в таком плане улучшаться, исходя из собственного опыта, наблюдений?
KP>Удачи с превращением в супер-сеньора в 2021 году!
Порадовал позитивный настрой в ответе)
Задам вопрос так:
Вы берёте на работу коллегу С++ сника. Какой профиль кандидата видите? Какой образ человека с какими чертами рисуете себе? С каким бы коллегой сработались?
Насколько, по вашему, важен энтузиазм.
Было бы достаточно, чтобы кандидат сказал, что он делал то-то на работе. Или хотели бы услышать, что для души пилил то-то и то-то?
Как у Вас шло развитие? Просто работа? work-life баланс? И Вам было норм? И в работе успевали, и с семьей? И не чувствовали, что нужно еще практику, теорию добирать?
Здравствуйте, avovana, Вы писали:
A>Хочу понять, что думаете на тему определения супер спеца.
Все из списка. Плюс:
Уметь объяснять принимаемые решения
Знать границы применяемых технологий (плюс границы своих знаний и практики)
Уметь двигаться вперед в условиях недостаточной/противоречивой информации (т.е. делать что-то полезное и не ждать, пока вам аналитик принесет все ответы)
Уметь объяснять бизнесу свою пользу
Уметь объяснять, чем вы полезны команде! Это немаловажный момент. Особенно с учетом того, что с ростом должности увеличивается количество общения
Желательно уметь устанавливать культуру команды. Т.е. принципы, на основе которых принимаются решения. Негласные правила общения. И т.п.
Уметь анализировать свои предыдущиие решения. При необходимости — определять причины и делать выводы на будущее
Уметь выражать грамотно и понятно свои мысли. Писать и поддерживать необходимую документацию (вряд ли у вас хватит времени объяснять одно и то же каждому разработчику при быстром росте проекта).
Процессы (формальные) тоже желательно уметь выстраивать. Знать, какие проблемы решает Agile. Иметь представление о RUP и проблемах, которые пытались решить им
Уметь управлять качеством (что, зачем, почему, как)
Уметь учить других. Не просто "читать лекции", а именно учить! Вставать на сторону ученика. Искать причины непонимания. Находить более индивидуальные примеры, объяснения. Давать упражнения на выработку стабильного автоматического навыка.
А в целом все просто — полностью отвечать за техническую сторону проекта (или вашей его части) и его работоспособность. Плюс не вызывать ненависти у тех, с кем вы работаете (команда и смежники).
A>Достаточно ли мне работать с интересом, как советовали в той же теме, и автоматом это будет приводить к наращиванию скилла?
На данном этапе — этого достаточно. У вас вполне разнообразные обязанности.
A>Как видите, какую-то часть рабочего времени приходится "не работать инструментом", а "проводить в коммуникации". Это нормально?
Это нормально. Рабочие инструменты меняются. Становится больше почты, диаграм и документов. Чем круче титул, тем меньше работы непосредственно с кодом. У вас value не в том, что вы делаете непосредственно руками. А в том, что ваша команда (вся команда, можно еще смежные должности и группы включать) работает лучше, чем без вас.
A>Или работы не хватит? Нужны курсы, доп. проекты?
Зависит от работы. Пока — хватит. Если будете окукливаться — можно что-нибудь другое попробовать. Желательно знать всякие "удобные" инструменты (bash/zsh/whatever, python, etc...). Чтобы не все решать на C++.
A>По курсам. Сегодня такие нашел:
Если интересно — слушайте. Не интересно — не слушайте. Слушать интересные курсы вседа полезно. Главное относится к ним критично. Т.е. делать что-то только потому, что так сказали на курсах — это плохо. Делать это потому, что вы считаете что-то правильным (и у вас есть объяснения, почему вы так считаете) — хорошо. Что-то из сказанного на курсах будет совпадать с вашим мнением, что-то отличаться. Что-то будет пододом для различных экспериментов и ограничений. В конце концов у всех вырабатывается свой стиль.
Здравствуйте, avovana, Вы писали:
A>Здравствуйте, bnk, Вы писали:
bnk>>Зачем ты хочешь стать этим самым супер-спецом, чего тебе не хватает-то?
A>Похоже, заголовок оказался слишком броским)
Поскольку ты привел ссылки на некоторые топики тут, потому и спросил. А ты вроде как, так и не ответил, зачем ты хочешь стать супер-спецом?
То есть, ну вот предположим, стал ты этим супер-спецом, и что? Что дальше-то?
Здравствуйте, bnk, Вы писали:
bnk>То есть, ну вот предположим, стал ты этим супер-спецом, и что? Что дальше-то?
Есть экспертиза.
Нравится работать.
Всегда востребован и высокооплачиваем.
Обеспечиваю семью со своей стороны.
Делаю сложные проекты.
Или вопрос — что после этого?
А, по вашему, что после этого?
Или, с точки зрения своей реализации специалистом, этого и хватит до конца дней?
Здравствуйте, Sharov, Вы писали:
A>>По отусу я прошел. Было не просто, сделал половину. Но реально улучшил скилл. S>Вот этот -- https://otus.ru/lessons/arhitektor-po/ , за 70т рублей? Деньги не жалко?
Откуда в Рунете такие цены неадекватные?! Да и содержание...
Здравствуйте, avovana, Вы писали:
A>Вы берёте на работу коллегу С++ сника. Какой профиль кандидата видите?
Нормальное знание C++ плюс *NIX ну и предметная область, если она критична. В том же Касперском предметной области мы не ожидали при найме, т.к. если просить такой опыт, то искать можно вечно.
A>Какой образ человека с какими чертами рисуете себе? С каким бы коллегой сработались?
а) не мудак (ничего общего с модным надрочем на токсичность не имеет).
б) может работать самостоятельно не прося подтверждения каждому шагу.
A>Насколько, по вашему, важен энтузиазм.
Важен для чего?
A>Было бы достаточно, чтобы кандидат сказал, что он делал то-то на работе. Или хотели бы услышать, что для души пилил то-то и то-то?
Если есть проекты это всегда плюс. Я, обычно, смотрю открытые репы, если они есть.
A>Как у Вас шло развитие?
странно, мне всегда очень сильно везло
A>Просто работа?
Не, я довольно много времени на АйТи трачу за пределами работы. Это одно из хобби.
A>work-life баланс?
Да вроде в норме всё.
A>И Вам было норм?
Да мне почти всегда норм, я вообще от процесса жизни удовольствие получаю.
A>И в работе успевали, и с семьей?
Само собой. Главное что бы дома было всё хорошо, тогда и с работой будет хорошо.
A> И не чувствовали, что нужно еще практику, теорию добирать?
Постоянно добираю. Книги, какие-то проекты на коленке.
Но я вот что не пойму, а что ты хочешь получить на выходе? Зачем становиться "супер сеньором"? В чем цель? Я имею ввиду что-то типа "я хочу бабла", "я хочу запускать корабли на Марс", "я хочу проектировать сложные системы" ну и т.д.
Спасибо за такой развернутый ответ, рассуждение!
Очень полезно для меня в данный момент времени, осознания что и как делать.
Вы писали: A>>Как видите, какую-то часть рабочего времени приходится "не работать инструментом", а "проводить в коммуникации". Это нормально? M>Это нормально. Рабочие инструменты меняются. Становится больше почты, диаграм и документов. Чем круче титул, тем меньше работы непосредственно с кодом. У вас value не в том, что вы делаете непосредственно руками. А в том, что ваша команда (вся команда, можно еще смежные должности и группы включать) работает лучше, чем без вас.
Это напоминает размышления о тим-лиде.
А сейчас посмотрел видео о solution architector. На него тоже.
Так ли это?
Почему это меня беспокоит. Сейчас такое впечатление, что если ты тех. специалист, то, как писали в топике "40+" не проблема найти работу(как я понял).
Но если ты вырос в такого эксперта/тим лида/solution architector именно в данной предметной области компании, то ты пророс в неё и такая описанная экспертиза именно в ней и на ней завязан дальнейший рост или просто пребывание: Пояснительный пример
То есть, я воспринял это описание как описание уже какой-то руководящей должности. Уже не тех. специалиста, который пишет код.
Или нет? Или это описание — логичный рост тех специалиста? И совершенствование себя как тех специалиста — это именно миграция в это верхнеуровневое управление, представление, понимание текущего проекта. И в этом случае ты востребован на рынке, также, как и специалист, постоянно пишущий код? И, тогда, обратное — постоянно пишущий код специалист — специалист еще не высокого уровня?
Нет. По С++.
Тогда он был для специалистов с опытом, желающих улучшить, систематизировать знания.
В этом была фишка отуса.
Сейчас уже есть 0+. То ли отдельным курсом. То ли расширили тот.
Здравствуйте, kaa.python,
Спасибо за ответы. Очень интересно.
Вы писали:
KP>Но я вот что не пойму, а что ты хочешь получить на выходе? Зачем становиться "супер сеньором"? В чем цель? Я имею ввиду что-то типа "я хочу бабла", "я хочу запускать корабли на Марс", "я хочу проектировать сложные системы" ну и т.д.
Вкратце, ответил bnk на аналогичный вопрос.
Плюс, наверное, хочу получать удовольствие от работы. Собственно, как и получаю сейчас.
Вот только пока не понял, на вашем уровне это, в основном, программирование, или уже руководящая работа?
KP>В том же Касперском предметной области мы не ожидали при найме, т.к. если просить такой опыт, то искать можно вечно.
Когда устраивался в Сбер было также. И проект вроде С++. Но, как оказалось, знание предметной финансовой области волей-неволей приходится наращивать в связи с очередными use case'ами.
A>>Насколько, по вашему, важен энтузиазм. KP>Важен для чего?
Для работы. Для развития.
A>>Как у Вас шло развитие? KP>странно, мне всегда очень сильно везло
Что это значит? Постоянно были интересные проекты? Коллеги?
Насколько считаете важным повстречать любящих свою профессию людей? Может, попадались такие? От которых бы передавался энтузиазм и воодушевление от процесса разработки.
Был ли ментор?
KP>Откуда в Рунете такие цены неадекватные?! Да и содержание...
О чем и речь! Я реально офигиваю от этих цен. Можно взять их программу и искать англоязычные лекции на ютубе, например.
Либо читать в блоге. Неужели обратная связь с ментором, а по сути платят именно за нее, столько стоит?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, kaa.python, Вы писали:
KP>>Откуда в Рунете такие цены неадекватные?! Да и содержание...
S>О чем и речь! Я реально офигиваю от этих цен. Можно взять их программу и искать англоязычные лекции на ютубе, например. S>Либо читать в блоге. Неужели обратная связь с ментором, а по сути платят именно за нее, столько стоит?
Это хороший вопрос. По курсу С++ заметил такие сильные стороны:
1) Начитка материала онлайн от эксперта с возможностью задавать вопросы в моменте. На нашем потоке был Дмитрий Шебордаев. Насколько помню, в то время возглавлявший команду поиска Рамблера.
2) Домашка, решая которую углубляешься в очередной раздел С++.
3) Обратная связь по очередной итерации решения с подсвечиванием того, что было сделано хорошо, что можно улучшить, что требовалось в задание. У нас был Василий Зазнобин. Архитектор из Сбербанка.
4) Практика ревью уже сданных задач других студентов.
5) Созданный в слаке чат для текущей набранной группы с возможностью спрашивать, общаться по домашкам и в целом. Это оказалось очень ценно.
6) Периодичность занятий, задающая ритм из которого лучше не выбиваться, чтобы не отстать от поезда.
Для меня было ценно. Именно в тот момент времени, с тем моим желанием, с теми преподавателями, с той программой курса.
А про курс архитектора. Какая там практика? Делать какие-то докер образы, микросервисы? Уже не сильно мотивирует туда заливать много своего времени. Проще, как говорилось, посмотреть видео.
Тем более, лично мне курс показался разрозненным и больше про какие то широкоиспользуемые ИТ мейнстримы. Но чтобы вот так взять и связать с плюсами — не очень понятно как.
То есть, теряется связь:
теория + закрепление на практики.
Здравствуйте, avovana, Вы писали:
S>>О чем и речь! Я реально офигиваю от этих цен. Можно взять их программу и искать англоязычные лекции на ютубе, например. S>>Либо читать в блоге. Неужели обратная связь с ментором, а по сути платят именно за нее, столько стоит?
A>Это хороший вопрос. По курсу С++ заметил такие сильные стороны: A>1) Начитка материала онлайн от эксперта с возможностью задавать вопросы в моменте. На нашем потоке был Дмитрий Шебордаев. Насколько помню, в то время возглавлявший команду поиска Рамблера. A>2) Домашка, решая которую углубляешься в очередной раздел С++. A>3) Обратная связь по очередной итерации решения с подсвечиванием того, что было сделано хорошо, что можно улучшить, что требовалось в задание. У нас был Василий Зазнобин. Архитектор из Сбербанка. A>4) Практика ревью уже сданных задач других студентов. A>5) Созданный в слаке чат для текущей набранной группы с возможностью спрашивать, общаться по домашкам и в целом. Это оказалось очень ценно. A>6) Периодичность занятий, задающая ритм из которого лучше не выбиваться, чтобы не отстать от поезда.
В принципе, неплохо. И сколько это все стоило, сколку длился курс?
A>Для меня было ценно. Именно в тот момент времени, с тем моим желанием, с теми преподавателями, с той программой курса.
A>А про курс архитектора. Какая там практика? Делать какие-то докер образы, микросервисы? Уже не сильно мотивирует туда заливать много своего времени. Проще, как говорилось, посмотреть видео. A>Тем более, лично мне курс показался разрозненным и больше про какие то широкоиспользуемые ИТ мейнстримы. Но чтобы вот так взять и связать с плюсами — не очень понятно как. A>То есть, теряется связь: A>теория + закрепление на практики.
А понятно, хотите развиваться по линии эксперта в ++, что-то вроде technical fellow в ms или гуглах.
Потому что архитектура это не про ++, это обозревать проблему под разными углами, коммуникации с другими и т.п. вещи.
Выбор соотв. стека, выбор бд , монолит vs микросервисы и т.п. Плюсы тут очень сильно с боку. Тут скорее
понимание проблем бизнеса\заказчика, технологий и компетенции соотв. исполнителей (команды) для решения задач.
Здравствуйте, avovana, Вы писали:
bnk>>То есть, ну вот предположим, стал ты этим супер-спецом, и что? Что дальше-то?
A>Всегда востребован и высокооплачиваем. A>Обеспечиваю семью со своей стороны. A>Делаю сложные проекты.
Понятно спасибо за ответ на тупой вопрос
Я наверное в целом спрашивал, не про твой конкретный случай, думал вдруг найду какую мотивацию, сорри.
К сожалению мне это похоже не так интересно. Денег вроде понятно что хватит, бомжевать не буду (ну а если буду, то по собственному желанию).
Сложные проекты все равно не потяну, поскольку талантов особых нет, да и не особо интересно уже, ибо рутина в основном.
Здравствуйте, Sharov, Вы писали:
S>О чем и речь! Я реально офигиваю от этих цен. Можно взять их программу и искать англоязычные лекции на ютубе, например. S>Либо читать в блоге. Неужели обратная связь с ментором, а по сути платят именно за нее, столько стоит?
Моя теория — столько платят за плохой уровень английского и/или отсутствие навыка самообразования.
Здравствуйте, avovana, Вы писали:
A>Плюс, наверное, хочу получать удовольствие от работы. Собственно, как и получаю сейчас.
Ну тогда у тебя уже всё есть. Делай так же и дальше будет всё хорошо
A>Вот только пока не понял, на вашем уровне это, в основном, программирование, или уже руководящая работа?
Мне думается, "уже" к руководящей работе не применимо. Я строго против позиций выше тимлида/техлида, т.к. там крайне много затрат нервов при совсем незначительном увеличении ЗП. Так же становится сильно сложнее ездить между странами, управленцев и своих хватает везде. Так что я вполне себе иду по техническому направлению развития и этому очень рад.
A>>>Как у Вас шло развитие? KP>>странно, мне всегда очень сильно везло A>Что это значит? Постоянно были интересные проекты? Коллеги?
Последние 10 лет мне удавалось довольно случайным образом попадать в очень классные компании мирового класса.
A>Насколько считаете важным повстречать любящих свою профессию людей? Может, попадались такие? От которых бы передавался энтузиазм и воодушевление от процесса разработки.
Важно встречать полезных людей.
A>Был ли ментор?
Нет, считаю что он вообще бесполезен. Я сам умею учиться.
Здравствуйте, bnk, Вы писали:
bnk>Сложные проекты все равно не потяну, поскольку талантов особых нет, да и не особо интересно уже, ибо рутина в основном.
Тут вспомнил вакансию в штаты в одной из тем. Как писал автор:
Выпускников IT специальностей забирают всякие Blizzard и т.д. и платят 120 k$ со старта.
То есть ребята уже с 23 лет уже в топовой компании.
Даже так — уже с 18 получают высшее IT образование.
Даже так — уже со школы интересуются этой темой. Участвуют в олимпиадах и т.п.
(можно такой же российский пример привести).
То есть, по сравнению с таким образом IT спеца с детства, я со своим опытом явно бы проигрывал.
Здесь должно помочь осознание, что таким ТОПом не стану, а лучше буду сравнивать себя с собой.
Здравствуйте, avovana, Вы писали:
bnk>>Сложные проекты все равно не потяну, поскольку талантов особых нет, да и не особо интересно уже, ибо рутина в основном.
A>Тут вспомнил вакансию в штаты в одной из тем. Как писал автор: A>Выпускникам IT специальностей уже платят 120$ и забирают всякие Blizzard и т.д.
A>То есть ребята уже с 23 лет уже в топовой компании. A>Даже так — уже с 18 получают высшее IT образование. A>Даже так — уже со школы интересуются этой темой. Участвуют в олимпиадах и т.п.
A>То есть, по сравнению с таким образом IT спеца с детства, я со своим опытом явно бы проигрывал. A>Здесь должно помочь осознание, что таким ТОПом не стану, а лучше буду сравнивать себя с собой.
Если бы мне вернуться на 25 лет назад, я бы наверное вообще в IT не пошел. Благо были и выигранные олимпиады (правда не по программированию) и вообще отличником был
Вместо этого, постарался бы поступить в магистратуру или аспирантуру где-нибудь в Швейцарии или Германии например, желательно по профилю связанному с биотехнологиями.
Теперь знаю, что это было вполне себе осуществимо. У меня даже знакомый был, который бросил IT в универе и примерно так и сделал.
Так что не очень разделяю твой энтузиазм, тебе только 30, какой смысл самому закапываться в IT?
Сейчас воспринимаю программирование скорее как ремесло. 120$ это вроде не заоблачные деньги, так-то это 50 евро в час. Лыжный инструктор берет больше.
И хотя безусловно, какой-то интерес к работе у меня есть, понимаю, что он есть и в выпиливании лобзиком гномиков из фанеры.
К сожалению, в отличие от тех, кого от написания кода прёт, я это делаю скорее потому,
что из того, что я делать умею, за программирование платят больше.
Здравствуйте, avovana, Вы писали:
A>Похоже, заголовок оказался слишком броским) A>Если проще: A>Как улучшаться в своей профессии? A>Нормально работать? A>Читать статьи на so. A>Читать блоги по С++. A>Читать книги про С++. A>И этого достаточно для углубления?
Нет. Еще хорошие компании и коллеги. Возможно, стоит поставить на первое место.
A>То есть, одних плюсов может и не хватить для построения надежной системы/продукта?
Точно не хватит. Любой более-менее сложный продукт — это результат работы многих людей. Поэтому чем сложнее проект, тем важнее менеджерский вклад.
A>Приводил ссылки на курсы по архитектуре, которые на днях нашел. A>Стоит ли в таком плане улучшаться, исходя из собственного опыта, наблюдений?
Стоит, если хватает времени и сил, но это необязательно самое эффективное вложение.
Здравствуйте, avovana, Вы писали:
A>Это напоминает размышления о тим-лиде. A>А сейчас посмотрел видео о solution architector. На него тоже. A>Так ли это?
Да, это так. Просто писать код могут очень многие, а вот грамотно объяснять — уже меньше. Более того, даже для рядовых разработчиков растет количество общения. Связано это с тем, что сложность разрабатываемых проектов сейчас уже превосходит возможности одного человека. Во времена Форда (лет 100 назад, на заре индустриализации) еще было разделение, когда инженеры могли разработать процесс производства и отдать менеджерам для его непрекословного выполнения. Но ко многим современным активностями (не ограничено программированием, применимо, например, к медицине) это уже не подходит. Слишком много информации, слишком много меняющихся факторов. Поэтому обратная связь и идеи от рядовых исполнителей важны.
A>Почему это меня беспокоит. Сейчас такое впечатление, что если ты тех. специалист, то, как писали в топике "40+" не проблема найти работу(как я понял).
Тему не читал. Но мне кажется, вы немного неправильно интерпретируете. Работу не проблема найти, если вы готовы работать руками. Это происходит, когда вы довели типичные операции до автоматизма. Т.е. у вас нет проблемы что-то закодировать после того, как вы поняли требования. Вот этот навык — это то, что подразумевается под "тех. специалист". Если вы любите свою профессию и не пытаетесь избежать личной работы, такой навык очень сложно утратить. Он может стать менее актуальным с современными инструментами, но общие принципы мало меняются. Плюс по работе в команде вам все равно придется знакомиться с современными аналогами. Проблемы появляются, если вы руками работать не любите и хотите руководить. Я таких встречал. На вопрос "а можете написать ..." (что-то совершенно простое и рутинное) отвечают, что "я таким не занимаюсь и не помню". Вот в этом случае работу будет найти сложно.
Собственно, "наличие вашего value для команды" — это как раз один из важнейших способов избежать потери навыков. Все, что вы говорите и предлагаете, должно быть релеватно задачам, потребностям и квалификации рядовых исполнителей. А для этого нужно очень хорошо понимать конкретно их ситуацию (навыки, задачи, ограничения и т.п.).
A>Но если ты вырос в такого эксперта/тим лида/solution architector именно в данной предметной области компании, то ты пророс в неё и такая описанная экспертиза именно в ней и на ней завязан дальнейший рост или просто пребывание: A>Пояснительный пример
Не надо слишком сильно фокусироваться на "предметной области компании". Где то я видел утверждение, что "каждая компания считает себя уникальной, но на самом деле она практически всегда совершенно стандартная". Вот так и подходите к этому. Есть стандартные задачи, которые решают архитекторы (высокоуровневые требования и ограничения, общая возможность реализации, поддержание общей структуры, чтобы в ней можно было разобраться, компромисс между всеми stakeholders и еще много чего). Какие при этом документы и активности предписывает отдельная компания — это ее личные трудности. Т.е. есть "проблемы и пути решения" (они переносятся). И есть конкретные ритуалы, которые до какой-то степени тоже выучить придется. Но не стоит придавать им слишком много значения.
А пример у вас отличный. Он как раз иллюстрирует мое утверждение, что "нужно быть готовым работать руками". В видео человек ушел с руководящей должности в аналитики. Ну и что он говорит? "Я пришел и 99.9% я знал, как делать". Это вот те навыки, которые сложно забыть.
A>То есть, я воспринял это описание как описание уже какой-то руководящей должности. Уже не тех. специалиста, который пишет код.
Я про должности вообще не говорил, я говорил про требуемые навыки . А уж когда и как их надо применять — это другой вопрос.
A>Или нет? Или это описание — логичный рост тех специалиста? И совершенствование себя как тех специалиста — это именно миграция в это верхнеуровневое управление, представление, понимание текущего проекта. И в этом случае ты востребован на рынке, также, как и специалист, постоянно пишущий код? И, тогда, обратное — постоянно пишущий код специалист — специалист еще не высокого уровня?
Это вполне логичный рост. Еще раз обращу внимание, что я не писал должностные обязанности. Я на самом деле описал аспекты типичного проекта. Их могут делать разные люди. И, например, в сильной команде (полностью из суперсеньеров) эти обязанности могут быть распределены между членами команды. Им не нужен тимлид или менеджер. У них сложилось так, что роли распределены на основе их склонностей (кому-то интересно с заказчиком больше говорить, кому-то — настраивать автомтатизацию тестов и развертывания). Отсюда и критерий "крутости" как возможности брать ответственность за любые аспекты. Например, у нас все (без исключений!) члены команды должны уметь делать типичные операции (разработка, тестирование) не хуже, чем принято культурой разработки. Первый этап — недоступность одного из разработчиков не приводит к остановке (или вообще к серьезным проблемам). Т.е. есть частичное перекрытие навыков. Второй этап — каждый "супер сеньер" может в одиночку выдавать результат, который соответствует минимальным критериям качества (полное перекрытие необходимых навыков). Это очевидно будет медленне и хуже максимально возможного качества команды. Вот второе достигнуть — гораздо сложнее, да и не всегда нужно. Зато такой специалист сможет быть прекрасным дополнением к любой команде. Он/она готов/готова писать код и может закрыть еще какой-нибудь аспект (а то и несколько), которого не хватает вашей новой команде. Или может хватает, но им никто не хочет заниматься (люди разные все). Из вашего списка это "представление, понимание текущего проекта" с разных сторон. "Верхнеуровневое управление" — слишком широкий термин. Он включают еще всякую бюрократию конкретной организации (которой не обязательно заниматься). А без бюрократии "управление" ничем сильно не отличается от "лидерства" — умения объяснять, почему нужно делать что-то конкретным способом.
Важно уметь писать код, который решает реальные проблемы. Всегда нужны люди, которые не просто будут выполнять задачи, а готовы изучать текущий проект. Нельзя помнить все. Поэтому хорошо, когда кто-то в команде может спросить "а ты точно это имел в виду? Фигня какая-то ведь получается!". А уж сколько он кода пишет — это вторично. Может, кому-то повезло с командой и можно все время уделять любимому делу. А может быть, с командой не повезло и пришлось в одиночку закрывать все остутствующие навыки. При переходе от лида/архитектора важно только, как человек относится к уменьшению автономии. Если нормально — никаких проблем нет.
Самый правильный рост из программиста (человека, пишущего код) в разработчика (человека, делающего программные продукты). В какой конкретно роли/ролях — зависит от того, с кем приходится работать. Не надо определять себя как "человека, которому дали конкретные ручки порулить" (это некоторые team lead, которые сами себя позиционируют как "говорил другим, что они должны делать"). Роль разработчика как раз подразумевает, что вы понимаете, что делаете на каждом шаге, а не просто следуете тому, что вам кто-то сказал.
Интересно, спасибо.
Правильно понимаю, что такая метаморфоза "программиста -> разработчика" возможна лишь в определенных условиях?
То есть, тот же agile как раз и нацелен на то, чтобы дать программисту свободу с ответственностью? С которыми и можно понимать проект, общаться с другими. А не зажиматься в рамках "дали задачу, её сделал и хватит с меня".
KP>>Но я вот что не пойму, а что ты хочешь получить на выходе? Зачем становиться "супер сеньором"?
G>Рискну предположить — обеспечить себе job & income security.
Думаю, да. Мне кажется, что у всех это цель. Осознанная или неосознанная.
По крайне мере, это очень логично — работать и понимать, что, в том числе, нарабатываешь себе job & income security.
Здравствуйте, kaa.python, Вы писали:
G>>Рискну предположить — обеспечить себе job & income security.
KP>Для этого не надо быть супер, достаточно быть просто средним и всё это будет. Поэтому цель "супер" и не понятна.
"Супер", скорее, как противовес "плыву по течению".
Если "средний" как раз и есть — работаю и интересуюсь, выделяю баланс жизни и работы, тогда — да, быть таким средним.
Тогда определение "суперности" остаётся пустым.
Можете привести определение? Что это такое? Можете ли сказать, что встречали таких? Если да, какое впечатление осталось?
Как писали, что "суперность" можно понять "если мечтаешь поучаствовать в космической программе...". Но в ней и такой "средний" может.
Тогда "супер" оставить для Линуса Торвальдса и Страуструпа?
И выходит тогда такая градация профессионализма:
Здравствуйте, avovana, Вы писали:
A>Здравствуйте, maxkar, Вы писали:
A>Интересно, спасибо. A>Правильно понимаю, что такая метаморфоза "программиста -> разработчика" возможна лишь в определенных условиях?
Да, это в первую очередь зависит от непосредственного начальника и команды. Они должны позволять контроллировать (в рамках вашей задачи хотя бы) различные аспекты. Без экспериментов, собственных наблюдений и выводов здесь никуда.
Еще должен предупредить, что "меньше знаешь — крепче спишь" прекрасно применимо к трансформации и вообще к желанию быть "супер". Потому что когда много знаешь, видно очень много проблем в компании. Например, я практически никогда не собеседуюсь в команды со Scrum (потому что считаю, что во многих случаях есть альтернативы лучше и выбор необоснован). И много другого. А так как на бумаге вы — технический специалист, изменить что-то получается сложнее, чем менеджерам, имеющим формальную власть.
A>То есть, тот же agile как раз и нацелен на то, чтобы дать программисту свободу с ответственностью? С которыми и можно понимать проект, общаться с другими. А не зажиматься в рамках "дали задачу, её сделал и хватит с меня".
Нет, agile совсем не на это нацелен. Как минимум, изначальный. Вообще он как раз требует в качестве начального условия команду "супер сеньеров" и является скорее методологией управления требованиями а не полноценной методологии разработки.
Agile решает две вполне конкретные проблемы типичных (на то время) заказчиков и проектов. Первая — контракт на 3 года на разработку какой-то системы для бизнеса. Уже за первый год ситуация на рынках меняется и какие-то из начальных требований становятся неактуальными а появляются новые. А за три года заказчик вообще может бизнес сменить. Вторая — это когда заказчика слушают слишком много. И вот он смотрит на раннюю версию и просит: "Давайте кнопочку передвинем? А теперь синей сделаем. Не... Не подходит синей, красной нужно! И круглой! Ой, уже неделя прошла, а где все то, что вы мне обещали за нее сделать?" Это feature creep (или разрастание одной небольшой change до целого проекта), когда время уходит с важных задач. И вот agile решает именно эти проблемы путем выбора фиксированных приоритетов на определенное время. Плюс вменяемый размер итерации, за который требования не успеют устареть (а если вдруг и успеют, не слишком много усилий потрачено). Что и как делают программисты в это время — за пределами методологии. Может, половина команды вообще напрямую над user stories не работает, не важно.
Общение со всей командой там же растет из-за де-факто специализации разработчиков на отдельных областях. Один лучше знает базы данных, другой — UI. И в процессе обсуждения задачи больше шансов, что подводные грабли будут сразу обнаружены и ликвидированы. Т.е. UI-специалист может пропустить что-то специфичное для БД и наоборот. Применимо даже к супер-специалистам, они все равно фокусируются только на части аспектов.
Если вы еще вспомните, что методология предлагалась контракторами/консультантами, то вообще все станет на свои места. Это способ взять себе нужную свободу и заставить заказчика (который совсем не эксперт в программировании) думать о проекте а не о том, что сегодня разработчики что-то выглядят расслабленными. Как видите, инициатива и цели применения очень важны в данном случае. Типичный корпоративный agile используется для того, чтобы отобрать свободу у программистов и переложить на них всю ответственность. Битва за процессы — это весело!
С другой стороны, это не отменяет того факта, что agile не мешает совершенствоваться. Т.е. можно использовать неизбежное и задавать вопросы бизнесу, другим разработчикам и вообще кто есть вокруг. Можно также попробовать брать задачи на интересную тематику (тесты, мониторинг, что угодно) и быть первопроходцем (плюс получать простор для экспериментов). Да и в рамках рутины в типичной реализации вам все равно придется поработать на разных фронтах (код, автоматическое тестирование, деплой/релиз). Так что тоже практика.
При этом ничего плохого в более длительном планировании и non-agile тоже нет. Даже в рамках большого проекта есть маленькие относительно независимые части. Т.е. какой-нибудь модуль, который разрабатывается относительно отдельно. У него после первого релиза могут быть (и будут) доработки, но времени будет нужно меньше. В этих рамках появляется возможность экспериментов. Немного меняется круг общения (соседние команды, архитектор, представители заказчика в отдельных областях).
Здравствуйте, avovana, Вы писали:
A>"Супер", скорее, как противовес "плыву по течению". A>Если "средний" как раз и есть — работаю и интересуюсь, выделяю баланс жизни и работы, тогда — да, быть таким средним.
Ну вот ты уже и есть, цель достигнута, осталось слегка барахтаться и быть на поверхности и, собственно, всё.
A>Тогда определение "суперности" остаётся пустым. A>Можете привести определение? Что это такое?
Ну вот, например, вполне подходит под "супер" в моем понимании. Можешь поискать тут посты Anatolix, Cyberax, jazzer, kochetkov.vladimir, мыщхъ, remark (упорядочено по алфавиту), они вполне себе тянут на "суперность", больше в голову никто не пришел из "простых смертных", т.е. не считая товарищей уровня Страуструп
A>Можете ли сказать, что встречали таких? Если да, какое впечатление осталось?
Угу, с тремя знаком лично, очень хорошее впечатление.
Здравствуйте, kaa.python, Вы писали:
A>>Тогда определение "суперности" остаётся пустым. A>>Можете привести определение? Что это такое?
KP>Ну вот, например, вполне подходит под "супер" в моем понимании. Можешь поискать тут посты Anatolix, Cyberax, jazzer, kochetkov.vladimir, мыщхъ, remark (упорядочено по алфавиту), они вполне себе тянут на "суперность", больше в голову никто не пришел из "простых смертных", т.е. не считая товарищей уровня Страуструп
Здравствуйте, kaa.python, Вы писали:
KP>Ну вот, например, вполне подходит под "супер" в моем понимании.
Человек просто попал в корпоративную струю. К квалификации никакого отношения. Более того, корреляция обычно обратная. Формальное определение супер-спеца, всё-таки, нетривиальная задача. И в чём-то даже апостериорная. Вот сейчас я точно знаю, что продукт, написанный Васей, был очень качественный и своевременный, а тогда был уверен, что весь отдел фигнёй страдает. А с Петей наоброт — вроде, столько всего нагенерил и согласно лучшим методикам, но поддерживать это гэ оказалось себе дороже.
спасибо за ответ на тупой вопрос 
. А уж когда и как их надо применять — это другой вопрос.
