Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть

Про инженеров и программистов

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

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

В то же время инженер (engineer, вдумайтесь в этимологию) хоть и не знает какой-нибудь Python, но вполне себе программистские (алгоритмические) задачи решает постоянно. Даже такая привычная вещь, как механическая коробка передач современного автомобиля, является воплощением в металле сложного алгоритма. Я уже молчу про АКПП и другие еще более нетривиальные вещи.

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

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

К чему это все? А к тому, что нужно развиваться не только в сторону знания различий ES5 и ES6. Я не буду агитировать за знание искусств или истории, все-таки мы не гуманитарии, но, блин, если у вас в дипломе написано «инженер-программист», нужно хоть немного быть и «инженером», а не только «программистом».

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

программист — это потребитель (да-да, она самая) плодов деятельности инженеров
Абсолютно аналогично, современные инженеры пользуются сложнейшим программным обеспечением для моделирования, расчетов, черчения и т. д. При том, даже самые продвинутые инженеры не обязаны понимать как эти инструменты работают. Например, должен ли архитектор уметь читать исходный код Автокада?
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Помню на первой работе у меня было написано в посаде «инженер-аналитик» :) Фирма занималась ремонтом банкоматов. А в те времена большинство фирм были устроены так, что ты должен был быть и грузчиком, и зав складом и непосредственно прямыми обязаностями типа аналитики. Короче есть заявка — работай. И один раз людей не хватило и я потулит подымать банкомат. Ну короче я его не только не поднял, я еще что то там закоротил и от клавы е**бнуло по мне не хило.
Тогда начальника мне сказал: «Томас, ты настоящий инжИнер. От слова инжир .» :)))

Мне когда -то директор говорил -ты инженер!, а инженер должен уметь-всё!

Ну а че, я видел ИТ вакансии с требованием поднимать тяжести

ну я в переносном смысле «поднимать» — что б он заработал. Может и в вакансии имелось ввиду «поднимать систему в тяжелой ситуации».

нет, было 50 фунтов или около того указано)

«Требуются сильные программисты»?

> Многие из присутствующих, например, без заглядывания в Википедию назовут скорость света в вакууме?

1, Скорость света в вакууме равна 1. Что дальше?

«Человек должен уметь сменить пленку, спланировать вторжение, заколоть свинью, управлять кораблем, спроектировать дом, написать сонет, свести счета, построить стену, вправить кость, утешить умирающего, отдать приказ, выполнить приказ, работать вместе, действовать в одиночку, решить уравнение, проанализировать новую задачу, разбросать навоз, запрограммировать компьютер, приготовить вкусную еду, сражаться, и побеждать, и умереть смертью храбрых.
Специализация — удел насекомых.»

Лажовая цитата. Ты сам-то хотел бы лечиться у того, кто «может вправить кость»? Или чтоб он тебе программировал автопилот или кардиостимулятор?

Как по мне, в этой цитате в каждой строчке сквозит сарказм)

Вообще-то как минимум эта цитата переведена неправильно. «A human being should be able» — это не «должен уметь», а «должен мочь», разный оттенок смысла. «Мочь» не подразумевает качество, а скорее практическую возможность сделать хоть как-то или разобраться, как сделать.

Хотя даже в таком контексте автор кажется мне слишком идеалистом, и я бы не доверял доморощенным программистам, строителям и костоправам.

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

Не могу не выразить своё мнение:
Программист должен быть инженером в первую очередь!

Иначе его работа — сферическая в вакууме.

Ну есть ещё кодеры, которые делают всё только по точному указанию.
Но у них должна быть цель вырасти :)

Кто использует в разработке системный подход, стандарты ISO/IEC и т.д. -это инженеры. Кто просто кодит -не инженер.

Интересно, какие

стандарты ISO/IEC
использовал Сайрус Смит? До возникновения ISO и инженеров-то не было, получается?

Первым учебником по инженерному делу можно считать выпущенный в 1729 году учебник для военных инженеров «Наука инженерного дела» француза Бернара Фореста де Белидора.
Если Сайрус Смит его читал -значит он -инженер!)

Инженерия причем!) раньше действительно не было единых стандартов -теперь есть.
Чтобы было понятно- я не считаю, что программист должен знать в совершенстве радиоэлектронику или устройство холодильника.
Сейчас не средние века, один человек не может все в голове охватить..
Но в своей работе он должен применять инженерный подход, чтобы считаться инженером.
Программная инженерия (англ. software engineering) — приложение систематического, дисциплинированного, измеримого подхода к развитию, функционированию и сопровождению программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению (ISO/IEC/IEEE 24765-2010)
ru.wikipedia.org/...iki/Программная_инженерия
Также не нужно забывать про системную инженерию:
ru.wikipedia.org/wiki/Системная_инженерия

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

Вуз виноват не в том, что они становятся кодерами, а в том, что они после вуза даже на кодеров не тянут. А должны бы — на инженеров.

Хиба виші винуваті що студенти дуркуваті?

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

Каждый инжинер программист, но не каждый программист инженер :)

то есть по вашему инженер-геодезист является программистом?
улыбнули спасибо, люблю чушь

Это была шутка, если что :)

кажется мне пора идти в отпуск

Делите людей на тупых и умных. Зачем эти заморочки с инженерами и программистами.

Где заканчивается умный и начинается тупой? Определение в студию.

Если такой вопрос возникает у кого-то, он во второй рубрике (не соображает как отличить тупого от умного)

А вы, вероятно, к умным себя относите? Потому как, судя по последнему вашему комментарию, я бы с вами не согласился.

Пытались мерять универской корочкой — неполучись
Пытались мерять зарплатой — несрослось.
Пытались мерять лычкой — тоже неудача.
Зато на форуме можна всегда срачик развести.

Этот топик можно переименовывать в «Бомбеж инженеров». Инженеры, идите инженирируйте что то, хватит сидеть на форумах.

Оце так зашквар... Додам лайна на вентилятор!
Інженер — це лошпєт у порівнянні із програмістом (не плутати із кодером). Бо програмісту зазвичай необхідно вивчити матчастину і інженера, і керівника, і економіста, і медика, і астронома із агрономом, і навіть бабці, що сидить на лавочці. Бо така в нього важка доля, вивчати те, що він автоматизує...

Есть авторы статей на ДОУ, а есть тролли. И если кто-то думает, что это одно и то же, то в данном частном случае будет прав.

Юра Паламарчук был совершенно на другом уровне

Он, вроде, пропал куда-то. Или нет?

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

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

