Из общения с опытными специалистами в области разработки ПО видно, что всё чаще предметом особой гордости является возможность заявить об узкой специализации. Т. е. назваться просто «software developer» или «QA engineer» считается не так престижно как «server-side java developer» или «standalone application QA automation engineer». Более того, и при обсуждении возможных сценариев профессионального развития часто приходится слышать опасение стать олицетворением английской поговорки «Jack of all trades, master of none» (или по-русски, «кто за всё берется, тому ничего не удается»). Приводятся доводы в стиле: вот продолжу заниматься «.net-разработкой» и на рынке труда буду оценен как .net-специалист с пятью годами опыта, а перейду на ruby и буду снова несколько лет «числиться» новичком.

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

Действительно, опасение стать jack of all trades можно понять. Но никто не призывает быть master of none. Я призываю, достигнув мастерства в узкой профессиональной области (и это, конечно, обязательный этап для любого специалиста) не останавливаться на достигнутом. Освоил нюансы server-side java разработки? Молодец! Попробуй, научиться чему-то ещё, чего раньше делать не доводилось (например, из за разделения труда с коллегами по проекту). Не стоит «копить» годы «специализированного опыта», очень часто три года опыта на поверку оказываются одним годом, но три раза.

Более того, я не только призываю не замыкаться на конкретных языках программирования или парадигмах (попробуйте неимперативные языки, это бодрит!), я предлагаю программистам, контролерам качества, бизнес-аналитикам, инженерам поддержки, техническим писателям, проектным менеджерам не гнушаться понять, в чем состоит труд коллег, вместе с которыми мы делаем наше общее дело: создаем программное обеспечение [для цифровых электронных вычислительных машин]. У каждого из нас были причины выбрать ту или иную специальность. Как правило, это связано с личной эффективностью в той или иной сфере деятельности. И я ни в коем случае не призываю отказываться от этой специализации. Я всецело разделяю максиму: заниматься нужно тем, что получается лучше, чем у других. Но содержательное понимание собственных ограничений и возможностей и сопоставление их с ограничениями и возможностями коллег не только позволит создать и укрепить атмосферу взаимоуважения при совместной работе (а это, буквально, жизненно важно), это позволить нам, как команде, перейти на качественно новый уровень возможностей по созданию ПО. Мы сможем делать более масштабные, востребованные и более качественные программы, используя для этого меньше усилий и средств.

Надеюсь, немногие, дочитавшие до этого места, поняли, к чему относился призыв «понимать» из названия статьи. Верно, я призываю стараться понять все аспекты создания ПО, не останавливаясь лишь на тех, что касаются непосредственных обязанностей. На определенные сложности, ожидающие тех, кто решиться последовать призыву, намекает вторая часть названия. Это, к слову, название известной статьи Питера Норвига, которую я рекомендую к прочтению.

Сложность состоит в том, что на то чтобы понять, как создается ПО, уйдет много лет. Прочитать Сode complete, SICP, BABoK и PMBook можно за несколько месяцев. Но на то чтобы действительно их понять, уйдут годы, а возможно и десятки лет. Сейчас нет абсолютно никаких ограничений по доступу к информации и знаниям. Курсы ведущих вузов доступны для всех желающих. С проверкой теории на практике могут быть сложности при работе в небольших коллективах над длительными специфическими проектами. Но работа в крупной компании предоставляет практически неограниченные возможности по практическому ознакомлению с любым аспектом производства ПО. По сути, единственным условием является наличие желания. Желания учится. Желания понимать.

Но самое коварное препятствие поджидает нас в начале пути профессионального роста. Нередко приходится сталкиваться со специалистами, попавшими в ловушку иллюзии всезнания. В некоторых подразделениях нашей компании обсуждалась даже (скорее в шутку) возможность введения в качестве необходимого условия для присвоения сотрудникам высокой инженерной квалификации (SD+) отсутствие требования по присвоению этой квалификации со стороны самого сотрудника. Обсуждалось в шутку, но статистика на текущий момент 100-процентная: каждый раз, когда сотрудник сам интересовался «а не пора ли уже», оказывалось, что пока ещё рановато, и наоборот во всех тех случаях, когда «было уже пора», сам сотрудник скорее сомневался в том, что он уже достоин. Эффект Даннинга — Крюгера в действии.

Бороться с этим препятствием относительно несложно, нужно лишь помнить, что если вы не готовы вслед за Сократом повторять «я знаю лишь, что я ничего не знаю», то это всегда означает, что уровня Сократа вы пока не достигли, и никогда не является признаком того, что вы Сократа превзошли.

Кстати, по результатам опроса на programmers.stackexchange.com на тему «что должен уметь каждый разработчик» наибольшее количество баллов набрал ответ: «смирить гордыню и признать ошибки, не принимая их лично».

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

Автор статьи — технический директор компании Itransition.