Abbiamo avuto: $ 100K in crediti GCP, un ingegnere fondatore che aveva costruito sistemi in azienda, e andato sul mercato. Mentre abbiamo trascorso del tempo lottando con ciò che sembrava una pila di tecnologia “non ottimale”, abbiamo perso la cosa più importante: il tempo, l’impulso e strategicamente un’opportunità. Questa storia non riguarda persone senza senso comune. avevo senso comune, e sapevamo che dovremmo mantenere le cose semplici.Ma quando il tuo modello mentale non si adatta alla situazione, tutto il tuo senso comune viene spazzato via. Anche questa non è una storia sulla cattiva ingegneria. Si tratta di come la buona ingegneria uccide le start-up. Come la stessa esperienza che ti rende maggiore diventa la tua più grande responsabilità. Questo articolo presenta Per aiutarti a fare il decisioni e evitare quelle sbagliate che ho fatto. mental models right 
 
 Per chi è questo: ingegneri senior che iniziano o si uniscono alle start-up in fase iniziale.Se hai trascorso 5+ anni in impresa o Big Tech, questo è il tuo avvertimento. Per chi è questo: ingegneri senior che iniziano o si uniscono alle start-up in fase iniziale.Se hai trascorso 5+ anni in impresa o Big Tech, questo è il tuo avvertimento. Per chi è questo: Il modello mentale #1 - L'infrastruttura "gratuita" è la più costosa $100K in crediti GCP sembra un dono, ma è una trappola. Ti spinge verso l'eccesso di ingegneria perché "è già pagato". ottieni istanze di calcolo, bilanciatori di carico, registri dei contenitori e strumenti aziendali che richiedono l'installazione aziendale. Certo, è possibile creare flussi di lavoro "distribuire da GitHub a VM" su GCP/AWS/Azure. Alcuni prodotti si avvicinano. Ma richiede passaggi aggiuntivi: configurare Cloud Build, configurare ruoli IAM, scrivere script di distribuzione, gestire segreti e configurare controlli di salute. Si brucia il tempo di costruire l'infrastruttura di distribuzione prima di distribuire prodotti reali. Le piattaforme come o ti dà ciò di cui le start-up hanno davvero bisogno: una VM persistente con la distribuzione start-and-go da GitHub. Facile come può essere: spinge il tuo codice e si sta distribuendo. Solo pronto per utilizzare VM con variabili ambientali, SSL, bilanciatori di carico, log, ecc. Non è "gratuito", ma è pronto. Railway Fly.io I crediti gratuiti ti spingono verso l'eccesso di ingegneria perché "è già pagato". ti convinci che stai risparmiando soldi mentre spendi la tua risorsa più preziosa: il tempo. 
 
 
 Il modello mentale Potrai trascorrere settimane impostando l’infrastruttura “adeguata”, ma i concorrenti hanno lanciato in due giorni su Heroku.O hanno ottenuto 1.000 utenti mentre lavoriamo su un pipeline di distribuzione.Questi utenti valgono più di crediti gratuiti.Anche quando lo eviti, c’è un problema più profondo: come gli ingegneri senior pensano alla semplicità stessa. Il modello mentale Potrai trascorrere settimane impostando l’infrastruttura “adeguata”, ma i concorrenti hanno lanciato in due giorni su Heroku.O hanno ottenuto 1.000 utenti mentre lavoriamo su un pipeline di distribuzione.Questi utenti valgono più di crediti gratuiti.Anche quando lo eviti, c’è un problema più profondo: come gli ingegneri senior pensano alla semplicità stessa. Modello mentale #2 – “Minimale” <> “Simile” Il tradizionale principio KISS ci dice di mantenere il nostro software semplice.Ma nelle start-up, questo è il bersaglio sbagliato.Non dovresti mantenere il tuo SOFTWARE semplice; dovresti mantenere le tue SOLUZIONI semplici. La vera semplicità dovrebbe essere misurata con lo sforzo totale, non con la complessità del codice: Total Effort = Initial Build + Maintenance + Debugging + Feature Addition + Security Updates + Scaling Changes Quando si costruisce da zero, si possiede tutti questi per sempre. Quando si utilizza un servizio, la maggior parte di questi diventano zero. Il servizio di terze parti "bloated" è in realtà la soluzione semplice perché riduce al minimo l'impegno totale. My OAuth Example Il nostro ingegnere fondatore ha deciso di costruire OAuth da zero invece di usare una "biblioteca sconosciuta".Una settimana dopo, ha presentato un PR: implementazione di OAuth pulita con token JWT, rotazione dei token di aggiornamento, gestione delle sessioni e controllo dell'accesso basato su ruoli. Non ho negato il PR. E questo è stato un errore. Lanciare via una settimana di lavoro avrebbe schiacciato il morale. Ma crea complessità di codice e lo mette sulla strada sbagliata. Inoltre, non discutere l'approccio in anticipo è stato il nostro vero errore. Lasciamo l'orgoglio ingegneristico prendere una decisione strategica. Poi, un cliente aveva bisogno di Microsoft OAuth e Google OAuth. Implementazione personalizzata significava giorni di rifactoring, rotazione dei token di aggiornamento, casi di bordo, RBA e altre cose. Ogni aggiunta "simile" richiedeva una profonda comprensione del nostro auth personalizzato. Ogni aggiornamento di sicurezza era nostro da implementare. Ogni nuovo requisito era nostro per codificare. Principles L'errore classico dell'ingegnere senior: ottimizzare per il controllo piuttosto che i risultati.Nelle start-up, la realtà richiede di invertire completamente il modo in cui gli ingegneri senior pensano: 
 
 
 
 STOP pensare: "Questo è solo un paio di giorni di codifica"Start pensare: "Questo è un paio di giorni NON codificare il mio prodotto reale" STOPPARE di pensare: “Posso costruire questo semplicemente” START di pensare: “Posso risolvere questo semplicemente non costruendo” STOP Thinking: "Servizi di terze parti aggiungono complessità" START Thinking: "Servizi di terze parti assorbono complessità" 
 
 
 Il modello mentale Nelle start-up, KISS significa essere pigri su tutto tranne il tuo prodotto principale. Non pigri in termini di qualità, MA pigri in termini di sforzo. Perché ogni ora trascorsa ricostruendo problemi risolti è un'ora rubata dai problemi non risolti che determinano effettivamente se la tua startup vive o muore. Questo cambiamento di mentalità è abbastanza difficile. ma diventa più difficile quando la tua esperienza funziona attivamente contro di te, quando gli strumenti che hai padroneggiato diventano gli strumenti che ti rallentano. Il modello mentale Nelle start-up, KISS significa essere pigri su tutto tranne il tuo prodotto principale. Non pigri in termini di qualità, MA pigri in termini di sforzo. Perché ogni ora trascorsa ricostruendo problemi risolti è un'ora rubata dai problemi non risolti che determinano effettivamente se la tua startup vive o muore. Questo cambiamento di mentalità è abbastanza difficile. ma diventa più difficile quando la tua esperienza funziona attivamente contro di te, quando gli strumenti che hai padroneggiato diventano gli strumenti che ti rallentano. Modello mentale #3 - Opzioni di comfort Abbiamo scelto Angular perché il nostro ingegnere fondatore lo sapeva profondamente. Decisione intelligente, giusto? Usa i tuoi punti di forza, codice di qualità della nave. Il framework era buono, ma il problema era il suo ecosistema. The Ecosystem Trap Angular è eccellente e il nostro ingegnere potrebbe costruire qualsiasi cosa con esso. Ma "qualsiasi cosa" ha richiesto tempo solo per iniziare. configurare la distribuzione, l'autenticazione e i componenti di base dell'interfaccia utente significava una configurazione infinita prima di scrivere una singola funzione. Mentre abbiamo debuggito i temi Angular Material, i concorrenti possono (e utilizzeranno) Next.js + Vercel erano già utenti a bordo. Basta confrontare questo con il percorso Next.js + Vercel: implementare un'app scheleton con l'app create-next di npx il primo giorno, aggiungere l'autenticazione Clerk e i componenti shadcn/ui, spedire le funzionalità reali il primo giorno. Why does this happen? La differenza non è la qualità del framework, ma l'ottimizzazione dell'ecosistema. Next.js/React è circondato da strumenti di costruzione di start-up supportati da venture per altre start-up: 
 
 
 
 
 UI: shadcn/ui - copia, pasta, nave Auth: Clerk/Supabase - configurare in pochi minuti Sviluppo: Vercel - git push equals produzione Tutto il resto: se le start-up ne hanno bisogno, qualcuno ha costruito un servizio L'ecosistema di Angular serve le aziende: potente, flessibile, infinitamente personalizzabile. Perfetto(?) per i team di 50 e un veleno per i team di 3. 
 
 
 
 
 
 
 Il modello mentale Questa scelta ha rivelato una distinzione cruciale: Framework Senior: "Ho padroneggiato Angular. posso costruire qualsiasi cosa con esso." Essi ottimizzano per la qualità del codice e le pratiche di ingegneria "adeguate". hanno bisogno di una tabella dati? Essi trascorrono due settimane a costruire un componente perfettamente astratto, paginato - per le vostre 50 righe di dati. Nel frattempo, i concorrenti hanno catturato DataTable di shadcn e spedito agli utenti il primo giorno. Applied Senior: "Conosco Angular, ma Next.js navi 3x più veloce. Usaamo questo." Ottimizzano per il feedback del mercato. Caricano tutti i dati sul lato client perché "non colpiremo la scala per mesi" e spediscono con componenti off-the-shelf. Il loro codice potrebbe essere dimenticabile, ma stanno iterando sulla funzione tre mentre Framework Senior sta ancora perfezionando la loro astrazione di paginazione. La mossa veramente senior è chiedersi: "Solverò i problemi di domani o le opportunità di oggi?" La scelta del giusto ecosistema. Il modello mentale Questa scelta ha rivelato una distinzione cruciale: : "Ho padroneggiato Angular. posso costruire qualsiasi cosa con esso." Ottimizzano per la qualità del codice e le pratiche di ingegneria "adeguate". Necessitano di una tabella dati? Trascorrono due settimane a costruire un componente perfettamente astratto, paginato - per le tue 50 righe di dati. DataTable e spedito agli utenti il primo giorno. Framework Senior shadcn's Applied Senior: "Conosco Angular, ma Next.js navi 3x più veloce. Usaamo questo." Ottimizzano per il feedback del mercato. Caricano tutti i dati sul lato client perché "non colpiremo la scala per mesi" e spediscono con componenti off-the-shelf. Il loro codice potrebbe essere dimenticabile, ma stanno iterando sulla funzione tre mentre Framework Senior sta ancora perfezionando la loro astrazione di paginazione. : « " The truly senior move is asking yourself Risolviamo i problemi di domani o le opportunità di oggi? La scelta del giusto ecosistema. Modello mentale #4 - Costruire il nucleo, affittare il contesto Ma anche con gli strumenti giusti, c'è una trappola finale: la costrizione a costruire le cose perché si può, non perché si dovrebbe.Questa trappola uccide team tecnicamente forti e più start-up di quanto si possa immaginare: costruire cose che nessuno ha chiesto perché si può, non perché si dovrebbe. Abbiamo trascorso almeno un mese in totale sulle funzionalità di cui nessuno aveva bisogno. OAuth personalizzata quando esisteva Auth0. Una coda di lavoro basata su Postgres quando esisteva Redis + Celery. Terraform dal primo giorno, quando la console ha funzionato bene. Ogni decisione si sentiva produttiva, ma ognuna era auto-sabotaggio per affrontare sfide reali come parlare con i clienti o fare altri sviluppi dei clienti. Il modello è semplice: se i clienti non ti scelgono, non costruirlo. My $50 Rule Se un SaaS costa meno di $50 al mese, non puoi permetterti di costruirlo. La costruzione personalizzata di OAuth richiede 1-2 settimane di manutenzione complessiva e l'aggiunta di diversi fornitori di OAuth. A tassi di bruciatura di startup, che è $ 5.000-$ 15.000 in tempo di ingegneria, o in un tempo di opportunità persa. Auth0 è gratuito per fino a 25.000 utenti attivi, quindi $ 35 / mese. Si potrebbe pagare per Auth0 per 35 anni con quello che costa costruirlo una volta. Quindi, non si tratta di soldi, ma di priorità e costi di opportunità. Exception A mio parere, costruisci solo se non puoi imparare sugli utenti senza di esso. Un esempio semplice è quando devi testare se gli utenti pagheranno per i rapporti generati da AI. Costruisci la versione più semplice che dimostri la domanda. E tutto il resto cerca di scivolare. Sì, salta l'infrastruttura, salta "fare bene", salta le migliori pratiche che non spediscono caratteristiche, salta i test. Again, be as lazy as possible in writing code. What I Actually Use 
 
 
 
 
 
 Auth: Clerk (React-native, meglio DX) o Auth0 (B2B-focused, enterprise-ready) Email: Resend (developer-first) o SendGrid (testata in battaglia) Analisi: PostHog (gratuito fino alla scala) Monitoraggio: Sentry (imbattibile per gli errori) Hosting: Cloudflare o Vercel (se all-in su Next.js) Queste non sono approvazioni ma le mie scelte ottimizzate per la velocità. suppongo che la tua pila sarà diversa, ma questo principio non lo sarà. 
 
 
 Il modello mentale Se i clienti lo vedono e ti scelgono, costruisci. Tutto il resto, prova a noleggiare: auth, e-mail, pagamenti, monitoraggio....qualsiasi cosa. La tua startup non morirà dall'utilizzo di Auth0, ma morirà da trascorrere tre settimane di autenticazione della costruzione mentre gli utenti delle caratteristiche della nave concorrenti vogliono. La decisione di ingegneria più senior non è cosa costruire. Il modello mentale Se i clienti lo vedono e ti scelgono, costruisci. Tutto il resto, prova a noleggiare: auth, e-mail, pagamenti, monitoraggio....qualsiasi cosa. La tua startup non morirà dall'utilizzo di Auth0, ma morirà da trascorrere tre settimane di autenticazione della costruzione mentre gli utenti delle caratteristiche della nave concorrenti vogliono. La decisione di ingegneria più senior non è cosa costruire. Linea di fondo I LLM hanno costruito le merci. Qualsiasi giovane con Claude può creare quel sistema auth personalizzato di cui sei così orgoglioso. il tuo valore non sta in ciò che puoi costruire più, ma è sapere cosa non costruire. La vera seniorità significa avere la disciplina di ignorare il 90% di ciò che sai e di spedire la soluzione di oggi, non l'architettura di domani.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Questo audio è prodotto nella lingua originale della storia!

KISS o morire: perché gli ingegneri senior falliscono nelle start-up

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

How to Mint Your Name.HackerNoon Web3 Identity Namespace

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

How to Mint Your Name.HackerNoon Web3 Identity Namespace

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps