761,38
Рейтинг
SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Гамак дривен девелопмент: «Сон — это важная часть работы программиста»

Блог компании SkillFactoryПрограммированиеУчебный процесс в ITClojureЛайфхаки для гиков
Автор оригинала: Рич Хикки
Рич Хикки — создатель языка программирования Clojure, независимый разработчик ПО и консультант с 20-летним опытом работы в различных областях разработки ПО. Примерно 2,5 года в одиночку работал над Clojure, прежде чем кому-либо его показать.

image

Предлагаю вашему вниманию расшифровку доклада 2010 года «Hammock Driven Development»

Это просто доклад, основанный на опыте. Не научный доклад, не будет какой-то методологии, науки или чего-то ещё.

Когда был последний раз, когда вы всерьёз думали о чем-то целый час? Чтобы вас никто не беспокоил и вы могли сосредоточиться. Или целый день? Помните ли вы день, когда вы могли целый день над чем-то думать? Или месяц? Почти всё время думая над чем-то? Или год?

Это чрезвычайно ценные моменты, если они у вас вообще есть. Я считаю, что мне очень повезло, я мог думать о трех разных вещах в течение года или более. Одной из них был Clojure. И нет ничего, что я ценю больше, чем такое время.

Еще одна вещь, которую я хотел бы спросить: «Когда вы в последний раз чувствовали себя уверенно, пытаясь сделать то, чего никогда раньше не делали?» И как вы думаете, что нужно, чтобы стать уверенным в том, чего вы никогда не делали раньше?

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

Поэтому я начну с того, что расскажу о некоторых вещах в области разработки софта, о которых мы все знаем, что это правда.

Автор перевода и субтитров: Константин ProsWeb Проскурня (t.me/ProsWeb)



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

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

Аудитория: Нет.

Вы заметили, что я научился показывать каждый элемент по очереди? Так что теперь вы не знаете, что я собираюсь сказать дальше. Это превосходно. Нет, определенно, абсолютно точно нет.

Наименее дорогостоящее место для исправления ошибок, когда вы проектируете своё ПО.
Что все делают, да?

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

У нас нет хорошего представления о том, что мы делаем, прежде чем мы это сделаем. А потом, быстрей, быстрей, быстрей и мы хватаемся за всё.

У нас есть методологии, и мы чувствуем себя действительно хорошо после этого.

Но если вы всё испортите, как сказал Марк (Mark McGranaghan), в самом начале, то ничего хорошего не выйдет.

Они не являются проблемами реализации. Очевидно есть проблемы с реализацией. И тестирование и другие вещи помогают с этим.

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

Анализ и проектирование


Я собираюсь немного поговорить об анализе и проектировании. Я знаю, что это так устарело, и ужасно, и по праву было раскритиковано, и действительно выброшено. Потому что люди считали, что это связано с процессом, рисованием картинок, знанием всего обо всём и составлением всесторонних планов по Каскадной модели (Waterfall model) и в этом было много всего ужасного. Но это не значит, что шаг перед «иди и сделай это» не является важным шагом.

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

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

Анализ и проектирование — это две вещи: выявление проблемы, которую мы пытаемся решить, и оценка предлагаемого нами решения с точки зрения того, решает ли оно эту проблему или нет. Это действительно то, чем являются эти вещи, а не что-то ещё.

Мы должны решать проблемы. Мы не должны пилить фичи. Решть проблему! Здесь нет ничего про фичи… Что такое фича? Фича — это просто атрибут чего-то. Это блестящая хромированная ручка на чем-то. Не в этом предназначение машины.

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

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

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

Если мы можем найти способ обойти проблему, мы говорим: «Ух ты! Это здорово».

Но это не здорово.

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

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

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

image


Пойа написал эту удивительную книгу под названием «Как решать задачу» в 1945 году, о том, как практиковаться в практике, и каковы методы решения математических задач в этом случае.

Это потрясающая книга, полная глубокого понимания.

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

Одна из вещей, которая не так хороша в этой книге, это то, что она находится в математическом пространстве. В этом пространстве есть действительно хорошая вещь. Когда вы решили проблему, и вы думаете, что у вас есть ответ, у вас есть все методы математического доказательства, чтобы определить, есть ли у вас ответ на самом деле.

У разработчиков софта этого нет.

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

