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

Отсюда и стоит так остро проблема рефакторинга кода.

умение видеть будущее, равно как и последствия своих действий даны не всем.

Это нарабатываемый скилл)

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

Я не люблю делать бесполезную работу. Свою точку зрения стараюсь отстаивать. 😏

По этой причине не зашло в своё время написание дипломов на заказ.. 😂

Когда знаешь, что программа нафиг не нужна - не стоит прям на неё 😬

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

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

Согласен. Тоже были ситуации такие. Если начальство сильно упорствовало, то я давал им возможность убедиться в том, что их предупреждали..)

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

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

Вот потому и тактик) что решаешь задачу локально без учёта общих потребностей проекта.

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

Это в 2006-2008 годах было)

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

Но это всё верно при одном условии. Если претендуешь на уровень выше простого кодера.

>>Ну и английский не помешает.
Забавно, что в присланном тобой видосе (в оффтопной группе) Черниговская прямо говорит "иностранные языки и музыка" forever :))

Посмотри в видосе https://t.me/Delphi_Lazarus_offtop/7423
Секцию вопросов-ответов (с 1:06:00). там есть практически этот вопрос. И докладчик ответила на него просто шикарно 😁