Не могу не процитировать

Ссылка

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

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

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

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

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

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

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

C# и namespace

"Не прошло и сто лет", как я обнаружил, что объявлять namespace необязательно - классы объявленные на верхнем уровне в файле, становятся членами namespace по умолчанию. А студия неймспейс генерит автоматом всегда.
Внимание, вопрос - если меня раздражает лишний отступ на namespace и я убрал его объявление - кошерно ли это? Объявления классов стали начинаться от левого края и это немного читабельнее для мозга, но можыд, я тем самым нарушил какие-нибудь тонкие талмудистские запреты и меня ждет кара?

Я точно псих

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

Почему же я псих:
1) Такое ощущение что я повторно изобрел то, что уже есть в SOAP веб-сервисах, т.е. вызов метода по URL. Но их же, суко, wget-ом и curl-ом проверять задолбешься. И вообще чистые url в запросах и плейн-текст в ответах как-то легче для мозга, чем SOAP.
2) Декларативная проверка прав доступа вроде есть в каком-то расширении для WS. Мне в натуре года три назад не хватило мозга это прочесть и осилить, особенно в редакции микрософта. Там просто жопный ад.
3) Кажется, я что-то похожее неделю назад читал в описании spring web framework.

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