Комментарии 16
Полностью поддерживаю.
При обнаружении ошибки, котрорая затрагивает каскад проблем, дополнительно вношу в специальный раздел в базе знаний (у нас это Confluence), где собраны правила разработки, условия и т.д.
Алгоритм претерпел изменения:
Это ещё не синьор.
У синьора вот так:
Узнать о проблеме
Локализовать проблему
Загуглить проблему и решениеПофиксить проблему
Не понятно за что заминусовали комментарий выше, сеньор, если решения в гугле нет - как раз таки должен найти решение сам, иначе какой он сеньор, или это уже уровнем выше? ))
Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Сеньор, который не пользуется опытом других
Я не писал, что синьор не пользуется опытом других. Я написал, что он не "загуглит проблему и решение". Максимум - это уже точное решение проблемы (команда в терминал, название свойства, путь к конфигу и т. д.).
Да, если проблема для специалиста новая - он идёт гуглить что за проблема. Но для помидоров такие ситуации случаются не часто.
если решения в гугле нет
Если решения в гугле нет - это триггер, что с вероятностью 99.9999% ты прямо сейчас творишь какую-то дичь и нужно внимательно пересмотреть подход.
Я зачеркнул гугл потому, что у синьора есть опыт решения задач и он их решает.
Ещё я нарочно убрал весь бред про базу знаний, перепроверку всего кейса, разбирательства в причинах и т. д. Если ошибка из-за того, что число округляется в неправильную сторону - то да, тут можно и поправить 1 строку в коде. Но в ситуациях, когда нужно разбирательство, синьор не тратит своё время на это, а делегирует мидлу или даже джуну.
У настоящего сеньора проблемы решаются сами при самом его присутствии.
Надо всегда исправлять не последствия, а причину баги ^.^
Спасибо за статью. Второй "алгоритм" справедлив и для джунов и для всех вообще, включая обычных юзеров которые просто настраивают свой домашний компьютер. Это надо доносить ещё до школьников на уроках информатики. Не понял в чём тут "фишка" в этой статье. Это же стандартный подход к любой проблеме с аппаратной или программной частью. Не понимаю почему у автора ушло на понимание этого 10 лет.
Чем хороший программист отличается от плохого
а как же классика: у хорошего программиста меч зеленый, а у плохого - красный?
two weeks of coding might save you two hours of thinking
Все хорошо, но проблема-то была в том, что вообще в принципе Excel файл использовался :) И во втором алгоритме (зря заминусовали человека выше) можно вообще было не гуглить или напугать, понять что принятый ответ ответом не является и т.д...
Я не синьор (да и вообще не программист официально), но для меня лично переломным стало понимание того, что нужно прочитать и осознать что тебе пишет компилятор/интерпретатор (а если есть возможность - то вообще линтер). Причем сделать это перед тем, как гуглить. Возможно и гуглить не нужно будет, и в голове больше отложится.
Анализ начинается еще на уровне постановки задачи
Чем хороший программист отличается от плохого, или почему нужно выходить за рамки