типичный программист понятия не имеет о том, как функционирует не то что двигатель его автомобиля, но даже компьютер, за которым он работает.
Типичному программисту (не кодеру!) главное понимать окружение и термины той задачи, для которой он пишет ПО. А окружение это может быть очень разным: банковская сфера, медицина, спутники и т.д. И для каждой из этих сфер программист должен иметь весьма и весьма специфические знания. Согласитесь, программисту банковской сферы совсем необязательно знать скорость света в вакууме, хотя программисту спутника такое знание в подсознании уже зашито...
Да, существует масса инженеров и программистов в одном флаконе, но таких с годами почему-то все меньше и меньше.
А почему так? Ответ ведь на поверхности: не нужен такой специалист Заказчику. Узкоспециализированного им подавай...
И результат этого мы постоянно наблюдаем в виде производственных фейлов
Знаете, мне смешно, когда результат подобных фэйлов списывают на «ошибку программиста». Извините, если при запуске космического аппарата ПО не прогнали «в хвост и в гриву» через автотесты и разного рода симуляторы, а запустили как есть, в надежде на то, что «программист не ошибается» — то и видим падающие ракеты, сходящие с орбиты спутники и т.д. Производственный косяк — это косяк всего ПРОЦЕССА, а не только программиста...
А к тому, что нужно развиваться не только в сторону знания различий ES5 и ES6.
Согласен. Но более разумно развиваться в своей области + смежных областях, а не вообще. Если ты не занимаешься разработкой ПО в сфере авиации , то тебе совсем необязательно знать принцип работы турбореактивного двигателя. Почему так? Отвечу цитатой известного литературного персонажа, который был одним из лучших специалистов В СВОЕМ деле:

Шерлок Холмс: Коперник? Знакомая фамилия. Что он сделал?
Доктор Ватсон: Боже мой, так ведь это же он открыл, что Земля вращается вокруг Солнца! Или этот факт вам тоже неизвестен?
Шерлок Холмс: Но мои глаза говорят мне, что, скорее, Солнце вращается вокруг Земли. Впрочем, может быть, он и прав, ваш... как его — Коперник.
Доктор Ватсон: Простите меня, Холмс... Вы человек острого ума, это сразу видно! Вы превосходно знаете химию... Как же Вы не знаете... вещей, которые известны каждому школьнику?!
Шерлок Холмс: Ну, когда я был школьником, я это знал, а потом основательно забыл.
Доктор Ватсон: Вы что, хвастаетесь своим невежеством?!
Шерлок Холмс: А Вы, Ватсон, можете отличить грязь на Ридженс-стрит от грязи на Пиккадилли? Или пепел гаванской сигары от пепла манильской? Или можете мне сказать, что написано в третьем параграфе «Уложения о наказаниях Британской империи»? Можете?
Доктор Ватсон: Но ведь я говорю об элементарных вещах, которые знает каждый!
Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает: тащит туда нужное и ненужное. И наконец наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что её не достанешь. Я делаю по-другому. В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой. А лишнего хлама мне не нужно.
Доктор Ватсон: Учение... Коперника... по-Вашему, хлам?!
Шерлок Холмс: Хорошо. Допустим, Земля вращается вокруг Солнца.
Доктор Ватсон: То есть... то есть... ка́к — допустим?!
Шерлок Холмс: Земля вращается вокруг Солнца. Но мне в моём деле это не пригодится!

Печально не то, что программисты не знают принцип работы реактивного двигателя. Печально то, что они не понимают даже того что программируют. Это как разница между знанием и пониманием. Можно знать язык программирования, но не понимать к чему приведет та или иная конструкция. И вот тут начинаются критические проблемы. Если бы вы были программистом, то знали, что автотесты ничего не решают. Потому что они соответствуют математической модели. А реальность для того и реальность, что модель ей соответствует только в определенный пределах ис определенной точностью. Выйдет ли эта модель за пределы истинности зависит от понимания а не от знания языка. Сейчас эра фичешистов. Они знают все особенности конкретного языка, но программируют такую хрень... от непонимания принципов работы вычислительной техники. Шерлок Холмс в данном случае лишь подтверждение сказанного мною.

И вот тут начинаются критические проблемы.
Хорошо, давайте рассмотрим критичность этих проблем детальнее...
что автотесты ничего не решают
Хорошо, допустим, что автотесты ничего не решают. Исключаем их из рабочего процесса, нечего заморачиваться и тратить x2 времени на эту бесполезную ничего не решающую затею.
модель ей соответствует только в определенный пределах ис определенной точностью.
Так а кто же спорит? Совершенно верно. И чем конкретнее, понятнее будут описаны эти пределы и допустимая точность, тем точнее будет реализация ПО для обеспечения функционирования этой модели.
Выйдет ли эта модель за пределы истинности зависит от понимания
Так я с этим и не спорю. Шерлоку тоже необходимо было глубинное понимание сыскной деятельности и смежных с этим сфер. Но совсем бесполезным и даже вредным (с его точки зрения) было понимание принципов существования Солнечной Системы. Они им ни в каком виде не применялись...
Если бы вы были программистом
Не обижайтесь, но сразу видно «инженера-теоретика». И снова отвечу Вам цитатой, но уже ближе к нашей, программистской теме. Автора и название книги давать не буду, это Библия программиста-практика:

Интеллект не кажется чертой характера и на самом деле не является им. Высочайший уровень интеллекта — далеко не главное условие для человека, желающего стать хорошим программистом, Что? Для этого не НУЖНО быть суперинтеллектуальным?
Нет, не нужно. Никто не обладает достаточным для программирования уровнем интеллекта. Чтобы полностью охватить и понять сразу все детали даже средней программы, человек должен был бы обладать почти неограниченными возможностями. Способ использования интеллекта важнее, чем его уровень...

Большинство аспектов программирования являет собой попытки компенсации строго ограниченных способностей разума. Самые лучшие программисты — те, кто понимают, насколько ограничены их возможности. Они скромны. Худшие программисты отказываются признать, что их способности не соответствуют задаче. Характер не позволяет им стать отличными программистами. Чем усерднее вы работаете над компенсацией ограниченных возможностей своего разума, тем лучше будете программировать. Быстрота вашего развития напрямую зависит от вашей скромности...

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

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

принципов существования Солнечной Системы.
Просто у Конан Дойла не хватило мозгов придумать случай, когда эти принципы Шерлоку бы понадобились.

Автору «Затерянного мира» не было проблем такое придумать. Но он, в отличие от вас, понимал законы жанра.

"

Библия программиста-практика
" эту «библию» написал какой-нибудь бывший сантехник. Для таких же сантехников-"программистов«. Слишком много факторов необходимо учесть для хорошей программы. Так что выбросьте эту «Переписку Каутского с Энгельсом» о том как все просто поделить.

Это все равно как «любая кухарка может управлять страной».

