Долгосрочные ошибочные предположения программирования

Ответ 1

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

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

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

Ответ 2

Чтобы люди знали, чего они хотят.

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

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

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

Изменить: этот ответ теперь является вики-сообществом, чтобы успокоить людей, расстроенных при этом ответе, дающем мне репутацию.

Ответ 3

Что я знаю, где проблема с производительностью без профилирования

Ответ 4

Что я должен иметь только одну точку выхода из функции/метода.

Ответ 5

То, что непрограммисты понимают, о чем я говорю.

Ответ 6

Это бесплатное программное обеспечение было возможно.

Ответ 7

Эти частные переменные-члены были частными для экземпляра, а не класса.

Ответ 8

Я думал, что статическая печать очень сидела на вашей клавиатуре.

Ответ 9

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

Ответ 10

Умные люди всегда умнее меня.

Я могу побить себя, когда ошибаюсь, и часто получаю от себя самоуничижение. Раньше я восхищался многими разработчиками и часто предполагал, что, поскольку они знали больше меня на X, они знали больше, чем я.

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

Мораль истории: Никогда не недооценивайте, что вы можете принести в таблицу.

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

То, что женщины находят компьютерных программистов сексуальными...

Ответ 14

Что качество программного обеспечения приведет к увеличению продаж. Иногда это происходит не всегда.

Ответ 15

Что все языки (в основном) созданы равными.

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

Выбор правильного языка для работы так же важен/критичен, как и любое другое решение для одного проекта.

Ответ 16

То, что большое соотношение комментариев и кодов - хорошая вещь.

Мне потребовалось некоторое время, чтобы понять, что код должен быть самодокументирован. Конечно, комментарий здесь и там полезен, если код не может быть понятнее или если есть важная причина, по которой что-то делается. Но, в общем, лучше потратить время комментариев на переименование переменных. Это чище, понятнее, а комментарии не получают "не синхронизированы" с кодом.

Ответ 17

Это программирование невозможно.

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

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

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

Ответ 18

"При ошибке" Возобновить следующий "была какая-то обработка ошибок

Ответ 19

Это программное обеспечение требует прочной основы в высшей математике.

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

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

Ответ 20

Это оптимизация == переписывание на языке ассемблера.

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

Ответ 21

• Что руководство компании заботится о качестве кода.
• Чем меньше строк, тем лучше.

Ответ 22

Я бы сказал, что сохранение элемента года в дате в виде двух цифр является предположением о том, что страдает целое поколение разработчиков. Деньги, которые были взорваны на Y2K, были довольно ужасающими.

Ответ 23

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

Ответ 24

Этот XML будет действительно совместимым и удобочитаемым форматом данных.

Ответ 25

Этот С++ был как-то по своей сути лучше всех других языков.

Это я получил от друга пару лет впереди меня в колледже. Я держал его со мной в течение смущающего долгого времени (сейчас я краснею). Это было только после того, как мы работали с ним в течение 2 лет или около того, прежде чем я увидел трещины для того, кем они были.

Никто - и ничего - совершенен, всегда есть место для улучшения.

Ответ 26

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

Ответ 27

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

Модели дизайна были похожи на магию; вы могли бы сделать действительно аккуратный материал. Позже я обнаружил функциональное программирование (через Mozart/Oz, OCaml, позже Scala, Haskell и Clojure), а затем я понял, что многие из шаблонов были просто шаблонами или дополнительной сложностью, потому что язык не был выразительным достаточно.

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

Ответ 28

В течение первых нескольких лет я программировал, я не понимал, что 1 Кбайт составляет технически 1024 байта, а не 1000. Меня всегда было немного озадачено тем фактом, что размеры моих файлов данных выглядели слегка от того, что я ожидали, что они будут.

Ответ 29

Это условие проверяется как:

if (condition1 && condition2 && condition3)

выполняются в неуказанном порядке...

Ответ 30

То, что мое программирование будет быстрее и лучше, если я сделаю это самостоятельно.