Есть удивительные примеры того, как люди практикуются в вещах, в которых, кажется,
у них нет надежды стать хорошими, но они становятся хорошими в них, потому что они практиковались.

Если вы практикуетесь в решении проблем, действительно практикуетесь в решении проблем, вы добьетесь успеха в этом. Если вы будете практиковать методологию X, вы будете хороши в ней.

Я хотел бы, чтобы вы спросили себя: «Какой лучший способ для достижения цели?»

Мне все равно, что такое X. Выберите любой X, который вы хотите. Вы бы предпочли быть хорошими в этом? Или быть середнячками в решении проблем? Так что нам нужно сделать?

Если мы собираемся работать над решением проблем, на что похожа наша деятельность?

Первое, что нужно сказать: «Я решаю эту проблему. Эта проблема заключается в следующем.
Бла, бла, бла, бла, бла и, следовательно, бла».

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

Если мы не решаем проблемы, я понятия не имею, почему мы находимся в этой комнате. Мы обязательно должны работать над решением проблем, а это значит, что мы должны нумеровать их. И затем с ментальной позиции, о которой я расскажу чуть позже, на самом деле важно произнести проблемы вслух. С позиции человека, который пытается решить проблему.

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

Следующая часть, которая, определенно, сложнее, и книга Пойи великолепна в этом. В ней много практических вещей. Многие из них совпадают с тем, что он сказал — это понять проблему.

Мы говорим: «У нас есть эта проблема. Я думаю, что нам нужна база данных NoSQL». Чего-то не хватает, верно?

«У нас есть эта проблема. Нам нужна база данных NoSQL».

Мы на самом деле не сказали, «почему». Каковы характеристики этой проблемы, которые приводят нас к этому пространству решения? Я думаю, вот в этом и есть вся интересная часть в разработке софта.

Итак, первый шаг: что вы знаете о том, что вы пытаетесь сделать?

Там определенно будет куча фактов. Там будут требования заказчика. Будут другие вещи. Будет контекст: система должна работать на такого рода устройствах, должна работать с такой продолжительностью. больше, чем столько ватт, или должна поддерживать 10 миллионов пользователей. Что бы это ни было. Требования такого плана и такие ограничения. Все эти условия — факты, которые вам нужно учитывать. Там будут вещи, про которые вы сразу же знаете, что вы их не знаете. «Интересно, где мы возьмём данные в качестве входных данных для этой системы?» Или: «Что мы будем делать, когда наш основной источник данных недоступен? У нас есть запасной источник?» Будут такие вопросы.

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

Другая вещь, которую нужно сделать, это сказать, вы знаете, все говорят: «О, делай Х. У меня есть отличная идея для Х». Как будто вы единственный человек в мире, который когда-либо решал эту проблему. Это очень, очень маловероятно, поэтому найдите готовые решения подобных проблем. Есть ли другие, о которых вы знаете? Что вы можете узнать о них?

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

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

Еще одна вещь, которую вы должны сделать: вы должны быть разборчивыми. Вы должны быть критически настроены. В мире ПО нам всем нужно такими быть, потому что есть все эти вещи от сообщества.

Это как, я просто услышал «замечательно». Я бы хотел, чтобы «замечательно» случилось. Я просто слышу это 50 раз на дню. Не все предложения замечательны. Трудно говорить о решениях других людей, которые не являются замечательными. Так что, в основном, сосредоточьтесь на своих собственных проблемах. В частности, когда вы находите решения, когда вы пытаетесь найти решение проблемы, ищите дефекты в своем собственном решении. И, конечно, вы могли бы поговорить об этом, потому что технические ошибки будут. Ошибки в логике будут. Будут также и вкусовщина и личные мнения, проблемы абстракций и тому подобное. Все это связано вместе, хватит на отдельный разговор. Но какие бы проблемы вы ни находили в своих собственных решениях, попробуйте решить их тоже, сразу, заранее.

Итак, другая вещь, которую вы видите:
«О, мы собираемся сделать это».
«О, мы используем базу данных NoSQL».
«Это здорово. У неё есть эти 10 атрибутов. Это потрясающе».

Действительно легко быть в восторге от хороших сторон того, что вы делаете, но вы должны обращать внимание на компромиссы. Шансы на отсутствие компромиссов в любом решении невелики.

