Чем хороший программист отличается от плохого, или почему нужно выходить за рамки
Когда-то я был молод и зелен и решал проблемы именно так, как их решают джуны. Алгоритм такой:
- Узнать о проблеме
- Локализовать проблему
- Загуглить проблему и решение
- Пофиксить проблему
Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открывал файл, редактировал проблемную строчку, закрывал файл. Проблема решена.
Или другой пример: не отработал скрипт из-за ошибки в коде. Чиню ошибку, скрипт начинает работать.
Прошло 10 лет... Алгоритм претерпел изменения:
- Узнать о проблеме
- Локализовать проблему
- Загуглить проблему и посмотреть много решений
- Понять, почему это произошло
- Понять, что нужно сделать, чтобы это не произошло снова
- Понять, что ещё затронуто проблемой
- Понять, где ещё потенциально могут возникнуть похожие проблемы
- Пофиксить проблему
- В зависимости от количества необходимых усилий, пофиксить всё сопутствующее
- Рассказать пацанам в слаке про свой фейл (== поделиться опытом)
Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открываю файл, разбираюсь, как проблемная строчка попала в него, пытаюсь сделать, чтобы она туда больше не попадала, ищу такие же ошибочные строчки в файле, ищу другие потенциальные ошибки, чиню файл сам или заворачиваю на доработку. Проблема решена - либо полностью, либо частично, но с полным осознанием это факта.
Или другой пример: не отработал скрипт из-за ошибки в коде. Разбираюсь, кто написал скрипт, почему писал ручками вместо того, чтобы вызвать какую-то команду для настройки и деплоя, где ещё подобные ошибки могут быть (и в этом проекте, и в проектах других клиентов), чиню и делаю всё возможное, чтобы это не произошло опять.