Тут есть две ситуации: 1. если специалист умнее работодателя, и 2. если работодатель умнее специалиста.
В первом случае, работодатель испытывает естественное чувство благодарности и деньги — отличный способ ее выразить.
А вот во втором — на самом деле работодатель прокачивает специалиста и тот становится более востребован.
Ну так ситуация, когда эффективный собственник оказывает большее влияние — нормальна и даже желательна. Вы же не хотите, чтобы неэффективный собственник оказывал большее влияние на власть.
И давайте определимся, что такое лоббирование. Лоббирование своих интересов — то просто высказывание их нужным людям. Вы тоже можете высказывать свои интересы, у нас есть общественные приемные во многих администрациях.
Мило, конечно, но более разумно хранить архивы в Африке, а не на севере. Если цивилизации окажутся уничтожены, то повторное расселение будет идти из африки, а от африки до арктики далековато.
Если мы действительно хотим, чтобы наш код использовался в наработках наших потомков, то нужно запустить архив в космос, а оттуда непрерывным сигналом передавать на Землю. А на самой Земле построить специальные приемники на ритэгах и отдать по паре штук в каждую страну (разумеется, сигнал не должен требовать декодировщика. Приемник — просто подмога, а не обязательная часть).
Не делал точных расчетов, но по прикидке, такое решение обойдется дешевле 250 копий архива + постоянного обновления архива. Плюс, в космосе можно обновлять информацию на спутнике с Земли. Не быстро, конечно, но, по крайней мере, это не требует участия человека.
Это совсем не верно. Вы и так делаете лишь маленькие кусочки, только вы в уме объединяете их в виртуальные большие кусочки. Простая работа — это линейная работа, которая реализуема за конечное время. Любой проект — простая работа, особенно если он типовой.
Сложная работа — разрешать нерешенные противоречия.
Профессионалы стремятся избегать такой работы (и я не исключение), но все главные профиты (и риски) лежат именно в сфере противоречий.
Забавно, что как разработка, так и юриспруденция, хотя и (по большей части) простые «внутри», сами по себе в «зазеркалье»: по ту сторону неразрешенного противоречия.
Обратите внимание, что я специально добавил де-факто, чтобы вы не путали с юридическим термином.
Само по себе добавление слова «юридический» показывает что вы в глубине души понимаете что компания — не настоящий субъект.
И в этом не было бы проблем, если бы компании были теми же, что и раньше. Сегодня сами компании поменялись, а наши представления о них еще нет. Мы все еще трактуем их исходя из представлений 60-х, но это уже совсем другой зверь.
Да. И это ровно почему СССР развалился: на самом деле, люди хотят не работать, а внимания. Когда бюро под началом генерального конструктора выпустит самолет, внимание получит строго один человек: его генерального конструктор.
Поэтому западное общество устроено немного хитрее: работа на работе — лишь этап обучения перед самостоятельным плаванием. И поэтому, в конечном итоге, протокол совещания будет сводиться к пунктам «Вася хочет выучить ангуляр», и «Петя хочет выучить реакт». У них нет конфликта интересов, нет необходимости в конкуренции, нет необходимости в дискриминации. Соответственно, нет необходимости иметь и записи о том, что в этой итерации Пете было грустно.
А самолет никому не нужен. Ну жили там в северных отдаленных районах люди, ну и еще тыщу лет проживут.
Тут такая хитрость. Мы рассматриваем как обычных людей, так и компании как субъект отношений. Грубо говоря, у нас там в голове есть специальный счетчик, который рассчитывает кто кому и сколько должен. Наличие этого счетчика проявляет себя в деньгах. Деньги — это материальный эквивалент психического счетчика.
Мы относимся к компаниям как к субъекту, принимаем как должное идею обмена с ними материальными ценностями, но де-факто, компания — не субъект и никогда им не была.
На самом деле, компания — это скорее трактор. Мы пользуемся трактором, обслуживаем его, но никому и в голову не приходит платить ему деньги, трактор не занимает деньги на свободном рынке, у трактора нет прав, нет обязанностей.
Поэтому, когда вы используете логику для людей: «должен — не должет, обязан не обязан» в отношении компаний, вы совершаете логический трюк. Не знаю зачем это вам, но просто знайте, что вы так делаете.
Мы, юристы, — довольно упрямые создания и любим вдумчиво читать первоисточник
Если ваше мнение об Agile основано на манифесте, то это искаженное представление. Разработка не имеет столь же хорошо разработанных теоретических обоснований, как и юриспруденция, и манифест — это просто текст, написанный простыми людьми. Разумеется, реальная практика применения аджайла отличается от того, о чем можно догадаться, изучая текст.
Большое спасибо за комментарий! Именно такую позицию мы сотни и, наверное, уже тысячи раз встречали в общении с разработчиками / представителями IT.
И на то есть основания. Если мне нужно сделать сайт, то каким бы сложным сайт ни был, это все равно простая работа, потому что задача разбивается на простые операции, с которыми любой человек может справиться.
С точки зрения юриспруденции, есть веками зарекомендовавшаяся себя практика изменения правовых норм
А кем и к кому применяются правовые нормы? И что вообще означает «применить норму»?
Наша критика сфокусирована на том, что применение Agile именно создании продуктов — крайне рискованная затея. Стремление создать для клиента «quick win» вполне разумно и обоснованно
Это ложное представление. Аджайл не для быстрых побед, а для митигации рисков.
Вам не нужен аджайл, если вы не собираетесь узнавать ничего нового между итерациями. И в то же время, если вы не собираетесь узнавать ничего нового между итерациями, вы просто все поймете в конце проекта, когда он выйдет на рынок.
Наш многолетний опыт в области high-end юриспруденции (M&A, банкротство, защита активов и др.) позволяет с уверенностью говорить о том, как должна быть построена логика работы системы Legal AI, чтобы соответствовать самым высоким требованиям и стандартам.
Я понимаю, что эти вещи гораздо приятнее делать и лучше оплачиваются, но для меня это очень простые операции. Я думаю, что в будущем люди будут просто регистрировать эти состояния на госуслугах и все документы будут подтягиваться автоматически.
Есть сложные вопросы, связанные с деконструкцией субъектности. Я сам еще не вполне разбираюсь в этой теме, но какие должны быть законы в свете новых открытий о человеке? Как применять те законы, что уже есть в свете тех же открытий?
Ну вот, например, акцепт. Акцепта же не существует в реальности, это просто такая игра словесная.
Это элементарно проверить: EULA каждого первого сервиса включает в себя отказ от ответственности. Но при этом в межличностных отношениях отказ от ответственности — красный флаг и с человеком, который свою ответственность отрицает просто не будут говорить. А под EULA подписываются и бровью не ведут.
Хотя, разумеется, если у личности могут быть разумные основания отказаться от ответственности (психически здоровых людей не бывает), то компания, в которой работают люди с самыми разными особенностями принципиально имеет более широкие возможности, чем отдельный человек. Даже два человека, с несовпадающими отклонениями друг-друга корректируют, а у компании в 300 человек вообще 0 оснований для такого отказа. Получается, что обычный механизм регуляции отношений, который мы используем для людей просто не работает с компаниями.
Увы, оценка аджайла как не подходящего сразу же выдает воздушный замок в проекте.
Аджайл не просто модный способ управления, а предполагает проверку ценности на каждой итерации. Т.е. заказчик не просто получает продукт по частям, а пока команда готовит следующую версию, показывает предыдущую клиенту (пользователю) и получает обратную связь от него. Соответственно, правки между итерациями — это не просто так, а жизненная необходимость.
И если вы в себе уверены на 100% что от начала и до конца видите продукт каким он нужен конечному пользователю, даже не вникая в его рабочие процессы, не делая журналов рабочего дня пользователя, не изучая техпроцессы, то шанс что вы заблуждаетесь очень высок.
Если у вас есть обоснованные соображения, что длина итерации в две недели коротковата для этого проекта, или что подготовка публичного релиза займет более двух итераций, это вполне справедливые опасения. Но в конечном итоге, как длина итерации, так и объем первого релиза определяются эмпирически.
Я вообще не считаю, что людей нужно делить на джунов/не джунов. Де-факто, есть лишь один навык: доведение дел до конца. Если человек систематически не доводит дела до конца, задача обучения этому навыку выходит вообще за рамки трудовой деятельности. Но если доводит, то появляется спектр времени, как долго у разных людей займет сделать одну и ту же задачу. И тут смысл делить людей на джунов и не джунов появляется только тогда, когда спектр задач однотипный. Но когда спектр задач однотипный, появляется проблема скуки. И в работе со скукой, в сущности, есть два пути: или руководитель превращается в массовика-затейника, или в сурового надсмотрщика. И сегодня руководитель-надсмотрщик уже мало кому интересен по всяким там причинам.
Поэтому, ответ на вопрос «как работать с джуниорами?» будет — «также, как и со всеми остальными, но убедившись предварительно что это правильные люди».
Было уже много фреймворков, которые пытались делать свой синтаксис внутри атрибутов и это всегда боль. Вы пишете что «Поддержку IDE всегда можно добавить», но по факту, очень мало библиотек имеют такую поддержку. Я знаю только Angular, разве что, но это топ-3 фреймворк. Если поддержка синтаксиса появится когда Numl войдет в первую тройку, ждать придется очень долго.
Дальше вы делаете очень много утверждений, которые видны только из вашего опыта. Я не знаю, насколько ваш опыт типичен, но де-факто, сейчас уже смотрят на то, как живые люди пишут код. Фреймворки Angular, React, Vue (отчасти) сделаны, смотря на то, как реальные люди пишут много кода в больших компаниях. Я не знаю кто вы и где работаете, но если это ваше мнение построено не на анализе поведения живых людей, то практически без шансов. Конкурировать с одним только ангуляром сегодня чистое самоубийство а их там три с кепкой.
1. CSS-синтаксис внутри аттрибутов — строка. В IDE это будет сплошным цветом, а я хочу видеть нормальную подсветку с автоподстановкой.
2. Почему отказались от синтаксиса shadow:hover[:1]="0"?
+ можно сделать синтаксис: (shadow="0" size="2rem"):hover[:1]
Я так понял, что речь идет не про альтернативный язык, а про просто библиотеку компонентов.
Мне нравится идея задавать стиль на самом компоненте, но по-сути это тот же самый style="...". Ну погранулярней, ну можно задавать псевдоклассы.
Это понятно. Я про то и пишу, что вы связываете потребность в безопасности и статическую типизацию как будто бы это само собой разумеется.
Однако, почему программерская мысль остановилась на этом этапе? Что мешает пойти еще дальше?
Проблема в том, что разработчики дают противоположные по смыслу обещания, которые они не способны выполнить одновременно:
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Верно, в разных. Компании, которые лоббируют свои интересы делают это из созидательных мотивов, а вы из разрушительных. Так что иллюзии тут у вас.
В первом случае, работодатель испытывает естественное чувство благодарности и деньги — отличный способ ее выразить.
А вот во втором — на самом деле работодатель прокачивает специалиста и тот становится более востребован.
И давайте определимся, что такое лоббирование. Лоббирование своих интересов — то просто высказывание их нужным людям. Вы тоже можете высказывать свои интересы, у нас есть общественные приемные во многих администрациях.
Если мы действительно хотим, чтобы наш код использовался в наработках наших потомков, то нужно запустить архив в космос, а оттуда непрерывным сигналом передавать на Землю. А на самой Земле построить специальные приемники на ритэгах и отдать по паре штук в каждую страну (разумеется, сигнал не должен требовать декодировщика. Приемник — просто подмога, а не обязательная часть).
Не делал точных расчетов, но по прикидке, такое решение обойдется дешевле 250 копий архива + постоянного обновления архива. Плюс, в космосе можно обновлять информацию на спутнике с Земли. Не быстро, конечно, но, по крайней мере, это не требует участия человека.
Сложная работа — разрешать нерешенные противоречия.
Профессионалы стремятся избегать такой работы (и я не исключение), но все главные профиты (и риски) лежат именно в сфере противоречий.
Забавно, что как разработка, так и юриспруденция, хотя и (по большей части) простые «внутри», сами по себе в «зазеркалье»: по ту сторону неразрешенного противоречия.
Само по себе добавление слова «юридический» показывает что вы в глубине души понимаете что компания — не настоящий субъект.
И в этом не было бы проблем, если бы компании были теми же, что и раньше. Сегодня сами компании поменялись, а наши представления о них еще нет. Мы все еще трактуем их исходя из представлений 60-х, но это уже совсем другой зверь.
Поэтому западное общество устроено немного хитрее: работа на работе — лишь этап обучения перед самостоятельным плаванием. И поэтому, в конечном итоге, протокол совещания будет сводиться к пунктам «Вася хочет выучить ангуляр», и «Петя хочет выучить реакт». У них нет конфликта интересов, нет необходимости в конкуренции, нет необходимости в дискриминации. Соответственно, нет необходимости иметь и записи о том, что в этой итерации Пете было грустно.
А самолет никому не нужен. Ну жили там в северных отдаленных районах люди, ну и еще тыщу лет проживут.
Мы относимся к компаниям как к субъекту, принимаем как должное идею обмена с ними материальными ценностями, но де-факто, компания — не субъект и никогда им не была.
На самом деле, компания — это скорее трактор. Мы пользуемся трактором, обслуживаем его, но никому и в голову не приходит платить ему деньги, трактор не занимает деньги на свободном рынке, у трактора нет прав, нет обязанностей.
Поэтому, когда вы используете логику для людей: «должен — не должет, обязан не обязан» в отношении компаний, вы совершаете логический трюк. Не знаю зачем это вам, но просто знайте, что вы так делаете.
Если ваше мнение об Agile основано на манифесте, то это искаженное представление. Разработка не имеет столь же хорошо разработанных теоретических обоснований, как и юриспруденция, и манифест — это просто текст, написанный простыми людьми. Разумеется, реальная практика применения аджайла отличается от того, о чем можно догадаться, изучая текст.
И на то есть основания. Если мне нужно сделать сайт, то каким бы сложным сайт ни был, это все равно простая работа, потому что задача разбивается на простые операции, с которыми любой человек может справиться.
А кем и к кому применяются правовые нормы? И что вообще означает «применить норму»?
Это ложное представление. Аджайл не для быстрых побед, а для митигации рисков.
Вам не нужен аджайл, если вы не собираетесь узнавать ничего нового между итерациями. И в то же время, если вы не собираетесь узнавать ничего нового между итерациями, вы просто все поймете в конце проекта, когда он выйдет на рынок.
Я понимаю, что эти вещи гораздо приятнее делать и лучше оплачиваются, но для меня это очень простые операции. Я думаю, что в будущем люди будут просто регистрировать эти состояния на госуслугах и все документы будут подтягиваться автоматически.
Есть сложные вопросы, связанные с деконструкцией субъектности. Я сам еще не вполне разбираюсь в этой теме, но какие должны быть законы в свете новых открытий о человеке? Как применять те законы, что уже есть в свете тех же открытий?
Ну вот, например, акцепт. Акцепта же не существует в реальности, это просто такая игра словесная.
Это элементарно проверить: EULA каждого первого сервиса включает в себя отказ от ответственности. Но при этом в межличностных отношениях отказ от ответственности — красный флаг и с человеком, который свою ответственность отрицает просто не будут говорить. А под EULA подписываются и бровью не ведут.
Хотя, разумеется, если у личности могут быть разумные основания отказаться от ответственности (психически здоровых людей не бывает), то компания, в которой работают люди с самыми разными особенностями принципиально имеет более широкие возможности, чем отдельный человек. Даже два человека, с несовпадающими отклонениями друг-друга корректируют, а у компании в 300 человек вообще 0 оснований для такого отказа. Получается, что обычный механизм регуляции отношений, который мы используем для людей просто не работает с компаниями.
Аджайл не просто модный способ управления, а предполагает проверку ценности на каждой итерации. Т.е. заказчик не просто получает продукт по частям, а пока команда готовит следующую версию, показывает предыдущую клиенту (пользователю) и получает обратную связь от него. Соответственно, правки между итерациями — это не просто так, а жизненная необходимость.
И если вы в себе уверены на 100% что от начала и до конца видите продукт каким он нужен конечному пользователю, даже не вникая в его рабочие процессы, не делая журналов рабочего дня пользователя, не изучая техпроцессы, то шанс что вы заблуждаетесь очень высок.
Если у вас есть обоснованные соображения, что длина итерации в две недели коротковата для этого проекта, или что подготовка публичного релиза займет более двух итераций, это вполне справедливые опасения. Но в конечном итоге, как длина итерации, так и объем первого релиза определяются эмпирически.
Только если проект типовой. Но вообще идея делать типовой проект — крайне сомнительная сама по себе.
Поэтому, ответ на вопрос «как работать с джуниорами?» будет — «также, как и со всеми остальными, но убедившись предварительно что это правильные люди».
Дальше вы делаете очень много утверждений, которые видны только из вашего опыта. Я не знаю, насколько ваш опыт типичен, но де-факто, сейчас уже смотрят на то, как живые люди пишут код. Фреймворки Angular, React, Vue (отчасти) сделаны, смотря на то, как реальные люди пишут много кода в больших компаниях. Я не знаю кто вы и где работаете, но если это ваше мнение построено не на анализе поведения живых людей, то практически без шансов. Конкурировать с одним только ангуляром сегодня чистое самоубийство а их там три с кепкой.
2. Почему отказались от синтаксиса
shadow:hover[:1]="0"?+ можно сделать синтаксис:
(shadow="0" size="2rem"):hover[:1]Я так понял, что речь идет не про альтернативный язык, а про просто библиотеку компонентов.
Мне нравится идея задавать стиль на самом компоненте, но по-сути это тот же самый
style="...". Ну погранулярней, ну можно задавать псевдоклассы.КМК, если делать такой ход конем:
Это будет и покрасивее и поудобней. Почему так не стали?
Однако, почему программерская мысль остановилась на этом этапе? Что мешает пойти еще дальше?
1. «ПО может быть получено, путем композиции простых операций, которые мы умеем делать» → «дорогой менеджер, не мог бы ты, пожалуйста, составить план разработки ПО из этих операций, а мы его реализуем максимально хорошо».
2. «У нас есть и свои потребности, которые мы могли бы удовлетворить с помощью ПО» → «дорогой менеджер, пожалуйста, позволь нам самим организовывать свое время и результат, возможно, даже превысит твои ожидания».
Разумеется, одновременно эти обещания не могут быть выполнены и причина этому — реальная жизнь:
1. Первое обещание не может быть выполнено, потому что сегодня мы в большей степени аутсорсим наши усилия: мы составляем ПО из готовых чужих модулей, ПО крутится на не контролируемом нами окружении (в облаке) и нас самих учат программированию другие люди, мы не постигаем его с нуля.
2. Увы, постижение мастерства реализации конкретного ПО с нуля и до последнего байта методом проб и ошибок просто слишком долго. Рыночное окно для этого ПО просто закроется, когда мы изучим все необходимое.
Совместить оба подхода можно с помощью прозрачности: менеджер держит в голове полную картину, но вы ему честно говорите какой ваш личный интерес в решении этой задачи.
Поскольку мириться с несовершенством жизни менеджер умеет и так, остается только научить его мириться с вами.
Т.е. идеальный эстимейт: «эта задача займет 2 часа, но я еще хочу дописать документацию и причесать код, поэтому 4 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.