Ещё одна вещь в том, «чего вы не знаете?». Если есть вещи, о которых вы знаете,
что вы их не знаете, в этом случае нужно иметь вопросы, которые вы должны задать чтобы узнать, чего вы не знаете. Вы не можете знать всего, поэтому такие вещи должны быть помечены вопросами.

С чем бы вам ни пришлось работать, запишите все эти вещи. На этой странице должны
быть знаки вопроса. Если нет вопросительных знаков, вы пропустите этот шаг.

Другая вещь, о чем вам следует подумать: никто из нас не родился, зная, как писать программы.
Никто из нас не родился, зная про SQL, про Интернет, протоколы или про что-то ещё. И если вы пытаетесь решить проблему, особенно в пространстве, в котором вы еще её не решали, у вас будет очень ограниченная возможность найти решение, если у вас мало информации.

Вам нужно будет получить много разных входных данных, чтобы вы могли позволить своему мозгу вращаться между ними и сказать: «О, да. Эта идея и эта идея связаны друг с другом, и, следовательно, я могу сделать эту другую вещь.»

Если вы возьмете только очень узкий фрагмент «Я точно вижу, что я делаю сейчас, прямо сейчас, чтобы выйти с решением на следующей неделе» у вас не будет достаточно информации для принятия решений. Итак, вам нужно прочитать о том пространстве, в котором вы находитесь, много, очень конкретные вещи прочитать. Ух ты, есть и другие люди, пытающиеся сделать то же самое; и затем в целом, есть эти другие характерные проблемы; и, может быть, даже, если захотите, попытаетесь найти исследовательские работы, которые находятся в этом же пространстве.

Удивительно, что классные вещи можно найти, если поискать что-то вроде документов ACM (Ассоциация вычислительной техники): «О, мне интересно, сможем ли мы получить определенный тип хэш-кода, Вы заходите в Google и вводите «хэш-код, который делает что-то». Нажимаете Enter. И если есть некоторые научные и ACM ссылки, возьмите эти документы. Даже если вы понимаете только крошечную часть статьи, это, вероятно, будет способствовать вашей способности думать о своей проблеме.

Другое дело: даже если вы не собираетесь спорить с автором идеи вслух, когда вы смотрите на его решение, будьте крайне критичны. Я не могу сказать вам, как часто вы будете находить новую лучшую идею, полностью распяв идею последнего парня. Хотя бы, в вашей собственной голове. Разберите её на части, потому что, когда вы разберете её, вы обнаружите пару вещей, которые, возможно, они не записали, когда решали её.

Все говорят, что проектирование — это компромиссы. Все это знают. Обычно, когда они говорят о компромиссах в своем программном обеспечении, они говорят о частях своего программного
обеспечения, которые отстойные. Я должен был учесть эти компромиссы. Это не то, чем является компромисс, верно?

Вы должны рассмотреть, по крайней мере, два решения вашей проблемы. Как минимум два. И вы должны выяснить, что хорошо и что плохо в этих вещах, прежде чем вы сможете сказать:
«Я нашёл компромисс». Поэтому я очень рекомендую вам это сделать. И когда вы сделаете это,
вы сможете записать это где-нибудь.

Ладно. Итак, давайте поговорим немного больше о практике.

Большая часть попыток сделать эту работу заключается в концентрации внимания. У нас вчера был действительно хороший разговор о состоянии потока, и это своего рода концепция
связанная с концентрацией. И когда вы пытаетесь что-то спроектировать, вам понадобится самая сильная концентрация внимания, чем когда-либо.

И поэтому про гамак есть несколько интересных моментов.

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

Компьютеры плохие, плохие источники отвлечения. Они очень плохие, особенно для таких как мы.

Это похоже на что-то еще, помимо того, о чем я пытаюсь думать.

Вам отчаянно нужно убежать от компьютера, если вы пытаетесь сконцентрироваться. Почти невозможно сконцентрироваться, сидя за компьютером.

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

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

Это просто характер работы такого рода, поэтому важно сообщить им об этом.

Многие люди не будут иметь времени, чтобы делать это каждый день или в течение целой недели, но если вы собираетесь сосредоточиться, определите, в каком виде это будет.

Все знают о методе «тайм-аута» для маленьких детей (временное отделение ребенка от окружающей среды).

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