эту «библию» написал какой-нибудь бывший сантехник
Эх, поизмельчал нынче наш брат-программист. Если для Вас Стив МакКоннелл является «бывшим сантехником», то спорить не буду. Даже не удивлюсь, если Вы не знаете, кто это...

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

Вы еще Билла Гейтса программистом объявите. Какую известную программу этот человек написал, прежде чем писать книги? Как Билл Гейтс, несколько строк на бейсике?

Билл не то что несколько строк -он свою версию интерпретатора Бейсика разработал с другом..И самую первую игру для IBM PC..

Кстати первичное образование у него — философ. Так что к программированию у него такое же отношение как и у сантехника. Так что я почти угадал.

Википедия вещь полезная, но лучше не палиться.

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

По поводу сантехника давайте обратимся в анг версию вики:

“a master’s degree in software engineering from Seattle University”. У вас там какая корочка, простите? Государственный университет села Берізки? Дальше читаем:

“He then pursued a career in the desktop software industry, working at Microsoft, Boeing, the Russell Investment Group and several other Seattle area firms. At Microsoft, McConnell worked on TrueType as part of Windows 3.1. At Boeing, he worked on a Strategic Defense Initiative project.”

Я не буду вас спрашивать где вы работали чтобы было сопоставимо с майкрософтами и боингами.

П.С. говорить что человек не относится к разработке ПО на основании его прошлой корочки с другой области — очень умно.

Гейтс тоже «основатель» компании и поэтому он у вас программист? Здесь как в форексе. Те кто умеет работать, не будет терять время на написание книг. А тот кто стал банкротом вдруг берутся учить других и становятся «консультантами». Для того чтобы передать опыт надо его иметь. А потратить 5 лет на философию вместо программирования сразу снижает объем опыта в программировании из-за элементарных потерь времени. Моя «корочка» это ДПИ, факультет Вычислительной техники, специальность «Вычислительные машины, компьютеры, системы и сети». Работал по специальности более 20 лет, без перерыва на философию. Что касается его книги — там чисто философские рассуждения на околонаучные темы. Подход к программированию через пятую точку. Многие вещи искажены. Местами глупости написаны... Но для сантехников самое то. Потому как элементарные вещи преподаются в вузе а не читаются в книге не понятно кого.

Что касается его книги — там чисто философские рассуждения на околонаучные темы.
Давайте спорить о вкусе устриц с теми, кто их ел :-)

Это не устрицы :) Когда книги занята всякими «метафорами» и прочей ерундой, то это книга для кого угодно, только не для инженера.

Ну, вам виднее. А то что его в мире книг по ПО считают одним из лидеров то такое. Куда ему тупому сантехнику до выпускника ынжынерии. Вы бы однозачно написали лучше. Надеюсь скоро напишите и поделитесь своим огромным правильным опытом, а не его философскими бреднями.

Это не устрицы :) Когда книги занята всякими «метафорами» и прочей ерундой, то это книга для кого угодно, только не для инженера.
— «не читал, но осуждаю»

Кстати, если вам интересно читать только «по сути», то берите туториалы, документацию. Вы видимо еще не доросли до проектирования ПО, до этой всей «фигни». Вообщем оставайтесь код манки, не читайте ту философщину для неинжынеров. Удачи.

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

Вы пишете компиляторы?)) Давайте так — вы нам опишите что вы программируете и потом поговорим. Если вы ничего толком не писали то закроем тему. Меня интересуют проекты на высокоуровневых языках где уже важны все эти знания по архитектуре приложений. Опыт написания драйвера не катит.

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

Я так понял аргументы у вас закончились, решили перейти на личности? Ну ок. Когда то давно я писал, и поддерживал несколько лет, программу тарификации ( расчет стоимости или биллинговая система) телефонных разговоров клиентов Укртелекома Донецкой области (C/C++, Java). Это несколько миллионов записей в различных форматах в сутки. Без оракла, на машинах с 486 процессором. Также разрабатывал модифицировал исходные тексты TACACS+ для модемного пула Cisco для учета статистики/тарификации предоставленного доступа интернет.. и еще много чего, сюда не влезет весь текст.. Сейчас я пишу программы для семейства ARM Cortex. Достаточно?

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

Ну если для вас несколько миллионов строк данных в сутки и куча справочников — это легкое приложение, тогда почему вы тут околачиваетесь а не оракл дрессируете?

Откуда ж мы знаем, что вы там с этими миллионами строк делали. Может просто в /dev/null спускали

И часто ваши биллинговые системы в dev/null деньги пускают? И налоговая вам ничего не говорит? Про льготы ветеранам. льготные тарифы на праздники, в соседние зоны, на платные линии, на бесплатные, мобильный трафик, время звонка, дальность связи, междугородние, международные, местные ... округление, выдача счетов, работа с клиентами в абонотделах, выставление счетов, переназначение звонков...

Билингом не увлекаюсь. Поток данных может быть большой но и обработка их может быть простая и в архив. Количество записей само по себе ещё ни о чем не говорит. Тем более что в укртелекоме и налоговых работа через одно место — скорее правило, чем исключение.

Я застал еще ЕС и прошел по сути всю историю программирования. Процесс формализации (а не «конструирования») задачи был ВСЕГДА. Вся разработка всегда основывалась на обработке входных данных и получение выходных. От типа входных данных выбиралась модель обработки. А не как в книге, «может так а может иначе. 30% решают так а 70% иначе и фиг его знает как надо»... Откуда выбраны финансовые показатели, приведенные в книге? С потолка? Почему они решили что их статистика отражает успешность проектов а не коррелирует с тупостью разработчиков? Подчеркиваю еще раз. Инженер оперирует формулами, математическими показателями... В книге НИКАКИХ математических показателей нет.

А я еще раз подчеркну что книга о проектировании ПО, а не туториал по чему то. Там не должно быть математических формул :) Там разбирается не как написать ПО, а как написать его хорошо.

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

Написание хороших программ это не математика, это не формулы. Это набор логических обоснований и правил, основанных на ОПЫТЕ в большей мере, что собственно и описывается в таких книгах. Как написать правильное приложение — такое математикой не опишешь.

Это математика, формулы, теории графов, системы диагностики..... Сейчас новых языков как мусора на свалке. И в качестве обоснований их применения слышно только что это «круто». Или что это короче в тексте, продуктивнее...так говорили про UML, так говорят все. Это всего лишь реклама. Все это уйдет на свалку.

Вы пишете ерунду.

Нет, вы.

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

Проблема в том, что
1) математическое подтверждение часто необходимо, но никак не достаточно
2) часто оно и не необходимо, когда нет критического ресурса.

