Systemdesign för nya projekt
Att bestämma vad delarna är och hur de pratar med varandra, innan någon skriver kod. Det är mycket billigare att flytta en ruta i ett diagram än att flytta en databas senare.
Min datavetenskapliga examen och mina år av fullstackkodande har båda knuffat mig åt samma håll: jag är mer intresserad av hur ett system är format än av syntaxen i ett visst språk. Här kommer det till nytta.
De flesta små företag har ingen bild av sitt eget system utöver det som finns i en eller två personers huvuden. Det går bra tills någon slutar, eller tills ni ska fatta ett dyrt beslut.
Att bestämma vad delarna är och hur de pratar med varandra, innan någon skriver kod. Det är mycket billigare att flytta en ruta i ett diagram än att flytta en databas senare.
Jag läser koden och infrastrukturen och berättar hur det faktiskt är uppbyggt, vilket inte alltid är som folk tror.
Hur era tjänster och tredje parter utbyter data. Det mesta av svårigheten ligger i vad som händer när ena sidan inte är tillgänglig, så det är där jag lägger fokus.
Hjälp att välja vad ni ska bygga med, och skriftliga skäl för valet. Dels så att ni kan ompröva det, dels så att nästa person inte river upp det av misstag.
Hur systemet fungerar, varför det fungerar så och vad man ska vara försiktig med. Det alla är överens om är viktigt och ingen har tid att skriva.
En titt på vad som går sönder först när användningen växer, och vad det skulle kosta att åtgärda. Oftast är det en eller två saker, inte allt.
Någon att diskutera ett beslut med när ni inte har någon internt att diskutera med. Ibland är svaret att er plan var bra.
Resultatet är aldrig bara ett diagram. Ett diagram utan resonemanget bakom missförstås inom en månad.
Koden, infrastrukturen och historiken över vad som gått fel. Jag pratar också med den som håller det igång, eftersom det sällan står nedskrivet.
Vad som finns, hur det hänger ihop och var beroendena finns. Ofta är det första gången det ritas upp överhuvudtaget.
Sorterat efter verklig konsekvens: vad som hotar verksamheten, vad som bara irriterar teamet och vad som faktiskt är bra som det är.
Fynd och rekommendationer med resonemanget bifogat, så att ert team kan bygga vidare på tänkandet i stället för att gissa vad jag menade.
En genomgång med den som behöver den. Skrivna dokument skummas; frågorna kommer fram i samtal.
En del av det här är ett par dagars arbete. En del är en månad. Berätta vilket beslut du står inför så säger jag vilket det är, även om svaret är att du inte behöver mig.
En utomstående genomläsning av ert nuvarande system, nedskriven och genomgången tillsammans.
Att utforma hur något ska byggas, antingen ett nytt projekt eller en ombyggnad av en del av ett.
Regelbundna timmar för team som vill ha någon att tänka igenom det här tillsammans med.
Det här arbetet lönar sig mest innan ni binder er. När något väl är byggt kostar samma frågor betydligt mer att besvara.
En ny produkt, en ombyggnad eller en flytt till molnet. Besluten som fattas de första två veckorna är de ni lever med i åratal.
Duktiga utvecklare som var och en ansvarar för sin del, och ingen vars jobb är hur delarna passar ihop. Lätt att sluta med sju rimliga beslut som inte stämmer överens.
Ni äger något ni inte byggt och som ingen kan förklara. Innan ni kan ändra det säkert måste någon reda ut vad det gör.
Berätta vad du väger mellan och var det gör ont idag. Jag föreslår det minsta arbete som besvarar frågan.
Boka en granskning