Не беспокойтесь: вы профессионал и ведете себя соответственно.

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

Это не непрофессионально — обращаться к внешнему ресурсу. На самом деле было бы непрофессионально не использовать документацию, если вы не уверены, как что-то работает.

Свидетельствует ли ваш уровень доверия к документации о неопытности? Конечно, в определенной степени. Но вы неопытны . Проработав всего несколько месяцев, вы будете знать не так много, как человек с многолетним опытом. Это просто факт, и вряд ли кто-то будет в этом против вас.

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

Тесты по программированию — это немного другое.

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

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

Использование документации в качестве разработчика заставляет меня выглядеть непрофессионально?

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

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

Я также прошу на будущее; например, если мне нужно написать код во время собеседования для другой работы, я думаю, вам не следует использовать документацию.

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

Кто-то однажды сказал мне что-то вроде: «Хирург не может читать свои книги каждый раз, когда ему приходится оперировать пациента».

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

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

Профессионализм и знания - две совершенно разные вещи.

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

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

Не искать вещи, не зная, что это непрофессионально, но это не ваш случай.

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

Использование документации в качестве разработчика заставляет меня выглядеть непрофессионально?

Нет. Запоминание мельчайших произвольных деталей — пустая трата ваших ресурсов. Вам придется помнить многие из них как в PHP (которому немного не хватает согласованности), так и в веб-разработке в целом, если вы знакомы с несколькими языками и десятком фреймворков.

Меня высмеивают за то, что я так часто использую SO/Documentation, что заставляет сомневаться в моих способностях.

Это может оказаться не самым эффективным способом решения ваших задач.

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

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

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

Совершенствуйте свои инструменты и демонстрируйте производительность, это профессионально.

Другие дали убедительные ответы, но никто не занимается этим прямо; жирный акцент мой:

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

Кто эти люди, которые «издеваются» над вами, и откуда вы знаете, что это «…заставляет других сомневаться в [ваших] способностях?»

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

В конце концов, каждый человек в мире использует справочные инструменты для выполнения работы. Черт возьми, разве у юристов и врачей нет кучи справочников и книг, на которые они постоянно ссылаются? Программирование ничем не отличается.

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

FWIW Я работаю на компьютере более 20 лет, и только в последние несколько лет я могу буквально визуализировать решения в своей голове, не написав ни строчки кода. Это навык, в который человек врастает, и его нельзя требовать от кого-то по требованию.

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

На самом деле, я несколько раз защищал других разработчиков, когда заказчик консультационных услуг говорил что-то вроде «почему я плачу хорошие деньги за кого-то, кто даже не может написать код, не посмотрев его в Интернете?»

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

Конечно, непрофессионально искать вещи, когда вы незнакомы.

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

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

Возьмем, к примеру, mail()функцию. Вы знали…

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

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

• При отправке письма оно должно содержать заголовок From. Это можно установить с помощью additional_headersпараметра или установить значение по умолчанию в php.ini.

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

• Параметр $toдолжен соответствовать RFC 2822 .

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

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

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

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

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

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

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

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

Есть разница между «профессионалом» и «знатоком». Если есть какая-то информация, которую мне нужно знать, и у меня есть выбор между тупо сидеть на стуле и застрять, или проверять документацию, то я проверяю документацию. Это абсолютно профессионально.

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

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

Редко бывает, что я сам не могу решить проблему. Но это требует времени. Учитывая выбор между часом, чтобы понять это самому, и пятью минутами, используя Google, тратить час непрофессионально.

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

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

Не использовать документацию

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

Только учебники?

Люди, которые часто ищут в Google учебные пособия или фрагменты кода, включая SO, даже не ссылаясь на документацию, бесконечно раздражают меня. Такое поведение, на мой взгляд, является огромной ловушкой. Это приводит к своего рода программированию, подпитываемому полусырыми, произвольными, бессистемными «знаниями». Эти программисты, как правило, имеют много предубеждений. Вот откуда берутся такие самородки, как «никогда не использовать git rebase», «никогда не использовать not inв SQL», «всегда делать XXX», «никогда не делать YYY». Им будет очень трудно мыслить нестандартно, придумывать новые идеи, формировать интуицию о том, как структурировать свои приложения и все то, что делает отличных разработчиков.

Я бы призвал вас сначала решить любую проблему, просмотрев документацию/справку, а затем искать SO или другие фрагменты.

Конечно, есть исключения. Если ваша проблема совершенно очевидно является чем-то вроде ошибки или чем-то очень, очень, очень особенным, что вряд ли будет описано в какой-либо документации (например, специальная комбинация библиотек/модулей и т. д.), то во что бы то ни стало идите прямо к ТАК.

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

Документация

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

Я не нахожу диковинным читать, например, старую классику C++ (старую добрую статью), Gang of Four Design Patterns, (онлайн-версию) руководства Programming Ruby, чрезвычайно хорошо сделанные man-страницы Perl, Книга Git, некоторые RFC, HTML/XML/и т.д. спецификации и так далее спереди назад. Я бы сделал и делал это даже в свободное время и, честно говоря, ожидал бы этого от любого достойного программиста (очевидно, в зависимости от того, с чем он работает). Я также прекрасно осознаю, что я (по крайней мере, в компаниях, в которых я работал в последние десятилетия) совершенно одинок с таким мнением.

(NB: очевидно, что вам не нужно запоминать огромные списки ссылок на API, но, по крайней мере, просматривайте их, чтобы увидеть, что доступно и каков «дух» API.)

После того, как вы полностью освоитесь с этой темой, настало время взглянуть на сторонний код для вдохновения или просмотреть старые вопросы SO (или задать новые вопросы самостоятельно).

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

Ваш навык программиста заключается в том, как вы можете видеть полную картину и разрабатывать эффективные решения, а не в том, сколько API вы можете запомнить. Цель состоит в том, чтобы выполнить работу правильно и эффективно. Если бы вам пришлось искать каждый API и каждую деталь, я бы сказал, что у вас есть некоторые проблемы. Я ожидаю, что хороший разработчик будет хорошо знаком со всем, что используется часто, в последнее время и регулярно, но не будет тратить умственные способности на то, что используется нечасто, когда его можно легко найти. Если вы посещали stackoverflow более или менее раз в день, это не проблема; если вы проводите на нем большую часть своего обычного рабочего дня, это будет проблемой.

Меня высмеивают за то, что я так часто использую Stack Overflow/документацию

Мнения других людей о вас не определяют вас , они определяют только вас

Использование документации в качестве разработчика заставляет меня выглядеть непрофессионально?

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

«Хирург не может читать свои книги каждый раз, когда ему приходится оперировать пациента».

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

если мне нужно написать код во время собеседования на другую работу, я думаю, вам не следует использовать документацию

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