В качестве примера к первому: старый Фортран — это всё математика, так? Но то, из-за чего его официально обвинили в гибели венерианской миссии и стали срочно разрабатывать требования к замене — было связано с совершенно не математическими свойствами, а именно — объявлениями переменной по использованию и грамматикой, не опирающейся на лексический анализ.
Этот стиль грамматики хорошо проработан математически; он не соответствует тем LL(1), LALR(1) и прочим, что учат в вузах, но он тоже проработан. Проблема в том, что он тяжело конфликтует с чисто эмпирическим гуманитарным аспектом: где именно ошибаются люди.

И точно так же C vs. Java — вторая может быть сколь угодно неправильна с вашей точки зрения, но само по себе устранение самого тяжёлого класса ошибок — порчи памяти, неизбежных в больших проектах — достаточно, чтобы стерпеть потерю времени и памяти для большинства задач. Вы говорили, что использовали яву; и вы не понимаете, что причина её использования вроде бы явно противоречит обычной математике оценки эффективности реализации?

И я повторюсь — книги по апи и книги по проектированию ПО это совершенно разные вещи. Хотя код манки конечно хватит и знаний по апи/документации.

Математическое основание по вашему апи? Проектирование ПО обязано иметь математическую основу. В противном случае есть большой риск невозможности решения поставленной задачи и краха проекта (что и происходит все чаще по причине пренебрежения математическим обоснованиям).

Проектирование ПО обязано иметь математическую основу.

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

То что происходит там сейчас, я не могу сказать. Как только появились гуманитарные, ментальные, идеологические и прочие факторы, влияющие на принятие решений при программировании, мои разработки прекратились в том сегменте. Доказывать им что либо бесполезно. Для них существуют только одно доказательство — их банкротство. А после банкротства нет смысла их поднимать.

Очень много кто сыграл в ящик за это время. Тот же Rational Rose, Sun, Borland ... перечислять можно очень долго. И ВСЕ утверждали что они самые правильные программисты.

Sun и Borland померли из-за тупых маркетологов. Софт у них как раз был отличный, в случае Sun весь мир до сих пор пользуется.

У Borland’а були проблеми із компілятором. Він був гіршим за майкрософтівський та навіть інтелівський. Ось і померла тваринка.

У Borland’а були проблеми із компілятором.
Зато у него была Дельфи, на которой в свое время программили практически все (ну — некоторые еще на Гупте).
Проблема, судя по всему, была в том, что они остановились в развитии и успокоились. В итоге поезд ушел дальше, а достаточных ресурсов на то, чтобы его догнать, уже не было.
Сугубое имхо, конечно.

Так этоже и интернет експлорер постигло, да другие проекты тоже, когда останавливается развитие это момент начала умирания

Так этоже и интернет експлорер постигло
Да, но у MS есть практически бесконечные ресурсы, чтобы его переделывать (и переименовывать, да).
А вот у Borland, Digital, Sun, Micrografx etc. их не было. Зато хватало сомнительного менеджмента, похоже.

Делфі розчавив Майкрософт своїми готовими компонентами. У Борланда з ними була вельми велика проблема. Або безкоштовні й кострубаті, або платні. В віжуал студії вони йшли з коробки. Переможець, сподіваюся, наявний.

Вначале компилятор был не хуже. Они потом начали отставать. Дальше Т.Т. уже сказал.

Между прочим, мне с месяц назад приходил оффер на какое-то участие в развитии RAD Studio. Так что жив курилка...

Вот я не представляю как бы вы например писали мобайл апп с таким подходом к вещам) А там ведь не только книжки по проектированию кода надо читать, а еще по юзер интерфейсу, как правильно отображать, как правильно должны функционаровать элементы уи, да даже правильные цвета нужно девелоперу знать) Пришлось бы изучать кучу информации «от сантехников» :)

А почему вы решили что я не писал мобильных приложений? Под Symbian писал. Когда пошла политика ограничения программистов сертификатами я сразу сменил поле деятельности. Nokia через небольшое время стало банкротом. Наверное вы считаете свою Java лучший системой разработки? Огорчу вас. Это труп в ближайшей перспективе.

Угадайте :) Математика, булева алгебра, ассемблер, С...С++ подает признаки шизофрении. Не может определиться, то ли строгая типизация как раньше или auto параметры (то ли к мудрым, то ли к красивым). Фичешисты не понимают, что лок для инкремента одной переменной стоит очень дорого. Потому что после лока придется ждать анлок из другой нити, которая в процессоре восстановится через тысяци переключений контекста в операционной системе. Java тупит с выделением памяти и в других местах при мультиядерной обработке...

І багато ви бачили ентерпрайз-рішень, написаних на асемблері?

У меня был выбор. Или действовать по идиотским правилам и принципам, или уйти в ассемблер и С. Я выбрал второе. А на «энтерпрайз» я насмотрелся. От программ, которые суточный объем рассчитывали двое суток, до разрушившихся от избыточной сложности. Да и «лидеры» рынка местами такую ерунду толкали...

Отже, можна сказати, що не бачили. А чому? Так ж цікава мова... Лаконічна, проста, швидка...
Ви вважаєте, що ви б самотужки написали краще? А за скільки десятиріч?

Насколько я помню, энтерпрайз это уровень предприятия. Укртелеком это уровень выше, корпоративный. И оракл и m$ доросли до уровня предприятий, не выше. Ну или как там у них сейчас с названиями :)

Кожен кулік своє болото вихваляє?

В случае с ораклом и m$ не то что «вихваляє». Местами намеренно лжет и запрещает окружающим писать правду под угрозой суда.

Ну то й що? Подайте на них в суд та виграйте!

Язык «C» еще называют высокоуровневым ассемблером. На нем написаны почти все операционные системы и базы данных...

Мне кажется вам по духу очень должен подойти Go

Мне не надо «по духу». «По духу» я уже проходил и не раз. Мне надо обоснованное применение.

Да шо ви кажете! Ви серйозно? Ось так прямо всі операційні системи? Вау! Круто! А на чому написана Windows?

И на чем? Назовите этот «идеальный» язык программирования :)

то ли строгая типизация как раньше или auto параметры

В C++ вообще-то auto не мешает строгой типизации, это не void*, а просто вывод типов компилятором.

Ну и как вы себе представляете поиски возможной ошибки, в случае если во всем коде поставить auto? Это не почти тоже самое ?

Точно также, как и без auto. Я его чаще пишу, когда мне лень писать длинные строки шаблонных типов, компилятор сам подставит.

Ну вот и представьте себе, что будет если код пишет толпа программистов. При этом все они предполагают различные типы данных. Каков будет результат?

При этом все они предполагают различные типы данных

Значит, обломится там, где вызов функции/метода с аргументом одного типа на самом деле предполагает другой тип, и выльется в ошибку компилятора. В чём проблема-то?

Почему на этапе компилятора? Ошибка и у клиента может выползти. Когда причинит ему убытки из за переполнения.

