4 ключевые идеи программирования
#py_basic

Мой путь к написанию кода за деньги, а не просто как хобби, был долог и тернист. К настоящему моменту я пробовал программировать на 10 разных языках, включая Python, Java, C++. Когда я (несколько лет) преподавал Питон с нуля, я обычно начинал с того, что знакомил студентов с четырьмя "ключевыми идеями программирования". Если хорошо усвоить эти идеи, то можно научиться писать код любой сложности, так как всё остальное, что есть в программировании, - лишь надстройка над этими четырьмя идеями.

1. Функции - это действия, которые умеет выполнять ваша программа. Программу можно представить в виде робота, который умеет, например, танцевать, делать уборку, ходить в магазин за хлебом и т.д. Все эти "умения" робота - это функции. Отдельно взятая сложная функция может состоять из более простых функций (действий). Например, функция "сходить за хлебом" может состоять из действий: "взять деньги", "построить маршрут до магазина", "дойти до магазина", "найти в магазине хлеб" и так далее.

2. Переменные - это то, как программа хранит знания о мире. Говоря образно, это такие коробочки с этикетками, на каждой из которых написано название. То, что написано на коробке, - это название переменной, а то, что внутри коробки, - это содержимое, которое переменная хранит (числа, текст, или более сложные объекты). В почти любой программе есть свой "склад коробок" - это все переменные, в которых хранятся знания о мире, заложенные в программе. Следуя нашему примеру про поход за хлебом, можно представить себе переменную-коробку с этикеткой money. Тогда внутри этой коробки должно лежать число, которое обозначает, сколько у нас есть денег.

3. Ветвления - это логика принятия решений внутри нашей программы. Её можно представить в виде простых правил, на которые наша программа-"робот" ориентируется при совершении действий. Например, наш робот решает, покупать ему французский багет или нет. Он может сравнить стоимость багета (которая, допустим, "лежит" в коробке-переменной baguette_price) с количеством денег, которое у него осталось (переменная money). Если стоимость хлеба ниже, чем количество оставшихся денег, то нужно покупать. Конечно, логика робота может быть сколь угодно более сложной. :)

4. Циклы - это просто многократное повторение одних и тех же действий. Например, пока робот не нашёл подходящее хлебо-булочное изделие, он должен идти вдоль витрины и оценивать каждый товар в ассортименте. Когда хлеб найден, нужно прервать цикл (ведь дальше искать нет смысла) и идти к кассе оплачивать товар. Ещё может быть "маленький" цикл (оценить сегодняшний ассортимент в магазине) внутри "большого" цикла (каждый день ходить в магазин). В заключение можно вспомнить фильм "День сурка", где герой, по сути, застрял в бесконечном цикле, но в результате выполнения определённых действий ему всё-таки удаётся "вырваться".

Как найти первую работу программистом
#career

Несмотря на большую нехватку разработчиков / специалистов по машинному обучению на рынке труда, найти первую работу даже с хорошими знаниями и навыками, но без опыта, бывает очень сложно. Зато с опытом - почти без проблем. Поэтому найти свою самую первую работу программистом - это как будто бы самый сложный квест в этой игре, после которого всё становится гораздо легче. Как же преодолеть этот порог? На мой взгляд, есть четыре основные "точки входа" в профессию, связанную с написанием кода (то есть это не абстрактное "войти в IT", я не говорю про HR-специалистов, менеджеров по управлению проектами, дизайнеров и так далее).

1. Стажировки в крупных компаниях. Здесь обычно бывает жёсткий отбор, плюс на рынке не так уж много компаний, готовых растить стажёров. Однако на мой взгляд, это самая классная и престижная точка входа. Даже если стажировка неоплачиваемая, но компания хорошая, а у вас нет опыта работы по специальности, - стоит попробовать.

2. Работа в стартапах. Вы удивитесь, насколько ниже порог входа в стартапах и маленьких компаниях, чем в больших корпорациях (даже на позицию стажёра). Дело в том, что у молодых стартапов зачастую нет возможности платить адекватную рынку зарплату, и тогда они готовы нанимать и без опыта (но знания и навыки, конечно же, всё равно нужны).

3. Опен-сорс. Многие проекты с открытым исходным кодом страдают от нехватки людей, готовых бесплатно их улучшать и исправлять баги. Если вы станете контрибьютером в таком проекте (а там не обязательно очень сложные задачи, бывают и относительно простые), то вам точно будет о чём рассказать на собеседовании. Также это может быть довольно престижно, если проект/библиотека/фреймворк пользуется известностью.

