Кто тут писал про тупую работу кодера от забора и до обеда?

[metaclass]

[...]
Это форум программистов, или форум детского сада?

Программист - это такое существо, которое обязано разбираться в очень широком диапазоне тем. Кроме того, программист - это инженер, а общее инженерное фундаментальное образование, вообще-то, предполагает и знание ТРИЗа, и знание методов иммитационного моделирования, и теорию вероятности с мат. статистикой, и основы экономики, и много чего прочего. Без такой базы программист дерьма не стоит, поскольку заказчику проще самому сделать, чем недоучке объяснять свою предметную область.

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


PS: Программист выполняет функции инженера: проектирует и реализует устройства, выполняющие некую функцию. То есть, программист - это инженер. А если не инженер - то это и не программист, поскольку он не может выполнять своих служебных обязанностей.

Comments

[guamoka.livejournal.com]

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

если честно, даже после беглого просмотра перлов этого чудака, утверждаешься в справедливости одной старой истины: ученый дурак во сто крат страшнее невежественного.

зы. divida et empera.

[metaclass.livejournal.com]

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

[nvm.livejournal.com]

тут да, это проблема.

[vp.livejournal.com]

В случае программирования можно обойтись знанием только "языка" или "тулса" только в одном случае - если ты пишеш флеш или веб. Вот там да, действительно. Сайты будут всегда почти одинаковы по смыслу, и ничего специального знать не нуна.
А в случае работы с кровавым ентерпрайзом, то, чем занимается владелец дневника и то, чем занимаюсь я, для того, чтобы что-то родить нужно в совершенно новой предметной области конкретной отрасли экономика разбираться ЛУЧШЕ, чем специалисты этой отрасли, которые будут работать с твоей системой! Это же самоочевидно. Именно потому и возникают такие требования.
Не знаеш радиофизику? Пожалуйста, пример, как систему, основанную на RF-ID поставили на предприятии, где были помехи на этих частотах, и все пошло в зад. И т.п. и т.д.
И речь о том, что человек с фундаментальной подготовкой В СОСТОЯНИИ за ограниченное время способен разобраться в ЛЮБОЙ предметной области. Начиная от мясокомбината и заканчивая нефтеперегонкой. А кодер тупой - нет. Потому что он ограничен по определению

[guamoka.livejournal.com]

>>
В случае программирования можно обойтись знанием только "языка" или "тулса" только в одном случае - если ты пишеш флеш или веб.
<<

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

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

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

>>
Не знаеш радиофизику? Пожалуйста, пример, как систему, основанную на RF-ID поставили на предприятии, где были помехи на этих частотах, и все пошло в зад.
<<

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

[inhate.livejournal.com]

В "кровавом ентерпрайзе" есть пара понятие аналитика/постановщика задач - который каленым железом вытягивает из заказчика его предметную область, как это должно работать, творчески перерабатывает, пердусматривает, зачастую верно предсказывая фичи которые могут потребоваться и основу которых дешевле заложить на начальном этапе - и выражает это в виде ТЗ, по которому уже рисуется UML.
Я искренне считаю крайней степенью идиотизма использовать рабочее время человека способного лучше чем заказчик понять проблему (а это действительно надо для создания успешной системы) в качестве простого кодера, ровно как и нанимать оферквалифайд кодеров. Хватит с кодера и владения _своей_ предметной областью - производства ПО - абы понимал как работает релиз-цикл в данной конторе, делал свою часть и не мешал другим.

[metaclass.livejournal.com]

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

[guamoka.livejournal.com]

>>
Я не видел ни одного человека, который, не понимая предметной области, мог бы написать что-то вменяемое.
<<
все разработчики, участвующие в определенном проекте, так или иначе начинают разбираться в предметной области. но от этого они не становятся экспертами, и не обязательно способны на постановку задачи в рамках всей системы. однако они способны помимо своих прямых обязанностей имплементации принимать квалифицированные решения в рамках подсистем/компонент потому что а) обладают необходимыми знаниями, полученными от аналитика; б) знают, что и у кого спросить по предметной области в ситуации неопределенности.

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

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