Потому что правила преобразования типов в С++ очень жесткие.

Неправда. Там остались неявные преобразования типов.

Их немного, и у тех, кто програмит на плюсах или С они уже в подкорку вбиты. Классическое преобразование int в double :).
Но к auto это отношения не имеет.

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

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

Просто программист с и с++ пишет код, учитывая эти нюансы.
Ну и тебе вопрос, что произойдет при преобразовании int в double?
В зависимости от твоего ответа будет видно насколько ты толстый тролль.

Вот я поражаюсь местному «бомонду». Прям как у Филатова. «Ну и ушлый вы народ —
Ажно оторопь берет!
Всяк другого мнит уродом,
Несмотря, что сам урод.»

ПС: особенно меня насмешило про «немного». В двоичной системе, где только да или нет у вас новое состояние «немного» :)

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

Компилятор по рукам надает. Это с++, я не какой-то скриптовый язык с их странными автоматическими преобразованиями.

Тю, люди и без auto умудряются делать логические ошибки типа операций с unsigned int переменной и сравнению её на предмет < 0 при обратном цикле. Чинится только статическим анализатором кода.

А если будет auto ваш анализатор найдет проблему без анализа? И найдет ли вообще?

Вы еще не написали что я не программист. Или что никогда не писал энтерпрайз приложений. Вот поэтому я и ушел из этой области. Рад за вас, что вы хорошо «знаете» auto.

Вы определённо программист, и даже с опытом — что не мешает вам не знать, как работает auto в C++, и быть активным невежей в этой области.

Найдёт. С уважением, кэп.

С++ подает признаки шизофрении. Не может определиться, то ли строгая типизация как раньше или auto параметры (то ли к мудрым, то ли к красивым).

Она строгая. Но её не обязательно явно называть :)

Вот например, когда вы пишете x = a*b+c, вы же не описываете явно тип a*b? Оно само вычисляет. И вы с этим согласны, кроме случаев, когда надо явно сузить тип, и то не будете заводить переменную под это.

auto из C++ - просто вынос этой концепции за пределы внутренностей одного выражения.

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

Ну так atomic ops уже поддерживаются чуть менее чем везде, с тех пор, как многонитевость стала не только для суперизбранных. И как не лочить лишний раз — тоже тысячи книжек рассказывают. И про false sharing, и другие хитрости. Только вы пытаетесь представить это как супернауку, доступную только сишникам...

Java тупит с выделением памяти

Именно выделением? Или словом «тупит» назван факт использования GC?

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

Спасибо, господа, я накушался. Да здравствует анархия!

(а задроты-девелоперы все равно такие смешные несмышленыши, что аж жалко болезных)

P.P.S. 25k, ребята, просто 25k в последнем месяце. А вы гребите. Может догребете куда-нибудь :)

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

Так ни для кого не секрет, что джаваскрипт — язык, но не программирования.

Ну вы ведь как разностороний человек, который наверняка основы статистики знает, должны понимать, что ваш единичный пример — маловато. Обратных догадываетесь сколько? Сам один знаю, как раз человек инженер хороший. Ну и реально не видно, как общие знания совершенно не в профильной области помогут баблу. Вы хоть пример приведите, типа вот на работе пригодилось внезапно такое моё знание. Т.к. приведённые вами примеры —

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

Насчет ппс, у вас зп 25к баксов? Или заказ на такую сумму во фрилансе выполнили? Если 2ое то не впечатлили

25k
25k чего ? Долларов, гривен, посещений вашего блога на вордпрессе? Урон в секунду по врагам в варкрафте? Площадь кв.м. вашего огорода в селе в Винницкой области?
Укажите явно.

Как говорил один мой преподаватель (КПИ, ФИВТ, АУТС): раньше наши студенты разные схемы паяли, а сейчас даже не знают, с какой стороны паяльник брать.

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

Вы шо, это же архиважно для проектирование хайлоад базы данных знать что такое канифоль, и быть в курсе как протекает процесс паяния с технической точки зрения

Можна і без пайки. Наприклад розробка якої небудь інфрмаційної панелі, з програмуванням контролера, записом на flash карту бази даних, і відображенням інформації на tft дисплеї.

А вы ещё не в курсе, что новые поколения TFT дисплеев будут управляться через SQL?

На тот момент на нашей кафедре вовсю учили двигатели, микроконтроллеры, реле, ... На лабораторных собирали на «бредборде» декодер кода Грея, меряли ВАХ светодиодиков. Как сейчас помню курсач по активному НЧ/ВЧ фильтру на операционном усилителе. При этом из-за какой-то несогласованности моя группа так и не имела лекций по SQL!

Главное в инженере — кругозор, логика и самообучение.

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

Так какие же они тогда инженеры без паяльника и синей изоленты? :-D

але паяльник все ще потрібен для «просунутого» крипто-аналізу

Можна скористатися breadboard.

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

Да, всё ок. Но если хочешь создать что-то новое, вне ежедневной рутины? Модное слово — стартап! Потребуются знания из смежных областей, хотя бы понимание общих принципов и закономерностей. Но это не нужно 99% кодеров.

Простой пример. Когда USB была не сильно популярна в МК, а для дешёвого и быстрого ввода/вывода данных использовали LPT (принтеры, сканеры и проч.), мы сделали свой девайс на коленке для ввода изохронного потока и упёрлись в потолок по скорости ввода информации в компьютер. Другие смогли выжать больше, причём на том же простейшем режиме работы порта, но как и почему? Обладая общими знаниями, я ответил на этот вопрос за пять минут, фикс был программный на стороне микроконтроллера. Даже просто угадать ответ несложно полным перебором, но, как вы думаете, чего не хватало и почему?

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

Ылита, началась делится на тру инженеров ылиту и не тру инженеров ылиту

Та деление в головах уже давно.
Чувачки просидевшие года в универе, зубрящие, работающие и пилящие проджекты за миску риса, всегда батхертят, когда видят смышленых новичков, которые обладая 0 опыта и знаниями уровня табуретки сходу подымают зп больше чем «отцы». Всегда это было, всегда это будет.

