Simon Pantzare

Linkedin
Github
Plats Sundsvall

En utvecklare med vana att ta idéer till produktion

i gemet
15år
på startups
10år
ish

Kompetensområden

Backend och devops
Min spets ligger på backend-utveckling och devops. I team där andra kompetenser finns är det här mitt fokus brukar hamna: att snickra ihop, launcha och drifta tjänster som crunchar data, tar hand om ordrar eller integrerar system. Likaså att sätta upp produktions- och testmiljöer eller system för CI, ofta på AWS.
Fullstack
I små bolag—som startups i tidiga skeden—är det vanligt att teamet sedan tidigare inte har djup i alla områden som behövs. Tack vare det har jag byggt upp en gedigen bredd och vana av att jobba i alla delar av stacken: från front och appar, till data engineering och ETL, till Linux-admin och nätverk.
Affärsförståelse
Jag är varken ekonom, jurist eller säljare men är van vid (och tycker det är kul) att samarbeta med dem. Jag vet vad en driftsatt MVP eller en riktigt bra demo kan vara värd för potentiella kunder och investerare, kan göra tradeoffs med hänsyn till runway och när nästa investeringsrunda ska resas, har deltagit i tekniska DDs och vet vad som menas med att GPL smittar.

Vad tycker du om…?

Beprövad teknik

Jag föredrar beprövad teknik och är särskilt konservativ när det gäller system som tar hand om kärnverksamheten. Nytt betyder inte bättre.

Lindy-effekten säger att bäst före-datumet på idéer och tekniker förlängs med deras ålder. Ett programmerings­språk, libb eller ramverk som har funnits i 15 år är mer sannolikt att finnas kvar och vara populärt om ytterligare 15 år, än ett som bara har funnits i ett par år eller månader.

Observerbarhet

Jag värnar om metrics, loggar, larm och event-data: att kunna få tidiga indikationer på problem som gör att teamet kan agera innan användare hör av sig eller ens märker av något. Det hjälper också teamet att fokusera på rätt saker: mät istället för att gissa hur ändringar presterar!

Bra DX

Att sätta upp utvecklingsmiljöer, köra tester och skeppa till produktion ska vara friktionsfritt. Det lönar sig i form av enklare onboarding och intern mobilitet, färre personberoenden, kortare ledtider och gladare utvecklare.

Molntjänster

Jag föredrar att använda molnleverantörer och deras högnivåtjänster för att frigöra tid till annat. Även om det ofta går snabbt att komma igång med self-hosting så äter det tid att hålla system patchade och att hålla en OK tillförlitlighet med redundans och backuper och allt vad det innebär. Saker har dessutom en tendens att bli mer driftkritiska över tid, och då är det skönt när det går att växa med en leverantör.

Låg komplexitet

Det är viktigt för mig att förstå användarnas problem för att kunna hålla lösningar små och enkla. Likaså att fundera på hur lösningar passar ihop med varandra och sträva efter en slimmad och enkel teknik-stack som är billig att förvalta över tid och är enkel att onboarda till.

End-to-end-fokus

Jag gillar när lösningar tidigt skär genom kringliggande system och exponeras för användare. Det ökar chansen för att vi stöter på oförutsedda problem tidigt i utvecklingen och gör det enklare att hålla fokus på rätt saker: de till helheten sett viktigaste problemen.

Att slänga kod

Jag är övertygad om att slut­produkten blir bättre och når användarna tidigare om vi skriver simpel kod som vi räknar med att få kasta och skriva om i takt med att vi lär oss mer om problem­domänen och våra tekniska förutsättningar.

Tydliga mål

Det gör mycket för min motivation att veta vart vi ska och att organisationen har en delad bild av målet. Om stakeholders är samspelta kan vi lägga energi på att bygga saker som tar oss framåt istället för att fastna i konsensus­sökande och tappa styrfart.

Jobb i urval

Några av de produktlanseringar och projekt jag har deltagit i.

Narrative

Narrative var en hårdvarustartup med bas i Linköping som byggde en wearable-kamera med tillhörande app och molnbaserad lagring. Jag var den förste backend-utvecklaren och lade med det växande teamet grunden för bilduppladdning och de backendsystem som sköter omskalning och beskäring av bilder, omvandling av GPS-rådata till koordinater och reverse geocoding, snabb åtkomst från appar och webb och sociala funktioner. Jag var tongivande i jobbet kring bearbetning av event-data och data warehousing som produkt- och marknads-teamen använde.

Systemen tog hand om hundratals miljoner bilder—en användare som bar kameran under en hel dag genererade ett par tusen bilder och företaget hade som mest tiotusentals användare.

AWS (EC2, S3, RDS, Lambda) Python Django MySQL Go

Leeroy

