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

[metaclass]

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

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

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


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

Comments

[nvm.livejournal.com]

хм, а почему бы не потребовать от заказчиков хотя бы поверхностного знакомства с С++?

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

[metaclass.livejournal.com]

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

[beskov.livejournal.com]

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

Best Regards

[situns.livejournal.com]

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

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

[ding-0.livejournal.com]

Оффтоп. Количество сообщений на форуме у него красивое...

+1

[ex-chistyak.livejournal.com]

Программист - это инженер. Остальные - неведомо кто. Мусор, наверное.

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

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

[black-angel-by.livejournal.com]

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

мля, сам не понимаю чтонаписал :(

[metaclass.livejournal.com]

Да потому что людей новых учить заставляют давно и прочно сошедших с ума психов, типа меня. У меня спроси любую мелочь - я начну рассказывать сначала про нее. Затем про то, из чего она произошла, потом по все более расширяющемуся дереву связанных знаний, итд.
Потому что не понимаю, как человеку объяснить простым образом, к примеру, скажем принцип работы SQL запроса, если оный SQL тянет за собой реляционную теорию и булеву алгебру, реляционная теория теорию множеств, а булева алгебра и теория множеств тянут за собой всякую математическую хренотень, которую зачем-то когда-то мне преподавали. И это еще не считая всякие компутер-сайенсовые связанные дисциплины, вроде декларативных языков, обработки списков и функционального программирования :)

[guamoka.livejournal.com]

>>
Потому что не понимаю, как человеку объяснить простым образом, к примеру, скажем принцип работы SQL запроса, если оный SQL тянет за собой реляционную теорию и булеву алгебру
<<

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

[vp.livejournal.com]

Не согласен.
Я 100 раз видел, что получается из того, когда человек работает и использует механизмы и не понимает, КАК оно работает. Типичный пример - передача параметров в SQL запрос.

[guamoka.livejournal.com]

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

[guamoka.livejournal.com]

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

[vp.livejournal.com]

select * from Table1 where Field1 = ' + Param1 + ' and Field2 = ' + Param2

[atzkey.livejournal.com]

http://imgs.xkcd.com/comics/exploits_of_a_mom.png
http://xkcd.com/327/

[metaclass.livejournal.com]

Конкатенация SQL запроса и параметров ручками vs использование связываемых переменных.

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

[guamoka.livejournal.com]

>>
То самое разделение труда.
<<

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

[black-alpinist.livejournal.com]

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

А что ты сам-то из этого знаешь (бух. учет с экономикой только не путай ;)? Не боишься сам провалиться на своем собеседовании?

[ratibor-vv.livejournal.com]

Вчера с xanth_ego (долгие годы разрабатывал своими руками, а теперь руководит разработкой и внедрением очень крупной комплексной системы автоматизации управления предприятием), flaer_black'ом, еще рядом товарищей обсуждали как раз этот вопрос (в кафе ПроКофий, давно ставшем стандартным местом заседаний нашего сообщества). Молодой и горячий коллега (заодно мой студент) доказывал, что институт заставляет его учить кучу всякой ерунды, а он лучше бы это время потратил на ПХП или Си++. Мы с xanth высказали такой набор тезисов:
- "специализация - удел насекомых" (с). Узкий специалист, великолепно владеющий одним узким ремеслом, зато владеющий на 200%, нужен и очень полезен и эффективен на этапах стабильности, когда на протяжении жизни одного поколения уклад жизни, общественная практика, потребности итд меняются мало. А такие времена уже в неолите закончились. Сейчас успешнее и выгоднее (и себе и обществу) тот, кто своим ремеслом владеет пусть и не столь виртуозно, зато способен гибко менять и используемый инструментарий, и, более того, область задач.
- Jedem das Seine (c) надпись на воротах Освенцима. Если некто и хочет освоить ремесленное программирование, не выходящее за рамки одного-двух-трех языков и инструментов, то кто мы такие, чтобы принудительно заставлять его становиться всесторонне академически образованным мыслителем? Но точно также он имеет право не получать диплом о высшем образовании. Для узкой ремесленной специализации есть ПТУ. Кстати, нечего сетовать, что университет плохо обучает тем самым ремесленным технологиям и инструментам: университет по определению предназначен для тех, кто метит на более высокий уровень абстракции (кстати, ПТУшное или техникумовское образование до поступления в университет очень даже полезно, сравнить с системой подготовки офицеров в 3-м Рейхе).
- Тот, кто ограничен конкретно-ремесленным уровнем восприятия проблем, обречен решать одну, другую, третью задачи в розницу. Тот, кто владеет абстрактным мышлением, сможет со своего уровня не увидеть разницы между этими тремя задачами и решить их оптом. Кстати, это не отменяет того факта, что ремесленные решения могут оказаться шедевральными, филигранно проработанными, более компактными (в 90-х в каком-то журнале публиковалась программа в машинных кодах: строит на экране фрактал и занимает менее 100 байт). Но это будут именно решения ad hoc. А в современном программировании далеко положишь -- близко возьмешь (скрипты, промежуточные языки, конфигурационные файлы -- там, где можно было все это жестко замуровать в исходник программы).
- тот, кто ограничивает себя ремесленным уровнем, сможет в будущем -- максимум -- успешно продать себя работодателю (что, кстати, вовсе не плохо и не так мало). А тот, кто, благодаря фундаментальному академическому образованию, в ущерб некоторой технической виртуозности, обладает целостным вИдением мироздания, способен осознанно преобразовывать мир вокруг себя. Каждый решает для себя, какой из двух путей выбрать.
- То же самое, но другими словами. Одно дело успешно решать задачи. Другое -- задачи ставить. Для первого широта кругозора желательна, для второго обязательна.

[vp.livejournal.com]

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