translation of grades/middle.md

English/Grades/Middle.md

@@ -1,43 +1,47 @@
 # Middle C++
 
-## Кто это?
+## Who is it?
 
-Это разработчик, который понимает технический контекст разработки и способен создать дизайн и решения для функционала внутри компонента/приложения даже в случае неполноты требований. Также имеет практический опыт работы на проектах и в рамках принятых бизнес-процессов.
+It's a developer that understands the technical context of development and has abilities to create a design and solution for functionality that is a part of an application or component. The design also can be created even in case of an insufficient amount of requirements. This person also has a commercial experience background and is familiar with common business processes of development.
 
-В основном решает технические задачи, но, в отличие от джуна, способен делать это самостоятельно или под менторством синьора/тимлида.
+In general, the middle developer solves technical tasks. In comparison with a Junior, this person can do work without any help or minor assistance from a Senior/Lead engineer.
-
-## Что ожидается по умению написания кода?
-
-- Компилятор и язык его больше не пугают и практически не приносят сюрпризов, а если и приносят, то способен самостоятельно генерировать гипотезы, проверять их и копать вглубь
-- Ориентируется в базовых концепциях языка и понимает, какие ещё языки существуют и чем они отличаются
-- Пишет понятный и поддерживаемый код
-- Знает базовые принципы дизайна и на их основе способен принять техническое решение
-- Понимает не только язык программирования, но и его технический контекст, то есть понимает весь технический цикл, через который проходит код и ориентируется в инструментах, которые помогают этот цикл поддерживать:
-    - Написание кода (IDE, текстовые редакторы, практики программирования, качество кода)
-    - Хранение исходного кода и продуктов (системы контроля версий, пакетные менеджеры, серверы)
-    - Компиляция (компиляторы, системы сборки, библиотеки)
-    - Тестирование (фреймворки, стратегии тестирования)
-    - Доставка
-    - Выполнение на целевой системе
-- Глубже понимает и знает базовую информатику (структуры данных, конечные автоматы, алгоритмы)
-
-## Что ожидается по общим навыкам?
-
-- Способен самостоятельно ориентироваться в технической части проекта и принимать решения, которые вписываются в него
-- Понимает, когда нужно остановиться, чтобы не переусложнить решение
-- Имеет практический опыт работы в команде
-- Способен формулировать и доносить идеи и мысли до других членов команды
-- Имеет практический опыт работы по различным методологиям: Kanban, Agile/Scrum, Waterfall и т.д.
-- Помогает другим членам команды
-
-## Рекомендации и советы
-
-### Про обучение
-- Начинайте прокачивать софт-скиллы, если хотите вырасти в синьора. На синьорском уровне техническая экспертиза часто отходит на второй план, а на первый выходит умение вести диалог и договариваться. Хороший разработчик, не тот кто пишет много кода, а тот, кто понимает как решить проблему максимально просто и эффективно. В идеале - без написания нового кода, а ещё лучше - если ещё удалится пара десятков/сотен строк.
-- Стадия миддла самая энергозатратная с точки зрения обучения. От вас требуется не только прокачивать технические скиллы, но также навыки коммуникации и погружение в проблемы бизнеса. Это значит, что вам требуется одновременно развиваться в нескольких направлениях одновременно. Уделяйте внимание в равной степени как "хард", так и "софт" скиллам.
-- Должное внимание "софт" скиллам также повышает вероятность того, что вы быстрее станете востребованным профессионалом на рынке. Вы можете попытаться стать узконаправленным техническим специалистом и игнорировать коммуникативные навыки, но, во-первых, компаниям нечасто нужны подобные кадры в больших количествах, во-вторых, вам придется конкурировать с лучшими из лучших. Если вы действительно готовы состязаться с лучшими специалистами на рынке, то смело идите вперед, но все же рекомендуем подумать о диверсификации своих навыков. 
 
 
-### Про опыт
+## What coding abilities are expected?
-- Основная ловушка для многих мидлов: фанбойство по технологиям, фреймворкам, внедрением паттернов или подходам к разработке. Постарайтесь прагматично подходить к выполнению задач на проекте. Не нужно пытаться затянуть все последние новинки, только чтобы поиграться с ними или ради строчки в резюме. На этом этапе очень велик соблазн проявить свое мастерство через обилие технологий или оверинжиниринг.
+
-- Если вы действительно считаете, что проекту нужна новая библиотека или фреймворк - обсудите это с синьором/тимлидом. Предложите им попробовать создать прототип, где сможете проверить их в действии прежде чем втягивать в проект. Пожалуйста, никогда не втягивайте их в обход всей команды или втихаря! Для вас - это развлечение, но для проекта/тимлида это станет головной болью в будущем, т.к. это повысит стоимость поддержки проекта и принесёт неожиданные проблемы. 
+- The compiler and programming language is not a "magic box" anymore. Any obstacles or surprises can be solved by generating of hypothesis, validation, and confirmation/rejection.
+- Understands foundation concepts of C++, knows about other languages, and can compare them with each other
+- Writes readable, extendable, and maintainable code 
+- Knows design patterns and principles, can make technical decisions
+- Understands a technical context of the language: e.g. how the code is compiled, knows tools that help to maintain a code lifecycle:
+    - Code writing (IDE, text editors, code quality, best practices, etc.)
+    - Archivation of source code and a product (version system control, package managers, servers, etc.)
+    - Compilation (compilers, build systems, libraries)
+    - Testing (frameworks, testing strategies)
+    - Shipment/Deployment
+    - Execution on a target system,
+- Knows better Computer Science foundations (data structures, graphs, finite machines, algorithms)
+
+
+## What general skills are expected?
+
+- Can personally make decisions based on technical knowledge/background of a project
+- Understands when a solution is "good enough" to prevent overengineering
+- Has a team player mindset
+- Can formulate and share an opinion with other teammates
+- Has empiric background with different methodologies: Kanban, Agile/Scrum, Waterfall, etc.
+- Helps other teammates
+
+
+## Tips and recommendations
+
+### Studying
+
+- It's time to improve soft skills if you want to become a Senior one. The technical expertise goes a bit behind and an ability to build dialogs and find compromises with others go first. A good developer is not one who writes a lot of code, but understands how to solve a problem efficiently with minimal "bleeding". Good - without any new code, ideally - if even tens/hundred lines of code are removed.
+- The middle role is most difficult for studying. You're needed to think not only about hard skills but also about soft skills and business-problem solving. It means you're asked to concentrate on both aspects simultaneously either about hard skills or soft skills.
+- Good attention to soft-skills increases the probability to become a high-demand professional on the marker. You can try to grow as a highly specialized developer and ignore soft skills, but first - this kind of specialists are not often needed in business problems, second - competition among such kinds of developers is extremely high. If you're ready to compete with the best specialists on the market then don't listen to us and bravely go forward, but we still recommend thinking about skills diversity.
+
+### Experience
+
+- The main trap of many middle developers: they're "fanboys" of technologies, frameworks, design patterns, or methodologies. Try to be more pragmatic while solving tasks on your project. Don't try to intake all the newest ideas only to play with them or get "yet another skill" to your CV. The Middle role is a "pandora box" of overengineering or "diving" around frameworks.
+- If you really think a library/framework is needed for a project - discuss it with a Senior or Lead engineer first. Propose them to create a "proof of concept" where you will be able to check all hypotheses in action before intake a new dependency. Please, don't try to do it behind your team! It's fun for you, but it's a "disaster" for your team in the future. It increases maintenance costs and also might bring unforeseen consequences.