4. Собственные проекты. Если вы никогда не писали код за деньги, это вовсе не значит, что у вас не должно быть классных пет-проектов. Нужно постепенно накапливать сильное портфолио, при этом важно уметь интересно рассказать о том, какие возникали сложности и что в итоге получилось круто. Знаю студентов, которые на собеседованиях так здорово рассказывали о своих курсовых работах, что их нанимали даже без опыта.

Зачем учиться решать алгоритмические задачки?
#career

Ответ на этот вопрос, наверное, очевиден: чтобы прокачать своё алгоритмическое мышление и (как побочный эффект) легче устраиваться на работу.

История из жизни. Я работаю в своей уже четвёртой по счёту IT-компании. В двух из них при прохождении отбора мне приходилось решать алгоритмические задачи. Часто задачи используют как скрининг, особенно (в моём опыте) в зарубежных компаниях. То есть сначала решаешь за ограниченное время пару задач на специальной платформе, а потом, после проверки решений, тебя приглашают на технические собеседования. (Кстати, в одной компании у меня собеседований было целых шесть, но вообще-то такое бывает редко. Во многих компаниях делают оффер после 1-2 собеседований.)

Иногда задачи приходится решать прямо на собеседовании. На самом деле, это не так уж и страшно, потому что у интервьюера можно уточнить непонятные моменты, а иногда и получить подсказку, когда идёшь в явно неверном направлении.

Если вам тяжело даётся решение задач, особенно на время или в присутствии других людей, не переживайте, это вопрос практики. К тому же многие задачи однотипны и решаются похожими приёмами. Хорошо, что есть платформы наподобие LeetCode, на которых есть много задач разных уровней сложности и автопроверка, там каждый может постепенно повысить свой уровень.

Давайте в следующий раз попробуем решить какую-нибудь не самую простую задачу и вместе разобрать решение!

Кстати, не стесняйтесь задавать вопросы в комментариях. На всякий случай скажу, что я придерживаюсь принципа "глупых вопросов не бывает".

Задача от Google про разложение на полные квадраты
#py_basic

У этой задачи есть история. Моя знакомая (она NLP / бэкенд-разработчик) много гуглила по работе, и поисковик однажды предложил ей решить несколько задач на программирование. Оказывается, Google следит за вашими поисковыми запросами не только для того, чтобы показывать вам более релевантную контекстную рекламу. Если вы много гуглите про бэкенд-разработку, то Google может предложить вам такой челлендж. Если его успешно пройти, то дальше зовут на собеседование. Там было несколько задач, я покажу вам самую первую из них. Она не сложная, но сможете ли вы решить её эффективно?

На входе положительное целое число, нужно разложить его на сумму квадратных чисел так, чтобы слагаемых было наименьшее количество. Слагаемые-точные квадраты нужно расположить в списке в порядке убывания. Например, если нам пришло число 7, то нужно разложить его на [4, 1, 1, 1], но не на [1, 1, 1, 1, 1, 1, 1] (не наименьшее количество слагаемых), не на [5, 1, 1] (первое число не является квадратом целого числа), не на [1, 4, 1, 1] (неправильный порядок) и так далее. Ещё несколько примеров:

12 -> [9, 1, 1, 1]
16 -> [16]
1 -> [1]

Завтра покажу решение и сделаю разбор.

Задача на разбивку слитной строки на слова
#py_advanced

Специально для тех, кому предыдущая задача показалась простой, взял более хитрую с LeetCode: https://leetcode.com/problems/word-break/
Она отмечена как задача средней сложности. Такую вполне реально получить на собеседовании на джуновскую или даже мидл-позицию (как скрининг).

На входе слитная строка наподобие "мамамылараму" и список слов, например, ["раму", "мама", "мыла"]. Нужно вернуть True, если строку можно разделить на заданные слова так, чтобы не было пересечений и не оставалось неиспользованных символов. Слова можно использовать сколько угодно раз. В противном случае нужно вернуть False. Примеры:

"мамамылараму", ["раму", "мама", "мыла"] -> True
"мамамылараму", ["раму", "мама", "мыла", "дома"] -> True
"мамамылараму", ["мама", "мыла", "дома"] -> False
"мамамылараму", ["лараму", "мама", "мыла"] -> False
"мамамылараму", ["раму", "мама", "мыл"] -> False
"мамамамамама", ["ма", "му"] -> True

