Ты написал код, отправил его на ревью. Во время ревью тебе указали на ошибку в коде и вернули задачу на доработку. Здесь мы не рассматриваем ошибки в бизнес-логике написанного кода — только ошибки на уровне интерпретатора/компилятора, из-за которых приложение «падает». Не нужно послушно исправлять указанную ошибку и отправлять задачу на повторное ревью. После чего ждать дальнейшей участи и надеяться на то, что ревьюер ничего больше не найдет и пропустит код дальше. А еще не нужно оправдываться. Оправдание есть у каждого (открою секрет: ревьюеру не интересно, почему ты допустил ошибку. В первую очередь это должно быть интересно тебе лично — сделай правильные выводы, чтобы такая ошибка не повторялась). Не нужно исправлять ошибку сразу. Проверь работоспособность всего кода. Повторю — ПРОВЕРЬ РАБОТОСПОСОБНОСТЬ. И исправь ВСЕ выловленные ошибки. Пройдись по коду всеми возможными линтерами и анализаторами (линтер - это как автоматическая проверка орфографии в MS Word, только для кода).  Запусти код еще раз у себя (локально, на тестовом стенде, еще как-нибудь).  «Погоняй» код на различных данных. Пообщайся с постановщиком или тестировщиком, чтобы получить приближенные к реальности входные данные для тестирования.  Поправь найденные ошибки. Повтори все вышенаписанное еще раз. Наличие ошибки — это повод задуматься о том, что код плохо протестирован самим разработчиком. А ведь прямая обязанность разработчика — это в первую очередь предоставление РАБОТОСПОСОБНОГО кода. Тестировщики проверяют корректность бизнес-логики, граничные и нестандартные значения. Но только при условии, что код работает и способен запуститься на тестировочном стенде. Повторяю — нужно исправлять не ошибку, а проверить работоспособность своего кода. Каждой его строчки. И убедиться, что твой код не повлиял на другой функционал. Запомни: твой коллега-ревьюер — не линтер. В его обязанности не входит построчная проверка кода на синтаксические ошибки. И тестировщик не линтер.  Цель ревью — взглянуть на твое решение «свежим» взглядом или с позиции опыта и указать на моменты реализации, которые ты не учел. Но никак не поиск ошибок на уровне кода. А задача тестировщика — проверить код на соответствие бизнес-требованиям, а также убедиться, что новый функционал не повредил стабильные узлы. Конечно, есть компании, где ревьюеры пробегутся по всему коду и подробно укажут на все найденные ими ошибки. Но такое бывает редко. И такие ревьюеры — тема для отдельного поста. Ситуации, когда от разработчика выходит неработоспособный код, конечно же бывают. Никто не отменял запары, форс-мажоры, усталость и невнимательность. Но если такие ситуации повторяются регулярно, то это существенный удар по твоей репутации как разработчика. Ревьюерам не хочется постоянно быть нянькой — им хочется выполнять СВОИ задачи, а вместо этого они отвлекаются на поиск ошибок в ТВОЕМ коде. И это повод: Обновить свой инструментарий: обвесить свою IDE (или редактор кода) линтерами и анализаторами или настроить скрипт, который при изменениях прогонял бы код проекта через них. Подумать над средой для тестирования задач. Чтобы можно было собрать проект и «погонять» его при разных условиях. Не так глубоко, как это делают тестировщики. Но основные кейсы нужно обязательно протестировать самостоятельно. Лайфхак: спроси у коллег, как они тестируют свой код перед отправкой в ревью. При постановке задачи сформировать (с постановщиком, тестировщиком или самостоятельно) тест-кейсы.  Ревьюер скажет тебе спасибо, если ты коротко опишешь список изменений, которые ты внес в код. А также укажешь, как именно тестировал и проверял свой код. Подумать о внедрении подходов и инструментов тестирования (Unit-тесты, TDD, например, если их нет) лично для себя или на уровень всего отдела. Ты написал текст, отправил на проверку и получил фидбэк о пропущенной запятой или орфографической ошибке.  Исправить ошибку и снова отправить на проверку.  Внимательно — весьма внимательно — пройтись по всему тексту и перепроверить все запятые и буквы.  1  Время принимающего текст (например, старшего редактора) для бизнеса стоит дороже. Он может либо править твои ошибки, либо делать более сложную задачу.   2 Страдает твоя личная репутация. Неимоверно бесит два или три раза подряд отправлять текст на правку элементарных вещей. ​​ 3 Возможно, в тексте есть и другие — более серьезные ошибки. Если ты дописываешь текст в сильной запаре и с вытекающими под вечер глазами, остановись. Проветрись и проверь еще раз. Может, где-то дублирование смыслов. Может, неверная ссылка. В общем, проверь.  Не страшно пропустить запятую. Важно отношение. Не надо писать, что было мало времени на вычитку. Или что голова распухла от задач. Надо принять замечание и все внимательно проверить.  Если ситуация такова, что надо срочно отправить текст, который дописываешь с гудящим от напряжения мозгом, пиши коммент: «Отправляю текст. В нем могут быть опечатки, потому что делали срочно. В течение часа я внимательно проверю еще раз».  Пропущенная запятая — не ошибка, а сигнал о повторной тщательной проверке.  То же относится, когда на ошибку указали в комментариях в соцсетях. Поблагодарить за внимательность, исправить ошибку и пойти внимательно читать весь текст. Весь. Текст. Целиком.  Андрей — редактор. Павел — разработчик.