Инструменты не равно навыки

14 комментариев
Инструменты не равно навыки

Не перестаю удивляться тому, как много вопросов вроде «Какой x лучше?» встречается на Programmers.SE и Stack Overflow. Время от времени мне приходится вступать с друзьями и коллегами в дискуссии, тема которых формулируется так: «А что вы думаете о x?». Темы двух этих разновидностей объединяются тем, что x — это какой-либо язык, фреймворк или инструмент.

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

Вы совершенствуетесь как профессионал, осваивая новые умения, инструменты в данном случае играют вспомогательные роли.

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

Начну с примера из моего собственного опыта. Еще в университете я стал заниматься разработкой с ASP.NET WebForms. Вскоре я очень хорошо разобрался в этом фреймворке, научившись приспосабливать его для обработки каких угодно частных случаев, что встречались мне на практике. Я наловчился самостоятельно писать расширения и эффективно переиспользовать уже задействованные компоненты. Сам я считал себя талантливым программистом, а работодатели воспринимали меня как довольно умелого специалиста. Но после долгих раздумий я теперь понимаю, что разработчик из меня был никудышный.

Через некоторое время в общем доступе появился фреймворк ASP.NET MVC, вызвавший всеобщее ликование. Я же воспринял новинку саркастически, будучи уверенным, что любой мой сайт получится более быстрым, функциональным и стабильным, чем у другого разработчика, который попытается сделать такой же ресурс при помощи MVC. Я стал изучать MVC, но этот шаблон был для меня совершенно непривычен, я с огромным трудом усваивал его основополагающие принципы и приемы разработки с его помощью. Оказалось, что я превосходно владею ASP.NET WebForms, но остаюсь довольно посредственным программистом.

Через некоторое время поддержка WebForms прекратилась, и у меня началась черная полоса. Хуже всего пришлось из-за нерационального использования JavaScript; я просто не понимал, что вставлять код JS на страницу и выполнять его именно в момент использования элемента управления — слишком затратный и медленный метод. Конечно, код переиспользовался на машинном интерфейсе, но неидеально, поскольку многие операции были актуальны именно для той страницы, которая их вызывала, и никак не касались совместного использования той или иной методологии доступа к данным. Код пользовательского интерфейса получался раздутым и уродливым. Именно в этой ситуации я понял, что самое время переходить к использованию MVC; очевидно, с его помощью я мог бы сделать код чище, ведь до меня это уже удавалось другим коллегам. Прошло время, я стал отличным специалистом по MVC. Но при этом оставался плохим разработчиком. 

Наконец, я осознал, что и фреймворк MVC не идеален. Некоторые его детали оказались угловатыми и неудобными (например, Microsoft AJAX). В MVC порой получался очень чистый код, но этого удавалось достичь не всегда [1]. На этом этапе карьеры я стал изучать NUnit и принципы разработки через тестирование. Быстро стал настоящим фанатом модульного тестирования, а качество моего кода значительно повысилось.

Примерно в тот же период, когда я осваивал разработку через тестирование (TDD), меня заинтересовали Agile-методологии, в частности, как они могут помочь мне улучшить навыки разработки. Именно этот момент можно считать поворотным. Я стал пользоваться собственной небольшой Kanban-доской для управления резервом проекта (project backlog) — и опять же добился качественного скачка в профессионализме. Теперь я четко представлял, какие задачи предстоит решить в первую очередь, гораздо более рационально группировал одни важные задачи с другими. Я стал опираться на технику, которая никак не являлась частью процесса разработки, не была специальным инструментом, но действительно улучшала результаты моего труда. Мне пришлось изучить, как именно строятся рабочие процессы, а не просто освоить новое «приспособление». И мой код становился все лучше [2]

С тех пор я стал работать гораздо вдумчивее, анализировать свои навыки и пытаться определить, на самом ли деле я понимаю, «как это работает», а не «как это вертится». Я написал собственный MVC-фреймворк на node.js. Так я хотел доказать себе, что не просто умею использовать шаблон MVC или писать код на JavaScript, но и понимаю, каким образом этот шаблон помогает мне писать более качественный код. В ходе работы я подробно познакомился со спецификацией HTTP и теперь действительно понимаю принципы работы Веба, а не просто делаю программы для него.

Все это приводит меня к исходной посылке. Оглядываясь назад, я понимаю, что вырос как разработчик, не просто изучив практику использования ASP.NET MVC, jQuery, Node.js, а заглянув несколько глубже. Я научился применять шаблон MVC в другом языке, где действуют иные принципы. Осознал, как именно базовый фреймворк WebForms взаимодействует с браузером, а не просто научился писать собственный указатель времени/даты.

