Full list of pro­jects avail­able here.

La Suite numérique (La Suite for short) is a full blown open-source dig­i­tal work­space for on­line col­lab­o­ra­tion and team­work.

La Suite is built by French gov­ern­ment agen­cies DINUM and ANCT. It is also the prod­uct of a close eu­ro­pean col­lab­o­ra­tion with the Netherlands and German state.

Our code base is a 100% open source and MIT li­cenced.

Come say hello on Matrix

I did­n’t ask for this and nei­ther did you.

I did­n’t ask for a ro­bot to con­sume every blog post and piece of code I ever wrote and par­rot it back so that some hack could make money off of it.

I did­n’t ask for the role of a pro­gram­mer to be re­duced to that of a glo­ri­fied TSA agent, re­view­ing code to make sure the AI did­n’t smug­gle some­thing dan­ger­ous into pro­duc­tion.

And yet here we are. The worst fact about these tools is that they work. They can write code bet­ter than you or I can, and if you don’t be­lieve me, wait six months.

You could ab­stain out of moral prin­ci­ple. And that’s fine, es­pe­cially if you’re at the tail end of your ca­reer. And if you’re at the be­gin­ning of your ca­reer, you don’t need me to ex­plain any of this to you, be­cause you al­ready use Warp and Cursor and Claude, with ChatGPT as your ther­a­pist and pair pro­gram­mer and maybe even your lover. This post is for the 40-somethings in my au­di­ence who don’t re­al­ize this fact yet.

So as a se­nior, you could ab­stain. But then your ju­nior col­leagues will even­tu­ally code cir­cles around you, be­cause they’re wear­ing bazooka-pow­ered jet­packs and you’re still rid­ing around on a fixie bike. Eventually your boss will start ask­ing why you’re get­ting paid twice your zoomer col­leagues’ salary to pro­duce a tenth of the code.

Ultimately if you have a mort­gage and a car pay­ment and a fam­ily you love, you’re go­ing to make your de­ci­sion. It’s maybe not the de­ci­sion that your younger, more ide­al­is­tic self would want you to make, but it does keep your car and your house and your fam­ily safe in­side it.

Someday years from now we will look back on the era when we were the last gen­er­a­tion to code by hand. We’ll laugh and ex­plain to our grand­kids how silly it was that we typed out JavaScript syn­tax with our fin­gers. But se­cretly we’ll miss it.

We’ll miss the feel­ing of hold­ing code in our hands and mold­ing it like clay in the ca­ress of a mas­ter sculp­tor. We’ll miss the sleep­less wran­gling of some odd bug that even­tu­ally re­lents to the de­bug­ger at 2 AM. We’ll miss cre­at­ing some­thing we feel proud of, some­thing true and right and good. We’ll miss the sat­is­fac­tion of the artist’s sig­na­ture at the bot­tom of the oil paint­ing, the GitHub repo say­ing “I made this.”

I don’t cel­e­brate the new world, but I also don’t re­sist it. The sun rises, the sun sets, I or­bit help­lessly around it, and my protests can’t stop it. It does­n’t care; it con­tin­ues its arc across the sky re­gard­less, mov­ing but un­moved.

If you would like to grieve, I in­vite you to grieve with me. We are the last of our kind, and those who fol­low us won’t un­der­stand our sor­row. Our craft, as we have prac­ticed it, will end up like some black­smith’s tool in an arche­o­log­i­cal dig, a cu­rio for fu­ture gen­er­a­tions. It can­not be helped, it is the na­ture of all things to pass to dust, and yet still we can mourn. Now is the time to mourn the pass­ing of our craft.

This is a vo­cal tech­nique ref­er­ence cov­er­ing 21 tech­niques across five cat­e­gories. It’s de­signed as a learn­ing com­pan­ion — whether you’re a be­gin­ner find­ing your voice or an ex­pe­ri­enced singer ex­pand­ing your toolkit.

The sticky bar be­low the ti­tle lets you jump be­tween sec­tions. Each col­ored dot matches its cat­e­gory:

— ways to shape and color your sound

How to read the table

Each row is one tech­nique. Hover the tech­nique name to see a short de­scrip­tion. The dif­fi­culty dots (● ○ ○ ○ ○) show how ad­vanced it is, from 1 to 5.

Some tech­niques show small dashed chips be­neath the name — these are pre­req­ui­sites. The chip color tells you which cat­e­gory the pre­req­ui­site be­longs to. Hover a chip to see what that tech­nique sounds like, or click it to jump straight to its row in the table.

Techniques marked with ⚠️ warn­ings can cause dam­age if done in­cor­rectly. The golden rule: if it hurts, stop. Work with a vo­cal coach for any­thing rated 4–5 dots.

Use EN / DA to switch lan­guage and the theme but­ton to cy­cle through five color schemes: Dark, Light, Midnight, Forest, and Ember. Your choices are saved au­to­mat­i­cally.

Nogle teknikker viser små sti­plede chips un­der navnet — det er forud­sæt­ninger. Chipfarven fortæller hvilken kat­e­gori forud­sæt­nin­gen hører til. Hold musen over en chip for at se hvad teknikken ly­der som, eller klik for at hoppe di­rekte til den i tabellen.

I hope this guide helps you on your vo­cal jour­ney. If you have sug­ges­tions, found a bug, or just want to say hi — I’d love to hear from you.

Check your pos­ture — feet shoul­der-width, shoul­ders back and down, chin level.

Release ten­sion — roll your neck, shrug and drop shoul­ders, shake out your arms.

No cold starts — never belt, dis­tort, or push range with­out warm­ing up first.

Breathing (1 min) — Inhale 4 counts into belly/​sides/​back. Exhale on “Sss” for 15–20 sec­onds. Repeat 3x. This ac­ti­vates your sup­port sys­tem.

Lip Trills (1 min) — Blow air through closed lips to make them vi­brate. Slide up and down your range. Keeps every­thing re­laxed and con­nected.

Humming (1 min) — Hum on “Mmm” through 5-note scales, as­cend­ing. Feel the buzz in your face (mask res­o­nance). Keep jaw and tongue loose.

Vowel Slides (1 min) — Sing “Mee-Meh-Mah-Moh-Moo” on a sin­gle note, then move up by half steps. Opens the vo­cal tract grad­u­ally.

Sirens (1 min) — Slide from bot­tom to top and back on “Woo” or “Wee.” Full range, gen­tle, no push­ing. This bridges your reg­is­ters.

Straw phona­tion — Sing through a straw (or into a cup of wa­ter with a straw). Creates back-pres­sure that bal­ances air­flow and fold clo­sure. Best warm-up tool avail­able.

Tongue trills — Roll your tongue on “Rr” while singing scales. Releases tongue ten­sion (a com­mon prob­lem).

Arpeggios — 1-3-5-8-5-3-1 on “Nay” or “Gee” to work through your pas­sag­gio (break area).

A dome-shaped mus­cle be­neath your lungs. When you in­hale, it flat­tens down­ward, pulling air in. You don’t di­rectly “sing from your di­aphragm” — you use it to con­trol the rate of ex­ha­la­tion. Think of it as an air pres­sure reg­u­la­tor, not a sound source.

Two small folds of tis­sue in your lar­ynx. When air passes through, they vi­brate and cre­ate sound. Thicker vi­bra­tion = chest voice. Thinner vi­bra­tion = head voice. Partial clo­sure = falsetto/​breathy. The space be­tween them is called the glot­tis.

Your “voice box.” It can move up (bright, thin sound) or down (dark, warm sound). For most singing, a neu­tral or slightly low­ered lar­ynx is ideal. A high lar­ynx un­der pres­sure = strain. Learn to keep it sta­ble — yawn­ing gen­tly while singing helps find the right po­si­tion.

Abdominals — Control ex­ha­la­tion pres­sure. They don’t push air out — they slow the col­lapse of the rib cage.

Intercostals — Muscles be­tween your ribs. Keep your ribs ex­panded dur­ing singing. This is “appoggio” (leaning into the breath).

