Я выбираю один из этих вариантов:
1. Тщательная проверка, если я хорошо представляю всю архитектуру решения и даже отдельные элементы решения и мне довольно несложно все это изложить в коде и потом только "сводить концы". Тут конечно возможны разнообразные подводные камни и грабли, про которые я не подумал и "сведение концов" может растянуться на неприличное время, но исходная архитектура и вариант кода есть заранее благодаря уже имеющимся знаниям в задаче/сценариях/области. Вариант очень хорошо подходит для получения "клонов" с меня: сотрудник с такой задачей сделает эту задачу примерно так же как я или лучше. Когда такое решение есть - я ставлю 'approved'. Так же вариант хорошо подходит для обучения сотрудников.
2. Поверхностная проверка, если я вообще не представляю что за решение может быть у задачи: я не работал с этой областью, я уже все забыл, новые подводные камни/грабли несовместимые с текущей архитектурой и другие варианты, сводящиеся к "это абсолютно новая для меня задача". Тут уже наоборот: я буду учиться и становиться чьим-то клоном. Я буду изучать новую область, исследовать проблему, "с нуля" искать варианты решений и проверять каждой из них и я так иногда делаю, если у меня нет других важных/срочных задач. Либо я могу проверить только мелкие ньюансы типа правильных проверок входных данных и читаемость нового кода. Если сотрудник уже не раз хорошо решал другие задачи, то я так и делаю: не исследую какие еще могут быть варианты, не влезаю в новую область, кратко обсуждаю и ставлю 'approved'.
