Чем хороший специалист в разработке ПО отличается от плохого, что для него свойственно? Ответ во многом зависит от этапа его развития: для начинающих важны одни вещи, по мере получения опыта — совсем другие. Я попробовал собрать в одном материале свои соображения о разных этапах становления специалиста. Давайте выясним аспекты, формирующие человека, про которого потом можно уверенно сказать — вот «хороший специалист». Осторожно, под катом много картинок для лучшего ассоциативного запоминания.

Меня зовут Никита Данилов, начинал как WPF .NET-программист, а сейчас заядлый .NET бэкенд-программист. Прошел аспирантуру, преподавание в учебном центре и университете, что вызвало у меня определенную профессиональную деформацию.

В 2021 году мне посчастливилось выступить на DotNext 2021 Moscow с докладом Good Software Engineer — кто это?, а теперь хочу сделать это на Хабре текстом. 

Оглавление

• Терминология

• Junior

• Senior

• Principal

• Заключение

Вступление

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

Терминология

Кто-то может считать это всё пустой демагогией, тем не менее, именно с развитием терминологии я связываю зрелость отрасли. Кем вы себя считаете, на том и будете фокусироваться. Есть ведь «кодер», есть «программист», «разработчик», и есть «инженер» — слова то разные.

Любопытно, есть ли тот, кто считает, что это синонимы? К моей радости, шутки про «тыжпрограммист» стали менее распространёнными. Люди вне IT-сферы постепенно поняли — мы подчас занимаемся совершенно разными вещами. Давайте тогда и мы сейчас разберём эти термины.

Кодер — специалист, специализирующийся на кодировании, написании исходного кода по спецификациям.

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

var code = Coding(Specs); // TODO: Implement AI for that.

Прежде чем сесть писать код, необходимо продумать архитектуру системы, всех движущихся частей. После написания кода, потребуется доставка, поддержка и развитие вашего решения. Т.е. если вы лишь кодер и умеете лишь преобразовывать слова в код, то, скорее всего, вы не сможете предоставить крупное решение целиком, а ваша ценность (в большинстве случаев) примерно на уровне транспилятора, на мой взгляд. Безусловно, есть области где требуется сложная алгоритмика, да и ресурсы вроде Leetcode стали популярны, но по моим сугубо субъективным оценкам — рано или поздно к вашим навыкам обязательно прибавится умение смотреть на проблему в целом.

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

Насколько я могу судить, всё-таки больше прижился термин «программист» (programmer). Это человек, создающий различное программное обеспечение, что подразумевает явно больше действий, чем превращение спецификации в код. Довольно широко употребляется также термин «разработчик» (developer), но разрабатывать можно много чего: планы, программное обеспечение, золотые рудники, а потому, без приписки «ПО» этот термин не самостоятелен, это скорее уточнение деятельности. Зато здесь возможно уточнение квалификации, например, «инженер-программист».

Сам термин «программное обеспечение» (software) вошёл в обиход с 1960-х годов, когда появилось разделение команд на пишущих программную часть и собирающих железную.

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

Инженер (лат. ingenium — способности, изобретательность), разрабатывает новые и/или оптимизирует существующие решения, опираясь на фундаментальные и прикладные науки.

Наконец, «инженер». Данный термин обладает более богатой историей и определяет того, кто изобретает новое или улучшает существующее решения некой проблемы.

Инженеры, как правило, вовлечены во все процессы жизненного цикла решения, включая исследования, планирование, проектирование, разработку, документацию, производство, наладку, испытание, эксплуатацию, обслуживание, управление качеством и т. д.

Опираясь на фундаментальные и прикладные науки, инженер находит и реализует решение проблемы.

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

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

С другой стороны, вокруг не вакуум, вокруг нас существует мир. Он состоит из самых разных людей. Мы используем библиотеки и ТЗ, написанные другими. Рефакторим код, написанный кем-то другим. Вокруг нас всегда есть другие люди, живые, с которыми полезно общаться. Есть и результаты их деятельности — код, ТЗ, дизайн, отчеты о багах. Создать значимый продукт без этого мне уже не видится возможным. Обратите внимание на то, сколько новых профессий появилось в ИТ-проектах всего лишь за последние 10 лет.

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

Junior

С чего начинается развитие человека вообще?