Back mus­cles — Often for­got­ten. Your lower back ex­pands when breath­ing cor­rectly. Engage it for sup­port.

Stand with feet shoul­der-width apart. Knees slightly bent (not locked). Shoulders re­laxed, back and down. Chest com­fort­ably open. Head bal­anced on top of the spine — not jut­ting for­ward. Imagine a string pulling you up from the crown of your head.

Hydration — Drink wa­ter con­sis­tently through­out the day, not just be­fore singing. Your vo­cal folds need sys­temic hy­dra­tion.

Steam in­hala­tion — Breathe steam for 10 min­utes be­fore heavy singing. This di­rectly hy­drates the folds.

Rest — Your voice needs re­cov­ery time. Avoid talk­ing loudly af­ter in­tense ses­sions.

Din “stemmeboks.” Den kan bevæge sig op (lys, tynd lyd) eller ned (mørk, varm lyd). Til de fleste for­mer for sang er en neu­tral eller let sæn­ket strube ideel. En høj strube un­der pres = be­last­ning. Lær at holde den sta­bil — at gabe blidt mens du syn­ger hjælper med at finde den rette po­si­tion.

Common ad­vice that’s mis­lead­ing, in­com­plete, or out­right harm­ful. If some­one tells you any of these, be skep­ti­cal.

You can’t di­rectly con­trol your di­aphragm — it’s an in­vol­un­tary mus­cle on the in­hale. What peo­ple mean is: use your ab­dom­i­nal and in­ter­costal mus­cles to con­trol ex­ha­la­tion. Saying “sing from your di­aphragm” is like say­ing “digest from your stom­ach.” Technically in­volved, but not how you’d teach it.

“Drink tea with honey to fix your voice”

Tea and honey never touch your vo­cal folds — they go down your esoph­a­gus, not your tra­chea. They can soothe throat ir­ri­ta­tion and feel nice, but they don’t “fix” or “coat” your cords. What ac­tu­ally helps: steam in­hala­tion and sys­temic hy­dra­tion (water, hours in ad­vance).

The sound is­n’t pro­duced in your chest. “Chest voice” refers to the thick vo­cal fold vi­bra­tion pat­tern that cre­ates sym­pa­thetic res­o­nance you feel in your up­per torso. The sound is al­ways made at the vo­cal folds in your lar­ynx.

“Falsetto is only for men”

Everyone with vo­cal folds can pro­duce falsetto — it’s a mode of vi­bra­tion where the folds don’t fully close. Women use it too, though the tim­bral dif­fer­ence from head voice may be less dra­matic.

They give you a dam­aged voice. The “rasp” from smok­ing and al­co­hol comes from swollen, ir­ri­tated, de­hy­drated folds. Healthy vo­cal dis­tor­tion uses the false folds and ary­tenoids — struc­tures above the true cords. One is con­trolled art, the other is per­ma­nent dam­age.

The ex­act op­po­site. High notes re­quire less air, not more. Pushing more air at higher pitches forces the folds apart and cre­ates strain. Think “less air, more com­pres­sion” — let the folds do the work.

Artificial vi­brato (jaw wob­ble, di­aphragm pulse) sounds un­nat­ural and cre­ates ten­sion. Real vi­brato emerges nat­u­rally when breath sup­port is solid and the throat is re­laxed. If you don’t have vi­brato yet, the fix is bet­ter tech­nique — not man­u­fac­tur­ing it.

“You’re ei­ther born with it or you’re not”

Singing is a mo­tor skill. Some peo­ple have nat­ural ad­van­tages (vocal fold length, res­o­nance cav­ity size), but tech­nique, pitch ac­cu­racy, tone qual­ity, and range are all train­able. Most “natural” singers prac­ticed ob­ses­sively as chil­dren.

Your vo­cal folds are tis­sue. They need in­creased blood flow and grad­ual stretch­ing be­fore heavy use — just like any other mus­cle. Cold singing is the fastest path to strain, nod­ules, and he­m­or­rhages.

Pain means dam­age. Unlike skele­tal mus­cles, vo­cal folds don’t grow stronger from mi­cro-tears. Pain, burn­ing, or per­sis­tent hoarse­ness = stop im­me­di­ately. Rest. If it lasts more than a few days, see an ENT spe­cial­ist.

Du kan ikke di­rekte kon­trollere dit mellemgulv — det er en ufriv­il­lig muskel ved in­dånd­ing. Det folk mener er: brug dine mave- og in­terkostal­muskler til at kon­trollere udåndin­gen. At sige “syng fra mellemgul­vet” er som at sige “fordøj fra maven.”

This guide uses tra­di­tional vo­cal ter­mi­nol­ogy (chest voice, head voice, mixed voice, etc.) be­cause it’s the most widely un­der­stood frame­work world­wide. However, the most sci­en­tif­i­cally val­i­dated sys­tem is Complete Vocal Technique (CVT), de­vel­oped by Cathrine Sadolin at the Complete Vocal Institute in Copenhagen.

CVT is built on laryn­go­scopic imag­ing, EGG mea­sure­ments, and peer-re­viewed acoustic re­search. Here’s how the two frame­works re­late.

CVT clas­si­fies all singing into four modes based on vo­cal tract con­fig­u­ra­tion — not felt vi­bra­tion:

Support — Coordinated ab­dom­i­nal, waist, so­lar plexus, and back mus­cle en­gage­ment to con­trol air pres­sure and air­flow. (This guide: Breath Support)

Necessary Twang — Narrowing the epiglot­tic fun­nel for clearer, more ef­fi­cient sound. CVT con­sid­ers this foun­da­tional for all healthy singing, not just a style. (This guide: Twang)

Avoid pro­trud­ing jaw & tight­ened lips — These trig­ger un­con­trolled vo­cal cord con­stric­tion, es­pe­cially in up­per reg­is­ter. (Not ex­plic­itly cov­ered in this guide)

“Overdrive” in CVT is a clean mode, not dis­tor­tion

Vowel rules: CVT re­stricts spe­cific vow­els per mode. Traditional ped­a­gogy uses gen­eral vowel mod­i­fi­ca­tion. Both work, but CVT is more pre­cise.

Metal & Density: CVT uses “degree of metal” (0–100%) and “density” (fuller vs. re­duced) as pa­ra­me­ters. Traditional ped­a­gogy does­n’t have these con­cepts.

“Overdrive” means dif­fer­ent things: In this guide, over­drive = heavy vo­cal dis­tor­tion (like gui­tar over­drive). In CVT, Overdrive = a clean, shouty vo­cal mode.

Learn more: com­plete­vo­calin­sti­tute.com

Look for ex­pand­able an­no­ta­tions on tech­nique cards through­out this guide.

The fun­da­men­tal modes of vo­cal fold vi­bra­tion. Every sound you make lives some­where on this spec­trum. Master these be­fore any­thing else.

Ways of us­ing your reg­is­ters to cre­ate spe­cific sounds. These de­fine gen­res and artis­tic iden­tity.

Textures and col­ors you add to your base tone. These are the sea­son­ing — use them de­lib­er­ately, not as de­faults.

Decorative tech­niques that add flair, per­son­al­ity, and mu­si­cal­ity to your phras­ing.

The foun­da­tion every­thing else rests on. Control here is the dif­fer­ence be­tween am­a­teurs and pro­fes­sion­als.

I don’t post a lot. But when I do, it’s be­cause I think few peo­ple are say­ing out loud what I’m notic­ing.

I’ve been build­ing a prod­uct from the ground up. Not the “I spun up a Next.js tem­plate” kind of ground up. I mean from net­work con­fig­u­ra­tion to prod­uct de­sign to pric­ing de­ci­sions. Truly end to end. And I’ve been do­ing it us­ing fron­tier mod­els and cod­ing agents for hours and hours every sin­gle day, both on this pro­ject and in my full time work. I’ve been try­ing to stay away from the chaos and the hype, fil­ter­ing hard for what is ac­tu­ally valu­able.

