Подборка 35 вредных привычек разработчиков. Изучите данные привычки, найдите те, которые есть у вас, и постарайтесь избавиться от них.
Итак, какие же вредные привычки стоит избегать каждому программисту? Вероятнее всего, таковых привычек куда больше, чем 35, но согласитесь, 35 звучит круто, и это единственное, почему их 35.
Я выделил #17 и #35, так как считаю их наиболее важными, и поэтому предлагаю вам прочесть про них подробнее. Думаю, что вы найдете это ценным для себя.
1. Действовать так, словно вы все знаете
Не поддавайтесь на чувство, будто вы все знаете. Это не так, и это нормально.
2. Тратить весь день на совещания
Если вы тратите большую часть дня на совещания, то вам следует пересмотреть потраченное время и организовать его более продуктивно.
3. Неадекватно реагировать на критику вашего кода.
Лучшие программисты всегда готовы на простой и открытый диалог по поводу написанного ими кода и всегда готовы улучшить его.
4. Слишком рано сдаваться
Очень многие программисты подходят настолько близко к решению проблемы, но в последний момент опускают руки, так и не решив проблему.
5. Отказ от помощи
Четкое объяснение своей проблемы кому-либо еще, зачастую, приводит к её решению. Это, собственно, и есть “Метод утёнка”.
6. Перекладывание вины на других
Наиболее ценным считается работник, который берет ответственность за написание кода на себя.
7. Написание кода, который преждевременно оптимизирует другой код
В большинстве ситуаций преимущество в производительности, полученное с помощью полной оптимизации сложного для понимания кода, является излишним.
8. Игнорирование мнения других разработчиков
Одним из наилучших способов развития считается парное программирование с более опытным разработчиком. Обращайте внимание на мнение других разработчиков.
9. Незнание основных способов оптимизировать код
Вот несколько ситуаций, когда производительность очень важна:
- Сложность алгоритма;
- Неэффективная работа с базой данных;
- Стороннее API;
- Запросы N+1.
При возникновении проблем с производительностью вам следует проанализировать её, понять, что занимает время и как решить данную проблему.
10. Пренебрежение отношениями с другими членами команды
Вас наняли написать код, но вам также следует взаимодействовать с другими членами команды.
11. Участие в решениях офиса
Иногда вам может показаться, что решение команды неверно, но пока вы в состоянии выполнять поставленные задачи, то лучше всего не обращать на такие решения внимание.
12. Находиться под давлением
Если при вашей работе пользователь не может использовать ваш продукт, то это приносит тонну давления. В данном случае вам следует дать пользователям возможность использовать продукт для того, чтобы оставаться спокойным и успешно выполнять работу.
13. Никогда не использовать плохой код
В реальных условиях часто приходится идти на компромиссы, причиной этого может быть:
- Дедлайны;
- Эксперименты;
- Неотложные баги, которые нуждаются в срочном исправлении.
Вам следует понимать, когда написание плохого кода — это хорошо и то, что делается это в случаях, когда нужно успеть выполнить все требования к сроку.
14. Усложнение решения несложных задач
Не создавайте сбивающих с толку решений для несложных задач.
15. Вести себя как босс, а не лидер
Очень многие разработчики не знают, как управлять людьми. Вы должны быть человеком, к которому обращаются за организационными вопросами и наставлениями, а не только за кратковременными советами.
16. Использование неверных инструментов для работы
Не делайте поспешных выводов подобно: “о, этим я уже пользовался, значит и тут сойдет”. Следует быть готовым к использованию различных технологий, языков и фреймворков.
17. Отказ от поиска ответов на вопросы в области программирования
Гугл — это один из самых мощных инструментов любого программиста.
18. Отсутствие понимания используемых инструментов
Так как вам придется потратить большое количество времени, используя инструменты наподобие текстовых редакторов, командной строки и т.д., то очень важно освоить их. Потратьте время и изучите все приёмы и хитрости, для того, чтобы ваша работа стала более эффективной.
19. Игнорирование сообщений об ошибках
Ошибки в коде случаются постоянно. Зачастую они содержат очень ценную информацию о том, что пошло не так, почему это произошло и какая строчка кода вызвала ошибку. Вам следует уделять больше времени подобным сообщениям, а не пытаться избегать их.
20. Недооценивание подсчета времени
Лучшие разработчики наслаждаются временем, проведенным за написанием кода, и даже не замечают его. Однако это не означает, что после 10 000 часов написания кода должно что-то измениться.
21. Отказываетесь учиться на своих ошибках
Это контрпродуктивно. При возникновении ошибок просто взгляните на них шире и поймите 3 вещи:
- Что является конечной причиной ошибки?
- Возможно ли изменить процесс или варианты поведения приложения, чтобы в будущем избежать подобных ошибок?
- Можно ли было найти данную ошибку заранее и тем самым уменьшить ее влияние?
Если вы не будете учиться на своих ошибках, то будете повторять их снова и снова.
22. Боязнь написанного кода
Знаете, что три дня, потраченные на написание неверного решения, научат вас большему, чем становление жертвой аналитического паралича?
23. Идеализирование вашего набора инструментов
Некоторым разработчикам нравится текстовый редактор vim, другие ненавидят его, и им нравится текстовый редактор emacs, но бывают ситуации, когда необходимо использовать только один редактор.
24. Отделение себя от сообщества разработчиков
Существует множество сообществ разработчиков по всему миру. Многие сообщества связаны с такими организациями, как Railsbridge, GirlDevelopIt и событиями RubyConf, RailsConf. В них вы можете найти много всего полезного.
25. Отсутствие аккаунтов Twitter
Создатели таких огромных открытых проектов как ruby, rails, JavaScript и другие представлены в Twitter. Потратив здесь некоторое количество времени, вы вынесите для себя много полезного из того, что создали разработчики данных проектов.
26. Не вносите вклад в сообщество программистов
Следует всегда принимать участие в жизни программистского сообщества и начинать это как можно раньше. Как только вы начнете это делать, то поймете, насколько это доброжелательно и полезно.
27. Борьба с какой-либо задачей, решение её, но не документирование
Каждый из нас сталкивался с задачей, решение которой нет на просторах Интернета. И если вы сталкиваетесь с такой задачей, то вам приходится решать её самому. В этом случае вашим долгом является документирование данного решения, чтобы в дальнейшем помочь любому нуждающемуся в данном решении.
28. Написание слишком большого или маленького количества комментариев
Комментарии — это существенные пометки для любого разработчика. Но, как и все остальное, их должно быть умеренное количество.
29. Несвоевременное обновление текущих проблем продукта
Для продукт-менеджеров своевременное обновление статуса продукта — очень важный фактор. Если вы не будете своевременно обновлять статус вашего продукта, то это может привести к множеству головных болей.
30. Частое группирование несвязных вещей в один проект
Очень легко взять за привычку связывать две абсолютные разные вещи в один проект. Однако если каждая из этих вещей имеет большой масштаб и сложна в понимании, то решение может быть сильно усложнено.
31. Игнорирование мнения конкретного разработчика
Бывает так, что некоторые тимлиды даже тщательно обсуждают сложный план по смене направления разработки практически со всеми членами команды только лишь для того, чтобы не брать в расчет мнение одного из разработчиков.
Пожалуй, это худшее, что можно сделать, так делать не нужно.
32. Придерживаться хорошо продуманного, но не работающего плана
Наверное, единственное, что может быть хуже смены направления разработки в последнюю минуту, — это отказ прекращать следовать плохой идее.
33. Извиняться всякий раз, когда пишите плохой код
Если вы стали замечать, что каждый раз извиняетесь за свой плохой код, то это означает, что вы переоценили свои возможности и сроки сдачи проекта.
34. Тратите недостаточно сил и энергии на проверку и анализ кода
Команда разработчиков — это единый коллектив, а значит, и ответственность за написание кода у всех одна, поэтому каждый член команды должен тщательно анализировать и доводить код до современных стандартов.
35. Тратите недостаточное количество времени на советы, поддержку и наставления для других разработчиков в вашей команде
Обеспечение постоянного роста, обучения и развития коллектива — это ваша работа. Ведь каждый коллектив программистов должен всегда совершенствоваться.
Я глубоко убеждён в том, что каждый разработчик — это незавершенный проект. Поэтому иметь подобные вредные привычки — это нормально. По факту, для того, чтобы развиваться как разработчик, да и вообще, как и в любом другом деле, нужно следовать 3 пунктам:
- Признайте, что у вас есть вредные привычки;
- Найдите мотивацию, чтобы исправить их;
- Примените данную мотивацию для того, чтобы избавиться от этих привычек и заиметь полезные.
Если вы прочитали данную статью, то выполнили первый пункт. Теперь настало время переходить к двум другим.
Также вы можете прочесть мою историю о том, как я указал на ошибки senior developer из Microsoft и как это изменило мою жизнь.
Перейдите по ссылке, чтобы прочесть историю.
Ссылка на оригинальную статью
Перевод: Александр Давыдов
Комментарии