Решение и разбор - завтра.

Dive into Deep Learning
#ml

И напоследок на сегодня хочу поделиться, недавно наткнулся на полезнейшую книжку по машинному / глубокому обучению:
https://d2l.ai/

Почему рекомендую:
* Написал крутой коллектив учёных из Amazon
* Книга бесплатная (но на английском)
* Отлично подходит для начинающих, будет интересна и продвинутым
* Актуальные примеры кода на современных фреймворках
* Книгу постоянно обновляют, она не должна быстро устареть
* Пишут, что её уже используют в 400 университетах в 60 странах мира

Прочитал несколько глав для ознакомления, мне понравилось.

Я выложил решения и разборы двух вчерашних задач, ищите их в комментариях к соответствующим постам.
Лучше, конечно, сначала попробовать решить одну или обе задачи самостоятельно, а потом сравнить с моими решениями.
Буду рад, если поделитесь впечатлениями от задач или прокомментируете мои разборы)
Завтра выложу полезные советы из своего опыта о том, как решать задачи.

Как научиться хорошо решать алгоритмические задачи?
#py_basic #py_advanced

Мы уже говорили о важности решении задач для развития алгоритмического мышления и подготовки к собеседованиям. Затем я предложил вам пару задач разной сложности с последующим разбором, знаю, что некоторым из вас удалось их решить. Теперь поделюсь лайфхаками из своего опыта - надеюсь, что они помогут вам научиться хорошо решать алгоритмические задачи и чувствовать себя увереннее на собеседованиях.

1. Когда начинаете решать новую задачу, рекомендую сначала разобрать её на бумаге, нарисовать схему, диаграмму, таблицу и т.п. Я считаю, что это самый важный шаг (и навык) - так обычно получаются более эффективные решения, чем если сразу садиться писать код.
2. При этом часто помогает вопрос: "а как человек (а не компьютер) решал бы эту задачу?" Вручную пошагово разобрать несколько примеров ввода, от простых до более сложных.
3. Если за 10-15 минут не появилось идей (иногда полезно и дольше поломать голову для тренировки), нужно сесть за код и попробовать запрограммировать хотя бы неполное решение, начав с простых случаев. Обычно в процессе этого приходят новые идеи.
4. Если на одних примерах ваше решение работает, а на других нет, это уже большой прогресс. Дальше нужно просто разобрать сложные случаи и понять, как их включить в ваше решение, сделав его более общим.
5. Если задача "не поддалась" за час-два и вы устали, лучше сделать перерыв и отдохнуть. Мозг так устроен, что он не может очень долго напряжённо работать над одной сложной задачей. Возможно, задача пока что вам не подходит и нужно какое-то время порешать более простые задачи, либо вы её всё-таки решите за несколько дней в "фоновом" режиме. И то, и другое - хорошо.
6. Не нужно ругать себя, если не получилось решить, потому что это нормальный процесс саморазвития. Помните, что мозг лучше всего учится на неудачах. Настоящая цель - не решить задачу, а повысить свои навыки.
7. Рекомендуют подбирать себе задачи таким образом, чтобы было где-то 15% неудач. Это оптимальный уровень сложности, когда из, скажем, 20 задач вы можете решить 17, а остальные не можете. Если процент успеха выше, значит, вы недостаточно себя нагружаете и ваш прогресс идёт медленнее, чем мог бы. Если же процент успеха ниже, значит, вы выбираете слишком сложные задачи, а это опасно для вашей мотивации и самооценки.

Ну и достаточно пока о задачах) В ближайших постах поговорим на другие темы.

Что нужно показать на собеседовании по машинному обучению?
#ml #career

Из опыта прохождения и проведения многочисленных собеседований в сфере ML могу сказать, что чаще всего интервьюеры хотят видеть в вас следующее:

• Чёткое понимание того, как происходит машинное обучение - градиентный спуск, типичные постановки задач в ML, функции потерь, недообучение / переобучение (bias / variance), валидация моделей, правильная методология проведения экспериментов.
• Опыт или хотя бы теоретическое знание методов решения различных проблем с данными: шум, выбросы, несбалансированность, низкая репрезентативность, повторы, слишком мало данных, слишком много данных и т.д.
• Знание и опыт применения основных современных и классических моделей в вашей области, будь то обработка структурированных данных или же естественного языка, изображений, звука.
• Не всегда, но довольно часто желателен опыт создания микросервисов, оптимизации моделей, мониторинга ML-приложений в продакшне.

