Используйте эти навыки, чтобы стать лучшим разработчиком, которым вы можете быть!

Обучение программированию — один из лучших навыков, которые вы можете развить как в качестве лидера, так и человека, который может принести реальную пользу компании. Тем не менее, это сложный навык, который требует много разных элементов, чтобы собраться вместе.

Я попытался задокументировать некоторые важные бизнес-уроки, которые я усвоил за последние 20 лет в качестве разработчика программного обеспечения и бизнес-лидера.

Эти уроки должны быть одинаково ценны как для лидеров, так и для разработчиков; это путь к тому, чтобы стать 10-кратным разработчиком с точки зрения ценности для бизнеса.

Научитесь представлять свою работу, чтобы повысить ее ценность для бизнеса.

Самый важный урок, который я могу дать любому другому разработчику программного обеспечения, состоит в том, чтобы научиться представлять свою работу таким образом, чтобы бизнес мог ее воспринять.

Вы несете ответственность за то, чтобы представить результат в наилучшем виде. Маленькие штрихи, направленные на улучшение результата и предоставление чего-то с небольшим количеством полировки, имеют большое значение в глазах других людей.

Например, если вы специалист по данным, то научиться представлять результаты — это то, как вы можете принести наибольшую пользу бизнесу.

Если вы являетесь фронтенд-разработчиком, то представление чего-то, что является незаконченным кодерским искусством, приведет к низкой цене вашей работы.

Я понимаю, что это будет спорно, особенно при представлении работы, которая «еще не закончена». Важно учитывать аудиторию, которой вы демонстрируете; ваша аудитория, вероятно, не будет иметь того же понимания, что и вы, о фоновой работе.

Большинство людей работают визуально при оценке результатов, именно здесь бизнес дает наибольшую обратную связь, и это часто дает непропорциональную ценность для бизнеса по сравнению с фоновой работой, необходимой для доставки.

Убедитесь, что вы выделили достаточно времени, чтобы правильно представить свою работу, и не оставляйте ее до конца. Если вы это сделаете, то это всегда будет ощущаться в спешке, и результат будет страдать.

Большинство программистов имеют естественную склонность начинать заново.

Попросите кого-нибудь посмотреть код другого разработчика, и часто вы получите ответ, что «это дерьмо», «это нужно было сделать по-другому» и т. д. и т. д.

Хотя в некоторых случаях это может быть правдой, одна вещь, которую я усвоил за многие годы, заключается в том, что программисты очень критичны друг к другу. Они делают поспешные суждения, не понимая, сколько времени, усилий и знаний ушло на разработку конкретного фрагмента кода.

Их естественное стремление что-то выбросить и начать заново. Иногда это правильный выбор, а иногда нет.

Как разработчик, вы должны взвесить все за и против переписывания кода:

  • Этот код в настоящее время работает в бизнесе?
  • Критично ли это для ведения бизнеса?
  • Он сломан? Сломанный спектр; некоторый код может работать отлично, но быть исключительно медленным. Это само по себе может классифицировать его как сломанный.
  • Как вы можете поддерживать этот код в будущем?
  • Вы хотите стать «человеком, к которому обращаются» за этим фрагментом кода?

Реальный вопрос, который вы должны себе задать: как замена этого кода повысит ценность вашего бизнеса?

Построить или купить

Приступая к программному проекту, всегда стоит рассмотреть возможность покупки готового решения, а не создание нового решения.

Это дает много преимуществ; это может повлечь за собой первоначальные затраты, но сэкономить значительное время и ресурсы в будущем. Покупка продукта снимает большую часть риска, высвобождает ресурсы разработки для решения других приоритетных задач бизнеса и снижает будущие затраты на обслуживание/управление для команды разработчиков программного обеспечения.

Учитывайте каждую из этих затрат при принятии решения о покупке или строительстве; поддержание внутреннего решения связано со значительными временными и альтернативными затратами.

Большинство компаний не задумываются об использовании библиотеки с открытым исходным кодом, потому что она бесплатна; у них тоже есть скрытые затраты на техническое обслуживание.

Никто не учит вас создавать или покупать, когда вы учитесь программировать. Это жизненно важный инструмент в арсенале разработчика программного обеспечения.

Скорость против качества

При первом рассмотрении проекта одним из важных моментов принятия решения должно быть требуемое качество. В разработке программного обеспечения качество напрямую влияет на скорость доставки.

Есть элементы качества, которые могут быть встроены в автоматизированный процесс для обеспечения минимального стандарта, но есть затраты, связанные с большинством действий, ориентированных на качество.

При оценке качества, необходимого для проекта, следует учитывать:

  • Как долго будет требоваться этот код? Одноразовый код сильно отличается от кода производственного уровня, который должен работать десять лет.
  • Когда бизнесу нужен этот код? При доставке кода, требующего срочности, может быть вполне допустимо накопить некоторый технический долг.
  • Кто является конечным потребителем этого кода? Код для внутреннего использования часто имеет другой стандарт, чем код для клиента.
  • Насколько вероятно, что этот код будет обновлен в будущем? Весь код должен поддерживаться, но некоторый код может нуждаться в регулярном обновлении.
  • Каков риск, связанный с этим кодом? Вероятно ли, что добавление кода нарушит связанный с ним код? Если да, то следует ли применять новый код к тем же (или более высоким) стандартам качества кода?

Бывают случаи, когда вполне допустимо быстро что-то изменить или написать сценарий за десять минут для решения конкретной проблемы.

Точно так же бывают случаи, когда это может быть безрассудным и неприемлемым. Понимая бизнес-требования перед началом проекта, вы можете принять правильное решение о требуемом качестве.

Убедитесь, что вы понимаете бизнес-требования, лежащие в основе проекта разработки программного обеспечения. Он устанавливает правила игры и ожидания от вашей доставки.

Если проблема заключается в том, что «нам нужно добраться из пункта А в пункт Б», существует ряд решений от «арендовать велосипед» до «купить Феррари». Именно с помощью требований вы сможете выяснить, какое решение является наиболее подходящим.

Повторяйте, улучшайте, повторяйте снова

Одна вещь, которую я усвоил, это то, что каждые шесть месяцев в качестве программиста я оглядывался на предыдущую работу и думал, что теперь я сделал бы это по-другому. Это часть процесса обучения, которым вы должны управлять для бизнеса как разработчик.

Не бросайтесь сразу к переписыванию; Когда вы видите возможность улучшить часть кода, рассмотрите ее стратегически:

  • Сэкономит ли это мне время в будущем?
  • Улучшит ли это работу конечного пользователя?
  • Сделает ли это быстрее? Медленный код дорого обходится вам как разработчику (сложно тестировать) и пользователю (тратит время впустую), не говоря уже о затратах ресурсов на хостинг.

Ищите возможности для повторения и улучшения, но делайте это стратегически. Убедитесь, что это добавленная стоимость для вас и бизнеса

Бонусный урок для лидеров

Управление разработчиками программного обеспечения может быть разочаровывающим, захватывающим, полезным и мучительным; часто на одном и том же часовом совещании. Вот бонусный урок для руководителей разработчиков программного обеспечения.

Дайте им пространство для работы, разработка программного обеспечения — это творческое занятие, и вы должны относиться к нему соответствующим образом. Одного правильного решения не существует, часто возникают небольшие препятствия, на решение которых уходят дни, а на решение — минуты.

Обязательно поддерживайте их наилучшим образом, чтобы найти способы помочь им. Вы можете сделать это, предоставив дополнительных опытных разработчиков, когда кто-то борется, или найдя более удобные способы общения с ними (возможно, они предпочитают текстовые, а не устные обсуждения).

Кроме того, не забудьте способствовать улучшению их процессов; большинство разработчиков будут взывать к улучшению процессов разработки. В RazorSecure мы работали над этим, наняв agile-коуча для регулярного управления командой посредством улучшения процессов.

Бонусный урок для разработчиков

Потратьте время на то, чтобы научиться лучше общаться, как в устной, так и в текстовой форме. Разочарование часто является улицей с двусторонним движением; вы можете быть недовольны руководством, и если дело в плохом общении, они могут относиться к вам так же.

Предложите оливковую ветвь и работайте над решением проблемы, а не сосредотачивайтесь на том факте, что проблема существует.

Лучший бизнес-урок, который я могу дать каждому, — это сосредоточиться на добавлении ценности во все, что вы делаете. В большинстве случаев существует компромисс между максимально возможной ценностью и предоставляемой «ценностью за час». В этом разница между 10-кратным разработчиком и средним 10-кратным разработчиком, который обеспечивает максимальную отдачу в час.

Возьмите на себя ответственность за демонстрацию своей ценности и ценности команды, которой вы управляете. Дайте вашим разработчикам программного обеспечения шанс проявить себя.