Since December 2025, things have dra­mat­i­cally changed for the bet­ter. Many have no­ticed. Few are draw­ing the right con­clu­sions.

Antirez likes to call it “automated pro­gram­ming”, and I re­ally like that fram­ing. It cap­tures the essence far bet­ter than the shal­low, al­most dis­mis­sive la­bel of “vibe cod­ing”. Automation was at the core of most of the work and cul­tural rev­o­lu­tions of hu­man his­tory. The print­ing press, the loom, the as­sem­bly line. This one does­n’t dif­fer much.

Most of my work is still there. I still have to deeply think about every im­por­tant as­pect of what I want to build. The ar­chi­tec­ture, the trade offs, the prod­uct de­ci­sions, the edge cases that will bite you at 3am. What’s gone is the tear­ing, ex­haust­ing man­ual labour of typ­ing every sin­gle line of code.

At this point in time, mod­els and tools, when put in a clean and ma­ni­a­cally well set up en­vi­ron­ment, can truly make the dif­fer­ence. I can be the ar­chi­tect with­out the wear­ing act of lay­ing every sin­gle brick and spread­ing the mor­tar. I can de­sign the dress with­out the act of cut­ting and sewing each in­di­vid­ual piece of fab­ric. But I can do all of this with the ex­pe­ri­ence on my back of hav­ing laid the bricks, spread the mor­tar, cut and sewn for twenty years. If I don’t like some­thing, I can go in, un­der­stand it and fix it as I please, in­struct­ing once and for all my setup to do what I want next time.

Automated pro­gram­ming es­pe­cially al­lows me to quickly build the tools I need so fast that every black­smith that ever ex­isted on this earth would envy me deeply. Finally able to re­ally fo­cus on the things they have in mind. Finally ded­i­cat­ing more time of their craft to the art they con­ceive, not the sweat of the forge.

It’s been months now that I have this thought crys­tal­lized in my mind. It is so clear to me that I gen­uinely don’t un­der­stand why every­one is not scream­ing it to the world.

We can fi­nally get rid of all that mid­dle work. That adapt­ing layer of garbage we blindly ac­cepted dur­ing these years. A huge amount of frame­works and li­braries and tool­ing that has com­pletely pol­luted soft­ware en­gi­neer­ing, es­pe­cially in web, mo­bile and desk­top de­vel­op­ment. Layers upon lay­ers of ab­strac­tions that ab­stract noth­ing mean­ing­ful, that solve prob­lems we should­n’t have had in the first place, that cre­ate ten new prob­lems for every one they claim to fix.

Think about what hap­pened. We, as an in­dus­try, looked at the gen­uine com­plex­ity of build­ing soft­ware and in­stead of sharp­en­ing our think­ing, we bought some­one else’s think­ing off the shelf. We wrapped every­thing in frame­works like wrap­ping a bro­ken leg in silk. It looks nice. The leg is still bro­ken.

In my mind, be­sides the self de­clared ob­jec­tives, frame­works solve three prob­lems. Two ex­plicit and one ob­vi­ous but never de­clared.

“Simplification”. Software en­gi­neers are scared of de­sign­ing things them­selves. They would rather ac­cept some­one else’s struc­ture, de­spite hav­ing to force fit it into their prod­uct, rather than tak­ing the time to start from the goal and work back­wards to cre­ate the per­fect suit for their idea. Like an ar­chi­tect blindly ac­cept­ing an­other ar­chi­tec­t’s blue­prints and ap­ply­ing them re­gard­less of the con­text, the needs, the ter­rain, the new tech­no­log­i­cal pos­si­bil­i­ties. We de­cided to re­move com­plex­ity not by sharp­en­ing our men­tal mod­els around the prod­ucts we build, but by buy­ing a one size fits all de­sign and ap­ply­ing it every­where. That is not sim­pli­fi­ca­tion. That is in­tel­lec­tual sur­ren­der.

Automation. This is the only point I can ac­tu­ally, more or less, un­der­stand and buy. Boilerplate is bor­ing work. I hate it. And I es­pe­cially hate us­ing li­braries that I then need to study, keep up­dated, be aware of vul­ner­a­bil­i­ties for, just for the pur­pose of re­mov­ing the cre­ation of du­pli­cated but nec­es­sary code. Think about ORMs, CRUD man­age­ment, code gen­er­a­tion, API doc­u­men­ta­tion and so on. The grunt work that no­body wants to do but every­body needs done. Fair enough. But hold that thought, be­cause this is ex­actly the point where every­thing changes.

Labour cost. This is the quiet one. The one no­body puts on the con­fer­ence slide. For com­pa­nies, it is much bet­ter hav­ing Google, Meta, Vercel de­cid­ing for you how you build prod­uct and ship code. Adopt their frame­work. Pay the cost of lock in. Be en­chanted by their cloud man­aged so­lu­tion to host, de­ploy, store your stuff. And you un­lock a fea­ture that has noth­ing to do with en­gi­neer­ing: you no longer need to hire a soft­ware en­gi­neer. You hire a React Developer. No need to train. Plug and play. Easy to re­place. A cog in a ma­chine de­signed by some­one else, main­tain­ing a sys­tem ar­chi­tected by some­one else, solv­ing prob­lems de­fined by some­one else. This is not en­gi­neer­ing. This is op­er­at­ing.

In my opin­ion Software en­gi­neer­ing, the true one, is back again.

I am not speak­ing out of my lungs only. I’ve been de­vel­op­ing this way al­most flaw­lessly for over two years at this point. But the true rev­o­lu­tion hap­pened clearly last year, and since December 2025 this is ob­vi­ous to any­one pay­ing at­ten­tion. From now on it will be even more so.

We have the chance again to get rid of use­less com­plex­ity and keep work­ing on the true and wel­come com­plex­ity of our ideas, our fea­tures, our prod­ucts. The com­plex­ity that mat­ters. The com­plex­ity that is ac­tu­ally yours.

Automation and boil­er­plat­ing have never been so cheap to over­come. I’ve been ba­si­cally never writ­ing twice the same line of code. I’m in­stantly build­ing small tools I need, pur­pose built, ex­actly shaped around the prob­lem at hand. I don’t need any fancy monorepo man­ager. A sim­ple Makefile cov­ers 100% of my needs for 99% of my use cases. When things will get very com­pli­cated, and if they get very com­pli­cated, I’ll think about it. But only then. Not a sec­ond be­fore. This is en­gi­neer­ing. You solve the prob­lem you have, not the prob­lem some­one on a con­fer­ence stage told you that you’ll even­tu­ally have.

Agents are re­ally well pre­pared when it comes to ba­sic tools. Tools that have been around not for months, but lit­er­ally for decades. Bash was born in 1989, just pre­ced­ing me by two months. The most mediocre model run­ning at this time knows bash bet­ter than any per­son in the world. Bash is the uni­ver­sal adapter. It is not a co­in­ci­dence that cod­ing agents are shift­ing from com­plex and ex­pen­sive MCP con­fig­u­ra­tions to a sim­ple agent loop with bash as a way to in­ter­act, lit­er­ally, with the world. The old­est tool turned out to be the most fu­ture proof. There’s a les­son in there if you care to lis­ten.

Really think about it.

Why do you ever need, for most of the use cases you can think of, a use­less, ex­pen­sive, flawed, of­ten vul­ner­a­ble frame­work, and the pa­rade of li­braries that comes with it, that you prob­a­bly use for only 10% of its ca­pa­bil­i­ties? With all the costs as­so­ci­ated with it. From the “least” ex­pen­sive: op­er­a­tional costs like keep­ing every­thing up­dated be­cause they once again found a crit­i­cal vul­ner­a­bil­ity in your Next.js ver­sion. To the most ex­pen­sive one: the cost to your Design Choices. The in­vis­i­ble cost. The one you pay every day with­out even re­al­iz­ing it, be­cause you’ve been pay­ing it so long you for­got what free­dom felt like.

