Зачем, всё-таки, матан программисту?

kernel

Программист == софтверный инженер. Решает в зависимости от должности, в спектре от всего и вся
до ничего.

Таки отсюда получается, что есть, cab.

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

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

Как так?

Или предметники, умеющие программировать.

Это да.

Как так?

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

Таки отсюда получается, что есть

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

без которого программа превращается в говнокод

Кстате, ходят упорные слухи, что в Индии очень сильна математическая школа. Возникает вполне законный вопрос про печально известный индусокод. Что-то тут не так. Или матшкола - фейк, или одно из двух.

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

Или с тобой?

Со мной. Причем, я много раз был инициатором и не раз брал на себя ответственность за проект в целом.

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

Что именно - сам техпроцесс, архитектура, инструментарий, общение заинтересованных сторон?

Что именно - сам техпроцесс?

Ну да, твое участие и там и сям.

Сложно вот так вот, в двух словах, Грабин целую книжку написал, как мягкое введение в project management. Завтра постараюсь ответить.
В тему:
раз, два, три.

Завтра постараюсь ответить.

Спасибо :)

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

4.2

Конечно вредно. Беда в том, что требования физических задач часто обгоняли мои знания математики.

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

Кому нужны? На западе (да и у нас) огромное количество крупных контор где нужны именно обычные «софтверные инженеры». Никаких «широкообразованных» инженеров опять не надо - нужны сразу специализированный инженеры со знанием программирования, если речь идет о разработке какого либо оборудования (и ПО к нему).

нужны сразу специализированный инженеры со знанием программирования

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

Никаких «широкообразованных»

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

Ну да, твое участие и там и сям.

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

Честно говоря, я думаю, что твои проблемы лежат в области управления проектом в целом и твоей личной активностью в частности. Есть книжки, в которых даются, в общем, неплохие советы по практикам - по управлению проектами, например, Стив наш Макконел «Профессиональная разработка программного обеспечения» или недавно пиаренная мной книжка Грабина. Макконел больше теоретизирует, Грабин более практичен, но у него меньше циферок. Конкретные техники рассматриваются много у кого, например у Эрика Реймонда или у Ханта в «Программист-прагматик. Путь от подмастерья к мастеру».
При этом не забывай, что книги это не серебряные пули, просто они указывают хорошо зарекомендовавшие себя методики, полезные в одних ситуациях и не очень в других.

Ну, например.
Сначала группа специалистов, хорошо понимающих в разных вопросах (проектирование интерфейсов, дизайн, программная инженерия) вместе с заказчиком пишут ТЗ.
Проектировщики интерфейсов при этом еще общаются с «низшим звеном». Зачем оно надо кому бы то ни было еще — не понятно.
А дальше реализация со всем разделением труда.

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

В индии просто очень много программистов, 90% которых закончили недельные курсы «пхп для чайников» и пошли программировать. Оставшиеся 10% пишут клево, но имидж индусам по понятным причинам создают не они.

Зачем оно надо кому бы то ни было еще — не понятно.

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

Over 90% матанализа в ВУЗе - это упражнения на интегрирование и дифференцирование. Они, в свою очередь, на 90% суть преобразования сложного выражения в эквивалентную форму с целью упростить его вид, выделить независимые части и т.д. То есть, по-нашему, по-рабоче-крестьянски, это рефакторинг.

У Вас какой-то неправильный матан :) Как насчет доказательства равномерной непрерывности на отрезке непрерывной функции на нём?