Долго сохраненный, неправильные [закрытые] предположения программирования

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

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

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

Эти проверки условий, например:

if (condition1 && condition2 && condition3)

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

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

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

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

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

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

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

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

Этот C ++ был в некотором роде лучше всех других языков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для долгое время я думал, что плохое программирование - это что-то, что происходит на грани ... что "делать вещи правильно" было нормой. Сейчас я не такой наивный.

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

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

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

Что женщины считают программистов сексуальными ...

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

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

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

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

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

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

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

«Далее возобновить при ошибке» было своего рода обработкой ошибок

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

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

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

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

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

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

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

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

That a large comment/code ratio is a good thing.

It took me a while to realize that code should be self documenting. Sure, a comment here and there is helpful if the code can't be made clearer or if there's an important reason why something is being done. But, in general, it's better to spend that comment time renaming variables. It's cleaner, clearer and the comments don't get "out of sync" with the code.