Вопрос к программистам⁠⁠

По большому счёту вопрос - не о программировании в узком смысле слова, а об управлении (программными, если придираться к словам) проектами.

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

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

(Здесь пропущены разные интересные для больших программных продуктов шаги. Вам они в начале пути - примерно на уровне пояса.)

3. Разбить задачу создания программы на какое-то количество небольших частных задач - как минимум, дожен осуществляться ввод данных, их обработка и вывод результатов. Всё это - в соответствии с бизнес-правилами. Разбиение продолжается до тех пор, пока для каждой задачи не станет ясно как именно она дожна быть решена. Как минимум для каждой задачи должен быть прописан алгоритм решения хотя бы для основного хода событий (т. е. игнорируя ошибки) в понятном и доступном исполнителю (программисту) виде. Могут быть указаны основные структуры данных, общие для нескольких задач - просто чтобы не забыть. (На самом деле не только и не столько чтобы не забыть - но нам сейчас эти соображения похуй).

И вот мы подошли к самому программированию. Ура!

4. Делаем задачи, которые определили в пункте 3. Если мы всё спланировали хорошо, то у нас всё срастётся и задача будет решена.

Если что-то пошло не так, то надо понять почему и вернуться к самому корню проблемы для её правильного устранения - вплоть до пересмотра функциональных требований (что чаще всего всё же не нужно). При этом мы старое не выкидываем, а творчески преобразуем стараясь менять как можно меньше для достижения ожидаемого эффекта: чем меньше изменений, тем меньше работы - а нам лень. Впрочем, иногда лучше выкинуть почти всё (из разбиения на задачи) и сделать заново - но это либо самые первые крупные проекты, либо какая-то фатальная патология была на этапах 1-2.

5. Оценка результата. Испытания.

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

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