Путь падавана

21.03.23

Саморазвитие

Мой взгляд на развитие и точки роста квалификации молодого (начинающего) программиста.

Накануне посмотрел несколько выступлений (докладов) в рамках темы "Путь из джунов в миддлы". Стало сильно жалко молодых людей, которые решили пройти несложный, в общем-то, путь такими витиеватыми вензелями. 

Что я отметил, прослушав эти грустные истории. Вся область знаний и все мерило квалификации слишком сосредоточено на самом программном инструментарии. Я позволю себе усомниться в существовании какого-то уникума, который наизусть выучил весь синтакс-помощник, например. А в этом вообще нужда есть? Глупо представить ситуацию, когда однажды ты будешь знать все - наизусть. По очень простой причине - это "всё" всё время меняется! Вслед за простыми формами пришли управляемые, появились асинхронные методы с их оповещениями, а про оповещения придется однажды забыть, т.к. уже возник механизм ожиданий. Поэтому, когда на собеседованиях начинают "подлавливать" какими-то вопросами, предполагающими знания синтаксиса наизусть, я на таких персонажей с удивлением смотрю - а это надо наизусть помнить?? С полной уверенностью советую молодежи никак не комплексовать по этому поводу, это совершенно не отражает степень вашей квалификации! Освойте представление о самой идеологии платформы 1С, ее основные конструктивные составляющие. А дальше можно просто "шпаргалить". Вам что-то понадобилось от управляемой формы? Посмотрите ее методы в Синтакс-Помощнике, авось натолкнетесь на метод, который как-то решит ваш вопрос. Если что-то будете делать часто - запомните это поневоле. Не запомните - не беда, шпаргалка всегда рядом!

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

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

Констатирую. Решил стать программистом - выбирай специализацию! То есть, определись с отраслью или видом деятельности, в которой ты будешь применять всякие цифровые технологии. И даже не питай иллюзий, что есть такая рафинированная деятельность, как абстрактное программирование чего-то там, о чем-то там. Всегда будешь писать что-то конкретное для вполне реального функционала и будет два устойчивых состояния, ты будешь либо знать - что и как ты делаешь, либо будешь лазить по форумам и надоедать коллегам в поисках каких-то "костылей", которые так же бездумно будешь пытаться вставить в проблемные места своего кода. И на мой взгляд, оценка квалификации программиста, в отрыве от знаний той сферы, для которой он принимается на работу, вообще мало реализуема. Помните такой мем про таксиста - "До вокзала довезешь?" - "А дорогу покажешь?" Вот и в программировании так же - мало "уметь рулить", надо еще и "дорогу знать".

квалификация развитие карьера

См. также

Радио "Аналитик", 17 выпуск 2 сезона. Про модель Кеневин с Андреем Путиным

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    350    0    Radio_Analyst    0    

5

5 идей, как еще аналитик может развивать себя

Личная эффективность Презентации и публичные выступления Бесплатно (free)

В статье рассказывается о 5 способах развития аналитика уровня мидл, мидл + и выше.

18.04.2024    1058    0    TanyaRi    1    

12

Профессиональное мировоззрение учетного специалиста (ч.2). Хозяйственная и бухгалтерская (виртуальная) реальности

Личная эффективность Бесплатно (free)

В этой части статьи предложен вариант профессиональной мировоззренческой модели на основе пары взаимосвязанных реальностей – хозяйственной реальности и бухгалтерской (виртуальной) реальности.

09.04.2024    447    0    Polav62    0    

4

Радио "Аналитик", 16 выпуск 2 сезона. Про метанавыки с Никитой Меньшовым

Личная эффективность Презентации и публичные выступления Бесплатно (free)

В шестнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что такое матанавыки, в чем их ценность, чем они отличаются от soft skills и как их развивать.

01.04.2024    361    0    Radio_Analyst    0    

4

Профессиональное мировоззрение учетного специалиста (ч.1). Наука или не наука?