И ваш бодрствующий разум действительно хорош в части критики. Он очень хорошо анализирует и очень, очень хороший тактик. Прямо сейчас нам нужно принять решение.
Лев гонится за нами. Прыгай влево. Мы действительно хороши в этом. Вот в чем заключается наш бодрствующий разум: поддерживать нас живыми и принимать краткосрочные решения, смотреть на немедленно предоставляемую информацию и что-то делать с ней.

Однако, если вы думаете, что собираетесь сесть и посмотреть на проблему впервые, и уставиться в свой компьютер, и что-то делать, и поговорить в течение 10 минут, и принять действительно хорошее решение. Я так не думаю. Я знаю, что не могу этого сделать. Точно нет.

Проблема с такими вещами в том, что они толкают вас наверх. «О, я вижу это. О, я вижу это. О, я вижу… хорошо, здесь у меня есть выбор налево или направо. Хорошо, я могу идти направо. Немного вверх. Влево или вправо, вправо. Теперь налево. Вверх. Ещё вверх. Эта часть вашего разума действительно хороша в поиске локального максимума, но она не очень хороша в том, чтобы сойти с трассы, на которой она находится, и обнаружить тот факт, что там есть еще один холм, который действительно поднимает вас выше. Но я думаю, что есть очень, очень важное занятие, которым вы должны заниматься, если хотите использовать весь свой мозг и стать очень хорошими в решении проблем. Иными словами, подумать об использовании своего времени бодрствования, чтобы назначить таски своему фоновому разуму, действительно серьезно задуматься о чем-то и создать работу для своего фонового разума. В этом и заключается смысл гамака, и весь этот список, и вся эта работа, о которой мы собираемся поговорить, когда вы будете бодрствовать, на самом деле состоит в том, чтобы дать другой половине вас занятие.

Еще одна хорошая вещь в вашем бодрствующем разуме: когда вы думаете, что у вас есть прекрасная идея, которую вы придумали в фоновом разуме, ваш бодрствующий разум хорошо
разбирает её на части, говоря: «Ах. Вы думали, что проснулись с этой блестящей идеей, но теперь я вижу эту особенность, которая кажется не такой блестящей».

Итак, давайте поговорим о фоновом разуме.

Я не собираюсь прямо приравнивать его к спящему разуму, но спящий разум это первый пример фонового разума. Вы можете получить доступ к своему фоновому разуму в течение дня когда вы не спите, но это сложно. Он хорош в создании связей. Такие вещи, как «Если я сделаю хижину из грязи, и будет сильный дождь, она распадется» это не обязательно та вещь, которую
вы можете тактически выяснить.

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

И поэтому, когда Марк говорит об абстракциях и тому подобных вещах, абстракции — это программная стратегия. Поскольку идея заключается в том, что вы принимаете какое-то супер глобальное решение, которое должно быть правильным в целом ряде контекстов, в которых вы пока не можете принимать тактические решения.

Что значит создать абстракцию, из которой вы собираетесь создавать библиотеки?

Что значит поместить что-то в язык программирования, когда я понятия не имею, что вы, ребята, собираетесь с этим делать?

Это более стратегическая вещь.

Вы не создаете языки программирования и не говорите: «Как этот язык программирования
будет обрабатывать HTTP-запросы?»

Что вы хотите сделать, так это дать Марку то, что он сможет использовать, когда у него будет тактическое решение в отношении HTTP-запросов. И это стратегическое мышление, и ваш фоновый разум хорош в стратегическом мышлении. Если вы хотите создать абстракцию,
вы должны найти время, чтобы заняться этим размышлением, потому что эта часть вашего мозга, из которой она исходит. Эта часть создает абстракцию. Она проводит аналогии. Я думаю, что именно здесь вы решаете большинство нетривиальных задач.

Иногда вы можете принимать правильные решения на лету, но если вы действительно пытаетесь решить что-то сложное, вам нужно задействовать другую половину своей головы. Так что я не просто так говорю это. Американские ученые говорят, что когда мы спим, мы обрабатываем информацию в течение дня, это довольно очевидно.

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

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

Когда вы решаете, что важно, а что нет? Когда вы спите.

Эволюция решила эту проблему для нас, и это решение, которое она придумала. Мы не можем игнорировать его. Мы должны использовать его. Но самое главное — найти скрытые отношения
и решить проблемы, над которыми мы работали.

Итак, представьте, что кто-то говорит: «У меня есть проблема этого, того, того». И вы смотрите на это в течение 10 минут и говорите: «Хорошо, я собираюсь пойти в кино и сделать что-то ещё или что-то ещё». Затем вы идёте спать. Собираетесь ли вы решить эту проблему во сне?

