Buoni ingegneri, cattivi ingegneri e cattivi ingegneri: un aneddoto per i leader dei dati | di Ella Pham | Novembre 2023 | Intelligenza-Artificiale

La mia struttura d’oro per distinguere gli ingegneri buoni, cattivi e cattivi in ​​tutti i campi, compresi i dati

Ingegnere significa progettare o costruire qualcosa utilizzando scientifico principi— Dizionario Cambridge.

A tutti noi piace molto bravi ingegnericostruiscono fantastici ponti, strade, razzi, applicazioni e strutture dati che rendono la nostra vita più semplice e piacevole ogni giorno.

Con la stessa logica, cattivi ingegneri non migliorerà molto la vita. Se li assumiamo, progetteranno e costruiranno qualcosa, ma impiegheranno più tempo, denaro ed energia.

Ma sai anche che al di fuori dello spettro del bene e del male ce ne sono anche ingegneri malvagila cui mentalità non è costruire, ma fare non costruire.

Essendo io stesso un ingegnere e avendo lavorato con più team di ingegneri indossando i panni del proprietario del prodotto/responsabile del progetto, la totalità delle mie esperienze mi ha detto qualcosa sugli ingegneri buoni, cattivi e cattivi. Amo i buoni ingegneri, ho empatia per i cattivi ingegneri e disprezzo gli ingegneri malvagi.

Alla fine di questo post te lo dirò fondamentalmente, quali sono le differenze tra questi tipi di ingegneri. Ma prima, raccontiamo la storia da una prospettiva più aneddotica.

Riflettendo sulle tue esperienze e conoscenze del mondo dell’ingegneria, quali pensi siano i comportamenti comuni degli ingegneri buoni, cattivi e cattivi?

Di seguito sono riportate le mie osservazioni:

Buoni ingegneri:

• Riconoscono i problemi
• Risolvono i problemi utilizzando un approccio sostenibile
• Risolvono anche altri problemi relativi alla causa principale identificata

Cattivi ingegneri:

• Riconoscono i problemi
• Risolvono il problema a breve termine
• Creano più problemi risolvendo il problema originale

Ingegneri malvagi:

• Fanno finta di non vedere i problemi

Vorrei rendere più semplice immaginare questi tre personaggi di ingegnere descrivendo un esempio concreto nel mondo dell’ingegneria dei dati.

Prendiamo un ingegnere dei dati che costruisce una pipeline, che copia una serie di tabelle di dati grezzi da un data warehouse transazionale in un contenitore nel cloud. Seguendo l’architettura a medaglione, in cui i dati passano attraverso gli strati bronzo, argento e oro, prima puliscono i dati e li scaricano in una serie di tabelle con strati bronzo nella data Lakehouse designata. Successivamente, normalizzano la tabella nello strato d’argento e stabiliscono anche relazioni tra loro. Infine, uniscono più tabelle in una vista e creano nuove funzionalità per rappresentare le metriche aziendali da inserire nelle dashboard di Tableau.

Durante il test dei dashboard, si nota che in alcuni record mancano valori per una determinata colonna. Gli utenti aziendali sono preoccupati poiché vedono più del 50% dei record con dati mancanti per quella colonna, ma riconoscono anche che i dati potrebbero essere incompleti alla fonte. Ora gli ingegneri dovranno indagare e risolvere il problema.

Un buon ingegnere lo farà:

• Innanzitutto sanno molto bene come quella colonna si trasformò dallo strato di bronzo allo strato d’oro e d’argento. In altre parole, conosceranno l’esatta derivazione dei dati della colonna con i dati mancanti.
• Identificare un record di esempio con dati mancanti nel gold layer, ma con dati all’origine per quella colonna. Se non riescono a identificare alcun dato nell’intera popolazione, dichiarano che i dati stessi sono incompleti.
• Se viene identificato un record valido con dati mancanti, applica nuovamente manualmente la logica di trasformazione su quel record di esempio per vedere perché i dati per quella colonna non sono stati ricevuti. Qui ci saranno 2 scenari:
• Scenario 1: il record campionato contiene alcune caratteristiche impreviste, che rendono i valori delle colonne esclusi dal gold layer. In breve, questo è un progetto problema. In questo scenario, un buon ingegnere discuterà di queste caratteristiche inaspettate con il proprietario del prodotto e determinerà un piano di trattamento per esse. O decideranno di poter tranquillamente ignorare questo sottoinsieme della popolazione, poiché i dati con queste caratteristiche non sono rilevanti per l’obiettivo aziendale; Oppure troveranno una logica di trasformazione personalizzata per loro, al fine di inserire i dati.
• Scenario 2: il valore della colonna emerge nella trasformazione manuale, ciò significa che la percezione della derivazione dei dati iniziale è errata. In breve, questo è un esecuzione problema. Il buon ingegnere tornerà per verificare cosa sta facendo la pipeline di dati o quale sia effettivamente la derivazione dei dati. Quindi ripetono il resto dei passaggi.

Un cattivo ingegnere:

• Avere una scarsa comprensione della derivazione dei dati.
• Identificare un record di esempio con dati mancanti nel gold layer, ma con dati all’origine per quella colonna. Se non riescono a identificare alcun record, dichiarano che i dati stessi sono incompleti.
• Se viene identificato un record valido con dati mancanti, provare ad applicare una trasformazione logica manuale su un record con dati mancanti per vedere perché la colonna non viene visualizzata.
• Trarre conclusioni errate sul motivo per cui i valori delle colonne non vengono visualizzati, principalmente perché la loro comprensione della derivazione dei dati e della pipeline di dati complessiva è sbagliata.
• Se la loro osservazione li porta alla conclusione dello Scenario 1 come sopra (un problema di progettazione), informeranno il team che si tratta di un problema di qualità dei dati e chiuderanno la giornata. Presumono che il design sia perfetto e che non ci sia nulla da migliorare qui.
• Un ingegnere più etico ma anche più disastroso tenterà di elaborare un trattamento personalizzato per i record interessati (ad esempio modificando il design), tuttavia, creerà un pasticcio ancora più grande poiché la loro percezione della derivazione dei dati non è corretta fin dall’inizio.
• Se la loro osservazione li porta alla conclusione dello Scenario 2 (un problema di esecuzione), torneranno indietro e studieranno il divario tra la pipeline di dati implementata e quella progettata e potrebbero effettivamente trovare la soluzione giusta la prossima volta.

Cosa farà un ingegnere malvagio?

• Potrebbero o meno conoscere la corretta provenienza dei dati, questo è irrilevante.
• Dicono che poiché i dati per la colonna sono incompleti dalla fonte (in base a ciò che l’azienda ha detto loro), ovviamente, i dati mancheranno nel dashboard.
• Quindi presumono che non ci siano problemi con la pipeline dei dati, poiché i dati sono intrinsecamente incompleti.
• Finiscono la giornata e tornano a casa.

Spero che il mio esempio sopra ti abbia dato una rappresentazione più chiara dei tre tipi di ingegneri. Tuttavia, l’esempio può aiutarti a lungo termine solo dopo aver compreso le differenze fondamentali tra ingegneri buoni, cattivi e cattivi. Per differenziarli sistematicamente tra i tre, è fondamentale scoprirne le caratteristiche essenziali:

Ecco la mia opinione a riguardo:

• Un buon ingegnere possiede 3 qualità: conoscenze eccezionali, impegno per la veritàE impegno per il risultato.
• Manca anche un cattivo ingegnere conoscenze eccezionali o cimpegno per i risultati. Tuttavia, hanno un livello medio di impegno nei confronti della verità.
• Un ingegnere malvagio non ha nulla o poco impegno per la verità. Per loro il risultato non ha alcuna importanza. Si preoccupano di altri aspetti (magari dell’apparenza dei risultati), oppure non si preoccupano di nulla. È raro che un ingegnere malvagio abbia una conoscenza eccezionale, ma se lo fa, non è comunque rilevante, poiché, ancora una volta, non si preoccupano né della verità, né del risultato.

Alcuni di voi potrebbero scoprire che qui non esiste una chiara distinzione tra gli ingegneri cattivi e quelli malvagi. Normalmente, il male spesso fa del male, quindi ti aspetteresti che un ingegnere malvagio introduca codice dannoso con cattive intenzioni o che copra i propri errori passati. Sono d’accordo. Tuttavia, ciò che vorrei evidenziare qui è dove traccio il confine tra male e male:

Non è necessaria necessariamente un’azione dannosa affinché l’ingegnere sia malvagio, una volta che è l’ingegnere inizia a ignorare la verità davanti ai loro occhi (cioè fingendo di non vedere i problemi), entrano nel regno del male.

E più fatti ignorano, più diventeranno malvagi.

Quindi la prossima volta, quando incontri un ingegnere, cerca gli indicatori di tutte e tre queste qualità. Non essere ancora così sicuro se trovi solo un elenco di credenziali, certificazioni o decenni di esperienza: sono solo indicatori di conoscenze eccezionali.

L’impegno è un attivo stato mentale. È necessario trovare indicatori di impegno per la verità o risultati indagine attenta di modelli comportamentali storici, analisi continua del proprio processo di pensiero, e osservazioni delle loro reazioni alle sfide.

Trascurare la ricerca di indicatori di impegno o verità significa trascurare il proprio successo e lasciare che sia deciso da ingegneri apparentemente “ben informati”.

Alla fine, si tratta di essere responsabile della propria decisione di assunzione/partnership. Se non vuoi sprecare i tuoi soldi, inizia a identificare gli ingegneri buoni, cattivi e malvagi.

***

Ciao, se stai leggendo questo articolo, è probabile che ti interessino i dati. Pensi che ci siano valori inestimabili che possono essere estratti dai dati e sei ansioso di trovare le migliori strategie, pratiche di implementazione e strumenti per estrarre quanto più valore possibile dalle risorse di dati della tua organizzazione (o tue).

Se è vero, dai un’occhiata alla mia newsletter settimanale: Dati e oltre la spedizione. Ogni edizione ti offrirà contenuti approfonditi dalla community di Data, curati e riepilogati per offrirti prospettive nuove, ben articolate e pratiche sulla missione, le visioni, le strategie e gli strumenti di Data Leader veramente efficaci.