良いエンジニア、悪いエンジニア、悪意のあるエンジニア──データリーダーのための逸話
「優れたエンジニア、劣ったエンジニア、悪質なエンジニア──データリーダーに贈る逸話」
私の黄金のフレームワーク:すべての分野、データを含む、優れた、悪い、邪悪なエンジニアを区別するために
エンジニアリングとは、科学的な原則を使用して何かを設計または構築することです- Cambridge Dictionary。
私たちは皆、優れたエンジニアを愛しています。彼らは素晴らしい橋、道路、ロケット、アプリケーション、そしてデータ構造を構築し、私たちの生活を毎日より簡単で楽しいものにしてくれます。
同じロジックで、悪いエンジニアはあまり生活を向上させません。彼らを雇うと、何かを設計して構築しますが、私たちの時間、お金、エネルギーをより多く取られます。
しかし、良いと悪いの範囲外にも、邪悪なエンジニアと呼ばれる人々が存在することを知っていますか。彼らの考え方は構築することではなく、構築しないことです。
- 「マルチコードダイアグラムの紹介:複雑なセットの関係を視覚化する」
- Pythonコードの行数を100行未満で使用した動的プログラミングによる在庫最適化
- LangChainの発見:ドキュメントとのチャット、チャットボット翻訳、ウィキペディアとのチャット、合成データ生成
私自身もエンジニアであり、製品所有者/プロジェクトマネージャの役割を果たしながら複数のエンジニアリングチームと一緒に働いている経験の全体から、良いエンジニア、悪いエンジニア、邪悪なエンジニアについての何かを教えてくれました。私は良いエンジニアを愛し、悪いエンジニアに共感し、邪悪なエンジニアを軽蔑します。
この記事の最後には、基本的に、このようなタイプのエンジニアの違いは何かを伝えます。しかし最初に、より逸話的な視点から物語を語ります。
優れた、悪い、邪悪なエンジニアの一般的な観察
自分自身の経験やエンジニアリングの世界の知識を振り返り、良い、悪い、邪悪なエンジニアの共通の行動は何だと思いますか?
以下は私の観察です:
良いエンジニア:
- 彼らは問題を認識します
- 持続可能なアプローチで問題を解決します
- 同定した根本的な原因に関連する他の問題も解決します
悪いエンジニア:
- 彼らは問題を認識します
- 一時的に問題を解決します
- 元の問題を解決することで他の問題を生み出します
邪悪なエンジニア:
- 彼らは問題を見ないふりをします
具体例を見てみましょう
データエンジニアリングの世界で、これらの3つのエンジニアのパーソナリティを具体的な例で説明することで、イメージしやすくします。
クラウド内の指定されたデータレイクに、トランザクションデータウェアハウスから一連の生データテーブルをコピーするパイプラインを構築しているデータエンジニアを想像してみてください。データはブロンズ、シルバー、ゴールドのレイヤーを通過するメダリオンアーキテクチャに従って処理され、最初にデータをクリーンアップして、ブロンズレイヤーテーブルの一連のセットにダンプします。次に、テーブルをシルバーレイヤーで正規化し、それらの間に関係を確立します。最後に、マルチプルテーブルを結合してビューで新しい特徴を作成し、Tableauのダッシュボードにフィードするためのビジネスメトリックを表現します。
ダッシュボードのテスト中に、一部のレコードの特定の列に欠損値があることがわかりました。ビジネスユーザーは、その列のデータの50%以上が欠損していることを心配していますが、データはソースで不完全かもしれないとも認識しています。ここで、エンジニアは問題を調査して解決する必要があります。
良いエンジニアは:
- まず、その列がブロンズからゴールドまでどのように変換されたかを非常によく知っています。言い換えれば、欠損データのある列の正確なデータラインエージが分かります。
- ゴールドレイヤーの欠損データがあるサンプルレコードを特定しますが、その列のソースにデータがある場合。集団全体でレコードを特定できない場合は、データ自体が不完全であることを宣言します。
- 欠損データがある有効なレコードが特定された場合、彼らはそのサンプルレコードで変換ロジックを再度手動で適用し、なぜその列のデータが伝わらなかったのかを確認します。以下に2つのシナリオがあります:
- シナリオ1:サンプルレコードには予期しない特徴がいくつか含まれており、その列の値がゴールドレイヤーから除外されている場合。つまり、これは設計の問題です。この場合、良いエンジニアはこれらの予期しない特徴を製品所有者と共有し、それらに対する処理計画を決定します。これらの特徴を持つデータはビジネス目標に関連性がないため、この人口のサブセットを安全に無視することを決定するか、それらに対してカスタム変換ロジックを考案します。
- シナリオ2:列の値が手動変換で伝わる場合、初期のデータラインエージの認識が誤っていることを意味します。つまり、これは実行の問題です。良いエンジニアはデータパイプラインや実際のデータラインエージを再確認し、残りの手順を繰り返します。
悪いエンジニアは以下のようなことをします:
- データの経緯を十分に理解していない。
- ゴールドレイヤーのサンプルレコードに欠落したデータがあり、ソースの該当の列にデータがある場合、それらのレコードを特定しようとせず、データ自体が不完全であると結論づける。
- 欠落したデータを持つ有効なレコードを特定した場合、欠落したデータを持つレコードに手動のロジック変換を適用し、なぜ列が表示されないのかを調べる。
- データの経緯と全体的なデータパイプラインに対する理解が誤っているため、なぜ列の値が表示されないのかについて間違った結論を出す。
- 上記のようなシナリオ1の結論(設計上の問題)に至った場合、これをデータ品質の問題とし、それで終わりにする。彼らは設計が完璧であり改善する必要がないと仮定している。
- より倫理的ですが、より壊滅的なエンジニアは、影響を受けたレコードにカスタム処理(つまり、設計の変更)を試みるかもしれませんが、データの経緯の認識が最初から間違っているため、かえって問題を増やすことになります。
- 彼らの観察がシナリオ2の結論(実行上の問題)に至った場合、実装されたデータパイプラインと設計されたデータパイプラインのギャップを調べ直し、次回は正しい解決策を見つけ出すかもしれません。
悪徳エンジニアは何をするのでしょうか?
- 正しいデータの経緯を知っているかどうかは関係ありません。
- ソースからのデータが欠落しているため(ビジネスからの情報に基づく)、もちろんダッシュボードにもデータが欠落すると結論づける。
- そのため、データパイプラインに問題はなく、データ自体が本来的に不完全であると仮定する。
- それで終わりにして家に帰る。
良いエンジニア、悪いエンジニア、悪徳エンジニアの基本的な違い
上記の例が3種類のエンジニアのより明確な描写を提供したことを願っています。ただし、この例はあなたが良いエンジニア、悪いエンジニア、悪徳エンジニアの基本的な違いを理解してからの長期的な助けとなります。これら3つの異なるタイプを系統的に区別するために、彼らの本質的な特徴を見つけることが重要です:
ここで私の見解を述べます:
- 良いエンジニアは3つの特性を備えています:優れた知識、真実へのコミットメント、結果へのコミットメント。
- 悪いエンジニアは優れた知識または結果へのコミットメントのどちらかが不足しています。ただし、彼らは真実へのコミットメントにおいてはVoAGIレベルのコミットメントを持っています。
- 悪徳エンジニアは真実へのコミットメントがないかほとんどないです。結果は彼らにとって重要ではありません。彼らは他の側面(たとえば結果の外見)に関心があるか、あるいは何にも関心がない可能性があります。悪徳エンジニアが優れた知識を持っていることは稀ですが、それは関係ありません。再び、真実や結果に対して彼らは関心がありません。
一部の人々から、ここでは悪いエンジニアと悪徳エンジニアの間に明確な区別がないと感じるかもしれません。通常、悪は害を与えるものです-つまり、悪意のあるコードを意図的に導入するか、過去のミスを隠すことを悪徳エンジニアが予想されます。それに同意します。ただし、ここで私が強調したいのは、悪と悪徳の境界線の設定です:
エンジニアが悪徳になるためには、悪意のある行動が必要ではありません。エンジニアが自分の目の前の真実を無視し始める(つまり、問題を見なかったことにする)とき、彼らは悪徳の領域に足を踏み入れます。
そして彼らが無視する事実が多ければ多いほど、彼らはより悪徳になります。
良いエンジニア、悪いエンジニア、悪徳エンジニアをどのように見分けるか?
次回、エンジニアに出会ったときには、これら3つの特性の指標を探してください。単に資格や認定、数十年の経験のリストを見つけたとしても、まだ確信しないでください-それらは優れた知識の指標に過ぎません。
コミットメントは積極的な心の状態です。真実や結果へのコミットメントの指標を見つけるには、歴史的な行動パターンを慎重に調査し、自分の思考プロセスを継続的に分析し、彼らが直面する課題への反応を観察する必要があります。
コミットメントや真実の兆候を探すことを怠ることは、自分自身の成功を軽視し、それを「知識豊富な」エンジニアに決定させることを意味します。
最終的にこれは、雇用やパートナーシップの決定に対して責任を持つことです。お金を無駄にしたくないのであれば、優れた、悪い、邪悪なエンジニアを見極めることを始めましょう。
***
こんにちは、もしあなたがこれを読んでいるのであれば、あなたはデータに関心を持っているのかもしれません。あなたはデータから抽出できる貴重な価値があると考え、組織(または自身)のデータ資産から可能な限り多くの価値を引き出すための最善の戦略、実装方法、ツールを見つけたいと熱望しています。
もしそうなら、私の週刊ニュースレターをチェックしてみてください – Data & Beyond Dispatch。各号では、データコミュニティからの洞察に基づいた内容を取り上げ、真に効果的なデータリーダーの使命、ビジョン、戦略、ツールボックスについて新鮮で明確で実践的な視点を提供します。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
- 「2024年に必ず試してみるべきトップ15のベクターデータベース」
- 2024年のデータサイエンス向けトップ15のベクトルデータベース:包括的ガイド
- 「RAGを紹介します データソースから自然言語を使用してRAGパイプラインを作成するStreamlitアプリ」
- 「ジョンズホプキンスのこの論文は、時間と望遠鏡を超えて宇宙の発見の確率的カタログマッチングを加速させるデータサイエンスの役割を強調しています」
- データの観察可能性:AI時代の信頼性
- 「AIに関するアレン研究所の研究者らが、大規模なデータセット上での2段階のトレーニングプロセスによって開発された、新しい科学文書の埋め込みモデルであるSPECTER2を開発しました」
- 「PyTorchでのSoft Nearest Neighbor Lossの実装方法」