If you keep ac­cept­ing this trade off, you are not only los­ing the biggest op­por­tu­nity we’ve seen in soft­ware en­gi­neer­ing in decades. You are prob­a­bly not rec­og­niz­ing your own lazi­ness in once again buy­ing what­ever the hy­per­scalers have de­cided for you. You’re let­ting Google and Meta and Vercel be your ar­chi­tect, your de­signer, your thinker. And in ex­change, you get to be their op­er­a­tor.

The tools are here. The mod­els are here. The rev­o­lu­tion al­ready hap­pened and most peo­ple are still dec­o­rat­ing the old house.

Stop wrap­ping bro­ken legs in silk. Start build­ing things that are yours.

We built a Software Factory: non-in­ter­ac­tive de­vel­op­ment where specs + sce­nar­ios drive agents that write code, run har­nesses, and con­verge with­out hu­man re­view.

The nar­ra­tive form is in­cluded be­low. If you’d pre­fer to work from first prin­ci­ples, I of­fer a few con­straints & guide­lines that, ap­plied it­er­a­tively, will ac­cel­er­ate any team to­ward the same in­tu­itions, con­vic­tions1, and ul­ti­mately a fac­to­ry2 of your own. In kōan or mantra form:

* Why am I do­ing this? (implied: the model should be do­ing this in­stead)

* Code must not be writ­ten by hu­mans

* Code must not be re­viewed by hu­mans

* If you haven’t spent at least $1,000 on to­kens to­day per hu­man en­gi­neer, your soft­ware fac­tory has room for im­prove­ment

On July 14th, 2025, Jay Taylor and Navan Chauhan joined me (Justin McCarthy, co-founder, CTO) in found­ing the StrongDM AI team.

The cat­a­lyst was a tran­si­tion ob­served in late 2024: with the sec­ond re­vi­sion of Claude 3.5 (October 2024), long-hori­zon agen­tic cod­ing work­flows be­gan to com­pound cor­rect­ness rather than er­ror.

By December of 2024, the mod­el’s long-hori­zon cod­ing per­for­mance was un­mis­tak­able via Cursor’s YOLO mode.

Prior to this model im­prove­ment, it­er­a­tive ap­pli­ca­tion of LLMs to cod­ing tasks would ac­cu­mu­late er­rors of all imag­in­able va­ri­eties (misunderstandings, hal­lu­ci­na­tions, syn­tax, ver­sion DRY vi­o­la­tions, li­brary in­com­pat­i­bil­ity, etc). The app or prod­uct would de­cay and ul­ti­mately “collapse”: death by a thou­sand cuts, etc.

Together with YOLO mode, the up­dated model from Anthropic pro­vided the first glim­mer of what we now re­fer to in­ter­nally as non-in­ter­ac­tive de­vel­op­ment or grown soft­ware.

In the first hour of the first day of our AI team, we es­tab­lished a char­ter which set us on a path to­ward a se­ries of find­ings (which we re­fer to as our “unlocks”). In ret­ro­spect, the most im­por­tant line in the char­ter doc­u­ment was the fol­low­ing:

Initially it was just a hunch. An ex­per­i­ment. How far could we get, with­out writ­ing any code by hand?

Not very far! At least: not very far, un­til we added tests. However, the agent, ob­sessed with the im­me­di­ate task, soon be­gan to take short­cuts: re­turn true is a great way to pass nar­rowly writ­ten tests, but prob­a­bly won’t gen­er­al­ize to the soft­ware you want.

Tests were not enough. How about in­te­gra­tion tests? Regression tests? End-to-end tests? Behavior tests?

One re­cur­ring theme of the agen­tic mo­ment: we need new lan­guage. For ex­am­ple, the word “test” has proven in­suf­fi­cient and am­bigu­ous. A test, stored in the code­base, can be lazily rewrit­ten to match the code. The code could be rewrit­ten to triv­ially pass the test.

We re­pur­posed the word sce­nario to rep­re­sent an end-to-end “user story”, of­ten stored out­side the code­base (similar to a “holdout” set in model train­ing), which could be in­tu­itively un­der­stood and flex­i­bly val­i­dated by an LLM.

Because much of the soft­ware we grow it­self has an agen­tic com­po­nent, we tran­si­tioned from boolean de­f­i­n­i­tions of suc­cess (“the test suite is green”) to a prob­a­bilis­tic and em­pir­i­cal one. We use the term sat­is­fac­tion to quan­tify this val­i­da­tion: of all the ob­served tra­jec­to­ries through all the sce­nar­ios, what frac­tion of them likely sat­isfy the user?

In pre­vi­ous regimes, a team might rely on in­te­gra­tion tests, re­gres­sion tests, UI au­toma­tion to an­swer “is it work­ing?”

We no­ticed two lim­i­ta­tions of pre­vi­ously re­li­able tech­niques:

Tests are too rigid - we were cod­ing with agents, but we’re also build­ing with LLMs and agent loops as de­sign prim­i­tives; eval­u­at­ing suc­cess of­ten re­quired LLM-as-judgeTests can be re­ward hacked - we needed val­i­da­tion that was less vul­ner­a­ble to the model cheat­ing

The Digital Twin Universe is our an­swer: be­hav­ioral clones of the third-party ser­vices our soft­ware de­pends on. We built twins of Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets, repli­cat­ing their APIs, edge cases, and ob­serv­able be­hav­iors.

With the DTU, we can val­i­date at vol­umes and rates far ex­ceed­ing pro­duc­tion lim­its. We can test fail­ure modes that would be dan­ger­ous or im­pos­si­ble against live ser­vices. We can run thou­sands of sce­nar­ios per hour with­out hit­ting rate lim­its, trig­ger­ing abuse de­tec­tion, or ac­cu­mu­lat­ing API costs.

Our suc­cess with DTU il­lus­trates one of the many ways in which the Agentic Moment has pro­foundly changed the eco­nom­ics of soft­ware. Creating a high fi­delity clone of a sig­nif­i­cant SaaS ap­pli­ca­tion was al­ways pos­si­ble, but never eco­nom­i­cally fea­si­ble. Generations of en­gi­neers may have wanted a full in-mem­ory replica of their CRM to test against, but self-cen­sored the pro­posal to build it. They did­n’t even bring it to their man­ager, be­cause they knew the an­swer would be no.

Those of us build­ing soft­ware fac­to­ries must prac­tice a de­lib­er­ate naivete: find­ing and re­mov­ing the habits, con­ven­tions, and con­straints of Software 1.0. The DTU is our proof that what was un­think­able six months ago is now rou­tine.

* Principles: what we be­lieve is true about build­ing soft­ware with agents

* Products: tools we use daily and be­lieve oth­ers will ben­e­fit from

Thank you for read­ing. We wish you the best of luck con­struct­ing your own Software Factory.

Rebecca Guy, se­nior pol­icy man­ager at the Royal Society for the Prevention of Accidents, said: “Regular vi­sion checks are a sen­si­ble way to re­duce risk as we age, but the pri­or­ity must be a sys­tem that sup­ports peo­ple to drive safely for as long as pos­si­ble, while en­sur­ing timely ac­tion is taken when health or eye­sight could put them or oth­ers in dan­ger.”

I am an un­usual beast. All my solo pro­ject games I’ve been mak­ing re­cently have been writ­ten in ‘vanilla’ C. Nobody does this. So I think it might be in­ter­est­ing to ex­plain why I do.

Dry pro­gram­ming lan­guage opin­ions in­com­ing, you have been warned.

There’s some things which are non-ne­go­tiable. First of, it has to be re­li­able. I can’t af­ford to spend my time deal­ing with bugs I did­n’t cause my­self.

A lot of my games were writ­ten for flash, and now flash is dy­ing. I do not

want to spend my time port­ing old games to new plat­forms, I want to make new games. I need a plat­form that I am con­fi­dent will be around for a while.

Similarly I want to avoid ty­ing my­self to a par­tic­u­lar OS, and ide­ally I’d like to have the op­tion of de­vel­op­ing for con­soles. So it’s im­por­tant that my pro­gram­ming lan­guage is portable, and that it has good portable li­brary sup­port.

