Хорошие инженеры, плохие инженеры и злые инженеры – анекдот для руководителей данных

Прекрасные инженеры, менее удачные и злобные - анекдот для руководителей данных

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

Картинка от автора (сгенерирована с помощью приложения Canva’s Magic Media)

Инженерирование – это проектирование или создание чего-либо с использованием научных принципов – Cambridge Dictionary.

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

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

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

Как инженер сам по себе и человек, работавший с несколькими инженерными командами в роли владельца продукта/менеджера проекта, мои опыты подсказывают мне что-то о хороших, плохих и злых инженерах. Я люблю хороших инженеров, сочувствую плохим и презираю злых инженеров.

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

Некоторые общие наблюдения о хороших, плохих и злых инженерах

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

Ниже приведены мои наблюдения:

Хорошие инженеры:

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

Плохие инженеры:

  • Они распознают проблемы
  • Они решают проблему на краткосрочный период
  • Они создают больше проблем, решая исходную проблему

Злые инженеры:

  • Они притворяются, что не видят проблемы

Анализ конкретного примера

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

Представьте себе инженера по работе с данными, который создает конвейер, копирующий наборы необработанных данных из транзакционного хранилища данных в контейнер в облаке. Следуя архитектуре медальона, где данные проходят через слои бронзы, серебра и золота, он сначала очищает данные и переносит их в набор таблиц слоя бронзы в назначенном озере данных. Затем он нормализует таблицу в слое серебра, а также устанавливает связи между ними. Наконец, он объединяет несколько таблиц в представлении и создает новые функции, отображающие бизнес-метрики для подачи на панели Tableau.

В процессе тестирования панелей отмечено, что в некоторых записях отсутствуют значения для определенного столбца. Бизнес-пользователи беспокоятся, так как видят, что более 50% записей не содержат данных для этого столбца, но они также признают, что данные могут быть неполными на источнике. Теперь инженерам надо провести исследование и устранить проблему.

Хороший инженер будет:

  • Во-первых, он очень хорошо знает, как этот столбец был преобразован из слоя бронзы в слоя золота и серебра. Другими словами, он знает точную цепочку передачи данных для столбца с отсутствующими данными.
  • Он определит пример записи с отсутствующими данными в слое золота, но с данными на источнике для этого столбца. Если он не может найти ни одной записи во всей выборке, он объявит, что сами данные неполные.
  • Если он обнаружит действительную запись с отсутствующими данными, он вручную применит логику преобразования к этой примерной записи, чтобы понять, почему данные для этого столбца не прошли. Здесь есть 2 сценария:
  • Сценарий 1: примерная запись содержит некоторые неожиданные характеристики, из-за которых значения ее столбцов были исключены из слоя золота. Короче говоря, это проблема дизайна. В этом сценарии хороший инженер обсудит эти неожиданные характеристики с владельцем продукта и определит план обработки данных для них. Либо он решит, что эту подгруппу населения можно безопасно игнорировать, поскольку данные с этими характеристиками не являются значимыми для бизнес-целей; либо он придумает специальную логику преобразования для них для внесения данных.
  • Сценарий 2: значение столбца поступает при ручном преобразовании, что значит, что его восприятие исходной цепочки данных неверно. В коротких словах, это проблема исполнения. Хороший инженер перепроверит, что делает конвейер данных или что на самом деле является цепочкой данных. Затем он повторит оставшиеся шаги.

Плохой инженер будет:

  • Плохо понимать цепочку данных.
  • Определять пример записи с отсутствующими данными в основном слое, но имеющей данные в источнике для этой колонки. Если они не могут определить ни одну запись, они объявляют, что сами данные являются неполными.
  • Если обнаруживается действительная запись с отсутствующими данными, они пытаются применить ручную логическую трансформацию к записи с отсутствующими данными, чтобы понять, почему столбец не проходит.
  • Получают неверные выводы о том, почему значения столбцов не проходят, главным образом, из-за неправильного понимания цепочки данных и общего конвейера обработки данных.
  • Если их наблюдение приводит их к выводу Сценария 1 выше (проблема проектирования), они информируют команду о том, что это проблема качества данных и считают, что все закончено. Они предполагают, что проектирование идеально и здесь нечего улучшать.
  • Более этичный, но также более катастрофический инженер будет пытаться прийти к специальной обработке для затронутых записей (т.е. изменить проектирование), однако он создает еще больший беспорядок, так как его восприятие цепочки данных изначально неправильно.
  • Если их наблюдение приводит их к заключению Сценария 2 (проблема выполнения), они вернутся и изучат пробел между реализованным и разработанным конвейером данных и, возможно, действительно найдут правильное решение в следующий раз.

Что будет делать злой инженер?

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

Основные различия между хорошими, плохими и злыми инженерами

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

Вот мое мнение об этом:

  • Хороший инженер обладает 3 качествами: исключительными знаниями, преданностью правде и преданностью результату.
  • Плохой инженер лишен либо исключительных знаний, либо преданности результату. Однако у них есть уровень преданности правде VoAGI.
  • Злой инженер не имеет или имеет мало преданности правде. Результат для них не имеет значения. Они заботятся о других аспектах (возможно, о внешнем виде результатов), или им вообще не имеет значения. У злого инженера редко бывают исключительные знания, но если они есть, то они не имеют значения, поскольку имравидно, что их не волнует ни правда, ни результат.

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

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

Чем больше фактов они игнорируют, тем больше злыми они становятся.

Как определить хороших, плохих и злых инженеров?

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

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

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

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

***

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

Если это так, тогда ознакомьтесь с моим еженедельным информационным бюллетенем – Data & Beyond Dispatch. Каждый выпуск принесет вам интересный контент из сообщества данных, отобранный и подведенный итоги, чтобы дать вам свежие, хорошо структурированные и практические точки зрения на миссию, видение, стратегии и инструменты действительно эффективных лидеров данных.