Почему надо хорошо знать свой инструмент
Каждый раз, когда я рассказываю в блоге как я провожу собеседование программистов, я получаю груду комментариев вида «я плохо знаю язык и считаю, что это нормально, а ты собеседуешь неправильно, нельзя требовать от людей хорошего знания языка». Я уж думал, что я последний человек на Земле, который считает, что инструмент надо знать хорошо (справедливости ради, некоторые комментаторы меня в этом поддерживали).
Ан нет, отличная презентация Олве Маудала и Джона Джаггера «Deep C (and C++)» даёт надежду, что я не последний и хорошо показывает различия между посредственным знанием и хорошим.
Если проводить аналогии с молотком, хорошим знанием инструмента будет считаться умение этим молотком делать дело. А вовсе не знание всех существующих в мире видов ручек к молоткам и детальное понимание того, что произойдёт, если пытаться забить гвоздь в азотной атмосфере.
К сожалению, многие задачи собеседований скорее напоминают пример с молотком в азотной атмосфере, проверяя энциклопедические знания.
Что, конечно же, не отменяет необходимости знать свой инструмент достаточно хорошо, чтобы конечный результат получался с требуемым уровнем качества.
Комментарий для Александр Симонов:
Если проводить аналогии с молотком, то знание всех существующих в мере ручек равно знанию всех языков программирования, а вовсе не знанию одного языка хорошо. Умение забить гвоздь в азотной атмосфере относится к опыту, а не знанию языка.
Комментарий для Евгения Степанищева:
Все языки — это таки все инструменты, включая пневматические дрели и кисточки для акварели.
Александр говорил как раз-таки не про умение, а про знание, не подкрепленное опытом (потому что опыту взяться неоткуда — какой дурак будет в азотной атмосфере применять гвозди, все же знают, что шурупы гораздо лучше для этого подходят).
Два программиста. Один сам выучил язык на практике, читая много отрывочной информации, мануал и читал чужие исходники, так что уважал краткость и читабельность кода.
Второй пользовался только университетскими знаниями и не следил ни за блогами, ни за чем новым, считая что и так потратил временя на изучение инструмента, что подтвердили дипломом и собеседованием. Писал при этом очень академический ОО код.
Даже не знаю что лучше.
Комментарий для Eyeless:
Все языки — все инструменты. Я говорю про знание одного. Причём тут все инструменты и все языки?
Комментарий для Eyeless:
Я не говорю сейчас про методологии и практики. Я, вроде, однозначно вполне написал, нет?
Евгений, а можно разграничить как-то между «хорошо» и «плохо»? Ну, хотя бы в вашем восприятии.
Я вот например, понятия не имею, хорошо я знаю PHP, или плохо, хорошо я знаю SQL или плохо. Что питон я знаю плохо, я знаю :)
Комментарий для Илай:
Ещё не факт, что их надо противопоставлять. «Академик» мог не знать каких-то приёмов, но быть достаточно сообразительным и иметь достаточно знаний, чтобы додуматься самостоятельно. «Практик» мог не знать про академический подход, но вывести паттерны программирования из своего огромного опыта. Именно так они кстати и были созданы.
Комментарий для Олег Горбунов:
Так а слайды-то посмотрите, там же есть всё :) Или всё равно не понятно?
Комментарий для Евгения Степанищева:
Ну я это... слона то и не приметил ;)
Посмотрел слайды. Я очень плохо отношусь к «собеседователям» которые считают, что я должен угадать «правильный» ответ на его «хитрый» вопрос относительно его восприятия и настроения. На краткий вопрос положен краткий ответ. Разверни в вопросе, что же именно хочешь услышать, какие знания тебя интересуют — ты получишь развернутый ответ.
Разговаривать нужно с людьми. И желательно, не вопросами «угадай, или я идиот, или я хочу узнать какие-то особенности» — уважение должно быть взаимным.
Комментарий для Олег Горбунов:
Тут я полностью согласен. Нужно объяснить на что внимание обратить.
Комментарий для Евгения Степанищева:
Я думаю, Илай говорил вот о чём: при прочих равных лучше тот программист, который обладает глубоким знанием языка. Но если, например, глубокое знание языка сочетается с провалами в других областях, и «глубокий» знаток пишет грязный код или не задумывается о проектировании, то достоинство сводится на нет.
Вероятно, читатели всякий раз негодуют, потому что опасаются, что вы, Евгений, ставите глубокое знание языка выше прочих достоинств соискателя.
Не знаю по поводу глубокого знания, но мне кажется, что правильней выбирать человека который может пользоваться тем набором знаний которые у него уже есть. Дело в том, что можно знать массу приёмов и хитых хаков для разбора и решения примеров, но на практике в большом проекте не смочь их реализовывать. Знать и уметь пользоваться — это разные понятия.
Комментарий для warmland.ru:
Мне интересно как они этот вывод делают.
Комментарий для www.orcinus.ru:
Мы не в сферическом офисе работаем. Рядом работают люди, которые пользуются своим набором знаний того, что у них есть. И люди прежде всего люди, они совершают ошибки, они где-то чересчур усложняют. Важно уметь это читать, ошибки же трудно искать не зная языка хорошо.
тема использования std::vector в embedded програмировании не раскрыта на странице 369.
Комментарий для Евгения Степанищева:
Я пока читал слайды, с ужасом представил человека, который всеми этими знаниями активно пользуется при написании кода. То есть активно полагается на все эти соглашения.
Комментарий для warmland.ru:
«Си» другой язык, язык другого поколения, он не «помогает» программировать. Когда он был придуман никто не приходил в ужас от этого. И даже много позже программисты ещё находили прелесть в знаниях такого рода. Думаю, что закат языка Перл произошёл из-за этой тендеции — тенденции к упрощению, к переходу на «дружественные» языки, которые не позволяют программисту совершить распространённые ошибки.
Например, Пайтон не позволит сделать присваивание в условии. «if a=b: pass» вызовет синтаксическую ошибку. «Гоу» не даст создать функцию без возвращаемого значения (все ветвления так же учтутся).
Тем не менее, любой язык надо знать в подробностях. Это просто выгодно. «Побеждает сильнейший», а хорошее знание языка позволит быстрее найти ошибку и даже, иногда, её «почувствовать», позволяет быстро разобраться в сложном коде, в чужом коде, в плохом коде. Я предпочту такого программиста.
Например, в приведённых слайдах, если бы программа в debug компилировалась, а в обычном режиме начала чудить, девочка из слайда, взглянув на код, сразу бы поняла, что речь идёт об неинициализированной переменной и даже знала бы почему в debug этого не происходила, мальчик же оттуда же, начал трассировать программу или занулять всё подряд, т. е. его скорость решения проблемы была бы ниже.
Комментарий для Евгения Степанищева:
Наверное, за этим будущее. Программная инженерия и так сложная штука, за исторически сложившиеся трудности держаться незачем.
Я надеюсь, что у вас молчаливо предполагается, что хорошее знание языка используется, чтобы понимать такой код, как в слайдах, а не писать его. Хотя job security, наверное, — это тоже неплохо.
Я с вами согласен, но если бы я захотел озвучить мысль о том, что глубокое знание языка важно, я бы десять раз оговорился, что оно важно при прочих равных.
Полностью согласен. Аналогия с молотком не уместна. Программист не гвозди забивает, он программы делает. Это в разы более сложная задача и к ней гораздо выше требования. Вы же не согласитесь учиться у врача, который умеет только горчичники ставить и температуру мерить? Или у того, кто выучил только половину болезней, а про другую половину и не слыхал? Я видел достаточно программистов, которые не только не помогали, а вообще мешали работе, потому что сначала им нужно было все объяснять, потом проверять и перепроверять, потом переделывать самому. По логике вещей это не я долежн таким программистам платить, а они — мне.
Насколько часто встречаются люди, глубоко знающие язык, но не умеющие применять эти знания?
Я тоже еще раз повторюсь, что (по-моему) посредственное знание инструмента -- один из наиболее важных возможных недостатков программиста. Исключение — рассматриваемая область не основная для него, или он начал ее изучать сравнительно недавно. Но если несколько лет кодить на си, и не знать, в каких случаях переменная инициализируется нулем, а в каких — мусорным значением, то мало чем можно оправдаться.
ролик про embedded программирование. а там:
Комментарий для zg:
Что за ролик?
Если программист использовал другой инструмент, то он может не разбираться в исходном. Но тогда нечего позиционировать себя как C/C++ программист.
Комментарий для fulc.ru:
презентация, ссылка в посте.
какой, другой?
Комментарий для fulc.ru:
страница 4, первое предложение.
С++ очень громоздкий язык. С огромным числом тонкостей. И эти тонкости необходимо знать чтобы программировать. Эта презентация — антирекламма языка.
Всегда было любопытно кому он уступит свою современную нишу.
Спасибо, отличная pdf-ка!!! Погрузился в мир C++, к удивлению многие нюансы до сих пор помню, хотя не пишу на нем более 8 лет.
Комментарий для vorobyev.name:
Вот ещё хорошая ссылка по Cи++, если ещё не читаете: http://alenacpp.blogspot.com/search/label/cpp