Тут такая хитрость. Мы рассматриваем как обычных людей, так и компании как субъект отношений. Грубо говоря, у нас там в голове есть специальный счетчик, который рассчитывает кто кому и сколько должен. Наличие этого счетчика проявляет себя в деньгах. Деньги — это материальный эквивалент психического счетчика.
Мы относимся к компаниям как к субъекту, принимаем как должное идею обмена с ними материальными ценностями, но де-факто, компания — не субъект и никогда им не была.
На самом деле, компания — это скорее трактор. Мы пользуемся трактором, обслуживаем его, но никому и в голову не приходит платить ему деньги, трактор не занимает деньги на свободном рынке, у трактора нет прав, нет обязанностей.
Поэтому, когда вы используете логику для людей: «должен — не должет, обязан не обязан» в отношении компаний, вы совершаете логический трюк. Не знаю зачем это вам, но просто знайте, что вы так делаете.
Мы, юристы, — довольно упрямые создания и любим вдумчиво читать первоисточник
Если ваше мнение об 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 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Увы, абсолютная диктатура невозможна на практике. Может быть, вы сможете найти формулу, которая предскажет вероятность установления такой диктатуры к определенной дате, но мое предсказание, что уже где-то на 10% дата отодвинется в далекое будущее.
Пожалуй, единственная альтернатива — вообще отказ от власти и решение всех вопросов как у известного вида приматов — через коитус. Интересная альтернатива, но она обессмысливает вообще предмет вашей статьи: если основа всех конфликтов — потребность в сексе, почему бы не сократить расстояние и сразу им не заняться? Зачем нужно таблички рисовать, выдумывать что-то.
Умирает человек, попадает в рай. Его встречает апостол Петр.
Человек: Простите, что вас беспокою, но у меня к вам есть один вопрос
Апостол: Слушаю вас
Ч: Я прожил довольно долгую жизнь, но так и не понял одного. Скажите, в чем был смысл моей жизни?
А: Вам правда нужно это знать?
Ч: Очень
А: Помните, вы 1973 году ехали в поезде Москва-Краснодар?
Ч: Э-э… ну…
А: И вы еще познакомились в купе с попутчиками
Ч: Наверное…
А: И вы пошли вместе в вагон-ресторан
Ч: Да…
А: И за соседним столиком сидела женщина
Ч: Возможно…
А: И она попросила вас передать ей соль
Ч: И я ей передал соль.
А: И вы передали ей соль
Ч: Передал.
А: Ну и вот…
Решение всех противоречий не выгодно самим людям. В конечном итоге выяснится, что верования основаны на личных особенностях, а картина мира — лишь средство адаптации.
если вам нужно доказательство наличия ключа. И так далее.
Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.
Для этого вам её надо допустить везде, во всей программе, если упрощать. Практика показывает, что это сделать сложно.
Поясните.
Можно начать с «прочитать из сокета данные, где в первых четырёх байтах длина, а в следующих — содержимое, со статическими гарантиями невыхода за границы массива и обработки плохих случаев». Продолжить можно с «подключиться к БД, достать схему и проверить, что все запросы соответствуют этой схеме».
Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.
Ну вот вы уже измеряете производительность в терминах каких-то абстрактных поинтов за итерацию. А потом удивляетесь, когда я рассказываю вам про погоню за поинтами вместо пользовательского счастья в командах разработки.
Понятно, что пока вы не можете удовлетворить пользователя, нет смысла говорить о производительности.
Ну так я к ровно тому и подвожу, что пока у вас пользователь несчастлив, пока вы его удовлетворяете не достаточно быстро, нет смысла и говорить о корректности программы с точки зрения типов. Тем более, что система типов вообще никак не решает те проблемы, которые реально доставляют пользователю боль.
А как вы разделяете одно доказательство от другого?
Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.
Или у вас на любой аргумент есть контр-аргумент, утверждающий, что аргумент на самом деле не о преимуществах системы типов, а о чём-то другом?
Да, я стараюсь рассматривать множество альтернативных вариантов.
А что до программистов — ну, кто-то и на современные языки переходить не хочет, предпочитая писать на коболе каком-нибудь, или на C++03.
В том-то и дело, что речь идет не о ком-то, а о массах программистов. Сотнях и, возможно, тысячах. Вы не можете их просто так сбросить со счетов.
Однако даже он даёт больше статических гарантий, чем питон.
Ну, я бы не сказал что это прям плюс. Кому-то уже писал, что я действительно считаю систему типов неоценимой подмогой во время обучения программированию. Но зачем она зрелому программисту — вопрос открыт.
Разработчикам на плюсах только об этом не говорите. Не поймут-с.
Вроде об этом Фаулер писал. Так что все в курсе.
Вы, кажется, перепутали большие компании с бодишопом. Как думаете, какая текучка на проектах типа LLVM или V8?
Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.
А, ну если у меня текучки нет, то я-то бесконечно внимательный и помню каждую строку кода, которую писал 5 лет назад.
Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.
Каким?
Медленно.
Компилятор хаскеля вон на хаскеле написан, компилятор первого идриса — на хаскеле, компилятор агды — на хаскеле, компилятор всяких MLей — на MLях, хотя эти языки далеко не всегда топ в производительности.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Нет. Опыт перехода на более строгие языки у меня есть, когда становилось как раз более непривычно, и я могу с этим опытом сравнить.
Ну, понятно. У меня тоже был период, когда я боялся к крупным проектам подходить. Ничего, период прошел, теперь все норм.
Мы относимся к компаниям как к субъекту, принимаем как должное идею обмена с ними материальными ценностями, но де-факто, компания — не субъект и никогда им не была.
На самом деле, компания — это скорее трактор. Мы пользуемся трактором, обслуживаем его, но никому и в голову не приходит платить ему деньги, трактор не занимает деньги на свободном рынке, у трактора нет прав, нет обязанностей.
Поэтому, когда вы используете логику для людей: «должен — не должет, обязан не обязан» в отношении компаний, вы совершаете логический трюк. Не знаю зачем это вам, но просто знайте, что вы так делаете.
Если ваше мнение об 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 часа».
Менеджер может не согласиться, поскольку проект требуется реализовать в сжатые сроки, или по другим причинам. Ну штош.
Пожалуй, единственная альтернатива — вообще отказ от власти и решение всех вопросов как у известного вида приматов — через коитус. Интересная альтернатива, но она обессмысливает вообще предмет вашей статьи: если основа всех конфликтов — потребность в сексе, почему бы не сократить расстояние и сразу им не заняться? Зачем нужно таблички рисовать, выдумывать что-то.
Человек: Простите, что вас беспокою, но у меня к вам есть один вопрос
Апостол: Слушаю вас
Ч: Я прожил довольно долгую жизнь, но так и не понял одного. Скажите, в чем был смысл моей жизни?
А: Вам правда нужно это знать?
Ч: Очень
А: Помните, вы 1973 году ехали в поезде Москва-Краснодар?
Ч: Э-э… ну…
А: И вы еще познакомились в купе с попутчиками
Ч: Наверное…
А: И вы пошли вместе в вагон-ресторан
Ч: Да…
А: И за соседним столиком сидела женщина
Ч: Возможно…
А: И она попросила вас передать ей соль
Ч: И я ей передал соль.
А: И вы передали ей соль
Ч: Передал.
А: Ну и вот…
Кроме того, я не знаю, как именно он компилируется. Может быть, он не использует все оптимальные процессорные инструкции.
Мне нужно чтобы система типов мне гарантировала, что в файле не будет бяки.
Поясните.
Хорошие примеры. Теперь покажите, как это решается с помощью системы типов.
Понятно, что пока вы не можете удовлетворить пользователя, нет смысла говорить о производительности.
Ну так я к ровно тому и подвожу, что пока у вас пользователь несчастлив, пока вы его удовлетворяете не достаточно быстро, нет смысла и говорить о корректности программы с точки зрения типов. Тем более, что система типов вообще никак не решает те проблемы, которые реально доставляют пользователю боль.
Свидетельство. Я вообще не считаю, что в таком сложном вопросе можно найти строгое доказательство.
Да, я стараюсь рассматривать множество альтернативных вариантов.
В том-то и дело, что речь идет не о ком-то, а о массах программистов. Сотнях и, возможно, тысячах. Вы не можете их просто так сбросить со счетов.
Ну, я бы не сказал что это прям плюс. Кому-то уже писал, что я действительно считаю систему типов неоценимой подмогой во время обучения программированию. Но зачем она зрелому программисту — вопрос открыт.
Вроде об этом Фаулер писал. Так что все в курсе.
Это комьюнити проекты, там картина другая. Любой проект, когда выходит в паблик — это успешный проект. Мы вообще ничего не знаем о внутренних, а их там сотни.
Не каждую, разумеется. Сегодня спагетти-код считается моветом и программы структурируются довольно крупными блоками: функция, класс, модуль. Это вы и я вспомним и через 5 и через 10 лет.
Медленно.
Это тут вообще роли не играет. Все перечисленные языки выполняются на виртуальной машине.
Ну, понятно. У меня тоже был период, когда я боялся к крупным проектам подходить. Ничего, период прошел, теперь все норм.