Програміст я, або просто добре гуглю?

Лист Скотту Хансельману

«Іноді в моїй голові звучить питання — чи дійсно я розробник або просто добре гуглю. Я не знаю правильної відповіді — я гуглер або розробник. Скотт, будь ласка, допоможи мені з'ясувати»

Від перекладача

Всім привіт, з вами Максим Іванов, і сьогодні ми поговоримо про один з постів Скотта Хансельмана (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?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.