Насколько мне известно, после стадии минимального «приспособления» (адаптации), которое стимулирует развитие, дальше требуется «любопытство»: «А что если сделать вот так?»

Чем подкрепляется любопытство?

Экспериментом и результатами. Это заложено в нашем организме, мы приспосабливаемся к миру, и наш мозг поощряет нас за получение жизненно важной информации (или хотя бы кажущейся таковой).

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

Любопытство порождает задачу. Задача требует эксперимента для решения, когда вы применяете свои навыки и оцениваете результат. Крайне редко всё удаётся с первого раза. Можно вспомнить любой возраст. Постройка домика из кубиков в детстве, катание на велосипеде в юности, первый деплой на production. Если говорить про действительно новое, то это подразумевает отсутствие наработанных навыков.

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

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

Каков худший результат ошибки джуниора?

Не скомпилируется. Или возникнет runtime-исключение. Или среда разработки зависнет (или будет удалена production-БД, но вы же соблюдаете технику безопасности?)

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

Что отличает программиста от других профессий — это способ решения задачи. Скорее всего, задачу мы будем решать именно путем создания некой программы. Внезапно, ни курсы, ни книги, ни тренеры не сделают из тебя программиста. Они могут значительно помочь, дать знания, но только решение задач при помощи программ делает из тебя программиста. Даже если код взят со StackOverflow, Sql.ru, или любого иного места, не суть важно. На самом первом этапе мы именно учимся решать задачи при помощи кода, узнавая попутно новое.

Коллеги

Здесь я хочу выделить важный момент про коллег. Давайте вспомним свои студенческие годы. Тонны информации вливались нам в голову. Мы делали невероятные задания за один вечер.

Как и почему нам это удавалось?

Кроме того, что в принципе мы были совсем молодые, ещё я помню, как мы много общались, обменивались, списывали, переписывали.

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

Поэтому важно общаться с единомышленниками (что мы и делаем в этом докладе/посте). Это позволяет узнавать новое быстрее, решать проблему лучше. Общаться при этом ответственно. Если кому-то пообещать, а потом не сделать – вы рискуете заработать сомнительную репутацию. Потом так же поступят с вами. На этом этапе мы учимся ответственно говорить «да», брать ответственность за наши предложения и решения.

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

Хотелось бы упомянуть два эксперимента:

• William G. Chase and Herbert A. Simon — Perception in chess (полный текст)

• Ben Shneiderman — Exploratory Experiments in Programmer Behavior (полный текст)

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

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

То есть это всё про общие практики (best practices). Если код написан единообразно, логичен для всех в команде, то работать с таким кодом значительно легче всем. Если же код совершенно незнаком и не удаётся найти общую идею, то мозгу приходится запоминать его просто как набор символов, что заведомо труднее.

Книги

Про нашу профессию написано немало книг. «Чистый код» и «Чистая архитектура» Роберта Мартина, «Рефакторинг» Мартина Фаулера, конечно же «Паттерны проектирования» GoF и классическое «Искусство программирования» Дональда Кнута. Это всё хорошие книги, полезные, и вроде даже про лучшие практики, но мистер Дрейк как бы намекает.

Прежде всего я бы предложил сфокусироваться на двух других книгах, которые и про код, и про людей, и про профессию: 

• «Совершенный код» Стива Макконнелла.

• «Идеальный программист» Роберта Мартина.

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

• Полезнее научиться вдумчивому подходу к работе, нежели просто заучивать конкретные техники и алгоритмы.

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

• И полезно понимать, что вокруг тебя тоже живые люди.

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

Ваш главный инструмент

Постепенно, по завершению первого этапа развития, мы понимаем в чём сила — в нашем интеллекте (читай, в мозге). 

Ваш строительный материал это интеллект, а главный инструмент — ваш мозг.

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

Таким образом, в начале нашего пути мы учимся развиваться, как в избитой фразе про университеты: учимся учиться. Кроме того, учимся общаться с коллективом, находиться в коллективе. Постепенно осознаём возможности нашего интеллекта. Между прочим, именно на этом этапе зачастую можно поймать эффект Даннинга-Крюгера, но не страшно, бывает (в разумных пределах конечно, кто из вас обещался разработать новую систему формирования расписания ВУЗа с нуля за 3 месяца?). Так проходят первые годы сначала джуниора, а затем и миддла.

Senior

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

Как мы себе представляем сеньора? 

