From b8b947ea72132410283f07076364f83c6c900447 Mon Sep 17 00:00:00 2001
From: Pavel Tovchigrechko
 <99090300+paveltovchigrechko@users.noreply.github.com>
Date: Fri, 6 Jan 2023 14:49:32 +0600
Subject: [PATCH] Russian version, after review. Version 03 (#4)

* Changes and improvements in additional files (README, License, Contributions)

* Fix typos, rephasing. All files. Version 03
---
 .../Personal-Skills/01-Learn-To-Debug.md      |   6 +-
 ...to-Debug-by-Splitting-the-Problem-Space.md |   6 +-
 .../03-How-to-Remove-an-Error.md              |   2 +-
 .../04-How-to-Debug-Using-a-Log.md            |   2 +-
 ...-How-to-Understand-Performance-Problems.md |   6 +-
 .../06-How-to-Fix-Performance-Problems.md     |   8 +-
 .../07-How-to-Optimize-Loops.md               |   4 +-
 .../10-How-to-Deal-with-Intermittent-Bugs.md  |   8 +-
 .../12-How-to-Conduct-Experiments.md          |   6 +-
 .../02-How-to-Estimate-Programming-Time.md    |   8 +-
 ...o-Utilize-People-as-Information-Sources.md |   4 +-
 .../Team-Skills/05-How-to-Document-Wisely.md  |   2 +-
 .../06-How-to-Work-with-Poor-Code.md          |   2 +-
 .../07-How-to-Use-Source-Code-Control.md      |   4 +-
 .../10-How-to-Recognize-When-to-Go-Home.md    |   4 +-
 .../11-How-to-Deal-with-Difficult-People.md   |   6 +-
 ...adeoff-Quality-Against-Development-Time.md |   4 +-
 ...ow-to-Manage-Software-System-Dependence.md |   2 +-
 .../04-How-to-Make-a-Buy-vs-Build-Decision.md |   4 +-
 .../Judgment/05-How-to-Grow-Professionally.md |   2 +-
 .../06-How-to-Evaluate-Interviewees.md        |   2 +-
 ...ow-When-to-Apply-Fancy-Computer-Science.md |   2 +-
 .../08-How-to-Talk-to-Non-Engineers.md        |   2 +-
 .../01-How-to-Stay-Motivated.md               |   2 +-
 .../03-How-to-Tradeoff-Time-vs-Space.md       |   2 +-
 .../Personal-Skills/04-How-to-Stress-Test.md  |   4 +-
 ...-How-to-Balance-Brevity-and-Abstraction.md |   2 +-
 .../06-How-to-Learn-New-Skills.md             |   2 +-
 .../09-Communication-Languages.md             |   6 +-
 .../Personal-Skills/10-Heavy-Tools.md         |   2 +-
 .../Personal-Skills/11-How-to-analyze-data.md |   4 +-
 ru/2-Intermediate/README.md                   |   2 +-
 .../01-How-to-Manage-Development-Time.md      |   4 +-
 ...ow-to-Manage-Third-Party-Software-Risks.md |   2 +-
 .../03-How-to-Manage-Consultants.md           |   2 +-
 ...-Disagree-Honestly-and-Get-Away-with-It.md |   2 +-
 .../01-How-to-Fight-Schedule-Pressure.md      |   2 +-
 .../02-How-to-Understand-the-User.md          |   2 +-
 .../03-How-to-Get-a-Promotion.md              |   2 +-
 ru/3-Advanced/README.md                       |   4 +-
 .../01-How-to-Develop-Talent.md               |   2 +-
 .../08-How-to-Communicate-Well.md             |   2 +-
 .../10-How-to-Deal-with-Managerial-Myths.md   |   2 +-
 ...1-How-to-Deal-with-Organizational-Chaos.md |   2 +-
 .../02-How-to-Utilize-Embedded-Languages.md   |   2 +-
 .../03-Choosing-Languages.md                  |   6 +-
 ru/5-Bibliography.md                          |   2 +-
 ru/6-History.md                               |   2 +-
 ru/7-Contributions.md                         |  39 ++---
 ru/GLOSSARY.md                                |   8 +-
 ru/LICENSE.md                                 |   7 +-
 ru/README.md                                  |  22 +--
 ru/SUMMARY.md                                 | 159 +++++++++---------
 53 files changed, 198 insertions(+), 199 deletions(-)

diff --git a/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md b/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
index 763811a..991c78b 100644
--- a/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
+++ b/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
@@ -4,9 +4,9 @@
 
 Те идеалисты, которые считают, что дизайн, анализ, теория сложности вычислений и подобное более фундаментальны, чем отладка, вряд ли являются работающими программистами. Работающий программист не живет в идеальном мире. Даже если вы идеальны, вы окружены и вынуждены работать с кодом, который написан в больших корпорациях, организациях вроде GNU и вашими коллегами. Большая часть этого кода неидеальна, и она неидеально задокументирована. Без способности видеть исполнение этого кода, малейший баг выбьет вас из колеи. Часто увидеть исполнение можно только с помощью эксперимента, то есть, отладки. 
 
-Отладка больше касается исполнения программ, чем самих программ. Если вы купите программное обеспечение от большой компании, то как правило вам не доведется увидеть сам код. Но все равно будут моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы. Обычно вы при работе создаете баг, изучаете собственный код и понятия не имеете, как он возник. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
+Отладка больше касается исполнения программ, чем самих программ. Если вы купите программное обеспечение от большой компании, то как правило вам не доведется увидеть сам код. Но все равно будут моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы программы. Обычно вы при работе создаете баг, изучаете собственный код и понятия не имеете, как он возник. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
 
-Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать ход исполнения. Иногда баг виден визуально, например, если он отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, баг связан с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
+Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать за ее ходом исполнения. Иногда баг виден визуально, например, если он отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, баг связан с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
 
 Распространенные методы изучения "внутренностей" программы можно поделить на:
 
@@ -16,6 +16,6 @@
 
 Отладчики это прекрасное средство, когда они стабильны и доступны, но вывод в консоль и логирование гораздо важнее. Отладчики часто отстают от развития языков программирования, так что они могут быть доступны не в каждый момент времени. К тому же, некоторые отладчики могут незначительно изменять ход исполнения программы, поэтому применять их в этих случаях непрактично. Наконец, существуют виды отладки, такие как проверка утверждений в большой структуре данных, которые требуют написания нового кода и изменения хода исполнения программы. Так что важно знать, как пользоваться отладчиками, когда они доступны, но критично важно уметь использовать два оставшихся метода.
 
-Некоторые начинающие программиста боятся отладки, если та требует изменения кода. Это можно понять, ведь это немного похоже на вскрытие с исследовательскими целями. Но вы должны научиться вызывать свой код, экспериментировать с ним и понимать, что ничего из того, что вы временно делаете с ним, не сделает его хуже. Если у вас есть такой страх, найдите наставника. Мы теряем множество хороших программистов в самом начале их обучения из-за этого страха.
+Некоторые начинающие программиста боятся отладки, если та требует изменения кода. Их можно понять, ведь это немного похоже на вскрытие с исследовательскими целями. Но вы должны научиться вызывать свой код, экспериментировать с ним и понимать, что ничего из того, что вы временно делаете с ним, не сделает его хуже. Если у вас есть такой страх, найдите наставника. Мы теряем множество хороших программистов в самом начале их обучения из-за этого страха.
 
 Следующее: [Как отлаживать, разделяя пространство проблемы](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
index 6f7c1db..ab80909 100644
--- 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
@@ -1,14 +1,14 @@
 # Как отлаживать, разделяя пространство проблемы
 [//]: # (Version:1.0.0)
-Отладка это интересно, потому что она начинается с проблемы. Вы думаете, что программа делает одно, но на самом деле она делает что-то другое. Не всегда это настолько просто, но все примеры, которые я мог бы привести, будут надуманными по сравнению с реальными случаями. Отладка требует творчества и изобретательности. Если и есть какой-то один ключ к отладке, то он заключается в приеме "разделяй и властвуй" в отношении проблемы.
+Отладка это интересно, потому что она начинается с проблемы. Вы думаете, что программа делает одно, но на самом деле она делает что-то другое. Не всегда это настолько просто, но все примеры, которые я мог бы привести, будут надуманными по сравнению с реальными случаями. Отладка требует творчества и смекалки. Если и есть какой-то один ключ к отладке, то он заключается в приеме "разделяй и властвуй" в отношении проблемы.
 
 Предположим, к примеру, что вы написали программу, которая должна выполнять десять инструкций подряд. Затем вы запускаете ее, и она вылетает. Поскольку вы не планировали вылет программы, у вас появляется проблема. Когда вы смотрите на вывод программы, вы видите, что первые семь инструкций были выполнены успешно. Оставшиеся три инструкции не видны в выводе, поэтому пространство проблемы сужается: программа вылетает либо на восьмой, либо на девятой, либо на десятой инструкции.
 
 Сможете ли вы поставить эксперимент, чтобы увидеть, где вылетает программа? Конечно. Вы можете использовать отладчик или добавить вывод в консоль (либо их эквивалент на вашем языке программирования) после восьмой и девятой инструкций. Когда вы запустите программу снова, пространство проблемы станет еще уже, например, вы увидите, что программа вылетает на девятой инструкции. Я считаю, что помнить о точном определении проблемы помогает сосредоточиться на ее решении. Когда несколько человек работают под давлением и стрессом над задачей, очень легко забыть о том, что в ней является главной проблемой.
 
-Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, напополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка и которое следует поделить пополам? Именно здесь на помощь приходят изобретательность и опыт.
+Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, напополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка и которое следует поделить пополам? Именно здесь на помощь приходят смекалка и опыт.
 
-Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того понимания программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешнем кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
+Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того понимания программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешним кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
 
 Когда вы разделили все пространство программы на все места, где может быть ошибка, вам предстоит определить, где именно она находится. В простом случае, когда вопрос стоит как "В какой неизвестной мне строке падает программа?", вы можете спросить себя: "Неизвестная мне строка с ошибкой находится до или после этой строки, которая по моему мнению должна исполняться в середине программы?" Как правило, вы будете не настолько удачливы, чтобы обнаружить, что ошибка кроется в одной строке или даже в одном блоке кода. Чаще проблема будет звучать как "Либо в этом графе есть указатель на некорректный объект, либо мой алгоритм некорректно складывает переменные в этом графе". В этом случае, возможно, вам придется написать небольшую программу для проверки указателей, чтобы решить, какую из частей этого пространства проблемы можно исключить. 
 
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
index 9531023..6e49d68 100644
--- 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
@@ -4,6 +4,6 @@
 
 При исправлении бага важно внести наименьшие изменения, которые его устранят. Вы можете заметить другие места в коде, которые потребуют улучшений, но не вносите их одновременно с исправлением ошибки. Старайтесь применять научный метод: изменять только одно зараз. Лучший способ для этого: воспроизвести баг, внести исправления, затем перезапустить программу и убедиться, что бага больше нет. Конечно, иногда придется менять не одну, а несколько строк кода, но концептуально все равно старайтесь вносить точечные изменения для исправления ошибки.
 
-Иногда в программе присутствует несколько багов, очень похожих друг на друга. Определить их и исправить по одному - это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае, вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир часто бывает беспорядочен. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
+Иногда в программе присутствует несколько багов, очень похожих друг на друга. Определить их и исправить по одному - это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае, вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать, и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир часто бывает беспорядочен. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
 
 Следующее: [Как отлаживать, используя логирование](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
index 6933061..5ae285d 100644
--- 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
@@ -6,7 +6,7 @@
 - Логи могут давать статистику и данные о производительности, такие как время между выполнением команд
 - Если логи настраиваемы, то они помогают собрать общую информацию для устранения непредвиденных специфических проблем без необходимости модифицировать или перезапускать код
 
-Количество выводимой в лог информации это всегда компромисс между информативностью и краткостью. Избыток информации сделает лог тяжелым и вызовет *слепоту прокрутки*, усложняя поиск нужного. Недостаток информации может просто сделать лог бесполезным. По этой причине полезно делать логи настраиваемыми. Как правило, каждая запись в логе отображает свое место в исходном коде, исполняющий ее поток, если он есть, точное время исполнения и, обычно, дополнительную информацию вроде значений переменных, объем свободной памяти, число объектов с данными и так далее. Эти записи покрывают весь исходный код, особенно основные функциональные узлы и рискованный код. Записи можно распределить по уровням, и настраивать в конфигурации вывод только записей определенного уровня. Лог следует проектировать таким образом, чтобы его записи помогали решать проблемы программы, которые вы предвидите. Предусматривайте и проблему измерения производительности.
+Количество выводимой в лог информации это всегда компромисс между информативностью и краткостью. Избыток информации сделает лог тяжелым и вызовет *слепоту прокрутки*, усложняя поиск нужного. Недостаток информации может просто сделать лог бесполезным. По этой причине полезно делать логи настраиваемыми. Как правило, каждая запись в логе отображает свое место в исходном коде, исполняющий ее поток, если он есть, точное время исполнения и, обычно, дополнительную информацию вроде значений переменных, объем свободной памяти, число объектов с данными и так далее. Эти записи покрывают весь исходный код, особенно основные функциональные узлы и рискованный код. Записи можно распределять по уровням, и настраивать в конфигурации вывод только записей определенного уровня. Лог следует проектировать таким образом, чтобы его записи помогали решать проблемы программы, которые вы предвидите. Предусматривайте и проблему измерения производительности.
 
 Если у вас есть постоянный лог, вывод в консоль можно выполнить в рамках записей лога, и некоторые из отладочных сообщений стоит перманентно включить в систему логирования.
 
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
index bb3ba1f..1fe7800 100644
--- 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
@@ -1,11 +1,11 @@
 # Как определять проблемы производительности
 [//]: # (Version:1.0.0)
-Изучение проблем производительности так же неизбежно, как освоение отладки. Даже если вы в точности и совершенстве понимаете затраты на исполнение вашего кода, он будет взаимодействовать с другим программным обеспечением, над которым у вас нет будет такого контроля или понимания. Как бы то ни было, на практике проблемы производительности немного отличаются и проще, чем отладка в целом.
+Изучение проблем производительности так же неизбежно, как и освоение отладки. Даже если вы в точности и совершенстве понимаете затраты на исполнение вашего кода, он будет взаимодействовать с другим программным обеспечением, над которым у вас нет будет такого контроля или понимания. Как бы то ни было, на практике проблемы производительности немного отличаются и проще, чем отладка в целом.
 
-Предположим, что вы или ваши клиенты считают систему или одну из подсистем слишком медленной. Перед тем, как вы попытаетесь ускорить ее, вам стоит построить мысленную модель и определить, почему она медленная. Вы можете использовать профилировщик или хороший лог, чтобы определить, где именно затрачивается врвмя или иной ресурс системы. Существует известное утверждение, что 90% времени затрачивается на 10% кода. Я бы добавил к этому важность затрат на чтение и запись в оценке проблем производительности. Часто большая часть времени тратится либо на чтение информации, либо на ее запись. Хорошим первым шагом в построении мысленной модели проблемы будет нахождение затратных операций чтения и записи и 10% кода, занимающих большую часть ресурса.
+Предположим, что вы или ваши клиенты считают систему или одну из подсистем слишком медленной. Перед тем, как вы попытаетесь ускорить ее, вам стоит построить ее мысленную модель и определить, почему она медленная. Вы можете использовать профилировщик или хороший лог, чтобы определить, где именно затрачивается время или иной ресурс системы. Существует известное утверждение, что 90% времени затрачивается на 10% кода. Я бы добавил к этому важность затрат на чтение и запись в оценке проблем производительности. Часто большая часть времени тратится либо на чтение информации, либо на ее запись. Хорошим первым шагом в построении мысленной модели проблемы будет нахождение затратных операций чтения и записи и 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
index 0dca667..57a78cb 100644
--- 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
@@ -1,12 +1,12 @@
 # Как устранять проблемы производительности
 [//]: # (Version:1.0.0)
-Большинство проектов можно с относительно небольшими усилиями ускорить в 10-100 раз относительно их первой версии. В условиях сжатых сроков ыыхода на рынок разумно и эффективно выбирать ту реализацию, которая проще и быстрее остальных. Однако, производительность это часть удобства использования, поэтому часто ее стоит оценивать более внимательно.
+Большинство проектов можно с относительно небольшими усилиями ускорить в 10-100 раз относительно их первой версии. В условиях сжатых сроков выхода на рынок разумно и эффективно выбирать ту реализацию, которая проще и быстрее остальных. Однако, производительность это часть удобства использования, поэтому часто ее стоит оценивать более внимательно.
 
-Главное в улучшении производительности сложной системы - это проанализировать ее достаточно тщательно, чтобы найти "узкие места", то есть те места, где запрашивается наибольший объем ресурсов. Нет большого смысла оптимизировать функцию, которая занимает только 1% процессорного времени. Если вы не уверены, что изменение ускорит систему или ее значительную часть хотя бы в два раза, то стоит хорошо подумать, стоит ли это вообще делать. Как правило, такие способы ускорения есть. Оценивайте также затраты на тестирование и проверки, которые потребует ваше изменение кода. Каждое изменение кода влечет за собой необходимость тестирования, поэтому лучше иметь немного больших изменений.
+Главное в улучшении производительности сложной системы - это проанализировать ее достаточно тщательно, чтобы найти "узкие места", то есть те места, где запрашивается наибольший объем ресурсов. Нет большого смысла оптимизировать функцию, которая занимает только 1% процессорного времени. Если вы не уверены, что изменение ускорит систему или ее значительную часть хотя бы в два раза, то стоит хорошо подумать, стоит ли это вообще делать. Как правило, такие способы ускорения есть. Оценивайте также затраты на тестирование и проверки, которые потребует ваше изменение кода. Каждое изменение кода влечет за собой необходимость тестирования, поэтому лучше иметь небольшое число значительных изменений.
 
-После того, как вы добились двукратного улучшения производительности в одном месте, стоит снова провести анализ программы и определить следующее по затратам узкое место. Тогда можно заняться им.
+После того, как вы добились двукратного улучшения производительности в одном месте, стоит снова проанализировать программу и определить следующее по затратам узкое место. Тогда можно заняться им.
 
-Часто узкие места в производительности будут представлять собой что-то вроде подсчета коров по ногам и делению на четыре вместо обычного подсчета по головам. Например, я часто забывал дать собственный индекс часто запрашиваемому столбцу в реляционной базе управления данных, что замедляло весь процесс минимум в 20 раз. Среди других примеров: ненужные операции чтения и записи в циклах, отладочные сообщения, ставшие неактуальными, избыточное выделение памяти и в особенности неумелое использование библиотек и сторонних фреймворков, которые плохо документированы в части производительности. Такой вид улучшений легко определить и с ходу внести в программу. 
+Часто узкие места в производительности будут представлять собой что-то вроде подсчета коров по ногам и последующего деления на четыре вместо обычного подсчета по головам. Например, я часто забывал дать собственный индекс часто запрашиваемому столбцу в реляционной базе управления данных, что замедляло весь процесс минимум в 20 раз. Среди других примеров: ненужные операции чтения и записи в циклах, отладочные сообщения, ставшие неактуальными, избыточное выделение памяти и в особенности неумелое использование библиотек и сторонних фреймворков, которые плохо документированы в части производительности. Такой вид улучшений легко определить и с ходу внести в программу. 
 
 Что делать, когда очевидных мест для улучшений не осталось? Вы можете продолжать искать узкие места на более глубоком уровне или пересмотреть весь дизайн системы. Последнее дает прекраную возможность продемонстрировать свои умения программиста не только в реализации нового дизайна системы, но и в умении убедить своего босса в том, что это необходимо. Тем не менее, перед тем, как вы начнете убеждать его в необходимости коренных изменений, спросите себя, ускорит ли ваше решение систему в 5-10 раз.
 
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
index 34c39f5..63e387f 100644
--- a/ru/1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md
+++ b/ru/1-Beginner/Personal-Skills/07-How-to-Optimize-Loops.md
@@ -1,6 +1,6 @@
 # Как оптимизировать циклы
 [//]: # (Version:1.0.0)
-Иногда вам будут встречаться затратные по времени циклы или рекурсивные функции, которые окажутся узкими местами в вашей программе. Перед тем, как вы попытаетесь ускорить цикл, потратьте некоторое время на то, чтобы понять, можно ли избавиться от него полностью. Сработает ли здесь какой-нибудь другой алгоритм? Можно ли вычислить это параллельно с другим вычислением? Если вам не удалось найти обходной путь, тогда оптимизируйте цикл. Это просто: вынесите из него все, что можно. В конце концов, эта операция требует не только изобретательности, но и понимания, сколько затрачивается на каждое выражение и операцию. Вот несколько предложений:
+Иногда вам будут встречаться затратные по времени циклы или рекурсивные функции, которые окажутся узкими местами в вашей программе. Перед тем, как вы попытаетесь ускорить цикл, потратьте некоторое время на то, чтобы понять, можно ли избавиться от него полностью. Сработает ли здесь какой-нибудь другой алгоритм? Можно ли вычислить это параллельно с другим вычислением? Если вам не удалось найти обходной путь, тогда оптимизируйте цикл. Это просто: вынесите из него все, что можно. В конце концов, эта операция требует не только смекалки, но и понимания, сколько затрачивается на каждое выражение и операцию. Вот несколько предложений:
 
 - Уберите операции с плавающей точкой
 - Не выделяйте впустую новые блоки памяти
@@ -10,6 +10,6 @@
 - Старайтесь не использовать затратные приведения типов данных
 - Перемещайте указатель вместо того, чтобы пересчитывать индексы
 
-Стоимость каждой из этих операций зависит от вашей конкретной системы. Где-то компиляторы и аппаратное обеспечение выполнит их вместо вас. Разумеется, чистый и эффективный код лучше, чем тот, который требует понимания специфичной платформы.
+Стоимость каждой из этих операций зависит от вашей конкретной системы. Где-то компиляторы и аппаратное обеспечение выполнят их вместо вас. Разумеется, чистый и эффективный код лучше, чем тот, который требует понимания специфичной платформы.
 
 Следующее: [Как справиться с расходами на операции чтения и записи](08-How-to-Deal-with-IO-Expense.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
index aae3578..661861a 100644
--- 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
@@ -1,6 +1,6 @@
 # Как устранять плавающие баги
 [//]: # (Version:1.0.0)
-Плавающий баг это родственник пятидесятиметрового невидимого скорпиона из глубокого космоса. Этот кошмар воспроизводится так редко, что его трудно наблюдать, но достаточно части его нельзя просто игнорировать. Вы не можете отладить баг, потому что вы не можете его найти.
+Плавающий баг это родственник пятидесятиметрового невидимого скорпиона из глубокого космоса. Этот кошмар воспроизводится так редко, что его трудно наблюдать, но достаточно часто его нельзя просто игнорировать. Вы не можете отладить баг, потому что вы не можете его найти.
 
 Хотя после восьми часов отладки вы начнете сомневаться в этом, плавающие баги подчиняются тем же самым законам логики, что и все остальное. Что делает их трудными, это неизвестные обстоятельства, в которых они воспроизводятся. Постарайтесь записать все условия, при которых происходит плавающий баг, чтобы вы могли предположить, в чем на самом деле заключается изменчивость бага. Баг может быть связан со значениями данных, например, воспроизводиться, только когда переменной присваивается значение "Вайоминг". Если причина изменчивости не в этом, то следующим пунктом стоит проверить синхронизацию конкуррентности.
 
@@ -8,10 +8,10 @@
 
 Самый глупый плавающий баг, который создал я, заключался в многопоточной реализации одного функционального языка программирования для учебного проекта. Я тщательно обеспечил корректную оценку параллельности программы, правильное использование ядер процессора (всех восьми в данном случае). Я просто-напросто забыл синхронизировать сборщик мусора. Программа могла работать безошибочно долгое время, завершая все задания, которые я ей назначал. Со стыдом признаюсь, я начал подозревать аппаратное обеспечение, прежде чем меня осенило, в чем проблема.
 
-Недавно на работе у нас был плавающий баг, на который мы потратили несколько недель. У нас есть многопоточное серверное приложение на Java, размещенное на Apache-серверах. Чтобы поддержать быструю смену веб-страниц, мы выполняли все операции чтения и записи в небольшом наборе из четырех потоков, отделенных от потоков, ответственных за смену страниц. Время от времени они "замораживались" и, насколько мы могли понять из логов, прекращали делать что-либо полезное на несколько часов. Поскольку у нас было выделено четыре потока, само по себе это не было большой проблемой. До тех пор, пока не замораживались все четыре потока одновременно. Тогда очереди запросов, освобожденные замороженными потоками, забивали всю свободную память и крашили наш сервер. Нам потребовалась неделя, чтобы просто выявить баг, и за это время мы не смогли понять, в чем причина, вызывающая этот баг, и даже что именно происходило в потоках в тот момент, когда они "застревали".
+Недавно на работе у нас был плавающий баг, на который мы потратили несколько недель. У нас есть многопоточное серверное приложение на Java, размещенное на Apache-серверах. Чтобы поддержать быструю смену веб-страниц, мы выполняли все операции чтения и записи в небольшом наборе из четырех потоков, отделенных от потоков, ответственных за смену страниц. Время от времени некоторые из этих четырех потоков "замораживались" и, насколько мы могли понять из логов, прекращали делать что-либо полезное на несколько часов. Поскольку у нас было выделено четыре потока, само по себе это не было большой проблемой. До тех пор, пока не замораживались все четыре потока одновременно. Тогда очереди запросов, освобожденные замороженными потоками, забивали всю свободную память и крашили наш сервер. Нам потребовалась неделя, чтобы просто выявить баг, и за это время мы не смогли понять, в чем причина, вызывающая этот баг, и даже что именно происходило в потоках в тот момент, когда они "застревали".
 
-Этот пример демонстрирует риск, связанный с использованием стороннего программного обеспечения. Мы использовали лицензионный код, который убирал теги HTML из текста. Хотя, к счастью,  у нас был исходный код, мы не изучали его досконально, пока мы не включили логирование на нашем сервере и не увидели, что потоки почтовых сообщений забивались из-за этого лиценционного кода.
+Этот пример демонстрирует риск, связанный с использованием стороннего программного обеспечения. Мы использовали лицензионный код, который убирал теги HTML из текста. Хотя, к счастью, у нас был исходный код, мы не изучали его досконально, пока мы не включили логирование на нашем сервере и не увидели, что потоки почтовых сообщений забивались из-за этого лиценционного кода.
 
-Программа работала прекрасно, за исключением некоторых длинных и необычных текстов. В этом случае, время обработки текста становилось пропорционально квадрату его длины. Если бы такие тексты встречались бы регулярно, мы бы сразу нашли баг. Если бы они вообще не попадались бы, бага просто не было бы. Как это бывает, мы потратили несколько недель, чтобы наконец понять и решить проблему.  
+Программа работала прекрасно, за исключением некоторых длинных и необычных текстов. В этом случае, время обработки текста становилось пропорциональным квадрату его длины. Если бы такие тексты встречались бы регулярно, мы бы сразу нашли баг. Если бы они вообще не попадались бы, бага просто не было бы. Как это бывает, мы потратили несколько недель, чтобы наконец понять и решить проблему.  
 
 Следующее: [Как научиться проектировать программы](11-How-to-Learn-Design-Skills.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
index 271d8bf..ba7c792 100644
--- a/ru/1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md
+++ b/ru/1-Beginner/Personal-Skills/12-How-to-Conduct-Experiments.md
@@ -1,10 +1,10 @@
 # Как экспериментировать
 [//]: # (Version:1.0.0)
-Великий Эдсгер Дейкстра красноречиво объеснил, что информатика не является экспериментальной наукой[ExpCS] и не зависит от электронных устройств. Как он выразился в 1960-е годы [Knife]:
+Великий Эдсгер Дейкстра красноречиво объяснил, что информатика не является экспериментальной наукой[ExpCS] и не зависит от электронных устройств. Как он выразился в 1960-е годы [Knife]:
 
 > ...произошло худшее: предмет стал известен как “computer science”, что, собственно говоря, то же самое, что называть хирургию “knife science”. И в сознании людей прочно укоренилось, что “computer science” - это наука о машинах и периферийном оборудовании.
 
-Программирование может и не быть экспериментальной наукой, но у большинства программистов не возможности заниматься тем, что Дейкстра определил как “computer science”. Мы должны работать в области экперимента подобно некоторым (но не всем) физикам. Если спустя 30 лет можно будет заниматься программированием без экспериментирования, то это будет великим достижением информатики.
+Программирование может и не быть экспериментальной наукой, но у большинства программистов нет возможности заниматься тем, что Дейкстра определил как “computer science”. Мы должны работать в области эксперимента подобно некоторым (но не всем) физикам. Если спустя 30 лет можно будет заниматься программированием без экспериментирования, то это будет великим достижением информатики.
 
 Эксперименты, которые вам придется заниматься, включают:
 
@@ -18,6 +18,6 @@
 
 Первое: старайтесь четко обозначать свои исходные предположения или утверждения, которые вы собираетесь проверить. Очень полезно записывать их, особенно, если вы работаете в коллективе.
 
-Часто вам придется проектировать серию экспериментов, каждый из которых опирается на знания, полученные в результате предыдущего. Таким образом, следует проектировать эксперименты таким образом, чтобы получать как можно больше информации. К сожалению, это противоречит принципу простоты экспериментов. Вам придется развивать свою экспертизу в этой области самостоятельно.
+Часто вам придется проектировать серию экспериментов, каждый из которых опирается на знания, полученные в результате предыдущего. Таким образом, следует проектировать эксперименты так, чтобы получать как можно больше информации. К сожалению, это противоречит принципу простоты экспериментов. Вам придется развивать свою экспертизу в этой области самостоятельно.
 
 Следующее: [Командные навыки. Почему важно оценивать задачи](../Team-Skills/01-Why-Estimation-is-Important.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
index 5ad5101..f34e0c9 100644
--- 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
@@ -2,13 +2,13 @@
 [//]: # (Version:1.0.0)
 Оценка времени требует практики и труда. Иногда так много труда, что имеет смысл отдельно оценивать время на оценку задачи, особенно, если речь идет об оценке большой задачи.
 
-Когда вас просят оценивать большую задачу, самое честное - потянуть время. Большинство инженеров полны энтузиазма и склонны угождать, а задержка ответа не обрадует спрашивающего. Но выданная с ходу оценка вряд ли будет точной и честной.
+Когда вас просят оценить большую задачу, самое честное - потянуть время. Большинство инженеров полны энтузиазма и склонны угождать, а задержка ответа не обрадует спрашивающего. Но выданная с ходу оценка вряд ли будет точной и честной.
 
 Пока вы думаете над ответом, возможно, получится сделать прототип задачи. Если обстоятельства позволяют, то это самый точный способ оценки, и он позволяет добиться реального прогресса.
 
-Когда взять время на некоторое исследование задачи невозможно, то сначала вы должны четко и ясно установить, что именно означает ваша оценка. Сформулируйте это значение как первое и заключительное части вашей оценки в письменном виде. Подготовьте письменный ответ, разбирая задачу на более мелкие задания, в идеальном случае, требующие не больше одного рабочего дня. Самое важное здесь - ничего не забыть. Например, очень важно время на документирование, тестирование, планирование, взаимодействие с другими командами, отпуска. Если вы каждый день тратите часть времени на общение с неумными людьми, добавьте отдельную строку на это в общую оценку времени. Это даст вашему боссу общее видение того, что отнимает у вас немного времени, а на что вам требуется его гораздо больше.
+Когда взять время на некоторое исследование задачи невозможно, то сначала вы должны четко и ясно установить, что именно означает ваша оценка. Сформулируйте это значение как первое и заключительное части вашей оценки в письменном виде. Подготовьте письменный ответ, разбирая задачу на более мелкие задания, в идеальном случае, требующие не больше одного рабочего дня. Самое важное здесь - ничего не забыть. Например, очень важно время на документирование, тестирование, планирование, взаимодействие с другими командами, отпуска. Если вы каждый день тратите часть времени на общение с неумными людьми, добавьте отдельную строку на это в общую оценку времени. Это даст вашему боссу общее видение того, что отнимает у вас немного времени, а на что вам его требуется гораздо больше.
 
-Я знаком с программистами, которые включают такие временные затраты в общую оценку в неявном виде, то есть просто прибавляют их к общему времени работы. Я не советую так делать. Одним из эффектов такого подхода может стать потеря доверия. Например, программист может заложить три дня на задачу, которую он на самом деле собирается выполнить за день. Программист планирует потратить еще два дня на документирование своей работы или на другой полезный проект. Но тот факт, что работа была выполнена только за один день, очень просто выяснить. И тогда может возникнуть впечатление, что программист бездельничал или переоценил задачу. Намного лучше дать четкое описание того, что вы реально собираетесь делать в рамках задачи. Если документирование занимает в два раза больше времени, чем написание кода, и в оценке сказано об этом, то это дает преимущества, если это донести до вашего менеджера.
+Я знаком с программистами, которые включают такие временные затраты в общую оценку в неявном виде, то есть просто прибавляют их к общему времени работы. Я не советую так делать. Одним из эффектов такого подхода может стать потеря доверия. Например, программист может заложить три дня на задачу, которую он на самом деле собирается выполнить за день. Программист планирует потратить еще два дня на документирование своей работы или на другой полезный проект. Но тот факт, что работа была выполнена только за один день, очень просто выяснить. И тогда может возникнуть впечатление, что программист бездельничал или переоценил задачу. Намного лучше дать четкое описание того, что вы реально собираетесь делать в рамках задачи. Если документирование занимает в два раза больше времени, чем написание кода, и в оценке сказано об этом, то это дает свои преимущества, если это донести до вашего менеджера.
 
 Включайте все временные затраты в оценку в явном виде. Если задача скорее всего займет один день, но может растянуться на десять дней, если ваш первоначальный подход не сработает, отметьте это в вашей оценке. Либо укажите среднее время задачи согласно вашим оценкам вероятностей разных исходов. Любые риски, связанные с временем на задачу, должны быть включены в оценку. Вряд ли конкретный человек заболеет в конкретный момент времени. Но в большом проекте с множеством программистов обязательно будут те, кто возьмет больничный. То же самое касается отпусков. А какова вероятность обязательного обучающего семинара в рамках всей компании? Если ее можно оценить, включите ее в общую оценку. Кроме этого, еще есть неизвестные факторы. Их по определению не получится оценить по отдельности. Вы можете заложить для них отдельную строку в общей оценке, либо учесть их как-то по-другому. Чего нельзя делать, так это позволять своему боссу забыть об их существовании. Очень легко превратить оценку времени в расписание, если не учитывать неизвестные факторы.
 
@@ -16,6 +16,6 @@
 
 Если в задаче присутствуют большие риски, которые невозможно оценить, ваша обязанность донести это до менеджера так, чтобы тот не брал на себя обязательства, связанные с ними. В этом случае стоит сделать все возможное, чтобы снизить эти риски.
 
-Если вы сможете убедить свою компанию исользовать *экстремальное программирование*, то вам придется оценивать только относительно небольшие задачи. Это гораздо интереснее и продуктивнее.
+Если вы сможете убедить свою компанию использовать *экстремальное программирование*, то вам придется оценивать только относительно небольшие задачи. Это гораздо интереснее и продуктивнее.
 
 Следующее: [Как искать информацию](03-How-to-Find-Out-Information.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
index 5c97e85..f03f22a 100644
--- 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
@@ -2,9 +2,9 @@
 [//]: # (Version:1.0.0)
 Уважайте время каждого человека и соизмеряйте его со своим. Вопрос дает гораздо больше, чем просто ответ. Человек, которого вы спрашиваете, узнает вас как просто из вашего присутствия, так и по вашему вопросу. Вы узнаете о человеке то же самое, и вдобавок, возможно, вы получаете ответ на ваш вопрос. Как правило, это гораздо важнее, чем ваш вопрос.
 
-Однако, ценность вопросов умешьшается тем больше, чем чаще вы их задаете. В конце концов, вы отнимаете у человека самое важное: время. Выгоды от общения стоит соизмерять с затратами на него. Более того, конкретны выгоды и затраты отличаются от человека к человеку. Я убежден, что руководитель 100 человек должен тратить 5 минут в месяц на разговор с каждым человеком в организации. Это займет 5% всего времени руководителя. Но 10 минут может быть слишком много для такого числа, а 5 минут может быть много, если в компании 1000 сотрудников. Число времени, которое вы тратите на беседы с каждым человеком в вашей компании, зависит от роли человека (больше, чем от должности). Вам следует разговаривать с вашим боссом чаще, чем с боссом вашего босса, но и с ним вам стоит немного разговаривать. Это может оказаться некомфортным, но я считаю, что ваша обязанность каждый месяц немного разговаривать со всеми вашими руководителями, несмотря ни на что.
+Однако, ценность вопросов умешьшается тем больше, чем чаще вы их задаете. В конце концов, вы отнимаете у человека самое важное: время. Выгоды от общения стоит соизмерять с затратами на него. Более того, конкретные выгоды и затраты отличаются от человека к человеку. Я убежден, что руководитель 100 человек должен тратить 5 минут в месяц на разговор с каждым человеком в организации. Это займет 5% всего времени руководителя. Но 10 минут может быть слишком много для такого числа, а 5 минут может быть много, если в компании 1000 сотрудников. Число времени, которое вы тратите на беседы с каждым человеком в вашей компании, зависит от роли человека (больше, чем от должности). Вам следует разговаривать с вашим боссом чаще, чем с боссом вашего босса, но и с ним вам стоит немного разговаривать. Это может оказаться некомфортным, но я считаю, что ваша обязанность каждый месяц немного разговаривать со всеми вашими руководителями, несмотря ни на что.
 
-Главное правило: все получают пользу от небольшой беседы с вами. И чем чаще происходит беседа, тем меньше пользы они получают. Ваша работа состоит в том, чтобы дать этим людям полезу от разговора с вами и получить ее самому, сохраняя баланс между нею и потраченным временем.
+Главное правило: все получают пользу от небольшой беседы с вами. И чем чаще происходит беседа, тем меньше пользы они получают. Ваша работа состоит в том, чтобы дать этим людям пользу от разговора с вами и получить ее самому, сохраняя баланс между нею и потраченным временем.
 
 Важно уважать свое собственное время. Если разговор с кем-то, несмотря на то, что он займет время этого человека, поможет сохранить вам ваше время, то вам стоит провести этот разговор. Если только вы не считаете, что потраченное на разговор время этого человека более важно для всей организации.
 
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
index a3c24d5..4d57c30 100644
--- a/ru/1-Beginner/Team-Skills/05-How-to-Document-Wisely.md
+++ b/ru/1-Beginner/Team-Skills/05-How-to-Document-Wisely.md
@@ -1,6 +1,6 @@
 # Как документировать правильно
 [//]: # (Version:1.0.0)
-Жизнь слишком коротка, чтобы писать ерунду, которую никто не будет читать. Если вы пишите плохо, никто не будет это читать. Так что лучше всего документировать хорошо и немного. Менеджеры часто не понимают этого, потому что даже плохая документация дает им ложное чувство уверенности, что они не зависят от своих программистов. Если кто-то абсолютно настаивает, чтобы вы писали никому не нужную документацию, скажите "да" и начинайте спокойно искать новую работу. 
+Жизнь слишком коротка, чтобы писать ерунду, которую никто не будет читать. Если вы пишите плохо, никто не будет это читать. Так что лучше всего документировать хорошо и немного. Менеджеры часто не понимают этого, потому что даже плохая документация дает им ложное чувство уверенности, что они не зависят от своих программистов. Если кто-то абсолютно настаивает, чтобы вы писали никому ненужную документацию, скажите "да" и начинайте спокойно искать новую работу. 
 
 Чтобы снизить запрос на документирование, нет ничего более эффективного, чем дать точную оценку времени, которое на него потребуется. Реалии жизни холодны и суровы: документирование, как и тестирование, может занять гораздо больше времени, чем разработка.
 
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
index 7036276..7f72475 100644
--- 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
@@ -8,4 +8,4 @@
 
 Важно помнить, что абстракция и инкапсуляция, два лучших средства программиста, особенно применимы к плохому коду. Возможно, вы не сможете переделать целиком большой блок кода, но если вы добавите новый уровень абстракции к нему, то сможете добиться некоторых преимуществ без переделки всего кода. В частности, вы можете отделить особенно плохие части кода, чтобы отрефакторить их независимо от остального кода.
 
-Следующее: [Как использовать системы контроля кода](07-How-to-Use-Source-Code-Control.md)
\ No newline at end of file
+Следующее: [Как использовать системы контроля версий](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
index ca20628..dd2752f 100644
--- 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
@@ -1,9 +1,9 @@
 # Как использовать системы контроля версий
 [//]: # (Version:1.0.0)
-Системы контроля версий (также известные как системы контроля кода) позволяют вам эффективно управлять проектами. Они очень полезны для программиста-одиночки и жизненно важны для группы разработчиков. Они отслеживают все изменения во всех версиях кода, так что ни одна строка кода не может быть потеряна навсегда. Кроме этого, они позволяют присвоить осмысленное название изменениям. С помощью таких систем можно писать отладочный код с уверенностью, ведь весь модифицируемый код можно хранить отдельно от исходного работающего. Новый код потом можно показать всей команде или сразу выпустить.
+Системы контроля версий (также известные как системы контроля кода) позволяют вам эффективно управлять проектами. Они очень полезны для программиста-одиночки и жизненно необходимы для группы разработчиков. Они отслеживают все изменения во всех версиях кода, так что ни одна строка кода не может быть потеряна навсегда. Кроме этого, они позволяют присвоить осмысленное название изменениям. С помощью таких систем можно писать отладочный код с уверенностью, ведь весь модифицируемый код можно хранить отдельно от исходного работающего. Новый код потом можно показать всей команде или сразу выпустить.
 
 Я довольно поздно оценил все преимущества систем контроля версий, но теперь без них я не начну даже небольшой личный проект. Вообще они нужны, когда вы работаете в команде с одной кодовой базой. Но у них есть другое важное преимущество: они поощряют думать о коде как о растущей системе. Поскольку каждое изменение отмечено своим именем или номером, постепенно приходишь к мысли, что программное обеспечение это видимая последовательная серия изменений в коде. Я думаю, что это особенно полезно для начинающих программистов.
 
-Хорошая техника использования системы контроля версий заключается в том, чтобы постоянно держать свой код в пределах нескольких дней от актуальности. Код, который не может быть закончен за несколько дней, проверяется, но таким образом, чтобы он был неактивным и не вызывался в действующей системе, а значит, не создавал проблем для других. Ошибки, замедляющие работу товарищей по команде, непростительны и часто являются табу.
+Хорошая техника использования системы контроля версий заключается в том, чтобы постоянно держать свой собственный код в пределах нескольких дней от актуального. Код, который не может быть закончен за несколько дней, проверяется, но таким образом, чтобы он был неактивным и не вызывался в действующей системе, а значит, не создавал проблем для других. Ошибки, замедляющие работу товарищей по команде, непростительны и часто являются табу.
 
 Следующее: [Как писать юнит-тесты](08-How-to-Unit-Test.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
index 8950abf..9356b6b 100644
--- 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
@@ -1,6 +1,6 @@
 # Как понять, когда идти домой
 [//]: # (Version:1.0.0)
-Программирование это деятельность, которая также является культурой. К сожалению, это не та культура, которая ценит психическое и физическое здоровье. По культурно-историческим причинам (например, необходимость работать по ночам на ненагруженных компьютерах) и из-за сильного давления выпустить продукт на рынок программисты традиционно перерабатывают. Не думаю, что стоит верить всему, что рассказывают, но мне кажется, что 60 рабочих часов в неделю это распространенный график, а 50 часов это практически минимум. Это значит, что часто требуется гораздо больше. И это серьезная проблема для хорошего программиста, который отвечает не только за себя, но и за своих коллег. Вы должны понимать, когда идти домой, и иногда, когда предложить своим коллегам пойти домой. Здесь не может быть четких правил для решения проблемы, так же, как не может быть однозначных правил о том, как воспитывать детей. Все люди разные.
+Программирование это деятельность, которая также является культурой. К сожалению, это не та культура, которая ценит психическое и физическое здоровье. По культурно-историческим причинам (например, необходимость работать по ночам на ненагруженных компьютерах) и из-за сильного давления выпустить продукт на рынок программисты традиционно перерабатывают. Не думаю, что стоит верить всему, что рассказывают, но мне кажется, что 60 рабочих часов в неделю это распространенный график, а 50 часов это практически минимум. Это значит, что часто требуется гораздо больше. И это серьезная проблема для хорошего программиста, который отвечает не только за себя, но и за своих коллег. Вы должны понимать, когда идти домой, и иногда, когда предложить пойти домой своим коллегам. Здесь не может быть четких правил для решения проблемы, так же, как не может быть однозначных правил о том, как воспитывать детей. Все люди разные.
 
 Свыше 60 рабочих часов в неделю для меня огромная нагрузка, которую я могу выдержать лишь небольшое время (около недели). Но иногда от меня ожидается именно столько. Не знаю, справедливо ли ожидать от человека 60 часов работы в неделю. Я не уверен, что даже 40 часов это справедливо. Однако, я уверен, что глупо работать так много, чтобы почти не извлекать пользы от дополнительных часов работы. Для меня лично этот предел лежит за 60 часами в неделю. Я лично считаю, что программист должен проявлять благородство и нести эту тяжелую ношу. Однако, быть козлом отпущения - не обязанность программиста. Печальный факт заключается в том, что часто программистов просят быть козлами отпущения, чтобы устроить для кого-то представление, например, когда менеджер пытается впечатлить руководителя. Программисты часто идут на это, потому что они хотят угодить и не умеют говорить "нет". Есть четыре способа защиты от такого отношения:
 
@@ -9,7 +9,7 @@
 - Научитесь говорить "нет", говорите "нет" всей командой, если это необходимо
 - Увольняйтесь, если нет других выходов
 
-Большинство программистов это хорошие программисты, а хорошие программисты хотят сделать как можно больше. Чтобы достичь этого, они должны эффективно управлять своим временем. Между разогревом перед работой и глубоким погружением в нее всегда должно пройти некоторое время. Многие программисты лучше всего работают, когда они располагают длинными, никем не прерываемыми отрезками времени, в течение которых они могут сосредоточиться и погрузиться в работу. Но люди должны еще и спать, и выполнять множество других вещей. Каждый должен найти способ сбалансировать свой рабочий ритм и ритм жизни. Каждый программист должен делать все возможное, чтобы обеспечить себя периодами эффективной работы, например, резервируя определенные дни, когда он может отвлекатьсяя только на самые важные собрания.
+Большинство программистов это хорошие программисты, а хорошие программисты хотят сделать как можно больше. Чтобы достичь этого, они должны эффективно управлять своим временем. Между разогревом перед работой и глубоким погружением в нее всегда должно пройти некоторое время. Многие программисты лучше всего работают, когда они располагают длинными, никем не прерываемыми отрезками времени, в течение которых они могут сосредоточиться и погрузиться в работу. Но люди должны еще и спать, и делать множество других вещей. Каждый должен найти способ сбалансировать свой рабочий ритм и ритм жизни. Каждый программист должен делать все возможное, чтобы обеспечить себя периодами эффективной работы, например, резервируя определенные дни, когда он может отвлекаться только на самые важные собрания.
 
 Поскольку у меня есть дети, я стараюсь проводить вечера с ними. Лучше всего мне подходит очень долгий рабочий день, затем поспать в офисе или рядом (я работаю очень далеко от дома), затем на следующий день уйти домой достаточно рано, чтобы провести время с моими детьми до того, как они отправятся спать. Этот ритм не очень удобен для меня, но это лучшее, что я смог найти. Отправляйтесь домой, если у вас заразная болезнь. Вы должны идти домой, если у вас суицидальные мысли. Вы должны сделать перерыв или идти домой, если вы думаете об убийстве больше, чем несколько секунд. Вы должны отправить домой человека, если он демонстрирует признаки серьезного умственного расстройства или депрессии. Если из-за усталости у вас возникает соблазн быть более нечестным или вредным, чем вам обычно свойственно, сделайте перерыв. Не используйте кокаин или амфетамины для борьбы с усталостью. Не злоупотребляйте кофеином. 
 
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
index cb4c5df..34706ea 100644
--- 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
@@ -4,12 +4,12 @@
 
 Это может стать проблемой для некоторых программистов, у которых нет опыта подобных ситуаций, и чей предыдущий жизненный опыт научил моделям поведения, которые не годятся в рабочем окружении. Трудные люди часто привыкают к разногласиям, и на них меньше, чем на остальных, действует социальное давление идти на компромисс. Главное - уважать их должным образом, что больше, чем захотите вы, и меньше, чем могут захотеть подобные люди.
 
-Программисты вынуждены работать вместе в команде. Когда возникает разногласие, его надо как-то решить, его нельзя игнорировать слишком долго. Трудные люди часто бывают чрезвычайно умны, и им есть, что полезного высказать. Очень важно слушать их и понимать без предубеждения, которое может вызывать их личность. Трудности в общении часто становятся источником разногласий, но их можно преодолеть терпением. Старайтесь держать общение в спокойном и вежливом тоне, не поддавайтесь на уловки увеличить конфликт. После того, как вы потратите разумное время на попытки понять оппонента, примите решение.
+Программисты вынуждены работать вместе в команде. Когда возникает конфликт, его надо как-то решить, его нельзя игнорировать слишком долго. Трудные люди часто бывают чрезвычайно умны, и им есть, что полезного высказать. Очень важно слушать их и понимать без предубеждения, которое может вызывать их личность. Трудности в общении часто становятся источником разногласий, но их можно преодолеть терпением. Старайтесь держать общение в спокойном и вежливом тоне, не поддавайтесь на уловки увеличить конфликт. После того, как вы потратите разумное время на попытки понять оппонента, примите решение.
 
 Не позволяйте грубой силе заставлять вас делать то, с чем вы несогласны. Если вы лидер команды, принимайте то решение, которое вы считаете лучшим. Не принимайте решения исходя из личных причин, какими они бы ни были. Будьте готовы объяснить свое решение. Если вы в команде с трудным человеком, не позволяйте, чтобы решение лидера было вызвано любым личным мнением. Если решение не в вашу пользу, примите его.
 
-Трудные люди меняются и становятся лучше в общении. Я сам был свидетелем этому, но такое случается редко. Как бы то ни было, у всех бывают периоды взлетов и падений.
+Трудные люди меняются и становятся лучше в общении. Я сам был тому свидетелем, но такое случается редко. Как бы то ни было, у всех бывают периоды взлетов и падений.
 
 Один из самых больших вызовов, встречающихся каждому программисту, особенно лидерам, это держать трудного человека вовлеченным в общую работу. Такие люди больше склонны уклоняться от нее и пассивно сопротивляться.
 
-Следующее: [Разработчик среднего уровня](../../2-Intermediate)
+Следующее: [Программист среднего уровня](../../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
index 9d6b380..7047cff 100644
--- 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
@@ -2,12 +2,12 @@
 [//]: # (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
index ce013c8..af8c34e 100644
--- 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
@@ -3,7 +3,7 @@
 Современное программное обеспечение имеет тенденцию зависеть от множества компонентов, которые могут не быть под вашим непосредственным контролем. Это повышает продуктивность за счет синергии и повторного использования. Однако, каждый такой компонент приносит с собой некоторые проблемы:
 
 - Как вы будете исправлять баги в компоненте?
-- Ограничивает ли компонент вас использовать определенное аппаратное обеспечение или систему?
+- Вынуждает ли компонент вас использовать определенное аппаратное обеспечение или систему?
 - Что вы будете делать, если компонент полностью откажет?
 
 Всегда лучше инкапсулировать компонент таким образом, чтобы он был отделен от основной системы, и его можно было легко заменить. Если компонент покажет свою неработоспособность, вы замените его на другой или напишите свой собственный. Инкапсуляция не улучшает переносимость, но делает переписывание кода проще, что почти также здорово.
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
index e4b3eaf..5bb0c16 100644
--- 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
@@ -2,12 +2,12 @@
 [//]: # (Version:1.0.0)
 Предпринимательская компания или проект, которые пытаются добиться чего-то с помощью программного отбеспечения, постоянно вынуждены принимать решения типа *покупать программу или писать свою*. Это выражение неудачно по двум причинам. Оно как будто игнорирует существование свободного и открытого программного обеспечения, которое необязательно покупать. И, что более важно, его стоит переформулировать в *приобрести и интегрировать или написать свое и интегрировать*, потому что затраты на интеграцию обязательны надо учесть. Такие решения требуют редкого сочетания деловой, управленческой и инженерной смекалки. 
 
-- Насколько полно ваши требования совпадают с требованиями под которые было создано программное обеспечение, рассматривающееся к покупке?
+- Насколько полно ваши требования совпадают с требованиями, под которые было создано программное обеспечение, рассматривающееся к покупке?
 - Какая часть программы, которую вы можете купить, действительно вам нужна?
 - Каковы затраты на оценку интеграции?
 - Каковы затраты на интеграцию?
 - Приобретение этой программы увеличит или уменьшит затраты на долгосрочную поддержку?
-- Если вы напишите свое программное обеспечение под свои цели, поставить ли это вашу компанию в нежелательную бизнес-ситуацию?
+- Если вы напишите свое программное обеспечение под свои цели, поставит ли это вашу компанию в нежелательную бизнес-ситуацию?
 
 Следует как минимум дважды хорошо подумать, прежде чем начинать создавать программу, достаточно большую, чтобы стать основой чьего-то бизнеса. Подобные идеи часто предлагают яркие и оптимистичные люди, которые могут внести большой вклад в вашу команду. Если их идея окажется убедительной, возможно вы захотите изменить свой бизнес-план. Но не инвестируйте необдуманно в решение, которое больше, чем ваш собственный бизнес.
 
diff --git a/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md b/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md
index e1a828b..8395deb 100644
--- a/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md
+++ b/ru/2-Intermediate/Judgment/05-How-to-Grow-Professionally.md
@@ -1,6 +1,6 @@
 # Как расти профессионально
 [//]: # (Version:1.0.0)
-Возьмите на себя роль, превышающую вашу ответственность. Выполняйте роль, которую вы хотите. Выражайте признательность и благодарность людяи за их вклад в успех организации и за помощь лично вам.
+Возьмите на себя роль, превышающую вашу ответственность. Выполняйте ту роль, которую вы хотите, чтобы вам поручили. Выражайте признательность и благодарность людяи за их вклад в успех организации и за помощь лично вам.
 
 Если вы хотите стать лидером команды, способствуйте формированию общего согласия в работе. Если вы хотите стать менеджером, возьмите ответственность за график. Обычно вы спокойно можете сделать это, работая с лидером или менеджером, так как это снимет с них большую нагрузку. Если это слишком сложная задача для начала, возьмите на себя обязанности поменьше.
 
diff --git a/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md b/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md
index aa222a1..40381a3 100644
--- a/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md
+++ b/ru/2-Intermediate/Judgment/06-How-to-Evaluate-Interviewees.md
@@ -6,7 +6,7 @@
 
 Как минимум, вам стоит выделить два часа на устное собеседование по техническим навыкам каждого кандидата. С опытом вы научитесь быстро выяснять, что они знают, и быстро проводить границу с тем, чего они не знают. Кандидаты с уважением относятся к этому. Мне доводилось несколько раз слышать от кандидатов, что качество собеседования было одной из причин выбрать компанию. Хорошие профессионалы хотят, чтобы их нанимали за навыки, а не за последнее место работы, колледж или другие несущественные характеристики.
 
-При собеседовании также стоит оценивать способность кандидата учиться, что гораздо важнее того, что он уже знает. Также стоит обратить внимание на признаки трудного человека. Их можно распознать, разбирая заметки о собеседовании, но во время интервью быть трудно их заметить. Умение кандидата общаться и взаимодействовать с людьми гораздо важнее знания новейшего языка программирования.
+При собеседовании также стоит оценивать способность кандидата учиться, она гораздо важнее того, что он уже знает. Также стоит обратить внимание на признаки трудного человека. Их можно распознать, разбирая заметки о собеседовании, но во время интервью может быть трудно их заметить. Умение кандидата общаться и взаимодействовать с людьми гораздо важнее знания новейшего языка программирования.
 
 Один из читателей рекомендует давать кандидатам тестовое задание на дом. Преимущество этого теста в том, что он позволяет выявить кандидата, который хорошо презентует себя, но не может писать код. Таких людей немало. Я лично не пробовал этот метод, но он кажется разумным.
 
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
index 9f97e8a..416e5d7 100644
--- 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
@@ -1,6 +1,6 @@
 # Как понять, когда применять высокие технологии
 [//]: # (Version:1.0.0)
-Существует свод знаний об алгоритмах, структурах данных, математике и других вещах, о которых программисты знают, но довольно редко используют в работе. На практике эти замечательные вещи слишком сложны и, как правило, ненужны. Нет смысла улучшать алгоритм, когда большая часть времени тратится на неэффективный запрос к базе данных. Досадная часть программирования заключается в том, чтобы заставить системы общаться друг с другом и использовать очень простые структуры данных для построения красивого пользовательского интерфейса. 
+Существует свод знаний об алгоритмах, структурах данных, математике и других вещах, о которых программисты знают, но довольно редко используют в работе. На практике эти замечательные вещи слишком сложны и, как правило, ненужны. Нет смысла улучшать алгоритм, когда большая часть времени тратится на неэффективный запрос к базе данных. Изрядная часть программирования заключается в том, чтобы заставить системы общаться друг с другом и использовать очень простые структуры данных для построения красивого пользовательского интерфейса. 
 
 Когда следует применять высокие технологии? Когда следует открывать серьезные книги, чтобы найти альтернативу обычному алгоритму? Иногда полезно это делать, но такие технологии следует тщательно оценивать.
 
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
index d2b3c70..d6e987b 100644
--- 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
@@ -16,4 +16,4 @@
 
 Иногда неинженеры из доброты и стремления принять правильное решение предлагают вещи, которые по их мнению сделают нашу жизнь проще, тогда как в действительности существует решение гораздо лучше, которое можно найти, объединив взгляд неинженера с вашей технической экспертизой. Я лично люблю экстремальное программирование, поскольку оно решает эту проблему неэффективности. Быстрое согласование оценки с идеей упрощает поиск новой идеи, которая представляет собой лучшее сочетание затрат и выгод.
 
-Следующее: [Продвинутые навыки](../../3-Advanced)
+Следующее: [Продвинутый программист](../../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
index 733e631..b71b698 100644
--- a/ru/2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md
+++ b/ru/2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md
@@ -10,6 +10,6 @@
 - Искать возможности применить новые технологии, языки программирования и техники
 - Стараться либо научить кого-то, либо научиться самому в каждом проекте, как был мал он ни был
 
-Наконец, если возможно, старайтесь измерять свой вклад в работу в том, что для вас персонально имеет значение. Например, когда я работаю над багами, общее число уже исправленных мною багов мне совершенно неинтересно, ведь оно не зависит от общего числа багов, которые все еще возможно существуют. Кроме того, это число отражает мой вклад в самом малом из всех возможных ракурсов. Но соотносить каждый исправленный баг со счастливым клиентом для меня, наоборот, очень ценно, и служит мотивацией в работе.
+Наконец, если возможно, старайтесь измерять свой вклад в работу в том, что для вас персонально имеет значение. Например, когда я работаю над багами, число уже исправленных мною багов мне совершенно неинтересно, ведь оно не зависит от общего числа багов, которые все еще возможно существуют. Кроме того, это число отражает мой вклад в самом малом из всех возможных ракурсов. Но соотносить каждый исправленный баг со счастливым клиентом для меня, наоборот, очень ценно, и служит мотивацией в работе.
 
 Следующее: [Как заслужить доверие](02-How-to-be-Widely-Trusted.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
index b81cebf..c326233 100644
--- 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
@@ -10,6 +10,6 @@
 
 Улучшение компромисса между объемом памяти и скоростью вычислений часто может привести к кардинальному изменению одного из этих параметров. Перед тем, как начать работу, спросите себя, действительно ли то, что вы собираетесь улучшить, нуждается в этом. Работать с алгоритмами интересно, но не забывайте, что улучшение того, что не является проблемой, не принесет заметной разницы в программу и увеличит нагрузку на тестирование.
 
-В современных компьютерах память кажется дешевым ресурсом, потому что в отличие от процессорного времени вы не видите, как она используется, пока не упретесь в потолок. Но тогда сбой может оказаться катастрофическим. Существуют и другие скрытые затраты на использование памяти, такие как ваш эффект на сторонние программы, который должен быть постоянным, и время на ее выделение и освобождение. Обдумайте эти моменты перед тем, как вы пожертвуете памятью ради ускорения.
+В современных компьютерах память кажется дешевым ресурсом, потому что в отличие от процессорного времени вы не видите, как она используется, пока не исчерпаете целиком. Но тогда сбой может оказаться катастрофическим. Существуют и другие скрытые затраты на использование памяти, такие как ваш эффект на сторонние программы, который должен быть постоянным, и время на ее выделение и освобождение. Обдумайте эти моменты перед тем, как вы пожертвуете памятью ради ускорения.
 
 Следующее: [Как проводить стресс-тестирование](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
index ef47144..5a02664 100644
--- a/ru/2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md
+++ b/ru/2-Intermediate/Personal-Skills/04-How-to-Stress-Test.md
@@ -4,10 +4,10 @@
 
 План для стресс-тестирования следует разрабатывать на ранних стадиях проекта, так как часто он помогает в точности прояснить, что именно ожидается от системы. Две секунды на запрос веб-страницы это позорный провал или оглушительный успех? Достаточно ли 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
index ad758d3..7361e3b 100644
--- 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
@@ -1,6 +1,6 @@
 # Как балансировать краткость и абстракцию
 [//]: # (Version:1.0.0)
-Абстракция - это ключ к программированию. Следует тщательно выбирать, насколько абстрактны вам следует быть. Начинающие программисты в своем энтузиазме часто создают больше абстракций, чем в действительности необходимо. Один из признаков такой ситуации: вы создаете классы, которые почти не содержат код и служат только для абстрактного представления чего-то. Привлекательность этого подхода понятна, но ценность краткости кода надо соизмерять с ценностью абстракции. Иногда можно видеть ошибку, совершаюмую восторженными идеалистами: на старте проекта создается множество классов, которые кажутся восхитительно абстрактными, и кажется, что они справятся со всеми ситуациями, которые только могут возникнуть. По мере продвижения проекта и наступления усталости код становится беспорядочным. Тела функций становятся больше, чем они должны быть. Пустые классы это еще и бремя документирования, которое часто игнорируется под давлением. Итоговый результат был бы лучше, если бы энергия, потраченная на абстракцию, была бы потрачена на то, чтобы сохранить код кратким и простым. Это разновидность *спекулятивного программирования*. На эту тему я очень рекомендую прочесть статью Пола Грэхема ['Succinctness is Power'](http://www.paulgraham.com/power.html).
+Абстракция - это основа программирования. Следует тщательно выбирать, насколько абстрактным вам следует быть. Начинающие программисты в своем энтузиазме часто создают больше абстракций, чем в действительности необходимо. Один из признаков такой ситуации: вы создаете классы, которые почти не содержат код и служат только для абстрактного представления чего-то. Привлекательность этого подхода понятна, но ценность краткости кода надо соизмерять с ценностью абстракции. Иногда можно видеть ошибку, совершаюмую восторженными идеалистами: на старте проекта создается множество классов, которые кажутся восхитительно абстрактными, и кажется, что они справятся со всеми ситуациями, которые только могут возникнуть. По мере продвижения проекта и наступления усталости код становится беспорядочным. Тела функций становятся больше, чем они должны быть. Пустые классы это еще и бремя документирования, которое часто игнорируется под давлением. Итоговый результат был бы лучше, если бы энергия, потраченная на абстракцию, была бы потрачена на то, чтобы сохранить код кратким и простым. Это разновидность *спекулятивного программирования*. На эту тему я очень рекомендую прочесть статью Пола Грэхема ['Succinctness is Power'](http://www.paulgraham.com/power.html).
 
 Существует определенные догмы, связанные с такими полезными техниками как *сокрытие информации* и *объектно-ориентированное программирование*, применение которых иногда заходит слишком далеко. Они позволяют писать код более абстрактно и предвидеть возможные в нем изменения. Однако, я лично считаю, что не следует писать слишком много спекулятивного кода. Например, принято прятать целочисленные переменные в объектах за публичными методами класса, так что сама переменная не видна, а доступен только интерфейс к ней. Это позволяет изменить реализацию этой переменной без изменения вызывающего эти методы кода. Возможно, это подходит для разработки библиотек, где необходимо предоставить устойчивый API. Но я не думаю, что преимущества этого подхода перевешивают избыток кода, потраченного на него, особенно, когда моя команда владеет вызывающим кодом и может переписать как его, так и вызываемый код. Четыре или пять строк кода - это большая цена за такое умозрительное преимущество.
 
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
index 06e774a..d7cd842 100644
--- 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
@@ -6,7 +6,7 @@
 
 Хороший учитель не заменит практику, но гораздо лучше книги. Что вы можете предложить потенциальному учителю в обмен на его знания? Как минимум, вы можете предложить усердно учиться, так что время этого человека не будет потрачено впустую.
 
-Постарайтесь уговорить своего босса оплатить вам формальное обучение, но помните, что чаще всего гораздо полезнее потратить то же время на свободную игру с тем навыком, который вы хотите освоить. Однако, в нашем несовершенном мире легче попросить об обучении, чем о времени на свободное полуизучение-полуигру, хоть множество обучений и сводятся ко сну на лекциях в ожидании обеда. 
+Постарайтесь уговорить своего босса оплатить вам формальное обучение, но помните, что чаще всего гораздо полезнее потратить то же время на свободную игру с тем навыком, который вы хотите освоить. Однако, в нашем несовершенном мире легче попросить об обучении, чем о времени на свободное полуизучение-полуигру, хоть множество формальных обучений и сводятся ко сну на лекциях в ожидании обеда. 
 
 Если вы руководитель, постарайтесь понять, как учатся ваши подчиненные и помогите им, назначая им такие проекты и задания, которые им по плечу и одновременно позволят развить интересные им навыки. Не забывайте, что самые важные навыки программиста вовсе не технические. Дайте своей команде время экспериментировать и практикуйте в команде смелость, честность и взаимодействие.
 
diff --git a/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md b/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md
index 6609d44..e624185 100644
--- a/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md
+++ b/ru/2-Intermediate/Personal-Skills/09-Communication-Languages.md
@@ -2,10 +2,10 @@
 [//]: # (Version:1.0.0)
 Существуют языки, то есть формально определенные синтаксические системы, которые являются не языками программирования, а языками взаимодействия систем, создаными специально для облегчения взаимодействия через стандартизацию. В 2003 году самые важные из них это UML, XML и SQL. Вы должны быть знакомы с каждым из них, чтобы уметь использовать их и понимать, когда их следует применять.
 
-UML - это обширная формальная система для создания схем и диаграмм, описывающих архитектуру. Ее прелесть в том, что она одновременно и визуальна, и формальна, и способна передать огромное количество информации, если автор и его аудитория понимают UML. Вам следует знать UML, потому что иногда архитектуру описывают с ее помощью. Существуют очень полезные инструменты для создания проессионально выглядящих схем UML. Во многих случаях, UML слишком строгая и формальная система, и я иногда находил, что для архитектурных схем проще использовать стрелки и прямоугольники. Но я уверен, что изучение UML полезно так же, как и изучение латыни.
+UML - это обширная формальная система для создания схем и диаграмм, описывающих архитектуру. Ее прелесть в том, что она одновременно и визуальна, и формальна, и способна передать огромное количество информации, если автор и его аудитория понимают UML. Вам следует знать UML, потому что иногда архитектуру описывают с ее помощью. Существуют очень полезные инструменты для создания профессионально выглядящих схем UML. Во многих случаях, UML слишком строгая и формальная система, и я иногда находил, что для архитектурных схем проще использовать стрелки и прямоугольники. Но я уверен, что изучение UML полезно так же, как и изучение латыни.
 
-XML - это стандарт для определения новых стандартов. Это не решение проблем передачи данных, хотя иногда вы увидите, что XML представляют именно так. Но скорее, это средство автоматизации самой скучной работы по обмену данных, а именно структурное представление данных в линейной последовательности и обратный синтаксический анализ этого последовательности в структуру данных. UML предоставляет неплохую проверку типов и правильности данных, хотя это лишь небольшая часть того, что вам понадобится в работе.
+XML - это стандарт для определения новых стандартов. Это не решение проблем передачи данных, хотя иногда вы увидите, что XML представляют именно так. Но скорее, это средство автоматизации самой скучной работы по обмену данных, а именно структурное представление данных в линейной последовательности и обратное преобразование этой последовательности в структуру данных. UML предоставляет неплохую проверку типов и правильности данных, хотя это лишь небольшая часть того, что вам понадобится в работе.
 
-SQL - это очень мощный и богатый язык запросов и манипулирования данными. Это не совсем язык программирования. У него есть много вариаций, в основном зависимых от конкретного продукта, который его использует. Они не так важны как стандартное ядро языка. SQL - это основа всех реляционных баз данных. Вы можете не работать в области, где требуется понимание такого типа баз данных, но вам все равно следует иметь базовое представление о них и о синтаксисе и назначении SQL.
+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
index 6233a81..f93871e 100644
--- a/ru/2-Intermediate/Personal-Skills/10-Heavy-Tools.md
+++ b/ru/2-Intermediate/Personal-Skills/10-Heavy-Tools.md
@@ -9,6 +9,6 @@
 - Математические бибилиотеки
 - 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
index 8bc7d0d..fd83cb3 100644
--- a/ru/2-Intermediate/Personal-Skills/11-How-to-analyze-data.md
+++ b/ru/2-Intermediate/Personal-Skills/11-How-to-analyze-data.md
@@ -6,6 +6,8 @@
 
 Неважно, на каком этапе вы начинаете работать с данными, они всегда остаются главной заботой в хорошо спроектированном приложении. Если вы внимательно посмотрите, как бизнес-аналитик извлекает требования из запросов клиентов, то поймете, что данные играют фундаментальную роль. Аналитик создает так называемые диаграммы потоков данных, где указаны источники данных, и обозначен поток информации. Определив, какие данные будут частью системы, архитектор начнет формировать источники данных с точки зрения баз данных, протоколов обмена данными и форматов файлов. После этого задачу можно передавать программисту. Но процесс на этом не заканчивается, потому что вы (программист) даже после подобной тщательной обработки данных должны проанализировать их, чтобы выполнить задачу оптимальным способом. В основе вашей работы лежит идея Никлауса Вирта, создателя нескольких языков программирования. "Алгоритмы + Структуры данных = Программы". Алгоритм никогда не существует отдельно, делая что-то сам по себе. Каждый алгоритм обязательно взаимодействует как минимум с какой-то частью данных.
 
-Таким образом, раз алгоритмы не функционируют в вакууме, вы должны анализировать и данные, которые кто-то передал вам для разработки, и данные, которые надо воплотить в коде. Вот простой пример. Вы пишите программу для поиска книг в библиотеки. Согласно вашей спецификации пользователь может выбрать книги по сочетанию жанра, автора, названию, издателю, году издания и числу страниц. Конечная цель вашего модуля - создать корректный запрос SQL для отправки в базе данных. Основываясь на этих требованиях, вы можете выбирать варианты. Можно проверять каждый параметр по очереди, используя оператор "switch" или несколько последовательных "if". Можно создать массив параметров и проверять, есть ли в нем каждый параметр. Можно создать (или использовать) абстрактный объект для контроля данных, от которого унаследовать конкретные параметры и связать их с механизмом управления событиями. Если в требованиях есть есть настройка производительности запроса через проверку параметров в определенном порядке, то вы можете рассмотреть применение дерева компонентов для построения SQL-запроса. Как видно, выбор алгоритма зависит от данных, которые вы решите использовать или создать. Подобные решения часто отделяют эффективные алгоритмы от провальных. Однако, эффективность здесь не единственная проблема. Вы можете создать десяток переменных и сделать их максимально эффективными. Но такой код не будет легко поддерживаемым. Возможно, выбор подходящего контейнера для хранения всех ваших переменных поможет сохранить ту же скорость алгоритма и вдобавок сделает код более понятным для ваших коллег, когда они вернутся к нему в следующем году. Более того, хорошо выбранная структура данных позволит им легко расширить функциональность вашего кода без переписывания уже имеющихся частей. В конечном счете ваш выбор данных определяет, как долго просуществует ваш код. Еще один пример для размышлений. Преположим, у вас задача найти все слова в словаре с тремя и более анаграммами. При этом анаграмма должна быть другим словом в этом же словаре. Если вы будете думать об этой задаче, как о задаче на вычисление, то вы придете к бесконечным вычислениям в попытке вычислить все комбинации анаграмм для каждого слова и сравнить их со всеми остальными словами в словаре. Однако, анализируя исходные данные, вы можете заметить, что каждое слово можно представить как запись с самим словом и сортированным массивом из его букв в виде ID. С этим знанием нахождение анаграмм превращается в сортировку этого массива и нахождение слов с аналогичным ID. Прямой алгоритм может потребовать несколько дней на выполнение, тогда как более хитрый выполняется за несколько секунд. Вспомните этот пример, когда в следующий раз вы стокнетесь с неразрешимой проблемой.
+Таким образом, раз алгоритмы не функционируют в вакууме, вы должны анализировать и данные, которые кто-то передал вам для разработки, и данные, которые надо воплотить в коде. Вот простой пример. Вы пишите программу для поиска книг в библиотеки. Согласно вашей спецификации пользователь может выбрать книги по сочетанию жанра, автора, названию, издателю, году издания и числу страниц. Конечная цель вашего модуля - создать корректный запрос 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
index ea278b1..537a370 100644
--- a/ru/2-Intermediate/README.md
+++ b/ru/2-Intermediate/README.md
@@ -1,4 +1,4 @@
-# 2. Разработчик среднего уровня
+# 2. Программист среднего уровня
 [//]: # (Version:1.0.0)
 - Личные навыки
 	- [Как сохранять мотивацию](Personal-Skills/01-How-to-Stay-Motivated.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
index 28bb771..377ded9 100644
--- 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
@@ -1,8 +1,8 @@
 # Как управлять временем разработки
 [//]: # (Version:1.0.0)
-Чтобы управлять временем разработки, поддерживайте четкий и актуальный проектный план. Проектный план - это оценка временных затрат, график, набор промежуточных этапов для отслеживания прогресса и распределение времени вашей команды на каждое задание. Он также должен включать другие вещи, о которых важно помнить, такие как встречи с командой тестирования, подготовка документации, заказ рабочего оборудования. Если вы работаете в команде, проектный план должен быть согласованным решением, как на старте проекта, там и по его ходу.
+Чтобы управлять временем разработки, поддерживайте четкий и актуальный проектный план. Проектный план - это оценка временных затрат, график, набор промежуточных этапов для отслеживания прогресса и распределение времени вашей команды на каждое задание. Он также должен включать другие вещи, о которых важно помнить: встречи с командой тестирования, подготовка документации, заказ рабочего оборудования. Если вы работаете в команде, проектный план должен быть согласованным решением, как на старте проекта, там и по его ходу.
 
-Проектный план служит для принятия решений, а не для демострации того, насколько вы организованы. Если он слишком подробный или неактуальный, к нему бесполезно обращаться для принятия решений. В реальности, все эти решения касаются отдельных людей. План и ваша экспертиза позволять вам понять, следует ли передать часть задач одного члена команды другому. Этапы проекта отмечают его прогресс. Если вы используете модный современный трекер задач для планирования проекта, не поддавайтесь соблазну сходу расписать большой предварительный план. Лучше используйте трекер, чтобы поддерживать емкость и актуальность задач.
+Проектный план служит для принятия решений, а не для демострации того, насколько вы организованы. Если он слишком подробный или неактуальный, к нему бесполезно обращаться для принятия решений. В реальности, все эти решения касаются отдельных людей. План и ваша экспертиза позволят вам понять, следует ли передать часть задач одного члена команды другому. Этапы проекта отмечают его прогресс. Если вы используете модный современный трекер задач для планирования проекта, не поддавайтесь соблазну сходу расписать большой предварительный план. Лучше используйте трекер, чтобы поддерживать емкость и актуальность задач.
 
 Если вы не успеваете выполнить этап, следует немедленно предпринять что-то, как минимум проинформировать босса о том, что запланированное завершение проекта сместится на некоторое время. Стоило бы начать с того, что оценка и расписание никогда не будут идеальны, но они дают иллюзию, что вы сможете наверстать пропущенные дни в конце проекта. Может быть. Но так же вероятно, что вы недооценили эту часть проекта, как и то, что вы ее переоценили. Так что запланированное завершение проекта уже сместилось, нравится вам это или нет.
 
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
index 04723a5..1c62c8b 100644
--- 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
@@ -6,6 +6,6 @@
 
 Если стороннее программное обеспечение все же существует, оно по-прежнему несет с собой риски, но по крайней мере эти риски можно преодолеть. Если вы предполагаете использование сторонних программ, уже на ранней стадии проекта следует посвятить время на их оценку. Никому не понравится услышать, что потребуется две недели, а то и два месяца на оценку пригодности всех трех сторонних программ, но это то, что надо сделать как можно раньше. Стоимость интеграции нельзя оценить без надлежащей оценки задействованных сторонних программ.
 
-Понимание пригодности существующих сторонних программ для конкретных задач - это очень отраслевое знание. Оно субъективно, и в основном им владеют эксперты. Вы можете сэкономить кучу времени, если сможете найти экспертов. Часто проект настолько зависит от стороннего программного обеспечения, что если интеграция провалится, то провалится весь проект. Выразите все подобные риски в проектном плане. Постарайтесь иметь план на случай непредвиденных обстоятельств, например, альтернативные сторонние программы или возможность реализовать часть их функциональности самостоятельно. Никогда не вносите в график еще не выпущенное стороннее прграммное обеспечение.
+Понимание пригодности существующих сторонних программ для конкретных задач - это очень отраслевое знание. Оно субъективно, и в основном им владеют эксперты. Вы можете сэкономить кучу времени, если сможете их найти. Часто проект настолько зависит от стороннего программного обеспечения, что если интеграция провалится, то провалится весь проект. Выразите все подобные риски в проектном плане. Постарайтесь иметь план на случай непредвиденных обстоятельств, например, альтернативные сторонние программы или возможность реализовать часть их функциональности самостоятельно. Никогда не вносите в график еще не выпущенное стороннее программное обеспечение.
 
 Следующее: [Как руководить консультантами](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
index 8e5c43b..9320741 100644
--- a/ru/2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md
+++ b/ru/2-Intermediate/Team-Skills/03-How-to-Manage-Consultants.md
@@ -1,6 +1,6 @@
 # Как руководить консультантами
 [//]: # (Version:1.0.0)
-Используйте консультантов, но не полагайтесь на них. Эти замечательные люди заслуживают всяческого уважения. Поскольку они наблюдали множество проектов, они зачастую знают больше о специфических технологиях или даже техниках программирования, чем вы. Лучший способ использовать их как штатных преподавателей, которые могут научить на собственном примере.
+Используйте консультантов, но не полагайтесь на них. Эти замечательные люди заслуживают всяческого уважения. Поскольку они наблюдали множество проектов, они зачастую знают больше о специфических технологиях или даже техниках программирования, чем вы. Лучший способ использовать их - в качестве штатных преподавателей, которые могут научить на собственном примере.
 
 Однако, обычно консультанты не могут стать частью команды в том смысле, что и обычные сотрудники, хотя бы потому, что у вас может не хватить времени изучить их сильные и слабые стороны. Их финансовые обязательства гораздо ниже. Они могут легко уйти. Они меньше выигрывают, если компания в целом процветает. Некоторые из них будут хороши, некоторые средними, некоторые плохими консультантами. Поскольку ваш выбор консультантов будет не так тщателен, как подбор сотрудников, чаще вы будете встречать плохих.
 
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
index 2df240f..d8ad7c1 100644
--- 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
@@ -1,6 +1,6 @@
 # Как честно выражать несогласие
 [//]: # (Version:1.0.0)
-Несогласие это прекрасная возможность принять хорошее решение, но его следует выражать аккуратно. Надеюсь, обычно вы спокойно выражаете свою точку зрения, вас внимательно слушают, а затем принимается решение. В этом случае больше нечего сказать, и вам только остается решить, поддерживаете ли вы решение, даже если вы с ним несогласны. Если вы можете поддержать решение несмотря на свое несогласие, скажите об этом. Так вы покажете своб ценность: вы независимы, имеете свое мнение и не идете на поводу, но одновременно уважаете принятое решение и всю команду.
+Несогласие это прекрасная возможность принять хорошее решение, но его следует выражать аккуратно. Надеюсь, обычно вы спокойно выражаете свою точку зрения, вас внимательно слушают, а затем принимается решение. В этом случае больше нечего сказать, и вам только остается решить, поддерживать ли решение несмотря на свое несогласие с ним. Если вы все же можете поддержать решение, с которым вы несогласны, скажите об этом. Так вы покажете свою ценность: вы независимы, имеете свое мнение и не идете на поводу, но одновременно уважаете принятое решение и всю команду.
 
 Иногда решение, с которым вы несогласны, принимается потому, что те, кто его принимает, не имели возможности полностью оценить ваше мнение. В этом случае, исходя из пользы для компании или команды вам стоит прикинуть, поднимать ли вопрос. Если это небольшая на ваш взгляд ошибка, то, возможно, не стоит пересматривать решение. Если же речь идет о серьезной ошибке, то стоит выдвинуть возражения.
 
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
index 59996bb..519eefd 100644
--- 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
@@ -1,6 +1,6 @@
 # Как справляться с давлением графика
 [//]: # (Version:1.0.0)
-Давление выхода на рынок - это необходимость быстро выпустить хороший продукт. Это хорошо, поскольку отражает финансовую действительность и до некоторой степени это полезное давление. Давление графика - это давление выпустить что-то быстрее, чем это возможно, и подобное давление опустошает, оно нездоровое и встречается слишком часто.
+Давление выхода на рынок - это необходимость быстро выпустить хороший продукт. Это хорошо, поскольку отражает финансовую действительность, и до некоторой степени это полезное давление. Давление графика - это давление выпустить что-то быстрее, чем это возможно, и подобное давление опустошает, оно нездоровое и встречается слишком часто.
 
 Давление графика существует по нескольким причинам. Люди, дающие задания программистам не до конца ценят нашу рабочую этику и любовь к профессии. Возможно, поскольку они проецируют собственное поведение на нас, они ожидают, что просьба сделать задачу быстрее заставит нас работать усерднее. Возможно, это так, но эффект от такой просьбы очень мал, а ущерб велик. Вдобавок, они не понимают, что в действительности значит разработать программное обеспечение. Они не могут этого понять, не могут разработать систему самостоятельно, поэтому единственное, что им остается, это наблюдать за давлением выхода на рынок и подталкивать программистов.
 
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
index bc5528c..b5b9cac 100644
--- 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
@@ -6,7 +6,7 @@
 - У пользователей есть своя работа, они будут скорее думать о небольших доработках в вашем продукте, чем о больших улучшениях
 - Мнение одного конкретного пользователя не может представлять общее мнение всех пользователей вашего продукта
 
-Ваша обязанность - дать пользователям не то, что они говорят, что хотят, а то, что они хотят в дествительности. Однако, лучше всего это сформулировать и получить от ваших пользователей ответ, что ваше предложение действительно отвечает их реальных желаниям. Хотя у пользователей может не хватит полного понимания всей картины для ответа. Ваша уверенность в собственных идеях на этот счет должна варьироваться. Следует одинаково опасаться как самоуверенности, так и ложной скромности, когда речь идет о нуждах вашего пользователя. Программисты нацелены на проектирование и создание. Исследователи рынка нацелены на выявление нужд потребителей. Эти два типа людей или два типа мышления в одном человеке, гармонично работая в связке, дают наилучший шанс сформировать правильное понимание пользователя.
+Ваша обязанность - дать пользователям не то, что они говорят, что хотят, а то, что они хотят в действительности. Однако, лучше всего это сформулировать и получить от ваших пользователей ответ, что ваше предложение действительно отвечает их реальным желаниям. Хотя у пользователей может не хватит полного понимания всей картины для ответа. Ваша уверенность в собственных идеях на этот счет должна варьироваться. Следует одинаково опасаться как самоуверенности, так и ложной скромности, когда речь идет о нуждах вашего пользователя. Программисты нацелены на проектирование и создание. Исследователи рынка нацелены на выявление нужд потребителей. Эти два типа людей или два типа мышления в одном человеке, гармонично работая в связке, дают наилучший шанс сформировать правильное понимание пользователя.
 
 Чем больше времени вы проведете с пользователями, тем лучше вы сможете понять, что будет лучшим для них. Вам стоит проверять свои идеи на пользователях так часто, насколько это вообще возможно. Вам стоит обедать с ними, если это возможно.
 
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
index d646634..1809c04 100644
--- 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
@@ -8,6 +8,6 @@
 
 Если вы чуствуете, что вас обошли с повышением, поговорите с боссом об этом. Спросите его в явном виде, что вы должны делать, чтобы получить повышение, и постарайтесь сделать это. Это кажется банальным, но часто ваше представление того, что вам надо делать, отличается от представления вашего босса. Кроме того, такой разговор в некотором смысле подтолкнет вашего босса.
 
-Большинство программистов скорее всего имеют преувеличенное представление о собственных способностях, в конце концов, мы все не можем входить в 10% лучших программистов. Однако, я встречал и людей, которые были очень сильно недооценены. Нельзя ожидать, что оценка каждого будет на 100% совпадать с реальностью, но я думаю, что в общем люди довольно справедливо себя оценивают. С одной оговоркой: вас нельзя справедливо оценить без видимости вашей работы. Иногда из-за обстоятельств или личных качеств кто-то будет не настолько сильно заметен. Работа из дома или географически удаленно от вашей команды и босса делает это особенно трудным. 
+Большинство программистов скорее всего имеют преувеличенное представление о собственных способностях. В конце концов, мы все не можем входить в 10% лучших программистов. Однако, я встречал и людей, которые были очень сильно недооценены. Нельзя ожидать, что оценка каждого будет на 100% совпадать с реальностью, но я думаю, что в общем люди довольно справедливо себя оценивают. С одной оговоркой: вас нельзя справедливо оценить без видимости вашей работы. Иногда из-за обстоятельств или личных качеств кто-то будет не настолько сильно заметен. Работа из дома или географически удаленно от вашей команды и босса делает это особенно трудным. 
 
 Следующее: [Управление командой. Как развивать таланты](../Serving-Your-Team/01-How-to-Develop-Talent.md)
diff --git a/ru/3-Advanced/README.md b/ru/3-Advanced/README.md
index 3e314ce..c0b4f7b 100644
--- a/ru/3-Advanced/README.md
+++ b/ru/3-Advanced/README.md
@@ -1,6 +1,6 @@
-# 3. Advanced
+# 3. Продвинутый программист
 [//]: # (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)
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
index 950aa56..c4bb3ce 100644
--- 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
@@ -1,6 +1,6 @@
 # Как развивать таланты
 
-Ницше преувеличил, когда сказал [Stronger]:
+Ницше преувеличил, когда сказал[Stronger]:
 
 > Всё, что меня не убивает, делает меня сильнее.
 
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
index 01708c6..8f23481 100644
--- 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
@@ -4,7 +4,7 @@
 
 Программист - это социальное существо, и его выживание зависит от коммуникации с командой. Продвинутый программист - это социальное существо, чье удовлетворение зависит от коммуникации с людьми за пределами команды.
 
-Программисты приносят порядок в хаос. Один из интересных способов делать это - внести какое-нибудь предложение за пределами вашей команды. Это можно сделать в виде черновика или устно. Такой подход имеет огромное преимущество в том, что очерчивает рамки дискуссии. Он также ставит вас в позицию критикуемого и может привести к отвержению и пренебрежению. Продвинутый программист должен быть готов к этому, ведь у него есть уникальные возможности, а значит, и уникальная ответственность. Предприниматели, которые не являются программистами, нуждаются в том, чтобы программисты проявляли инициативу хоть в каком-то виде. Программисты - это та часть моста между идеями и действительностью, которая опирается на последнее.
+Программисты приносят порядок в хаос. Один из интересных способов делать это - внести какое-нибудь предложение за пределами вашей команды. Это можно сделать в виде черновика или устно. Такой подход имеет огромное преимущество в том, что очерчивает рамки дискуссии. Он также ставит вас в позицию критикуемого и может привести к отказу и игнорированию. Продвинутый программист должен быть готов к этому, ведь у него есть уникальные возможности, а значит, и уникальная ответственность. Предприниматели, которые не являются программистами, нуждаются в том, чтобы программисты проявляли инициативу хоть в каком-то виде. Программисты - это та часть моста между идеями и действительностью, которая опирается на последнее.
 
 Я все еще не освоил до конца навык взаимодействия, но что я сейчас пытаюсь делать, можно выразить как четырехсторонний подход. После того, как я привожу свои идеи в порядок и полностью готов, я стараюсь сообщить о них устно, вручаю нужным людям черновой набросок (на бумаге или в электронном виде), показываю демо и затем терпеливо повторяю процесс. Я думаю, что часто мы недостаточно терпеливы для такого сложного общения. Не стоит расстраиваться, если ваши идеи не были приняты сразу. Если вы вложили много усилий в их подготовку, никто не будет думать о вас плохо из-за отказа. 
 
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
index 78bc895..67fc4fd 100644
--- 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
@@ -6,7 +6,7 @@
 - Программистов можно сравнивать. (Программисты очень сильно отличаются друг от друга)
 - В проект можно добавить ресурсов, чтобы ускорить его. (Коммуникация с новыми людьми в проекте почти всегда скорее ведет к замедлению проекта, чем к ускорению)
 - Разработку программного обеспечения можно надежно оценить по времени и затратам. (Это невозможно даже теоретически)
-- Производительность программистов можно измерить в рамках одной простой метрики, например, в строках кода. (Если качество в емкости, то избыточные строки кода это плохо, а не хорошо)
+- Производительность программистов можно измерить одной простой метрикой, например, в строках кода. (Если качество в емкости, то избыточные строки кода это плохо, а не хорошо)
 
 Если у вас есть возможность, вы можете попытаться объяснить эти мифы, но не расстраивайтесь, если у вас не получится. Не портьте себе репутацию воинственным противостоянием этим мифам. Каждый из них поддерживает идею менеджеров о том, что у них есть реальный контроль над тем, что происходит в проекте. Но правда в том, что менеджеры только упрощают процесс, если они хороши, и мешают ему в противном случае.
 
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
index b423ba2..d97c9d8 100644
--- 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
@@ -1,6 +1,6 @@
 # Как справляться с организационным хаосом
 
-Иногда случаются короткие периоды времени, когда царит организционный хаос: такие как массовые увольнения, покупка компании другой, размещение компании на бирже, массовый наем сотрудников и так далее. Такие времена неспокойны для всех, но возможно программистам здесь проще, так как их самооценка основана на чем-то большем, чем просто должность. Организационный хаос это прекрасная возможность для программистов проявить свою суперсилу. Я специально говорю об этом в самом конце эссе, потому что это тайна всех программистов. Если вы не программист, пожалуйста, прекратите чтение прямо сейчас.
+Иногда случаются короткие периоды времени, когда царит организционный хаос: такие как массовые увольнения, покупка компании другой, размещение компании на бирже, массовый найм сотрудников и так далее. Такие времена неспокойны для всех, но возможно программистам здесь проще, так как их самооценка основана на чем-то большем, чем просто должность. Организационный хаос это прекрасная возможность для программистов проявить свою суперсилу. Я специально говорю об этом в самом конце эссе, потому что это тайна всех программистов. Если вы не программист, пожалуйста, прекратите чтение прямо сейчас.
 
 > Программисты могут создавать и поддерживать продукт.
 
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
index 717992f..0017993 100644
--- 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
@@ -2,7 +2,7 @@
 
 Встраивание языка программирования в систему обладает почти эротическим притяжением для программиста. Это одно из самых творческих свершений, которые он может сделать. Встроенный язык делает систему невероятно мощной и позволит вам использовать ее самые творческие возможности. Это превратит систему в вашего друга.
 
-У лучших тестовых редакторов есть встроенные языки программирования. Это можно использовать в той мере, в какой целевая аудитория может овладеть этими языками. Конечно, можно сделать использование встроенного языка необязательным, как это делается в текстовых редакторах, так что ими пользуются опытные пользователи, а остальным они и не нужны.
+У лучших тестовых редакторов есть встроенные языки программирования. Это можно использовать в той мере, в какой целевая аудитория может овладеть этими языками. Конечно, можно сделать использование встроенного языка необязательным, как это и делается в текстовых редакторах, так что ими пользуются опытные пользователи, а остальным они и не нужны.
 
 Я и многие другие программисты попадали в ловушку создания встроенных языков со специальным назначением. Я попадался на это дважды. В мире уже существует множество языков, которые спроектированы специально для подобных целей. Подумайте дважды, прежде чем создавать еще один.
 
diff --git a/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md b/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md
index e7efda5..6ea9c91 100644
--- a/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md
+++ b/ru/3-Advanced/Technical-Judgment/03-Choosing-Languages.md
@@ -12,8 +12,4 @@
 
 Некоторые из этих преимуществ чисто психологические, но психология тоже важна. В конце концов, издержки языковой тирании перевешивают любые преимущества, которые она дает.
 
-<<<<<<< HEAD
-Следующее: [Правильные компромиссы. Как справляться в давлением графика](../Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
-=======
-Следующее: [Нахождение компромиссов. Как справляться в давлением графика](../Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
->>>>>>> 86a634dfe293c0eb66dc413384b0fe7cb1306ea3
+Следующее: [Правильные компромиссы. Как справляться с давлением графика](../Compromising-Wisely/01-How-to-Fight-Schedule-Pressure.md)
diff --git a/ru/5-Bibliography.md b/ru/5-Bibliography.md
index a04fc94..874cc14 100644
--- a/ru/5-Bibliography.md
+++ b/ru/5-Bibliography.md
@@ -14,7 +14,7 @@
 
 [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..
+[Stronger] Friedrich Nietzsche. 1889. Twilight of the Idols, "Maxims and Arrows", section 8.
 
 ## Сайты
 
diff --git a/ru/6-History.md b/ru/6-History.md
index 165bf7a..40f030c 100644
--- a/ru/6-History.md
+++ b/ru/6-History.md
@@ -30,7 +30,7 @@
 
 Оригинальная версия этого документа была начата Робртом Л. Ридом в 2000 году и впервые опубликована в электронном вида в Samizdat Press(http://Samizdat.mines.edu) в 2002 году. Он посвящен программистам Hire.com.
 
-После того, как статья была упомянута на Slashdot в 2003 году, около 75 человек прислали мне письма с предложениями и найденными ошибками. Я ценю помощь и вклад каждого из них. Было немало повторов, но эти люди внесли значимые предложения или первые заметили ошибки, которые я позже исправил: Морган МакГуайр, Дэвид Мейсон, Том Мортел, ninja Programmer на Slashdot, Бен Верк, Роб Хаферник, Марк Хоув, Питер Парейт, Брайан Грейсон, Зед А. Шоу, Стив, Бенц, Максим Йоффе, Эндрю Ву, Дэвид Джецке и Том Коркоран.
+После того, как статья была упомянута на Slashdot в 2003 году, около 75 человек прислали мне письма с предложениями и найденными ошибками. Я ценю помощь и вклад каждого из них. Было немало повторов, но эти люди внесли значимые предложения или первые заметили ошибки, которые я позже исправил: Морган МакГуайр, Дэвид Мейсон, Том Мортел, Ninja Programmer на Slashdot, Бен Верк, Роб Хаферник, Марк Хоув, Питер Парейт, Брайан Грейсон, Зед А. Шоу, Стив, Бенц, Максим Йоффе, Эндрю Ву, Дэвид Джецке и Том Коркоран.
 
 Наконец, я хотел бы поблагодарить Кристину Валлери, чья редакция и вычитка существенно улучшили второй черновик, и Уэйна Аллена, который побудил мне начать это эссе.
 
diff --git a/ru/7-Contributions.md b/ru/7-Contributions.md
index d40ba50..db78808 100644
--- a/ru/7-Contributions.md
+++ b/ru/7-Contributions.md
@@ -1,31 +1,32 @@
-# Участеи в проекте
+# Участие в проекте
 [//]: # (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)
+- Китайский. Переводчик [ahangchen](https://github.com/ahangchen)
+- Русский. Переводчик [paveltovchigrechko](https://github.com/paveltovchigrechko)
 
-**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.
+Github содержит список всех [участников](https://github.com/braydie/HowToBeAProgrammer/graphs/contributors) данного проекта.
 
-## Editorship and Move to GitHub
+## Редакция и переезд на Github
 
-[Braydie Grove](https://www.github.com/braydie) has agreed to serve as editor-in-chief.
+[Braydie Grove](https://www.github.com/braydie) согласился быть главным редактором проекта.
 
-Braydie transposed the original essay into MarkDown and created the repository.
+Он перевел оригинальное эссе в MarkDown и создал данный репозиторий.
diff --git a/ru/GLOSSARY.md b/ru/GLOSSARY.md
index 02549ed..a8a956f 100644
--- a/ru/GLOSSARY.md
+++ b/ru/GLOSSARY.md
@@ -1,6 +1,6 @@
 # Глоссарий
 [//]: # (Version:1.0.0)
-В данном глоссарии собраны термирны, использующиеся в эссе. Термины необязательно имеют стандартное для большинства людей значение. Eric S. Raymond собрал массивный и информативный глоссарий[HackerDict], оценив малую часть которого, можно с удовольствием прочесть от корки до корки, как бы это странно ни звучало.
+В данном глоссарии собраны термирны, использующиеся в эссе. Термины необязательно имеют стандартное для большинства людей значение. Эрик С. Рэймонд собрал массивный и информативный глоссарий[HackerDict], оценив малую часть которого, можно с удовольствием прочесть от корки до корки, как бы это странно ни звучало.
 
 ### Вывод в консоль
 
@@ -16,7 +16,7 @@
 
 ### Клан
 
-Люди, которые разделяют с вами верность некой общей цели.
+Люди, которые разделяют с вами верность некой общей цели или профессии.
 
 ### Бизнес
 
@@ -30,9 +30,9 @@
 
 Невозможность найти нужную информацию из-за того, что она спрятана в большом количестве другой, менее интересной, информации.
 
-### wall-clock
+### Реальное время
 
-Фактическое время, измеряемое настенными часами, противоположность процессорного времени.
+Фактическое время исполнения программы, измеряемое настенными часами, противоположность процессорного времени.
 
 ### Узкое место
 
diff --git a/ru/LICENSE.md b/ru/LICENSE.md
index 3e18a1a..7c36621 100644
--- a/ru/LICENSE.md
+++ b/ru/LICENSE.md
@@ -1,12 +1,11 @@
 
 ## 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.
+"Как быть программистом: Community Version", авторы Robert L. Read и Community, издано под лицензией 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
index e5de3de..d6ae0df 100644
--- a/ru/README.md
+++ b/ru/README.md
@@ -1,25 +1,25 @@
-# How to be a Programmer: Community Version
+# Как быть программистом: 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/).
+Выпущено под лицензией [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]. Данное эссе слегка отличается от этих великолепных работ тем, что акцентирует внимание на социальных проблемах и обобщает набор необходимых программисту навыков так с моей личной точки зрения.
+Программирование преподается на курсах. Великолепные книги The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96] и Extreme Programming Explained [XP99]: все обучают программированию и более общим вопросам о том, как быть хорошим программистом. До или вместе с данной статьей непременно стоит ознакомиться также с эссе Пола Грехэма [PGSite] и Эрика Рэймонда [Hacker]. Данное эссе слегка отличается от этих великолепных работ тем, что акцентирует внимание на социальных проблемах и обобщает набор навыков, необходимых программисту, с моей личной точки зрения.
 
-В данном эссе я называю "боссом" любого, кто ставит перед вами задачи. Слова "бизнес", "компания" и "племя" я использую как синонимы, кроме тех случаев, когда "бизнес" означает генерирование прибыли, "компания" - место работы, а "клан" - людей, с которыми вы разделяете преданность.
+В данном эссе я называю "боссом" любого, кто ставит перед вами задачи. Слова "бизнес", "компания" и "клан" я использую как синонимы, кроме тех случаев, когда "бизнес" означает генерирование прибыли, "компания" - место работы, а "клан" - людей, с которыми вы разделяете преданность общему делу или профессии.
 
 Добро пожаловать в клан.
 
 ## Содержание
 
-1. [Начинающий разработчик](1-Beginner)
+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)
@@ -45,7 +45,7 @@ Licensed under [Creative Commons Attribution-ShareAlike 4.0 International Licens
 		- [Делайте перерывы, когда вы в тупике](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. [Программист среднего уровня](2-Intermediate)
 	- Личные навыки
 		- [Как сохранять мотивацию](2-Intermediate/Personal-Skills/01-How-to-Stay-Motivated.md)
 		- [Как заслужить доверие](2-Intermediate/Personal-Skills/02-How-to-be-Widely-Trusted.md)
@@ -73,8 +73,8 @@ Licensed under [Creative Commons Attribution-ShareAlike 4.0 International Licens
 		- [Как проводить собеседования](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. [Продвинутый программист](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)
@@ -97,7 +97,7 @@ Licensed under [Creative Commons Attribution-ShareAlike 4.0 International Licens
 4. [Глоссарий](GLOSSARY.md)
 5. [Приложение A - Библиография/Список сайтов](5-Bibliography.md)
 6. [Приложение B - История (на январь 2016)](6-History.md)
-6. [Приложение C - Участие в проекте (на январь 2016)](7-Contributions.md)
+7. [Приложение 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
index e442482..4f01b51 100644
--- a/ru/SUMMARY.md
+++ b/ru/SUMMARY.md
@@ -1,80 +1,81 @@
-# 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)
+* [Начинающий программист](1-Beginner/README.md)
+	* Личные навыки
+		* [Научитесь отлаживать](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-Intermediate/README.md)
+	* Личные навыки
+		* [Как сохранять мотивацию](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-Advanced/README.md)
+	* Техническая экспертиза
+		* [Как отличить сложное от невозможного](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)
+* [Глоссарий](GLOSSARY.md)
+* [Приложение A - Библиография/Список сайтов](5-Bibliography.md)
+* [Приложение B - История (на январь 2016)](6-History.md)
+* [Приложение C - Участие в проекте (на январь 2016)](7-Contributions.md)