Кто-то из зала: Конечно.

Нет.

Вы ведь не думали над этой проблемой? Нет, вы не думали о ней.

Вы не думали о ней достаточно усердно, пока бодрствовали, чтобы она стала важной для
вашего разума, пока вы спите. И мы возвращаемся к тому, что питает ваш фоновый разум. Вы действительно должны усердно поработать: просто думайте над ней, не записывая её. Просто подумайте о проблеме в течение дня, чтобы она стала повесткой дня для вашего фонового разума. Вот как это работает.

Когда люди где-то там говорят: «Боже мой. Как я собираюсь найти еду, но я знаю, что видел там лося, и он, кажется, иногда находится у воды." Именно тогда вы просыпаетесь пещерным человеком и говорите: «Давайте пойдем охотиться на животных у воды». Это не логический вывод. Кажется, что ваш бодрствующий разум анализирует это, но не обязательно в этом есть логика.

Это действительно процесс такого параллельного мышления. Так что это очень важно.

В общем, у нас есть проблема, потому что нас просят написать софт, который со временем становится все более и более сложным. И мы знаем, что существует предел рабочей памяти типа 7 плюс/минус 2. И как бы умны мы ни были, мы все страдаем от одного и того же ограничения.
Но проблемы, которые мы призваны решать, обычно гораздо больше, чем эти числа. Так что же нам делать?

Если мы не можем вместить все это в нашу голову одновременно, как мы можем работать над проблемой с более чем девятью компонентами?

Я порекомендую вам записать всю информацию. Особенно в наше время.

Итак, вы многое записали про проблему. Вы знаете, в чем проблема. Вы знаете много фактов о ней. Вы знаете ограничения среды исполнения. Вы знаете то, чего не знаете. Вы задали себе эти вопросы. Вы записали их. «Я хотел бы знать, чтобы я знал то-то». Вы посмотрели на конкурентоспособные вещи и сказали: «Это прекрасно работает здесь, но эта часть этой конкурентоспособной вещи — отстой. Я ненавижу это. Хотелось бы, чтобы её здесь не было».
Вы положили важную повестку дня в свой фоновый разум. И когда вы пытаетесь загрузить проблему, вам нужно изучить её, вот в этом и был смысл записать её раньше. Если вы записали все вещи, в том числе некоторые наброски того как вы хотите решить проблему, вы можете
просто оглянуться и посмотреть на неё.

И это вроде как, сколькими шарами можно жонглировать одновременно? Ну, вы можете жонглировать только таким количеством. Ну, я не могу жонглировать вообще. Но если мы посмотрим на 7 плюс/минус 2, мы скажем, что мы можем жонглировать 7-9 шарами.

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

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

У всех есть понятие своего собственного мысленного взгляда? То, что вы видите, когда закрываете глаза и начинаете думать о чем-то. Это странно, я имею в виду, что на самом
деле это не визуально в техническом плане, хотя некоторые люди действительно визуально богаты.

Я не могу описать это, но это не очень реалистично. Эта часть важна для вашего мозга, потому что в этот момент вы переключаетесь из режима ввода информации. Если вы просто посмотрите на свой список, вы находитесь в режиме «Я получаю входные данные». Но когда вы сидите и обдумываете что-то, и хешируете это в своей голове, у вас нет другого ввода, что означает, что вы тренируете возврат.

Я посмотрел на эти 20 пунктов. Допустим, было всего 20. Я смотрел на эти 20 пунктов снова и снова. И я прыгал между ними. Теперь я закрываю глаза и пытаюсь вернуть их и подумать о них немного больше в моей голове, и вы обнаружите, что если вы сделали последний шаг, возвращая информацию снова и снова, вы действительно сможете сесть в гамак и вытащить
все части довольно большой проблемы из вашей головы возможно, одновременно,
и подумать о них таким образом.

Это упражнение действительно очень важно. Я не знаю, почему, просто так и есть, потому что оно ускоряет возврат, который определенно помогает разобраться с важными моментами
вашему фоновому разуму. Будем называть это «временем мысленного взгляда»

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

Одна из вещей, которые я бы сказал: по крайней мере, подождите ночь.