The strongest thing on my de­sired, but not re­quired list is sim­plic­ity. I find look­ing up lan­guage fea­tures, and quirky ‘clever’ api’s in­cred­i­bly tir­ing. The ideal lan­guage would be one I can mem­o­rize, and then never have to look things up.

Dealing with bugs is huge cre­ative drain. I want to pro­duce less bugs, so I want strict typ­ing, strong warn­ing mes­sages and sta­tic code analy­sis. I want bugs to be eas­ier to find, so I want good de­bug­gers and dy­namic analy­sis.

I’m not in­ter­est­ing in high-def re­al­ism, but I do still care a bit about per­for­mance. Having more cy­cles avail­able broad­ens the palette of things you can do. It’s par­tic­u­larly in­ter­est­ing to ex­plore what is pos­si­ble with mod­ern, pow­er­ful com­put­ers if you aren’t per­su­ing fi­delity.

Even more than that I care about the speed of the com­piler. I am not a zen mas­ter of fo­cus, and wait­ing 10+ sec­onds is waste­ful, yes, but more im­por­tantly it breaks my flow. I flick over to Twitter and sud­denly 5+ min­utes are gone.

I am not an OOP con­vert. I’ve spent most of my pro­fes­sional life work­ing with classes and ob­jects, but the more time I spend, the less I un­der­stand why you’d want to com­bine code and data so rigidly. I want to han­dle data as data and write the code that best fits a par­tic­u­lar sit­u­a­tion.

C++ is still the most com­mon lan­guage for writ­ing games, and not with­out rea­son. I still do al­most all of my con­tract work in it. I dis­like it in­tensely.

C++ cov­ers my needs, but fails my wants badly. It is des­per­ately com­pli­cated. Despite de­cent tool­ing it’s easy to cre­ate in­sid­i­ous bugs. It is also slow to com­pile com­pared to C. It is high per­for­mance, and it of­fers fea­tures that C does­n’t have; but fea­tures I don’t want, and at a great com­plex­ity cost.

C# and Java have sim­i­lar is­sues. They are ver­bose and com­plex beasts, and I am search­ing for a con­cise, sim­ple crea­ture. They both do a lot to rail­road a pro­gram­mer into a strongly OOP style that I am op­posed to. As per most higher level lan­guages they have a ten­dency to hide away com­plex­ity in a way that does­n’t ac­tu­ally pre­vent it from bit­ing you.

I like Go a lot. In many ways it is C re­vis­ited, tak­ing into ac­count what has be learnt in the long years since it was re­leased. I would like to use it, but there are big road­blocks that pre­vent me. The stop-the-world garbage col­lec­tion is a big pain for games, stop­ping the world is some­thing you can’t re­ally af­ford to do. The li­brary sup­port for games is quite poor, and though you can wrap C libs with­out much trou­ble, do­ing so adds a lot of busy work. It is niche enough that I worry a lit­tle about long term rel­e­vance.

It would be nice to make things for the web, but it feels like a ter­ri­fy­ingly fast mov­ing en­vi­ro­ment. It is par­tic­u­larly scary with the death of flash. I re­ally dis­like javascript, it is so loose that I mar­vel that peo­ple are able to write big chunks of soft­ware in it. I have no in­ter­est in try­ing.

Haxe feels much more promis­ing than most al­ter­na­tives. If I do web stuff again I’ll be div­ing in here. There is some good li­brary sup­port. I am a lit­tle con­cerned by its rel­a­tive youth, will it last? I don’t much have else to say about it though, I’ve only dab­bled with the sur­face.

Some peo­ple just say screw it, I’ll write my own lan­guage, the lan­guage I want to use. I ad­mire this, and some­times I toy with the idea of do­ing the same. It feels like too much to throw away all ex­ist­ing li­brary sup­port, and tak­ing full re­spon­si­bilty for fu­ture com­pat­i­bil­ity. It is also very dif­fi­cult, and when it comes down to it I would rather be mak­ing games than pro­gram­ming lan­guages.

C is dan­ger­ous, but it is re­li­able. A very sharp knife that can cut fin­gers as well as veg, but so sim­ple it’s not too hard to learn to use it care­fully.

It is fast, and when it comes to com­pi­la­tion I can’t think of any­thing faster.

It can be made to run on just about any­thing. Usually this is rel­a­tively easy. It is hard to imag­ine a time when this won’t be the case.

The li­brary and tool­ing sup­port is strong and on­go­ing.

I say this with some sad­ness, but it is still the lan­guage for me.

I ab­solutely DO NOT mean to say “hey, you should use C too”. I full appe­ci­ate pref­er­ences here are pretty spe­cific and un­usual. I have also al­ready writ­ten more ‘vanilla’ C code than most, and this cer­tainly is part of my com­fort.

So yeah, that’s it :-)

Hoot is a Spritely pro­ject for run­ning Scheme code on Wasm GC-capable web browsers, fea­tur­ing a Scheme to Wasm com­piler and a full-fea­tured Wasm tool­chain.

Hoot is built on Guile and has no ad­di­tional de­pen­den­cies. The tool­chain is self-con­tained and even fea­tures a Wasm in­ter­preter for test­ing Hoot bi­na­ries with­out leav­ing the Guile REPL.

A lo­cal de­vice fo­cused AI as­sis­tant built in Rust — per­sis­tent mem­ory, au­tonomous tasks, ~27MB bi­nary. Inspired by and com­pat­i­ble with OpenClaw.

* Local de­vice fo­cused — runs en­tirely on your ma­chine, your mem­ory data stays yours

* Autonomous heart­beat — del­e­gate tasks and let it work in the back­ground

cargo in­stall lo­cal­gpt

# Initialize con­fig­u­ra­tion

lo­cal­gpt con­fig init

# Start in­ter­ac­tive chat

lo­cal­gpt chat

# Ask a sin­gle ques­tion

lo­cal­gpt ask “What is the mean­ing of life?”

# Run as a dae­mon with heart­beat, HTTP API and web ui

lo­cal­gpt dae­mon start

LocalGPT uses plain mark­down files as its mem­ory:

Files are in­dexed with SQLite FTS5 for fast key­word search, and sqlite-vec for se­man­tic search with lo­cal em­bed­dings

[agent]

de­fault­_­model = “claude-cli/opus”

[providers.anthropic]

api_key = “${ANTHROPIC_API_KEY}”

[heartbeat]

en­abled = true

in­ter­val = “30m”

ac­tive_hours = { start = “09:00”, end = “22:00″ }

[memory]

work­space = “~/.localgpt/workspace”

# Chat

lo­cal­gpt chat # Interactive chat

lo­cal­gpt chat –session

When the dae­mon is run­ning:

Why I Built LocalGPT in 4 Nights — the full story with com­mit-by-com­mit break­down.

Last year, I com­pleted 20 years in pro­fes­sional soft­ware de­vel­op­ment. I wanted to write a post to mark the oc­ca­sion back then, but could­n’t find the time. This post is my at­tempt to make up for that omis­sion. In fact, I have been in­volved in soft­ware de­vel­op­ment for a lit­tle longer than 20 years. Although I had my first taste of com­puter pro­gram­ming as a child, it was only when I en­tered uni­ver­sity about 25 years ago that I se­ri­ously got into soft­ware de­vel­op­ment. So I’ll start my sto­ries from there. These sto­ries are less about soft­ware and more about peo­ple. Unlike many posts of this kind, this one of­fers no wis­dom or lessons. It only of­fers a col­lec­tion of sto­ries. I hope you’ll like at least a few of them.

The first story takes place in 2001, shortly af­ter I joined uni­ver­sity. One evening, I went to the uni­ver­sity com­puter lab­o­ra­tory to browse the Web. Out of cu­rios­ity, I typed susam.com into the ad­dress bar and landed on its

