В этой статье рассказывается об основных этических принципах, которым должен следовать каждый программист/разработчик, чтобы быть одним из элиты и лучшим в развивающейся индустрии программного обеспечения и технологий.
Большинство разработчиков не понимают двух вещей: во-первых, понять
- Что люди имеют в виду, когда говорят Прагматичный?
- Что нужно, чтобы стать программистом, следуя прагматизму?
Проще говоря, быть прагматичным можно интерпретировать как «быть опытным мастером». .
Прагматичность — это практичность и руководство «приоритетом действия над доктриной и опыта над фиксированными принципами».
«Я человек, который ценит мастерство не потому, что результат — результат красоты, а потому, что это инвестиция в мое будущее. ”
Быть прагматичным означает стать лучшим разработчиком. Дело не столько в навыках, сколько в опыте и практике. Требуется много практики и опыта, чтобы стать прагматичным разработчиком.
С каждым новым опытом вы уносите с собой что-то новое, что вы изучаете, что определенно будет связано с точкой, когда вы будете двигаться вперед, чтобы столкнуться с новыми проблемами.
Разработчик должен понимать, что каждое программное обеспечение, которое вы разрабатываете, — это ремесло. Каждый человек, вовлеченный в создание этого ремесла, несет равную ответственность. Как вы думаете, как в таком случае может помочь прагматизм?
Например, рассмотрим сценарий строительства дома, в котором важную роль играют различные мастера. От архитектора, инженера-строителя до маляра и рабочего, у каждого из них есть свои навыки, которые помогают украшать и завершать строительство дома.
В том же контексте, когда вы являетесь частью команды, создающей продукт, ваш личный вклад играет очень важную роль. Независимо от того, являетесь ли вы частью команды backend/frontend/DevOps, это не имеет значения. Ваш вклад важен, так как вы в целом будете представлять команду, создающую продукт, а не только как личность.
Как уже говорилось, прагматизм больше касается того, как вы можете внести качественный вклад в команду не только как разработчик, но и как член команды.
Хотите знать, что нужно, чтобы следовать прагматизму? Давайте разберемся, что отличает Программистов-Прагматиков от толпы.
Быть ответственным
В каждом проекте обязательно будут проблемы. Проблемы сопровождают каждый проект, над которым вы будете работать, несмотря на принятие всех мер безопасности, т. е. перекрестную проверку протокола собрания, документации, тестирование и т. д.
Несмотря на принятие всех мер, возможны задержки поставок или непредвиденные технические проблемы, что иногда неизбежно.
Берите на себя ответственность и отвечайте за свою ответственность. Убедитесь, что вы общаетесь и держите команду в курсе всех обновлений.
Малейшие ошибки во время презентации вашего продукта клиенту могут привести к катастрофическому ущербу для репутации компании или фирмы, которую вы представляете.
Недопонимание или отсутствие общения может привести к большому количеству заблуждений в команде или в рамках проекта. Когда я выходил из стадии стажера-разработчика, нам нужно было продемонстрировать нашу работу клиенту. Бэкенд-команде пришлось в последний момент внести некоторые изменения в функциональность, и они передали их мобильной команде, но не сообщили об этом веб-команде, ожидая, что они будут переданы. В итоге это вызвало много шума.
Убедитесь, что все доведено до команды должным образом, и избегайте недопонимания. Если вы или команда считаете, что продукт не в лучшей форме для презентации, обязательно попросите о продлении, взяв на себя ответственность за то, что произошло, и убедившись, что это не повторится.
Если мы можем принять и гордиться своими способностями, мы должны принять и честно признать свои недостатки.
Предполагая ситуацию, когда вы не можете решить проблему из-за нехватки ресурсов или любой другой проблемы, избегайте представления проблемы/недостатка, с которым вы столкнулись, для данного описания проблемы. Лучше укажите причины, по которым вы не можете их решить, и предложите им альтернативные решения.
Как избежать технических долгов — энтропия программного обеспечения
Когда вы работаете в команде, вы являетесь частью группы, плывущей в одной лодке для создания продукта. Утечка на лодке (аналогично неправильному решению или коду, который вы поместили в кодовую базу) может привести к тому, что лодка сгниет (технический долг) и утонет, в результате чего лодка утонет вместе с людьми в ней.
Мы обязаны исправить эти утечки в первую очередь, когда мы это поняли. Не оставляйте такие лазейки открытыми, даже если крайний срок близок. Если это не серьезно, добавьте ToDo и исправьте это позже.
В одном из проектов, над которым я работал, мы изначально не структурировали код, когда нам приходилось иметь дело с 2/3 сервисами, из-за нехватки времени. По мере того, как мы продолжали создавать функции поверх них, мы получили 12 сервисов и целую кодовую базу, которую невозможно было восстановить, и, в конце концов, нам пришлось структурировать ее за один раз, что было очень мучительно.
Проявите инициативу, будьте катализатором
Иногда бывает так, что мы видим какой-то грязный код. Когда это произойдет, постарайтесь донести это до своей команды. Если ограничение по времени не позволяет команде поработать над этим и исправить его, лучшее, что вы можете сделать, это отметить его.
В ситуации, когда куски кода таковы, что вам нужно их исправить (серьезная ошибка), сообщите об этом команда, возьмите на себя инициативу и ответственность за исправление неработающего кода и его проверку.
Садоводство — ближайшая аналогия процессу развития. Точно так же, как вы однажды посадили саженец и вам нужно заботиться о нем каждый день, так же, как вы создаете код, следите за тем, чтобы ни одна часть кодовой базы не гнила. После того, как вы разработали программное обеспечение, необходимо тщательно его обеспечить и поддерживать.
Всякий раз, когда появляются новые требования, убедитесь, что разработка новой функции не повлияет на существующую функциональность и не вызовет значительных изменений в ней. Кроме того, убедитесь, что добавление нового требования выполнено таким образом, что остается место для другого набора новых требований.
Достаточно хорошо недостаточно хорошо
Как мы можем оценить, достаточно ли хорош продукт/программное обеспечение, которое мы создаем?
Достаточно хорошо может иметь два значения:
- Полностью удовлетворительно: требования выполнены, ожидания удовлетворены, основная проблема решена.
- Вряд ли адекватно: самый низкий уровень производительности, который не считается сбоем.
«Достаточно хорошо» — это не «Достаточно хорошо» в том смысле, что «Полностью удовлетворительно» — это не то же самое, что « Едва адекватно».
«Как мы можем знать, достаточно ли это хорошо? ”
Идеальное программное обеспечение — это миф. Возможно, ключом к правильному балансу является понимание восприятия пользователя и заинтересованной стороны.
Программное обеспечение/продукты, которые вы создаете, будут использоваться определенным набором пользователей или обычными пользователями. Всегда лучше получать отзывы от конечных пользователей об их пользовательском опыте. Мы можем выпустить бета-версию (кандидат на выпуск) и предоставить ее вашим заинтересованным сторонам, другим членам команды и, возможно, конечным пользователям для обратной связи.
Как я уже говорил, идеальное программное обеспечение — это миф. Несмотря на то, что это миф, существует то, что мы называем минимально жизнеспособным продуктом (MVP). Каждый продукт, который вы создаете, будет иметь минимальную жизнеспособность, чтобы его можно было принять в качестве функционального продукта.
Лучше всего MVP можно описать как промежуточную точку между более ранними стадиями процесса разработки и конечным продуктом, отвечающую всем основным требованиям продукта.
Предположим, что особняк находится в стадии строительства, изначально, когда особняк находится в стадии строительства, вам не очень удобно оставаться в нем. Но по мере того, как строительство особняка завершается необходимыми столярными работами, он становится достаточно пригодным (жизнеспособным), чтобы вы могли остаться.
Точно так же, когда продукт решает основные потребности данной постановки задачи, его можно рассматривать как минимально жизнеспособный продукт.
«Apple выпустила первую версию Hypercard с примерно 500 известными ошибками, но продукт имел оглушительный успех. Команда контроля качества Hypercard выбрала правильные ошибки для поставки. Они также выбрали правильные качества… важно не количество ошибок, а эффект от каждой ошибки. ”
- Джеймс Бах, автор термина Достаточно хорошее программное обеспечение.
По мере того, как мы продвигались вперед, определенно должна была возникнуть ситуация, когда вы могли бы добавить некоторые функции в качестве дополнения, даже не упоминая их в требованиях, основанных на ваших астрологических предположениях.
Надстройка, которую вы добавляете в проект, может быть единственной вещью, которая не нужна и разрушает качество или стандарты проекта.
Определите ожидания, основанные на графике времени и предоставленных ресурсах. Дайте лучшее программистам, конечным пользователям и будущим специалистам по сопровождению кода. Ничто не всегда идеально. И самое главное, мы должны знать меру. Не убивайте хорошую программу чрезмерной инженерией.
Портфель знаний, долгосрочные инвестиции
Как вы все знаете, индустрия программного обеспечения и технологий — это постоянно меняющийся ландшафт, в котором развиваются технологии и наука, лежащие в основе технологий. С темпами эволюции так же важно, как быть экспертом в области определенной технологии, так же важно быть в курсе этой технологии.
Если вы не будете в курсе технологий, над которыми работаете, со временем вас будут считать устаревшим ресурсом.
Инвестиции в портфель знаний — это тип инвестиций с гарантированной рентабельностью.
«Инвестиции в знания всегда приносят наибольший доход».
— Бенджамин Франклин
Рассматривая Портфель знаний как инвестиции, можно разделить инвестиции на два типа:
- Инвестиции с низким уровнем риска и высоким вознаграждением
- Высокий риск, высокая прибыль
Инвестиции с низким уровнем риска и высоким вознаграждением — это виды инвестиций, при которых вы тратите свое время на обучение и оттачивание своих навыков в технологии, которой вы владеете.
С другой стороны, инвестиции с высоким риском и высоким вознаграждением — это инвестиции в портфель знаний, когда вы не уверены в будущем этой технологии, но в настоящее время находитесь в тренде.
Вы должны стремиться находить новые технологии и изучать их до того, как они станут популярными.
«Изучение Java, когда она впервые появилась, возможно, было рискованным, но оно хорошо окупилось для первых последователей, которые сейчас находятся на вершине этой области. ”
— Программист-прагматик
Продолжайте регулярно инвестировать в различные технологии. Всегда оставайтесь в духе изучения новых вещей, которые могут научить вас мыслить нестандартно.
Всегда будьте скептичны и анализируйте то, о чем вы слышали или читали.
Связь, смертельное оружие
Коммуникация — важный фактор, который мы, как разработчики, иногда не можем реализовать. Коммуникация – это искусство передачи информации, идей и отношения от одного человека к другому. Коммуникация – это процесс осмысленного взаимодействия между людьми.
Как разработчику, нам приходится общаться на разных уровнях, начиная от общения внутри команды и заканчивая общением с клиентом.
Большую часть времени нам не удается определить и понять принцип МУДРОСТИ, лежащий в основе общения.
Один из самых важных факторов, играющих жизненно важную роль в понимании того, кому вы передаете свою идею.
Как владелец продукта, я хотел бы знать о продукте на основе его жизнеспособности и проблемы, которую он решает.
Как разработчик, я хотел бы знать, как мы можем решить постановку задачи или справиться с ней технически.
Как конечный пользователь или клиент, я хотел бы узнать больше о том, как работает продукт и как он отвечает всем моим требованиям.
Это, безусловно, то, что мы всегда упускаем. Несмотря на то, что вы лучший коммуникатор в команде, если вы технически объясняете аспекты и недостатки продуктов клиенту, маловероятно, что они поймут это, если только они не имеют опыта работы в области ИТ или не имеют каких-либо предварительных знаний.
Что касается эффективного общения, слушание также важно, как и передача вашей идеи. Всегда будьте внимательным слушателем.
Наконец, то, как вы сообщаете свою идею другому человеку, способствует эффективному обмену идеями. Каждая встреча не обязательно должна быть своего рода презентацией вашей идеи. Некоторые могут просто отправить по почте протокол встречи и перекрестно проверить его.
И как бы вы это ни делали, убедитесь, что вы делаете это правильно. Даже когда вы пишете электронные письма или протоколы собраний, убедитесь, что в них нет грамматических или орфографических ошибок.
Это очень важно, потому что, когда эти ошибки случаются с клиентом, с которым мы работаем, это больше говорит о фирме, которую вы представляете, а не только о вас самих. Вот почему необходимо быть осторожным с этими мельчайшими узлами.
Примечание. Общение — это не только то, что вы говорите. Это о том, что вы говорите и как вы
Всегда отвечайте на электронные письма, пропущенные звонки, сообщения в Slack и т. д.
Примечание. Вам не нужно немедленно реагировать на все!
Документация — это еще одно средство коммуникации, в основном письменное доказательство потока функциональности процесса. В индустрии программного обеспечения и технологий документация играет важную роль в сохранении требований к конечной функциональности.
Всегда убедитесь, что вы документируете протокол каждой встречи с клиентом и внутри команды.
Я знаю, что это был немного более длинный пост, чем ожидалось. Если вы зашли так далеко, я ценю ваше терпение и благодарю вас за ваше время. У меня было слишком много мыслей, чтобы их изложить, но помещать их все в один пост, возможно, было неправильной идеей. В любом случае, завершая пост, эти простые детские шаги являются фундаментальной этикой, которая выделит вас среди остальных разработчиков. Как разработчик, мы должны и должны стремиться быть лучше, чем были вчера. Это был мой первый шаг к прагматизму, и, думаю, он мог бы стать и вашим.
Я надеюсь, что эта статья помогла разобраться в тех мелочах, которые вы упустили. Оставайтесь с нами, чтобы узнать больше.
Счастливого обучения! :)
