När arbetsflödet är dåligt bygger jag hellre ett eget verktyg

Jag gick elprogrammet med inriktning elektronik och data, och byggde egna ljusstyrningar och kretskort långt innan jag visste vad ett arbetsflöde hette. Jag var tekniker i gymnasiemusikalen, och året efter lärare för nästa års tekniker. Sedan kom eget teknikbolag och många år inom avancerad AV- och liveproduktion.

Genom allt det har samma instinkt funnits kvar: när något inte fungerar som det borde vill jag förstå varför, och om svaret är "för att ingen har byggt det rätt" vill jag bygga det rätt. I dag kommer samma bygginstinkt tillbaka i mjukvara och AI. Verktygen har bytts ut, men irritationen över dåliga flöden är densamma.

I liveproduktion är komplexitet dyr, inte för att den är svår att förklara, utan för att den måste hanteras av människor som redan jobbar under tidspress. Varje onödigt steg, varje oklar knapp, varje manuell rutin som kunde varit automatiserad tar fokus från det som faktiskt avgör om produktionen blir bra.

Ett bra verktyg ska minska antalet beslut i fel ögonblick. När sändningen närmar sig ska man inte behöva fatta beslut som kunde fattats en gång för alla när verktyget byggdes. Det är den principen som driver nästan allt jag byggt.

Octopus föddes ur kaoset kring presentationer: vMix, QTimer, körscheman, sessioner och en mängd små manuella steg som alla skulle sitta exakt rätt under press. Målet var aldrig fler funktioner, det var ett lugnare och tydligare kontrollgränssnitt när det bränner till.

PXL RCP kom ur behovet av enklare kamerakontroll för Panasonic och Blackmagic. Iris, färg och matchning ska gå att hantera i ett verktyg som faktiskt passar verkligt arbete, inte i menyer som känns designade av någon som aldrig stått i en regi.

Activity Agent, Skalman, handlar om tidsrapportering och körjournal. Det är nödvändigt administration som tar tid från verkligt arbete. Idén är att låta systemen samla underlaget automatiskt och låta människan göra eftervalet, i stället för tvärtom, där människan matar systemet från minnet i efterhand. Skalman, det här projektet, har nu egen projektsida.

CLEN LED-bryggan är ett annat exempel: tekniken går att styra, men det befintliga gränssnittet är så bakvänt att det nästan är en prestation. Det är en bra påminnelse om att bra teknik inte automatiskt betyder bra användning, någon måste ta hänsyn till den som faktiskt ska använda den. På LED-sidan finns ett annat verktyg, LED Toolkit, byggt för att göra projektering och beräkningar snabbare och mer återanvändbara. Det växte ur samma vardag.

Det finns en fälla i allt det här som jag känner igen väl: enkelt för användaren kan vara svårt att bygga. Ett gränssnitt som känns självklart är ofta resultatet av att någon tagit alla besvärliga beslut i förväg, och tagit bort allt som inte behövdes. Det tar tid, och det kräver att man verkligen förstår arbetet verktyget ska stödja.

Det är också därför egenbyggt inte automatiskt är bättre. Ibland ska man köpa färdigt. Ibland ska man integrera det som finns. Att bygga själv är bara rätt när problemet är tillräckligt verkligt och återkommande, när det kostar fokus gång på gång, inte bara en gång.

Här ska jag vara ärlig mot mig själv: jag har många idéer samtidigt, och projekt sväller lätt. Det som börjar som "en liten hjälpfunktion" kan bli en plattform om man inte är försiktig. Varje verktyg man bygger är också ett verktyg man ska underhålla, och underhåll är den delen som aldrig är lika rolig som byggandet.

Så jag försöker bli bättre på fokus och prioritering. På att ställa frågan innan jag börjar: är det här ett problem som förtjänar en lösning, eller är det bara en idé som är kul att bygga? Och på att ibland säga "inte nu", även till saker jag vet att jag skulle kunna bygga.