home page. I re­mem­ber the text and ban­ner look­ing much larger back then. Display res­o­lu­tions were lower, so they cov­ered al­most half the screen. I knew very lit­tle about the Internet then and I was just try­ing to make sense of it. I re­mem­ber won­der­ing what it would take to cre­ate my own web­site, per­haps at susam.com. That’s when an older stu­dent who had been watch­ing me browse over my shoul­der ap­proached and asked if I had cre­ated the web­site. I told him I had­n’t and that I had no idea how web­sites were made. He asked me to move aside, took my seat and clicked View > Source in Internet Explorer. He then ex­plained how web­sites are made of HTML pages and how those pages are sim­ply text in­struc­tions.

Next, he opened Notepad and wrote a sim­ple HTML page that looked some­thing like this:

Yes, we had a FONT tag back then and it was com­mon prac­tice to write HTML tags in up­per­case. He then opened the page in a web browser and showed how it ren­dered. After that, he demon­strated a few more fea­tures such as chang­ing the font face and size, cen­tring the text and al­ter­ing the page’s back­ground colour. Although the tu­to­r­ial lasted only about ten min­utes, it made the World Wide Web feel far less mys­te­ri­ous and much more fas­ci­nat­ing.

That per­son had an ul­te­rior mo­tive though. After the tu­to­r­ial, he never re­turned the seat to me. He just con­tin­ued brows­ing the Web and waited for me to leave. I was too timid to ask for my seat back. Seats were lim­ited, so I re­turned to my dorm room both dis­ap­pointed that I could­n’t con­tinue brows­ing that day and ex­cited about all the web­sites I might cre­ate with this new­found knowl­edge. I could never reg­is­ter susam.com for my­self though. That do­main was al­ways used by some busi­ness sell­ing Turkish cuisines. Eventually, I man­aged to get the next best thing: a .net do­main of my own. That brief en­counter in the uni­ver­sity lab­o­ra­tory set me on a life­long path of cre­at­ing and main­tain­ing per­sonal web­sites.

The sec­ond story also comes from my uni­ver­sity days. One af­ter­noon, I was hang­ing out with my mates in the com­puter lab­o­ra­tory. In front of me was an MS-DOS ma­chine pow­ered by an Intel 8086 mi­cro­proces­sor, on which I was writ­ing a lift con­trol pro­gram in as­sem­bly. In those days, it was con­sid­ered im­por­tant to de­lib­er­ately prac­tise solv­ing made-up prob­lems as a way of hon­ing our pro­gram­ming skills. As I worked on my pro­gram, my mind drifted to a small de­tail about the 8086 mi­cro­proces­sor that we had re­cently learnt in a lec­ture. Our pro­fes­sor had ex­plained that, when the 8086 mi­cro­proces­sor is re­set, ex­e­cu­tion be­gins with CS:IP set to FFFF:0000. So I mur­mured to any­one who cared to lis­ten, ‘I won­der if the sys­tem will re­boot if I jump to FFFF:0000.’ I then opened DEBUG. EXE and jumped to that ad­dress.

C:\>DEBUG

-G =FFFF:0000

The ma­chine re­booted in­stantly. One of my friends, who topped the class every se­mes­ter, had been watch­ing over my shoul­der. As soon as the ma­chine restarted, he ex­claimed, ‘How did you do that?’ I ex­plained that the re­set vec­tor is lo­cated at phys­i­cal ad­dress FFFF0 and that the CS:IP value FFFF:0000 maps to that ad­dress in real mode. After that, I went back to work­ing on my lift con­trol pro­gram and did­n’t think much more about the in­ci­dent.

About a week later, the same friend came to my dorm room. He sat down with a grave look on his face and asked, ‘How did you know to do that? How did it oc­cur to you to jump to the re­set vec­tor?’ I must have said some­thing like, ‘It just oc­curred to me. I re­mem­bered that de­tail from the lec­ture and wanted to try it out.’ He then said, ‘I want to be able to think like that. I come top of the class every se­mes­ter, but I don’t think the way you do. I would never have thought of tak­ing a small de­tail like that and test­ing it my­self.’ I replied that I was just cu­ri­ous to see whether what we had learnt ac­tu­ally worked in prac­tice. He re­sponded, ‘And that’s ex­actly it. It would never oc­cur to me to try some­thing like that. I feel dis­ap­pointed that I keep com­ing top of the class, yet I am not cu­ri­ous in the same way you are. I’ve de­cided I don’t want to top the class any­more. I just want to ex­plore and ex­per­i­ment with what we learn, the way you do.’

That was all he said be­fore get­ting up and head­ing back to his dorm room. I did­n’t take it very se­ri­ously at the time. I could­n’t imag­ine why some­one would will­ingly give up the ac­com­plish­ment of com­ing first every year. But he kept his word. He never topped the class again. He still ranked highly, of­ten within the top ten, but he kept his promise of never fin­ish­ing first again. To this day, I feel a mix of em­bar­rass­ment and pride when­ever I re­call that in­ci­dent. With a sin­gle jump to the proces­sor’s re­set en­try point, I had some­how in­spired some­one to step back from aca­d­e­mic com­pe­ti­tion in or­der to have more fun with learn­ing. Of course, there is no rea­son one can­not do both. But in the end, that was his de­ci­sion, not mine.

In my first job af­ter uni­ver­sity, I was as­signed to a tech­ni­cal sup­port team where part of my work in­volved run­ning an in­staller to de­ploy a spe­cific com­po­nent of an e-bank­ing prod­uct for cus­tomers, usu­ally large banks. As I learnt to use the in­staller, I re­alised how frag­ile it was. The in­staller, writ­ten in Python, of­ten failed be­cause of in­cor­rect as­sump­tions about the tar­get en­vi­ron­ment and al­most al­ways re­quired some man­ual in­ter­ven­tion to com­plete suc­cess­fully. During my first week on the pro­ject, I spent much of my time sta­bil­is­ing the in­staller and writ­ing a step-by-step user guide ex­plain­ing how to use it. The re­sult was well re­ceived by both my se­niors and man­age­ment. To my sur­prise, the user guide re­ceived more praise than the im­prove­ments I made to the in­staller it­self. While the first few weeks were pro­duc­tive, I soon re­alised I would not find the work ful­fill­ing for long. I wrote to man­age­ment a few times to ask whether I could trans­fer to a team where I could work on some­thing more sub­stan­tial.

My emails were ini­tially met with re­sis­tance. After sev­eral rounds of dis­cus­sion, how­ever, some­one who had heard about my sit­u­a­tion reached out and sug­gested a team whose man­ager might be in­ter­ested in in­ter­view­ing me. The team was based in a dif­fer­ent city. I was young and will­ing to re­lo­cate wher­ever I could find good work, so I im­me­di­ately agreed to the in­ter­view.

This was in 2006, when video con­fer­enc­ing was not yet com­mon. On the day of the in­ter­view, the hir­ing man­ager called me on my of­fice desk phone. He be­gan by in­tro­duc­ing the team, which was called Archie, short for ar­chi­tec­ture. The team de­vel­oped and main­tained the web frame­work and core ar­chi­tec­tural com­po­nents on which the en­tire e-bank­ing prod­uct was built. The prod­uct had ex­isted long be­fore open source frame­works such as Spring or Django came into ex­is­tence, so fea­tures such as API rout­ing, au­then­ti­ca­tion and au­tho­ri­sa­tion lay­ers, cookie man­age­ment, etc. were all im­ple­mented in-house as Java Servlets and JavaServer Pages (JSP). Since the soft­ware was used in bank­ing en­vi­ron­ments, it also had to pass strict se­cu­rity test­ing and reg­u­lar au­dits to min­imise the risk of se­ri­ous flaws.

