Не понравилось что атрибут JsonDerivedType навешивается на базовый тип. Информация о наследниках тянется куда не надо, да и сам базовый тип может быть недоступен для модификации
Возможно топовые по размеру зарплаты разработчики просто менее мотивированы узнать «А что там у других?» и не заполняют опросы Хабр Карьеры, либо и вовсе не имеют там профиля)
Впервые увидел этот подход вот тут (ardalis/ApiEndpoints). С одной стороны, возникает бОльшая типизация и разделение вместо микса пачки методов в одном контроллере, а с другой - изобретение велосипеда, который вместо паттерна через пару лет может стать техническим долгом, который непонятно как переводить на рельсы новой версии .NET, и который нужно будет объяснять каждому новому разработчику
«Как делать дела, если их не хочется делать?» — Никак.
Попытки заставить себя тщетны. Другое дело — момент, когда «надо» возьмёт верх над «не хочу». Вот над этим уже можно работать. А если повезёт, какая-нибудь мелочь из общего дела перейдёт в разряд «хочу». Но это уже совсем другая история.
Очень всё строго. Ощущается так, что шаг вправо или влево, то сразу расстрел.
Представляется совтестский быт: сервант, ковер и телевизор. А по формату изложения создается впечатление жесткого рационализма. В духе «Солярис, конечно, неплох, но Гранта спокойно выполняет те же функции, поэтому сиди молча и пускай слюни».
я не говорил что менеджмент не нужен.
Просто если все станут заниматься метадеятельностью, то собственно работу делать будет некому
Резюмируя:
— Можно ли полностью отказаться от метадятельности? Нет.
— Можно ли отказаться от тех, кто непосредственно будет делать работу (=кодить)? Нет.
— Спасет ли гармония? Определенно, да.
Полагаю, что я и вы просто по-разному представили себе эту самую метадеяетельность. Я в виде менеджмента, а вы — в попытках «внедрения» софт скиллов во что и кого только можно.
Берём два человека — одного с зверски прокачанными софт-скиллами, а другого — с аналогично зверскими хард скиллами. Кого из них более вероятно возьмут в Google или Amazon на позицию софтвэа иженера? Я полагаю, вопрос риторический.
Не соглашусь с вами. Если при зверски прокаченных софт скиллах у человека и хард скиллы на том же уровне — то это просто находка, и да, немедленно нужно брать. Но здесь палка о двух концах, и обычно преобладание одних скиллов оказывает влияние на другие.
Все молодые погружены — [сарказм].
схема как «один работает а остальные языками чешут и занимаются метадеятельностью» не кажется мне действительно хорошей и гармоничной
Эта метадеятельность в конечном счете преобразуется в ТЗ. При решении задачи в проекте с несколькими командами без обсуждений и вопросов трудно обойтись. Не думаю, что открыл Америку, но просто камень ненужности в огород менеджмента показался странным. Бесспорно, что уточнить какие-то детали, определить и реализовать функциональность может один человек. Но со временем он будет обрастать потоком вопросов от коллег по команде и не только, и всё больше будет становиться базой знаний. А при постоянном потоке вопросов и проблем на реализацию сложных вещей времени и возможности концентрации будет оставаться всё меньше. Поэтому проще четко поставить задачу и отдать ее тому, кому не требуется чесать языком.
На мой взгляд идеал в гармонии и правильном распределении ролей. Даже вечно бурчащему и недовольному коллеге старичку программисту (ведь все молодые уже полностью погружены в софт-скиллз) будет весьма комфортно писать качественный и продуманный код, сидя спокойно за чашкой крепкого кофе, пока вокруг него будут носиться софт инженеры, общаться, делегировать, планировать и писать на хабр статьи, что гуру архитектора в жилете Вассермана срочно нужно обучить когнитивным навыкам.
Но если действительно есть в планах наступить хоть одной ногой в менеджмент, то оградиться от стресса soft skill-пирамидой придется. И чем больше погружение, тем больше и пирамида потребуется.
все эти штуки никак не помогают делать саму работу. Я и так знаю, что мне нужно сделать Х.
На мой взгляд, они и не должны помогать делать саму работу. Сделать работу может помочь разбитие большой задачи на мелкие, ее делегирование или что-то еще. Использую to-do листы с целью фиксации самих мыслей, а для некоторых — еще и желаемой даты выполнения. Потому что держать всё в голове просто невозможно, да еще и напрягает.
Для меня помощь ПО в том, что:
— Можно открыть список задач, и увидеть что сегодня/на неделе хорошо бы сделать в нужном контексте (работа, учеба, машина, etc.)
— Можно провести ревизию зафиксированных мыслей, провести чистку, приоритезацию и затем запланировать желаемую часть задач.
Или же «это не возможно, потому что затрагиваемая функциональность уже реализована с костылем, а мой перфекционизм не позволяет мне добавить еще один, а текущие оценки задачи — всё переделать»
Увидел в msdn, что можно без атрибутов, определив всё в отдельном классе унаследованном от
DefaultJsonTypeInfoResolverНе понравилось что атрибут
JsonDerivedTypeнавешивается на базовый тип. Информация о наследниках тянется куда не надо, да и сам базовый тип может быть недоступен для модификацииВозможно топовые по размеру зарплаты разработчики просто менее мотивированы узнать «А что там у других?» и не заполняют опросы Хабр Карьеры, либо и вовсе не имеют там профиля)
Впервые увидел этот подход вот тут (ardalis/ApiEndpoints). С одной стороны, возникает бОльшая типизация и разделение вместо микса пачки методов в одном контроллере, а с другой - изобретение велосипеда, который вместо паттерна через пару лет может стать техническим долгом, который непонятно как переводить на рельсы новой версии .NET, и который нужно будет объяснять каждому новому разработчику
Попытки заставить себя тщетны. Другое дело — момент, когда «надо» возьмёт верх над «не хочу». Вот над этим уже можно работать. А если повезёт, какая-нибудь мелочь из общего дела перейдёт в разряд «хочу». Но это уже совсем другая история.
Представляется совтестский быт: сервант, ковер и телевизор. А по формату изложения создается впечатление жесткого рационализма. В духе «Солярис, конечно, неплох, но Гранта спокойно выполняет те же функции, поэтому сиди молча и пускай слюни».
Резюмируя:
— Можно ли полностью отказаться от метадятельности? Нет.
— Можно ли отказаться от тех, кто непосредственно будет делать работу (=кодить)? Нет.
— Спасет ли гармония? Определенно, да.
Полагаю, что я и вы просто по-разному представили себе эту самую метадеяетельность. Я в виде менеджмента, а вы — в попытках «внедрения» софт скиллов во что и кого только можно.
Не соглашусь с вами. Если при зверски прокаченных софт скиллах у человека и хард скиллы на том же уровне — то это просто находка, и да, немедленно нужно брать. Но здесь палка о двух концах, и обычно преобладание одних скиллов оказывает влияние на другие.
Все молодые погружены — [сарказм].
Эта метадеятельность в конечном счете преобразуется в ТЗ. При решении задачи в проекте с несколькими командами без обсуждений и вопросов трудно обойтись. Не думаю, что открыл Америку, но просто камень ненужности в огород менеджмента показался странным. Бесспорно, что уточнить какие-то детали, определить и реализовать функциональность может один человек. Но со временем он будет обрастать потоком вопросов от коллег по команде и не только, и всё больше будет становиться базой знаний. А при постоянном потоке вопросов и проблем на реализацию сложных вещей времени и возможности концентрации будет оставаться всё меньше. Поэтому проще четко поставить задачу и отдать ее тому, кому не требуется чесать языком.
Но если действительно есть в планах наступить хоть одной ногой в менеджмент, то оградиться от стресса soft skill-пирамидой придется. И чем больше погружение, тем больше и пирамида потребуется.
На мой взгляд, они и не должны помогать делать саму работу. Сделать работу может помочь разбитие большой задачи на мелкие, ее делегирование или что-то еще. Использую to-do листы с целью фиксации самих мыслей, а для некоторых — еще и желаемой даты выполнения. Потому что держать всё в голове просто невозможно, да еще и напрягает.
Для меня помощь ПО в том, что:
— Можно открыть список задач, и увидеть что сегодня/на неделе хорошо бы сделать в нужном контексте (работа, учеба, машина, etc.)
— Можно провести ревизию зафиксированных мыслей, провести чистку, приоритезацию и затем запланировать желаемую часть задач.