Comments 100
Когда человек в следующий раз столкнется с той же проблемой, он снова полезет на Стек. И снова. И снова.
Чужое решение не запоминается.
Ерунда.
Я программист 3д графики. До выхода UE в Open Source — моя основная работа была завязана на программирование 3Д движков с нуля.
Я не смогу в тетрадке без внешних источников написать работающий код инициализации OpenGL. Я на нём работаю с 2004 года. Проектов написано под сотню, разного уровня сложности. Я много раз по документации писал инициализацию. Но не смогу её точно вспомнить. Зачем мне её в деталях учить?
Нет стимула разбираться, как оно устроено.
Ерунда.
Если вы пихаете код из внешнего источника не разобравшись в нём — это не проблема внешнего источника.
Это проблема вашего лида, который до сих пор вас не уволил.
Нормальные программисты берут решение с SO. Смотрят что в этом решении происходит и тогда уже копируют в своё код, без изменений, если код на 100% соответствует ситуации. Но никогда не пихают в свой код чужой черный ящик.
Смотрят что в этом решении происходит и тогда уже копируют в своё код,
«Смотрение» в чужих решениях обычно очень поверхностное. Нет глубокого понимания, нет обучения.
https://habrahabr.ru/post/218307/
Нашел решение, разобрался почему оно хреновое, написал в итоге своё(вроде тоже на основе обсуждения в SO, уже точно не помню).
Прошло два года:
1) Я ничего не помню о диспетчеризации событий в Android. Не работаю с этим, соответственно не помню. Несмотря на то, что в тот момент достаточно детально разобрал ситуацию.
2) Мне за два года больше ни разу знания о диспетчеризации событий в Android не пригодились.
Может давайте отделять фундаментальные знания, которые надо изучать, от всякой мишуры, которую сделал и забыл? Причем забыл, независимо от того, сам разработал решение или нагуглил.
Как? Ты вставил код, а потом баги пошли, как будешь дебажить, если не знаешь, что внутри, как работает?
Нормальные программисты берут решение с SO. Смотрят что в этом решении происходит и тогда уже копируют в своё код, без изменений, если код на 100% соответствует ситуации. Но никогда не пихают в свой код чужой черный ящик.
Вот только остальные 95% копипастят не глядя…
Stackoverflow это в большинстве случаев та же документация
Stackoverflow в большинстве случаев — это Add two variables using jquery. Есть и исключения, конечно, но они не опровергают общую картину.
В чем разница — поискать в гугле, или порыться в документации?
Кроме того, документация часто написана так, что бы отвязались, и в реальных задачах слабовато помогает.
Я начал писать ответ, но понял, что если для вас нет разницы между гуглением и чтением документации — вряд ли смогу что-то объяснить.
«Если учёный не может объяснить уборщице, которая убирается у него в лаборатории, смысл своей работы, то он сам не понимает, что он делает.» © Эрнест Резерфорд
А вы предлагаете читать документацию последовательно, сверху вниз?
В общем-то, имхо. это — самый эффективный метод чтения документации с точки зрения уровня полученных знаний и понимания этих знаний. Время и силы — это уже, конечно, другой вопрос и кому что важней.
Это, знаете ли, от документации зависит. Если у вас документация типа reference, то читать ее подряд — приблизительно так же полезно, как читать подряд энциклопедический словарь.
Ну и да, вот уж понимание от этого точно не зависит.
Но это справедливо только тогда, когда документация написана качественно. А это к сожалению не так в подавляющем большинстве случаев. И тогда на помощь приходит SO, на котором товарищи помогают обойти грабли, не учтенные в документации.
Не вижу причин противопоставлять эти два метода получения знаний.
Я как раз отношусь к «правильным» программистам, которые сами до опупения разбираются с проблемой, вместо того чтобы загуглить. И вот что я могу по этому поводу сказать: уже неоднократно ловил себя на том, что обнаружив багу в чужой библиотеке, докапываюсь до ее сути, исправляю ее, после чего выясняю что это никому не нужно — проект давно не обновляется, а в первой же строчке выдачи гугла решение в две строчки, как можно работать с библиотекой, чтобы не натыкаться на эту ошибку. То есть, я молодец, вроде как… только вот кому и какая польза от моих действий?
Польза вам. Вы получили левел-ап. А те, кто взяли «решение в две строчки» — нет. С годами эти левел-апы ощутимо проявляются в размере заработной платы.
С годами эти левел-апы ощутимо проявляются в размере заработной платы.
Или не проявляются. Ибо мои левел-апы оценить нельзя, а производительность «копипастера» как раз можно. Так что так себе аргумент — только для самоуспокоения годится.
Производительность «копипастера» часто падает до нуля при столкновении с нестандартной задачей/багом и и тогда оценить левел-апы становится очень просто. Один может решить задачу, а другой нет. Вопрос о квалификации и ЗП в такие моменты становится весьма очевидным.
Поверьте, еще ни на одном месте работы я не встречался с тем, что качество ценится больше количества
Попробуйте поработать в компании, которая делает свой продукт и руководство которой понимает, что им жить с этим легаси еще не один год. Таких конечно меньше чем тех кто человеко-часы продает, но они есть.
Практика показывает, что это ваше "часто" случается крайне редко! Потому что мир в основном состоит из рутинных и одинаковых задач, решение которых уже найдено и легко "гуглится".
У меня есть знакомый, который шлёпает телеграм-боты как блины, да еще и денежки за это получает, и при этом он практически не знает программирования! Это не фигура речи — это на самом деле так, и он этого не скрывает. Копипаст (в т.ч. и с Хабрахабра), Гугл, Стаковерфлоу, на вопросы "как это делается в Питоне" чаще всего я отвечаю — и всего этого оказывается более, чем достаточно. Как-то (не так плохо!) работает, заказчик доволен, приятель не голодает — всё отлично.
Я себе не могу позволить подобное — как же, я же как бы профессионал, мне нужно разобраться прежде, чем скопировать чьё-то чужое, а лучше, конечно, написать самому. Но когда прикидываю в уме, сколько денег я не заработал из-за своих принципов, ко мне приходит следующее понимание: в глазах посторонних профессионалом выглядит именно мой приятель.
Неа. В глазах людей, которые в этом не разбираются он выглядит профессионалом, а вот нормальные люди, чьё мнение действительно кого-то колеблет в профессиональной сфере, смотрят в код, ну или нанимают людей, которые будут понимать в людях и которые могут попросить другого человека посмотреть в код и сказать своё мнение о человеке.
Как ни странно код достаточно явно показывает отношение человека к проекту. Самое тупое — если где-то табы, а где-то пробелы в качестве отступов. Где-то snake_case, а где-то camelCase или вообще что-то гибридное. Связность названий переменных многое может сказать. Например снаружи использовались машины-иномарки, а в функции загрузки аргумент называется как грузовики.
Копипасту отличить вообще не трудно.
И вот лично я всегда прошу сначала показать код человека, с которым мне предстоит работать. Можно многое сказать о нём сразу же. И о профессионализме можно судить именно по качеству продукта.
Вот только единственная проблема, работодатели к таким тонкостям не прислушиваются. Им главное — скорость. Это всегда проблема. И не важно что ты делаешь всё красиво и читабельно. Если им резко нужно на 3 дня раньше, то ты должен сделать на 3 дня раньше, и не важно, что у тебя эти 3 дня на тестирование в плане были отведены. Короче всё как всегда, там где есть быстрые деньги нету качества.
Разбираясь в проблеме самостоятельно — ты между делом узнаешь подробно как оно устроено, запомнишь ньюансы которые тебе могут пригодиться позже, проникнешься архитектурой. Ведь не зря джуниоров заставляют заглянуть, например, во внутрь java.util.HashMap — там ведь очень много полезного.
SO отличный инструмент, и когда нет времени на ресер — он прекрасно спасает, но как говорит автор — нужно уметь и головой думать, и в исходниках ковыряться.
да мозги потренировать и прочие бредни
Да, мозги потренировать и прочие бредни. Точно подметили.
Понятное дело, что пользоваться коллективным разумом нужно в РАЗУМНЫХ(какая ирония, да?) пределах, я думаю, каждый тут это осознает. Отсюда — нет смысла говорить людям, что «не нужно подчистую копипастить код ай-я-яй».
Скачать документацию, чтобы была под рукой. Я рекомендую devdocs.io — на выбор 130 языков и фреймворков, бесплатно.
Дополнительно рекомендую Zeal — zealdocs.org. Заявлено 195 docsets
В некоторых моментах лучше чем devdocs. Например есть MySQL документация, которая в devdocs отсутствует по лицензионным соображения. Zeal имеется в репо Ubuntu и Fedora.
Во-вторых, на мой взгляд, удобство и эффективность поиска на Stack Overflow привели к ухудшению официальной документации — просто не стало смысла сильно напрягаться. Это при том, что и раньше-то немногие заморачивались.
Ну и в-третьих, все слишком быстро стало меняться, если раньше я ставил с нескольких дисков MSDN и мог пользоваться им чуть ли не годами, то сейчас такое просто не прокатит.
Это раньше бы сработало, во времена FoxPro, Clipper, скажем…
Да и задачи усложнились, в ответ на усложнение среды…
Но когда есть толковая документация, это хорошо и может быть полезнее заглянуть в нее и посмотреть какие-то хитрые моменты, прежде чем рыться в SO или загрязнять его вопросами. Другое дело, что сейчас это редкость, особенно во фронтенде…
А вот если программист за каждой ерундой лезет, то это уже не круто. Основы нужно знать наизусть и применять свободно.
Такой вопрос задавали Бобуку, он отлично ответил.
Недавно сделали прикол на эту тему: stackoverflow-autocomplete
Фиговое предложение.
Если программист не склонен включать мозг, наврядли ему что-то поможет, кроме осознания этого факта и работы над собой.
Я сам склонен к тому чтобы знать доки и проходить к решению самому. Но ситуации разные бывают. Например, мне сейчас чтобы понять как это сделать, нужно долго и вдумчиво вникать в концепцию работы с данным инструментарием, чтобы понять, как скажем затереть до прозрачности участок в нарисованной холсте. А ещё я могу написать код и он не будет работать не факт что просто из-за "лишней запятой" а не потому что я неправильно понял и использовал доку. В таком случае рабочий пример был бы очень необходим. Особенно когда клиент ещё плачется и ему нужно доделать побыстрее. Я вообще не особо люблю копировать код, но часто ищу готовые примеры, чтобы понять как это нужно делать.
Тезисы были бы следующие:
1) скорость разработки нынче выше на порядок, чем раньше, и никто не даст разработчику месяц копаться в документации;
2) StackOverflow это просто та же самая документация, просто более интуитивно/естественно структурированная;
3) ВСЕ проблемы в жизни разработчика случаются ровно 1 раз, переиспользование опыта с конкретной библиотекой это такой же миф, как переиспользование самостоятельно написанного кода.
Ну и там, все мы помним что методики разработки пляшут от бизнеса и решения его задач, а не от интеллекта разработчика и удовлетворения его эго.
Программировать приходится на VBA, питоне, C#. Для пет-проекта — на JavaScript.
На любую поблему на SO первые несколько ответов — как минимум не оптимальные, но иногда и ошибочные (хотя проблему в частности решают).
Последнее впечатлило: в драйвере puodbc вставка данных в ms sql возможна только построчно.
Большинство ответов сводились к решению сделать огромный sql запрос с кучей insert, и переправить его серверу.
Я-то знаю про загрузку из csv, и понимал, что нужно искать (решение — модуль миграции данных odo). Но в целом уровень решений ужасен, на уровне «побить в бубен».
При этом, так как я не профессиональный программист, я без SO вообще программировать не могу. Другое дело, что возраст, образование и опыт позволяют понять где решение, а где ерунда.
2. На SO часто ищу не «как сделать», а «как лучше сделать», например изучаю питон, после неплохого опыта в перле — я знаю как правильно решить задачу, но не знаю как это сделать в питоне и часто гугление приводит именно на SO, правда и там не всегда есть правильные ответы, но часто есть.
3. Внешняя память это однозначно хорошо, в ИТ слишком быстро всё меняется, нет смысла учить наизусть то, что завтра устареет.
К сожалению не видел ни разу толковой документации
Не столько про толковую документацию вообще, но в частности могу порекомендовать ЛибГен (если, конечно, на хабре это не запрещено). Редко-редко, но в некоторых книгах иногда все-таки можно найти то, что на SO не найдешь.
без интернета
я сначала подумал что предлагается кодить реально без интернета/ потом увидел совет «я рекомендую devdocs.io », — так что получается что не без интернета
статья конкретно про стековерфлоу а не использование онлайн ресурсов вообще?
devdocs.io работает без интернета.
Как добыта информация — из головы или из Stack Overflow — вы не поверите, абсолютно неважно, если итоговый результат технологически верен. А фундаментальные знания — да, расширять и углублять надо, никто не спорит. Они помогают быстрее и правильнее гуглить :)
Тут-то ты и понимаешь, как тяжело искать по документации то, не знаю что.
Иногда проблема именно в том, что не знаешь откуда начать копать.
SO помогает в том, что помогает сформулировать вопрос, продумать его. Поискать похожие.
Обычно, сначала пытаюсь решить проблему самостоятельно, потом лезу в гугл. Если не помогает- то пишу вопрос на SO с примерами кода (то есть показываю сообществу, что я пытался решить проблему, но не смог) и прошу показать в какую сторону копать дальше.
— ужасная документация (канцелярский язык по пять-десять существительных подряд, нет структуры, нет хороших примеров, давно не обновлялась, и т.п.);
— разработчики, которые проработали там десяток лет и помнят все возможные случаи и их решения наизусть, не хотят делиться знаниями (со стороны кажется, что это job security у них такая, но я бы не стал утверждать наверняка и за всех сразу).
И да, не знаешь, откуда начинать копать. Чувствуешь себя при этом, мягко скажем, неловко.
Я избегаю этих предприятий, благо такая возможность есть.
Да, я думаю, у большинства действующих программистов есть опыт программирования без интернета…
У меня, когда начинал учиться программировать, была только офф.документация по Delphi и пара книг из университетской библиотеки. Правда с тех пор осталась привычка во всём самому разбираться, не задавая вопросов на форумах.
Ну знаете ли, SO и Google разные вещи. Я вот довольно часто что-то ищу в документации с помощью Гугла, например по PHP или по тому же андроиду. Зачем лезть в какие-то книги, если их содержимое оцифровано, проиндексировано и бесплатное
Чужое решение не запоминается.
Что-то в этом есть…
К тому-же, найденный на Стеке решения часто далеко не оптимальны.
Попробовал ради интереса на этом сайте поискать исходники или документацию — по многим «page not found» или просто сигнатура метода без каких либо обьяснений. Например, было интересно почитать как работать вот это https://devdocs.io/haxe~java/util/concurrent/executorservice#awaitTermination.
Даже предложеный пример обучения джуниоров тому как работает HashMap — и тут промах :)
devdocs — это агрегатор и поиск, они не пишут документацию. Показывают то, что есть в оригинале. А там пусто: http://api.haxe.org/java/util/concurrent/ExecutorService.html
Найденное чужое решение действительно не запоминается, но не в случае, когда ты сам потратил кучу услий на то, чтобы найти решение проблемы, и не преуспел. Важен сам процесс поиска.
вот например текущий проект на STM32. всего кода 18 мегабайт, моего 400 Кбайт.
многие статьи на хабре используют RTOS, fatfs от елм-чана, езернет, кучу датчиков и тд
да даже усб стык это десятки тышь недокументированного говно-кода пьяной макаки с кучей багов и обычно не работающий без допила вообще.Гугл частенько выручает когда нужно допилить что либо после предшественников, которые как будто назло бывает выискивают то кривые плагины и библиотеки то не удосуживаются даже закомментировать всю эту Вакханалию после себя, но большей частю пытаюсь дойти до всего сам, ибо " Кто живет чужим трудом, тот неизбежно кончит тем, что начнет жить чужим умом, ибо свой ум вырабатывается только с помощью собственного труда" © Василий Осипович Ключевский
Любопытно, что предложение воспользоваться на 5 минут мозгом и документацией, прежде чем бросаться гуглить, вызвало у многих программистов такую яростную реакцию, как будто я хочу запретить stackoverflow. Думаю, это лучше всего показывает, что проблема злоупотребления Стеком реально существует.
Вот скажите мне, какая разница между "погуглить, чтобы найти статью из документации" и "воспользоваться документацией"?
В большинстве случаев проблемы которые гуглятся встречаются в карьере 1 раз, так же не стоит забывать, что технологии разрослись настолько, что даже если вы разобрали проблему по полочкам через определённый срок вы всё равно скорее всего забудете как решили её.
И я, честно говоря, сильно сомневаюсь, что нормальный программист будет бездумно копировать код не разобравшись в нём хотя бы поверхностно (не знаю как в мире вэба, но в мире С++ тупое копирование вряд ли когда либо будет работать хорошо). Я например гуглю в основном не готовое решение, а примеры на которых я мог бы построить свое решение со своими требованиями (Я надеюсь как и большинство тех, кому не понравилась статья). Так что я например получаю наибольший опыт именно с ресурсов на подобии SO.
Возможно ваш совет подходит для кто только нарабатывают базу в своей сфере, но для всех остальных это по моему мнению бестолковый совет, который только снизит производительность, не дав в замен ничего.
Цель — «внедрить Х» к примеру. К этой цели можно идти 2 дня, а можно и неделю, в зависимости от масштабов задачи.И вот когда наконец пишешь код, оптимизируешь сервис и каждые полчаса тебя отвлекают вопросами, срочными задачами и вызовами — вернуться в работу порой очень тяжело и на это тратится время.Находишь силы, пошурупишь немного над задачей(без «Ok Google» и SO) решаешь половину задачи «И тут появляется нечто новое, восхитительное. В новой версии софта появилась интереснейшая фича. Вышла новая классная железяка, которую надо купить и внедрить.»И так далее…
Отсюда вытекает вопрос насколько документация «полезней» гугла в данном контексте?!?!
Чужое решение не запоминается
Своё решение тоже не запоминается :) Довольно давно отвечаю на вопросы на stackoverflow. Так вот, уже несколько раз в поисках решения своих проблем с удивлением натыкался на свои же ответы. И я совершенно не помню этих ответов, не всегда даже помню, что была такая проблема.
Возможно, дело в том, что подавляющее большинство проблем – одноразовые. Естественно, я не пойду искать реализацию цикла for или детали вызова библиотечной функции, которая используется каждую неделю.
Чужое решение не запоминается. Нет стимула разбираться, как оно устроено. Нет чувства удовлетворения, когда «заработало!». Не образуются в мозгу новые нейронные связи. А без этого нет и запоминания.
Не знаю, как там у автора, а у меня «чужое решение», как правило, не решение — решаешь-то свою, совсем другую задачу. Задача стоит, допустим, собрать мопед, а на stackoverflow идёшь за недостающим винтиком — вместо этого надо найти месторождение руды, выплавить сталь, выточить винт, нарезать резьбу, только тогда образуются связи и будет удовлетворение, что мопед поехал?
Дальше хуже. Когда злоупотребляешь готовыми ответами, перестаешь воспринимать аналогии и косвенные решения. Ищешь, чтобы прямо один-в-один было то, что тебе нужно. В долгой перспективе это тупик.
Что за бред… Не бывает же готовых ответов — любой, самый лучший, ответ решает сильно упрощённую проблему в вакууме без проверок на null. Поди найди «прямо один-в-один то, что тебе нужно», ага — любое, самое лучшее, решение надо сурово адаптировать под свою задачу.
Г. У автора проблемы с интернетом походу)))
У меня когда такое было то тоже хотелось все мануале себе на комп выкачать.
А вообще я хоть и люблю писать свои велики, но блин иногда капец какая проблема появляется геморойная… Вот тут то Гугл выручает.
И ни в одном мануале такого не найдешь, ибо это опыт. И да делитесь своим опытом с другими!
Гулил, стековерфловил, и т.д. Оказалась бага виртуалмина
Другой вопрос, что нужно делать выводы из нагугленного, а не просто ctrl+c ctrl+v. Поэтому завел себе личный бложик с полезными заметками. + иногда неплохо оставлять и комменты на стеке.
Знаете проблему современного поколения? Она уже всеми стариками озвучена. Это проблема мнимой информированности.
Запомнить источник !== Запомнить решение
Как бы проблема немного другого рода, её автор и хочет донести. Это проблема мнимости знаний.
Я уверен, что хороший программист в свой код не будет вставлять то, что он не понимает. Ибо это реально дебелизм и вообще-то потенциальная дыра в коде.
Я тоже пользуюсь so, хабром и форумами. Но лично для меня ctrl+c ctrl+v — не доставляет удовольствия от решения задачи. Вот когда я понимаю почему так, а не иначе, тогда да, я крут и могу спокойно использовать этот кусок кода. Откоментив его для себя, чтобы в случае чего не забыть мысль, которую я в нём нашёл.
Никогда не понимал этой погони за скоростью работы. Если работаешь хорошо, то никто тебя гнать не будет. Если работаешь хорошо и с головушкой, то эти 45 минут на изобретение своей версии велика не пойдут в трубу.
Лично для меня любая мозговая активность является благом, будь то уравнение, алгоритм или составление запроса в поисковике.
1 задание, java. Вот тебе программа. За день разберись что к чему и быстро на следующий сделай то, то и то.
При условии что её писали 2 года 1,5 человека. На языке который изучал 3 недели. Крутись как хочешь, устроился на работу — работай, нет — вали (что не выйдет — это распределение после универа, но скажется на зп).
2 задание, php. Ну скоро там? 2-х недель тебе мало? Это всего лишь сайт для архива!
Это попытка делать спокойно и вдумчиво. Ибо прошлые версии сайта оказались настолько кривые прошлых программистов/кодеров, не знаю как это назвать, что исправлять что-то там «что бы работало» намного дольше, чем написать своё.
В итоге теперь(!) куча свободного времени, исправление мелких ошибок и убирание прошлых, копипастом, костылей за одно и изучение этого, нового для меня, языка — Java.
Программирование без интернета