Личная эффективность Бесплатно (free)

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

01.04.2024    522    0    Polav62    4    

5

Радио "Аналитик", 15 выпуск 2 сезона. "Путь аналитика" с Ильёй Никитиным. Переход от технической поддержки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

18.03.2024    353    0    Radio_Analyst    0    

5

Радио "Аналитик", 14 выпуск 2 сезона. "Путь аналитика" с Натальей Лосевой. Переход от разработки к анализу

Личная эффективность Обучение и наставничество Бесплатно (free)

В серии “Путь аналитика” мы говорим о том, как аналитики приходят в профессию, с какими задачами работают, с какими трудностями сталкиваются и как их преодолевают.

04.03.2024    402    0    Radio_Analyst    0    

5

Измерение и развитие потенциала сотрудников

Обучение и наставничество Бесплатно (free)

Тема измерения и развития потенциала сотрудников является ведущей последние два года в компании Proaction. Елена Дуюн, руководитель направления «Развитие корпоративной культуры», поделится с нами откровением, которое возникло в процессе исследовательского проекта на платформе Proaction. Елена расскажет о текущей кадровой ситуации, о видах потенциала сотрудников, о том, как оценивать этот потенциал и как мотивировать персонал на саморазвитие.

01.03.2024    431    0    DuyunElena    0    

3
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. pro-rok 296 23.03.23 08:35 Сейчас в теме
Статья интересная, хочу добавить от себя. Знать синтаксис на 100% конечно никому не надо.
Но вот вопросы на собеседовании про синтаксис помогают понять на сколько человек плотно работает с тем или иным объектом/разделом. Если ты каждый программируешь на протяжении нескольких лет, то некоторые вещи ты запоминаешь автоматически. А вот когда претендент говорит что у него опыт несколько лет, а простейший вопрос по синтаксису вводит в заблуждение, то тут надо подумать насколько он честен.