Ничего не стоит увлечься новым инструментом. Иногда возможности нового фреймворка вас просто очаровывают, вы не сомневаетесь, что он позволит вам писать приложения не только быстрее, но и надежнее. Скажем, вы уверены, что на Silverlight сможете написать просто отличный насыщенный веб-клиент — так что не стоит заморачиваться и учить для этого новый язык [3]. Я сам не раз оказывался в такой ситуации. Самое важное при этом — понимать, что новые фреймворки действительно очень хороши, и следует расширять свой кругозор, насколько это возможно. Но не забывайте, что ни один фреймворк не вечен, и все инструменты рано или поздно устаревают.

Рынок труда в ИT-индустрии, похоже, этого не учитывает. За последний год я видел множество вакансий, и большинство из них озаглавлены как «Требуется разработчик на <язык>» или «Требуется разработчик со знанием <фреймворк>». Далее идет список языков и фреймворков, с которыми соискатель должен иметь опыт работы на протяжении, допустим, последних трех лет [4]. Вероятно, рекрутер или HR-менеджер может не понимать, что у любого языка, фреймворка и инструмента обязательно найдутся параллели. Возьмем, к примеру, C#. Этот язык очень сильно завязан на Microsoft, а .NET-фреймворк содержит определенный набор инструментов, которые вам наверняка пригодятся, — например, NUnit. Но в основе своей C# очень похож на Java. Да, на Java анонимная функция объявляется совершенно иначе, и для этого используется JUnit, а не NUnit, но любой умелый C#-разработчик должен полностью сориентироваться в Java за очень короткое время. 

С другой стороны, вполне возможно, что средний C#-разработчик будет испытывать значительные проблемы с Ruby. Динамические и статические языки настолько отличаются на практике, что при их использовании действуют совершенно разные приемы и принципы [5]. Внедрение зависимостей? Совершенно не требуется в динамических языках. Интерфейсы? Да, но совсем не такие, к каким вы привыкли.

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

Вторая проблема связана с организационными изменениями. Большинство айтишных компаний тяготеют к использованию каких-то определенных фреймворков, и их руководство намерено так работать и дальше. С одной стороны, это вполне разумно: зачем отказываться от того, что точно нам подходит? Недавно у меня зашел разговор с одним программистом, работающим с node.js. Он утверждал, что node.js — идеальный инструмент на все случаи жизни, а я пытался убедить его в обратном [6]. Такое отношение, при котором определенный инструмент воспринимается как «в каждую бочку затычка» довольно проблематичен, поскольку в маленькой компании разработчику приходится иметь дело с гораздо менее разнообразными технологиями, чем в крупной. В большой корпорации от вас вполне могут потребовать написать машинный интерфейс совершенно иначе — так, чтобы он соответствовал API, принятому в этой корпорации. Опять же, такие способности должны прививаться снизу. Если вы расширяете собственные горизонты, осваивая новые технологии, то лучше понимаете, какая из них будет наиболее подходящей при реализации того или иного сценария. Не увлекайтесь всем подряд, что кажется новаторским и блестящим, сохраняйте спокойствие и спрашивайте себя: «Я хочу научиться работать с этим инструментом, потому что он хорошо подходит для решения стоящих передо мной задач или потому, что он просто мне нравится?» 

Наконец, существует проблема найма. Принципы приглашения новых сотрудников могут изменяться только сверху. Если кто-то из читателей может влиять на набор новых сотрудников в своей организации, то я убедительно прошу вас, господа: обращайте внимание на навыки разработчика, а не только на его резюме [7]. Не перестаю удивляться тому, что во многих ИT-компаниях по-прежнему отсутствует тест на разработку, а если он и имеется, то посвящен только основным технологиям, а не навыкам, лежащим в их основе. Как пригодилось бы такое сообщество, где посетитель может узнать не только «хорошие вопросы», которые следует задавать, но и хорошие навыки, которые стоит освоить.

Итак, я рассказал о моем профессиональном развитии. Мне помогло не столько изучение новых инструментов, сколько расширение кругозора, освоение приемов управления задачами и более глубокое понимание основополагающих принципов тех языков, с которыми я работаю. Надеюсь, что среди людей, дочитавших эту статью до конца, кто-то задумается: «Действительно, я знаю, как это делается. Но понимаю ли я, почему это делается так, а не иначе?» Коренные изменения протекают и усваиваются медленно, но наша индустрия очень молода и при этом превосходно социализирована. У нас есть потрясающие возможности меняться вместе, всем нашим цехом.

[1] Я знаю разработчиков, которые впихивают в контроллер тысячи действий — как из-за лени, так и из-за недостатка знаний. Читатели, хорошо знающие MVC, просто содрогнулись бы от такого кода.

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

[3] Однажды у меня произошел довольно сложный спор с коллегой на тему того, стоит ли использовать Silverlight. К сожалению, я оказался неправ. В настоящее время мое приложение на Silverlight уже перешло в разряд унаследованных, вызвало массу проблем. Из-за этого наша организация потеряла как минимум одного разработчика.

[4] Особенно меня умилила вакансия «Требуется CMS-разработчик». Удалил, не читая.

[5] Да, в C# есть ключевое слово dynamic. Но от этого язык не становится динамическим. В C# dynamic — это просто немного более красивая версия var.

[6] Когда я упомянул пакетную обработку, ему, наконец-то, оказалось нечем крыть. Я убежден, что любой человек, которому придется программировать на node.js пакетную обработку в масштабах большого предприятия, заработает себе тяжелую миопию.

[7] Недавно я был на собеседовании, где мне задали вопрос: «Чем отличается “visibility: hidden” от “display: none” в CSS»? Как бы кандидат ни ответил на такой вопрос, вы вряд ли узнаете о нем что-то ценное.

Эд Вудкок

Источник

Горячие события

Testing Stage 2020
26 марта — 28 марта

Testing Stage 2020

Киев
JSNation 2020 Amsterdam
3 июня — 5 июня

JSNation 2020 Amsterdam

Amsterdam

Читайте также

Разработчики Долины засомневались в плюсах работы в стартапах
Разработчики Долины засомневались в плюсах работы в стартапах

Разработчики Долины засомневались в плюсах работы в стартапах

Обитатели Кремниевой долины как ни во что другое верят, что будущее — за стартапами, пишет Quartz. Но всё больше разработчиков перестаёт смотреть на работу в них через розовые очки.
16 комментариев
Коронавирус переводит сотрудников на «удалёнку». ИТ, статистика, паника
Коронавирус переводит сотрудников на «удалёнку». ИТ, статистика, паника

Коронавирус переводит сотрудников на «удалёнку». ИТ, статистика, паника

С разгулом китайского коронавируса возможность работать удалённо становится не приятным бонусом для сотрудников или способом сэкономить для нанимателей, а вынужденной необходимостью, пишет Bloomberg.
Dice 2020 Salary Report: самые оплачиваемые технические специальности, навыки и города США
Dice 2020 Salary Report: самые оплачиваемые технические специальности, навыки и города США

Dice 2020 Salary Report: самые оплачиваемые технические специальности, навыки и города США

Business Insider очень странно вспомнил MSQRD
Business Insider очень странно вспомнил MSQRD

Business Insider очень странно вспомнил MSQRD

1 комментарий

Обсуждение

2

"Вторая проблема связана с организационными изменениями. Большинство айтишных компаний тяготеют к использованию каких-то определенных фреймворков, и их руководство намерено так работать и дальше."

Я бы сформулировал проблему иначе: "проблема аутсорса".
Если заказчик "там" и там же архитекторы - те, кто придумывают продукт и разрабатывают его архитектуру, то "тут" собственно и не нужен кто то кроме "программиста на язике ХХХ". Растёт количество таких проектов, растёт спрос на таких "программистов" (в кавычках, потому как скорее кодеров), изменяется образование под нажимом работодателей - рынок. Но растёт и количество компаний, осознающих, что это тупиковый путь (ну если и не тупиковый, то по крайней мере к вершинам не ведущий) и берущих на себя смелость в предоставлении заказчику более квалифицированных услуг, а не просто кодинг, и соответственно выставляющие перед соискателями иные требования, нежели просто знания такого то языка... Станет таких работодателей больше и образование потянется в этом же направлении.

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

0

