Как не надо писать прикладные программы

В МГТУ им. Баумана был дико неприятный для меня предмет - материаловедение, который мы называли “тряпки”. Если правильно помню, получить по нему отлично было просто - надо было присутствовать на всех лекциях (этот предмет не был профильным).

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

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

Мне поставили оценку три в утешительном режиме “за старания”, экзамен я бы на большее не сдал, ни по знаниям, ни по ситуации. Но важно здесь другое.

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

4 лайка

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

1 лайк

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

Каждому свое, но для меня просидеть несколько недель ковырясь с алгоритмами VS просидеть на скучных лекциях - звучит как однозначный выигрыш))

1 лайк

Тут прикольная штука, надо себе сразу придумать “выход из рекурсии”. Зачастую в работе (в универе у меня таких приколов не было) случается, что ты же не знаешь изначально сколько это займёт. И когда входишь в штопор, что это сильно дольше и труднее, а значит затраты не окупают выигрыш, надо остановиться. Пойти передоговориться, уточниться. Но это ж как-то надо подумать об этом. И дать себе какую-то прикидку “делаю вот это три дня”, если через три дня внятного результата не получается. Надо что-то делать. Может менять “метод работы”. Может работу менять)

2 лайка

Увы, этому меня толком не учили, и где-то лет до 28-30 я очень смутно догадывался что передоговориться таки можно(. Вернее я знал, что где-то есть такие люди, которые это умеют. Но чтобы самому! Коммуникации-коммуникации

2 лайка

“Лосось доплыл и умер, а что сделал ты для проекта?”. Не учат нигде этому ты прав. Мне раньше всегда казалось, что “кривое потому что изначально неправильно сделали”. А в начало же не вернёшься. Всё значит, ситуация не решаема. Кроме “сойти с поезда”, пусть сами разгребают.

Хочется курс по коммуникациям. Но надеюсь три семестра ШСМ в целом представления о том, почему-что-где не работает, уточнят. И станет понятнее, когда где что можно чинить, а когда уже бестолку…

2 лайка

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

1 лайк