Leeroy är en startup med bas i Sundsvall och Stockholm som utvecklar en restaurangplattform. Jag var en av de första utvecklarna och byggde tillsammans med resten av teamet de system som tar hand om app-ordrar, betalningar och integration med kassa och kitchen display.

Liksom på Narrative tog teamet ansvar för hela leveransen inklusive drift och CI.

AWS (ECS, EC2, RDS) Payments (Adyen, Swish) Java (Spring) Postgres AMQP (ActiveMQ)

Bonnier News

På Bonnier News Local (dåvarande Mittmedia) deltog jag i arbetet att modernisera hur redaktionerna jobbar med beteendedata, eller klickdata. Teamet införde nya system för insamling av user events från webb och appar, hantering av event-strömmar med långtidslagring i en datasjö, ETL för indexering i Redshift (OLAP-databas) och rapportering (ofta av en Slack-bot) om nya kunder och churn. Local-affären består av dussintals lokaltidningar.

AWS (Redshift, Kinesis, S3, Lambda) Python Java

Sektionskafé Baljan

Under studietiden på Linköpings universitet engagerade jag mig i studentfiket och moderniserade deras IT-system: jag skrev om de åldrande systemen från Perl till Python och Django, ersatte servern (som det börjat växa i spindelväv i) som kompletterades med RAID1 och offsite-backup, gjorde det möjligt att blippa kaffe med NFC-taggen i studentkorten och integrerade inlogg mot universitetets Oracle-system.

Jag skrev ett nytt top-up-system med kaffekort och införde systemstöd för automatisk schemaläggning för personalen (ett hundratal studenter per termin) och möjlighet för dem att byta skift med varandra. De populära topplistorna över vilka som blippar mest kaffe utökades med topplistor på sektionsnivå: är det maskinstudenerna, lärarna eller datavetarna som dricker mest kaffe? Vid den här tiden var fiket den största fristående kunden till Löfbergs lila, med hundratals besökare varje kvartsrast.

Python Django Postgres NFC Hårdvara

Weapons of choice

Programmeringsspråk, ramverk och andra verktyg som jag kan ge ditt uppdrag en flygande start med.

Python

Python har varit en ständig följeslagare från 2007 och framåt och är mitt go to-val för greenfield-utveckling om det inte är uppenbart att prestanda kommer att vara en begränsning. Python är ombytligt och fungerar lika bra för programvaru­utveckling som för scripting. Jag anser att det är särskilt svårslaget för att utforska nya problemdomäner där teamet kontinuerligt behöver kunna omforma lösningen, samt för problem som kräver databearbetning.

Jag har jobbat på ställen där Python varit det primära eller ett av huvudsspråken i ca 10 år och har många timmars hobbyhackande utöver det.

Django

Django är det populäraste webbramverket till Python och har funnits i 17 år. Jag har använt det till flera större produkter och har aldrig blivit besviken, vare sig med produktiviteten som utvecklare eller dess driftsäkerhet.

I kombination med client side-bibliotek som HTMX och Alpine.js har man en stack som behåller fördelarna med server side-rendering och produktiviteten i Django och Python men som möjliggör moderna tekniker som realtidsuppdateringar och partiella sidladdningar, utan att behöva introducera en separat stack för frontend-delarna.

Jag har ca 5 års professionell erfarenhet av att jobba med Django som primärt ramverk och använder det till ideella projekt och hobbysaker.

Postgres och SQL

Postgres klarar de flesta dataproblem du kastar på det. Samtidigt som det är en stabil transaktionsdatabas som klarar moderna SQL-konstruktioner skalar det väl för analytiska laster, kan agera dokumentdatabas, hanterar geodata genom PostGIS, klarar fulltextsök med hjälp av GIN-index och enklare grafproblem med rekursiva CTEs.

Om man växer ur standard-Postgres finns det specialiserade alternativ som Redshift för OLAP eller Amazon Aurora och Cloud Spanner för transaktionella workloads. Det är heller inget jättesteg att gå till andra databaser som bygger på SQL för ett ännu större utbud. Verktyg som AWS DMS och Kafka Connect gör det möjligt att synka dataset till flera ställen.

Amazon Web Services

Om det inte är uppenbart att allt man behöver och kommer att behöva finns hos en annan leverantör så bygger jag helst på AWS. Amazon erbjuder stabila lösningar som oerhört sällan blir deprekerade eller tappar bakåtkompatibilitet. Communityt är stort och det finns flera verktyg för att lyfta utvecklarupplevelsen ytterligare, som att jobba enligt infrastructure-as-code-principer med hjälp av AWS CDK.

