О, хорошая идея. Пойду вечером на Барстрит.

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

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

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

Когда стану непригодным для девелопмента пойду в ВУЗ преподавать. А там и сказке конец.

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

Всё ж носит вероятностный характер. У каждого параметра есть своя степень доверия.

Уверен. Я не пью, не курю и спортом занимаюсь. Мертвечиной не питаюсь. Живу в селе. Поэтому выгляжу моложе.

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

Если архитектор понимает как сделать, а объяснить разработчиками не может, то какая от него польза?

Тогда все, кто работает в NASA сумасшедшие. Если посмотреть на их ЗП, то в Америке этого хватит только на довольно скромную жизнь.

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

UML диаграммы уровня архитектуры поддерживаем, поскольку они нужны всегда.

Может быть. Преподавание и борьба с производственными реалиями в высококонкурентной отрасли — это разные вещи.

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

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

И вспоминать старый добрый ассемблер с его INT 21h-вым прерыванием. Можно еще пайкой «Синклеров» заняться.

Всё, понял. Проектирование не нужно. Возвращаемся в средние века.

Только когда с таким опытным человеком начинается работа, и он ваяет нечитаемый код, который перманентно находится на стадии 95%-ной готовности, начинаешь более ответственно относиться к собеседованиям.

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

Дворовой музыкант тоже без нот все песни под гитару лабает. И всё на 3-х аккордах! Попробуйте ему объяснить, зачем в музыке нужны ноты, гаммы и сольфеджио?

На одних парадигмах в ООП далеко не уедешь. Сам ООП не предоставляет программисту никаких преимуществ по умолчанию. Преимущества появляются тогда, когда мы начинаем правильно использовать ООП. А здесь уже начинаются такие моменты как UML, приёмы объектного проектирования и т.п.
Можно всю жизнь вариться в собственном соку, делать фрилансерские поделки-горбулины на 1000...10000 строчек кода. Тогда действительно UML не нужен. Но когда, например, нужно согласовать между участниками проектной команды модель предметной области даже малой сложности, скажем, с десятками взаимодействующих друг с другом бизнес-сущностей, нужен какой-то всем понятный язык проектирования. Т.е. UML.
Если человек никогда не работал с UML, то с высокой степенью вероятности, что он блефует, заявляя в своём резюме серьёзный опыт в OOP/OOD.

Нужно еще учитывать тот факт, что количество опыта еще не значит его качества.

Так же как черчение с машиностроением.

Есть такой дяденька Ален И. Голуб. У него есть книжка «Правила программирования на Си и Си++». Это пример мышления старого поколения программистов.