Это довольно широкое понятие, но здесь есть некоторые ключевые моменты:

• Естественно, он должен поставлять качественные решения в обговорённый срок. 

• Он следует процессу разработки и понимает, кто все эти люди вокруг.

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

Можно сказать, джуниор и миддл работают именно с задачами и больше на этапе реализации. В свою очередь, сеньор работает с пользовательскими историями, начиная с предварительных этапов.

С какой же проблемой сталкиваются практически все на этом этапе? Тут у меня накопилось очень много наблюдений как из своего опыта, так и из опыта знакомых.

Вы начинаете уметь больше, следовательно, вы начинаете делать больше. Где-то еще на стадии миддла вы вдруг начинаете вписываться во всё, до чего можете дотянуться. Либо просто наслаждаетесь тем, как здорово вам удаётся работать, вас слышат, вы творите добро. Внезапно вы осознаёте, что пашете круглые сутки. Чем больше вы бежите, тем больше требуется бежать. Как хомячок в колесе. Это рождает спутанные мысли, недоумение: чем быстрее я бегу, тем быстрее нужно бежать. Распространённая проблема. Я сам периодически попадаю в такую ситуацию (к счастью, с каждым годом всё реже).

Как считаете, почему этот хомячок постоянно занят?

Негативное проявление лени

Казалось бы, парадокс, но мы бежим, потому что ленимся. Наша леность коварна и проявляется по-разному. Бывает — негативно, например, когда сначала делаем, а только потом думаем, что может проявляться как:

• Инверсия приоритетов.

• Немедленное выполнение.

Начнем с неявного — хомячок ленится подумать. Как и мы, вместо того, чтобы подумать — надо ли срочно это делать, бросаемся делать. Не пытаемся понять приоритеты, а просто — вот что понятнее, то и делаем. Если выяснится, что сделать мы это можем только за месяц, а у нас есть неделя, то надо ли нам вообще это делать? Необходимо подумать и ответить всем вместе (помним ведь, что вокруг команда и прочие живые люди?), но хоть кто-нибудь должен задуматься первым.

Нашлась ошибка, надо исправить. Лень думать — подставим костыль побыстрее. 

Вот так мы и подставляем себя, и всю команду.

Вытекающее из этого проявление лени — когда мы НЕ делаем чего-то, а проявляться это может как:

• Отсрочка выполнения.

• Уклонение от работы.

Представьте, вот мы сильно загружены уже и просто тихо сливаем какие-то задачи, пока никто не видит. Тем самым, подставляя всех:

• Заказчика, кто страдает без функционала.

• Тимлида и менеджера, они закладывают оценки, им потом головой отвечать.

• Себя и команду.

Всё, что мы отложим, потом может выстрелить. Как? За день до релиза мы выясним, что половина задач на самом деле не доведена до ума. И что делать?

Позитивное проявление лени

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

Книга в меру подробно агрегирует известные факты об устройстве человека, плюс даёт полезные практики. Я же обращу внимание на ключевые моменты, которые вы можете почерпнуть вкратце из доклада «Принципы экономии мыслетоплива».

Качественный переход в сеньора и выше происходит с пониманием, что существуют позитивные проявления лени, когда вы сначала думаете (то есть анализируете и планируете, понимаете приоритеты), прежде чем действовать. 

Кроме того, моя рекомендация — научиться твёрдо говорить «нет». Если вы профессионал, то это ваша обязанность. Когда руководитель ставит нереальные сроки, вам лучше сказать «нет». Когда вам предлагают быстрое кривое решение, вам полезнее объяснить, к чему это приведет и, вероятно, сказать «нет». В таком случае, вам наверняка придётся научиться предлагать альтернативы. Когда вам предлагают постоянно работать по ночам, ваша обязанность — сказать «нет». Потому что вы знаете, как это потом вернётся. Проблема переработок давно известна, упоминается во многих книгах, например, одна из любимых — это «Человеческий фактор и управление программными проектами» Тома Демарко и Тимоти Листер (спасибо @pinckrow) Разных докладов тоже не счесть, как с психологической точки зрения, так и с нейробиологической.

Подытожим позитивные проявления лени:

• Думаем -> Делаем;

• Умение говорить «нет»;

• Автоматизация рутины;

• Написание сразу чистого кода/решения.

