The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Что меня больше всего расстраивает в моей профессии разработчика программного обеспечения - это постоянная необходимость понимать большие проблемы перед исправлением мелких ошибок, особенно если код является устаревшим и не мой. На самом деле, это еще более раздражает, когда код мой. “Глубокое мышление”, как его называют, которое всегда требуется перед решением даже маленькой проблемы, серьезно отталкивает меня от программирования. Или отталкивало. Пока я не начал думать по-другому и не стал поощрять себя быть ленивым. Вот как.
Я писал об этом несколько лет назад в этом посте блога: Как сокращать углы и оставаться крутым. Однако в нашей группе в Telegram, где мы говорим о Zerocracy, некоторые программисты постоянно задают мне один и тот же вопрос: Что делать, когда проект для меня совершенно новый, у меня есть всего 30 минут, а ошибка очень сложная?
Один из основных принципов Zerocracy - это #NoAltruism. Это означает, что вы всегда и только должны думать о себе и о своей личной выгоде. Вы не должны пытаться улучшать проект, повышать его качество, исправлять код или рефакторить что-либо… пока вас не оплатят за это.
Прежде всего, когда задача, за которую вам будут платить, стоит перед вами, и вы не можете понять, как ее решить, не вините себя. Вам не обязательно быть экспертом в устаревшем коде, который вы только что открыли. Строго говоря, вам не обязательно быть экспертом ни в чем. Проект, в отличие от вашей мамы, не ожидает от вас интеллекта или технической подкованности. Он нуждается в том, чтобы вы закрывали задачи.
Кого вы будете винить, если не себя, когда ошибка серьезна, код запутанный, и вы не имеете представления, сколько времени потребуется только для его понимания, не говоря уже о его исправлении? Хорошо, вы можете винить всех вокруг, но прежде всего вы должны винить сам код. Как его винить? Создавая новые задачи, в которых может звучать следующее:
Метод X слишком сложен, я не знаю, что он делает.
Алгоритм X неразборчивый, я не могу понять, что он делает.
Здесь используется библиотека X, но я не понимаю, почему вы не используете библиотеку Y.
Правила именования классов не ясны, пожалуйста, их задокументируйте.
Принцип организации данных неочевиден, задокументируйте его.
Однако не делайте ошибку, которую делают многие программисты, когда мы говорим им, что тикеты - единственный правильный способ решать проблемы. Они начинают задавать вопросы и искать помощь в тикетах, вот так вот:
Пожалуйста, помогите мне создать класс X.
“Где мне следует разместить класс X, в каком пакете?”
“Какую библиотеку следует использовать для выполнения X?”
Проект не является школой, он не заинтересован в том, чтобы сделать вас умнее или большим экспертом в его коде. Никто не будет объяснять вам что-либо, потому что это пустая трата денег и времени. Вместо этого проект будет исправлять свою кодовую базу, чтобы она стала более чистой и понятной для вас и всех остальных. Таким образом, никогда не просите объяснения или помощи, просите документацию и исправление исходного кода.
Что вы делаете дальше? Вы сидите и ждете, пока эти тикеты будут решены. Кто их решит? Вам все равно. Это проблема для менеджера проекта. Может быть, он/она даже назначит эти тикеты вам обратно, и это будет ваша проблема их решить. Но если это произойдет, то объем работы будет другим для вас. Вам не нужно будет исправлять ошибку, вам придется задокументировать некоторую функциональность или провести рефакторинг некоторого модуля.
У вас будут другие проблемы в этом новом, более узком объеме работы. Вы будете создавать новые тикеты, обвиняя всех вокруг вас, и они также могут вернуться к вам. И так далее. В конечном итоге, объем тикета будет настолько мал, насколько возможно его исправить за 30 минут.
Видите алгоритм? Я уверен, что да, но его очень сложно применить к реальной жизни и реальным программным проектам, по нескольким очевидным психологическим причинам.
Вы – перфекционист. Вы хотите завершить всю задачу, решить всю проблему и понять всю область. Что я могу сказать? Это не будет решено, пока проект продолжает платить вам за часы/месяцы. Как только они начнут платить за результаты, эта болезнь будет вылечена.
У вас нет страсти. Вам абсолютно не важно качество кода. Вам не нужно, чтобы он выглядел чистым, вы даже не можете определить, что такое чистота и что такое беспорядок. Вам просто хочется получить оплату в конце месяца. В этом случае вы даже не будете знать, какие проблемы нужно сообщить. Что я могу сказать? Пожалуй, вам стоит попробовать найти другую работу. Может быть, менеджером?
Вы боитесь. Обвинение проекта и создание тикетов могут создать впечатление, что у вас отрицательное отношение к кодовой базе и людям, создавшим ее, что не соответствует действительности. Вместо этого ваше отношение положительное, потому что вам на нем зависит и вы хотите, чтобы он стал лучше. Что я могу сказать? Сформулируйте свои заявки очень вежливо и мягко. Но продолжайте их создавать.
У вас нет времени. Вам нужно решить проблему сейчас, и у вас нет времени ждать разрешения тех жалоб, о которых вы сообщили. Что я могу сказать? Возложите вину на управление и потребуйте больше времени. Гораздо больше времени. Но никогда не возлагайте вину на себя.
Разработка программного обеспечения - идеальная территория для уклонения от труда, лености и сохранения спокойствия, потому что наша работа часто является дискретной и может быть очень пошаговой. Очень редко может возникнуть ситуация, когда невозможно обвинить проект и приостановить выполнение задания до устранения всех ваших претензий. Хотя лично я не могу представить такую ситуацию. Если вы можете, пожалуйста, дайте мне знать.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-18 at 04:59