Всё это, конечно, желательно демонстрировать на конкретных примерах из своей предыдущей работы / личных проектов. Так вы лучше продемонстрируете уверенное владение "матчастью". Не "проблема X решается методами Y1 и Y2", а "когда в таком-то проекте наша команда столкнулась с проблемой X, мы сначала применили метод Y1, но он оказался неэффективен по такой-то причине, поэтому мы перешли на метод Y2, и это привело вот к таким результатам". Так можно раскрыть больше деталей. Детали - ваши друзья, они не только свидетельствуют о вашем реальном опыте решения сложных проблем, но и делают ваш рассказ более живым и запоминающимся в глазах интервьюера. А это важно, потому что нас с вами (пока что) оценивают на собеседованиях живые люди, а не беспристрастные машины)

Пока остановлюсь на этом. Тема технических собеседований очень объёмная, буду постепенно раскрывать её в следующих постах.

Что важнее, модель или данные?
#ml

Как известно, суть машинного обучения в том, что мы не сами программируем логику принятия решений, а показываем машине довольно большое количество примеров, на которых она должна научиться решать ту или иную задачу. Многие инженеры по машинному обучению, с которыми я работал, считали, что главное в достижении хороших результатов - это применять самые свежие алгоритмы и трюки из научных статей. Другими словами, добиваться прироста качества за счёт изменений (часто - усложнений) в ML-модели. "Давайте возьмём нейросеть побольше!" Но нередко случается так, что недели и месяцы уходят на реализацию новых моделей и эксперименты с ними, при этом качество выполнения задачи не повышается или повышается несущественно - на 0.1-0.2%. Небольшой выигрыш в качестве может стоить значительных вычислительных ресурсов, что может быть неприемлемо в продакшне.

В последние годы набирает популярность другой подход, фокусирующийся на данных, а не на модели. По-английски его называют "data-centric machine learning". В нём задачу ставим чуть иначе: что, если наша модель уже достаточно хороша и мы просто должны показать ей более правильные и качественные примеры, чтобы она лучше научилась решать задачу?

В одной из компаний, где я работал, мы решали довольно трудную задачу классификации коротких текстов на японском языке. Классов было довольно много, некоторые из них были очень похожи, обучающих примеров было мало, и в результате всего этого наши нейросетевые модели плохо работали. Эксперименты с разными архитектурами мало помогали, поэтому я предложил применить подход, ориентированный на повышение качества датасета. Что мы сделали:

1. Анализ ошибок нашей модели. Валидационные примеры, которые не удаётся правильно классифицировать, часто могут выявить систематические проблемы обучения, сказать о том, чего не хватает в обучающих данных. Нам это помогло понять, какого рода тексты обычно относятся моделью к неверным классам, что между ними общего.
2. Построение матрицы ошибок (confusion matrix). Это ответило на вопрос, какие классы наиболее часто путает модель. По результатам мы добавили в обучающий датасет примеры, лучше разводящие между собой именно эти классы.
3. Сравнение качества модели с тем, насколько хорошо человек справляется с такой же задачей. Дали экспертам примеры из валидационного сета для ручной разметки, увидели, что люди тоже допускают немало ошибок и путают некоторые классы. Это помогло снизить нереалистичные ожидания от модели, а также пересмотреть принятую систему классов.
4. Очистка датасета от "плохих" примеров. Эксперты просмотрели датасет на предмет того, какие примеры (с человеческой точки зрения) слишком неоднозначны. С другой стороны, применили и автоматические методики поиска неадекватных примеров, основанные на методе ближайших соседей (сейчас я бы применил ещё и метод TracIn от Google).

Всё это в совокупности помогло значительно повысить точность классификации - с 0.47 до 0.85 - и практически "вернуло жизнь" проекту. Временные затраты были относительно невелики, к тому же значительная часть работ выполнялась экспертами-лингвистами, что позволило высвободить ценное время ML-инженеров.

Пишите в комментариях, о чём было бы интересно прочитать в следующих постах!

Наткнулся на полезный ресурс, делюсь:
https://github.com/Extremesarova/data_science_resources
Репозиторий в GitHub с обучающими материалами для дата-сайентистов и ML-инженеров. Собраны в одном месте ответы на вопросы для собеседований, бесплатные курсы, тьюториалы, шпаргалки и т.д. Все материалы упорядочены по темам. Многое на английском (как и сам репозиторий), но часть - на русском.