Что касается аналитиков и архитекторов, база конечно нужна всем и тут не обсуждается, но если вернуться к Вашей аналогии сантехника, то у него так же есть мастер и бригадир, которые могут подсказать и направить в нужный вектор.
mikadi; _DaFNa_; +2 Ответить
2. DemetrKlim 158 23.03.23 16:43 Сейчас в теме
(1) Мастер, бригадир и т.п. это административные должности. Они никак не дополняют квалификацию самого мастера. Более того Бригадир - то тот же мастер, просто самый лучший, но с тем же набором компетенций, что и подчиненные. В распределении между кодером и аналитиком предполагается изъятие некоторой части компетенций программиста и передаче их на "аутсортинг" другому спецу. Бригадир сантехников всегда заменит любого члена своей бригады, чего не скажешь о кодере и аналитике.
3. pma_2015 130 24.03.23 12:58 Сейчас в теме
Вот эта фраза – как кролик из шляпы: «Не так давно вдруг появились всякие "аналитики" и "архитекторы"». Прямо вдруг? И кто же их «появил»?
Эти роли на проектах создали мы, сами мы. Потому что сложные задачи одной ролью разработчика решаться перестали. А несложные задачи одной ролью решаются сих пор. Главное потом внезапно не осознать, что задача то сложнее, чем казалось. Например, надо было учесть движения по НДС. Поэтому в сложные конфигурации (ERP и производные) одного разработчика пускают редко.
Вообще, с ролями полезно вернуться к истокам – театру, литературе. Обычно автору приходится плодить толпу ролей. С чего бы это? Достаточно же одной, козырной. Нет?
4. DemetrKlim 158 24.03.23 14:09 Сейчас в теме
(3) Боюсь я этих слов "...сложные задачи...". Кто проходит самый сложный путь? Чаще всего это тот, кто изначально не знал дорогу, не так?
Любая сложная задача (даже если она объективно сложная!), состоит из более простых составляющих. Квалификация в том и состоит, чтобы понимать - с какой конструкцией приходится иметь дело, из каких функциональных блоков состоит эта конструкция и в каком из них, потенциально, может существовать проблема.
Истоки очень многих сложностей хорошо описывает принцип, известный как "бритва Оккама". Википедия очень понятно его разъясняет - не буду переписывать. И вот как действие этого принципа проявляется. Сначала мы (программисты!) в угоду своим нахрапистым заказчикам (требования бизнеса же!) насоздавали лишних сущностей, никак не существующих нормативно, не имеющих методологической подпорки и законодательного подкрепления. Один раз "провернувшись" в деловом обороте, эти сущности понятийно и жаргонно закрепились в привычках участников процессов и потребовали своего места в функционалах, расчетах, отчетности и прочем "готовом продукте" информационных систем. А любая сущность, не включенная в конструктивно завершенную методологию, породит - что? Сложности! На обслуживание этой сущности надо создавать кучу дополнительных объектов со взаимоисключающими свойствами и несопоставляющимися итогами и т.д. Сложности начинают самопроизвольно размножаться)
И вот тут возникает вилка. То, что в школьном курсе называлось "интенсивным или экстенсивным путем развития". Надо либо браться за ум и возвращаться к истокам, попутно приговаривая - "да что же мы нагородили??". Путь второй - расширить зону беспредела, включив в нее новых участников, по принципу "все равно уже свалка, так пусть хоть станет интереснее!" Пусть на сцене появятся новые игроки под названием Аналитик и Архитектор! А какое у них будет "творческое амплуа"? Можно прочесть какие-то научные труды на эту тему? А где этот опыт апробирован и с какими результатами? А как с экономикой такой услуги - будет ли смысл во внедрении, стоящем дороже самой валюты баланса предприятия? Сам факт того, что указанные роли возникли "по ходу работы в проекте" уже говорит о скоропалительности и "сырости" такого решения. Я ни разу не театрал, но в самой смелой фантазии не предположу, что режиссер в процессе представления выпустит на сцену персонажей, которые не были ни на одной репетиции, амплуа которых непонятно, а текст роли - экспромтом.
Почему смирились со сложностями? Ни разу не стало интересно - а кто нагородил все так сложно, что в этом стало не разобраться? Может быть, надо устранять сложности, а не придумывать новых персонажей, которые должны эти сложности обслуживать, порождая при этом отражения уже своих сложностей?
Раз уж упомянули НДС. Что же там сложного может возникнуть? Каждый момент времени разработчик должен находиться в контексте налогового законодательства, всего лишь! Буквально так, "в этой процедуре мы находимся в контексте статьи (такой-то НК РФ), а здесь проверяем условия (даты, вид оговора, налоговую политику и т.д.) для перехода в требуемый условиями контекст конкретного пункта статьи НК РФ". Ведь сложности возникают именно в тот момент, когда бизнес (по своей непонятной хотелке!) пытается выдернуть расчеты из контекста нормативной законодательной документации и поместить их в какие-то свои виртуальные миражи, где ему кажется, что он удачнее налог посчитает) И разве тут поможет аналитик? Там, где теряется нормативная и методологическая база, там никакой знахарь не поможет, а там, где проектирование базируется на нормативной методике - там и без аналитика вполне все понятно.
В титрах голливудских боевиков есть такая строчка "постановщик боёв (батальных сцен)". Казалось бы - что за персонаж? Все просто, чтобы на экране получилась красивая зрелищная драка, кто-то заранее должен расписать - кто и в какой момент какой рукой-ногой машет. Тупое добавление в обычную массовую драку нескольких случайных участников делает это неприятное зрелище еще более несуразным. Если на проекте есть сложности, то не персонажей надо добавлять, а сложности профильтровать - ведь очень многие сложности вполне субъективны рукотворны.....
Светлый ум; +1 Ответить
Оставьте свое сообщение