В умении хорошо продавать свои знания нет ничего плохого. Другое дело что у нас страна ресурсная, а фрилансить/аутсорсить научному работнику нельзя :(

фрилансить/аутсорсить научному работнику нельзя
Почему? Что мешает?

Выглядит как очередной батхерт по поводу зарплат у эмбедерров.

Не понимаю что ТСу не нравится. Программисты знают ровно столько сколько нужно для бизнеса. А разговоры кто что должен(кому?) — это какой то совок.

хоть вы его и не понимаете, но он вам не нравится.

Наче так багато фрілансу пов’язано з розрахунками реактивних двигунів, або виготовленням якихось рідких хімічних елементів, розробки програмного забезпечення для колайдерів, виготовленням космічних апаратів, будівництвом кораблів, будівництвом великих споруд, іншого. Але дуже багато пропозицій саме з веб програмування і програмування ігор, де не обов’язково знати швидкість світла і інше, а при потребі все необхідне можна прочитати в підручниках.

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

в реале лучше немного уметь — можно ускорить свою работу. Ну как пример приведу свой — разобравшись в «исходном коде» autodesk maya я смог настроить под себя инструментарий ( marking menu — кто шарит), который в самой майке настроить нельзя. Тока вот нехрен там читать и разбиратся, всё просто, на уровне паскаля. Короче умея немного кодить можно ускорить своё рисование.

Или вот пример Галёнкина — он вроде журналист а немного разобравшись в скриптовании — ускорил свою работу, убрал рутину с неожиданной стороны

Инженер, может и карандашиком на ватмане начертить чертежик....
В универе еще мог, сейчас не уверен. =)

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

Мне кажется вот такая градация уровней более устоявшаяся и логичная
Scripter
Coder
Hacker
Software Developer
Software Engineer
Computer Scientist
Creative coder
habrahabr.ru/post/135865

В статье по ссылке такое разделение описывается не как «градация уровней», а как «независимые группы». И это в корне все меняет.

И что меняет? Надо ли понимать Вас, что "

Software Engineer
" можно стать минуя
Software Developer
? Мое мнение — нельзя.

Это потому что вы наполняете эти слова своим специфическим смыслом. Не надо так.

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

Иначе все скатится к спору «должен ли программист менять картриджи». У слова Hacker, кстати, тоже куча определений, причем чаще всего взаимоисключающих.

На мой взгляд Вы пытаетесь заниматься фантазированием и сами наполняете эти понятия и определния своим видением.

Software Engineer
и
Software Developer
очень часто упоминаются в требованиях к вакансиям и они вполне определены. Вот здесь, например, коротко и просто орписаны различия между ними — www.webopedia.com/.../S/software_engineer.html И не надо ничего придумывать. Но если убрать слово
Software
, тогда да , можно обсуждать до бесконечности.

И кто такие Creative Coder и Hacker?

В США Senior Developer будет иметь в среднем 8+ лет опыта работы в ИТ-индустрии и степень магистра по Computer Science, у нас же это просто лычка за 5-7 лет выслуги.

И как бы часто слова Software Engineer & Software Developer не употреблялись в вакансиях в Украине, они у нас вообще не определены. О чем я вам и пытаюсь сказать.

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

насчет хакер — да, сомнительно как-то.

США Senior Developer будет иметь в среднем 8+ лет опыта работы в ИТ-индустрии и степень магистра по Computer Science,
не увенен в этом ,насчет магитсра. Бакалавра вполне хватит. И то, это для инжененра.
By U.S. law no person may use the title “engineer” (of any type) unless the person holds a professional engineering license from a state licensing board and are in good standing. A software engineer is also held accountable to a specific code of ethics.
Т.е. для кодера наличие диплома может и вообще не надо.

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

Треш. Программист — априори инженер, потому что программист — это тот, кто пишет алгоритмы. А кодер эти алгоритмы кодирует в ЯП. А вопрос в том, что практически все современные программисты кодируют свои алгоритмы сами — уже совершенно другой.

Далее: есть инженеры-программисты, а есть инженеры-холодильщики. Инженеру-программисту не обязательно знать всё, что знает инженер-холодильщик для того, чтобы считаться инженером. Точно также как переводчику с китайского не обязательно знать английский, чтобы считаться переводчиком.

В итоге: То что вы пытались выразить в статье: не нужно зацикливаться на своей профессии, нужно стараться обладать понемногу общими знаниями и знаниями из дпугих инженерных сфер. Идея светлая. Исполнение — полный фейл.

Инженер-конструктор всегда может и сам запрогать устройство. Но инженер-программист вряд ли сможет сам его спроектировать =)

Все не так! конструкторы пишут страшный код, а программисты делают железки из ардуин и 3д-принтеров :D

А как на счет чего-то серьезного?))

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

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

Погоджуся тільки щодо виробу типу «сферичний кінь у вакуумній упаковці».

Кажется, статья не о том, кто что может, правда? Статья о том, кто инженер, а кто нет

Здається, автор погано розуміє хто такі інженери, тому вважає, що програміст не інженер. Або п’яний. Інших пояснень цьому дампу свідомості я надати не можу.

Если кто-то думает, что это одни и те же люди, то он сильно ошибается.
Если кто-то думает, что эти люди разные — он ошибаецца как минимум не меньше :8)
...программист — это потребитель (да-да, она самая) плодов деятельности инженеров. Как показала практика, типичный программист понятия не имеет о том, как функционирует не то что двигатель его автомобиля, но даже компьютер, за которым он работает.
М-да ... не хочется спорить по поводу дефиниций что такое «знает как функционирует». Отвечу так: по сопсному опыту знаю, что типичный инженер-конструктор понятия не имеет, насколько легко (или вообще возможно) изготовить придуманную им гениальную деталь, которая одновременно уменьшает потребление бензина двигателем его автомобиля и потребление эл.-энергии его компутером :) Он пользуется расчетами в т.ч. инженера-программиста, а ответ на вопрос вышее даст ему инженер-технолог. Т.е. единственно в чем прав автор статьи, это в выводе :) см. пост нижее.

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

Конечно :) ... но заметьте, между «обязан понимать» и «на самом деле понимает» — дистанция огромного размера, не правда ли? Во-вторых, в моей практике за нетехнологичность изготовления ЭЛТ лишали премии в первую очередь технолога, а уже потом конструктора. В-третьих, как на меня, программер тоже обязан понимать, что происходит на уровне железа, BIOS и ОСьки, когда он нажимает красную кнопку на своем компе; и ситуация тут на самом деле примерно такая же, как в случае понимания конструктором требований изготовителя... но при чем тут слово «инженер» !?
Вы сопсно подтверждаете : давно настало время узкоспециализированных спецов, и если Вам одному удается совместить технологичность изготовления и конкретные ТЗ к изделию, то остается еще дизайн, размер, вес, стоимость («заменить серебро на люминий»), упаковка, реклама и маркетинг ... что является предметом заботы других инженеров.

Отвечу так: по сопсному опыту знаю, что типичный инженер-конструктор понятия не имеет, насколько легко (или вообще возможно) изготовить придуманную им гениальную деталь

Это не типичный инженер-конструктор, это обыкновенный балбес в духе пресловутых «британских ученых».

