Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Отлично написано, очень напоминает «Совершенный код» Макконелла.
(1)
не читал, не знаю насколько верно сравнение. А вот «Чистый код» Мартина читал после публикации первой версии этого курса. Там много похожего было по практике программирования. Пути и мысленные размышления что привели к тем или иным решениям разные конечно, а вот выводы сходные. Впрочем неудивительно, если решать сходные задачи, то и результаты будут сходные. Но можете убедиться, что здесь присутствует оригинальная мысль, хотя бы по стилю изложение. Конечно сложно сравнивать компактный конспект к лекции и полноценную книгу, в публикации старался довести и ход мыслей, а не только выводы.
(2)
А стоило бы, там это (большая часть) и многое другое подробно изложено. И простым языком.
меньше Макконела понравился, сильнее на ООП завязан и более субъективная что ли, меньше фундаментальных вопросов затронуто.
(3) Спасибо за комментарий, но к сожалению он вызвал больше вопросов чем дал ответов.
1. Я конечно рад что у Макконелла в целой книге рассказано больше чем у меня во введении, но всё же хотелось бы видеть указания на ключевые сходства и отличия. Причем не столько для себя сколько для читателей. Полагаю читатели оценили бы ваш труд, если бы вы сделали сравнительное описание. Готов даже оказать дополнительную информационную поддержку в этом деле. Информация об еще одном источнике ценной информации не может быть бесполезной.
Если конечно ваш комментарий не написан в порыве чувств. Уже сталкивался с подобными комментариями к первой публикации. Например говоря о принципе «Холодной и горячей головы» — сослались на Мартина (автора Чистого кода), что он де об этом уже писал, но когда у меня дошли руки его прочитать, то выяснилось что не совсем так. Да конечно, как о явлении он писал и свой практический опыт изложил. Но он и не пытался анализировать почему так происходит и для чего нужна «горячая голова», он просто отбросил это состояние сознания как безусловно вредное.
2. Вы упомянули сухо-академический стиль изложения. Буду лично благодарен, если укажете конкретные примеры. Дело в том, что приложил существенные усилия, чтобы сухие академические факты и выводы изложить простым языком и наверное дошел до предела возможностей самопроверки.
Макконела обязательно прочитаю. Но уже после, чтобы не смешивать работы и мысли, уже внес его в планируемые к прочтению книги.
Хорошо написано. Среди комментов сразу выявился адепт «тайного знания», «культа карго» и всего прочего )))
Макконнелл хорошо пишет, грамотно, много приводит ссылок на литературу и исследовательские работы — в этом огромный плюс заграничных книг, в отличие от отечественных, во многих из которых «адепты тайного знания» учат чему-то недалеких молокососов, ссылаясь только на себя любимого и якобы «оригинальное исследование», списанное с карнег и прочих дейлов (не про Вас, автор, но мало ли — мы же не читали еще продолжения). Если приводить конкретику, то Макконнелл описывает подходы к разработке (через тестирование, парное программирование, инспекции кода, прочие методологические механизмы поиска ошибок и, следовательно, повышения качества продукта, определяя, например, парное программирование и инспекцию кода, как лидеров по первоначальному поиску ошибок в коде и минимально потраченному времени, что закрепилось в итоге в CMM), механизмы оптимизации (табличная оптимизация, хеширование, деревья — алгоритмическая составляющая, описанная словами, а не мат.языком). В каждом утверждении он ссылается на опыт крупнейших корпораций (например, замена тестирования инспекцией кода в корпорации Боинг увеличила производительность труда в 8(!) раз). Ну и т.д. и т.п.
Отсюда как бы совет: будьте собой, но не пренебрегайте лучшими практиками. И если что-то утверждаете, приведите пример или ссылку на исследование.
(5) Спасибо за ёмкое описание работ Макконелла. По крайней мере понял теперь что мог иметь ввиду предыдущий комментатор. По этому поводу могу сказать, что с ним пересекаться буду, но не слишком часто.
Во-первых, нет доступа к настолько масштабным экспериментам
Во-вторых он судя по всему работает с внешними источниками, я с собственным опытом.
В-третьих, как можно заметить из предисловия и «захода издалека» к прикладным проблемам, суть исследования моего строилась на поиске причин проблем. Таким образом я не просто говорю что такое хорошо и что такое плохо, а выполняю анализ причин, почему плохо происходит. Т..е начинаю с базиса, а не с внешних признаков.
Ну и в четвертых, есть у меня некоторая психологическая травма от бездумного применения западных «бест практик» на живых русских людях. Возможно это тоже проявление еще неведомого науке культа, который еще ждёт своего исследователя, но фактор это существенно повлиял на решение делать своё исследование, а не верить на слово забугорным спецам.
За совет спасибо, стараюсь, но с оглядкой. Полагаю из текста выше это стало понятнее =)
А есть ли рабочие методики: «КАК» достичь всего этого. А то это все больше похоже на фразу: Пишите код хорошо
(7) Если речь про мануалы типа «how to», то наверное не существует готового и стопроцентного рецепта. Иначе бы и не было это публикации и многих других на эту тему.
Как сказано в предисловии, данный курс рассматривает причины проблем. В следующих лекциях будут предложены «правильные» практики решения проблем, но опять же в тех пределах которые удалось охватить. Как уже отвечал выше, не имея доступа к масштабной экспериментальной базе, сосредоточился на теоретической подготовке. Собственно, это второе (первое для широкой публики) издание курса
(7) «всего этого» — это чего конкретно? Повысить качество разработки? Автор пока говорит так: «проверяй свою работу», ну и советует прогнать создаваемую программу через критерии работоспособности, гибкости и сопровождаемости. Если программа работает, она «гибкая» и «сопровождаемая» (т.е. кто угодно может ее развивать), то качество разработки — высокое.
Но, с другой стороны, всегда есть другие критерии. Например, производительность. Если программа работает, сопровождаема и «гибка», но при этом не удовлетворяет критериям производительности ключевых операций, то она недостаточно качественная (на мой взгляд) и ее нужно допилить. При этом может оказаться, что любой допил будет снижать производительность или не сможет повысить ее до необходимого уровня (например, применена попытка перебрать все варианты при раскладке/разрезке/упаковке, а это факториал от количества вариантов в пределе, при этом система просто ищет луший из всех вообще — тут никакой подход не сможет помочь, ибо при сотне вариантов время операции будет уходить в бесконечность). Как бы мораль: если не знаешь алгоритма, можешь и не решить проблему, при том создав сопровождаемую, «гибкую» и работающую на 10 тестовых элементах программу.
(9)
Работоспособность это и есть внешнее качество программы — насколько она соответствует стоящим перед ней задачам, как она выглядит снаружи, как взаимодействует с железом. Недостаточно развернул определение работоспособности. Спасибо.
Про зависимость свойств между собой писал отдельно. Программа может хорошо выполнять свою работу, но быть абсолютно негибкой и с трудом сопровождаемой . В остальном же согласен. Именно это и хотел сказать. Мы формулируем для себя простые критерии оценки, а далее в зависимости от требования момента и собственных способностей проводим эту самую оценку.
(9)
Сдаётся мне, что есть способы обойтись без полного перебора. По краней мере ест ьсмутные воспоминания когда математически какие-то площади и объемы делили и резали на нужные куски. Но это надо Ильдаровича призывать и создавать отдельный топик =)
(11) необязательно. Фактически существует несколько алгоритмов, которые в той или иной степени способствуют решению данного класса задач с некоторыми допущениями. Есть простой алгоритм «в лоб» — жадный, с помощью которого у того же Ильдаровича реализован пример 3д-упаковки в запросе. Я в своей статье сформулировал данный принцип просто: «бери больше — кидай дальше». Алгоритм далеко на оптимальный, но есть возможность через дополнительные перестановки улучшить показатели. Есть различные варианты генетического алгоритма и алгоритма «отжига», при котором используется свойство атомов кристаллической решетки занимать энергетически самые выгодные позиции. Все эти алгоритмы эффективно позволяют найти локальные минимумы и из них — глобальный, но, конечно же, не всегда. Дальше существуют оптимизации с динамическим программированием, которые ищут максимально лучшие варианты, но при этом используют много памяти.
Но все это говорит больше о том, что программист должен решать задачу не путем меньшего количества строк кода, а путем выбора метода, которые ему более известен, а если методы ему не известны вообще — произвести некоторое дообучение, чтобы не писать гибкую сопровождаемую и работающую программу, при этом через какое-то время упереться в предел ее производительности.
Я считаю, что программист должен знать алгоритмы работы с данными в принципе. Любая программа — это преобразование аргументов функции в ее результат через присваивание (в частности присваивание вычисленного выражения) и ветвление. Все остальное — это детали (например, цикл — это ветвление по признаку окончания цикла, но важно понимать, что цикл можно организовать и с помощью рекурсии, а при обходе дерева такой подход — единственно достойный внимания). В итоге реальный способ повышения качества программ — это прокачка скилов в области обработки данных, когда программист не просто умеет присваивать и «ветвить», но и понимает, в каком случае чего и куда присваивать, а где производить ветвление. И если программист не знает, что в упорядоченном списке можно найти элемент за O(log2N) то это — плохой программист.
(12)
Об это подробнее будет во второй лекции.
(12)
Нельзя не согласиться. Можно добавить ещё знание ходовых структур данных (массивы, связанные списки, графы и т.д.) и особенности их применения.
(12)
Судя по Вашим прошлым комментариям здесь опечатка (когда имеется ввиду массив и классический binary search).
(14)
Здесь имеется ввиду любой упорядоченный список. В нем найти элемент гарантировано можно за Log2 N итераций, где N — количество элементов в этом списке. Что имеете ввиду Вы — не ясно.
(15) Я имею ввиду то, что описанную Вами задачу нельзя решить с указанной сложностью. Если бы в Вашем условии было написано «массив» вместо «списка», тогда задача сводится к простому . Просьба поправить меня, если не прав, приведя описание алгоритма с указанной оценкой сложности для следующего примера: найти заданный элемент в односвязном упорядоченном по возрастанию значений элементов списке мощностью N (), имея ссылку на его первый элемент (head node). Более детально: имеем односвязный список 1->2->3->…->100 и ссылку на его первый элемент (на 1->) — нужно найти элемент со значением 80 за log2 N (log2 100) итераций.
(16) Навскидку из примитивного — метод половинного деления -вполне уложится в этот норматив
(17), выше по ссылке binary search — .
(18) То что ссылка была я заметил, только удивился зачем использовать англоязычный термин при наличии русского аналога. Вопрос то вы задавали другой, что двоичный поиск не справится с задачей в рамках норматива log2 N, тогда как даже небольшой умственный эксперимент показывает обратное.
Или мы вас оба неправильно поняли или вы неправильно поняли условие задачи
(16) все зависит от того, что называть списком. И зачем спорить с утверждением и тут же его приводить? Странным не находите?
(17) Ну вот, хранители «тайного знания» атакуют, ибо «список» для них — это элемент с одним или двумя указателями (вперед/назад). При том слово «список» вполне может относиться к массиву, таблице значений, списку значений и т.д.. т.е. к тому, что можно получить по индексу. А в списке значений даже слово «список» есть, что хранителей «тайных знаний» все-равно не наводит ни на какую мысль, ибо с их точки зрения список значений — не «список» )))
(19) в том то и дело, что не справится — прочитайте внимательно:
— двоичный поиск можно применять только при наличии возможности получения значения элемента за О(1) — поэтому и попросил автора коммента уточнить — не опечатался ли он.
Ссылки на англоязычную страницу вики привожу потому, что там все описано детальнее, к тому же есть ссылка на аналогичную статью на русском (в самой вики слева блок ссылок на других языках).
(21)
Ссылки на англоязычную страницу вики привожу потому, что там все описано детальнее, к тому же есть ссылка на аналогичную статью на русском (в самой вики слева блок ссылок на других языках).
Теперь понял, что ты ввиду имел. Для односвязного по определению двоичный поиск не будет работать. Но опять же вопрос — где в 1с есть односвязные списки в которых нужно искать значение? Мы же всё таки про 1С говорим. Нужно отделать мух от котлет, и не заниматься буквоедством, иначе за отдельными фактами не увидим суть.
Вообще тема алгоритмов очень обширная и было бы интересно и полезно провести практическую работу по адаптации различных алгоритмов (того же поиска) к прикладной специфике 1с. Есть желание взяться?
(20)
— да, это то, о чем я писал в первом комменте. Если для Вас список — «CписокЗначений» в контексте 1С, тогда вопросов нет.
(22)
— поэтому и уточнил что автор коммента имеет ввиду под списком — оказалось .
(22)
— думаю о «курсе по теории и практике программирования» — и конечно в контексте 1С — ведь мы на Инфостарте 🙂
(22)
— полностью согласен, при этом термины должны трактоваться однозначно и уточняться при необходимости.
(22)
— идея интересная, но на текущий момент выделить на это время не смогу.
(24)
Даже по приведенной ссылке есть следующее:
Если у списка есть селектор и он упорядочен, то поиск в нем нужного значения можно произвести с приведенным количеством сравнений.
(23) А по поводу «адаптации» алгоритмов к 1С, то это уже сделано неоднократно. От жадных алгоритмов до нейронных сетей. Достаточно поиска по сайту (хотя, конечно, куда проще найти нужную статью в гугле на этом же сайте, чем воспользоваться поиском внутри, ибо о релевантности создатели ресурса знают куда меньше).
(25)
— да, выше на это и обратил внимание (написал см. Возможности доступа). Там же написано «Термином список также называется несколько конкретных структур данных, применяющихся при реализации абстрактных списков, особенно связных списков.» — аналогичная ассоциация у меня с института, в профильной литературе тоже под списками как правило понимаются именно связанные списки.
(25)
— то он обычно называется .
Заинтриговали. Где подписаться, что бы читать дальше?
(27) Не уверен что это единственный способ, но можно добавить в друзья. В данном случае приходят уведомления новых публикациях.
******Внимание******
Вторая лекция будет опубликована в субботу. Форматирование текста для сайта занимает довольно много времени, поэтому отложил дату публикации
Написано все правильно и даже неплохо. Все будут согласно кивать головами и хлопать по плечу.
Но полезность для кого бы то ни было — весьма сомнительна, как по мне. А уж называть «учебным курсом» — излишне самонадеянно.
Это ведь не для опытных прогов. Им это не нужно, они и так это знают, впитав «потом и кровью» на «продакшене».
Значит, для новичков? Но новичкам нужны не общие фразы вида «не делай плохо, делай хорошо». Им нужно как можно больше живых примеров и конкретных руководств к действию. Прочитать того же Макконелла будет гораздо полезнее, как по мне.
(30)
Не без этого, но наряду с кризисными явлениями в отрасли, явно видны и попытки преодоления хаоса. Поэтому не согласен что впустую. Очень много людей в отрасли кто хочет что-то учиться. Много новичков, которые хотят учиться.
— называть что? Введение это не весь курс, это именно введение. Определение терминов и базовых принципов.
Не согласен. Опытным этот курс не менее важен чем для новичков. Также не согласен, что опыт можно измерить годами стажа или литрами пролитых пота и крови. Позволю здесь автоцитату: «Опыт не равен стажу. Это не годы жизни, не пережитые испытания, а то как человек это понял и осмыслил. Стаж получают все, опыт — те кто приложил к этому усилия». Так и в нашем деле, можно выработать условные рефлексы по типу «так делать нельзя, потому что я так сделал на продакшене и было очень плохо», но чем мы тогда будем отличаться от собаки?
В комментариях ко второй лекции уже отвечал на подобный комментарий. Хватает практики, на мой взгляд, даже слишком много голой практики. Также в предисловии курса уже дан ответ на это возражение. Заранее!
(31)
Измерить нельзя. Но корреляция всегда прямая.
Тем, кому стаж не дает опыта, никакие курсы уже не помогут. Такое мое мнение. Это случайные люди в профессии.
(32)
Тем, кому стаж не дает опыта, никакие курсы уже не помогут. Такое мое мнение. Это случайные люди в профессии.
Вот так взял и большую часть трудящейся братии назвал случайными людьми. Я бы обиделся. Не за себя, так за товарищей. Но в прошлом. Сейчас просто объясню.
Нет ничего необычного в ситуации когда длительность стажа, не соответствует объему опыта. Именно по этой причине, существует деление на категории специалистов, на наставников и учеников, на ведущих и рядовых.
Как и в военном деле. Пусть рядовой не знаком с теорией тактики и смутно представляет себе стратегию, но без рядовых бойцов никакое дело не провернуть. Можно конечно изобретать планы и теории и общаться узким кругом «неслучайных» людей, но вся тяжесть практической реализации ляжет на рядовой состав.
Также важно понимать, что рост эффективности в системе: начальник — гений, подчиненные — бараны, быстро упирается в возможности рядового состава. В такой ситуации даже не слишком существенное поднятие уровня подготовки рядового состава, в сумме серьезно повысит возможности всего подразделения. Тогда как поднятие уровня подготовки начальника даже в разы всегда имеет ограничение практической реализации этого уровня.
(33)
Увы, соглашусь.
Но мы про программирование.
А для программиста эта ситуация если не необычная, то ненормальная точно.
Слишком динамичная отрасль и слишком широкое поле знаний. Программист обязан уметь в эффективное самообучение.
А при наличии нужной информации в свободных источниках, курсы — слишком неэффективная форма обучения.
Слишком часто курсы выглядят как полезное времяпровождение для людей, которые книжек не читали, на котором они слушают «откровения» людей, которые их таки осилили. Польза такого времяпровождения для первых — весьма сомнительна. Польза для вторых — несомненна, если курсы платные.
(34)
Блин, а так можно было, да? Хотя так и есть, за эти лекции я свои деньги уже получил, и буду получать. Потому что есть в них и объективная необходимость и несомненная польза, а во всем этом времяпровождении даже экономический смысл в виде повышения производительности труда при сравнительно небольших затратах.
А вообще, подобное восприятие мира — завышенные требования к окружающим, суть когнитивное искажение, смысл которого сводится к ожиданию от окружающих таких же способностей как от себя самого. Другими словами — ошибочное причисление себя к среднестатистическому уровню, тогда как фактический уровень много выше. Кстати есть и обратный пример искажения известный как эффект Данннига-Крюгера. Так что советую перечитать про абстракции и культы.
(33)
В западной практике сотрудник растет до того момента, до которого позволяет его уровень компетенции. Именно из-за этого часто на руководящих должностях в больших компаниях сотрудники уже доросли до своего предела и с трудом справляются со своей текущей работой, иначе они бы продолжили расти.
По поводу профессиональной карьеры, то всегда есть два варианта развития: вертикальный и горизонтальный рост. При вертикальном росте происходит «прокачивание» навыков работы с другими сотрудниками, умение ставить задачу, умение следить за ее выполнением, умение писать отчеты, которые понятны следующему уровню руководителей, умение, наконец, создавать стоимость. При горизонтальном росте сотрудник растет за счет повышения уровня компетенции в прикладной специфике: джуниор, мидл, синьор, тимлид, архитектор, технический директор… Всегда есть возможность из программиста уйти в РП, если программировать не особо получается, а вот из РП в программиста уйти куда сложнее…
Хороший стиль, отсутствуют ляпы. Даже ошибок пунктуации (почти) нет. 🙂
Есть позитивное отличие от всяческих Макконнелов, Мартинов и даже Брукса. А именно: западные авторы вынужденно «заточены» на дебиловатых читателей. Им приходится многократно повторять одно и то же, чтобы у читателя, которого думать в школе не учили, хоть что-то в голове застряло. Это «одно и то же» в большинстве случаев оказывается правильным, но в итоге — замшелый догматизм, порождаемый некритичным восприятием (и сопоставлением с действительностью) текста.
К счастью, автору пока еще позволено адресоваться к людям, нормально мыслящим. Пока ЕГЭ окончательно таких людей не вытравил.
(36)
Да, буквально недавно мне коллеги рассказывали про такой парадокс. Но ведь и лечение известно — вернуть человека туда, где он будет справляться. Конечно для руководителя это непростая задача — сделать это мягко и не травматично, но и цена вопроса высока. По крайней мере, когда мне приходилось заниматься управлением, я всегда уделял особое внимание движениям персонала вверх и вниз. Кто перерос свой уровень — должен быть поднят. Кто не тянет текущий — идет ниже.
Быть хорошим разработчиком это не «руками водить» тут думать надо =)
(38)
А это не парадокс, а суть мировосприятия западной цивилизации. Т.е. если достижения получены, то они должны остаться. При этом понижение в должности в современном формате скорее всего приведет к тому, что вполне полезный сотрудник уйдет, на его место придется повысить кого-то, кто пока еще недостаточно тянет, а не место того взять или повысить еще кого-то — трудная задача выбора, ибо в любом случае теряется текущая производительность организации, но при замене сотрудника она теряется сильнее, а долгосрочная перспектива в западной модели рассматривается с трудом…
Япония, например, решает проблему просто — человек всю жизнь растет в должности, а нехватка компетенции восполняется потоком снизу новых идей и людей, которых не тормозят, а доводят до того уровня, где будет принято решение. Именно по-этому японская модель придумала такие штуки, как кан-бан, и это придумали не руководители, а обычные работяги (у них там есть «кружки качества», в которых состоят три-пять сотрудников в самом низу, и они после ВУЗов и прочих техникумов удаль молодецкую тратят на рацио, которое руководство всегда старается применить для пользы дела, а не заворачивает со словами «молодо-зелено», как это делают у нас).
Прошу прощения у всех кого заставил ждать новой лекции. Успокою. Лекция будет. После публикации первых двух и чтения третьей лекции для общественности получил настолько богатую обратную связь, что несколько увлекся.
Впрочем, от этого была и польза. В ходе обсуждения было поднято столько вопросов, что раскрыть их в комментариях было невозможно. Поэтому, по совету коллег, принял решение собрать материалы по контексту в котором создавался учебный курс. Собранный материал станет основой для доклада на Infostart Event. Данный доклад станет ответом на многочисленные вопросы зачем этот учебный курс, какие задачи он выполняет и почему он именно такой. На данный момент материалы собраны, доклад отправлен на голосование и я могу вновь вернуться к переработке лекций в текстовый формат.
Автор, почему не применяешь свои советы к стилю написания статьи?
Это точно? Это мнение специалиста по данной теме по эволюционной биологии, генетике, психологи и т.д? Есть ли другие мнения у специалистов по этой теме ? Сколько раз воззрения на эту область поменялись за последние 100 лет? Зачем читающему эту статью это знать?
(41)
Чтобы каждая более-менее разумная обезьяна понимала, откуда у нее эти тараканы в голове, и что это не лечится, но с этим можно жить.
(42) но это ведь не точно, да ? 🙂
(43) Если будет время и желание, то поищу ссылки на соответствующие антропологические исследования. Ну а экспериментально легко подтверждается в ходе наблюдения за развитием детенышей и их становлением в полноценных людей.
(44) большинство состояний лечится.
(45) Я бы так не сказал. Можно научиться жить с чем-то. Но это как неизлечимая болезнь, с периодами ремиссий и сезонных обострений. Так называемый человек, своим поведением от обезьяны, только за счет многолетнего нахождения в социуме. Помести человека в дикую среду, и большая часть людей деградирует за удивительно короткий срок, меньшая — за больший. Но уже следующее поколение будет диким.
Также, у человека есть ряд особенностей по сравнению с братьями-обезьянами, которые с одной стороны дали в своё время однозначное эволюционное преимущество, с другой, создают проблемы на высоких этапах развития, не являясь уже однозначным благом:
1. Упорство в достижении непосредственно видимой цели. Когда-то оно было необходимо для методичного создания первых каменных инструментов — та еще работа. В наше время, например, проявляется бюрократизме, педантичности, участвует в формировании «синдрома вахтёра».
2. Упорство во мнении. Единожды сформированное «правильное» мнение, особенно если это мнение пришло готовым от старших по иерархии в группе, очень сложно изменить. Отсюда предрассудки, зашоренность взглядов, фанатизм и др.
3. Гипертрофированная социальность. Про социальные потребности и проблемы их сублимации особо не буду расписывать. Отмечу один важный фактор — интуитивное воспроизведение принятых в сообществе правил поведения. Фактор хороший, если правила в сообществе хороши, но в комментах к третьей статье приводил наглядный пример негативной практики.
Разумеется, человек осознающий себя и обладающий проистекающей из этого осознания волей, способен преодолевать свои инстинкты. Но преодоление инстинктов есть результат постоянной внутренней борьбы врожденных свойств с приобретенными. И это самое «большинство состояний лечится», есть ремиссия вызванная интенсивной терапией, но не полное излечение.
(46)
Ну если говорить о клинических случаях, то психические именно заболевания — да, с ними непросто что-то сделать, но и это лечится при достаточной мотивации со стороны врача и пациента. А вот с психологическими проблемами все проще, но многие ли из нас обращаются к психологу при трудностях? Вот, например, недавно читал про одного из разработчиков языка «котлин» из JetBrains — он рассуждал на тему психоанализа, что ему психолог очень помогал часто и он даже портал для психологов сделал. А Андрей Курпатов в книге про счастье пишет, что на постсоветском пространстве обращаться за профессиональной помощью не принято и типа «сам должен смочь, преодолеть, побороть» и т.д.
А по поводу инстинктов, то преодолевая их и не «заземляясь», получаешь множественные мышечные блокировки, от которых тоже избавиться непросто. Тут уж спорт, движение, напряжение и прочая физическая активность помогают. Я, например, на прошлой неделе в день по часу-полтора на велосипеде ездил не останавливаясь, вчера другу помогал грушу 50-килограммовую дотащить до его дома (до электрички, потом от электрички на мост, с моста, по мостику через ручей и с прочими препятствиями). Так что деятельность физическая должна идти вместе с нагрузкой умственной, и непросто тем, у кого с физической нагрузкой трудности, в программировании…
Даже если Вы опишите прописные истины типа «Пишите код хорошо». С удовольствием прочитаю весь курс. Написано легко. Ожидаю в курсе не столько ссылки на авторитетов, а примеры из личного опыта и рабочей практики, возможно с курьезами и легким юмором.
Мне кажется, или комментарии интереснее статьи?))
(49) Так это же хорошо. Комментарии обогащают и дополняют материал. Прочтение статьи без прочтения комментариев, сделает впечатление неполным.
Однако, это не мешает крупным кампаниям зарабатывать на сакрализации образа бренда, например ифон, автопроизводители при снижении качества и ремонтопригодности автомобилей продолжают удерживать цены на высоком уровне и получать сверхприбыли. Так почему бы не поддерживать сакральность деятельности программиста и не повышать порог входа, ведь это путь успешных?