diff --git a/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md b/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
new file mode 100644
index 0000000..fef5247
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
@@ -0,0 +1,21 @@
+# Научитесь отлаживать
+[//]: # (Version:1.0.0)
+Отладка это краеугольный камень профессии программиста. Основное значение слова "debug" это "устранять ошибки", но значение, которое имеет реальный вес, это "видеть, как исполняется программа, изучая ее код". Программист, который не умеет эффективно отлаживать, слеп.
+
+Те идеалисты, которые считают, что дизайн, анализ, теория сложности вычислений и подобное более фундаментальны, чем отладка, не являются работающими программистами. Работающий программист не живет в идеальном мире. Даже если вы идеальны, вы окружены и вынуждены работать с кодом, который написан в больших корпорациях, организациях вроде GNU и вашими коллегами. Большая часть этого кода неидеальна, и она неидеально задокументирована. Без способности видеть исполнение этого кода, малейшее несоответствие выбьет вас из колеи. Часто увидеть это можно только с помощью эксперимента, то есть, отладки. 
+
+Отладка больше занимается исполнением программ, чем самими программами. Если вы купите программное обеспечение от большой компании, то обычно вам не доведется увидеть сам код. Но все равно будут возникать моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы. Обычно вы при работе создаете ошибку, изучаете собственный код и понятия не имеете, откуда возникла ошибка. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
+
+Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать ход исполнения. Иногда ошибка видна визуально, например, если она отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, ошибка связана с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
+
+Распространенные методы изучения "внутренностей" программы можно поделить на:
+
+- Использование отладчика,
+- Printlining --- внесение временных модификаций в программу, обычно выводящих информацию о ее текущем состоянии,
+- Логирование --- создание постоянного интерфейса, который выводит ход исполнения программы в виде отчета.
+
+Отладчики это прекрасное средство, когда они стабильны и доступны, но printlining и логирование гораздо важнее. Отладчики часто отстают от развития языков программирования, так что они могут быть доступны не в каждый момент времени. К тому же, некоторые отладчики могут незначительно изменять ход исполнения программы, поэтому применять их в этих случаях непрактично. Наконец, существуют виды отладки, такие как проверка утверждений в большой структуре данных, которые требуют написания нового кода и изменения хода исполнения программы. Таким образом, это важно знать, как пользоваться отладчиками, когда они доступны, но критично важно уметь использовать два оставшихся метода отладки.
+
+Некоторые начинающие программиста боятся отладки, если та требует изменения кода. Это можно понять, это немного похоже на вскрытие с исследовательскими целями. Но вы должны научиться тыкать и дергать свой код, экспериментировать с ним и понимать, что ничего из того, что вы временно делаете с ним, не сделает его хуже. Если у вас есть такой страх, найдите наставника. Мы теряем множество хороших программистов в самом начале их обучения из-за этого страха.
+
+Следующее: [Как отлаживать, разделяя пространство проблемы](02-How-to-Debug-by-Splitting-the-Problem-Space.md)
diff --git a/ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md b/ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md
new file mode 100644
index 0000000..eeff6b5
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md
@@ -0,0 +1,15 @@
+# Как отлаживать, разделяя пространство проблемы
+[//]: # (Version:1.0.0)
+Отладка это интересно, потому что она начинается с проблемы. Вы думаете, что программа делает одно, но на самом деле она делает что-то другое. Не всегда это настолько просто, все  примеры, которые я мог бы привести, будут надуманными по сравнению с реальными случаями. Отладка требует творчества и изобретательности. Если и есть какой-то один ключ к отладке, то он заключается в приеме "разделяй и властвуй" в отношении проблемы.
+
+Предположим, к примеру, что вы написали программу, которая должны выполнять десять инструкций подряд. Затем вы запускаете ее, и она вылетает. Поскольку вы не планировали вылет программы, у вас появляется проблема. Когда вы смотрите на вывод программы, вы видите, что первые семь инструкций были выполнены успешно. Оставшиеся три инструкции не видны в выводе, поэтому пространство проблемы сужается: программа вылетает либо на восьмой, либо на девятой, либо на десятой инструкции.
+
+Сможете ли вы поставить эксперимент, чтобы увидеть, где вылетает программа? Конечно. Вы можете использовать отладчик или добавить printline statements (либо их эквивалент на вашем языке программирования) после восьмой и девятой инструкций. Когда вы запустите программу снова, пространство проблемы станет еще уже, например, вы увидите, что программа вылетает на девятой инструкции. Я считаю, что помнить о точном пространстве проблемы помогает сосредоточиться на ее решении. Когда несколько человек работают под давлением над задачей, очень легко забыть о том, что является главной проблемой в ней.
+
+Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, напополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка? Именно здесь на помощь приходят изобретательность и опыт.
+
+Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того видения программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешнем кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
+
+Когда вы разделили все пространство программы на все места, где может быть ошибка, вы предстоит определить, где именно она находится. В простом случае, когда вопрос стоит как "В какой неизвестной мне строке падает программа?", вы можете спросить себя: "Неизвестная мне строка с ошибкой находится до или после этой строки, которая по моему мнению должна исполняться в середине программы?" Как правило, вы будете не настолько удачливы, чтобы обнаружить, что ошибка кроется в одной строке или даже в одном блоке кода. Чаще проблема будет звучать как "Либо в этом графе есть указатель на некорректный объект, либо мой алгоритм некорректно складывает переменные в этом графе". В этом случае, возможно, вам придется написать небольшую программу для проверки указателей, чтобы решить, какую из частей этого пространства проблемы можно исключить. 
+
+Следующее: [Как устранять ошибки](03-How-to-Remove-an-Error.md)
diff --git a/ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md b/ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md
new file mode 100644
index 0000000..acea68c
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md
@@ -0,0 +1,9 @@
+# Как устранять ошибки
+[//]: # (Version:1.0.0)
+Я намеренно разделил исследование хода исполнения программы от исправления ошибки. Но, разумеется, отладка означает и устранение ошибки. В идеале вы прекрасно поймете код и поймаете "Ага"-момент, когда вы четко увидите ошибку и как ее исправить. Но это не всегда будет возможно, поскольку зачастую ваша программа будет использовать недостаточно документированные сторонние системы, насчет которых у вас не будет полной ясности. В других случаях сам код будет настолько сложен, что ваше понимание его будет несовершенным.
+
+При исправлении ошибки важно внести наименьшие изменения, которые ее исправят. Вы можете заметить другие места в коде, которые потребуют улучшений, но не вносите их одновременно с исправлением ошибки. Старайтесь применять научный метод: изменять только одно зараз. Лучший способ для этого: воспроизвести ошибку, внести исправления, затем перезапустить программу и убедиться, что ошибки больше нет. Конечно, иногда придется менять не одну, а несколько строк кода, но концептуально все равно старайтесь вносить точечные изменения для исправления ошибки.
+
+Иногда в программе присутствует несколько ошибок, очень похожих друг на друга. Определить их и исправить --- это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае, вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир иногда бывает неряшлив. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
+
+Следующее: [Как отлаживать, используя логирование](04-How-to-Debug-Using-a-Log.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md b/ru/1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md
new file mode 100644
index 0000000..1d5e750
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md
@@ -0,0 +1,13 @@
+# Как отлаживать, используя логи
+[//]: # (Version:1.0.0)
+Логирование это практика написания программ таким образом, что они выдают последовательность информативных записей, называемых логом. Printlining это создание небольшого, обычно временного лога. Начинающие программисты должны понимать и использовать логи, поскольку их знания в программировании ограничены. Системные архитекторы должны понимать и использовать логи, потому что они работают со сложными системами. Количество информации, которую выдает лог, должно быть настраиваемым, желательно во время выполнения программы. В общем случае, логирование имеет три основных преимущества:
+
+- Логи могут дать полезную информацию о багах, которые трудно воспроизвести (например, такие, которые воспроизводятся на боевом окружении, но не на тестовом).
+- Логи могут вести статистику и данные о производительности, такие как время между выполнением команд.
+- Если логи настраиваемы, то они помогают собрать общую информацию для устранения непредвиденных специфических проблем без необходимости модифицировать или перезапускать код.
+
+Количество выводимой в лог информации это всегда компромисс между информативностью и краткостью. Избыток информации сделает лог тяжелым и вызовет *слепоту прокрутки*, усложняя поиск нужного. Недостаток информации может просто сделать лог бесполезным. По этой причине полезно делать логи настраиваемыми. Как правило, каждая запись в логе отображает свое место в исходном коде, исполняющий ее поток, если он есть, точное время исполнения и, обычно, дополнительная информация вроде значения переменной, объем свободной памяти, число объектов с данными и так далее. Эти записи покрывают весь исходный код, особенно основные функциональные узлы и рискованный код. Записи можно распределить по уровням, и настраивать в конфигурации вывод только записей определенного уровня. Лог следует проектировать таким образом, чтобы его записи помогали решать проблемы программы, которые вы предвидите. Предусматривайте и проблему измерения производительности.
+
+Если у вас есть постоянный лог, printlining можно выполнить в рамках записей лога, и некоторые из отладочных сообщений стоит перманентно включить в систему логирования.
+
+Следующее: [Как определять проблемы производительности](05-How-to-Understand-Performance-Problems.md)
diff --git a/ru/1-Beginner/Personal-Skills/05-How-to-Understand-Performance-Problems.md b/ru/1-Beginner/Personal-Skills/05-How-to-Understand-Performance-Problems.md
new file mode 100644
index 0000000..bf62f60
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/05-How-to-Understand-Performance-Problems.md
@@ -0,0 +1,11 @@
+# Как определять проблемы производительности
+[//]: # (Version:1.0.0)
+Изучение проблем производительности так же неизбежно, как освоение отладки. Даже если вы в точности и совершенстве понимаете затраты на исполнение вашего кода, он будет взаимодействовать с другим программным обеспечением, над которым у вас нет будет такого контроля или понимания. Как бы то ни было, на практике проблемы производительности немного отличаются и немного проще, чем отладка в целом.
+
+Предположим, что вы или ваши клиенты считают систему или одну из подсистем слишком медленной. Перед тем, как вы попытаетесь ускорить ее, вам стоит построить мысленную модель и определить, почему она медленную. Вы можете использовать профилировщик или хороший лог, чтобы определить, где именно затрачивается врвмя или иной ресурс системы. Существует известное утверждение, что 90% времени затрачивается на 10% кода. Я бы добавил к этому важность затрат на чтение и запись (I/O) в оценке проблем производительности. Часто большая часть времени тратится либо на чтение информации, либо на ее запись. Хорошим первым шагом в построении мысленной модели проблемы будет нахождение затратных операций чтения и записи и 10% кода, занимающих большую часть ресурса.
+
+Существует множество измерений в производительности компьютерной системы и множество потребляемых ресурсов. Первое, что стоит измерить, это реальное время на исполнение программы. Логирование этого времени особенно полезно тем, что оно может указать на непредвиденные обстоятельства, которые возникают в ситуациях, когда испоьлзование профилировщика непрактично. Однако, этот параметр не всегда дает полную картину происходящего. Иногда вычисления, которые требуют чуть больше общего времени, но занимают меньше процессорного времени, покажут себя лучше в реальном окружении. Аналогично, память, пропускная способность сети, доступ к базе данных или другому серверу могут оказаться, в конечном счете, гораздо дороже, чем процессорное время.
+
+Загруженность общих ресурсов, которые синхронизированы между собой, может привести к взаимной блокировке и ресурсному голоду. Взаимная блокировка это невозможность продолжить испонение программы из-за недостаточной синхронизации запрашиваемых ресурсов. Ресурсный голод это невозможность правильно запланировать работу компонента. Если это можно предусмотреть, то лучше всего с самого старта проекта иметь способ измерения загруженности ресурсов. Даже если она не случится, очень полезно иметь возможность утверждать это с уверенностью.
+
+Следующее: [Как устранять проблемы производительности](06-How-to-Fix-Performance-Problems.md)
diff --git a/ru/1-Beginner/Personal-Skills/06-How-to-Fix-Performance-Problems.md b/ru/1-Beginner/Personal-Skills/06-How-to-Fix-Performance-Problems.md
new file mode 100644
index 0000000..78241c3
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/06-How-to-Fix-Performance-Problems.md
@@ -0,0 +1,13 @@
+# Как устранять проблемы производительности
+[//]: # (Version:1.0.0)
+Большинство проектов можно с относительно небольшими усилиями ускорить в 10-100 раз относительно их первой версии. В условиях сжатых сроков ыхода на рынок разумно и эффективно выбирать ту реализацию, которая проще и быстрее остальных. Однако, производительность это часть удобства использования, поэтому часто ее стоит оценить более внимательно.
+
+Главное в улучшении производительности сложной системы это проанализировать ее достаточно тщательно, чтобы найти "узкие места", то есть те места, где запрашивается наибольший объем ресурсов. Нет большого смысла оптимизировать функцию, которая занимает только 1% процессорного времени. Если вы не уверены, что изменение ускорит систему или ее значительную часть хотя бы в два раза, то стоит хорошо подумать, стоит ли это вообще делать. Как правило, есть такие способы. Оценивайте также затраты на тестирование и проверки, которые потребует ваше ускорение. Каждое изменение кода приносит с собой необходимость тестирования, поэтому лучше иметь немного больших изменений.
+
+После того, как вы добились двукратного улучшения производительности в одном месте, стоит снова провести анализ программы и определить следующее по затратам узкое место. Тогда можно заняться им.
+
+Часто узкие места в производительности будут представлять собой что-то вроде подсчета коров по ногам и делению на четыре вместо обычного подсчета по головам. Например, я часто забывал дать собственный индекс столбцу в реляционной базе управления данных, что замедляло весь процесс минимум в 20 раз. Среди других примеров: ненужные операции чтения и записи в циклах, отладочные сообщения, ставшие неактуальными, избыточное выделение памяти и в особенности неумелое использование библиотек и сторонних фреймворков, которые плохо документированы в части производительности. Такой вид улучшений легко определить и с ходу внести в программу. 
+
+Что делать, когда очевидных мест для улучшений не осталось? Вы можете продолжать искать узкие места на более глубоком уровне или пересмотреть весь дизайн системы. Последнее дает прекраную возможность продемонстрировать свои умения программиста не только в реализации нового дизайна системы, но и в умении убедить своего босса в том, что это необходимо. Тем не менее, перед тем, как вы начнете убеждать его в необходимости коренных изменений, спросите себя, ускорить ли ваше решение систему в 5-10 раз.
+
+Следующее: [Как оптимизировать циклы](07-How-to-Optimize-Loops.md)
diff --git a/ru/1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md b/ru/1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md
new file mode 100644
index 0000000..4aafc84
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md
@@ -0,0 +1,15 @@
+# Как оптимизировать циклы
+[//]: # (Version:1.0.0)
+Иногда вам повстречаются затратные по времени циклы или рекурсивные функции, которые окажутся узкими местами в вашей программе. Перед тем, как вы попытаетесь ускорить цикл, потратьте некоторое время на то, чтобы понять, можно ли избавиться от него полностью. Сработает ли здесь какой-нибудь другой алгоритм? Можно ли вычислить это парамллельно с другим вычислением? Если вам не удалось найти обходной путь, тогда оптимизируйте цикл. Это просто: вынесите из него все, что можно. В конце концов, эта операция требует не только изобретательности, но и понимания, сколько затрачивается на каждое выражение и операцию. Вот несколько предложений:
+
+- Уберите операции с плавающей точкой.
+- Не размещайте впустую новвые блоки под память.
+- Держите рядом константы.
+- Передвиньте операции чтения и записи в буфер.
+- Старайтесь не использовать деление.
+- Старайтесь не использовать затратные приведения типов данных.
+- Перемещайте указатель вместо того, чтобы пересчитывать индексы.
+
+Стоимость каждой из этих операций зависит от вашей конкретной системы. Где-то компиляторы и аппаратное обеспечение выполнит их вместо вас. Разумнеется, чистый и эффективный код лучше, чем тот, который требует понимания специфичной платформы.
+
+Следующее: [Как справиться с расходами на операции чтения и записи](08-How-to-Deal-with-IO-Expense.md)
diff --git a/ru/1-Beginner/Personal-Skills/08-How-to-Deal-with-IO-Expense.md b/ru/1-Beginner/Personal-Skills/08-How-to-Deal-with-IO-Expense.md
new file mode 100644
index 0000000..e0c467d
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/08-How-to-Deal-with-IO-Expense.md
@@ -0,0 +1,13 @@
+# Как справиться с расходами на операции чтения и записи
+[//]: # (Version:1.0.0)
+В большинстве случаев процессоры работают быстро по сравнению со взаимодействием с аппаратными устройствами. Затраты на это взаимодействие обычно объединяются под словами операции чтения и записи и включают сетевые запросы, чтение и запись на диски, запросы в базы данных, чтение и запись файлов и другое использование аппаратной части, иногда расположенной не совсем рявдом с процессором. Так образом, построение быстрой системы это чаще улучшение операций чтения и записи, чем улучшение кода в цикле или даже совершенствование алгоритма.
+
+Существует две фундаментальные техники по улучшению операций чтения и записи: кэширование и форматирование данных. Кэширование позволяет избежать чтения-записи (обычно чтения некого абстрактного значения) с помощью сохранения копии значений локально. Таким образом, операция чтения для получения значения не повторяется. Главное в кэшировании четко обозначить, какие данные являются исходными, а какие - копиями. Должен существовать только один исходник. Кэширование опасно тем, что иногда копия может не отразить изменения, произошедшие в исходных данных.
+
+Форматирование данных это удешевление операций чтени и записи за счет более эффективного представления данных. Зачастую это конфликтует с другими требованиями к данным, вроде удобочитаемости и переносимости.
+
+Часто формат данных можно улучшить в 2-3 раза относительно их первоначального представления. Техники, которые позволяет сделать это, включают представление в двоичном виде вместо представление в удобочитаемом виде, передача справочников символов вместе с данными, так что длинные символы не нуждаются в кодировании, и, в крайнем случае, способы вроде алгоритма Хаффмана.
+
+Третий способ, который иногда возможен, это перенос вычислений ближе к самим данным. Например, если вы читаете данные из базы данных и выполняете с ними простые операции вроде сложения, то стоит попытаться перенести эту операцию на сервер базы данных. Этот способ очень сильно зависит от типа вашей системы, но вам стоит отдельно изучить его.
+
+Следующее: [Как управлять памятью](09-How-to-Manage-Memory.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Personal-Skills/09-How-to-Manage-Memory.md b/ru/1-Beginner/Personal-Skills/09-How-to-Manage-Memory.md
new file mode 100644
index 0000000..10d7ffa
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/09-How-to-Manage-Memory.md
@@ -0,0 +1,15 @@
+# Как управлять памятью
+[//]: # (Version:1.0.0)
+Память это ценнейший ресурс, который вы не можете себе позволить исчерпать. Какое-то время вы можете игнорировать ее, но в один момент вам придется решать, как ею управлять.
+
+Пространство памяти, которое должно сохраняться за пределами одной подпрограммы, часто называется *выделенной кучей*. Участок памяти без указателей на него бесполезен и называется *мусором*. В зависимости от системы, которую вы используете, вы можете решить удалить в явном виде память, выделенную под данные, которые вот-вот станут мусором. Но чаще у вас будет возможность использовать *сборщик мусора*. Он определяет мусорную память и освобождает ее автоматически, без вмешательства программиста. Сборщик мусора это прекрасное средство, оно уменьшает число ошибок в коде, позволяет писать его короче и понятнее с наимееньшими затратами. Используйте его, когда это возможно.
+
+Но даже со сборщиком мусора вы можете забить всю память мусорными данными. Классическая ошибка --- использовать хэш-таблицу в качестве кэша и забыть удалить ссылки в ней. Поскольку ссылка остается, данные по ней недосягаемы, и ссылка бесполезна. Это называется *утечкой памяти*. С самого начала разработки следует следить за утечками памяти и устранять их. Если у вас есть долго работающие системы, то память может никогда не заканчиваться при тестировании, будет исчерпана польователями при реальном использовании.
+
+Создание новых объектов это относительно затратная операция в любых системах. Память, выделенная напрямую под локальные переменные подпрограммы, однако, обычно дешевле из-за простой политики ее высвобождения. Избегайте создания ненужных объектов.
+
+Выжный момент происходит, когда вы можете определить верхнюю границу числа требуемых объектов. Если все объекты занимают одинаковый объем памяти, то вы можете выделить под них один блок памяти или буфер. Все необходимые вам объекты можно создавать и удалять внутри этого блока по принципу ротации, так что иногда это называют кольцевым или циклическим буфером. Обычно он быстрее, чем выделенная куча. 
+
+Иногда вам придется явно освобождать выделенное пространство памяти вместо того, чтобы полагаться на сборщик мусора. В этом случае вы должны тщательно проанализировать каждую часть выделенной памяти и разработать способ ее высвобождения в нужный момент времени. Способ может отличаться для каждого типа объектов, который вы создаете. Вы должны убедиться, что каждой операции выделения памяти соответствует операция ее освобождения. Это непросто, поэтому для упрощения задачи программисты как правило реализуют сборщик мусора в порстой форме, например, в виде подсчета ссылок на объекты.
+
+Следующее: [Как устранять плавающие баги](10-How-to-Deal-with-Intermittent-Bugs.md)
diff --git a/ru/1-Beginner/Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md b/ru/1-Beginner/Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md
new file mode 100644
index 0000000..0053887
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md
@@ -0,0 +1,17 @@
+# Как устранять плавающие баги
+[//]: # (Version:1.0.0)
+Плавающая ошибка это родственник пятидесятиметрового невидимого скорпиона из глубокого космоса. Этот кошмар воспроизводится так редко, что его трудно наблюдать, но достаточно части его нельзя просто игнорировать. Вы не можете отладить баг, потому что вы не можете его найти.
+
+Хотя после восьми часов отладки вы начнете сомневаться в этом, плавающие баги подчиняются тем же самым законам логики, что и все остальное. Что делает их трудными, это неизвестные обстоятельства, в которых они воспроизводятся. Постарайтесь записать все условия, при которых происходит плавающий баг, чтобы вы могли предположить, в чем на самом деле заключается изменчивость бага. Баг может быть связан со значениями данных, например, воспроизводиться, только когда переменной присваивается значение "Вайоминг". Если причина изменчивости не в этом, то следующим пунктом стоит проверить синхронизацию конкуррентности.
+
+Изо всех сил постарайтесь воспроизвести баг контролируемым способом. Если воспроизвести его не получается, попробуйте поймать его через логирование. Если нужно, напишите специальные логи для этого бага, которые будут записать то, что вам кажется связанным с ошибкой. Смиритесь с тем, что это будет долгий процесс, если ошибка воспроизводится на боевом окружении и не по вашей прихоти. Подсказки, которые вы можете извлечь из логов, могут не дать вам полного ответа, но должны предоставить достаточно информации для улучшения самих логов. Улучшение системы логирования для боевого окружения может занять много времени. Затем вам придется ждать, пока баг не появится вновь, чтобы получить информацию из обновленных логов. Этот цикл может повториться еще несколько раз.
+
+Самый глупый плавающий баг, который создал я, заключался в многопоточной реализации одного функционального языка программирования для учебного проекта. Я тщательно обеспечил корректную оценку параллельности программы, правильное использование ядере процессора (всех восьми в жанном случае). Я просто-напросто забыл синхронизировать сборщик мусора. Программа могла работать безошибочно долгое время, завершая все задания, которые я ей назначал. Со стыдом признаюсь, я начал подозревать аппаратное обеспечение, прежде чем меня осенило, в чем проблема.
+
+Недавно на работе у нас был плавающий баг, на который мы потратили несколько недель. У нас есть многопоточное серверное приложение на Java, размещенное на Apache-серверах. Чтобы поддержать быструю смену страниц, мы выполняли все операции чтения и записи в небольшом наборе из четырех потоков, отделенных от потоков, ответственных за смену страниц. Время от времени они "замораживались" и, насколько мы могли понять из логов, прекращали делать что-либо полезное на несколько часов. Поскольку у нас было выделено четыре потока, само по себе это не было большой проблемой. До тех пор, пока не замораживались все четыре потока одновременно. Тогда очереди запросов, освобожденные замороженными потоками, забивали всю свободную память и крашили наш сервер. Нам потребовалась неделя, чтобы просто выявить баг, и мы не смогли понять, в чем причина, вызывающая этот баг, и даже что именно происходило в потоках в тот момент, когда они "застревали".
+
+Этот пример демонстрирует риск, связанный с использованием стороннего программного обеспечения. Мы использовали лицензионный код, который убирал теги HTML из текста. Хотя, к счастью,  у нас был исходный код, мы не изучали его досконально, пока мы не включили логирование на нашем сервере и не увидели, что потоки почтовых сообщений забивались из-за этого лиценционного кода.
+
+Программа работала прекрасно, за исключением некоторых длинных и необычных текстов. В этом случае, исполнение было квадратичным. Это значит, что время обработки текста было пропорционально квадрату длины текста. Если бы такие тексты встречались бы регулярно, мы бы сразу нашли баг. Если бы они вообще не попадались бы, бага просто не было бы. Как бывает, мы потратили несколько недель, чтобы наконец понять и решить проблему.  
+
+Следующее: [Как научиться проектировать программы](11-How-to-Learn-Design-Skills.md)
diff --git a/ru/1-Beginner/Personal-Skills/11-How-to-Learn-Design-Skills.md b/ru/1-Beginner/Personal-Skills/11-How-to-Learn-Design-Skills.md
new file mode 100644
index 0000000..997dede
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/11-How-to-Learn-Design-Skills.md
@@ -0,0 +1,9 @@
+# Как научиться проектировать программы
+[//]: # (Version:1.0.0)
+Чтобы научиться проектировать программное обеспечение, наблюдайте за тем, как это делают более опытные коллеги. Затем изучайте хорошо написанные программы. Далее вы можете прочесть несколько книг о новейших техниках проектирования.
+
+Затем вы должны начать проектировать самостоятельно. Начните с небольшого проекта. Когда вы завершите его, оцените, насколько удачна или неудачна финальная архитектура, и как сильно вы отклонились от первоначальной концепции. Потом переходите на проекты побольше, желательно в сотрудничестве с другими людьми. Навык проектирования требует годы на выработку. Толковый программист может освоить основы за пару месяцев и дальше развиваться самостоятельно.
+
+Естественно и полезно развивать свой собственный стиль, но помните, что проектирование это искусство, а не наука. Люди, которые пишут об этом книги, заинтересованы в том, чтобы проектирование казалось научным. Не становитесь догматиком в отношении стилей проектирования.
+
+Следующее: [Как экспериментировать](12-How-to-Conduct-Experiments.md)
diff --git a/ru/1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md b/ru/1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md
new file mode 100644
index 0000000..5743c62
--- /dev/null
+++ b/ru/1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md
@@ -0,0 +1,23 @@
+# Как экспериментировать
+[//]: # (Version:1.0.0)
+Великий Эдсгер Дейкстра красноречиво объеснил, что информатика не является экспериментальной наукой и не зависит от электронных устройств. Как он выразился в 1960-е годы:
+
+> ...the harm was done: the topic became known as “computer science” - which, actually, is like referring to surgery as “knife science” - and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment.
+
+Программирвание может и не быть экспериментальной наукой, но у большинства программистов не возможности заниматься тем, что Дейкстра определил как вычислительную науку. Мы должны работать в области экперимента подобно некоторым (но не всем) физикам. Если спустя 30 лет можно будет заниматься программированием без экспериментирования, то это будет великим достижением информатики.
+
+Эксперименты, которые вам придется заниматься, включают:
+
+- Тестирование систем на небольших примерах данных, чтобы убедиться в их соответствии документации, либо чтобы понять их ответы, если документации нет.
+- Тестирование небольших изменений в коде, чтобы удостовериться, что они устраняют баг в программе
+- Измерение производительности системы в двух различных окружениях из-за несовершенства знаний о их характеристиках производительности
+- Проверка целостности данных
+- Сбор статистики, которая может помочь с разрешении сложных и трудновоспроизводимых багов
+
+Я не думаю, что в этом эссе я смогу объяснить, как проектировать эксперименты. Вам придется научиться этому самостоятельно и практиковаться. Я могу предложить два небольших совета.
+
+Первое, старайтесь четко обозначать свои исходные предположения или утверждения, которые вы собираетесь проверить. Очень полезно записывать их, особенно, если вы работаете в коллективе.
+
+Часто вам придется проектировать серию экспериментов, каждый из которых опирается на знания, полученные в результате предыдущего. Таким образом, следует проектировать эксперименты таким образом, чтобы получать как можно больше информации. К сожалению, это противоречит принципу простоты экспериментов. Вам придется развивать свою экспертизу в этой области самостоятельно.
+
+Следующее: [Командные навыки. Почему важно оценивать задачи](../Team-Skills/01-Why-Estimation-is-Important.md)
diff --git a/ru/1-Beginner/README.md b/ru/1-Beginner/README.md
new file mode 100644
index 0000000..b4d029f
--- /dev/null
+++ b/ru/1-Beginner/README.md
@@ -0,0 +1,27 @@
+# 1. Начинающий программист
+[//]: # (Version:1.0.0)
+- Личные навыки
+	- [Научитесь отлаживать](Personal-Skills/01-Learn-To-Debug.md)
+	- [Как отлаживать, разделяя пространство проблемы](Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md)
+	- [Как устранять ошибки](Personal-Skills/03-How-to-Remove-an-Error.md)
+	- [Как отлаживать, используя логи](Personal-Skills/04-How-to-Debug-Using-a-Log.md)
+	- [Как определять проблемы производительности](Personal-Skills/05-How-to-Understand-Performance-Problems.md)
+	- [Как устранять проблемы производительности](Personal-Skills/06-How-to-Fix-Performance-Problems.md)
+	- [Как оптимизировать циклы](Personal-Skills/07-How-to-Optimize-Loops.md)
+	- [Как справиться с расходами на операции чтения и записи](Personal-Skills/08-How-to-Deal-with-IO-Expense.md)
+	- [Как управлять памятью](Personal-Skills/09-How-to-Manage-Memory.md)
+	- [Как устранять плавающие баги](Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md)
+	- [Как научиться проектировать программы](Personal-Skills/11-How-to-Learn-Design-Skills.md)
+	- [Как экспериментировать](Personal-Skills/12-How-to-Conduct-Experiments.md)
+- Командные навыки
+	- [Почему важно оценивать задачи](Team-Skills/01-Why-Estimation-is-Important.md)
+	- [Как оценивать время на разработку](Team-Skills/02-How-to-Estimate-Programming-Time.md)
+	- [Как искать информацию](Team-Skills/03-How-to-Find-Out-Information.md)
+	- [Как спрашивать людей](Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md)
+	- [Как документировать правильно](Team-Skills/05-How-to-Document-Wisely.md)
+	- [Как работать с плохим кодом](Team-Skills/06-How-to-Work-with-Poor-Code.md)
+	- [Как использовать системы контроля версий](Team-Skills/07-How-to-Use-Source-Code-Control.md)
+	- [Как писать юнит-тесты](Team-Skills/08-How-to-Unit-Test.md)
+	- [Делайте перерывы, когда вы в тупике](Team-Skills/09-Take-Breaks-when-Stumped.md)
+	- [Как понять, когда идти домой](Team-Skills/10-How-to-Recognize-When-to-Go-Home.md)
+	- [Как вести себя с трудными людьми](Team-Skills/11-How-to-Deal-with-Difficult-People.md)
diff --git a/ru/1-Beginner/Team-Skills/01-Why-Estimation-is-Important.md b/ru/1-Beginner/Team-Skills/01-Why-Estimation-is-Important.md
new file mode 100644
index 0000000..0830507
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/01-Why-Estimation-is-Important.md
@@ -0,0 +1,15 @@
+# Почему важно оценивать задачи
+[//]: # (Version:1.0.0)
+Чтобы как можно быстрее выпустить программное обеспечение, нужно планировать не только ее разработку, но и документирование, запуск и продвижение. В коммерческих проектах также важны продажи и финансовая составляющая. Без предсказуемости времени разработки невозможно все это запланировать эффективно.
+
+Хорошая оценка времени на разработку дает предсказуемость. Менеджеры очень любят это. Тот факт, что теоретически и практически невозможно точно предсказать, сколько времени уйдет на рзработку, часто упускается менеджерами. Нас все время просят сделать эту невыполнимую вещь, и мы должны честно в этом признаться. Однако, будет нечестно не признать невыполнимость этого задания и, когда необходимо, не объяснить это. Вокруг временных оценок много недопониманий, так как люди склонны принимать слова
+
+> Я думаю, что если я правильно понимаю проблему, то около 50% вероятности, что мы сделаем это за пять недель. При условии, что никто не будет нам мешать все это время.
+
+в действительности означает
+
+> Я обещаю все сделать за пять недель, начиная с текущего момента.
+
+Это общая проблема непонимания требует, чтобы вы в явном виде обсуждали, что именно значит ваша временная оценка со своим боссом или клиентом. Так, словно они дети. Измените свои формулировки оценки, даже если они вам кажутся очевидными.
+
+Следующее: [Как оценивать время на разработку](02-How-to-Estimate-Programming-Time.md)
diff --git a/ru/1-Beginner/Team-Skills/02-How-to-Estimate-Programming-Time.md b/ru/1-Beginner/Team-Skills/02-How-to-Estimate-Programming-Time.md
new file mode 100644
index 0000000..5361792
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/02-How-to-Estimate-Programming-Time.md
@@ -0,0 +1,21 @@
+# Как оценивать время на разработку
+[//]: # (Version:1.0.0)
+Оценка времени требует практики и труда. Иногда так много труда, что имеет смысл отдельно оценивать время на оценку задачи, особенно, если речь идет об оценке большой задачи.
+
+Когда вас просят оценивать большую задачу, самое честное - потянуть время. Большинство инженеров полны энтузиазма и склонны угождать, а задержка ответа не обрадует спрашивающего. Но выданная с ходу оценка вряд ли будет точной и честной.
+
+Пока вы думаете над ответом, возможно, получится сделать прототип задачи. Если обстоятельства позволяют, то это самый точный способ оценки, и он позволяет добиться реального прогресса.
+
+Когда взять время на некоторое исследование задачи невозможно, то сначала вы должны четко и ясно установить, что именно означает ваша оценка. Сформулируйте это значение как первое и заключительное части вашей оценки в письменном виде. Подготовьте письменный ответ, разбирая задачу на более мелкие задания, в идеальном случае, требующие не больше одного рабочего дня. Самое важное здесь - ничего не забыть. Например, очень важно время на документирование, тестирование, планирование, взаимодействие с другими командами, отпуска. Если вы каждый день тратите часть времени на общение с неумными людьми, добавьте отдельную строку на это в общую оценку времени. Это даст вашему боссу общее видение того, что отнимает у вас немного времени, а на что вам требуется его гораздо больше.
+
+Я знаком с программистами, которые включают такие временные затраты в общую оценку в неявном виде, т.е. просто прибавляют их к общему времени работы. Я не советую так делать. Одним из эффектов такого подхода может стать потеря доверия. Например, программист может заложить три дня на задачу, которую он на самом деле собирается выполнить за день. Программист планирует потратить еще два дня на документирование своей работы или на другой полезный проект. Но тот факт, что работа была выполнена только за один день, очень просто выяснить. И тогда может возникнуть впечатление, что программист бездельничал или переоценил задачу. Намного лучше дать четкое описание того, что вы реально собираетесь делать в рамках задачи. Если документирование занимает в два раза больше времени, чем написание кода, и в оценке сказано об этом, то это дает преимущества, если это донести до вашего менеджера.
+
+Включайте все временные затраты в оценку в явном виде. Если задача скорее всего займет один день, но может растянуться на десять дней, если ваш первоначальный подход не сработает, отметьте это в вашей оценке. Либо укажите среднее время задачи согласно вашим оценкам вероятностей разных исходов. Любые риски, связанные с временем на задачу, должны быть включены в оценку. Вряд ли конкретный человек заболеет в конкретный момент времени. Но в большом проекте с множеством программистов обязательно будут те, кто возьмет больничный. То же самое касается отпусков. А какова вероятность обязательного обучающего семинара в рамках всей компании? Если ее можно оценить, включите ее в общую оценку. Кроме этого, еще есть неизвестные факторы. Их по определению не получится оценить по отдельности. Вы можете заложить для них отдельную строку в общей оценке, либо учесть их как-то по-другому. Чего нельзя делать, так это позволять своему боссу забыть об их существовании. Очень легко превратить оценку времени в расписание, если не учитывать неизвестные факторы.
+
+В командной работе следует стараться, чтобы оценку выполняли те люди, которые будут выполнять задачу, и чтобы оценка была согласована внутри всей команды. Люди отличаются по навыкам, опыту, готовности и уверенности. Неприятности начинаются, когда сильный программист оценивает задачу для себя, а более слабые программисты затем вынуждены придерживаться этой оценки. Когда вся команда согласна с построчным разбиением оценок затрат на задачи, это облегчает общее понимание задач и дает возможность тактически перераспределить нагрузку с более слабых членов команды на более сильных.
+
+Если в задаче присутствуют большие риски, которые невозможно оценить, ваша обязанность донести это до менеджера так, чтобы тот не брал на себя обязательства, связанные с ними. В этом случае стоит сделать все возможное, чтобы снизить эти риски.
+
+Если вы сможете убедить свою компанию исользовать *экстремальное программирование*, то вам придется оценивать только относительно небольшие задачи. Это гораздо интереснее и продуктивнее.
+
+Следующее: [Как искать информацию](03-How-to-Find-Out-Information.md)
diff --git a/ru/1-Beginner/Team-Skills/03-How-to-Find-Out-Information.md b/ru/1-Beginner/Team-Skills/03-How-to-Find-Out-Information.md
new file mode 100644
index 0000000..61977ec
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/03-How-to-Find-Out-Information.md
@@ -0,0 +1,19 @@
+# Как искать информацию
+[//]: # (Version:1.0.0)
+То, что вы ищете, определяет то, как вы это ищете.
+
+Если вы ищете информацию о *конкретных знаниях*, которые объективны и легко проверить, например, последняя версия патча для программного обеспечения, то лучше вежливо спросить об этом в интернете или в дискуссионной группе. Не ищите в интернете то, что связано с мнением или субъективной интерпретацией, отношение бреда здесь слишком велико.
+
+Если вы ищете *общие знания о чем-то субъективном*, историю мнений людей о предмете, то идите в библиотеку (я имею в виду настоящее здание с книгами). Например, чтобы узнать что-нибудь о математике, грибах или мистицизме, идите в библиотеку.
+
+Если вам нужно узнать, *как сделать что-то нетривиальное*, достаньте две-три книги, посвященные этой теме, и прочтите их. В интернете вы можете узнать, как сделать тривиальные вещи, вроде установки пакета программного обеспечения. Вы даже можете узнать серьезные вещи, например, хорошие техники программирования, но здесь легко потратить гораздо больше времени на поиск и отбор результатов и попытки определить, насколько авторитетен источник, чем на чтение соответствующей части в серьезной книге.
+
+Если вы ищете *информацию, которую скорее всего никто не знает*, например, "работает ли это новое программное обеспечение с огромными наборами данных?", все равно стоит поискать ответ в интернете и в библиотеке. Когда эти способы будут исчерпаны, вы можете спроектировать эксперимент, чтобы убедиться в истинности найденных ответов.
+
+Если вас интересует мнение или экспертное суждение с учетом некоторых уникальных обстоятельств, поговорите с экспертом. Например, если вы хотите знать, хорошая ли это идея написать современную систему управления данных на Lisp, вам стоит поговорить с экспертом Lisp и с экспертом по базам данных.
+
+Если вы хотите знать, *какова вероятность*, что существует более быстрый алгоритм для конкретного приложения, поговорите с тем, кто работает в этой области.
+
+Если вы хотите принять личное решение, которое можете принять только вы, вроде начинать вам свой бизнес или нет, попробуйте составить список аргументов за и против этого решения. Если это не поможет, попробуйте принять решение наугад. Предположим, вы изучили идею со всех сторон, провели нужные исследования, выяснили все обстоятельства, преимущества и недостатки идеи, но все равно не можете решить. Тогда вы должны последовать своему сердцу и сказать своему разуму заткнуться. Множество доступных техник гадания очень полезны для определения ваших подсознательных желаний, так как каждая из них представляет собой совершенно неоднозначный и случайный образ, которому ваше подсознание придаст свое значение.
+
+Следующее: [Как использовать людей в качестве источников информации](04-How-to-Utilize-People-as-Information-Sources.md)
diff --git a/ru/1-Beginner/Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md b/ru/1-Beginner/Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md
new file mode 100644
index 0000000..d8d5829
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md
@@ -0,0 +1,15 @@
+# Как спрашивать людей
+[//]: # (Version:1.0.0)
+Уважайте время каждого человека и соизмеряйте его со своим. Вопрос дает гораздо больше, чем просто ответ. Человек, которого вы спрашиваете, узнает вас как просто из вашего присутствия, так и по вашему вопросу. Вы узнаете о человеке то же самое, и вдобавок, возможно, вы получаете ответ на ваш вопрос. Как правило, это гораздо важнее, чем ваш вопрос.
+
+Однако, ценность вопросов умешьшается тем больше, чем чаще вы их задаете. В конце концов, вы отнимаете у человека самое важное: время. Выгоды от общения стоит соизмерять с затратами на него. Более того, конкретны выгоды и затраты отличаются от человека к человеку. Я убежден, что руководитель 100 человек должен тратить 5 минут в месяц на разговор с каждым человеком в организации. Это займет 5% всего времени руководителя. Но 10 минут может быть слишком много для такого числа, а 5 минут может быть много, если в компании 1000 сотрудников. Число времени, которое вы тратите на беседы с каждым человеком в вашей компании, зависит от роли человека (больше, чем от должности). Вам следует разговаривать с вашим боссом чаще, чем с боссом вашего босса, но и с ним вам стоит немного разговаривать. Это может показаться некомфортным, но я считаю, что ваша обязанность каждый месяц немного разговаривать с вашими руководителями, несмотря ни на что.
+
+Главное правило: все получают пользу от небольшой беседы с вами. И чем чаще происходит беседа, тем меньше пользы они получают. Ваша работа состоит в том, чтобы дать этим людям полезу от разговора с вами и получить ее самому, сохраняя баланс между нею и потраченным временем.
+
+Важно уважать свое собственное время. Если разговор с кем-то, несмотря на то, что он займет время этого человека, поможет сохранить вам ваше время, то вам стоит провести этот разговор. Если только вы не считаете, что потраченное на разговор время этого человека более важно для всей организации.
+
+Странным примером этого является летний стажер. От стажера на высокотехнической должности нельзя ожидать больших свершений, но можно ожидать, что но будет донимать вопросами всех подряд. Почему это позволяется? Потому что те, кого донимает стажер, получают от него важную возможность покрасоваться. У них, возможно, появляется шанс услышать новые идеи, посмотреть с другой точки зрения на проект. Может быть, они попытаются нанять стажера, но даже если это не так, все равно от него много пользы.
+
+Каждый раз, когда вы считаете, что людям есть что сказать, вам следует спрашивать их мнение. Это льстит им и позволяет вам узнать что-то новое, научить их чему-то новому. Хорошему программисту редко нужны советы от вице-президента по продажам, но когда они нужны, спросите их. Я однажды попросил разрешить мне послушать несколько звонков от ребят из отдела продаж, чтобы лучше понять их работу. Это заняло не больше 30 минут, но думаю, что это произвело на них большое впечатление.
+
+Следующее: [Как документировать правильно](05-How-to-Document-Wisely.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Team-Skills/05-How-to-Document-Wisely.md b/ru/1-Beginner/Team-Skills/05-How-to-Document-Wisely.md
new file mode 100644
index 0000000..a6388d9
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/05-How-to-Document-Wisely.md
@@ -0,0 +1,20 @@
+# Как документировать правильно
+[//]: # (Version:1.0.0)
+Жизнь слишком коротка, чтобы писать ерунду, которую никто не будет читать. Если вы пишите плохо, никто не будет это читать. Так что лучше всего документировать хорошо и немного. Менеджеры часто не понимают этого, потому что даже плохая документация дает им ложное чувство уверенности, что они не зависят от своих программистов. Если кто-то абсолютно настаивает, чтобы вы писали никому не нужную документацию, скажите "да" и начинайте спокойно искать новую работу. 
+
+Чтобы снизить запрос на документирование, нет ничего более эффективного, чем дать точную оценку времени, которое на него потребуется. Реалии жизни холодны и суровы: документирование, как и тестирование, может занять гораздо больше времени, чем разработка.
+
+Написание хорошей документации это, прежде всего, умение хорошо писать. Я предлагаю вам найти книги о том, как хорошо писать, изучить их и практиковаться. Но даже если вы плохой писатель или плохо владеете языком, на котором должны документировать, все, что вам реально нужно, это золотое правило "Поступай с другими так, как вы хотите, чтобы поступали с вами". Подумайте о тех, кто будет читать вашу документацию, что им будет нужно найти в ней, как вы можете это до них донести. Уже с этим вы будете лучше среднего автора документации и хорошим программистом.
+
+Когда дело касается документирования самого кода в противоположность написанию документировании для непрограммистов, лучшие программисты, которых я знаю, придерживаются универсального принципа писать самодокументируемый код и добавлять комментарии только там, где невозможно объяснить решения самим кодом. Для такого подхода есть две веские причины. Во-первых, любой, кому понадобится документация кода, в большинстве случаев сможет и предпочтет читать сам код. Разумеется, сделать это проще опытным программистам, чем начинающим. Но гораздо важнее, что код и документация не могут противоречить друг другу, если отдельной документации нет. Исходный код в худшем случае может быть написан плохо и непонятно. Документация, если она написана плохо, может лгать, а это в тысячу раз хуже.
+
+Это не облегчает работу ответственным программистам. Как писать самодокументируемый код? Что это вообще значит? Это значит:
+
+- Писать код, думая о том, что кому-то придется его читать;
+- Применять золотое правило выше;
+- Выбирать решение, которое очевидно, даже если менее очевидное решение быстрее;
+- Жертвовать небольшими оптимизациями вместо того, чтобы делать код менее понятным;
+- Думать о читателе кода и тратить больше своего драгоценного времени на то, чтобы ему было проще;
+- Никогда не называть функции `foo`, `bar` или `doIt`!
+
+Следующее: [Как работать с плохим кодом](06-How-to-Work-with-Poor-Code.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Team-Skills/06-How-to-Work-with-Poor-Code.md b/ru/1-Beginner/Team-Skills/06-How-to-Work-with-Poor-Code.md
new file mode 100644
index 0000000..894cffa
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/06-How-to-Work-with-Poor-Code.md
@@ -0,0 +1,11 @@
+# Как работать с плохим кодом
+[//]: # (Version:1.0.0)
+Иногда приходится работать с чужим плохо написанным кодом. Не стоит плохо думать об авторах этого кода, пока вы не поймете полностью их ситуацию. Возможно, они работали быстро и под давлением, чтобы успеть по графику. Как бы то ни было, чтобы работать с плохим кодом, вам надо его понять. Чтобы понять его, нужно время, и его надо откуда-то взять из вашего текущего графика. На этом следует настаивать. Чтобы понять код, вам придется читать исходники и экспериментировать с ним.
+
+Это отличный момент начать документировать, даже если пока только для себя. Попытка задокументировать код вынудит вас посмотреть на него с разных точек зрения, которые вы до этого не рассматривали, и конечный документ может получиться очень полезным. Пока вы занимаетесь этим, прикиньте, сколько займет переписать весь код или его некоторую часть. Сохранит ли время переписывание части кода? Сможете ли вы больше доверять коду, если вы перепишите его? Здесь опасайтесь самоуверенности. Если вы перепишете код, то вам будет проще, но будет ли проще следующему человеку, который будет работать с кодом? Если вы перепишите код, то как много придется тестировать? Не перевесит ли необходимость тестирования нового кода все преимущества, которые он принесет?
+
+В любой оценке времени, которую вы делаете для работы с чужим кодом, качество этоого кода должно влиять на ваше восприятие рисков проблем и неизвестных факторов.
+
+Важно помнить, что абстракция и инкапсуляция, два лучших средства программиста, особенно применимы к плохому коду. Возможно, вы не сможете переделать целиком большой блок кода, но если вы добавите новый уровень абстракции к него, то сможете добиться некоторых преимуществ без переделки всего кода. В частности, вы можете отделить особенно плохие части кода, чтобы отрефакторить их независимо от остального кода.
+
+Следующее: [Как использовать системы контроля кода](07-How-to-Use-Source-Code-Control.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Team-Skills/07-How-to-Use-Source-Code-Control.md b/ru/1-Beginner/Team-Skills/07-How-to-Use-Source-Code-Control.md
new file mode 100644
index 0000000..3308445
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/07-How-to-Use-Source-Code-Control.md
@@ -0,0 +1,9 @@
+# Как использовать системы контроля версий
+[//]: # (Version:1.0.0)
+Системы контроля кода (также известные как системы контроля версий) позволяют вам эффективно управлять проектами. Они очень полезны для одиночки и жизненно важны для группы разработчиков. Они отслеживают все изменения во всех версиях кода, так что ни одна строка кода не может быть потеряна навсегда. Кроме этого, они позволяют присвоить осмысленное название изменениям. С помощью таких систем можно писать отладочный код с уверенностью, ведь весь модифицируемый код можно хранить отдельно от исходного работающего. Новый код потом можно показать всей команде или сразу выпустить.
+
+Я довольно поздно оценил все преимущества систем контроля версий, но теперь без них я не начну даже небольшой личный проект. Вообще, они нужны, когда вы работаете в команде с одной кодовой базой. Но у них есть другое важное преимущество: они поощряют думать о коде как о растущей системе. Поскольку каждое изменение отмечено своим именем или номером, постепенно приходишь к мысли, что программное обеспечение это видимая последовательная серия изменений в коде. Я думаю, что это особенно полезно для начинающих программистов.
+
+Хорошая техника использования системы контроля версий заключается в том, чтобы постоянно держать свой код в пределах нескольких дней от актуальности. Код, который не может быть закончен за несколько дней, проверяется, но таким образом, чтобы он был неактивным и не вызывался в действующей системе, а значит, не создавал проблем для других. Ошибки, замедляющие работу товарищей по команде, непростительны и часто являются табу.
+
+Следующее: [Как писать юнит-тесты](08-How-to-Unit-Test.md)
diff --git a/ru/1-Beginner/Team-Skills/08-How-to-Unit-Test.md b/ru/1-Beginner/Team-Skills/08-How-to-Unit-Test.md
new file mode 100644
index 0000000..4329615
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/08-How-to-Unit-Test.md
@@ -0,0 +1,9 @@
+# Как писать юнит-тесты
+[//]: # (Version:1.0.0)
+Юнит-тестирование, то есть тестирование отдельных частей кода командой, написавшей его, это часть программирование, а не что-то отдельное от него. Проектирование того, как будет тестироваться код, это часть общего проектирования кода. Вам следует записывать планы по тестированию, даже если это всего одна фраза. Иногда тест окажется простым: "Хорошо ли выглядит кнопка?". Иногда он будет сложным: "Этот алгоритм сопоставления возвращает правильные совпадения?"
+
+Когда возможно, исползуйте проверки утверждений и тестовые драйверы. Они не только помогут найти баги в начале разработки, но будут полезны позже и позволят устранить более сложные проблемы.
+
+Экстремальные программисты много пишут об эффективном юнит-тестировании. Я могу только посоветовать ознакомиться с их трудами на эту тему.
+
+Следующее: [Делайте перерывы, когда вы в тупике](09-Take-Breaks-when-Stumped.md)
\ No newline at end of file
diff --git a/ru/1-Beginner/Team-Skills/09-Take-Breaks-when-Stumped.md b/ru/1-Beginner/Team-Skills/09-Take-Breaks-when-Stumped.md
new file mode 100644
index 0000000..dc7d331
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/09-Take-Breaks-when-Stumped.md
@@ -0,0 +1,5 @@
+# Делайте перерывы, когда вы в тупике
+[//]: # (Version:1.0.0)
+Когда вы в тупике, сделайте перерыв. Я иногда медитирую 15 минут, когда захожу в тупик, и проблема неожиданно разрешается, когда я возвращаюсь к ней. Ночной отдых иногда выполняет такую же роль в более широком масштабе. Возможно, поможет временное переключение на другую задачу.
+
+Следующее: [Как понять, когда идти домой](10-How-to-Recognize-When-to-Go-Home.md)
diff --git a/ru/1-Beginner/Team-Skills/10-How-to-Recognize-When-to-Go-Home.md b/ru/1-Beginner/Team-Skills/10-How-to-Recognize-When-to-Go-Home.md
new file mode 100644
index 0000000..fa3c770
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/10-How-to-Recognize-When-to-Go-Home.md
@@ -0,0 +1,16 @@
+# Как понять, когда идти домой
+[//]: # (Version:1.0.0)
+Программирование это деятельность, которая также является культурой. К сожалению, это не та культура, которая ценит психическое и физическое здоровье. По культурно-историческим причинам (например, необходимость работать по ночам на ненагруженных компьютерах) и из-за сильного давления выпустить продукт на рынок программисты традиционно перерабатывают. Не думаю, что стоит верить всему, что рассказывают, но мне кажется, что 60 рабочих часов в неделю это распространенный график, а 50 часов это практически минимум. Это значит, что часто требуется гораздо больше. И это серьезная проблема для хорошего программиста, который отвечает не только за себя, но и за своих коллег. Вы должны понимать, когда идти домой, и иногда, когда предложить своим коллегам пойти домой. Здесь не может быть четких правил для решения проблемы, так же, как не может быть однозначных правил о том, как воспитывать детей. Все люди разные.
+
+Свыше 60 рабочих часов в неделю для меня огромная нагрузка, которую я могу выдержать лишь небольшое время (около недели). Но иногда от меня ожидается именно столько. Не знаю, справедливо ли ожидать от человека 60 часов работы в неделю. Я не уверен, что даже 40 часов это справедливо. Однако, я уверен, что это глупо работать так много, что почти не извлекать пользы от дополнительных часов работы. Для меня лично этот предел лежит за 60 часами в неделю. Я лично считаю, что программист должен проявлять благородство и нести эту тяжелую ношу. Однако, быть козлом отпущения - не обязанность программиста. Печальный факт заключается в том, что часто программистов просят быть козлами отпущения, чтобы устроить для кого-то представление, например, когда менеждер пытается впечатлить руководителя. Программисты часто идут на это, потому что они хотят угодить и не умеют говорить "нет". Есть четыре способа защиты от такого отношения:
+
+- Как можно больше общайтесь со всеми сотрудниками в компании, чтобы никто не мог ввести в заблуждение руководителей относительно того, что происходит
+- Научитесь оценивать время на работу и планировать все ее части в явном виде и дайте всем четкое представление о своем расписании и где его найти
+- Научитесь говорить "нет", говорите "нет" всей командой, если это необходимо
+- Увольняйтесь, если дургих выходов нет
+
+Большинство программистов это хорошие программисты, а хорошие программисты хотят сделать как можно больше. Чтобы достичь этого, они должны эффективно управлять своим временем. Между разогревом перед работой и глубоким погружением в нее всегда должно пройти некоторое время. Многие программисты лучше всего работают, когда они располагают длинными, никем не прерываемыми отрезками времени, в течение которых они могут сосредоточиться и погрузиться в работу. Но люди должны еще и спать, и выполнять множетсов других вещей. Каждый должен найти способ сбалансировать свой рабочий ритм и ритм жизни. Каждый программист должен делать все возможное, чтобы обеспечить себя периодами эффективной работы, например, резервируя определенные дни, когда он может отвлекатьсяя только на самые важные собрания.
+
+Поскольку у меня есть дети, я стараюсь проводить вечера с ними. Лучше всего мне подходит очень долгий раочий день, затем поспать в офисе или рядом (я работаю очень далеко от дома), затем на следующий день уйти домой достаточно рано, чтобы провести время с моими детьми до того, как они отправятся спать. Этот ритм не очень удобен для меня, но это лучшее, что я смог найти. Отправляйтесь домой, если у вас заразная болезнь. Вы должны идти домой, если у вас суицидальные мысли. Вы должны сделать перерыв или идти домой, если вы думаете об убийстве больше чем несколько секунд. Вы должны отправить домой человека, если он демонстрирует признаки серьезного умственного расстройства или депрессии. Если из-за усталости у вас возникает соблазн быть более нечестным или вредным, чем вам обычно свойственно, сделайте перерыв. Не используйте кокаин или амфетамины для борьбы с усталостью. Не злоупотребляйте кофеином. 
+
+Следующее: [Как вести себя с трудными людьми](11-How-to-Deal-with-Difficult-People.md)
diff --git a/ru/1-Beginner/Team-Skills/11-How-to-Deal-with-Difficult-People.md b/ru/1-Beginner/Team-Skills/11-How-to-Deal-with-Difficult-People.md
new file mode 100644
index 0000000..d6bfb97
--- /dev/null
+++ b/ru/1-Beginner/Team-Skills/11-How-to-Deal-with-Difficult-People.md
@@ -0,0 +1,15 @@
+# Как вести себя с трудными людьми
+[//]: # (Version:1.0.0)
+Скорее всего вам придется иметь дело с трудными людьми. Может быть, вы сами трудный человек. Если вы из тех, у кого часто возникают конфликты с коллегами и руководителями, то вы должны ценить свою независимость, но одновременно работать над своими навыками взаимодействия с остальными, не принося в жертву свои принципы и ум.
+
+Это может стать проблемой для некоторых программистов, у которых нет опыта подобных ситуаций, и чей предыдущий жизненный опыт научил моделям поведения, которые не годятся в рабочем окружении. Трудные люди часто привыкают к разногласиям, и на них меньше, чем на остальных, действует социальное давление идти на компромисс. Главное - уважать их должным образом. Но это больше, чем захотите вы, и меньше, чем могут захотеть подобные люди.
+
+Программисты вынуждены работать вместе в команде. Когда возникает разногласие, его надо как-то решить, его нельзя игнорировать слишком долго. Трудные люди часто бывают чрезвычайно умны, и им есть, что полезного высказать. Очень важно слушать их и понимать без предубеждения, которое может вызывать их личность. Трудности в общении часто становятся источником разногласий, но их можно преодолеть терпением. Старайтесь держать общение в спокойном и вежливом тоне, не поддавайтесь на уловки увеличить конфликт. После того, как вы потратите разумное время на попытки понять оппонента, примите решение.
+
+Не позволяйте грубой силе заствавлять вас делать то, с чем вы несогласны. Если вы лидер команды, принимайте то, что вы считаете лучшим решением. Не принимайте решения исходя из личных причин, какими они бы ни были. Будьте готовы объяснить свое решение. Если вы в команде с трудным человеком, не позволяйте, чтобы решение лидера было вызвано любым личным мнением. Если решение не в вашу пользу, принимайте его от всей души.
+
+Трудные люди меняются и становятся лучше в общении. Я сам был свидетелем этому, но это случается редко. Как бы то ни было, у всех бывают периоды взлетов и падений.
+
+Один из самых больших вызовов, встречающихся каждому программисту, особенно лидерам, это держать трудного человека вовлеченным в общую работу. Такие люди больше склонны уклоняться от нее и пассивно сопротивляться.
+
+Следующее: [Разработчик среднего уровня](../../2-Intermediate)
diff --git a/ru/2-Intermediate/Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md b/ru/2-Intermediate/Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md
new file mode 100644
index 0000000..2293b7b
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md
@@ -0,0 +1,13 @@
+# Как балансировать качество и время разработки
+[//]: # (Version:1.0.0)
+Разработка программного обеспечения - это всегда компромисс между тем, что делает само программное обеспечение, и тем, чтобы проект был завершен. Вас могут попросить пожертвовать качеством разработки, чтобы ускорить запуск проекта. Причем жертва может оказаться такой, что это серьезно заденет вашу инженерную или бизнес-ответственность. Например, вас могут попросить применить слабое или неоправданное техническое решение, которое в дальнейшем приведет к множеству проблем.
+
+В таком случае ваша первая обязанность сообщить о таком требовании своей команде и ясно объяснить, чем обернется снижение качества. В конце концов, ваше техническое понимание проекта должно быть гораздо лучше понимания вашего босса. Подчеркните, что теряет проект, что приобретает, и какой ценой потери на текущем этапе придется восполнять на следующем цикле разработки. Здесь очень пригодится общее понимание, которое дает хороший проектный план. Если жертвование качеством влияет на усилия по обеспечению качества, укажите на это боссу и команде по качеству. Если жертвование качеством приведет к увеличению найденных багов после тестирования, укажите и на это.
+
+Если жертвы неизбежны, вам стоит попытаться отделить некачественный в результате такого решения код в отдельные компоненты, чтобы в дальнейшем вернуться к нему и переписать. Разъясните это своей команде, чтобы они могли запланировать такой подход.
+
+NinjaProgrammer на Slashdot прислал такой шедевр:
+
+> Помните, что хорошая архитектура будет устойчива к плохой реализации к коде. Если в коде присутствуют правильные интерфейсы и абстракции, тогда последующий рефакторинг будет менее болезненным. Если написать чистый код, который легко поправить, подумайте, в чем проблема у архитектуры, из-за которой это происходит.
+
+Следующее: [Как управлять зависимостями](02-How-to-Manage-Software-System-Dependence.md)
diff --git a/ru/2-Intermediate/Judgment/02-How-to-Manage-Software-System-Dependence.md b/ru/2-Intermediate/Judgment/02-How-to-Manage-Software-System-Dependence.md
new file mode 100644
index 0000000..9f34432
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/02-How-to-Manage-Software-System-Dependence.md
@@ -0,0 +1,13 @@
+# Как управлять зависимостями
+[//]: # (Version:1.0.0)
+Современное программное обеспечение имеет тенденцию зависеть от множества компонентов, которые могут не быть под вашим непосредственным контролем. Это повышает продуктивность за счет синергии и повторного использования. Однако, каждый такой компонент приносит с собой некоторые проблемы:
+
+- Как вы будете исправлять баги в компоненте?
+- Ограничивает ли компонент вас использовать определенное аппаратное обеспечение или систему?
+- Что вы будете делать, если компонент полностью откажет?
+
+Всегда лучше инкапсулировать компонент таким образом, чтобы он был отделен, и его можно было легко заменить. Если компонент покажет свою неработоспособность, вы замените его на другой или напишите свой собственный. Инкапсуляция не улучшает переносимость, но делает переписывание кода проще, что почти также здорово.
+
+Если у вас есть исходный код компонента, то риски снижаются вчетверо. С исходным кодом вы можете быстрее оценивать компонент, отлаживать, находить новые решения и вносить исправления. Если вы вносите исправления, то о них следует сообщить владельцу компонента, чтобы он включил их в официальный релиз. В противном случае, вам придется самостоятельно поддерживать неофициальную версию компонента.
+
+Следующее: [Как оценивать стороннее программное обеспечение](03-How-to-Decide-if-Software-is-Too-Immature.md)
diff --git a/ru/2-Intermediate/Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md b/ru/2-Intermediate/Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md
new file mode 100644
index 0000000..ba99c05
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md
@@ -0,0 +1,19 @@
+# Как оценивать стороннее программное обеспечение
+[//]: # (Version:1.0.0)
+Использование стороннего программного обеспечения это один из самых эффективных способов быстро построить серьезную систему. От него не следует отказываться, но следует изучить связанные с ним риски. Один из самых больших рисков это период множества багов и почти неработоспособности, случающийся перед тем, как программное обеспечение будет доработано и станет устойчивым продуктом. Прежде чем рассматривать возможность интеграции с программой, разработанной вашей или сторонней компанией, очень важно оценить, насколько она устойчива для использования. Вот десять вопросов, которые вы должны задать себе по этому поводу:
+
+1. Это выпущенный продукт? (Обещаниям не стоит верить)
+2. Существует ли доступный свод знаний об этом программном обеспечении?
+3. Вы первый пользователь?
+4. Есть ли у разработчиков программы сильный стимул для ее продолжения и развития?
+5. Есть ли техническая поддержка?
+6. Переживет ли проект уход нынешних разработчиков?
+7. Есть ли хотя бы наполовину соответствующая проверенная альтернатива?
+8. Известно ли это программное обеспечение вашей команде или компании?
+9. Хочет ли ваша команда или компания работать с ним?
+10. Сможете ли вы нанять людей для работы с ним, даже если это плохое программное обеспечение?
+
+Небольшое размышление над этими вопросами демонстрирует огромную ценность хорошо зарекомендовавшего себя свободного программного обеспечения и программного обеспечения с открытым кодом в снижении рисков. 
+
+
+Следующее: [Как решать: покупать программу или писать свою](04-How-to-Make-a-Buy-vs-Build-Decision.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md b/ru/2-Intermediate/Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md
new file mode 100644
index 0000000..0d43204
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md
@@ -0,0 +1,16 @@
+# Как решать: покупать программу или писать свою
+[//]: # (Version:1.0.0)
+Предпринимательская компания или проект, которые пытаются добиться чего-то с помощью программного отбеспечения, постоянно вынуждены принимать решения типа *покупать программу или писать свою*. Это выражение неудачно по двум причинам. Оно как будто игнорирует существование свободного и открытого программного обеспечения, которое необязательно покупать. И, что более важно, его стоит переформулировать в *приобрести и интегрировать или написать свое и интегрировать*, потому что затраты на интеграцию обязательны надо учесть. Такие решения требуют редкого сочетания деловой, управленческой и инженерной смекалки. 
+
+- Насколько полно ваши требования совпадают с требованиями под которые было создано программное обеспечение, рассматривающееся к покупке?
+- Какая часть программы, которую вы можете купить, действительно вам нужна?
+- Каковы затраты на оценку интеграции?
+- Каковы затраты на интеграцию?
+- Приобретение этой программы увеличит или уменьшит затраты на долгосрочную поддержку?
+- Если вы напишите свое программное обеспечение под свои цели, поставить ли это вашу компанию в нежелательную бизнес-ситуацию?
+
+Следует как минимум дважды хорошо подумать, прежде чем начинать создавать программу, достаточно большую, чтобы стать основой чьего-то бизнеса. Подобные идеи часто предлагают яркие и оптимистичные люди, которые могут внести большой вклад в вашу команду. Если их идея окажется убедительной, возможно вы захотите изменить свой бизнес-план. Но не инвестируйте необдуманно в решение, которое больше, чем ваш собственный бизнес.
+
+Рассмотрев эти вопросы, вам стоит подготовить две черновых проектных плана, один с покупкой программного обеспечения, второй с созданием собственного. Это подтолкнет вас оценить затраты на интеграцию. Также стоит рассмотреть затраты на долгосрочную поддержку программы. Чтобы оценить затраты на интеграцию, вам придется тщательно изучить само программное обеспечение перед покупкой. Если это невозможно, то вы берете на себя неразумные риски при покупке и вам стоит отказаться от приобретения программного обеспечения в данном проекте. Если в рассмотрении несколько подобных вопросов о покупке, то придется потратить время на тщательную оценку каждого случая.
+
+Следующее: [Как расти профессионально](05-How-to-Grow-Professionally.md)
diff --git a/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md b/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md
new file mode 100644
index 0000000..35930d0
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md
@@ -0,0 +1,11 @@
+# Как расти профессионально
+[//]: # (Version:1.0.0)
+Возьмите на себя роль, превышающую вашу ответственность. Выполняйте роль, которую вы хотите. Выражайте признательность и благодарность людяи за их вклад в успех организации и за персональнуб помощь вам.
+
+Если вы хотите стать лидером команды, способствуйте формированию общего согласия в работе. Если вы хотите стать менеджером, возьмите ответственность за расписание. Обычно вы спокойно можете сделать это, работая с лидером или менеджером, так как это снимет с них большую нагрузку. Если это слишком сложная задача для начала, возьмите на себя обязанности поменьше.
+
+Оценивайте себя. Если вы хотите стать лучше как программист, спросите программиста, которого вы уважаете, как стать похожим на него. Также вы можете спросить своего босса, который меньше разбирается в этом, но зато имеет большее влияние на вашу карьеру.
+
+Ищите пути освоить новые навыки, как тривиальные технические вроде освоения новой программной системы, так и трудные социальные, вроде умения писать хорошо. Старайтесь использовать эти навыки в работе.
+
+Следующее: [Как проводить собеседования](06-How-to-Evaluate-Interviewees.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md b/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md
new file mode 100644
index 0000000..cf331be
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md
@@ -0,0 +1,15 @@
+# Как проводить собеседования
+[//]: # (Version:1.0.0)
+Оценке потенциальных сотрудников не уделяется должного внимания. Нанятый плохой сотрудник это, как и неудачный брак, ужасно. Значительная часть усилий каждого должна быть направлена на найм, но это случается редко.
+
+Есть разные стили собеседования. Некоторые мучительны и направлены оказать на кандидата давление. Это служит ценной цели: выявить под стрессом недостатки характера и слабости. Кандидаты не честнее с интервьюерами, чем с самим собой, а чеолвеческая способность к самообману поразительна. 
+
+Как минимум, вам стоит выделить два часа на устную оценку технических навыков каждого кандидата. С опытом вы научитесь быстро выяснять, что они знают, и быстро проводить границу с тем, чего они не знают. Кандидаты с уважением относятся к этому. Мне доводилось несколько раз слышать от кандидатов, что качество собеседования было одной из причин выбрать компанию. Хорошие профессионалы хотят, чтобы их нанимали за навыки, а не за последнее местоработы или колледж или некие иные несущественные характеристики.
+
+При собеседовании также стоит оценивать способность кандидата учиться, что гораздо важнее того, что он уже знает. Также стоит обратить внимание на признаки трудного человека. Их можно распознать, разбирая заметки о собеседовании, но во время интервью быть трудно их определить. Насколько хорошо кандидат умеет общаться и взаимодействовать с людьми гораздо важнее знания новейшего языка программирования.
+
+Один из читателей рекомендует давать тестовое задание кандидатам. Преимущество этого теста в том, что он позволяет выявить кандидата, который хорошо представляет себя, но не может писать код. Таких людей немало. Я лично не пробовал этот метод, но он кажется разумным.
+
+Наконец, собеседование - это еще и процесс продажи. Вы продаете своб компанию или проект кандидату. Однако, поскольку вы разговариваете с программистом, не пытайтесь приукрасить правду. Начните с плохого, а затем перейдите к тому хорошему, что есть. 
+
+Следующее: [Как понять, когда применять высокие технологии](07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md)
diff --git a/ru/2-Intermediate/Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md b/ru/2-Intermediate/Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md
new file mode 100644
index 0000000..0788a87
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md
@@ -0,0 +1,15 @@
+# Как понять, когда применять высокие технологии
+[//]: # (Version:1.0.0)
+Существует свод знаний об алгоритмах, структурах данных, математике и других вещах, о которых программисты знают, но довольно редко используют в работе. На практике эти замкчательные вещи слишком сложны и, как правило, ненужны. Нет смысла улучшать алгоритм, когда большая часть времени тратится на неэффективный запрос к базе данных. Досадная часть программирования состоит в том, чтобы заставить системы общаться друг с другом и использовать очень простые структуры данных для построения красивого пользовательского интерфейса. 
+
+Когда следует применять высокие технологии? Когда следует открывать серьезные книги, чтобы найти альтернативу обычному алгоритму? Иногда полезно это делать, но такие технологии следует тщательно оценивать.
+
+Три самых важных соображения о потенциальном использовании какой-либо техники это:
+
+- Хорошо ли эта техники инкапсулирована? Так что риск для остальных систем невысок, как и общий прирост сложности и затраты на поддержку
+- Является ли преимущество использования этой техники значительным (например, в два раза для старой и хорошо разработанной системы или в десять раз для новой)?
+- Сможете ли вы проверить и оценить эту технику эффективно?
+
+Если хорошо изолированный алгоритм, использующий слегка более сложную логику, может уменьшить нагрузку на аппаратную часть или увеличить производительность в два раза, то будет преступлением не использовать его. Один из факторов поддержать такой подход - это показать, насколько низок риск использования, так как предлагаемая технология хорошо изучена. Остается только риск интеграции. Здесь опыт и экспертиза программиста в сочетании с самой технологией должны сделать интеграцию достаточно простой.  
+
+Следующее: [Как разговаривать с неинженерами](08-How-to-Talk-to-Non-Engineers.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Judgment/08-How-to-Talk-to-Non-Engineers.md b/ru/2-Intermediate/Judgment/08-How-to-Talk-to-Non-Engineers.md
new file mode 100644
index 0000000..756fec3
--- /dev/null
+++ b/ru/2-Intermediate/Judgment/08-How-to-Talk-to-Non-Engineers.md
@@ -0,0 +1,19 @@
+# Как разговаривать с неинженерами
+[//]: # (Version:1.0.0)
+Инженеры и в частности программисты часто отделяются от остальных людей. Это значит, что остальные люди непохожи на нас. Об этом стоит помнить во время общения с неинженерами. Всегда следует понимать свою аудиторию.
+
+Неинженеры умны, но не так связаны с созданием технических вещей, как мы. Мы создаем продукт. Они продают его, работают с ним, поддерживают и управляют, но они не эксперты в создании. Они не так хороши в командной работе, как инженеры (здесь, вне всяких сомнений, есть исключения). Их социальные навыки как правило так же хороши или лучше, чем у инженеров, но их работа не всегда требует того доверительного и точного общения и четкого распределения задач как у программистов.
+
+Неинженеры могут слишком стремиться угодить, и вы можете подавить их. Подобно нам, они могут без реального понимания сказать "да", чтобы угодить вам или из-за страха перед вами. И затем не выполнить свое обещание.
+
+Непрограммисты могут понимать технические аспекты, но у них нет того, что трудно даже для нас: технической экспертизы. Они понимают, как работает технология, но не могут понять, почему один способ займет три месяца, а другой три дня. (В конце концов, программисты анекдотично плохи в оценке затрат). Это дает прекрасную возможность для синергии с ними.
+
+При разговоре с вашей командой вы, не думая, используете сокращения или сленг, которые гораздо короче и эффективнее, так как у всех вас схожий опыт с технологиями и вашим продуктом в частности. Потребуется приложить усилие, чтобы не использовать этот сленг с теми, у кого нет подобного опыта, особенно, если присутствуют члены вашей команды. Такой сленг создает стену между вами и остальными и даже хуже, заставляет их бессмысленно тратить время.
+
+С вашей командой базовый контекст и цели общения ясны и не нуждаются в частом повторении, вы фокусируетесь на деталях. С неинженерами нужен другой подход. Они могут не понимать то, что вы считаете разумеещимся. И поскольку вы считаете это очевидным и не объясняете детали, после разговора с неинженером вам может показаться, что вы прекрасно поняли друг друга, в то время как в действительности образовалось большое недопонимание. Вам следует предполагать, что будет недопонимание, и внимательно следить, где в разговоре оно может появиться. Постарайтесь, чтобы ваш собеседник повторил или переформулировал то, что вы ему сказали, чтобы убедиться, что он правильно все понял. Если у вас есть возможность часто встречаться с этим человеком, потратьте время, чтобы узнать, насколько эффективно вы выражаете себя и как вы можете это делать лучше. Если в общении возникает проблема, стремитесь изменить собственный подход вместо того, чтобы разочаровываться в подходе собеседников.
+
+Я обожаю работать с неинженерами. Это дает прекрасные возможности учить и научиться самому. Вы можете подавать пример в смысле ясности и четкости в общении. Инженеры привыкли вносить порядок в хаос, вносить ясность в неразбериху, и неинженеры очень ценят это в нас. Поскольку мы владеем технической экспертизой и часто понимаем проблемы бизнеса, часто мы можем найти простое решение.
+
+Иногда неинженеры из доброты и стремления принять правильное решение предлагают вещи, которые по их мнению сделают нашу жизнь проще, тогда как в действительности существует решение гораздо лучше, которое можно найти, объединив взгляд неинженера с вашей технической экспертизой. Я лично люблю экстремальное программирование, поскольку оно решает эту проблему неэффективности. Быстрое согласование оценки с идеей упрощает поиск новой идеи, которая представляет собой лучшее сочетание затрат и выгод.
+
+Следующее: [Продвинутые навыки](../../3-Advanced)
diff --git a/ru/2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md b/ru/2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md
new file mode 100644
index 0000000..20c37a5
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md
@@ -0,0 +1,15 @@
+# Как сохранять мотивацию
+[//]: # (Version:1.0.0)
+Замечателен и удивителен тот факт, что программисты высоко мотивированы желанием создавать прекрасное, полезное и удобное. Это желание не уникально для программистов и не универсально, но оно настолько распространено именно среди них, что это отделяет эту профессию от остальных.
+
+У этого есть практические и важные последствия. Если программисты вынуждены делать что-то, что не является прекрасным, полезным или удобным, они начинают терять мотивацию. В создание уродливых, глупых и скучных вещей вкладывается много денег, но в конечном счете именно радость создания приносит наибольший доход компании.
+
+Очевидно, существуют целые индустрии вокруг мотивационных техник, некоторые из которых применимы и для программистов. Среди таких я могу выделить:
+
+- Использование наиболее подходящего языка программирования для конкретной задачи
+- Поиск возможностей применить новые технологии, языки программирования и техники
+- Попытка либо научить кого-то, либо научиться самому в каждом проекте, как был мал он ни был
+
+Наконец, если возможно, старайтесь измерять свой вклад в работу в том, что для вас персонально имеет значение. Например, когда я работаю над багами, общее число уже исправденных мною багов мне совершенно неинтересно, ведь оно не зависит от общего числа багов, которые все еще возможно существуют. Кроме того, это число отражает мой вклад в самом малом из всех возможных ракурсов. Но соотносить каждый исправленный баг со счастливым клиентом для меня, наоборот, очень ценно, и служит мотивацией в работе.
+
+Следующее: [Как заслужить доверие](02-How-to-be-Widely-Trusted.md)
diff --git a/ru/2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md b/ru/2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md
new file mode 100644
index 0000000..41c82dc
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md
@@ -0,0 +1,7 @@
+# Как заслужить доверие
+[//]: # (Version:1.0.0)
+Чтобы вам доверяли, вы должны заслуживать доверие. Вы также должны быть прозрачны. Если никто не знает вас толком, то никто до конца вам не поверит. С теми, кто близок к вам, например, с вашими коллегами по команде, такой проблемы не будет. Заслужить доверие за пределами своего отдела или команды можно будучи отзывчивым и информативным. Иногда кто-гибудь попробует злоупотребить этим доверием и попросит о необоснованных уступках. Не бойтесь этого, просто объясните, чем вам придется пожертвовать, чтобы выполнить просьбу.
+
+Не притворяйтесь, что знаете то, что вы на самом деле не знаете. С людьми, которые не являются частью вашей команды, вам придется научиться отделять "не могу ответить на это сходу" и "не могу этого знать в принципе".
+
+Следующее: [Как балансировать процессорное время и память](03-How-to-Tradeoff-Time-vs-Space.md)
diff --git a/ru/2-Intermediate/Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md b/ru/2-Intermediate/Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md
new file mode 100644
index 0000000..4ea766e
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md
@@ -0,0 +1,15 @@
+# Как балансировать процессорное время и память
+[//]: # (Version:1.0.0)
+Вы можете быть хорошим программистом, не заканчивая колледж, но вам не стать продвинытум разработчиком без базовых знаний теории сложности вычислений. Вам необязательно знать нотацию "большое О", но я лично считаю, что вам следует понимать разницу между "константным временем вычисления", "n log n" и "n в квадрате". Может быть, вы сможете интуитивно сбалансировать процессорное время и память без этого понимания, но если его нет, у вас не будет прочной базы для взаимодействия с вашими коллегами.
+
+При проектировании или изучении алгоритма важно понимать, что время выполнения алгоритма иногда представляет собой функцию от размера входных данных. Когда это так, мы можем сказать, что худшее/ожидаемое/лучшее время на исполнение этого алгоритма это "n log n", если оно пропорционально размеру ($n$), умноженному на логарифм размера данных. Это обозначение и способ выражения можно применять и к памяти, занимаемой структурой данных.
+
+Для меня теория сложности вычислений так же прекрасна и глубока, как и физика, и ее небольшая часть здорово помогает в работе.
+
+Время (циклы процессора) и память могут сбалансированы одно за счет другого. Это отличный пример того, что программирование - это компромисс. Не всегда оно систематично. В общем виде, съэкономить память можно за счет большего числа вычислений. Обратно, число вычислений можно уменьшить с помощью кэширования, то есть, увеличения памяти, хранящей копии данных. Иногда время можно уменьшить, сохраняя больше информации в структуре данных. Как правило, это требует небольшого объема памяти, но может усложнить алгоритм.
+
+Улучшение компромисса между объемом памяти и скоростью вычислений часто может привести к кардинальному изменения одного из этих параметров. Перед тем, как начать работу, спросите себя, действительно ли то, что вы собираетесь улучшить, нуждается в этом. Работать с алгоритмами интересно, но не позволяйте этому затмить факт, что улучшение того, что не является проблемой, не принесет заметной разницы в программу и увеличит нагрузку на тестирование.
+
+В современных компьютерах память кажется дешевым ресурсом, потому что в отличие от процессорного времени вы не видите, как она используется, пока не упретесь в потолок. Но тогда сбой может оказаться катастрофическим. Существуют и другие скрытые затраты на использование памяти, такие как ваш эффект на сторонние программы, который должен быть постоянным, и время на ее выделение и освобождение. Обдумайте эти моменты перед тем, как вы пожертвуете памятью ради ускорения.
+
+Следующее: [Как проводить стресс-тестирование](04-How-to-Stress-Test.md)
diff --git a/ru/2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md b/ru/2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md
new file mode 100644
index 0000000..2834f05
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md
@@ -0,0 +1,13 @@
+# Как проводить стресс-тестирование
+[//]: # (Version:1.0.0)
+Стресс-тестирование это интересно. Сначала кажется, что его цель - выяснить, будет ли система работать под нагрузкой. В действительности, обычно система работает под нагрузкой, но начинает отказывать в каких-то местах, если нагрузка достаточно большая. Я называю это "упереться в потолок". Могут быть ислючения, но почти всегда это "потолок". Смысл стресс-тестирования в том, чтобы выяснить, где находится этот потолок для системы, а потом понять, как его отодвинуть.
+
+План для стресс-тестирования следует разрабатывать на ранних стадиях проекта, так как часто он помогает прояснить в точности, что именно ожидается от системы. Две секунды на запрос веб-страницы это позорный провал или оглушительный успех? Достаточно ли 500 одновременных пользователей? Ответы зависят от системы, но перед началом ее проектирования их уже стоит знать. Чтобы быть полезным, стресс-тестирование должно достаточно хорошо имитировать действительную нагрузку. Вряд ли возможно смоделировать 500 одновременных хаотичных и непредсказуемых пользователей, используя многопоточность системы, но как минимум можно создать 500 симуляций и попытаться смоделировать некоторую часть того, что будут делать реальные пользователи.
+
+Во время стресс-тестирования начните с небольшой нагрузки и увеличивайте ее по одному параметру системы, например, по частоте входных запросов или по величине входных данных, пока вы не достигнете потолка системы. Если вы достигли его слишком рано, чтобы удовлетворить требованиям к системе, выясните, какой ресурс является узким местом в системе (как правило, сильно не хватает чего-то одного). Что это: память, процессор, операции чтения и записи, пропускная способность сети или нехватка данных? Теперь выясните, как вы можете отодвинуть потолок. Заметьте, что повышение потолка или увеличение нагрузки, с которой справляется система, может не помочь или даже снизить производительность для легконагруженной системы. Обычно производительность под большой нагрузкой важнее производительности под маленькой.
+
+Возможно, вам придется получить представление о нескольких разных параметрах системы, чтобы построить ее мысленную модель. Здесь не хватит какой-то одной техники. Например, логирование часто дает хорошую картину о реальном времени на исполнение команд между двумя событиями в системе, но если оно внедрено небрежно, не дает понимания об использовании памяти или даже о размере структур данных. Аналогично, в современных системах могут взаимодействовать несколько компьютеров и множество программных систем. Когда вы упираетесь в потолок (то есть производительность нелинейно зависит от размера входных данных) эти сторонние программы могут оказаться узким местом. Представление о работе этих программ, даже в виде простого измерения загрузки процессоров на всех задействованных машинах, может оказаться очень полезным.
+
+Знать потолок системы важно не только для того, чтобы отодвинуть его, но и для обеспечения предсказуемости, чтобы эффективно управлять ее разработкой.
+
+Следующее: [Как балансировать краткость и абстракцию](05-How-to-Balance-Brevity-and-Abstraction.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md b/ru/2-Intermediate/Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md
new file mode 100644
index 0000000..b0ce41e
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md
@@ -0,0 +1,10 @@
+# Как балансировать краткость и абстракцию
+[//]: # (Version:1.0.0)
+Абстракция - это ключ к программированию. Следует тщательно выбирать, насколько абстрактны вы хотите быть. Начинающие программисты в своем энтузиазме часто создают больше абстракции, чмъем в действительности необходимо. Один из признаков этого: вы создаете классы, которые почти не содержат код и служат толко для абстрактного представления чего-то. Привлекательность этого подхода понятна, но ценность краткости кода должны быть соизмерена с ценностью абстракции. Иногда можно видеть ошибку, совершаюмую восторженными идеалистами: на старте проекта создается множество классов, которые кажутся восхитительно абстрактными, и можно предположить, что они справятся со всеми ситуациями, которые только могут возникнуть. По мере продвижения проекта и наступления усталости код становится беспорядочным. Тела функций становятся больше, чем они должны быть. Пустые классы это еще и бремя документирования, которые часто игнорируется под давлением. Итоговый результат был бы лучше, если бы энергия, потраченная на абстракцию, была бы потрачена на то, чтобы сохранить код кратким и простым. Это разновидность *спекулятивного программирования*.
+Я очень рекомендую статью ['Succinctness is Power' by Paul Graham](http://www.paulgraham.com/power.html).
+
+Существует определенная догма, связанная с такими полезными техниками как *сокрытие информации* и *объектно-ориентированное программирование*, применение которых иногда заходит слишком далеко. Они позволяют писать код более абстрактно и предвидеть возможные в нем изменения. Однако, я лично считаю, что не следует писать слишком много спекулятивного кода. Например, принято прятать целочисленные переменные в объектах за публичными методами класса, так что сама переменная не видна, а доступен только интерфейс к ней. Это позволяет изменить реализацию этой переменной без изменения вызывающего эти методы кода. Возможно, это подходит для разработки библиотек, где необходимо предоставить устойчивый API. Но я не думаю, что преимущества этого подхода перевешивают избыток кода, потраченного на него, особенно, когда моя команда владеет вызывающим кодом и может переписать как его, так и вызываемый код. Четыре или пять строк кода это большая цена за такое умозрительное преимущество.
+
+Портируемость создает похожую проблему. Должен ли код быть портируемым на другой компьютер, компилятор, систему или платформу, или его стоит просто переписать под них? Я думаю, что непортируемый, короткий и легко переписываемый код лучше, чем длинный портируемый. Относительно легко и обычно хорошая идея ограничить непортируемый код в определенных областях, таких как класс, который выполняет запросы к базе данных, специфичные для данной СУБД.
+
+Следующее: [Как осваивать новые навыки](06-How-to-Learn-New-Skills.md)
diff --git a/ru/2-Intermediate/Personal-Skills/06-How-to-Learn-New-Skills.md b/ru/2-Intermediate/Personal-Skills/06-How-to-Learn-New-Skills.md
new file mode 100644
index 0000000..70d096f
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/06-How-to-Learn-New-Skills.md
@@ -0,0 +1,13 @@
+# Как осваивать новые навыки
+[//]: # (Version:1.0.0)
+Учить новое, особенно что-то нетехническое, это величайшее удовольствие из всех. Большинтсво компаний имели бы гораздо более высокую мораль в коллективе, если бы они понимали, как учеба мотивирует программистов.
+
+Люди учатся на практике. Чтение книг и курсы полезны, но сможете ли вы уважать программиста, который никогда не писал программы? Чтобы чему-нибудь научиться, вы должны поставить себя в положение, когда вы можете применять этот навык. Изучая новый язык программирования, попытайтесь выполнить на нем маленький проект перед тем, как вам придется использовать этот язык в большом проекте. Осваивая управление проектом по разработке программного обеспечения, сначала попробуйте управлять небольшим проектом.
+
+Хороший учитель не заменит практику, но гораздо лучше книги. Что вы можете предложить потенциальному учителю в обмен на его знания? Как минимум, вы можете пообещать усердно учиться, так что время этого человека не будет потрачено впустую.
+
+Постарайтесь уговорить своего босса оплатить вам формальное обучение, но помните, что чаще всего гораздо полезнее потратить то же время на игру с тем навыокм, который вы хотите освоить. Однако, в нашем несовершенном мире легче попросить об обучение, чем о времени на вольную игру, хоть множество обучений сводятся к сну на лекциях в ожидании обеда. 
+
+Если вы руководитель, постарайтесь понять, как учатся ваши подчиненные и помогите им, назначая им такие проекты и задания, которые им по плечу и одновременно позволяют им развить навыки, в которых они заинтересованы. Не забывайте, что самые важные навыки программиста вовсе не технические. Дайте своей команде время экспериментировать и практиковаться в смелости, честности и взаимодействии.
+
+Следующее: [Научитесь печатать вслепую](07-Learn-to-Type.md)
diff --git a/ru/2-Intermediate/Personal-Skills/07-Learn-to-Type.md b/ru/2-Intermediate/Personal-Skills/07-Learn-to-Type.md
new file mode 100644
index 0000000..58a39df
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/07-Learn-to-Type.md
@@ -0,0 +1,5 @@
+# Научитесь печатать вслепую
+[//]: # (Version:1.0.0)
+Научитесь печатать вслепую. Это навык среднего уровня, потому что писать код настолько сложно, что скорость его набора неважна и несильно влияет на затраченное время на разработку, насколько бы хорошим программистом вы не являлись. Однако, к тому времени, как вы станете программистом среднего уровня, скорее всего вы потратите кучу времени на письменное общение с коллегами и всеми остальными. Этот навык - забавная проверка вашей целеустемленности. Он требует отдельного времени, которое не так забавно потратить именно на него. Легенда гласит, что когда Майкл Тименн работал в Microelectronics and Computer Technology Corporation, его коллеги собирались у двери его кабинета послушать гул, производимый им при нажатии клавиш. Они были настолько быстры, что были практически неразличимы.
+
+Следующее: [Как выполнять интеграционное тестирование](08-How-to-Do-Integration-Testing.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Personal-Skills/08-How-to-Do-Integration-Testing.md b/ru/2-Intermediate/Personal-Skills/08-How-to-Do-Integration-Testing.md
new file mode 100644
index 0000000..cc2e778
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/08-How-to-Do-Integration-Testing.md
@@ -0,0 +1,7 @@
+# Как выполнять интеграционное тестирование
+[//]: # (Version:1.0.0)
+Интеграционное тестирование это совместное тестирование отдельных компонентов, которые прошли до этого юнит-тестирование. Интеграция дорого обходится, и это выясняется при тестировании. Вы должны включать время на интеграционное тестирование в свои оценки затрат и в расписание.
+
+В идеале вы должны организовать проект таким образом, чтобы в конце не было этапа, где явным образом должна происходить интеграция. Гораздо лучше постепенно интегрировать компоненты по мере их завершения в ходе проекта. Если это неизбежно, тщательно оцените временные затраты на такой этап.
+
+Следующее: [Communication Languages](09-Communication-Languages.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md b/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md
new file mode 100644
index 0000000..a0a4c37
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md
@@ -0,0 +1,11 @@
+# Языки взаимодействия систем
+[//]: # (Version:1.0.0)
+Существуют языки, то есть формально определенные синтаксические системы, которые являются не языками программирования, а языками взаимодействия систем, создаными специально для облегчения взаимодействия через стандартизацию. В 2003 году самые важные из них это UML, XML и SQL. Вы должны быть знакомы с каждым из них, чтобы уметь использовать их и понимать, когда их следует применять.
+
+UML - это обширная формальная система для создания схем и диаграмм, описывающих архитектуру. Ее прелесть в том, что она одновременно и визуальна, и формальна, и способна передать огромное количество информации, если автор и его аудитория понимают UML. Вам следует знать UML, потому что иногда архитектуру описывают с его помощью. Существуют очень полезные инструменты для создания проессионально выглядящих схем UML. Во многих случаях, UML слишком строгая и формальная система, и я иногда находил, что для архитектурных схем проще использовать стрелки и прямоугольники. Но я уверен, что изучение UML полезно так же, как и изучение латыни.
+
+XML - это стандарт для определения новых стандартов. Это не решение проблем передачи данных, хотя иногда вы увидите, что XML представляют именно так. Но скорее, это средство автоматизации самой скучной работы по обмену данных, а именно структурное представление данных в линейной последовательности и обратный синтаксический анализ этого последовательности в структуру данных. UML предоставляет неплохую проверку типов и правильности данных, хотя это лишь небольшая часть того, что вам понадобится в работе.
+
+SQL - это очень мощный и богатый язык запросов и манипулирования данными, и он не совсем является языком программирования. У него есть много вариаций, в основном зависимых от конкретного продукта, который его использует. Они не так важны как стандартное ядро языка. SQL - это основа всех реляционных баз данных. Вы можете не работать в области, где требуется понимание такого типа баз данных, но вам все равно следует иметь базовое представление о них и о синтаксисе и назначении SQL.
+
+Следующее: [Стандартные технологии](10-Heavy-Tools.md)
diff --git a/ru/2-Intermediate/Personal-Skills/10-Heavy-Tools.md b/ru/2-Intermediate/Personal-Skills/10-Heavy-Tools.md
new file mode 100644
index 0000000..93d3696
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/10-Heavy-Tools.md
@@ -0,0 +1,14 @@
+# Стандартные технологии
+ [//]: # (Version:1.0.0)
+По мере того, как развиваются технологии, разработка программного обеспечения переходит к использованию стандартизированных широко распространенных и незатратных продуктов. Это технологии могут взять на себя большую нагрузку в разработке программного обеспечения, но одновременно могут показаться пугающе непонятными и требовать много времени на освоение. Программист среднего уровня должен знать, как управлять этими технологиями и когда следует их использовать.
+
+На мой взгляд некоторыми примерами таких технологий являются:
+
+- Реляционные базы данных
+- Полнотекстовые поисковые системы
+- Математические бибилиотеки
+- OpenGL
+- XML-парсеры
+- Элеткронные таблицы
+
+Следующее: [Как анализировать данные](11-How-to-analyze-data.md)
diff --git a/ru/2-Intermediate/Personal-Skills/11-How-to-analyze-data.md b/ru/2-Intermediate/Personal-Skills/11-How-to-analyze-data.md
new file mode 100644
index 0000000..85e3cef
--- /dev/null
+++ b/ru/2-Intermediate/Personal-Skills/11-How-to-analyze-data.md
@@ -0,0 +1,11 @@
+# Как анализировать данные
+[//]: # (Version:1.0.0)
+Анализ данных - это ранний этап разработки, когда вы изучаете предметную область и определяете требования для преобразования их в программное обеспечение. Это формальное определение может заставить подумать, что анализ данных это деятельность, которую стоит оставить на системных аналитиков. А программисты должны сосредоточиться на написании кода, который те спроектируют. Если мы последует строго парадигме разработки, то возможно, это будет корректная идея. Опытные программисты становятся архитекторами, а лучшие архитекторы становятся бизнес-аналитиками и отвечают об требованиях к данным и выдают программистам четко определенное задание для написания кода. Но это не совсем так, так как данные это ядро любой деятельности программистов. Что бы вы не делали в своей программе, вы либо передаете, либо изменяете данные. Бизнес-аналитик изучает требования в широком виде, архитектор в чуть более узком разрезе, так что, когда проблема приходит в вам, кажется, что все, что вам надо сделать, это применить нужные алгоритмы и начать взаимодействовать с имеющимися данными.
+
+Это не так.
+
+Неважно, на каком этапе вы начинаете работать с данными, они всегда остаются главной проблемой хорошо спроектированного приложения. Если вы внимательно посмотрите, как бизнес-аналитик извлекает требования из запросов клиентов, то я поймете, что данные играют фндаментальную роль. Аналитик создает так называемые диаграммы потоков данных, где указаны источники данных, и обозначен поток информации. Определив, какие данные будут частью системы, архитектор начнет формировать источники данных с точки зрения баз данных, протоколов обмена данными и форматов файлов. После этого задачу можно передавать программисту. Но процесс на этом не заканчивается, потому что вы (программист) даже после подобной тщательной обработки данных должны проанализировать их, чтобы выполнить задачу оптимальным способом. В основе вашей работы лежит идея Никлауса Вирта, создателя нескольких языков программирования. "Алгоритмы + Структуры данных = Программы". Алгоритм никогда не существует отдельно, делая что-то сам по себе. Каждый алгоритм обязательно взаимодействует как минимум с какой-то частью данных.
+
+Таким образом, раз алгоритмы не функционируют в вакууме, вы должны анализировать и данные, которые кто-то передал вам для разработки, и данные, которые надо воплотить в коде. Вот простой пример. Вы пишите программу для поиска книг в библиотеки. Согласно вашей спецификации пользователь может выбрать книги по сочетанию жанра, автора, названию, издателю, году издания и числу страниц. Конечная цель вашего модуля - создать корректный запрос SQL для отправки в базе данных. Основываясь на этих требованиях, вы можете выбирать варианты. Можно проверять каждый параметр по очереди, используя оператор "switch" или несколько последовательных "if". Можно создать массив параметров и проверять, есть ли в нем каждый параметр. Можно создать (или использовать) абстрактный объект для контроля данных, от которого унаследовать конкретные параметры и связать их с механизмом управления событиями. Если в требованиях есть есть настройка производительности запроса через проверку параметров в определенном порядке, то вы можете рассмотреть применение дерева компонентов для построения SQL-запроса. Как видно, выбор алгоритма зависит от данных, которые вы решите использовать или создать. Подобные решения часто отделяют эффективные алгоритмы от провальных. Однако, эффективность здесь не единственная проблема. Вы можете создать десяток переменных и сделать их максимально эффективными. Но такой код не будет легко поддерживаемым. Возможно, выбор подходящего контейнера для хранения всех ваших переменных поможет сохранить ту же скорость алгоритма и вдобавок сделает код более понятным для ваших коллег, когда они вернутся к нему в следующем году. Более того, хорошо выбранная структура данных позволит им легко расширить функциональность вашего кода без переписывания уже имеющихся частей. В конечном счете ваш выбор данных определяет, как долго просуществует ваш код. Еще один пример для размышлений. Преположим, у вас задача найти все слова в словаре с тремя и более анаграммами. При этом анаграмма должна быть другим словом в этом же словаре. Если вы будете думать об этой задаче, как о задаче на вычисление, то вы придете к бесконечным вычислениям в попытке вычислить все комбинации анаграмм для каждого слова и сравнить их со всеми остальными словами в словаре. Однако, анализируя исходные данные, вы можете заметить, что каждое слово можно представить как запись с самим словом и сортированным массивом из его букв в виде ID. С этим знаением нахождение анаграмм превращается в сортировку этого массива и нахождение слов с аналогичным ID. Прямой алгоритм может потребовать несколько дней на выполнение, тогда как более хитрый выполняется за несколько секунд. Вспомните этот пример, когда в следующий раз вы стокнетесь с неразрешимой проблемой.
+
+Следующее: [Командные навыки. Как управлять временем разработки](../Team-Skills/01-How-to-Manage-Development-Time.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/README.md b/ru/2-Intermediate/README.md
new file mode 100644
index 0000000..3728f8b
--- /dev/null
+++ b/ru/2-Intermediate/README.md
@@ -0,0 +1,29 @@
+# 2. Разработчик среднего уровня
+[//]: # (Version:1.0.0)
+- Личные навыки
+	- [Как сохранять мотивацию](Personal-Skills/01-How-to-Stay-Motivated.md)
+	- [Как заслужить доверие](Personal-Skills/02-How-to-be-Widely-Trusted.md)
+	- [Как балансировать процессорное время и память](Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md)
+	- [Как проводить стресс-тестирование](Personal-Skills/04-How-to-Stress-Test.md)
+	- [Как балансировать краткость и абстракцию](Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md)
+	- [Как осваивать новые навыки](Personal-Skills/06-How-to-Learn-New-Skills.md)
+	- [Научитесь печатать вслепую](Personal-Skills/07-Learn-to-Type.md)
+	- [Как выполнять интеграционное тестирование](Personal-Skills/08-How-to-Do-Integration-Testing.md)
+	- [Языки взаимодействия систем](Personal-Skills/09-Communication-Languages.md)
+	- [Стандартные технологии](Personal-Skills/10-Heavy-Tools.md)
+	- [Как анализировать данные](Personal-Skills/11-How-to-analyze-data.md)
+- Командные навыки
+	- [Как управлять временем разработки](Team-Skills/01-How-to-Manage-Development-Time.md)
+	- [Как управлять рисками, связанными со сторонним программным обеспечением](Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md)
+	- [Как руководить консультантами](Team-Skills/03-How-to-Manage-Consultants.md)
+	- [Как соизмерять количество общения](Team-Skills/04-How-to-Communicate-the-Right-Amount.md)
+	- [Как честно выражать несогласие](Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md)
+- Экспертиза
+	- [Как балансировать качество и время разработки](Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md)
+	- [Как управлять зависимостями](Judgment/02-How-to-Manage-Software-System-Dependence.md)
+	- [Как оценивать стороннее программное обеспечение](Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md)
+	- [Как решать: покупать программу или писать свою](Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md)
+	- [Как расти профессионально](Judgment/05-How-to-Grow-zProfessionally.md)
+	- [Как проводить собеседования](Judgment/06-How-to-Evaluate-Interviewees.md)
+	- [Как понять, когда применять высокие технологии](Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md)
+	- [Как разговаривать с неинженерами](Judgment/08-How-to-Talk-to-Non-Engineers.md)
diff --git a/ru/2-Intermediate/Team-Skills/01-How-to-Manage-Development-Time.md b/ru/2-Intermediate/Team-Skills/01-How-to-Manage-Development-Time.md
new file mode 100644
index 0000000..591bd7f
--- /dev/null
+++ b/ru/2-Intermediate/Team-Skills/01-How-to-Manage-Development-Time.md
@@ -0,0 +1,11 @@
+# Как управлять временем разработки
+[//]: # (Version:1.0.0)
+Чтобы управлять временем разработки, поддерживайте четкий и актуальный проектный план. Проектный план - это оценка временных затрат, расписание, набор промежуточных этапов для отслеживания прогресса и распределение времени вашей команды на каждое задание. Он также должен включать другие вещи, которые важно помнить, такие как встречи с командой тестирования, подготовка документации, заказ рабочего оборудования. Если вы работаете в команде, проектный план должен быть согласованным решением, как на старте проекта, там и по его ходу.
+
+Проектный план служит для принятия решения, а не для демострации того, насколько вы организованы. Если он слишком опдробный или неактуальный, к нему бесполезно обращаться для принятия решений. В реальности, все решения это решения насчет конкретных людей. План и ваша экспертиза позволять вам понять, следует ли передать часть задач одного члена команду другому. Этапы проекта отмечают его прогресс. Если вы используете модный современный трекер задач для планирования проекта, не поддавайтесь соблазну сходу расписать большой предварительный план. Лучше используйте его, чтобы поддерживать емкость и актуальность задач.
+
+Если вы не успеваете выполнить этап, следует немедленно предпринять что-то, как минимум проинформировать босса о том, что запланированное завершение проекта сместится на некоторое время. Начать с того, что оценка и расписание никогда не будут идеальны, но они дают иллюзию, что вы сможете наверстать пропущенные дни в конце проекта. Может быть. Но так же вероятно, что вы недооценили эту часть проекта, как и то, что вы ее переоценили. Так что запланированное завершение проекта уже сместилось, нравитс вам это или нет.
+
+Убедитесь, что ваш план включает время на внутренние совещания команды, демострации проекта, документацию, периодические задачи по расписанию, интеграционное тестирование, общение с внешними командами, больничные, отпуска, поддержку существующих продуктов и окружения разработки. Проектный план может представить сторонним людям или боссу, чтобы они поняли, чем занята команда. По этой причине он должен быть краток и актуален.
+
+Следующее: [Как управлять рисками, связанными со сторонним программным обеспечением](02-How-to-Manage-Third-Party-Software-Risks.md)
diff --git a/ru/2-Intermediate/Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md b/ru/2-Intermediate/Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md
new file mode 100644
index 0000000..7296524
--- /dev/null
+++ b/ru/2-Intermediate/Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md
@@ -0,0 +1,11 @@
+# Как управлять рисками, связанными со сторонним программным обеспечением
+[//]: # (Version:1.0.0)
+Проект часто зависит от стороннего программного обеспечения, над которым у вас нет контроля. С этим связаны большие риски, которые должны быть понятны каждому, кто работает в проекте.
+
+Никогда не возлагайте никаких надежд на якобы обещанное, но пока еще недоступное программное обеспечение. Это вернейший способ вылететь в трубу. Неразумно просто скептически относиться к обещанию сторонней компании выпустить определенны продукт к определенной дате. Гораздо разумнее полностью проигнорировать его и забыть о его существовании. Никогда не записывайте такие надежды в документы вашей компании.
+
+Если стороннее программное обеспечение все же существует, оно по-прежнему несет с собой риски, но по крайней мере эти риски можно преодолеть. Если вы предполагаете использование сторонних программ, уже на ранней стадии проекта следует посвятить время на их оценку. Никому не понравится услышать, что потребуется две недели или два месяца на оценку пригодности всех трех сторонних программ, но это то, что должно быть сделано как можно скорее. Стоимость интеграции нельзя оценить без надлежащей оценки задействованных сторонних программ.
+
+Понимание пригодности существующих сторонних программ для конкретных задач - это очень отраслевое знание. Оно субъективно и главным образом опирается на экспертов. Вы можете съэконоить кучу времени, если сможете найти экспертов. Часто проект настолько зависит от стороннего программного обеспечения, что если интеграция провалится, то провалится весь проект. Выразите все подобные риски в проектном плане. Постарайтесь иметь план на случай непредвиденных обстоятельств, например, альтернативные сторонние программы или возможность реализовать часть их функциональности самостоятельно. 
+
+Следующее: [Как руководить консультантами](03-How-to-Manage-Consultants.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md b/ru/2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md
new file mode 100644
index 0000000..f70d33e
--- /dev/null
+++ b/ru/2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md
@@ -0,0 +1,9 @@
+# Как руководить консультантами
+[//]: # (Version:1.0.0)
+Используйте консультантов, но не полагайтесь на них. Эти замечательные людии заслуживают всяческого уважения. Поскольку они наблюдали множество проектов, они зачастю знают больше о специфических технологиях или даже техниках программирования, чем вы. Лучший способ использовать их как штатных преподавателей, которые могут научить на собственном примере.
+
+Однако, обычно консультанты не могут стать частью команды в том смысле, что и обычные сотрудники, хотя бы потому, что у вас может не хватить времени изучить их сильные и слабые стороны. Их финансовые обязательства гораздо ниже. Они могут легко уйти. Они меньше выигрывают, если компания в целом процветает. Некоторые из них будут хороши, некоторые средними, некоторые плохими консультантами. Поскольку ваш выбор консультантов будет не так тщателен, как подбор сотрудников, чаще вы будете встречать плохих.
+
+Если консультанты пишут код, то вы должны тщательно ревьюить его по мере работы. Нельзя доводить проект до конца, рискуя оставить большой непроверенный блок кода. Это относится ко всем членам команды, но обычно вы их знаете лучше, чем консультантов.
+
+Следующее: [Как соизмерять количество общения](04-How-to-Communicate-the-Right-Amount.md)
\ No newline at end of file
diff --git a/ru/2-Intermediate/Team-Skills/04-How-to-Communicate-the-Right-Amount.md b/ru/2-Intermediate/Team-Skills/04-How-to-Communicate-the-Right-Amount.md
new file mode 100644
index 0000000..00d4402
--- /dev/null
+++ b/ru/2-Intermediate/Team-Skills/04-How-to-Communicate-the-Right-Amount.md
@@ -0,0 +1,7 @@
+# Как соизмерять количество общения
+[//]: # (Version:1.0.0)
+Тщательно соизмеряйте стоимость совещания. Оно равно *его длительности, умноженной на числу участников*. Иногда совещания необходимы, но небольшие совещания лучше. Качество общения на небольших совещаниях лучше, и на них уходит меньше времени. Если на совещании кто-нибудь скучает, то это знак, что следующее собрание должно быть меньше.
+
+Необходимо следует все возможное, чтобы поощрять неформальное общение. Во время обеда с коллегами делается больше полезной работы, чем в любое другое время. Жаль, что многие компании не признают и не поддерживают этот факт.
+ 
+Следующее: [Как честно выражать несогласие](05-How-to-Disagree-Honestly-and-Get-Away-with-It.md)
diff --git a/ru/2-Intermediate/Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md b/ru/2-Intermediate/Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md
new file mode 100644
index 0000000..6c3d489
--- /dev/null
+++ b/ru/2-Intermediate/Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md
@@ -0,0 +1,11 @@
+# Как честно выражать несогласие
+[//]: # (Version:1.0.0)
+Несогласие это прекрасная возможность принять хорошее решение, но егоследует выражать аккуратно. Надеюсь, обычно вы спокойно выражаете свою точку зрения, вас внимательно слушают, а затем принимается решение. В этом случае больше нечего сказать, и вам только остается принять решение, даже если вы с ним несогласны. Если вы можете следовать решению несмотря на свое несогласие, скажите об этом. Это продемострирует, что вы независимы и не поддакиваете просто так, но одновременно уважаете принятое решение и всю команду.
+
+Иногда решение, с которым вы несогласны, принимается потому, что те, кто его принимает, не имели возможности полностью оценить ваше мнение. В этом случае, исходя из пользы для компании или команды вам стоит прикинуть, поднимать ли вопрос. Если это небольшая на ваш взгляд ошибка, то, возможно, не стоит пересматривать решение. Если же речь идет о серьезной ошибке, то стоит выдвинуть возражения.
+
+Обычно, возражения это не проблема. В некоторых стрессовых ситуациях и с некоторыми типами личностей они могут быть приняты на личный счет. Например, некоторые очень хорошие программисты недостаточно уверены в себе, чтобы возразить, даже если у них на это есть веские причины. В худшем случае, тот, кто принимает решения неуверен в себе и принимает возражения как вызов своему авторитету. Здесь важно помнить, что в таких обстоятельствах люди в первую очередь реагируют инстинктивно. Вам стоит высказать свои возражения лично и постараться показать, как новые аргументы изменят основу, на которой принимается решение.
+
+Независимо от того, будет решение отменено или нет, вы должны помнить, что вы не сможете сказать "Я же говорил!", поскольку альтернативное решение было полностью изучено.
+
+Следующее: [Экспертиза. Как балансировать качество и время разработки](../Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md)
diff --git a/ru/3-Advanced/Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md b/ru/3-Advanced/Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md
new file mode 100644
index 0000000..c851c12
--- /dev/null
+++ b/ru/3-Advanced/Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md
@@ -0,0 +1,11 @@
+# Как справляться с давлением графика
+[//]: # (Version:1.0.0)
+Давление выхода на рынок - это давление быстро выпустить хороший продукт. Это хорошо, поскольку отражает финансовую действительность и до некоторой степени это полезное давление. Давление графика - это давление выпустить что-то быстрее, чем это возможно, и это давление опустошает, оно нездоровое и встречается слишком часто.
+
+Давление графика существует по нескольким причинам. Люди, дающие задания программистам не до конца ценят нашу рабочую этику и насколько здорово быть программистом. Возможно, поскольку они проецируют собственное поведение на нас, они ожидают, что просьба сделать задачу быстрее заставит нас работать усерднее. Возможно, это так, но эффект от такой просьбы очень мал, а ущерб велик. Вдобавок, они не понимают, что в действительности значит разработать программное обеспечение. Они не могут этого понять, не могут разработать систему самостоятельно, поэтому единственное, что им остается, это наблюдать за давлением выхода на рынок и подталкивать программистов.
+
+Лучшее, что можно сделать с давлением графика, это превратить его в давление выхода на рынок. Для этого надо дать четкое представление о связи между имеющимися затратами и продуктом. Лучший способ это дать честную, детальную и, самое главное, понятную оценку всех трудозатрат. Это дает дополнительное преимущество в виде возможности принимать правильные управленческие решения насчет возможных компромиссов в функциональности.
+
+Ключевая мысль, которую должна прояснить оценка, заключается в том, что работа очень похожа на несжимаемую жидкость. Вы не можете вместить в промежуток времени больше работы, так как не можете вместить в контейнер больше воды, чем его объем. В некотором смысле, программист должен не говорить "Нет", а спрашивать в ответ "Чем вы готовы пожертвовать, чтобы эта работа была сделана?". Эффект от составления четких планов и оценок заключается в повышении уважения к программистам. Именно так ведут себя профессионалы. Усердная работа программистов станет видна, и нереалистичный график станет очевиден для всех. Программистов нельзя провести. Нереалистичный график это неуважение к команде, он сильно деморализует людей. Экстремальное программирование расширяет эту идею и строится вокруг нее. Я надеюсь, что каждому из читателей посчастливится использовать его в работе.
+
+Следующее: [Как понять пользователя](02-How-to-Understand-the-User.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Compromising-Wisely/02-How-to-Understand-the-User.md b/ru/3-Advanced/Compromising-Wisely/02-How-to-Understand-the-User.md
new file mode 100644
index 0000000..0fc20d6
--- /dev/null
+++ b/ru/3-Advanced/Compromising-Wisely/02-How-to-Understand-the-User.md
@@ -0,0 +1,17 @@
+# Как понять пользователя
+[//]: # (Version:1.0.0)
+Ваша обязанность - это понять пользователя и помочь это сделать вашему боссу. Поскольку пользователи непосредственно не вовлечены в разработку вашего продукта, они ведут себя слегка иначе:
+
+- Обычно пользователи выносят короткие суждения
+- У пользователей есть своя работа, они будут скорее думать о небольших доработках в вашем продукте, чем о больших улучшениях
+- Мнение одного пользователя не может представлять общее мнение всех пользователей вашего продукта
+
+Ваша обязанность - дать пользователям не то, что они говорят, что хотят, а то, что они хотят в дествительности. Однако, лучше всего это сформулировать для ваших пользователей и получить от них ответ, что ваше предложение действительно отвечает их реальных желаниям. Хотя у пользователей может не хватит полного представления для ответа. Ваша уверенность в собственных идеях на этот счет должно варьироваться. Следует одинаково опасаться как самоуверенности, так и ложной скромности, когда речь идет о нуждах вашего пользователя. Программисты нацелены на проектирование и создание. Исследователи рынка нацелены на выявление нужд потребителей. Эти два типа людей или два типа мышления в одном человеке, гармонично работая в связке, дают наилучший шанс сформировать правильное представление.
+
+Чем больше времени вы проведете с пользователями, тем лучше вы сможете понять, что будет лучшим для них. Вам стоит проверять свои идеи на пользователях так часто, насколько это вообще возможно. Вам стоит обедать с ними, если это возможно.
+
+Гай Кавасаки [Rules] подчеркивает важность *наблюдения* того, чем заняты ваши пользователи, дополнительно к выслушиванию их.
+
+Я думаю, что у подрядчиков и консультантов часто возникают большие проблемы с тем, чтобы их клиенты прояснили в своем сознаннии, что они хотят в действительности. Если вы намерены быть консультантом, я бы предложил вам выбирать клиентов по четкости их мыслей и по кошельку.
+
+Следующее: [Как получить повышение](03-How-to-Get-a-Promotion.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Compromising-Wisely/03-How-to-Get-a-Promotion.md b/ru/3-Advanced/Compromising-Wisely/03-How-to-Get-a-Promotion.md
new file mode 100644
index 0000000..b557ea9
--- /dev/null
+++ b/ru/3-Advanced/Compromising-Wisely/03-How-to-Get-a-Promotion.md
@@ -0,0 +1,13 @@
+# Как получить повышение
+[//]: # (Version:1.0.0)
+Чтобы получить повышение по роли, сначала начните играть эту роль.
+
+Чтобы получить повышение по должности, выясните, что ожидается от этой должности, и сделайте это.
+
+Чтобы получить прибавку к зарплате, обговорите это, имея на руках веские аргументы в свою пользу.
+
+Если вы чуствуете, что вас обошли с повышением, поговорите с боссом об этом. Спросите его в явном виде, что вы должны делать, чтобы получить повышение, и постарайтесь сделать это. Это кажется банальным, но часто ваше представление того, что вам надо делать, отличается от представления вашего босса. Кроме того, такой разговор в некотором смысле подтолкнет вашего босса.
+
+Большинство программистов скорее всего имеют преувеличенное представление о собственных способностях, в конце концов, мы все не можем входить в 10% лучших программистов. Однако, я встречал и людей, которые были очень сильно недооценены. Нельзя ожидать, что оценка каждого будет на 100% совпадать с реальностью, но я думаю, что в общем люди довольно справедливо себя оценивают, но с одной оговоркой: вас нельзя справедливо оценить без видимости вашей работы. Иногда из-за обстоятельств или личных качеств кто-то будет не настолько сильно заметен. Работа из дома или географически удаленно от вашей команды и босса делает это особенно трудным. 
+
+Следующее: [Serving Your Team - Как развивать таланты](../Serving-Your-Team/01-How-to-Develop-Talent.md)
diff --git a/ru/3-Advanced/README.md b/ru/3-Advanced/README.md
new file mode 100644
index 0000000..3e314ce
--- /dev/null
+++ b/ru/3-Advanced/README.md
@@ -0,0 +1,22 @@
+# 3. Advanced
+[//]: # (Version:1.0.0)
+- Технологическая экспертиза
+	- [Как отличить сложное от невозможного](Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md)
+	- [Как использовать встроенные языки](Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md)
+	- [Выбор языка программирования](Technical-Judgment/03-Choosing-Languages.md)
+- Правильные компромиссы
+	- [Как справляться с давлением графика](Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
+	- [Как понять пользователя](Compromising-Wisely/02-How-to-Understand-the-User.md)
+	- [Как получить повышение](Compromising-Wisely/03-How-to-Get-a-Promotion.md)
+- Управление командой
+	- [Как развивать таланты](Serving-Your-Team/01-How-to-Develop-Talent.md)
+	- [Как выбрать, над чем работать](Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md)
+	- [Как получить наибольшую отдачу от коллег](Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md)
+	- [Как разделять задачи](Serving-Your-Team/04-How-to-Divide-Problems-Up.md)
+	- [Как распределять скучные задания](Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md)
+	- [Как получить поддержку для проекта](Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md)
+	- [Как развивать систему](Serving-Your-Team/07-How-to-Grow-a-System.md)
+	- [Как качественно взаимодействовать](Serving-Your-Team/08-How-to-Communicate-Well.md)
+	- [Как сообщать неприятное](Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md)
+	- [Как справляться с менеджерскими мифами](Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md)
+	- [Как справляться с организационным хаосом](Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md)
diff --git a/ru/3-Advanced/Serving-Your-Team/01-How-to-Develop-Talent.md b/ru/3-Advanced/Serving-Your-Team/01-How-to-Develop-Talent.md
new file mode 100644
index 0000000..1632ac8
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/01-How-to-Develop-Talent.md
@@ -0,0 +1,23 @@
+# Как развивать таланты
+
+Ницше преувеличил, когда сказал [Stronger]:
+
+> Всё, что меня не убивает, делает меня сильнее.
+
+Ваша самая главная ответственность - это ваша команда. Вы должны хорошо знать каждого из членов команды. Вы должны нагружать свою команду, но не перегружать. Следует разговаривать с членами вашей команды об их нагрузке. Если они согласны с ней, то они будут хорошо мотивированы. В каждом проекте старайтесь нагружать их таким образом, чтобы они были согласны со своей нагрузкой, и одновременно, чтобы она совпадала с вашим собственным мнением о том, что нужно членам вашей команды. Нагружайте их не объемом работы, а новым навыком или слегка иной ролью в команде.
+
+Вам следует позволять людям (и себе тоже) иногда ошибаться. Предусматривайте эти неудачи в своем графике. Если никогда нет ошибок и неудач, то нет и чувства приключения. Если иногда нет ошибок и неудач, значит, вы недостаточно стараетесь. Когда кто-то ошибается, вам следует вести себя так вежливо, как вы можете, одновременно не относясь к человеку так, словно он преуспел.
+
+Постарайтесь вовлечь и увлечь каждого из членов команды. Спросите каждого из них в явном виде, что им нужно для мотивации, если они еще не мотивированы. Возможно, вы не сможете удовлетворить всех, но все же стоит узнать, кто что хочет.
+
+Нельзя мириться с тем, кто намеренно не тянет свою часть нагрузки из-за низкого морального духа или неудовлетворенности. Нельзя позволять отлынивать. Вы должны стараться привести таких людей в состояние высокой мотивации и продуктивности. Пока у вас хватает терпения, подталкивайте их в этом направлении. Когда ваше терпение иссякнет, увольняйте их. Нельзя позволять тому, кто намеренно работает ниже своего уровня, оставаться в команде. Это несправедливо по отношению к остальным.
+
+Выскажите публично сильным членам своей команды, что вы думаете, что они сильные сотрудники. Хвалите публично и критикуйте наедине.
+
+Более сильные члены вашей команды естественно будут заняты более трудными задачами, чем слабые. Это абсолютно нормально, и пока все в команде работают усердно, никто не должен заморачиваться по этому поводу.
+
+Странный факт, который не отражается на зарплатах, заключается в том, что хороший программист продуктивнее 10 плохих. Это порождает странную ситуацию. Часто будет случаться, что вы будете быстрее продвигаться по проекту, если отстранить от работы всех слабых членов команды. Если бы вы так поступали бы, то действительно в краткосрочной перспективе вы добьетесь большего прогресса. Однако, ваша команда потеряет несколько важных преимуществ, а именно обучение слабых членов команды, распространение знаний и способность команды восстанавливаться при потере сильных программистов. Сильные программисты должны быть снисходительными в этом плане и стараться видеть общую картину. 
+
+Часто вы можете дать более сильным членам команды сложные, но тщательно разграниченные задачи.
+
+Следующее: [Как выбрать, над чем работать](02-How-to-Choose-What-to-Work-On.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md b/ru/3-Advanced/Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md
new file mode 100644
index 0000000..5b759f7
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md
@@ -0,0 +1,5 @@
+# Как выбрать, над чем работать
+
+Вы балансируете свои собственные потребности с потребностями команды через выбор того аспекта проекта, над которым вы работаете. Вам  следует делать то, что у вас получается лучше всего, но ищите способы занять себя не увеличением работы, а применением новых навыков. Лидерство и навыки общения более важны, чем технические навыки. Если вы очень сильный программист, берите на себя самые сложные или рискованные задачи и выполняйте их как можно раньше, чтобы снизить риски.
+
+Следующее: [Как получить наибольшую отдачу от коллег](03-How-to-Get-the-Most-From-Your-Teammates.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md b/ru/3-Advanced/Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md
new file mode 100644
index 0000000..8f469b2
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md
@@ -0,0 +1,15 @@
+# Как получить наибольшую отдачу от коллег
+
+Чтобы получить наибольшую отдачу от коллег, развивайте дружеский командный дух и старайтесь, чтобы каждый был лично востребован и вовлечен.
+
+В развитии командного духа помогают такие банальные штуки как одежда с лого компании и корпоративы, но нет ничего лучше личного взаимоуважения. Если все уважают друг друга, то никто никого не захочет подводить. Командный дух появляется, когда люди жертвуют ради команды и думают в рамках блага для всей команды, а не о личной выгоде. Как лидер, вы не можете требовать большего, чем лично вы делаете в этом отношении.
+
+Одним из ключевых моментов в руководстве команды является достижение консенсуса, чтобы все были вовлечены в решение. Иногда это означает позволить своей команде ошибиться. То есть, если это не принесет большого ущерба проекту, вы должны позволить части своей команды поступать по-своему, основываясь на консенсусе, даже вы абсолютно уверены, что это неверное решение. В этом случае не надо соглашаться с коллегами, просто открыто выразите свое несогласие и примите общее решение. Не говорите обиженно или как будто вы вынуждают к решению, просто обозначьте, что вы несогласны, но для вас решение команды гораздо важнее. Часто это заставит команду изменить свое решение. В этом случае, не заставляйте ее следовать первоначальному плану.
+
+Если найдется человек, который не согласится с вами после того, как вы рассмотрите проблему со всех сторон, просто скажите, что вам надо принять решение, и это ваше решение. Если есть возможность проверить, было ли ваше решение ошибочным или позднее окажется, что оно ошибочно, измените его, как только сможете, и признайте правоту тех, кто был с вами несогласен.
+
+Спросите свою команду как в группе, так и индивидуально, что по их мнению создает командный дух и делает команду эффективной.
+
+Хвалите часто, но не много. Особенно хвалите тех, кто не согласен с вами, если в итоге они заслуживают похвалы. Хвалите публично и критикуйте наедине. Одно исключение: иногда прогресс или исправление ошибки нельзя отметить без упоминания виновника ошибки, в этом случае хвалите наедине.
+
+Следующее: [Как разделять задачи](04-How-to-Divide-Problems-Up.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/04-How-to-Divide-Problems-Up.md b/ru/3-Advanced/Serving-Your-Team/04-How-to-Divide-Problems-Up.md
new file mode 100644
index 0000000..1d614f5
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/04-How-to-Divide-Problems-Up.md
@@ -0,0 +1,9 @@
+# Как разделять задачи
+
+Брать проект по разработке программного обеспечения и делить его на индивидуальные задачи весело. Это стоит делать на ранних этапах. Иногда менеджеры склонны думать, что оценку затрат можно сделать без учета людей, которые будут выполнять задачи. Но это невозможно, так как продуктивность людей очень различается. Человек, обладающий конкретными знаниями о компоненте системы, также постоянно меняется, и это влияет на производительность.
+
+Подобно композитору, который учитывает тембр инструмента, играющего партию или тренеру спортивной команды, держащему в уме сильные стороны каждого игрока, опытный руководитель не сможет отделить разделение проекта на задачи от членов команды, которые будут заниматься этими задачами. Это одна из причин, по которой высокоэффективную команду не стоит разбивать на части.
+
+В этом есть определенная опасность, что люди будут скучать, так как такие команды основаны на сильных сторонах каждого. В этом случае члены команды не улучшают свои слабые стороны и не развивают новые навыки. Однако, специализация очень эффективна для производительности, если ею не злоупотреблять.
+
+Следующее: [Как распределять скучные задания](05-How-to-Handle-Boring-Tasks.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md b/ru/3-Advanced/Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md
new file mode 100644
index 0000000..3bfa89c
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md
@@ -0,0 +1,7 @@
+# Как распределять скучные задания
+
+Иногда невозможно избежать скучных задач, которые критичны для успеха компании или проекта. Такие задания могут сильно подорвать дух тех, кому придется заниматься ими. Лучше всего постраться найти способ заставить компьютер выполнять эти задачи вместо ваших коллаг, либо помочь им. Работа с течение недели над программой, выполняющей задачу, которая вручную займет ту же неделю, имеет то огромное преимущество, что она учит большему и иногда более повторяема. 
+
+Если ничего из этого не сработает, извинитесь перед теми, кому придется делать скучные задачи, но ни при каких обстоятельствах не позволяйте выполнять эти задачи в одиночку. Как минимум назначьте двоих на эту работу и поощряйте командную работу в выполнении таких задач.
+
+Следующее: [Как получить поддержку для проекта](06-How-to-Gather-Support-for-a-Project.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md b/ru/3-Advanced/Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md
new file mode 100644
index 0000000..c283c90
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md
@@ -0,0 +1,5 @@
+# Как получить поддержку для проекта
+
+Чтобы получить поддержку для проекта, создайте и расскажите все представление, которое покажет его реальную ценность для организации в целом. Попытайтесь вовлечь других в создание вашего представления. Это даст им причину поддерживать вас, а вам - возможность использовать их идеи. Индивидуально привлекайте ключевых людей для поддержки вашего проекта. Всегда, когда возможно, показывайте, а не рассказывайте. Если это реально, постройте прототип или макет для демонстрации ваших идей. Прототип всегда мощное средство, особенно для программного обеспечения, где он превосходит любое письменное описание.
+
+Следующее: [Как развивать систему](07-How-to-Grow-a-System.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/07-How-to-Grow-a-System.md b/ru/3-Advanced/Serving-Your-Team/07-How-to-Grow-a-System.md
new file mode 100644
index 0000000..3f62d41
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/07-How-to-Grow-a-System.md
@@ -0,0 +1,23 @@
+# Как развивать систему
+
+Семя содержит в себе идею дерева, но не имеет форму и мощь взрослого растения. Семя вырастает в саженец. Он становится больше. Он все больше похож на взрослое дерево. Дерево начичает приносить плоды. Наконец, оно умирает и служит пищей для других организмов.
+
+У нас есть роскошь относиться к программному обеспечению похожим образом. Мост не похож на него. Не бывает мостов-детей, бывают недостроенные мосты. Они гораздо проще, чем программное обеспечение.
+
+Полезно думать о программном обеспечении как о чем-то растущем, это позволяет нам добиться существенного прогресса до того, как у нас сложится идеальный мысленный образ того, что мы делаем. Мы можем использовать обратную связь от пользователей, чтобы скорректировать развитие системы. Всегда полезно обрезать слабые и ненужные ветки.
+
+Программист должен разработать законченную системы, которую можно поставлять и использовать. Но продвинутый программист должен гораздо больше. Вы должны разработать путь развития, который завершится готовой системой. Ваша работа - взять зародыш идеи и построить путь, который как можно плавнее приведет к оплезному продукту.
+
+Чтобы сделать это, вы должны визуализировать конечный результат и представить его так, чтобы ваша инженерная коианда загорелась им. Но кроме этого вы должны рассказать им без больших скачков весь путь, который ведет от текущей точки проекта до конечной. Дерево должно жить все это время, нельзя позволить ему умереть, а затем возрождать его.
+
+Этот подход отражен в спиральной разработке. Этапы проекты никогда не находятся далеко друг от друга и отмечают прогресс по пути проекта. В сверхконкурентной среде бизнеса лучше всего, если после каждого этапа программное обеспечение можно выпустить и заработать на этом денег, даже если оно все еще далеко от финального состояния. Одна из задач программиста - сбалансировать немедленную отдачу от проекта с будущей, тщательно выбирая путь прогресса, отраженный в его этапах.
+
+Продвинутый программист несет тройную ответственность за развитие программного обеспечение, команд и отдельных людей.
+
+Один из читателей, Роб Хаферник, прислал комментарий к этой части, который я не могу не привести полностью:
+
+> Я думаю, что вы недооценили важность этого вопроса. Он касается не только системы, но и алгоритмов, пользовательских интерфейсов, моделей данных и так далее. При работе над большой системой жизненно важно иметь измеряемый прогресс в достижении промежуточных целей. Ничто не сравнится с ужасом, когда вы доходите до конца и обнаруживаете, что все это просто не работает (посмотрите на недавний провал системы оповещения избирателей). Я бы пошел дальше и сформулировал бы это как природный закон: нельзя с листа построить большую и сложную систему. Ее можно только развить из небольшой в сложную через серию последовательных шагов.
+
+На это можно только ответить "Именно так!"
+
+Следующее: [Как качественно взаимодействовать](08-How-to-Communicate-Well.md)
diff --git a/ru/3-Advanced/Serving-Your-Team/08-How-to-Communicate-Well.md b/ru/3-Advanced/Serving-Your-Team/08-How-to-Communicate-Well.md
new file mode 100644
index 0000000..0338ac9
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/08-How-to-Communicate-Well.md
@@ -0,0 +1,11 @@
+# Как качественно взаимодействовать
+
+Чтобы качественно взаимодействовать, вам стоит осознать, насколько это трудно. Это сам по себе отдельный навык. Он усложняется тем, что люди, с которыми вам приходится общаться, несовершенны. Они не будут прилагать усилий, чтобы понять вас. Они плохо выражают свои мысли и плохо пишут. Ои часто перегружены работой или им скучно, либо как минимум больше сосредоточены на своей части работы, чем на глобальных проблемах, которые вы, возможно, решаете. Одно из преимуществ частных занятий и практики письма, публичных выступлений и слушания состоит в том, что если вы станете лучше во всем этом, вы сможете быстрее увидеть, где лежит проблема взаимодействия и как ее исправить.
+
+Программист - это социальное существо, и его выживание зависит от коммуникации с командой. Продвинутый программист - это социальное существо, чье удовлетворение зависит от коммуникации с людьми за пределами команды.
+
+Программм=исты приносят порядок в хаос. Один из интересных способов делать это - внести какое-нибудь предложение за пределами вашей команды. Это можно сделать в виде черновика или устно. Такой подход имеет огромное преимущество в том, что устанавливает рамки обсуждения. Он также ставить вас в позицию критикуемого и может привести к отвержению и пренебрежению. Продвиутый программист должен быть готов принять все это, ведь у него есть уникальные возможности, а значит, и уникальная ответственность. Предприниматели, которые не являются программистами, нуждаются в том, чтобы программисты проявляли инициативу хоть в каком-то виде. Программисты - это та часть моста между идеями и действительностью, которая опирается на последнее.
+
+Я все еще не освоил до конца навык взаимодействия, но что я сейчас пытаюсь делать, можно выразить как четырехсторонний подход. После того, как я привожу свои идеи в порядок и полностью готов, я стараюсь собощить о них устно, вручаю людям черновой набросок (на бумаге или в электронном виде), показываю демо и затем терпеливо повторяю процесс. Я думаю, что часто мы недостаточно терпеливы для такого сложного общения. Не стоит расстраиваться, если ваши идеи не были сразу приняты. Если вы вложили много усилий в их подготовку, никто не будет думать о вас плохо из-за отказа. 
+
+Следующее: [Как сообщать неприятное](09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md)
diff --git a/ru/3-Advanced/Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md b/ru/3-Advanced/Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md
new file mode 100644
index 0000000..d3ade2e
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md
@@ -0,0 +1,9 @@
+# Как сообщать неприятное
+
+Часто вам придется говорить людям вещи, которые им не понравятся. Помните, что у вас есть на то причина. Даже если с проблемой ничего нельзя сделать, вы сообщаете о ней как можно раньше, чтобы все были информированы о ней.
+
+Лучший способ сообщить о проблеме - это тут же предложить способ ее решения. Второй хороший способ - это попросить о помощи в ее решении. Если есть вероятность, что вам не поверят, соберите доказательства своей правоты.
+
+Одна из самых неприятных и частых фраз, которую вам придется произносить, это "График придется сдвинуть". Сознательный программист терпеть не может произносить ее, но должен делать это как можно раньше. Нет ничего хуже, чем откладывать решение, когда срывается этап проекта. Даже если решение заключается в информировании о проблеме. Когда такое проиходит, лучше всего сказать это от лица команды. Вам понадобится мнение вашей команды о проблеме и том, как ее решить, и участие команды в последствиях проблемы вместе с вами.
+
+Следующее: [Как справляться с менеджерскими мифами](10-How-to-Deal-with-Managerial-Myths.md)
diff --git a/ru/3-Advanced/Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md b/ru/3-Advanced/Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md
new file mode 100644
index 0000000..4475362
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md
@@ -0,0 +1,13 @@
+# Как справляться с менеджерскими мифами
+
+Слово *миф* иногда означает вымысел. Но у него есть и более глубокий смысл. Оно также означает историю религиозного значения, которая объясняет вселенную и отношение человека к ней. Менеджеры склонны забывать, что они знали, когда были программистами, и верить в определенные мифы. Пытаться переубедить их, что эти мифы ложны, будет так же грубо и бессмысленно, как разубедить религиозного человека в его убеждениях. По этой причине вам следует различать как мифы следующие убеждения:
+
+- Больше документации всегда лучше. (Они хотят этого, но не хотят, чтобы вы тратили на это свое время)
+- Программистов можно сравнивать. (Программисты очень сильно отличаются друг от друга)
+- В проект можно добавить ресурсов, чтобы ускорить его. (Коммуникация с новыми людьми в проекте почти всегда ведет к увеличению проекта)
+- Разработку программного обеспечения можно надежно оценить по времени и затратам. (Это невозможно даже теоретически)
+- Производительность программистов можно измерить в рамках одной простой метрики, например, в строках кода. (Если качество в емкости, то избыточные строки кода это плохо, а не хорошо)
+
+Если у вас есть возможность, вы можете попытаться объяснить это, но не расстраивайтесь, если у вас не получится. Не портьте себе репутацию воинственным противостоянием этим мифам. Каждый из них поддерживает идею менеджера о том, что у них есть реальный контроль над тем, что происходит в проекте. Но правда в том, что менеджеры только упрощают процесс, если они хороши, и препятствуют, если нет.
+
+Следующее: [Как справляться с организационным хаосом](11-How-to-Deal-with-Organizational-Chaos.md)
\ No newline at end of file
diff --git a/ru/3-Advanced/Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md b/ru/3-Advanced/Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md
new file mode 100644
index 0000000..b914ddc
--- /dev/null
+++ b/ru/3-Advanced/Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md
@@ -0,0 +1,11 @@
+# Как справляться с организационным хаосом
+
+Иногда случаются короткие периоды времени, когда царит организционный хаос: такие как массовые увольнения, покупка компании другой, выход на биржу, массовый наем сотрудников и так далее. Такие времена неспокойны для всех, но возможно программистам здесь проще, так как их самооценка основана на чем-то большем, чем просто должность. Организационный хаос это прекрасная возможность для программистов проявить свою суперсилу. Я специально говорю об этом в самом конце эссе, потому что это тайна всех программистов. Если вы не программист, пожалуйста, прекратите чтение прямо сейчас.
+
+> Программисты могут создавать и поддерживать продукт.
+
+Неинженеры могут руководить людьми, но в типичной компании по разработке программного обеспечения они не могут ничего создать или поддерживать без инженеров. Точно так же типичные инженеры не смогут продать продукт или эффективно вести бизнес. Эта суперспособность защищает почти от всех проблем, связанных с временным организационным хаосом. Пока она с вами, вам следует игнорировать полностью хаос и продолжать делать свою работы, как будто ничего не происходит. Вас, конечно, могут уволить, но если это случится, то скорее всего вы найдете новую работу благодаря своей суперспособности. Но чаще всего кто-нибудь измученный стрессом придет к вам и прикажет делать что-нибудь глупое. Если вы совершенно уверены, что это глупо, то лучше всего улыбаться и кивать, пока этот человек не уйдет. А затем продолжать делать то, что вы считаете правильным для компании.
+
+Если вы лидер, скажите своей команде делать то же самое и игнорировать все, что ей будут говорить остальные. Такое поведение наиболее выгодно для вас лично и для всей компании или проекта.
+
+Следующее: [Глоссарий](../../GLOSSARY.md)
diff --git a/ru/3-Advanced/Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md b/ru/3-Advanced/Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md
new file mode 100644
index 0000000..21006f2
--- /dev/null
+++ b/ru/3-Advanced/Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md
@@ -0,0 +1,9 @@
+# Как отличить сложное от невозможного
+[//]: # (Version:1.0.1)
+Ваша работа заключается в том, чтобы делать сложное и отличать невозможное. С точки зрения большиства программистов невозможное это то, что невозможно получить с помощью одной системы или то, что невозможно оценить. По этому определению научное исследование невозможно выполнить. Большой объем работы это сложно, не необязательно невозможно.
+
+Это нешуточное различие, потому что часто вас будут просить сделать то, что невозможно практически, будь то с научной точки зрения или с точки зрения разработки программного обеспечения. Тогда ваша задача помочь найти разумное решение, которое будет просто сложным и позволит реализовать большую часть запросов. Решение является сложным, если его можно с уверенностью распланировать, и понятны связанные с ним риски.
+
+Невозможно выполнить туманные требования вроде "Построить систему, которая будет вычислять самую привлекательную прическу и цвет волос для каждого клиента". Если требование можно сделать более четким, оно зачастую станет сложнее, например, "Построить систему, которая будет вычислять самую привлекательную прическу и цвет для клиента, позволять им предварительно просматривать решение, изменять его и настолько хорошо удовлетворять клиента, что мы будет получать от этого кучу денег". Если нет четкого определения успеха, то вы не добьетесь его.
+
+Следующее: [Как использовать встроенные языки](02-How-to-Utilize-Embedded-Languages.md)
diff --git a/ru/3-Advanced/Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md b/ru/3-Advanced/Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md
new file mode 100644
index 0000000..b8db6aa
--- /dev/null
+++ b/ru/3-Advanced/Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md
@@ -0,0 +1,11 @@
+# Как использовать встроенные языки
+
+Встраивание языка программирования в систему обладает почти эротическим притяжением для программиста. Это самое творческое, что можно сделать. Это делает системы невероятно мощной и позволит вам использовать ее самые творческие возможности. Это сделает систему вашим другом.
+
+У лучших тестовых редакторов есть встроенные языки программирования. Это можно использовать в той мере, в какой целевая аудитория может овладеть этими языками. Конечно, можно сделать использование встроенного языка необязательным, как это делается в текстовых редакторах, так что ими пользуются опытные пользователи, а остальным они и не нужны.
+
+И я, и множество других программистов попадали в ловушку создания встроенных языков со специальным назначением. Я попадался на это дважды. В мире уже существует множество языков, которые спроетированы для того, чтобы их встраивать в системы. Подумайте дважды, прежде чем создавать еще один.
+
+Вопрос, который стоит задать себе перед встраиванием языка, звучит так: входит ли использование таких языков в культуру моих пользователей или нет? Если ваша целевая аудитория состоит исключительно из непрограммистов, то насколько поможет внедрение языка в систему? Если целевая аудитория состоит из программистов, то не предпочтут ли они четкое API? И какой язык вы собираетесь встраивать? Программисты не очень любят изучать новый язык, если он применяется узко. Но если он похож на то, с чем они уже работают, то они быстро освоят его. Создавать новый язык это огромное удовольствие и радость. Но мы не должны позволять этой радости ослеплять нас и затмевать потребности пользователя. Если только у вас не по-настоящему оригинальные запросы и идеи, то почему бы не использовать уже существующий язык, с которым знакома некоторая часть ваших пользователей?
+
+Следующее: [Выбор языка программирования](03-Choosing-Languages.md)
diff --git a/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md b/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md
new file mode 100644
index 0000000..87cda5a
--- /dev/null
+++ b/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md
@@ -0,0 +1,15 @@
+# Выбор языка программирования
+
+Программист-одиночка, который любит свою работу, может позволить себе выбирать язык, лучше всего подходящий для задачи. Но у большинства работающих программистов небольшой выбор над языком, с которым они работают. Обычно, за них это решают руководители, которые больше принимают политическое, а не технологическое решение. Часто руководителям не хватает смелости использовать нетрадиционный инструмент, даже если они знают, иногда по собственному опыту, что менее распространенный инструмент лучше. В других случаях преимущество того, что большая часть команды и иногда более широкого общества владеет инструментом, исключает его выбор со стороны отдельного программиста. Часто менеджеры руководствуются необходимостью нанимать программистов с опытом с определенным языком. Вне сомнений они делают то, что считают лучшим для компании или проекта, и их стоит уважать за это. Однако, я лично считает этот подход одним из самых бесполезных и ошибочных, которые можно только встретить.
+
+Но конечно, все не так однозначно. Даже если основной язык обязателен, и вы не можете изменить его, часто случается, что некоторые инструменты или сторонние программы можно и нужно написать на других языках. Если язык должен быть встроен в систему (и вам всегда следует рассмотреть такую возможность), то его выбор во многом будет зависеть от пользователей системы. Из таких случаев следует извлекать преимущество и выбирать лучший язык для компании или проекта. Заодно это делает работу намного интереснее.
+
+Языки программирования в действительности стоит называть нотациями, поскольку выучить один из них не так трудно, как естественный язык. Для начинающих или непосвященных "выучить новый язык программирования" кажется сложной задачей, но после трех языков это всего лишь вопрос знакомства с доступными библиотеками. Нкоторые склонны думать о большой системе, в которой компоненты написаны на трех-четырех языках, как о беспорядочной солянке, но я утверждаю, что такая система во сногих случаях превосходит систему, написанную на одном языке:
+
+- Между компонентами, написанными на разных нотациях, нет тесной связи, они лучше изолированы друг от друга (хотя они могут иметь не совсем понятные интерфейсы)
+- Вы можете легко внедрить новый язык или платформу, переписав индивидуально каждый компонент
+- Один язык может не подходить для всех задач системы. Имея несколько языков для компонентов, вы можете выбирать наиболее подходящий для конкретной задачи
+
+Некоторые из этих преимуществ чисто психологические, но психология тоже важна. В конце концов, издержки языковой тирании перевешивают любые преимущества, которые она дает.
+
+Следующее: [Нахождение компромиссов. Как справляться в давлением графика](../Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
diff --git a/ru/5-Bibliography.md b/ru/5-Bibliography.md
new file mode 100644
index 0000000..5736f6e
--- /dev/null
+++ b/ru/5-Bibliography.md
@@ -0,0 +1,31 @@
+# Приложение A - Библиография/Список сайтов
+[//]: # (Version:1.0.0)
+## Книги
+
+[Rules00] Guy Kawasaki, Michelle Moreno, and Gary Kawasaki. 2000. HarperBusiness. Rules for Revolutionaries: The Capitalist Manifesto for Creating and Marketing New Products and Services.
+
+[RDev96] Steve McConnell. 1996. Microsoft Press. Redmond, Wash. Rapid Development: Taming Wild Software Schedules.
+
+[CodeC93] Steve McConnell. 1993. Microsoft Press. Redmond, Wash. Code Complete.
+
+[XP99] Kent Beck. 1999. 0201616416. Addison-Wesley. Extreme Programming Explained: Embrace Change.
+
+[PlanXP00] Kent Beck and Martin Fowler. 2000. 0201710919. Addison-Wesley. Planning Extreme Programming.
+
+[Prag99] Andrew Hunt, David Thomas, and Ward Cunningham. 1999. 020161622X. Addison-Wesley. The Pragmatic Programmer: From Journeyman to Master.
+
+[Stronger] Friedrich Nietzsche. 1889. Twilight of the Idols, "Maxims and Arrows", section 8..
+
+## Сайты
+
+[PGSite] Paul Graham. 2002. Articles on his website: [http://www.paulgraham.com/articles.html](http://www.paulgraham.com/articles.html). All of them, but especially "Beating the Averages".
+
+[Hacker] Eric S. Raymond. 2003. How to Become a Hacker. [http://www.catb.org/~esr/faqs/hacker-howto.html](http://www.catb.org/~esr/faqs/hacker-howto.html).
+
+[HackDict] Eric S. Raymond. 2003. The New Hacker Dictionary. [http://catb.org/esr/jargon/jargon.html](http://catb.org/esr/jargon/jargon.html).
+
+[ExpCS] Edsger W. Dijkstra. 1986. How Experimental is Computing Science?. [http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD988a.PDF](http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD988a.PDF).
+
+[Knife] Edsger W. Dijkstra. 1984. On a Cultural Gap. [http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD913.PDF](http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD913.PDF).
+
+Следующее: [История](6-History.md)
\ No newline at end of file
diff --git a/ru/6-History.md b/ru/6-History.md
new file mode 100644
index 0000000..c99fa25
--- /dev/null
+++ b/ru/6-History.md
@@ -0,0 +1,47 @@
+# Приложение B - История
+[//]: # (Version:1.0.0)
+## Move to Github
+
+This essay has been created as a repository on Github so that it can be easily shared, updated and improved. It was copied from [http://samizdat.mines.edu/howto/HowToBeAProgrammer.htm](http://samizdat.mines.edu/howto/HowToBeAProgrammer.htm) by [Braydie Grove](https://github.com/braydie). It was moved to Github in January 2016.
+
+## Request for Feedback or Extension
+
+Please send me any comments you may have on this essay. I consider all suggestions, many of which have already improved this essay.
+
+I have placed this essay under the GNU Free Documentation License. This license is not specifically designed for essays. Essays are usually intended to be coherent and convincing arguments that are written from a single point of view in a single voice. I hope this essay is a short and pleasant read.
+
+I also hope that it is instructive. Although not a textbook, it is broken into many small sections to which new sections can be freely added. If so inclined, you are encouraged to expand upon this essay as you see fit, subject to the provisions of the License.
+
+It may be arrogance to imagine that this document is worthy of extension; but hope springs eternal. I would be joyous if it were extended in the following ways:
+
+The addition of a comprehensive reading list to each section,
+
+The addition of more and better sections,
+
+Translation into other languages, even if only on a subsection-by-subsection basis, and/or
+
+Criticism or commentary in-lined into the text.
+
+The ability to build into different formats, such as palm formats and better HTML.
+
+If you inform me of your work, I will consider it and may include it in subsequent versions that I produce, subject to the provisions of the License. You may of course produce your own versions of this document without my knowledge, as explained in the License.
+
+Thank you.
+
+Robert L. Read
+
+## Original Version
+
+The original version of this document was begun by Robert L. Read in the year 2000 and first published electronically at Samizdat Press(http://Samizdat.mines.edu) in 2002. It is dedicated to the programmers of Hire.com.
+
+After this article was mentioned on Slashdot in 2003, about 75 people sent me email with suggestions and errata. I appreciate them all. There was a lot of duplication, but the following people either made major suggestions or were the first to find a bug that I fixed: Morgan McGuire, David Mason, Tom Moertel, Ninja Programmer (145252) at Slashdot, Ben Vierck, Rob Hafernik, Mark Howe, Pieter Pareit, Brian Grayson, Zed A. Shaw, Steve Benz, Maksim Ioffe, Andrew Wu, David Jeschke, and Tom Corcoran.
+
+Finally I would like to thank Christina Vallery, whose editing and proofreading greatly improved the second draft, and Wayne Allen, who encouraged me to initiate this.
+
+## Original Author's Bio
+
+Robert L. Read lives in Austin, Texas, with his wife and two children. He is currently a Principal Engineer at Hire.com, where he has worked for four years. Prior to that he founded 4R Technology, which made a scanner-based image analysis quality control tool for the paper industry.
+
+Rob received a PhD from the University of Texas at Austin in 1995 in Computer Science related to database theory. In 1987 he received a BA in Computer Science from Rice University. He has been a paid programmer since the age of 16.
+
+Next [License](LICENSE.md)
diff --git a/ru/7-Contributions.md b/ru/7-Contributions.md
new file mode 100644
index 0000000..d40ba50
--- /dev/null
+++ b/ru/7-Contributions.md
@@ -0,0 +1,31 @@
+# Участеи в проекте
+[//]: # (Version:1.0.0)
+This repository aims to be a community driven project, and your involvement will ultimately help improve the quality of this guide. 
+
+## What can I do to contribute?
+There are a number of ways to contribute to "How to be a Programmer".
+
+- Ideas for new sections
+- Improvements to existing sections
+- Identifying typos or other issues in sections
+- Contributing additional links to resources for sections
+- General suggestions for improving the project
+- Provide translations of the guide
+
+## Translations
+
+Currently this guide has been translated from English into the following languages:
+
+- Chinese by [ahangchen](https://github.com/ahangchen)
+
+**If you provide the initial translation of the guide into another language, you become legible to become a contributor on this project to help maintain and review changes made to the translation.**
+
+## Contributors
+
+Github holds a list of all [contributors](https://github.com/braydie/HowToBeAProgrammer/graphs/contributors) to this project.
+
+## Editorship and Move to GitHub
+
+[Braydie Grove](https://www.github.com/braydie) has agreed to serve as editor-in-chief.
+
+Braydie transposed the original essay into MarkDown and created the repository.
diff --git a/ru/GLOSSARY.md b/ru/GLOSSARY.md
new file mode 100644
index 0000000..0b1833e
--- /dev/null
+++ b/ru/GLOSSARY.md
@@ -0,0 +1,131 @@
+# Глоссарий
+[//]: # (Version:1.0.0)
+В данном глоссарии собраны термирны, использующиеся в эссе. Термины необязательно имеют стандартное для большинства людей значение. Eric S. Raymond собрал массивный и информативный глоссарий[HackerDict], оценив малую часть которого, можно с удовольствием прочесть от корки до корки, как бы это странно ни звучало.
+
+### unk-unk
+
+Жаргон для "неизвестное-неизвестное". Это проблемы, которые в настоящее время невозможно представить даже концептуально, и которые будут отнимать время, заложенное на проект, и сбивать график.
+
+### printlining
+
+Вставка в программу временных команд, которые выводят информацию о ее выполнении для последующей отладки.
+
+### Логирование
+
+Практика писать программу таким образом, чтобы она могла выводить настраиваемый отчет, описывающий ход ее исполнения.
+
+### divide and conquer
+
+Техника проектирования и отладки по принципу "сверху-вниз". Заключается в разделении большой проблемы или задачи на составные проблемы или задачи меньшего размера. 
+
+### vapour
+
+Воображаемые и часто обманчивые обещания насчет программного обеспечения, которое еще не готово для выпуска, и которое зачастую никогда не преобразуется в нечто работающее.
+
+### Босс
+
+Человек, который назначает вам задачи. В некоторых случаях, это сам пользователь.
+
+### tribe
+
+Люди, которые разделяют с вами верность некой общей цели.
+
+### low-hanging fruit
+
+Существенные улучшения, которые требуют мало затрат.
+
+### Entrepreneur
+
+Инициатор проектов.
+
+### business
+
+Группа людей, организованных для получения прибыли.
+
+### company
+
+Группа людей, организованных для получения прибыли.
+
+### scroll blindness
+
+Невозможность найти нужную информацию из-за того, что она спрятана в большом количестве другой, менее интересной, информации.
+
+### wall-clock
+
+Фактическое время, измеряемое настенными часами, противоположность процессорного времени.
+
+### Узкое место
+
+Главное ограничение в производительности системы. Ограничение, которые снижает производительность.
+
+### master
+
+Уникальный фрагмент информация, от которого происходят все кэшированные копии. Служит официальным определением данных.
+
+### Выделенная куча
+
+Память можно назвать "выделенной в куче", когда механизм по ее освобождению можно назвать сложным.
+
+### Мусор
+
+Память, которую занимают ненужные более для приложения объекты.
+
+### Сборщик мусора
+
+Система для обработки мусора.
+
+### Утечка памяти
+
+Набор нежелаемых ссылок на объекты, которые мешают сборке мусора. Либо ошибка в сборщике мусоре или системе управления памяти. Приводит к постепенному увеличению памяти, которую запрашивает программа с течением времени.
+
+### Экстремальное программирование
+
+Стиль разработки, которые акцентируется на общении с клиентами и автоматизированным тестированием.
+
+### hitting the wall
+
+Исчерпать некий ресурс и тем самым резко снизить производительность программы в противоположность постепенному снижению.
+
+### speculative programming
+
+Создание функции до того, как точно определено, будет ли она полезна.
+
+### information hiding
+
+Принцип проектирования, которые стремится изолировать друг от друга компоненты через внешние интерфейсы, предоставляющие необходимый минимум информации.
+
+### Объектно-ориентированное программирование
+
+Стиль программирования, акцентирующийся на управлении внутренним состоянием объектов.
+
+### communication languages
+
+Язык, спроектированный в первую очередь для стандартизации, чем для непосредственного использования.
+
+### boxes and arrows
+
+Свободный, неформальный стиль построения диаграмм из ячеек и стрелок, отображающих отношения. Противопоставляется формальным методологиям диаграмм, таким как UML.
+
+### lingua franca
+
+Популярный в своей области язык, ставший де-факто стандартом. Например, как французский был в одно время для международной дипломатии.
+
+### buy vs. build
+
+Выбор между покупкой программного обеспечения и самостоятельной разработкой.
+
+### mere work
+
+Работа, которая требует мало творчества и подразумевает малый риск. Можно легко оценить с точки зрения временных затрат.
+
+### programming notation
+
+Синоним для термина "языка программирования", который почеркивает математическую природу языков программирования и их простоту относительно естественных языков.
+
+### strawman
+
+Документ, который является стартовой точкой технической дискуссиии. Может вести к последующим версиям документации.
+
+### white-paper
+
+Информативный документ, который часто предназначен объяснить или продать продукт или идею аудитории, которая отличается от разработчиков данного продукта или идеи.
diff --git a/ru/LICENSE.md b/ru/LICENSE.md
new file mode 100644
index 0000000..3e18a1a
--- /dev/null
+++ b/ru/LICENSE.md
@@ -0,0 +1,12 @@
+
+## Creative Commons Attribution Share-Alike 
+
+"How To Be A Programmer: Community Version" by Robert L. Read with Community is licensed under Creative Commons Attribution Share-Alike Internal v 4.0.
+
+At present this work will be edited by Braydie Grove and Robert L. Read.
+
+We will make reasonable attempts to maintain proper attributions of contributions in the section entittle "Contributions". If you make a pull-request with a significant contribution, please add a very brief description of your contribution to that section.
+
+
+
+<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">How To Be A Programmer: Community Version</span> by <span xmlns:cc="http://creativecommons.org/ns#" property="cc:attributionName">Robert L. Read with Community</span> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
diff --git a/ru/README.md b/ru/README.md
new file mode 100644
index 0000000..4a94ad6
--- /dev/null
+++ b/ru/README.md
@@ -0,0 +1,103 @@
+# How to be a Programmer: Community Version
+[//]: # (Version:1.0.0)
+Robert L. Read with Community
+
+Copyright 2002, 2003, 2016 Robert L. Read
+
+Licensed under [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/).
+
+## Введение
+Быть хорошим программистом трудно и благородно. Самое сложное в коллективной разработке программного обеспечения это взаимодействие с коллегами и клиентами. Писать компьютерные программы важно и требует многих знаний и навыков, но это лишь детский лепет по сравнению с тем прочим, что хороший программист должен делать, чтобы создать программное обеспечение, успешное и для клиентов, и для множества коллег, за которых он несет частичную ответственность. В данном эссе я попытаюсь как можно более кратко изложить все те нюансы и детали, которые я сам бы хотел, чтобы кто-нибудь мне объяснил, когда мне был двадцать один год.
+
+Это очень субъективная тема, поэтому данное эссе неизбежно будет отражением моих персональных взглядов и убеждений. Я ограничу себя проблемами, с которыми, скорее всего, столкнется почти каждый программист во время работы. Многие из них, а также их решения являются настолько общечеловеческими, что вероятно, мой тон покажется назидательным. Несмотря на это, я надеюсь, что эссе окажется полезным.
+
+Программирование преподается на курсах. Великолепные книги The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96] и Extreme Programming Explained [XP99]: все обучают программированию и более общим вопросам о том, как быть хорошим программистом. До или вместе с данной статьей непременно стоит ознакомиться также с эссе Paul Graham [PGSite] и Eric Raymond [Hacker]. Данное эссе слегка отличается от этих великолепных работ тем, что акцентирует внимание на социальных проблемах и обобщает набор необходимых программисту навыков так с моей личной точки зрения.
+
+В данном эссе я называю "боссом" любого, кто ставит перед вами задачи. Слова "бизнес", "компания" и "племя" я использую как синонимы, кроме тех случаев, когда "бизнес" означает генерирование прибыли, "компания" - место работы, а "клан" - людей, с которыми вы разделяете преданность.
+
+Добро пожаловать в клан.
+
+## Содержание
+
+1. [Начинающий разработчик](1-Beginner)
+	- Личные навыки
+		- [Научитесь отлаживать](1-Beginner/Personal-Skills/01-Learn-To-Debug.md)
+		- [Как отлаживать, разделяя пространство проблемы](1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md)
+		- [Как устранять ошибки](1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md)
+		- [Как отлаживать, используя логи](1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md)
+		- [Как определять проблемы производительности](1-Beginner/Personal-Skills/05-How-to-Understand-Performance-Problems.md)
+		- [Как устранять проблемы производительности](1-Beginner/Personal-Skills/06-How-to-Fix-Performance-Problems.md)
+		- [Как оптимизировать циклы](1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md)
+		- [Как справиться с расходами на операции чтения и записи](1-Beginner/Personal-Skills/08-How-to-Deal-with-IO-Expense.md)
+		- [Как управлять памятью](1-Beginner/Personal-Skills/09-How-to-Manage-Memory.md)
+		- [Как устранять плавающие баги](1-Beginner/Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md)
+		- [Как научиться проектировать программы](1-Beginner/Personal-Skills/11-How-to-Learn-Design-Skills.md)
+		- [Как экспериментировать](1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md)
+	- Командные навыки
+		- [Почему важно оценивать задачи](1-Beginner/Team-Skills/01-Why-Estimation-is-Important.md)
+		- [Как оценивать время на разработку](1-Beginner/Team-Skills/02-How-to-Estimate-Programming-Time.md)
+		- [Как искать информацию](1-Beginner/Team-Skills/03-How-to-Find-Out-Information.md)
+		- [Как спрашивать людей](1-Beginner/Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md)
+		- [Как документировать правильно](1-Beginner/Team-Skills/05-How-to-Document-Wisely.md)
+		- [Как работать с плохим кодом](1-Beginner/Team-Skills/06-How-to-Work-with-Poor-Code.md)
+		- [Как использовать системы контроля версий](1-Beginner/Team-Skills/07-How-to-Use-Source-Code-Control.md)
+		- [Как писать юнит-тесты](1-Beginner/Team-Skills/08-How-to-Unit-Test.md)
+		- [Делайте перерывы, когда вы в тупике](1-Beginner/Team-Skills/09-Take-Breaks-when-Stumped.md)
+		- [Как понять, когда идти домой](1-Beginner/Team-Skills/10-How-to-Recognize-When-to-Go-Home.md)
+		- [Как вести себя с трудными людьми](1-Beginner/Team-Skills/11-How-to-Deal-with-Difficult-People.md)
+2. [Разработчик среднего уровня](2-Intermediate)
+	- Личные навыки
+		- [Как сохранять мотивацию](2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md)
+		- [Как заслужить доверие](2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md)
+		- [Как балансировать процессорное время и память](2-Intermediate/Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md)
+		- [Как проводить стресс-тестирование](2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md)
+		- [Как балансировать краткость и абстракцию](2-Intermediate/Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md)
+		- [Как осваивать новые навыки](2-Intermediate/Personal-Skills/06-How-to-Learn-New-Skills.md)
+		- [Научитесь печатать вслепую](2-Intermediate/Personal-Skills/07-Learn-to-Type.md)
+		- [Как выполнять интеграционное тестирование](2-Intermediate/Personal-Skills/08-How-to-Do-Integration-Testing.md)
+		- [Языки взаимодействия систем](2-Intermediate/Personal-Skills/09-Communication-Languages.md)
+		- [Стандартные технологии](2-Intermediate/Personal-Skills/10-Heavy-Tools.md)
+		- [Как анализировать данные](2-Intermediate/Personal-Skills/11-How-to-analyze-data.md)
+	- Командные навыки
+		- [Как управлять временем разработки](2-Intermediate/Team-Skills/01-How-to-Manage-Development-Time.md)
+		- [Как управлять рисками, связанными со сторонним программным обеспечением](2-Intermediate/Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md)
+		- [Как руководить консультантами](2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md)
+		- [Как соизмерять количество общения](2-Intermediate/Team-Skills/04-How-to-Communicate-the-Right-Amount.md)
+		- [Как честно выражать несогласие](2-Intermediate/Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md)
+	- Экспертиза
+		- [Как балансировать качество и время разработки](2-Intermediate/Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md)
+		- [Как управлять зависимостями](2-Intermediate/Judgment/02-How-to-Manage-Software-System-Dependence.md)
+		- [Как оценивать стороннее программное обеспечение](2-Intermediate/Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md)
+		- [Как решать: покупать программу или писать свою](2-Intermediate/Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md)
+		- [Как расти профессионально](2-Intermediate/Judgment/05-How-to-Grow-Professionally.md)
+		- [Как проводить собеседования](2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md)
+		- [Как понять, когда применять высокие технологии](2-Intermediate/Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md)
+		- [Как разговаривать с неинженерами](2-Intermediate/Judgment/08-How-to-Talk-to-Non-Engineers.md)
+3. [Продвинутый разработчик](3-Advanced)
+	- Технологическая экспертиза
+		- [Как отличить сложное от невозможного](3-Advanced/Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md)
+		- [Как использовать встроенные языки](3-Advanced/Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md)
+		- [Выбор языка программирования](3-Advanced/Technical-Judgment/03-Choosing-Languages.md)
+	- Правильные компромиссы
+		- [Как справляться с давлением графика](3-Advanced/Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
+		- [Как понять пользователя](3-Advanced/Compromising-Wisely/02-How-to-Understand-the-User.md)
+		- [Как получить повышение](3-Advanced/Compromising-Wisely/03-How-to-Get-a-Promotion.md)
+	- Управление командой
+		- [Как развивать таланты](3-Advanced/Serving-Your-Team/01-How-to-Develop-Talent.md)
+		- [Как выбрать, над чем работать](3-Advanced/Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md)
+		- [Как получить наибольшую отдачу от коллег](3-Advanced/Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md)
+		- [Как разделять задачи](3-Advanced/Serving-Your-Team/04-How-to-Divide-Problems-Up.md)
+		- [Как распределять скучные задания](3-Advanced/Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md)
+		- [Как получить поддержку для проекта](3-Advanced/Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md)
+		- [Как развивать систему](3-Advanced/Serving-Your-Team/07-How-to-Grow-a-System.md)
+		- [Как качественно взаимодействовать](3-Advanced/Serving-Your-Team/08-How-to-Communicate-Well.md)
+		- [Как сообщать неприятное](3-Advanced/Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md)
+		- [Как справляться с менеджерскими мифами](3-Advanced/Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md)
+		- [Как справляться с организационным хаосом](3-Advanced/Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md)
+4. [Глоссарий](GLOSSARY.md)
+5. [Приложение A - Библиография/Список сайтов](5-Bibliography.md)
+6. [Приложение B - История (на январь 2016)](6-History.md)
+6. [Приложение C - Участие в проекте (на январь 2016)](7-Contributions.md)
+
+
+<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">How To Be A Programmer: Community Version</span> by <span xmlns:cc="http://creativecommons.org/ns#" property="cc:attributionName">Robert L. Read with Community</span> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
diff --git a/ru/SUMMARY.md b/ru/SUMMARY.md
new file mode 100644
index 0000000..e442482
--- /dev/null
+++ b/ru/SUMMARY.md
@@ -0,0 +1,80 @@
+# Summary
+[//]: # (Version:1.0.0)
+* [Beginner](1-Beginner/README.md)
+	* Personal Skills
+		* [Learn to Debug](1-Beginner/Personal-Skills/01-Learn-To-Debug.md)
+		* [How to Debug by Splitting the Problem Space](1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md)
+		* [How to Remove an Error](1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md)
+		* [How to Debug Using a Log](1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md)
+		* [How to Understand Performance Problems](1-Beginner/Personal-Skills/05-How-to-Understand-Performance-Problems.md)
+		* [How to Fix Performance Problems](1-Beginner/Personal-Skills/06-How-to-Fix-Performance-Problems.md)
+		* [How to Optimize Loops](1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md)
+		* [How to Deal with I/O Expense](1-Beginner/Personal-Skills/08-How-to-Deal-with-IO-Expense.md)
+		* [How to Manage Memory](1-Beginner/Personal-Skills/09-How-to-Manage-Memory.md)
+		* [How to Deal with Intermittent Bugs](1-Beginner/Personal-Skills/10-How-to-Deal-with-Intermittent-Bugs.md)
+		* [How to Learn Design Skills](1-Beginner/Personal-Skills/11-How-to-Learn-Design-Skills.md)
+		* [How to Conduct Experiments](1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md)
+	* Team Skills
+		* [Why Estimation is Important](1-Beginner/Team-Skills/01-Why-Estimation-is-Important.md)
+		* [How to Estimate Programming Time](1-Beginner/Team-Skills/02-How-to-Estimate-Programming-Time.md)
+		* [How to Find Out Information](1-Beginner/Team-Skills/03-How-to-Find-Out-Information.md)
+		* [How to Utilize People as Information Sources](1-Beginner/Team-Skills/04-How-to-Utilize-People-as-Information-Sources.md)
+		* [How to Document Wisely](1-Beginner/Team-Skills/05-How-to-Document-Wisely.md)
+		* [How to Work with Poor Code](1-Beginner/Team-Skills/06-How-to-Work-with-Poor-Code.md)
+		* [How to Use Source Code Control](1-Beginner/Team-Skills/07-How-to-Use-Source-Code-Control.md)
+		* [How to Unit Test](1-Beginner/Team-Skills/08-How-to-Unit-Test.md)
+		* [Take Breaks when Stumped](1-Beginner/Team-Skills/09-Take-Breaks-when-Stumped.md)
+		* [How to Recognize When to Go Home](1-Beginner/Team-Skills/10-How-to-Recognize-When-to-Go-Home.md)
+		* [How to Deal with Difficult People](1-Beginner/Team-Skills/11-How-to-Deal-with-Difficult-People.md)
+* [Intermediate](2-Intermediate/README.md)
+	* Personal Skills
+		* [How to Stay Motivated](2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md)
+		* [How to be Widely Trusted](2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md)
+		* [How to Tradeoff Time vs. Space](2-Intermediate/Personal-Skills/03-How-to-Tradeoff-Time-vs-Space.md)
+		* [How to Stress Test](2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md)
+		* [How to Balance Brevity and Abstraction](2-Intermediate/Personal-Skills/05-How-to-Balance-Brevity-and-Abstraction.md)
+		* [How to Learn New Skills](2-Intermediate/Personal-Skills/06-How-to-Learn-New-Skills.md)
+		* [Learn to Type](2-Intermediate/Personal-Skills/07-Learn-to-Type.md)
+		* [How to Do Integration Testing](2-Intermediate/Personal-Skills/08-How-to-Do-Integration-Testing.md)
+		* [Communication Languages](2-Intermediate/Personal-Skills/09-Communication-Languages.md)
+		* [Heavy Tools](2-Intermediate/Personal-Skills/10-Heavy-Tools.md)
+		* [How to analyze data](2-Intermediate/Personal-Skills/11-How-to-analyze-data.md)
+	* Team Skills
+		* [How to Manage Development Time](2-Intermediate/Team-Skills/01-How-to-Manage-Development-Time.md)
+		* [How to Manage Third-Party Software Risks](2-Intermediate/Team-Skills/02-How-to-Manage-Third-Party-Software-Risks.md)
+		* [How to Manage Consultants](2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md)
+		* [How to Communicate the Right Amount](2-Intermediate/Team-Skills/04-How-to-Communicate-the-Right-Amount.md)
+		* [How to Disagree Honestly and Get Away with It](2-Intermediate/Team-Skills/05-How-to-Disagree-Honestly-and-Get-Away-with-It.md)
+	* Judgment
+		* [How to Tradeoff Quality Against Development Time](2-Intermediate/Judgment/01-How-to-Tradeoff-Quality-Against-Development-Time.md)
+		* [How to Manage Software System Dependence](2-Intermediate/Judgment/02-How-to-Manage-Software-System-Dependence.md)
+		* [How to Decide if Software is Too Immature](2-Intermediate/Judgment/03-How-to-Decide-if-Software-is-Too-Immature.md)
+		* [How to Make a Buy vs. Build Decision](2-Intermediate/Judgment/04-How-to-Make-a-Buy-vs-Build-Decision.md)
+		* [How to Grow Professionally](2-Intermediate/Judgment/05-How-to-Grow-Professionally.md)
+		* [How to Evaluate Interviewees](2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md)
+		* [How to Know When to Apply Fancy Computer Science](2-Intermediate/Judgment/07-How-to-Know-When-to-Apply-Fancy-Computer-Science.md)
+		* [How to Talk to Non-Engineers](2-Intermediate/Judgment/08-How-to-Talk-to-Non-Engineers.md)
+* [Advanced](3-Advanced/README.md)
+	* Technological Judgment
+		* [How to Tell the Hard From the Impossible](3-Advanced/Technical-Judgment/01-How-to-Tell-the-Hard-From-the-Impossible.md)
+		* [How to Utilize Embedded Languages](3-Advanced/Technical-Judgment/02-How-to-Utilize-Embedded-Languages.md)
+		* [Choosing Languages](3-Advanced/Technical-Judgment/03-Choosing-Languages.md)
+	* Compromising Wisely
+		* [How to Fight Schedule Pressure](3-Advanced/Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
+		* [How to Understand the User](3-Advanced/Compromising-Wisely/02-How-to-Understand-the-User.md)
+		* [How to Get a Promotion](3-Advanced/Compromising-Wisely/03-How-to-Get-a-Promotion.md)
+	* Serving Your Team
+		* [How to Develop Talent](3-Advanced/Serving-Your-Team/01-How-to-Develop-Talent.md)
+		* [How to Choose What to Work On](3-Advanced/Serving-Your-Team/02-How-to-Choose-What-to-Work-On.md)
+		* [How to Get the Most From Your Team-mates](3-Advanced/Serving-Your-Team/03-How-to-Get-the-Most-From-Your-Teammates.md)
+		* [How to Divide Problems Up](3-Advanced/Serving-Your-Team/04-How-to-Divide-Problems-Up.md)
+		* [How to Handle Boring Tasks](3-Advanced/Serving-Your-Team/05-How-to-Handle-Boring-Tasks.md)
+		* [How to Gather Support for a Project](3-Advanced/Serving-Your-Team/06-How-to-Gather-Support-for-a-Project.md)
+		* [How to Grow a System](3-Advanced/Serving-Your-Team/07-How-to-Grow-a-System.md)
+		* [How to Communicate Well](3-Advanced/Serving-Your-Team/08-How-to-Communicate-Well.md)
+		* [How to Tell People Things They Don't Want to Hear](3-Advanced/Serving-Your-Team/09-How-to-Tell-People-Things-They-Dont-Want-to-Hear.md)
+		* [How to Deal with Managerial Myths](3-Advanced/Serving-Your-Team/10-How-to-Deal-with-Managerial-Myths.md)
+		* [How to Deal with Organizational Chaos](3-Advanced/Serving-Your-Team/11-How-to-Deal-with-Organizational-Chaos.md)
+* [Appendix A * Bibliography/Websiteography](5-Bibliography.md)
+* [Appendix B * History (As of January 2016)](6-History.md)
+* [Appendix C * Contributions (As of January 2016)](7-Contributions.md)