у меня нету духовной печати :(
и я матерюсь
печаль

не інженер ви , не достойні

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

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

На практике — очень маловероятно, что хороший проектировщик мостов не сможет спроектировать так-себе двигатель.

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

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

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

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

Ниче непонятно. Инженер — это человек который использует научные знания и наблюдения для решения технических проблем. При этом основной вклад: не стучать молотком, а где-то в области принятия технических решений. Если все же переносить это в software(немного спорно, есть неоднозначная история software engineering, да и процессы отличаются от других областей), то получим тоже самое: решение проблем, с использованием знаний в CS, во всяких прикладных штуках типа языков программирования и здравого смысла. Ключевое: решение проблем, если хотите vs. программист, то там ключевое: создание программ, соответственно с упором на те же языки и фреймворки.

Например: пару костылей налету, фиговые, но позволяют зарелизить нужный функционал вовремя — это инженерное решение, написать все правильно, но просрать сроки — программистское.

А вот причем тут скорость света, устройство двигателя или холодильника — не совсем понятно.


А вот причем тут скорость света, устройство двигателя или холодильника — не совсем понятно.
Можно с этим поучаствовать в телепередаче «Весёлый эрудит».

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

Я ещё не описал 42 других способа применения подобным знаниям, а ты уже о месте.. На место будешь ставить свой сервиз в серванте.

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

ИМХО, программист это инженер и есть, а то, что имел автор статьи, это обычный кодер.

Холодильник действительно невозможно собрать без знаний о скорости света? :)
Тем более что первый электрический холодильник собрали в 1913-м, а более-менее точную скорость света узнали в 1947-м.

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

если допустим надо разрабатывать ПО для лаборатории — биологию и химию учить? а для библиотеки — классиков читать (самые известные хотя бы).
а как иначе? менеджеру в ИТ — надо знать ИТ, это ж «отрасль, кардинально от других отличающаяся», а программисту, который порносайт пишет — не надо знать, с какой стороны вставлять?
ПО для лаборатории — биологию и химию учить
Как минимум на школьном или выше придется. Ибо нихрена понимать не будешь, что от тебя хотят.
веб разработчики — им нужно знать, как именно работает турбина?
Этим ничего не нужно. Слепил сайтик кривенько и слава богу.
веб разработчики — им нужно знать, как именно работает турбина?
Надо знать как работает мир вокруг тебя. Хотя бы на уровне «куда не нужно совать руки». Но вопрос не совсем в этом. Как вам web-разработчик, который не знает даже самых основ HTTP-протокола? Я уже молчу про такие тонкие материи как различия между TCP и UDP. И это не ждун-студент, а вполне себе практикующий мидл.
если допустим надо разрабатывать ПО для лаборатории — биологию и химию учить?
Желательно уже знать, учить надо будет ту конкретную область на которой лаборатория специализируется. Потому что иначе вся реальная работа по проектированию ПО ляжет на сотрудников лаборатории, которые продумают что им нужно сейчас, что может понадобиться потом, как это реализовать с прицелом на будущее, и как вывести результаты чтобы ими было удобно пользоваться. Работой программиста в этом случае будет что? Переписать уже продуманную логику и архитектуру на конкретный язык? Не проще ли тогда сотрудникам лаборатории подучить какой-то язык программирования да сделать и эту часть тоже самим?
Желательно уже знать, учить надо будет ту конкретную область на которой лаборатория специализируется.
Нет. Потому как химия и биохимия в частности сами по себе совершенно не маленькие науки и требуют минимум 5-летнего специализированного высшего образования.
Соответственно для стороннего человека нет никаких шансов начать професионально разбираться в предмете за время внедрения проекта.
вся реальная работа по проектированию ПО ляжет на сотрудников лаборатории
Тоже нет. На них ляжет часть работы, связанная непосредственно с особенностями подготовки материала и обработкой результатов работы приборов. Дизайн системы и алгоритмическая же часть ляжет на разработчика.
Не проще ли тогда сотрудникам лаборатории подучить какой-то язык программирования да сделать и эту часть тоже самим?
Нет, не проще. У них другая специальность. И для создания системы нужны и химики и ИТ-шники. Иначе получится фигня.
требуют минимум 5-летнего специализированного высшего образования
С таким подходом учить действительно ничего не стоит ))
С таким подходом учить действительно ничего не стоит ))
Каждый должен заниматься своим делом. Большинство проектов для реального мира делаются командами из специалистов из предметной области и автоматизации процессов.
ЗЫ. С химиками, кстати, еще легко т.к. они тоже технари. Вы врачам что-то попробуйте автоматизировать ;)

А есть еще девелоперы :)
Мы отдельная каста

Юра зажигательнее писал и на эту тему в том числе.

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

В информационный же век они должны знать протокол HTTP, уметь работать с JSON, XML, владеть языками программирования и паттернами проектирования.

В индустриальный век
а двумя эпохами ранее надо было быть физически сильным, даже если ты астроном. иначе — конец.
перемены, перемены...

Так не знают же. Спросите у коллег, что такое ICMP? Или почему через прокси нельзя отправить электронную почту? Или это тоже не нужно настоящему web-программисту?

Или почему через прокси нельзя отправить электронную почту?
Хто вам таке сказав?
Про тунелі вам інженери не розказали?

а вам не розповідали, що проксі не зобов’язаний підтримувати метод CONNECT?

Який проксі? HTTP? SOCKS4? SOCKS5?

Думаю, що ви, як тру-дельфіст знаєте тільки Windows, тому для вас проксі == HTTP

Якщо так, то задача теж не складна — ssh over https, а далі тунелюємо, що хочемо, і CONNECT прекрасно буде працювати.

І так, це не задача програміста, це задача ops/devops.

Покажите мне программиста который ВСЕ знает.

По сути — что надо то и изучается, постепенно, по ходу.

Или почему через прокси нельзя отправить электронную почту?
1. Прописываем прокси в хроме
2. Идем на gmail.com
3. Пишем письмо и отправляем
4. ?????
5. PROFIT!!!

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

Можно подойти к вопросу как юрист и использовать SOCKS-прокси сервер. С ним даже в игрушки шпилить можно через соотв. прокси.

А в процессе настройки сокса внезапно оказывается, что на роутере динамический NAT. ;)

И что? Это ж не FTP в активном режиме.
Update: для игрушек же активный режим бывает нужен.

Гмм, был не прав, притупил. Если сокс на файрволе или вместо оного, то все ок.
Просто вспомнилось (не к месту), как народ пытался пихать соксы на клиенте, имеющем доступ к инету через обычный сквид. )
ЗЫ. Для игрушек обычно лучше простой нат, т.к. оно будет быстрее в подавляющем большинстве случаев + кривая реализация проксей в большинстве из них.

