Самое вредное неправильное представление новичков о программировании? [закрытый]

Это потому, что их программа компилируется и запускается, она делает то, что они ожидают от нее.

Если их код не компилируется или не работает, то это из-за ошибки в компиляторе.

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

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

Что пользователь - программист.

Все дело в синтаксисе программирования. Оказывается, все дело в решении проблем.

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

Должен признать, много лет назад в школе я был виноват в том, что думал, что мои программы не выглядят достаточно сложно! В эти дни мне хочется плакать, если что-то не окажется таким простым, как:

//start

if(something)
{
    do_stuff();
}

//go home

: P

Что если их программа работает на их собственном компьютере, то она будет работать и на других компьютерах.

«Но она работает на моей машине! "

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

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

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

Конечно,

1. Что их программа будет работать.
2. Если предыдущее препятствие будет чудесным образом преодолено, то их программа будет работать так, как ожидал конечный пользователь.
3. Если предыдущее препятствие снова будет чудесным образом преодолено, их программа выдержит испытание временем, то есть ее будет поддерживать
4. Если все предыдущие препятствия снова будут чудесным образом преодолены, их вторая система будет не хуже или лучше

Что их решение - Единый и Единственно Истинный Способ Решить Проблему , а все остальные просто тупы и неправы.

наиболее опасное заблуждение (финансовая версия):

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

Наиболее опасное заблуждение: все готово, когда код работает.

«Я собираюсь заработать кучу денег, играя с компьютерами!»

Редактировать: Еще один, который сводит меня с ума:

«Код другого парня не звонит. моя правильно, так что это не моя вина, что система не работает ". - без проактивного расследования, диагностики, предложенного патча, ничего. Мне, как менеджеру или руководителю группы, это действительно не по зубам.

The worse misconception I've encountered, and the hardest to be rid of, is that programming is writing code, and not reading it.

Что они «сломают» «что-то!

Или, чтобы определить« новичков »как тех, кто этого не делает:« Это легко изменить! Это программное обеспечение! »

приветствует,

Программа должна быть исправлена ​​с первого раза.

Сбой быстро, рано и часто. Это единственный способ поправиться.

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

Все, что нужно для этого, - это создавать новые классные вещи каждый день. Техническое обслуживание ЯВЛЯЕТСЯ частью программирования!

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

Да, приложение создаст. Да, наверное, это тоже cr @ p, когда вы закончите ...

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

Это как-то связано с компьютерами.

Разоблачение их представления о том, что «идеально, но очень поздно» лучше, чем «приемлемо и вовремя».

Никого не будет волновать, если какой-нибудь еженедельный отчет будет готовиться за 5 секунд. чем 8, если это задержка на два месяца.

Это круто == можно использовать.

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

Обновлено: зацикливайтесь на встроенном коде сборки на C

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

«Проблема не в моей программе, это ошибка в библиотеке / ОС / языке»

«Это сработало на моей машине! Что не так с вашим? »

« Все является шаблоном, вам просто нужно их найти »

« Мне не нужно тестировать, потому что я сделал только одну замену строки »

« Управление исходным кодом - это трата времени на этот проект »

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

На начальном этапе:

• Но разве весь мир не x86?
• Я должен передавать размер с этим буфером?
• Проверка ошибок? Почему?
• STL слишком сложен. Лучше сам все реализовываю.
  • (Используйте std :: swap ()! Std :: swap ()! Начните с этого, затем перейдите к большему количеству ...)
• Не зная, что вы не можете рассматривать двоичные буферы как строки, не завершив их сначала нулем. (Подумайте: read (), recv () и т. Д.)

Позже:

Ошибочно думать, что ...

• Что в байте 8 бит.

• Эта сборка мусора спасет вас из управления ресурсами.

• Endianness? Прокладка? Я не могу просто написать (), отправить () и т. Д. Всю структуру?

• Потоки, взаимоблокировки и состояния гонки, боже мой.
• i18n? (2009 год, и мы все еще узнаем, что Земля круглая!)
• Я мог бы написать это лучше. Время переписать. (Подсказка: рефакторинг .)
• Связано со временем, ошибочно полагая, что:
  • Что в течение календарного года летнее время начинается до его окончания.
  • Все временные зоны равны + или - целые часы.
  • Максимальное смещение UTC составляет + или - 12 часов.
  • 60 секунд в минуту.
  • Этот 1900 год високосный.

Ошибочно думать, что:

• 16-битного кода достаточно для хранения кодовой точки Unicode.
• Я могу игнорировать библиотеки FOSS, которые будут выполнять 90 % работы для меня.
• Этот C, C ++, Python, Lisp, C #, .NET, Java, VB6, Ruby, PHP, Bash, ассемблер - идеальный язык для любой задачи!

, что их код не нужно документировать. Они единственные, кто когда-нибудь взглянет на это, верно?