Jag stiftade bekantskap med AWS omkring år 2009 och har använt det i nästan alla projekt där det har varit möjligt att välja. Jag kan de vanliga tjänsterna mycket väl: EC2 med autoscaling och lastbalanserare, S3, RDS, ElastiCache, Route53, IAM, ACM, ECS, DynamoDB, Kinesis, Lambda, Redshift med flera. Jag vill inte sätta 5/5 på mig själv eftersom att utbudet är så oerhört stort och jag har troligen inte använt ens hälften av tjänsterna som finns tillgängliga.

Java

För backends som utgör grundbultar där prestanda och stabilitet är A och O och när det finns en så pass god förståelse för problemdomänen att det går att bygga system som troligen inte behöver förändras särskilt mycket över tid så föredrar jag Java. Likaså när kodbasen är stor eller när många utvecklare ska samsas i den.

Jag har ungefär 5 års erfarenhet av att koda Java heltid från 2016 och framåt.

Containers

Containers och Dockers genomslag har gjort det enkelt att hålla dev-, test- och prodmiljöer lika varandra. Vad som tidigare kunde ta ett par timmar att sätta upp är ofta bara ett docker compose up bort. Vi kan patcha produktionsinstanserna, om vi ens behöver tänka på dem, oberoende av de containrade applikationerna.

Jag har använt Docker sedan det open-sourcades av dotCloud och har flera års erfarenhet av att köra containers i produktion, antingen på AWS ECS eller direkt på instanser. Jag har följt utvecklingen av Kubernetes och har använt det som nyttjare men har inte erfarenhet av att sätta upp och drifta kluster annat än lite eget experimenterande. Kubernetes är komplext och jag har inte kunnat motivera att införa det i någon produkt jag byggt än.

Javascript och Node

Mängden paket i Javascript- och Node-ekosystemet är svårslaget. Även om jag föredrar Django för webbprojekt så finns Node ofta med i något hörn för att tillhandahålla frontend-bibliotek för styling och bundling eller libs för mer avancerade client side-saker eller -integrationer. TypeScript är också ett trevligt tillskott, särskilt för lite större projekt.

Node tycker jag lämpar sig väl för mindre backends eller när många saker sker asynkront. Nu för tiden är det heller inga problem att hitta stabila bibliotek och ramverk med några år på nacken.

Men gärna också…

Tekniker som jag har begränsad erfarenhet av men gärna använder för att ta ditt uppdrag i mål.

Go

Jag har använt Go i produktion vid några tillfällen och skulle gärna göra det igen. Jag har stor respekt för de som designade språket och tycker kopplingen till Bell labs och Plan 9 är lite fascinerande.

Det jag gillar mest med Go är att det är så pragmatiskt, är enkelt att skriva och läsa, har ett väldigt kapabelt standardbibliotek och är odramatiskt att drifta tack vare hur applikationer ofta kan distribueras som en enda binär.

Cloudflare Workers

Jag tror att Cloudflare är något på spåren med Workers. Att köra både kod och hålla data på edge-noder banar för nya sätt att bygga distribuerade, skalbara system som är enklare än typiska lösningar med ett halvsmart CDN framför en uppsättning lastbalanserare, applikationsservrar och databaser. Att sharda både data och compute redan på edge-nivå kanske kan ta bort några lager infrastruktur?

Lägg där till bra stöd för wasm som gör det möjligt att skriva applikationer i flera språk.

Kafka Streams

Konstruktionerna i Kafka Streams verkar göra det möjligt att bygga tjänster som är enkla att förstå men som ändå är robusta och skalar bra. Jag tror att lösningar som Kafka kommer förenkla för organisationer att få insikter från sin data eftersom att det minskar behovet att investera i en data-stack som lever parallellt med övriga produktionssystem.

Att se strömmar som en del av gränssnitten mellan team och organisationer tycker jag också är en spännande utveckling: att inte behöva beställa nya integrationspunkter eller endpoints från de som äger data utan istället kunna bygga på existerande strömmar. Det gör också prestandafrågor enklare när konsumenter per default ansvarar för att indexera data på sätt som passar deras egna workloads, snarare än att de som generar källdata ska behöva sätta sig in i konsumenters frågemönster.

Rust

Rust verkar som ett språk där program ofta fungerar när de kompilerar. Lägg till bra prestanda och toolchain.

Clojure

Jag fick upp ögonen för lisp under universitetstiden, där Common Lisp var språket i våra första programmeringskurser. Strax därefter släpptes Clojure och jag har fascinerats av kombinationen JVM + lisp (och JS + lisp genom ClojureScript). Det vore kul att få erfarenhet av att använda Clojure till något substantiellt.

Jag gillar att skriva och läsa kod som är funktionell och gärna deklarativ och tycker att Clojure har en bra balans där det går att skriva kod med sidoeffekter eller som är imperativ utan ceremonier. I andra programmeringsspråk saknar jag ofta Clojures inbyggda persistenta datastrukturer.