Программист ли я, или просто хорошо гуглю?
Письмо Скотту Хансельману
«Иногда в моей голове звучит вопрос — действительно ли я разработчик или просто хорошо гуглю. Я не знаю правильного ответа — я гуглер или разработчик. Скотт, пожалуйста, помоги мне выяснить»
От переводчика
Всем привет, с вами Максим Иванов, и сегодня мы поговорим об одном из постов Скотта Хансельмана (Scott Hanselman), который он написал по причине довольно серьезного и хорошо сформулированного письма к нему. В общем-то, меня вдохновила одна из статей на нашем ресурсе под названием Google-oriented programming. Больше всего мне понравилось то, что в программистах порой может появиться синдром самозванца. Конечно, труды Хансельмана не единственны в этом мире с точки зрения психологии, но он дает четко нам понять, что это нормально. Как он пишет: «Но вот в чем дело. Мы все иногда чувствуем себя обманщиками. Мы все обманщики. Это часть роста. Мы попадаем в ситуации, которые немного сложнее того, с чем мы можем справиться. Но мы справляемся с ними, мы не обманщики, и мы двигаемся к следующему испытанию.» Так давайте же разберемся, какие решения и выводы Скотт предлагает нам в своем посте. Приступим.
Простые правила
Вопрос, который был адресован мне, заслуживал ответа. Я написал об этом в блоге и ответил этому человеку на почту ссылкой.
На самом деле, я чувствовал то же самое, когда садился играть в видеоигры. Вам тяжело прогрессировать, когда уровни становятся сложнее. Каждый мой уровень был на волоске, и я всегда спрашивал себя: «разве я заслуживаю того, чтобы пройти этот уровень? Я не уверен, что смогу сделать это снова.»
Такое ощущение, что ты немного не в себе, когда слишком много думаешь. Кажется, что вода попала тебе в нос, однако ты вовсе не тонешь.
Во-первых, помните, что вы не одиноки. Я уверен в том, что мы растем, когда выходим за пределы своей зоны комфорта. Если это не ломает нас напрочь.
Во-вторых, все, что вам нужно это хорошо практиковаться. Есть Code Katas (упражнения в программировании, которые помогают программисту отточить свои навыки с помощью практики и повторения). Есть проект Эйлера, там появляются нерешенные проблемы чуть ли не каждую неделю.
В-третьих, попробуйте программировать в течение дня без погугливания. Затем два дня, может быть, неделю. Оцените, как вы себя чувствуете. И помните, что было такое время, когда мы программировали без копирования своей работы.
В-четвертых, думайте о проблеме глубже. Читайте об алгоритмах, читайте лучшие книги по программированию и проектированию. Вместо того, чтобы бездумно копировать код со Stack Overflow или копировать код крутого программиста.
В-пятых, принимайте участие в конференциях. Присоединяйтесь к социальным группам пользователей, встречайтесь с теми, кто двигает технологии вперед. Будьте гибкими.
А что вы думаете?
Популярные комментарии на habrahabr
koceg:
Я стараюсь много читать, причём книги из самых разных областей программирования. У меня нет цели запомнить всё или начать использовать эти знания на следующий день. Моя цель — расширять кругозор, чтобы когда появится необходимость, я знал в какую сторону копать. А сам этот процесс всегда начинается с поисковика.
splatt:
Я программирую вот уже почти 10 лет, и я признаюсь вам честно — за все это время я не дочитал ни одной книги по программированию. Я просто начинаю засыпать, когда читаю их, и усвоение материала начинает стремиться к нулю. В результате начинаешь просто пролистывать и искать то, что тебе более интересно и понятно. Мне кажется, это личное предпочтение. Лично мне вот не нравится сам формат книги, но я с удовольствием посмотрю видеоуроки и полистаю официальную документацию, что бы «включиться» в новый фреймворк или технологию. Для меня это тоже самое, что и книга, но гораздо быстрее. Ну и да — никакая книга не заменит вам практику, технику «просто возьми и начинай что-то делать (тестовый проект, todo list, и тд), решая задачи по мере поступления».
Scf:
С позиции опытного разработчика:
Гуглить что?
Чаще всего я гуглю тексты ошибок и куски стектрейсов
Затем — тёмные или подзабытые места фреймворков типа "hibernate declare composite key". Если мне нужно начать использовать новый фреймворк, я предпочту потратить день и прочитать официальную документацию.
И никогда — чужой код. Чужой код при решении проблем нужен только для того, чтобы изучить те API, которыми он пользуется для решения проблемы.
Исключение — это реализация достаточно сложных алгоритмов типа BCrypt, но и там не стоит брать первый попавшийся кусок.
Вкратце: гуглить надо прежде всего чужой опыт и чужие впечатления. Знания лучше по-возможности получать из документации, а код — писать самому или брать известные библиотеки.
vlreshet:
Старый анекдот:
Физику, математику и инженеру дали задание найти объём красного мячика.
Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости.
Математик измерил диаметр мяча и рассчитал тройной интеграл.
Инженер достал из стола свою «Таблицу объёмов красных резиновых мячиков» и нашёл нужное значение.
Вот так и у программистов. Хороший программист всегда сначала попытается нагуглить объём красного резинового мячика, вместо долгого и тернистого пути по поиску объёма самостоятельно. Зачастую нет смысла рыться в документации если тебе нужен чёткий ответ всего на один вопрос — проще нагуглить этот ответ, и работать дальше.
Комментарии к оригинальному посту
Советую перейти по ссылке, там вы найдете содержательные и качественные комментарии разработчиков по данному вопросу нашей с вами темы.К прочтению:
1. Является ли гугление плохой практикой?
2. 10 лучших сайтов с головоломками для программистов
3. Коаны о программировании
4. Питер Молинье о своей карьере
5. Is Googling a bad practice for doctors?
