Чем хороший программист отличается от плохого, или почему нужно выходить за рамки

Советую немного переделать этот список. Перед тем, как приступать к решению задачи, надо сначала подготовиться, сделать домашнее задание, и разобраться в том, что решать, и надо ли ее решать вообще. Если сразу приступать к решению, можно попросту потратить время зря.

Для меня, это больше выглядит так:

1. Узнать о проблеме

2. Проанализировать проблему

   1. Для начала выяснить, проблема ли это или так задумано by design, нужно ли вообще что-то менять

   2. Понять, почему это произошло, какие действия привели к проблеме

   3. Собрать информацию о том, как воспроизвести проблему

   4. Найти источник проблемы (root cause)

   5. Понять, какие части затронуты проблемой, какие последствия

3. Оценить проблему

   1. Насколько критична

   2. Насколько решабельна, прикинуть как быстро ее можно решить (estimate)

   3. Приоритизация решения (возможно проблема не так важна и ее можно дропнуть)

   4. Определиться кто и как ее должен решать (не факт, что это вы или ваша команда)

   5. Спланировать решение

4. Только сейчас уже решение (или делегирование) проблемы (включая гуглежь и прочее), когда мы знаем, с чем имеем дело, и имеем полную картину.

5. Проверка решения, тесты. Убедиться, что проблема решена, и что наше решение не поломало ничего нового.

6. Дальше уже рассказывать друзьям и делиться опытом.

Даже если это мидл, или джун, все равно советую хотя бы поверхностно пройти по анализу, чтобы понять, стоит ли за это браться, или может лучше заняться чем-то более значительным. Иначе, такой сеньор может погрязнуть во всех этих мелких проблемах вместо того, чтобы заниматься более серьезными вещами.