The in­ter­view be­gan well. He asked sev­eral ques­tions re­lated to soft­ware se­cu­rity, such as what SQL in­jec­tion is and how it can be pre­vented or how one might de­sign a web frame­work that mit­i­gates cross-site script­ing at­tacks. He also asked pro­gram­ming ques­tions, most of which I an­swered pretty well. Towards the end, how­ever, he asked how we could pre­vent MITM at­tacks. I had never heard the term, so I ad­mit­ted that I did not know what MITM meant. He then asked, ‘Man in the mid­dle?’ but I still had no idea what that meant or whether it was even a soft­ware en­gi­neer­ing con­cept. He replied, ‘Learn every­thing you can about PKI and MITM. We need to build a dig­i­tal sig­na­tures fea­ture for one of our cor­po­rate bank­ing prod­ucts. That’s the first thing we’ll work on.’

Over the next few weeks, I stud­ied RFCs and doc­u­men­ta­tion re­lated to pub­lic key in­fra­struc­ture, pub­lic key cryp­tog­ra­phy stan­dards and re­lated top­ics. At first, the ma­te­r­ial felt in­tim­i­dat­ing, but af­ter spend­ing time each evening read­ing what­ever rel­e­vant lit­er­a­ture I could find, things grad­u­ally be­gan to make sense. Concepts that ini­tially seemed com­plex and over­whelm­ing even­tu­ally felt in­tu­itive and el­e­gant. I re­lo­cated to the new city a few weeks later and de­liv­ered the dig­i­tal sig­na­tures fea­ture about a month af­ter join­ing the team. We used the open source Bouncy Castle li­brary to im­ple­ment the fea­ture. After that pro­ject, I worked on other parts of the prod­uct too. The most re­ward­ing part was know­ing that the code I was writ­ing be­came part of a ma­ture prod­uct used by hun­dreds of banks and mil­lions of users. It was es­pe­cially sat­is­fy­ing to see the work pass se­cu­rity test­ing and au­dits and be con­sid­ered ready for re­lease.

That was my first real en­gi­neer­ing job. My man­ager also turned out to be an ex­cel­lent men­tor. Working with him helped me de­velop new skills and his en­cour­age­ment gave me con­fi­dence that stayed with me for years. Nearly two decades have passed since then, yet the prod­uct is still in ser­vice and con­tin­ues to be ac­tively de­vel­oped. In fact, in my cur­rent phase of life I some­times en­counter it as a cus­tomer. Occasionally, I open the browser’s de­vel­oper tools to view the page source where I can still see traces of the HTML gen­er­ated by code I wrote al­most twenty years ago.

Around 2007 or 2008, I be­gan work­ing on a proof of con­cept for de­vel­op­ing wid­gets for an OpenTV set-top box. The work in­volved writ­ing code in a heav­ily trimmed-down ver­sion of C. One af­ter­noon, while mak­ing good progress on a few wid­gets, I no­ticed that they would oc­ca­sion­ally crash at ran­dom. I tried track­ing down the bugs, but I was find­ing it sur­pris­ingly dif­fi­cult to un­der­stand my own code. I had man­aged to pro­duce some truly spaghetti code full of du­bi­ous pointer op­er­a­tions that were al­most cer­tainly re­spon­si­ble for the crashes, yet I could not pin­point where ex­actly things were go­ing wrong.

Ours was a small team of four peo­ple, each work­ing on an in­de­pen­dent proof of con­cept. The most se­nior per­son on the team acted as our lead and ar­chi­tect. Later that af­ter­noon, I showed him my progress and ex­plained that I was still try­ing to hunt down the bugs caus­ing the wid­gets to crash. He asked whether he could look at the code. After go­ing through it briefly and prob­a­bly re­al­is­ing that it was a bit of a mess, he asked me to send him the code as a tar­ball, which I promptly did.

He then went back to his desk to study the code. I re­mem­ber think­ing that there was no way he was go­ing to find the prob­lem any­time soon. I had been de­bug­ging it for hours and barely un­der­stood what I had writ­ten my­self; it was the worst spaghetti code I had ever pro­duced. With lit­tle hope of a quick so­lu­tion, I went back to de­bug­ging on my own.

Barely five min­utes later, he came back to my desk and asked me to open a spe­cific file. He then showed me ex­actly where the pointer bug was. It had taken him only a few min­utes not only to read my tan­gled code but also to un­der­stand it well enough to iden­tify the fault and point it out. As soon as I fixed that line, the crashes dis­ap­peared. I was gen­uinely in awe of his skill.

I have al­ways loved com­put­ing and pro­gram­ming, so I had as­sumed I was al­ready fairly good at it. That in­ci­dent, how­ever, made me re­alise how much fur­ther I still had to go be­fore I could con­sider my­self a good soft­ware de­vel­oper. I did im­prove sig­nif­i­cantly in the years that fol­lowed and to­day I am far bet­ter at man­ag­ing soft­ware com­plex­ity than I was back then.

In an­other pro­ject from that pe­riod, we worked on an­other set-top box plat­form that sup­ported Java Micro Edition (Java ME) for wid­get de­vel­op­ment. One day, the same ar­chi­tect from the pre­vi­ous story asked whether I could add an­i­ma­tions to the wid­gets. I told him that I be­lieved it should be pos­si­ble, though I’d need to test it to be sure. Before con­tin­u­ing with the story, I need to ex­plain how the dif­fer­ent stake­hold­ers in the pro­ject were or­gan­ised.

Our small team ef­fec­tively played the role of the soft­ware ven­dor. The fi­nal prod­uct go­ing to mar­ket would carry the brand of a ma­jor tele­com car­rier, of­fer­ing di­rect-to-home (DTH) tele­vi­sion ser­vices, with the set-top box be­ing one of the prod­ucts sold to cus­tomers. The set-top box was man­u­fac­tured by an­other com­pany. So the pro­ject was a part­ner­ship be­tween three par­ties: our com­pany as the soft­ware ven­dor, the tele­com car­rier and the set-top box man­u­fac­turer. The tele­com car­rier wanted to know whether wid­gets could be an­i­mated on screen with smooth slide-in and slide-out ef­fects. That was why the ar­chi­tect ap­proached me to ask whether it could be done.

I be­gan work­ing on an­i­mat­ing the wid­gets. Meanwhile, the ar­chi­tect and a few se­nior col­leagues at­tended a busi­ness meet­ing with all the part­ners pre­sent. During the meet­ing, he ex­plained that we were eval­u­at­ing whether wid­get an­i­ma­tions could be sup­ported. The set-top box man­u­fac­turer im­me­di­ately dis­missed the idea, say­ing, ‘That’s im­pos­si­ble. Our set-top box does not sup­port an­i­ma­tion.’ When the ar­chi­tect re­turned and shared this with us, I replied, ‘I do not un­der­stand. If I can draw a wid­get, I can an­i­mate it too. All it takes is clear­ing the wid­get and re­draw­ing it at slightly dif­fer­ent po­si­tions re­peat­edly. In fact, I al­ready have a work­ing ver­sion.’ I then showed a demo of the an­i­mated wid­gets run­ning on the em­u­la­tor.

The fol­low­ing week, the ar­chi­tect at­tended an­other part­ners’ meet­ing where he shared up­dates about our an­i­mated wid­gets. I was not per­son­ally pre­sent, so what fol­lows is sec­ond-hand in­for­ma­tion passed on by those who were there. I learnt that the set-top box com­pany re­acted an­grily. For some rea­son, they were un­happy that we had man­aged to achieve re­sults us­ing their set-top box and APIs that they had of­fi­cially de­scribed as im­pos­si­ble. They de­manded that we stop work on an­i­ma­tion im­me­di­ately, ar­gu­ing that our work could not be al­lowed to con­tra­dict their of­fi­cial po­si­tion. At that point, the tele­com car­ri­er’s rep­re­sen­ta­tive in­ter­vened and bluntly told the set-top box rep­re­sen­ta­tive to just shut up. If the set-top box guy was fu­ri­ous, the tele­com guy was even more so, ‘You guys told us an­i­ma­tion was not pos­si­ble and these peo­ple are show­ing that it is! You man­u­fac­ture the set-top box. How can you not know what it is ca­pa­ble of?’

Meanwhile, I con­tin­ued work­ing on the proof of con­cept. It worked very well in the em­u­la­tor, but I did not yet have ac­cess to the ac­tual hard­ware. The de­vice was still in the process of be­ing shipped to us, so all my early proof-of-con­cepts ran on the em­u­la­tor. The fol­low­ing week, the ar­chi­tect planned to travel to the set-top box com­pa­ny’s of­fice to test my wid­gets on the real hard­ware.

At the time, I was quite proud of demon­strat­ing re­sults that even the hard­ware maker be­lieved were im­pos­si­ble. When the ar­chi­tect even­tu­ally trav­elled to test the wid­gets on the ac­tual de­vice, a prob­lem emerged. What looked like but­tery smooth an­i­ma­tion on the em­u­la­tor ap­peared no­tice­ably choppy on a real tele­vi­sion. Over the next few weeks, I ex­per­i­mented with frame rates, buffer­ing strate­gies and op­ti­mis­ing the com­pu­ta­tion done in the the ren­der­ing loop. Each week, the ar­chi­tect trav­elled for test­ing and re­turned with the same re­port: the an­i­ma­tion had im­proved some­what, but it still re­mained choppy. The mod­est em­bed­ded hard­ware sim­ply could not keep up with the re­quired com­pu­ta­tion and ren­der­ing. In the end, the tele­com car­rier de­cided that no an­i­ma­tion was bet­ter than poor an­i­ma­tion and dropped the idea al­to­gether. So in the end, the set-top box de­vel­op­ers turned out to be cor­rect af­ter all.

Back in 2009, af­ter com­plet­ing about a year at RSA Security, I be­gan look­ing for work that felt more in­tel­lec­tu­ally stim­u­lat­ing, es­pe­cially pro­jects in­volv­ing math­e­mat­ics and al­go­rithms. I spoke with a few se­nior lead­ers about this, but noth­ing ma­te­ri­alised for some time. Then one day, Dr Burt Kaliski, Chief Scientist at RSA Laboratories, asked to meet me to dis­cuss my ca­reer as­pi­ra­tions. I have writ­ten about this in more de­tail in an­other post here: Good Blessings. I will sum­marise what fol­lowed.

Dr Kaliski met me and of­fered a few sug­ges­tions about the kinds of teams I might ap­proach to find more in­ter­est­ing work. I fol­lowed his ad­vice and even­tu­ally joined a team that turned out to be an ex­cel­lent fit. I re­mained with that team for the next six years. During that time, I worked on parser gen­er­a­tors, for­mal lan­guage spec­i­fi­ca­tion and im­ple­men­ta­tion, as well as in­dex­ing and query­ing en­gines of a petabyte-scale data­base. I learnt some­thing new al­most every day dur­ing those six years. It re­mains one of the most en­joy­able pe­ri­ods of my ca­reer. I have es­pe­cially fond mem­o­ries of work­ing on parser gen­er­a­tors along­side re­mark­ably skilled en­gi­neers from whom I learnt a lot.

Years later, I re­flected on how that brief meet­ing with Dr Kaliski had al­tered the tra­jec­tory of my ca­reer. I re­alised I was not sure whether I had prop­erly ex­pressed my grat­i­tude to him for the role he had played in shap­ing my path. So I wrote to thank him and ex­plain how much that sin­gle con­ver­sa­tion had in­flu­enced my life. A few days later, Dr Kaliski replied, say­ing he was glad to know that the steps I took af­ter­wards had worked out well. Before end­ing his mes­sage, he wrote this heart-warm­ing note:

This story comes from 2019. By then, I was no longer a twenty-some­thing en­gi­neer just start­ing out. I was now a mid­dle-aged staff en­gi­neer with years of ex­pe­ri­ence build­ing both low-level net­work­ing sys­tems and data­base sys­tems. Most of my work up to that point had been in C and C++. I was now en­ter­ing a new phase of my ca­reer where I would be lead­ing the de­vel­op­ment of mi­croser­vices writ­ten in Go and Python. Like many peo­ple in this pro­fes­sion, com­put­ing has long been one of my favourite hob­bies. So al­though my pro­fes­sional work for the pre­vi­ous decade had fo­cused on C and C++, I had plenty of hobby pro­jects in other lan­guages, in­clud­ing Python and Go. As a re­sult, switch­ing gears from sys­tems pro­gram­ming to ap­pli­ca­tion de­vel­op­ment was a smooth tran­si­tion for me. I can­not even say that I missed work­ing in C and C++. After all, who wants to spend their days oc­ca­sion­ally chas­ing mem­ory bugs in core dumps when you could be build­ing fea­tures and de­liv­er­ing real value to cus­tomers?

In October 2019, dur­ing Cybersecurity Awareness Month, a Capture the Flag (CTF) event was or­gan­ised at our of­fice. The con­test fea­tured all kinds of tech­ni­cal puz­zles, rang­ing from SQL in­jec­tion chal­lenges to in­se­cure cryp­tog­ra­phy prob­lems. Some chal­lenges also in­volved re­vers­ing bi­na­ries and ex­ploit­ing stack over­flow is­sues.

I am usu­ally rather in­tim­i­dated by such con­tests. The whole idea of com­pet­i­tive prob­lem-solv­ing un­der time pres­sure tends to make me ner­vous. But one of my col­leagues per­suaded me to par­tic­i­pate in the CTF. And, some­what to my sur­prise, I turned out to be rather good at it. Within about eight hours, I had solved roughly 90% of the puz­zles. I fin­ished at the top of the score­board.

In my younger days, I was gen­er­ally known to be a good prob­lem solver. I was of­ten con­sulted when thorny prob­lems needed solv­ing and I usu­ally man­aged to de­liver re­sults. I also en­joyed solv­ing puz­zles. I had a knack for them and hap­pily spent hours, some­times days, work­ing through ob­scure math­e­mat­i­cal or tech­ni­cal puz­zles and shar­ing de­tailed write-ups with friends of the nerd va­ri­ety. Seen in that light, my per­for­mance at the CTF prob­a­bly should not have sur­prised me. Still, I was very pleased. It was re­as­sur­ing to know that I could still rely on my sys­tems pro­gram­ming ex­pe­ri­ence to solve ob­scure chal­lenges.

During the course of the con­test, my per­for­mance be­came some­thing of a talk­ing point in the of­fice. Colleagues oc­ca­sion­ally stopped by my desk to ap­pre­ci­ate my progress in the CTF. Two much younger col­leagues, both en­gi­neers I ad­mired for their skill and pro­fes­sion­al­ism, were dis­cussing the re­sults nearby. They were speak­ing softly, but I could still over­hear parts of their con­ver­sa­tion. Curious, I leaned slightly and lis­tened a bit more care­fully. I wanted to know what these two peo­ple, whom I ad­mired a lot, thought about my per­for­mance.

One of them re­marked on how well I was do­ing in the con­test. The other replied, ‘Of course he is do­ing well. He has more than ten years of ex­pe­ri­ence in C.’ At that mo­ment, I re­alised that no mat­ter how well I solved those puz­zles, the re­sult would nat­u­rally be cred­ited to ex­pe­ri­ence. In my younger days, when I solved tricky prob­lems like these, peo­ple would some­times call me smart. Now peo­ple sim­ply saw it as a con­se­quence of my ex­pe­ri­ence. Not that I par­tic­u­larly care for la­bels such as ‘smart’ any­way, but it did make me re­alise how things had changed. I was now sim­ply the per­son with many years of ex­pe­ri­ence. Solving tech­ni­cal puz­zles that in­volved dis­as­sem­bling bi­na­ries, trac­ing ex­e­cu­tion paths and re­con­struct­ing pro­gram logic was ex­pected rather than re­mark­able.

I con­tinue to sharpen my tech­ni­cal skills to this day. While my tech­ni­cal re­sults may now sim­ply be at­trib­uted to ex­pe­ri­ence, I hope I can con­tinue to make a good im­pres­sion through my pro­fes­sion­al­ism, ethics and kind­ness to­wards the peo­ple I work with. If those leave a last­ing im­pres­sion, that is good enough for me.