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

21.03.23

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

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

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

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

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

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

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

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

См. также

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

Опыт компании DNS показывает, что вместо стандартных практик набора лучше взять людей с непрофильных специальностей, не знакомых с программированием, и выучить их за 3 месяца самостоятельно. О том, как решить проблему дефицита кадров и выстроить процесс роста от джуна до сеньора внутри компании, пойдет речь в статье.

12.11.2024    515    0    AlexSvoykin    9    

3

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

«Я знаю одно – во мне есть нечто, и я это скрываю. Я не говорю об этом. Но оно там всегда. Мой Темный попутчик. Когда он просыпается, я чувствую себя живым.» (сериал «Декстер»). «Жажда разработки» – это психологические проявление внутреннего «я», вызывающее острую необходимость программировать. Все, кто любит программировать, неоднократно испытывали такую жажду, и я не исключение. Расскажем о том, как утолить свою жажду и найти баланс между хобби, работой и другими аспектами жизни.

07.11.2024    2748    0    BlizD    70    

41

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

Когда начинающий разработчик приходит в новую для себя сферу 1С, ему нужно пройти множество этапов, прежде чем стать специалистом приемлемого рабочего уровня middle. Расскажем о том, какие способы помогут разработчику быстрее научиться эффективно решать задачи.

09.10.2024    2261    0    Akcium    1    

5

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

В этом выпуске мы поговорили с ведущими подкаста "Аналитики у микрофона" Татьяной Рыловниковой и Анной Войкиной про цели и ценности создания, прослушивания и участия в подкастах.

09.09.2024    374    0    Radio_Analyst    1    

2

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

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

23.08.2024    1020    0    user1947860    3    

5

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

Я Егор, 1С-разработчик, который уже год работает дистанционно. В конце рабочего дня часто чувствовал себя выжатым лимоном, поэтому нашёл принципы сохранения ресурсности — делюсь рецептом.

20.08.2024    4346    0    PROSTO-1C    14    

23

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

Последние полгода систематизировала для себя тему онбординга и решила поделиться тем, к чему пришла на данный момент. Буду рада дополнениям в комментариях, так как тема крайне широкая. Часть наблюдений про организацию онбординга со стороны работодателя раскрою в отдельной статье. А в этой статье рассмотрим онбординг глазами приходящего в компанию сотрудника.

23.07.2024    1818    0    SerjoginaMaria    6    

13

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

Обсуждая пост одной "Охотницы" в телеграмме, зашла речь о доверии. А ведь важная штука! Рассмотрим, что это такое, надо ли давать его в кредит и если давать, то сколько вешать в граммах!?

08.07.2024    3963    0    biimmap    117    

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

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