Здравствуйте, 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>Ну вот, например, вполне подходит под "супер" в моем понимании.
Человек просто попал в корпоративную струю. К квалификации никакого отношения. Более того, корреляция обычно обратная. Формальное определение супер-спеца, всё-таки, нетривиальная задача. И в чём-то даже апостериорная. Вот сейчас я точно знаю, что продукт, написанный Васей, был очень качественный и своевременный, а тогда был уверен, что весь отдел фигнёй страдает. А с Петей наоброт — вроде, столько всего нагенерил и согласно лучшим методикам, но поддерживать это гэ оказалось себе дороже.
спасибо за ответ на тупой вопрос 
. А уж когда и как их надо применять — это другой вопрос.