Мой любимый способ борьбы с синдромом самозванца
#soft_skills

Как известно, синдром самозванца - довольно распространённая проблема. Даже матёрые специалисты нередко от этого страдают. Есть, конечно, тиражируемый совет "fake it until you make it": просто не показывай, что ты чего-то не знаешь, притворяйся уверенным в себе, а настоящая уверенность якобы придёт со временем. Лично мне такие манипулятивные подходы совсем не по душе. Думаю, ни к чему хорошему такие игры не приводят.

Мне больше нравится такой способ. Когда накатывает чувство неуверенности и сомнения в себе, нужно сказать себе следующее:

1. Я знаю, что у меня пока не получается <задача_А> и есть пробелы в <навык_Б>.
2. Однако я уже неплохо умею <навык_В>, <навык_Г> и <навык_Д>, а также справляюсь с <задача_Е> и <задача_Ж>.
3. Я готов учиться решать <задача_А> и знаю, что нужно сделать, чтобы лучше освоить <навык_Б>

То есть:

1) честное признание своих текущих ограничений,
2) опора на свои сильные стороны и уже сделанный прогресс,
3) целеполагание.

Правда работает.

И ещё, не нужно сравнивать себя с другими - если уж хочется сравнивать, то лучше с собой же год назад.

Проклятие правил (часть 1/2)
#ml

Когда имеет смысл для решения бизнес-задачи применять машинное обучение, а когда это того не стоит? С одной стороны, если задача не очень сложная, то быстрый результат можно получить и без ML, построив систему на правилах (эвристиках). Для этого нужно иметь некоторую экспертизу в решаемой задаче и уметь описывать логику принятия решения на формальном языке, будь то Python, регулярные выражения или что-то ещё.

Пример из личного опыта. Когда-то давно я работал преподавателем английского. Однажды мне захотелось заменить скучные языковые упражнения из учебника на более интересные. Я подумал, что дело не в самом формате упражнений - вставить пропущенные слова, выбрать правильную форму глагола, подходящуе по смыслу и т.д. - а в их содержании. Например, вместо текстов про банальных Джона и Мэри можно было бы взять более интересные студентам темы: музыку, спорт, Гарри Поттера и т.д. Но составлять упражнения вручную не хотелось. Зная Питон, я за несколько вечеров написал прототип автоматического генератора упражнений на основе любых текстов на английском. Программа ранжировала тексты по сложности на основе количественных показателей (средняя длина предложений и слов, средняя частота слов), затем выбирала в текстах интересные слова и контексты для создания пропусков, после чего форматировала тексты в виде упражнений. В первой версии программа поддерживала всего три вида упражнений, но её уже можно было использовать в учебном процессе. Получив первые результаты, я стал постепенно улучшать генератор: добавлял новые виды упражнений и совершенствовал алгоритм оценки сложности текстов. Всё это безобразие работало довольно хорошо без какого-либо машинного обучения, только на правилах. (Кстати, это был мой первый серьёзный проект в natural language processing, хоть и некоммерческий, т.к. программа распространялась бесплатно. Зато я сделал по нему несколько научных публикаций в 2014-2015 гг.)

Однако, как известно, есть много сложных задач, решение которых практически невозможно автоматизировать на достойном уровне качества без использования машинного обучения: машинный перевод, генерация изображений по текстовому запросу, распознавание речи и т.д. Странно было бы пытаться решать подобные задачи с помощью правил, написанных экспертами вручную (хотя такое порой пытались провернуть на ранних этапах развития искусственного интеллекта). А что нужно для машинного обучения? Хороший набор обучающих данных: чем он чище и полнее, тем лучше на нём обучится алгоритм. Для действительно сложных задач, которые решаются большими нейросетевыми моделями, конечно, нужно ещё обеспечить достаточные вычислительные ресурсы, но об этом мы поговорим как-нибудь в другой раз.

Проклятие правил (часть 2/2)
#ml

