Наверняка никогда пожалуй. А отдаленно это смотря на сколько)

У нас была на интервью недавно девушка, офигенная кстати, у них в команде случалось иногда "парное программирование", но в котором участвовала она как QA и разработчик

Значит где-то это есть всё-таки)

Вот и у нас в Инетре было так почти всегда хотя бы тезисно на планерках "буду делать так и так". А иной раз на какую то задачу смотрели вместе в один монитор

На каком этапе смотрели в один монитор?)

Например, на этапе когда заходит ПО "надо срочно вчера" и в спринт добавляет тикет))))))) Да я не помню честно говоря, по-разному, как-то просто гармонично это все было

У меня тоже такое было, и это классно! Но времени на это уходит очень много, конечно

Артём, конкретно тут ты пытаешься решить не ту задачу, добавляя себя к процессу кодинга. Этим увеличиваешь стоимость разработки.
Если программист систематически кодит с ошибками в логике - это некачественный программист. Улучшить качество кодинга можно улучшив программиста или заменив.
Причины плохого кодинга ты можешь попытаться выявить. А ты можешь эскалировать вопрос о компетенция программиста.
Программист должен кодить хорошо. Или отлично. И уметь учиться на ошибках.
Встроив себя в кодинг - ты улучшишь свои навыки кодинга. А оно кому надо и для чего ?
Мне нравится работать с хорошими программистами. Хорошие должны быть круче, экспертнее меня в кодинге и алгоритмах. Это их базовый навык.
Это не значит, что я верю безоговорочно в  алгоритмы и кодинговую непогрешимость хороших программистов..

Котомка-проверка

имхо болтология какая-то, хороший/плохой программист, нужны конкретные метрики как вы его будите оценивать, а их нет, так как много переменных (зависит от проекта, условий работы и мотивация в зп, формулировка требований, что разрабу нужно делать, может у него тз говно).

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

очень простой процесс, выяснить как получилось так, что разрабы которые ревьюили код не увидели элементарных ошибок и ревьюили ли они вообще. вот задача QA, постараться исправить процесс так чтобы это не повторялось (сделать обязательное ревью 2-мя разрабами, улучшить описание задачи)

Может кто в клубе по шахматам состоит.

Всем привет!
Вопрос немного не в тему группы, но может кто знает, есть ли в Новосибирске клубы где играют в шахматы?

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

если прям логику задачи не вычитывают конечно

Ну вот про это я говорю, а если бы тестировшик мог это вычитать без проблем, то обратная связь была бы в разы быстрее)

так тестеровщик, который может разобраться в говнокоде "плохого" разраба (на постоянной основе), либо сам имеет квалификацию разраба и что-то тут забыл. либо миф)

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

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