Rat In Mi Kitchen
There's a rat in mi kitchen there's a rat in mi kitchen what I'm I gonna do
There's a rat in mi kitchen there's a rat in mi kitchen what I'm I gonna do
I'm gonna fix the rat that's what am gonna do
I'm gonna fix that rat
Conviction and simplicity
Creating something simple requires a sobering attitude. Rather than rushing ahead with the first proposed plan, let the ideas simmer for a bit while you figure out whether there's actually any substance in them.
Persuation requires conviction, and conviction is not expressed through slow "maybe" answers to every question.
I feel like this is a core tension in marketing of technology - high-quality, simple systems require *work*, whereas effective communication about the benefits of said technology is about telling a story, convincingly.
Falsifiably tasty
Taste and falsifiability are both tremendously important, yet sharp tools that can be used too much and too little.
Too little taste and you never build your taste. Too much taste, and you agitate and anger people rather than discussing constructively. Too little falsifiability, and you don't know what's happening and it doesn't work. Too much falsifiability and you destroy nice things that don't carry objective truths.
I encourage you to pick up the knife edges of both falsifiability and taste, keep those edges sharp and try to stay on top of both.
Fire and steel: Clojure in two words - version 2
We want results at our fingertips, and systems we never need to touch again. Forge it with fire, build it with steel.
We achieve this goal by abstracting with data rather than code. Code will never fit into one hierarchy, because code doesn't intrinsically belong in one place. Instead, we structure code by structuring data. And we namespace that data. Our system design improves as we get better data namespaces.
That namespaced data helps further exploration: we can light our fire, move further and forge more steel.
Fire and steel: Clojure in two words
In creative pursuits, we need the fire of creativity and the reliability of steel. Clojure gives both. The REPL burns, and immutable data holds.
Conviction, courage and curiosity.
We ARE going to get there. We will take the first step. And on every step, we will look around, observe, judge and act.
We don't yet know what we are facing, but we are going to get there.
That confident curiosity is courage.
Confident in your skills and your team. Belief in the problem you're solving.
That confidence doesn't rise because the outcome is certain. It rises from being prepared. You know where you stand. You know where your team stands. You know your craft. You open your eyes, and stride into the unknown. Prepared, confident, curious.
Use curiosity, not doubt to temper legibility
Legibility is maximal when everything is static, so static it never moves and never can move.
We need creation, however. We need a bit of chaos. We need some fire.
Don't light that fire with fear, uncertainty and doubt. Light it with determined curiosity. Everyone fearing and doubting is NOT going to solve the problem. Exploring it for what it is, however, will.
Effektivt teamarbeid er orden og kaos i vill harmoni
Det kjedelige bør være dødt forutsigbart, sånn at vi kan bruke innsatsen vår på de faktiske problemene. Gjør det enkle så selvinnsigende at det løser seg selv, og lag DERETTER rom til å jobbe på de vanskelige problemene. Vi må ha begge. Kun kjedelig forutsigbarhet er gørr kjedelig, gir null intellektuell stimulering, og løser kun jobber som kunne vært automatisert bort.
Kontinuerlig kaos der alt flyr i alle retninger fører til at vi løper i sirkler uten å få gjort det vi skal.
Vi trenger begge - et dønn stabilt fundament som funker og støtter oss i jobben vi skal gjøre, og vilje, evne og mot til å møte utfordringer vi ikke vet, for så å gjøre det beste vi kan.
In the market for some legibility
Over the last year, I've learned a lot about limiting work in progress. I started working with Christian and Magnar in october, and Magnar in particular is exceptionally good at this. He doesn't start shit because he gets distracted - he finishes the important work.
Getting the important work done is of course tremendously useful - but what struck me the most is the legibility we gain from such a process. We don't introduce noise into the system - instead we work rigorously to limit the noise, so that the essence we're left with is perfectly LEGIBLE.
When I hear myself liking that legibility, I think of Seeing Like a State. In the 1700s (I think), German forestry authorities decided to clean up the woods. Easier if we just have one or two sorts of trees, right? Efficiency was gained the next time trees were felled, but two generations in, yield dropped. The ground was no longer fertile.
--
So -
1. Legibility is a sort of simplicity - the simpler, the better
2. .... but don't destroy the soil in pursuit of legibility - new things must grow.
Datastar strikes again
Listening to the podcast episode with Anders Muphy.
I find myself getting more and more motivated to try out Datastar.
1. No frontend build required
2. Push
3. No endpoint exposion
4. Just push new elements with IDs
So — what could be interesting to build?
Easy mode: remake this (stack.teod.eu) with Datastar.
Harder mode: demonstrate how Nexus and Replicant can be used on the server to power Datastar — no Clojurescript, no build required.
Also curious if Datastar should match Borkdude's lightweight CLJS universe in some way — squint or scittle maybe.
Perhaps the most exciting part is that by dropping the frontend build, I can drive everything from a REPL, and deploy to application.garden with zero hassle.
Hvorfor skulle på beslutninger og utførelse i kode?
Også kjent som "hvordan gjøre nytte av skillet mellom departement og direktorat i systemene du lager".
Datastar?
This site is built on HTMX. Having the entire app in one file, in one language is amazing.
Datastar is similar, but different. All of the state is on the server, and the server can push changes to the client if it pleases.
https://www.youtube.com/watch?v=6nn6YEbwf-k&t=1237s
This got me curious. It's Go and some events sent from the server.
The OTHER thing that got me curious is Open Props (https://open-props.style). Open props is *not* tailwind, but serves a similar purpose.
A new day dawns.
… and a new data structure carries its weight.
Remember to refresh the content after a new save.
This should be possible to do with HTMX. In fact, https://htmx.org/examples/update-other-content/ is written for exactly this use case.
Editing is necessary, append-only logs grow verbose
If stack.teod.eu aims to be an idea stack, ideas must be allowed to grow. Currently, they don't. I write the title for an idea, then push it. This is currently an idea bin.
Supporting edits shouldn't be too hard.
Downfall: on the blinding of perception and the killing of rebirth, a programmer's tale
"Hold det så enkelt som mulig" er en god ting!
UI og kode som jobber på SAMME AST.
- python kan importere ast-et
- og UI-et kan redigere samme greie
I kode kan du sjekke nåværende verdi, eller abonnere på endringer.
I wonder if anyone else have written weeknotes.
Three modes when creating:
- expand
- select
- reduce wip / cleanup
1. Datomic i mikrobloggeriet var en braksuksess!
2. Jeg vil lage file watcher som kun kjører når GARDEN_GIT_REVISION ikke er tilstede
3. Jeg vil lage en matte-poc med codemirror som kjører i en nettleser med ekstremt kjapp deploy, helst nobuild.
A sudden awareness of the bones in my body
Each movement
My breath
The length of my steps
In some sense predetermined. In some sense, a a choice I make.
Going with the flow means allowing things in motion to keep moving AND letting impulses alter the direction.
Feedback bør være:
1. Rask - ikke vente lenge
2. Bred - dekke det vi bryr oss om
3. Effektiv - mulig å forstå når vi får den.
Mens jeg leser https://parenteser.mattilsynet.io/flaskehals/, innser jeg at dette stemmer 100 % for profilering / tuning også.
Christian sier det selv, (time ,,,) er smal, mens en god flamegraph er bred nok.
> Det er lett å bare slenge en (time ,,,) rundt koden, og se hva vi får. Denne tilnærmingen gir oss et tall og kan være nyttig for en før og etter-sammenligning. Men det er også alt.
>
> Hvis det er én ting jeg har lært av Goldratt så er det at lokale optimaliseringer er meningsløse om man ikke har noen formening om hvor flaskehalsene i systemet befinner seg.
Enhetstesting for byggebransjen
Jeg tror det som trengs er masse innsats for å lage et "corpus" av automatiserte tester gitt et konsept.
Så trenger man beskrivelser av det konseptet!
Har funnet problemer med Hiccup. Løser Replicant biffen?
Ser sånn ut, i alle fall foreløpig???
TO LEARN IS TO COMPRESS
=======================
To learn is to compress. More knowledge fits now in the same space.
As you compress concepts, your chunks will change. The weight of your concept will stay mostly the same, but the weight of the _reach_ of the concept will increase. One unit of work will produce more value.
Keeping your chunk size small as you learn is essential. If the chunk size grows too large, your learning will slow. What about someone else's chunks? Perhaps you try work at their chunk size, and fail with a bang, making zero progress. Or you may refuse to work at their chunk size, sticking to your own. In that case, their chunk size may not make sense to you.
I cherish teamwork driven by mutual understanding, and a drive to aid.
Let's help each other move forward! Let's keep the goal in mind when we take steps!
That is what I want to do.
Had a nice walk + chat with Ben. Sun is nice. Sincere conversation is nice. 🙏☀️
Har vært på Kodekamp :)
Two nights after Monday's BJJ practice, I feel more sore than yesterday. I'm sore in my /jaw/, I didn't think that was even possible 🤔
I didn't practice yesterday (Tuesday), instead washed some clothes, ate dinner and enjoyed an episode of Band of Brothers.
It's going to be nice to see Sindre again!
Data can reduce coupling between components in your system.
Before: components take arguments, which they then call.
For example to apply a theme to HTML components.
Each component must take a color theme as input, which it uses to produce the correct HTML.
After: theme is a one-step data transformation.
Components return data describing HTML, with markers where data should be interpolated later.
This change lets us skip one argument from all components, meaning we don't have to pass around the theme.
Første BJJ-trening på LENGE.
Det gjør vondt i fingrene. Eller, vondt? De har blitt brukt.
Jeg kjenner det i skuldrene. Jeg kjenner det i ryggen.
Særlig ryggen. Trenger de små stabilitetsmusklene.
First build the whole system, then tweak.
Alan Kay did it in the 80s.
You can now.
Don't get stuck in a local optimum.
What matters is the performance of the system _as a whole_.
Does it solve what it's aimed to solve?
And is it aimed at the right problem?
Tweaking is something different, but tweak AFTER you've made a full system.
---
How does "First build the whole system, then tweak" relate to expand and contract in design thinking?
Frankly, I think it maybe doesn't.
Design thinking is about how you treat unknowns.
"First build the whole system, then tweak" is about treating knowns.
Get the knowns out of the way, so you can focus on the unknowns.
- how are you selling?
- when does a company start needing your product?
- when a company uses your product for success, how does that use look?
These are questions I didn't have good enough answers for.
Clerk is a tool for creating better feedback loops.
What's good feedback?
- feedback latency: 100 ms? 10 minutes? 3 days?
- feedback width: does it cover the whole thing, or just a slice?
- feedback visualization: is it a data dump, or does it show what you want to see?
I DAG STARTER EN NY UKE!