Есть проект A на языке B, написанный с использованием C.
Компании нужен разработчик, который "уже вчера" начнет писать код, потому что сроки, а заказчик нервничает.
Или у компании это внутренний проект, какая-нить система управления, которая работает уже N лет, и работает успешно.
Компания публикует вакансию: "Требуется программист, знающий B. знакомый с C, желательно с опытом разработки/поддержки A". Потому что им сотрудник нужен УЖЕ, и времени переучивать его нет, и времени ждать пока он разберется с нюансами тоже нет, и уж тем более никто не собирается переписывать все с нуля, потому что новичок считает что "вот это тут подходит лучше" или "сейчас это уже не модно, давайте писать на X". Им нужен вполне конкретный "винтик". Если у вас другая резьба или вы вообще не винтик, а гвоздь, то вы просто не подходите - есть много других компаний.

Это я к тому, что не надо пытаться все объяснить тем, что "там просто глупые HRы сидят, которые не понимают что значит быть хорошим разработчиком, но я им сейчас открою глаза".

0

> и времени ждать пока он разберется с нюансами тоже нет
Это ходьба по минному полю.

0

Лично я давно для себя понял, что знание нескольких языков программирования и технологий этих языков значительно ускоряют их изучение.
Конкретный пример - мне нужно было как то работать с технологией PCSC - это для работы с RFID метками. Документация по API и примеры на языке С мне не давали представления, как же все таки с ней работать. Однако потом я нашел модуль на языке Perl, прочитал его примеры, написал несколько скриптов для работы с этой технологией, и уже затем с легкостью написал код на языке С.

Anonymous
Anonymous Software Engineer в ScienceSoft
1

Статья годная. Если продолжить рассуждения автора, то в пределе можно придти к выводу, что реальное знание - оно граздо шире любых инструментов, фреймворков и, иногда, даже целых парадигм (прим. ООП с ограчением "всё - объект" и книжкой с паттернами для преодаления этого же ограничения).

В небезысзвестном MIT образование построено(с большего) вокруг теоритических аспектов инженерии в отрыве от какой-то конкретной платформы/тулы/очередногофреймворкалоггирования(тот же SICP чего стоит). Понимая инженерию на таком уровне для человека не составит никакого труда освоить сколь угодно сложные современные конкретные технологии.

На своём примере неоднократно испытывал ценность фундаментальных знаний. Зная принципы построения синтаксических и семантических тестовых анализаторов и поимев опыт написания С-подобного компилятора и интерпритатора, мне не составляет труда за короткие сроки на достаточно глубоком разобарться с тем как рабоать с очередным ЯП и как устроен его компилятор/интерпритатор.

p.s.1)SICP - http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
p.s.2)"В C# dynamic — это просто немного более красивая версия var."
2.a) var - нетерминал, предназначеный для вывода типа на этапе компиляции. Так называемый "type inference".
2.b) dynamic - нетерминал, предназначеный для работы с объектами в условяих отсутствия информации о типе на этапе компиляции. Т.е. в этом случае все метаинформация будет определена DLR'ом на этапе исполнения кода.

0

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

Ну то есть чтобы понять как работает язык программирования можно посмотреть в SICP. Но едва ли это поможет вам понять почему, скажем, "не прикручивается конкретно-этот-плагин конкретно-в-этом-месте".

Но если вы человек с правильно заточенным мышлением, вы поймете, что надо идти к первоисточнику - в исходники плагина. И наступит счастье.

Мне кажется.

0

> поимев опыт написания С-подобного компилятора и интерпритатора, мне не составляет труда за короткие сроки на достаточно глубоком разобарться с тем как рабоать с очередным ЯП и как устроен его компилятор/интерпритатор.

Все так, за исключением С++.

2

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

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

-2

Да.

1

"Да, на Java анонимная функция объявляется совершенно иначе, и для этого используется JUnit, а не NUnit," - нда, как это мне объявить анонимную функцию без JUnit? ума не приложу))))) .
"Любой умелый C#-разработчик должен полностью сориентироваться в Java за очень короткое время." - да ну? Что имеется в виду под "любой умелый"? Так уж и полностью? Java - она большая.. За какое за очень короткое время ? Чтобы успеть завалить горящий проект и побежать дальше изучать чтото еще, а то вдруг завтра Java устареет?

Есть старая пословица:

Мастер одного дела способен прокормить жену и семерых детей.
Мастер семи дел не прокормит и самого себя.

0

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

2

Вам в колхоз нужен тракторист.
Кого возьмете "водителя от бога, прирожденного таланта, с широким кругозором но с тракторами дела не имел". Или "просто тракториста, опыт 5 лет" ????

-1

Может и печально всё так в колхозах потому, что приоритет отдаётся "просто трактористам", а не "водителям от бога"?

3

Не, немного иначе. В наших колхозах даже если ты "водитель от бога", твоя участь все равно "водить трактор".