Иными словами, будьте настолько ленивыми, чтобы работать в меру, избегать человеческого фактора и сразу писать код без багов, а вопросы решать без проблем. Делов-то, да?

Кругозор

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

Найдя первое подходящее решение, наш разум стремится и дальше использовать его для экономии ресурсов (мозг вообще любит оптимизировать). Например, если говорить про жизнь, как успевать делать задачи вовремя? Простое решение — пойти списать откуда-нибудь. Отлично, работает!

Если говорить про код, то вот вам ваш первый наставник говорит, семь бед — одна абстрактная фабрика, и вы начинаете пихать её везде. Однако как ни странно, у многих разум всё же предпочитает иметь хоть какой-то выбор.

Ловушка захлопывается, когда вы находите второе решение. В дополнение к списыванию вы обнаруживаете, что если работать по ночам, то почему-то можно много успеть. Всё, дальше разуму достаточно вариантов. Вы либо ищете, где дёрнуть код, либо пашете. Здесь начинается борьба с разумом за поиски новых решений вместо использования старых. Только вот решений и критериев на самом деле зачастую больше двух. 

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

Каждое из решений подходит для своей ситуации, имеет свои компромиссы, тема в принципе избитая в статьях. Можно подумать, что в нашей индустрии тупик — это отсутствие решения. Часто тупик — это когда вы принимаете решение, а оно оказывается не очень хорошим, и чем дальше вы углубляетесь, тем хуже. Повторюсь, тупик возникает из-за лености вашего разума, когда вам кажется, что иных решений искать не надо. Лично мне известно два способа помочь разуму найти другие решения.

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

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

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

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

Отчасти наш мозг так устроен, что рассказ материала позволяет железно закрепить его. К тому же при подготовке материала вы неизбежно столкнётесь с чем-то новым. Кто-то таким образом закрывает своего рода долг перед обществом. Если ваш учитель/преподаватель/наставник/тимлид когда-то дал вам импульс к развитию, то здоровым желанием потом станет передать этот импульс дальше.

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

Очень спорно, если вы потратили на это 4 недели, а задача нужна была неделю назад.

Таким образом. На этапе сеньора мы учимся правильно понимать слово работа, точнее, здоровая работа здорового человека. Дальше мы вырабатываем в себе привычку расширять свой кругозор, ведь самые очевидные книги и ссылки мы успели изучить, а что и когда изучать дальше — ещё непонятно. Взаимопомощь помогает нам систематизировать знания и узнавать новое, а ещё зачастую она благотворно сказывается на нашем психоэмоциональном состоянии (если вдруг кому это важно).

Principal

Проходит некоторое время, сеньор набирается знаний и опыта. При этом он желает оставаться программистом, быть ближе к станку (коду), так сказать. Называют эту стадию по-разному: Chief, Principal, Tech Lead. Это не архитекторы, а именно высококлассные профессиональные инженеры-программисты. Источники чистого знания и мудрости, как луч света, разрезающий кромешную мглу неопределенности разработки программного обеспечения. Если ранее мы видели себя в космосе, то теперь это свет в нём.

Как мы себе обычно представляем такого человека?

Развитие, коллег, интеллект, работу, кругозор и помощь мы обсудили уже на предыдущих этапах, что же остаётся? Я нередко наблюдаю следующую ситуацию: человек набирается опыта, улучшает свои навыки, постепенно приближается к некоему совершенству. 

Эффект Даннинга-Крюгера здесь не имеет уже значения, тот пик мы давно прошли.

Часто кривую обучения рисуют таким образом: якобы чем больше вы знаете, тем медленнее растете (цифры выбраны наобум, все совпадения случайны). Только мне такой подход не нравится наличием предела.

Кем определен этот предел? Некоторые скажут, что любой язык и платформа конечны. Другие скажут об усталости от профессии и выгорании.

Обратимся к мудрости цитат. 

• Выражение Сократа – «Я знаю, что ничего не знаю, но люди воображают, будто они что-то знают, а оказывается, что они не знают ничего. Вот и получается, что, зная о своем незнании, я знаю больше, чем все остальные».

• Джордано Бруно тоже хорошо высказался, на мой взгляд – «Тот вдвойне слеп, кто не видит своей слепоты; в этом и состоит отличие прозорливо прилежных людей от невежественных ленивцев», причём он не понаслышке знал о выгорании на работе. 

• Лао-Цзы — «Знать, что не знаешь, есть высшее знание. Не знать, считая, что знаешь – болезнь».

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

Давайте разберемся, как нам жить с областью незнания и самое главное — зачем. Кто за последний год хотя бы раз открыто признавал, что был не прав и принимал чужое решение?

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

Здесь главный наш помощник — адекватная скромность. На этом этапе программист должен научиться признавать, что он может ошибаться. Именно на этом этапе это сложнее всего. Это не то же самое, что на пике Даннинга-Крюгера.

Мир меняется. Область незнания сама по себе постоянно расширяется. Лет 40 назад, чтобы перевести деньги другу со своего счёта, вам пришлось бы отстоять бесконечную очередь в сберкассу. Лет 10 назад, вам потребовался бы 1 час — доехать до банкомата, снять деньги, доехать до друга. Сейчас, чтобы перевести деньги другу, вам нужна одна минута и мобильный банкинг. Меняются инструменты, подходы, решения.

Подразумевать здесь можно любой новый инструмент.

• Возможно, новый проект взял предыдущие решения, но собрал их по-новому. Разве это не заслуживает любопытства? 

• Возможно, излишне молодые и ретивые переизобрели велосипед, собрав только худшее. Разве не ваш именно опыт поможет здесь спасти команду от ошибки выбора такой поделки?

Если там правда всё знакомо, то вам хватит одного часа на изучение. Вспоминаем историю с хомячком, у вас должно быть свободное время на подобное.

Если там правда нечто новое, то вы рискуете выкинуть потенциал к развитию, которое вам (как специалисту) почти ничего не стоит.

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

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

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

Получается, в большинстве случаев мы сами выдумываем себе границу, которую считаем «достаточной». Убрать границу совершенно не означает, что мы до самой старости будем только изучать фреймворки. Это абсолютно индивидуально. Как мы выяснили про кругозор — любой новый опыт из новой сферы может прокачать нас.

Главное — хотя бы стать (или оставаться) открытым этому опыту. 

Будьте открыты. Как дети. Я не зря начал с этого. Дети не выдумывают границ, потому и осваивают многие вещи очень быстро (плюс повышенная нейропластичность в детском возрасте, но данный факт не решающий, на мой взгляд). Иронично, что в 2017 году я читал доклад и наугад поставил скачок на 11 годах стажа наперёд. В день выступления было почти ровно 11 лет моего профессионального стажа, я ощущал все эти переживания и заходил на следующий цикл развития.

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

• Понятие «совершенство» растяжимо. Можно стремиться, невозможно достичь. Совершенство как цель лишено смысла.

• Развитие возможно всегда. Стресс-факторы выявляют уязвимости. Уязвимости выявляют потенциал. Постоянное улучшение. 

• Идеал — цель, которая всегда меняется. Нельзя останавливаться!

Заключение

Подведем итоги, что же делать? Получается, нет завершения пути в нашей профессии. Зачем оно нам? Получается, вообще все перечисленные моменты вместе и определяют хорошего инженера. Они все взаимосвязаны и особенно важны в своё время.

• В начале мы учимся учиться, развиваться вообще. Общаться с коллегами и быть самому достойным коллегой. 

• Понимаем возможности своего интеллекта. Учимся грамотно работать (не как над курсовыми). 

• Начинаем расширять кругозор и помогать другим, набираемся опыта. 

• Затем именно адекватная скромность позволяет нам определить, что есть еще большие границы незнания. Позволяет собрать опыт, переосмыслить его и продолжить развитие.

У всех этапы проходят по-разному, у кого-то длятся 2 года, у кого-то 11. Для каждого это его личная история. Главное помнить про каждый из этапов. При попытке пропустить какие-то из них вы сильно рискуете потом бегать по кругу, не понимая что происходит.

В основу этого текста лёг мой доклад с конференции DotNext. Впрочем, он там был в «экспериментальном» блоке, хотя обычно доклады на DotNext посвящены технической .NET-конкретике (вплоть до кода на слайдах). Если вы .NET-разработчик и это звучит интересно, можете обратить внимание на следующий DotNext, который начнётся 16 июня. Будучи фанатом и ценителем этой конференции, я решил вызваться помочь написать статью в предверии нового сезона.

Спасибо за внимание. Готов ответить на вопросы в комментариях.