Да знаю я это.. Вот только это «читатели — писатели», а не «вброс идеи — обсуждение толпой — реализация», тратить 4 — 6 часов на текст который прочитает 5 человек? Я лучше код буду писать, и на гитхаб выложу. А сказать об этом некуда, или большинство разрабов за пределами офиса о работе не думают? Других объяснений я не вижу)

Ах да, я пишу на Objective-C )

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

Так что Хакатоны остаются чисто индивидуальным видос спорта)

github.com/DAlOG/Morpheus

Comments are welcome)

Мне нравится Ваш ответ. Спасибо за обстоятельность. Видимо я вижу DOD в его крайнем проявлении, а вы OOD в его крайнем. На самом деле мы не слишком далеки от середины. В ООП слишком просто свалится в построение замков, создавая сущности не несущие ничего. Почти половина классов в моих системах инстанциируется в единственном экземпляре. Они вносят свою лепту в преобразование данных. И эта часть системы управляется данными. Но рано или поздно, так или иначе, 2 или более потока данных окажутся «зависимы», то есть семантически связаны. И видимо я не знаю как выразить эту связь в DOD. Смешивать данные и поведение нужно очень аккуратно. В OOD это сделать просто, в DOD — это сложно.

Вы просто не умеете готовить. Я не представляю как писать комплексный проект в команде с использованием DOD. Этот подход гораздо уже чем ООD. Он попросту игнорирует «взаимоотношения» сущностей. Представляя их в функциональном стиле. Такой дизайн годится для линейных, потоковых систем. Увы далеко не все ПО укладывается в эти ограничения.

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

Мне не нравятся компании с программированием в 20%, это не программирование, это выжимание денег из кармана заказчика, под видом «программной инженерии». Так должны писаться программы для NASA и военных, но не прикладной софт. Прикладной софт пишут программисты, а большая структура управления им мешает. Максимальная горизонтальность, минимальное расстояние до пользователей, кроссфункциональность и коллективная ответственность.

У нас с вами разные цели. Это здорово. Надеюсь достижение ваших сделает вас счастливым. Успехов!

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

Ну в общем то вы и не программист в моем понимании) Заработать денег? Вам правда нужно НАСТОЛЬКО высокие зп? Оглянитесь вокруг, люди получают в месяц 1500 и не условных, а украинских, и вынуждены работать то что дают. Они кормят своих детей и близких. Программистам дано право сделать жизнь других людей проще. Своим продуктом именно вы двигаете весь прогресс. А те кто умеет это продавать — продает. Так что не согласен. Что то хорошее сделать можно только забыв о ЗП, благо средний уровень это давно позволяет.

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

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