Неважно, как, вы и ваши приятели говорили об этом, и вы просто чувствуете давление: «Я понял в чём дело». Переспите с этой мыслью хотя бы одну ночь. Как минимум одну, если это важное решение.

Рич показал на слайде строку спите трезвыми для получения лучших результатов

Сколько людей проснулись сегодня утром с ответом на сложную проблему?

Вы видите? Это наука. Наука на работе. Нет, это действительно печальная вещь.

Если вы не думаете об этом, то получится так: «Что случилось? Я много работал весь день». Например: «Я закончил работать. Время отдыхать».

К сожалению, если вы верите в то, что я говорю сегодня, вы на самом деле делаете что-то важное, когда спите. Поэтому иногда вам действительно нужно дать мозгу шанс выполнить эту другую часть работы. Если вы всегда отрицаете это, я не думаю, что у вас будут лучшие результаты.

К сожалению, иногда одной ночи не достаточно.

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

Один из способов, с помощью которого вы можете справиться с этим и не попасть в тупик: «Хорошо, позвольте мне подумать об этом в течение 3 месяцев».

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

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

Затем, в конце концов, пирог выходит из духовки.

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

Если вы проснётесь с ответом на другую проблему, с которой не можете работать в этот день, запишите результаты этого фонового процесса. Они действительно полезны.

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

Таким образом, вы, в конце концов, должны писать код.

Это забавно, у Стю есть этот — он видел некоторые из моих таблиц проектирования. Как он их называет, «документ отчаяния» или как-то еще, он их называет. Кажется мы не можем этого сделать. Это не работает так. Знаки вопроса, бла, бла. Эта другая вещь была как… Один негатив.

Но это все вызовы в процессе решения проблем.
Это не отчаяние. Это позитивно.

В нём говорится: «Я знаю, каковы мои вызовы, и поэтому я могу работать над ними».

Вы получаете решение, теперь у вас есть что-то, поэтому вы пытаетесь…

Пытаетесь печатать поменьше. Я знаю, что я так делаю.

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

И я надеюсь, что, пройдя весь этот процесс, вы обретете уверенность после того как увидите, что он работает.

Итак, вы говорите: «Вы знаете что, я никогда не делал этого раньше, но я действительно думал об этом, и это решение, которое я нашел за ночь кажется потрясающим, и ух! Поехали!»

Важно взглянуть на то, что вы сделали, запустить это, увидеть, узнать что-то новое о решении и сказать: «О, вы знаете, моё предположение. Оно неверно. Я думал, что это будет иметь такую ​​
характеристику, но это не так и т. д.»

Я не защищаю Каскадную модель.

Попробуйте разные подходы и возвращайтесь.

Это хорошо.
Но не надейтесь на них.

Стоматология через тестирование, я не думаю, что смогу придумать лучшее название. Так это не работает.

Последняя мысль: вы будете ошибаться. Я часто ошибаюсь. Это часть игры.

Вы будете думать о лучших идеях. Я думаю, что это одна из самых захватывающих вещей.

Я думаю, что независимо от того, о чем я когда-либо думал, тот факт, что я знаю, что буду думать над лучшими решениями хотя они и будут не идеальными, потому что я знаю, что принёс что-то, что было не самым лучшим — означает, что я всё ещё в игре.

Всё ещё получается. Так что вы будете думать о лучших идеях. А ещё факты меняются. Они могут измениться по двум причинам, верно?

Во-первых, вы пропустили некоторые из них в самом начале. Они вновь открываются вами,
потому что вы пропустили их.

Что еще у нас есть?

Изменение требований. Мы знаем, что так бывает. Факты будут меняться. Когда факты меняются, не закапывайтесь. Проверьте снова и посмотрите, является ли ваш ответ все ещё верным в контексте новых требований, новых фактов. А если это не так, поменяйте решение и не извиняйтесь.

Иногда вы просто будете совершать ошибки, ошибки в логике или просто пойдёте не в ту сторону. Это нормально.

Если бы я мог пропагандировать что-либо, то я бы сказал «не бойтесь», особенно «не бойтесь ошибаться».

В итоге, это были рассуждения. Выводов не будет.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Читать еще


Теги:сонмышлениерешение проблемзолотой фонд
Хабы: Блог компании SkillFactory Программирование Учебный процесс в IT Clojure Лайфхаки для гиков
+4
7,2k 33
Комментарии 7

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
www.skillfactory.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре