Чем вы занимаетесь как разработчик программного обеспечения?

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

Наша работа - писать код? Мы определенно начинаем так думать, по большей части, не так ли. Просто приди, напиши мой код и иди домой. Если вы сейчас находитесь здесь, продолжайте читать.

Я собираюсь поразить тебя.

Написание кода - это то, как мы обычно делаем свою работу, но написание кода - это не сама работа.

Итак, в чем наша работа как разработчиков?

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

Они были так близки к истине, но все же в конце занервничали и должны были оговорить свое утверждение.

Почему «с кодом»?

Почему мы думаем, что если мы не пишем код, мы не делаем свою работу? Неуверенность? Недоразумение? Руководство не знает, зачем даже технический персонал?

Наверное, все вышеперечисленное, а некоторые вещи я еще не придумал. Люди - существа сложные.

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

Позвольте мне продемонстрировать свою точку зрения на примере из моей истории.

Моя любимая системная интеграция

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

Мой ответ может показаться легкомысленным, но он на 100% честен. Когда меня спрашивают: «Возможно ли это вообще?» Я всегда отвечаю: «Все возможно. Сможем ли мы это сделать, зависит от денежных и временных затрат ».

Звучит намного лучше, чем «Я не знаю, но я узнаю», но означает примерно то же самое.

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

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

Совершенно нет ничего невозможного

Если вы не берете ничего другого из этой статьи, примите следующее: нет ничего невозможного.

Когда вы начинаете копаться в проектах, которые люди считают невозможными, вы сталкиваетесь с теми же сценариями:

  • Им было лень делать проект
  • Они были слишком неопытны или недостаточно уполномочены, чтобы завершить проект.
  • Они создали проект, но пропустили требование, поэтому заявили, что это требование невозможно избежать переписывания.

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

На самом деле посмотрите на сценарии. Каждый «невозможный» проект сводится к этому. Я разбил первый и третий на отдельные сценарии, но можно утверждать, что на самом деле это один и тот же сценарий.

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

Невозможная интеграция финансового отчета

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

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

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

Финансы.

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

Второй намек - это основная суть проекта. Это был простой проект сопоставления файла CSV с API SOAP. То, что мы делали сотни раз раньше.

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

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

40 часов в месяц, 12 месяцев в году, то есть 480 часов в год.

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

Это дает нам около 10 000 долларов в год, затрачиваемых на ввод данных.

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

Начиная

Первое, что я делаю при любой системной интеграции, - это изучаю систему. Я знаю, что вы прямо сейчас думаете: «Хорошо, давайте прочтем документацию по API». Откуда мне знать? Потому что я тоже так думал, когда начинал.

Я больше не знаю. Это шаг, но это не первый шаг.

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

После этого я «пролистываю», где буквально вхожу в систему, и щелкаю по системе, заглядывая в каждый укромный уголок. Если есть форма, и я могу ее безопасно отправить, я делаю это.

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

Именно так я закончил этот проект без единой строчки кода.

Решение

Чтобы решить любую проблему, будь то код или нет, вам нужно знать свои системы от и до.

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

Я провел целый день, изменяя настройки и выполняя импорт, пока не зафиксировал факт: у меня не было абсолютно никакого способа взять файлы, которые были, и загрузить их как есть в нашу финансовую систему.

В них просто не было необходимых мне данных.

Значит, это было невозможно, правда?

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

Я сидел со своим менеджером проекта. Мы обсудили ситуацию, что я нашел и что мне нужно. Я объяснил ей, что нет необходимости в дорогостоящем проекте кода, когда мы можем просто исправить проблему с данными.

Создание индивидуального отчета обошлось нам в 2000 долларов. Но этот отчет появился через неделю, и я объяснил нашей финансовой команде, как использовать импортера.

Процесс, который раньше занимал неделю, теперь занимает минуту.

Мы сэкономили на этом отчете за 3 месяца.

Несколько советов, как сделать это для себя

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

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

В начале проекта меня волнуют только входы и выходы. Как мы доберемся из точки А в точку Б, не имеет значения.

Затем я ищу любые существующие системы, которые будут делать именно то, что мы ищем. Если это не удается, я ищу все, что поможет нам на 90% пути, как я обнаружил с импортером и ошибочным входным файлом.

В противном случае этого и только тогда я рассмотрю индивидуальное решение.

Дело не в том, что я не хочу писать код. Я люблю писать код. Я люблю писать сложный код.

Пользовательский код стоит дорого

Пользовательский код стоит больше денег, чем что-либо другое, но это только начало.

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

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

Но самое главное, я не пишу собственный код, потому что ...

Ваша работа - решать проблемы, а не писать код

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

Вот и все.

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

Найти готовое решение, которое поможет вам на 100%, - это все три из них.

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

Если у вас есть уверенность в том, что вы добьетесь успеха по первым двум параметрам, то, когда вы подойдете к своему руководителю и скажете: «Послушайте, этот проект? Вот сколько времени это займет, и этого не избежать. Это полная кастомная сборка ».

Они. Воля. Слушать.

Риски всегда делать нестандартный код

Риски, связанные с постоянным переходом к пользовательскому коду, невозможно переоценить, но позвольте мне подробно рассказать о них в еще одном анекдоте.

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

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

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

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

Это трудное положение, и компания разделяет его бремя.

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

Ключевые выводы

Если вы что-нибудь из этого уберете, возьмите это:

  • Нет ничего невозможного. Что-то слишком дорогое, чтобы возиться с ним.
  • Нет ничего важнее успеха проекта, кроме успеха компании.
  • Если вы сможете четко следовать обоим из вышеперечисленных, вы добьетесь успеха как разработчик программного обеспечения.
  • Ваша работа как разработчика программного обеспечения - решать проблемы. Как вы это делаете, не имеет значения, пока проблема решена.

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