Так значит, всё просто? Для сложных задач размечаем датасет и используем машобуч, а для относительно простых - придумываем хорошие эвристики? Проблема в том, что во многих компаниях неверно оценивают сложность задачи и начинают решать её системой правил, думая, что это "дёшево и сердито" и что так будет всегда. Поначалу всё выглядит неплохо: правила позволяют быстро получить какой-то приемлемый результат, а для дальнейшего улучшения системы, как кажется, нужно всего лишь учесть в правилах все возникающие исключения. Но это очень большое "всего лишь". Проклятие правил в том, что чем сложнее становится система, тем труднее и дороже её становится поддерживать. Штат экспертов, пишущих правила, постоянно растёт, как растёт и время, необходимое для обучения новых сотрудников (чем больше система правил, тем дольше в ней приходится разбираться даже опытному человеку). А допускать ошибки в таких системах становится всё легче. При этом у руководства компании может возникнуть ощущение, что раз в эту систему уже вбухали столько ресурсов, то нужно её развивать и дальше, а не отказываться от неё в пользу чего-то другого (например, машинного обучения). А тут на рынке появляется новый стартап, который с самого начала решал эту задачу как задачу машинного обучения. И вот он уже обходит компанию, которая за несколько лет на рынке вложила в свой продукт огромные ресурсы.

В качестве наглядной иллюстрации приведу ещё один пример из опыта. В одной из компаний, где я раньше работал, был матёрый программист, который в течение года разрабатывал систему правил для извлечения именованных сущностей (имён людей, географических локаций, названий компаний и т.п.) из текстов. Он работал над этой системой год. В ней была сложная логика, написанная на Джаве, использовались разные хитрые словари и списки исключений, а запуск полного цикла тестов занимал целую ночь. В конце концов автору системы и его начальству стало очевидно, что уровень качества распознавания всё ещё недостаточно высок, все исключения учесть невозможно, а любое изменение в раздувшейся до невозможности системе вызывает больше новых ошибок, чем исправляет старых. В результате компании всё равно пришлось переходить на ML, но уже было впустую потрачено слишком много времени и ресурсов.

Такие вот дела. Вывод: используйте правила для несложных задач, но используйте их с умом и помните, что иногда они становятся проклятием.

Как мотивировать себя? Три ошибки
#soft_skills

Меня просили написать о мотивации. Это вообще одна из самых важных тем. Откуда брать силы на изучение новых технологий и саморазвитие? Что помогает, а что мешает нашей мотивации? Как поддерживать себя, когда хочется сдаться и всё бросить?

TLDR:
1. Мотивация - не причина, а следствие
2. Фокус на процессе (приложении усилий), а не на результате
3. Подбадривание себя, а не самокритика

Есть несколько ошибок, которые легко допустить. Первая из них - думать, что мотивация является причиной, а не следствием. Тот, кто так думает, откладывает своё развитие на потом, "когда будет подходящее настроение". Этот момент может и не наступить. Мотивация - результат осознанных усилий с чётким пониманием цели. Преодолеть себя, победить сиюминутную лень, сделать что-то полезное для своего развития - и тогда получить в награду мотивацию. В это, может быть, трудно поверить, но если понаблюдаете за собой, то увидите, что самая сильная и "долгоиграющая" мотивация бывает не перед началом работы, когда ещё ничего не сделано, а после того, как сделали несколько шагов к цели, получили хотя бы какие-то результаты.

Но при этом зацикливаться на результате тоже неправильно, это вторая ошибка. Выучить Питон, поменять карьеру, взяться за трудный проект - звучит страшно и даже невозможно, но если идти к цели постепенно и думать только о непосредственном следующем шаге, то всё обычно получается. Мы движемся вперёд тогда, когда делаем следующий шаг, а не тогда, когда уже дошли. Мне очень сильно помогает измерять свой прогресс не достижениями, а количеством вложенного времени. Парадоксально? Но что зависит от меня напрямую - приложить усилия или получить результат? Только первое. А потраченное время - это хорошая метрика для оценки приложенных усилий. Результат же почти всегда зависит не только от меня, но и от других участников процесса, от обстоятельств, от сложности задачи и так далее.

С этим связана третья ошибка - ругать себя за неудачи. Порой мы для себя бываем самыми жестокими и беспощадными критиками. Это здорово замедляет развитие. Ругать себя - значит лишать себя воли и мотивации. Кстати, доказано экспериментально. Негатива в жизни и так хватает, лучше поддерживать и подбадривать себя, хвалить себя (да, даже так) за прилагаемые усилия и время, вложенное в саморазвитие. Это правда эффективно, как бы наивно ни звучало. Помогает получать положительные эмоции в процессе работы над собой и над трудными задачами. Для хорошей мотивации нужны положительные подкрепления, так устроен мозг. Ежедневные маленькие победы над собой, своей ленью, страхами, заблуждениями приводят к тому, что высокая мотивация превращается в полезную привычку.