Насчет оторванности - согласен. Очень легко уйти в рефакторинг, улучшайзинг и тому подобное. Ради чего? Хрен знает. Оптимизировать метод, чтобы он работал на 5% лучше? Чтобы что? Сам этим постоянно грешу и замечаю это во всем - например купил велик, начинаю на нем менять сидушку, покупать багажник, менять звезду. Уже не ради того, чтобы кататься и тд, а сам доставляет сам процесс выбора вот этого всего, похода на ПВЗ за запчастями. Хорошо в этом плане отрезвляет какая-то глобальная цель, общение с бизнесом. МОжет быть то, что мы делаем, вообще нафиг не нужно и мы могли бы в этом плане другим заниматься, более ценными и важными вещами. Я думаю ,что программисты перестали бы играть в свои лего на работе, если бы из ЗП складывалась из показателей работы компании (сделал фигню, которая не принесла бабла - ну сам виноват). Но не все согласятся с такими условиями работать.
В конечном счете так соглашаются работать, потому что это единственно верный коллективный путь. Сначала всегда идет резкое сопротивление, но потом, после принятия что это не про нападение на разработчиков, а наоборот - помощь в понимании своей траектории - все встает на свои места. Каждый в итоге хочет иметь наблюдаемый и осязаемый вклад в общее дело. Это и есть путь. Шутка юмора в том, что в последующих сериях я лишь немного отослался на руководящие вопросы, которые по сути дела и приводят к таким ковыряниям на местах, но об этом поже и обязательно будет. Потому что Технадзор как раз начинается с верхних этажей. Просто замер по нижним уровням всегда показывает что не так и куда это идет, и работа по исследованию ситуаций все равно начинается с разработки, и так или иначе в итоге все равно приведет наверх. Это уже очень протоптаная дорожка, кто-то решается, а кто-то нет. Поэтому это вопросы каждонго в компании личные, и внутренние. Ты принимаешь решение - делать дело, или строить заборы, где моя хата с краю. Чуз йор дестини
Да, итоговый результат деятельности программиста выглядит просто, но достигается он за счёт потраченных тысяч часов на пересоздание кубиков. Это называется иллюзия знания. Люди, прочитав книгу, полагают что полностью её поняли. Но попытавшись практиковать "понятое знание" быстро осознают, что нечего не помнят. К примеру можно взять любой прилавок в магазине, проанализировать его и понять, что сделан он из простых вещей и повторить его будет довольно просто. Но в таком процессе не учитывает, что он был создан в момент, когда такой вещи ещё не существовало. И стойка прилавка была воссоздана буквально из человеческого воображения, максимум что было - это одно два требования: штука должна быть широкой и устойчивой. А по итогу она закрывает намного больше потребностей: под ней можно хранить вещи, на неё можно что-то ставить. Если бы разработчик прилавка ориентировался только на первые требования и остановился на первой стойке, то получилось бы другой продукт, которым никто не пользуется и который мало кому нужен. С работой программиста всё точно также. Его результат легко оценить, и заключить, что всё просто. Но повторить "почему-то" получается только у тех, кто готов "пересобирать кубики" снова и снова.
Если у правления компании нет навыков и способов контроля расходования ресурсов -- это их личное дело, как говорится флаг им в руки. Ковыряния за счет работодателя -- это проблема работодателя а не программиста. Но вы можете ознакомиться с сетевым планированием, с ТРИЗ и проектированием. Стадия планирования, выявления предмета, определение противоречий, снятие противоречий и предложение обоснованного решения по материалам и технологиям -- это существующие и управляемые стадии, рутинная работа. Которая никому из програмистов не нужна и чужда, она сразу наводит прозрачность и снимает туман творческой деятельности для непосвященных. Начните с плана программи -- это творческая мука и сложность написать что программа будет делать? Это список из семи пунктов максимум. А потом предложите решение как вы видите релазиацию каждого из пунктов. Обсудите это с руководством. Примите решения о том делать или нет. Согласуйте данные компонентов, и приступайте к "творческому выбору решения", как угодно, любой js фреймворк или что там модно уже применяйте. Это уже не будет развалом дела, это будет контролируемая поставка результат. То что разработчик делать это не способени и не собирается прекрасно известно. Рассказывать о творческих муках можно сколь угодно долго, а можно просто планировать, брать ответственность за результат и поставлять компоненты. Тут свободный выбор каждого.
@@apavlyut ты просто не понимаешь о чём говоришь. Программные продукты настолько огромны, что просто не умещаются в памяти человека. Одно это уже исключает применении тех подходов, чтобы ты предложил. Никто просто не в состоянии определить как измениться система, пока новая функциональность не попадёт в продакшен. И выполнение всех предложенных тобой пунктов займет больше времени, чем просто сделать фичу или починить баг -- а следовательно дешевле, а следовательно именно так все и делают. И да, программист не отвечает за процессы в компании, это компетенции других людей. Но если кому-то очень хочется изменить процесс, то ТК РФ давно дал рекомендацию: обучаешь человека, контролируешь использование нового навыка. Возмущения по типу "не хотят", "не применяют", "не слушают" -- позиция абсолютно слабая и неконструктивная. Начните с плана программ. Это список из семи пунктов максимум. А потом предложите решение как вы видите релазиацию каждого из пунктов. Обсудите это с руководством....
@@CilezSayles Дорой мой телезритель, спасибо за идеальный комментарий. Я правда не уловил когда мы соскользнули на ты, но бывает. Комментарий является лучшей иллюстрацией того, как разрабочик будет наводить туман, даже не имея предмета обсуждения. У нас даже не было задачи, но мы уже знаем что планировать ее невозможно. Это же просто идеально! Мы сейчас не просто выкинули на помойку технологии творческого изобретения и создания нового, но и просто продемонстрировали что даже сам факт возможного обсуждения деталей исполнения у программиста вызывает взрывной эмоциональный оскал. Именно об этом я предупреждаю внимательных слушателей - вот так и приходится работать, жизнь она так сложилась, и никак иначе. Против фактов не попрешь, полностью с свами согласен. Я сохраню эту иллюстрацию, искренне благодарю за пример.
@@apavlyut ты предложил методологии, которые должны помочь в разработке по. Я посмотрел их главные принципы, указал на первое возникшее противоречие. Ты пишешь, что я навожу тумана. Ок, я понял.Их применение требует больше, чем 15 минут на ознакомление. Тогда тем более не понятно, почему разработчики должны им следовать.
Не очень понял в чём мораль и в чём детскость программистов? Програмист это обычный работяга, такой же как на слесарь на заводе или на строитель на стрйоке, только у него компьютер вместо перфоратора или станка. Задача рабочего - качественно выполнять свою работу в указанный срок. А насчёт детскости программистов, у них просто такой склад ума разбираться с устройством вещей и уметь их сделать по разному. Все остальные мечты и идеи про улучшению бизнеса, его структуры и т.п. обо всём этом должен париться хозяин, а не исполнитель. Никто не будет и не обязан жвать жопу ради чужого бизнеса.
А кто сказал что все программисты такие? Можете не пересматривать, я просто уточню - как правило программисты себе так ведут. А инженеры нет. Вот и делайте вывод самостоятельно - кто есть кто. Раньше никто не был прогрраммистом, все просто делали свою работу, которая не поменялась. Сейчас уйма "айтишников" и "программистов" - о них речь. Сами создали культ и в нем же закопались. Ирония судьбы в том, что на выходе получаются всегда интерфейсы, о которые идет замер реальности. Но это видимо высокие сложности, не будем о них.
@@apavlyut просто не понимаю в чём посыл ролика. В том что программисты и айтишники занимаются ерундой на рабочем месте, которая не приводит к явным результатам? Если так, то над ними сверху должен быть управляющий, (как у нас инженеров главный инженер), который раздаёт им задачи и чётко понимает кто что конкретно делает. У айтишников вроде есть подобный персонаж, кажется называют его TeamLead или как-то так.
@@alexander605 ну вы явно не глупый человек. давайте попробуем выйти в надсистему - ролики вам подкинули, и они вызвали эмоцию. если это резонирует - значет точка касания есть. думайте, я не для вас лично это записыаю, это невозможно. излагаю я рабочие вопросы, на которых далее будет выстроено много чего. раньше это было внутри, сейчас я занимаюсь этим от своего имени, для этого я публикую свое мнение по ряду вопросов. если совсем непнотяно, присматривайтесь дальше, материалов более конкретных будет достаточно. ну и лучше не хамить сразу, без разбора. на секудну задумайтесь, возможно есть детали, которые от вас ускользают на первый взгляд. темы не просты, и очень острые для многих, так что не думайте что тут какая-то наивность. я стараюсь очень деликатно
Провокационный спич😂
спасибо за комментарий!
Насчет оторванности - согласен. Очень легко уйти в рефакторинг, улучшайзинг и тому подобное. Ради чего? Хрен знает. Оптимизировать метод, чтобы он работал на 5% лучше? Чтобы что? Сам этим постоянно грешу и замечаю это во всем - например купил велик, начинаю на нем менять сидушку, покупать багажник, менять звезду. Уже не ради того, чтобы кататься и тд, а сам доставляет сам процесс выбора вот этого всего, похода на ПВЗ за запчастями.
Хорошо в этом плане отрезвляет какая-то глобальная цель, общение с бизнесом. МОжет быть то, что мы делаем, вообще нафиг не нужно и мы могли бы в этом плане другим заниматься, более ценными и важными вещами. Я думаю ,что программисты перестали бы играть в свои лего на работе, если бы из ЗП складывалась из показателей работы компании (сделал фигню, которая не принесла бабла - ну сам виноват). Но не все согласятся с такими условиями работать.
В конечном счете так соглашаются работать, потому что это единственно верный коллективный путь.
Сначала всегда идет резкое сопротивление, но потом, после принятия что это не про нападение на разработчиков, а наоборот - помощь в понимании своей траектории - все встает на свои места.
Каждый в итоге хочет иметь наблюдаемый и осязаемый вклад в общее дело.
Это и есть путь.
Шутка юмора в том, что в последующих сериях я лишь немного отослался на руководящие вопросы, которые по сути дела и приводят к таким ковыряниям на местах, но об этом поже и обязательно будет.
Потому что Технадзор как раз начинается с верхних этажей.
Просто замер по нижним уровням всегда показывает что не так и куда это идет, и работа по исследованию ситуаций все равно начинается с разработки, и так или иначе в итоге все равно приведет наверх.
Это уже очень протоптаная дорожка, кто-то решается, а кто-то нет.
Поэтому это вопросы каждонго в компании личные, и внутренние. Ты принимаешь решение - делать дело, или строить заборы, где моя хата с краю.
Чуз йор дестини
Жёсткий инсайт. Спекулятивное обобщение. Ждём новых технадзоров😮
Сегодня будет обобщение помягче.
Увы, узнала себя (за исключением бороды)
Спасибо за комментарий и просмотр.
Да, итоговый результат деятельности программиста выглядит просто, но достигается он за счёт потраченных тысяч часов на пересоздание кубиков.
Это называется иллюзия знания. Люди, прочитав книгу, полагают что полностью её поняли. Но попытавшись практиковать "понятое знание" быстро осознают, что нечего не помнят. К примеру можно взять любой прилавок в магазине, проанализировать его и понять, что сделан он из простых вещей и повторить его будет довольно просто. Но в таком процессе не учитывает, что он был создан в момент, когда такой вещи ещё не существовало. И стойка прилавка была воссоздана буквально из человеческого воображения, максимум что было - это одно два требования: штука должна быть широкой и устойчивой. А по итогу она закрывает намного больше потребностей: под ней можно хранить вещи, на неё можно что-то ставить. Если бы разработчик прилавка ориентировался только на первые требования и остановился на первой стойке, то получилось бы другой продукт, которым никто не пользуется и который мало кому нужен.
С работой программиста всё точно также. Его результат легко оценить, и заключить, что всё просто. Но повторить "почему-то" получается только у тех, кто готов "пересобирать кубики" снова и снова.
Если у правления компании нет навыков и способов контроля расходования ресурсов -- это их личное дело, как говорится флаг им в руки.
Ковыряния за счет работодателя -- это проблема работодателя а не программиста.
Но вы можете ознакомиться с сетевым планированием, с ТРИЗ и проектированием.
Стадия планирования, выявления предмета, определение противоречий, снятие противоречий и предложение обоснованного решения по материалам и технологиям -- это существующие и управляемые стадии, рутинная работа.
Которая никому из програмистов не нужна и чужда, она сразу наводит прозрачность и снимает туман творческой деятельности для непосвященных.
Начните с плана программи -- это творческая мука и сложность написать что программа будет делать? Это список из семи пунктов максимум.
А потом предложите решение как вы видите релазиацию каждого из пунктов. Обсудите это с руководством.
Примите решения о том делать или нет.
Согласуйте данные компонентов, и приступайте к "творческому выбору решения", как угодно, любой js фреймворк или что там модно уже применяйте.
Это уже не будет развалом дела, это будет контролируемая поставка результат.
То что разработчик делать это не способени и не собирается прекрасно известно.
Рассказывать о творческих муках можно сколь угодно долго, а можно просто планировать, брать ответственность за результат и поставлять компоненты.
Тут свободный выбор каждого.
@@apavlyut ты просто не понимаешь о чём говоришь. Программные продукты настолько огромны, что просто не умещаются в памяти человека. Одно это уже исключает применении тех подходов, чтобы ты предложил. Никто просто не в состоянии определить как измениться система, пока новая функциональность не попадёт в продакшен.
И выполнение всех предложенных тобой пунктов займет больше времени, чем просто сделать фичу или починить баг -- а следовательно дешевле, а следовательно именно так все и делают.
И да, программист не отвечает за процессы в компании, это компетенции других людей. Но если кому-то очень хочется изменить процесс, то ТК РФ давно дал рекомендацию: обучаешь человека, контролируешь использование нового навыка.
Возмущения по типу "не хотят", "не применяют", "не слушают" -- позиция абсолютно слабая и неконструктивная. Начните с плана программ. Это список из семи пунктов максимум. А потом предложите решение как вы видите релазиацию каждого из пунктов. Обсудите это с руководством....
@@CilezSayles Дорой мой телезритель, спасибо за идеальный комментарий. Я правда не уловил когда мы соскользнули на ты, но бывает.
Комментарий является лучшей иллюстрацией того, как разрабочик будет наводить туман, даже не имея предмета обсуждения. У нас даже не было задачи, но мы уже знаем что планировать ее невозможно. Это же просто идеально!
Мы сейчас не просто выкинули на помойку технологии творческого изобретения и создания нового, но и просто продемонстрировали что даже сам факт возможного обсуждения деталей исполнения у программиста вызывает взрывной эмоциональный оскал.
Именно об этом я предупреждаю внимательных слушателей - вот так и приходится работать, жизнь она так сложилась, и никак иначе. Против фактов не попрешь, полностью с свами согласен.
Я сохраню эту иллюстрацию, искренне благодарю за пример.
@@apavlyut ты предложил методологии, которые должны помочь в разработке по. Я посмотрел их главные принципы, указал на первое возникшее противоречие. Ты пишешь, что я навожу тумана. Ок, я понял.Их применение требует больше, чем 15 минут на ознакомление. Тогда тем более не понятно, почему разработчики должны им следовать.
Не очень понял в чём мораль и в чём детскость программистов? Програмист это обычный работяга, такой же как на слесарь на заводе или на строитель на стрйоке, только у него компьютер вместо перфоратора или станка. Задача рабочего - качественно выполнять свою работу в указанный срок. А насчёт детскости программистов, у них просто такой склад ума разбираться с устройством вещей и уметь их сделать по разному. Все остальные мечты и идеи про улучшению бизнеса, его структуры и т.п. обо всём этом должен париться хозяин, а не исполнитель. Никто не будет и не обязан жвать жопу ради чужого бизнеса.
А кто сказал что все программисты такие?
Можете не пересматривать, я просто уточню - как правило программисты себе так ведут.
А инженеры нет.
Вот и делайте вывод самостоятельно - кто есть кто.
Раньше никто не был прогрраммистом, все просто делали свою работу, которая не поменялась.
Сейчас уйма "айтишников" и "программистов" - о них речь. Сами создали культ и в нем же закопались.
Ирония судьбы в том, что на выходе получаются всегда интерфейсы, о которые идет замер реальности.
Но это видимо высокие сложности, не будем о них.
@@apavlyut просто не понимаю в чём посыл ролика. В том что программисты и айтишники занимаются ерундой на рабочем месте, которая не приводит к явным результатам? Если так, то над ними сверху должен быть управляющий, (как у нас инженеров главный инженер), который раздаёт им задачи и чётко понимает кто что конкретно делает. У айтишников вроде есть подобный персонаж, кажется называют его TeamLead или как-то так.
@@alexander605 ну вы явно не глупый человек.
давайте попробуем выйти в надсистему - ролики вам подкинули, и они вызвали эмоцию.
если это резонирует - значет точка касания есть.
думайте, я не для вас лично это записыаю, это невозможно.
излагаю я рабочие вопросы, на которых далее будет выстроено много чего.
раньше это было внутри, сейчас я занимаюсь этим от своего имени, для этого я публикую свое мнение по ряду вопросов.
если совсем непнотяно, присматривайтесь дальше, материалов более конкретных будет достаточно.
ну и лучше не хамить сразу, без разбора.
на секудну задумайтесь, возможно есть детали, которые от вас ускользают на первый взгляд.
темы не просты, и очень острые для многих, так что не думайте что тут какая-то наивность.
я стараюсь очень деликатно