Задача была — отправить электронную почту через прокси. Я написал письмо и нажал кнопку отправить. Вы можете иметь особое мнение, но я считаю, что задачу «отправить электронную почту» я выполнил. Использовал ли я при этом прокси? Да. Так что ваша претензия неуместна.

Кроме того, существуют и SMTP proxy, через которые так же можно отправлять почту.

ТС хотел вы********я, но вместо этого показал себя оленем.

> если у вас в дипломе написано «инженер-программист»
а если у меня написано «инженер-электронщик», что мне делать?

Всегда было интересно, кто такой «инженер-электронщик». Он электронами занимается, типа физик-ядерщик?

Вы термоядерный зануда, ну не электронщик, а электроник, вам легче от этого стало?

Если вы вдруг решите устроиться на вакансия «Петросяна», я готов предоставить вам свои рекомендации.

Вы мне такие гадости пишите. Не будет вам теперь никакой рекомендации!

У меня вообще просто «математик» и никакой не погроммист.

Якщо у дипломі людини написана професія, не означає, що вона нею володіє.

Если вы такие умные, почему вы такие бедные?

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

И да, богатые == умные.
богатые === умные

нифига, богатые и умные это множества которые пересекаются, но далеко не полностью

Читай Библию, там оный вопрос разобран.

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

Кто «мы»? Откуда информация о «наших» доходах? Что это вообще было?

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

Разве кто-то говорил «в одиночку»? Смысл опуса в том, что программисту с инженером поговорить уже не о чем, хотя первый вроде как является более специализированным коллегой второго. И как следствие — страдает качество выпускаемого продукта. Просто из-за незнания основ инженерного подхода.

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

Это если хипстер-пэтэушник, пишущий на чём-то модном
По кандидатам, про которых я уже писал в топике «Я знаю каратэ, кунг-фу и много других страшных слов», сложилось впечатление, что таких 99%.

Про автомобили — достаточно посмотреть разницу количества лет между релизами моделей BMW 5 серии в 80х года и сейчас, потом посмотреть на разницу в начинке и технологическую сложность.
Далее по этому же принципу смотри любой другой продукт.

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

Вы трамваем пользуетесь? А троллейбусом? А они на постоянном или переменном токе работают?

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

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

Википедия расскажет.

Все ясно, великий инженер слился с первого же вопроса, который сам и написал.

«великий инженер» просто не видит смысла объяснять великим погромистам основы термодинамики.

Простите что вмешался, но ответ очевиден же. Смесь воспламеняется потому что на то есть воля божья, все предельно просто !

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

Ты не видишь смысла, потому что твои знания термодинамики аналогичны знаниям «погромистов» о том как удалить i-ный элемент из связанного списка — .remove(int i). Поэтому ничего интересного из твоих объяснений мы все равно для себя не вынесем.

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

А при чём тут то, что она не подаётся, к тому, почему она загорается? :)

а она и не загорается — в дизельном двигателе вообще нет толивовоздушной смеси.

Он на святом эфире работает? :D

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

Не-не-не. Открываем Большой энциклопедический политехнический словарь и читаем:

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

Ну так не томи, расскажи что такое «однородная смесь» и в каких фазах находится топливо и воздух в момент возгорания в дизельном двигателе.

однородная

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

Добро пожаловать в реальный мир ;)
Гугли что такое вихрекамерный впрыск в дизельных двигателях.
Прямой впрыск появился не сразу.

Стыдно ли не знать принцип работы трехфазного трансформатор? Стыдно ли не знать принцы работы ядерного реактора? Стыдно ли не знать принцип работы RGB матрицы? Стыдно ли не знать принцип работы TCP протокола? Стыдно ли не знать принцип работы не симметричных алгоритмов шифрования и алгоритм работы RSA?

Хм... Ничего из вашего примера не является лично для меня «черным ящиком». И транформаторы делать приходилось, и RSA реализовывать, и TCP-обмен глючной железки дампить и разгребать по байту.

А для скольких айтишников, кстати, является открытием, что современный ядерный реактор на любой АЭС — это обычный паровоз, в котором вместо дров «горит» ядерное топливо?

А для скольких айтишников, кстати, является открытием, что современный ядерный реактор на любой АЭС — это обычный паровоз, в котором вместо дров «горит» ядерное топливо?
Думаю для любого технаря закончившего 1 курс вуза это не новость.

Смысл в том что инженер механик не знает как работает его айфон, по крайней мере если и знает то только частично, зачем тогда инженеру проектировавшему, например, материнку айфона или писавшему софт для камеры, знать как работает синхронизаторы каробки передач в его машине который проектировал? Могут ли эти инженеры не считать друг друга инженерами по вашему принципу?

А для скольких айтишников, кстати, является открытием, что современный ядерный реактор на любой АЭС — это обычный паровоз, в котором вместо дров «горит» ядерное топливо?
Школьный курс физики за 9 или 10 объяснял устройство ядерного реактора без идиотских упрощений типа «вместо дров горит ядерное топливо», другое дело что много инженеров на практике реализуют тренд «образование не нужно», побросали школу и пошли клепать говносайтики.
А для скольких айтишников, кстати, является открытием, что современный ядерный реактор на любой АЭС — это обычный паровоз, в котором вместо дров «горит» ядерное топливо?

Я надеюсь, что ни для одного. Потому что, например, КПД атомного реактора типа РБМК это 30-37%, что сравнимо с КПД тепловоза (25-35%), а не паровоза, для которого 15% было рекордным показателем синтетического теста, а в среднем было дай бог чтобы 4%. И такие цифры получены, в частности, благодаря отсутствию внешнего сгорания топлива, которое даёт половину из этой потери энергии. Водяной обмен, конечно, хуже прямого механического привода, но за неимением тахионного реактора приходится пока что использовать ядерный, увы.

Формулировки типа «обычный паровоз» хороши только в курилке и при наличии у всех участников разговора понимания, в чём они некорректны. В остальных же случаях они только сбивают понимание.

мабуть, малося на увазі те, що енергія з атомного реактора просто гріє воду для утворення пару, який крутить турбогенератор.
Схема

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

Вначале она греет расплав в первом контуре. Потом расплав греет второй контур где уже вода.
Так работают ВВЭР

РБМК (как и реактор на пресловутой Фукусиме) — одноконтурный. Там рабочее тело как раз вода из первого контура.

у вас такое оригинальное использование дефиса в последнем слове

У Хайдеггер-а, например, встречается и более оригинальное использование, e.g. «само-по-себе-себя-кажущее».

На ДОУ вот такие еще статьи были:

Почему разработчик — не инженер
dou.ua/...velopment-vs-engineering

Разница между разработчиком и программистом
dou.ua/.../developer-vs-programmer

Ну да, и у обоих Паламарчук автор...

Подписаться на комментарии