07.03.2026 22:37
👍 6703
🔁 2514
💬 51
📌 157
Lots of chatter about how software development was never about the code, it was about delivering solutions. But that misses the point. Good software design is about delivering *well-designed* solutions that can evolve and adapt. That takes time, not velocity.
Ahh... That's right. I had implemented a hindley-milner type system or a really basic one. I was in the process of implementing generics so now I'm coming back to that mess.
Prototypes that delivery the most value, for me, are ones that can be tossed.
You aren't shipping that prototype code to production are you?
Just thinking was about vibe coding and increasingly siloed development, coding agents reinventing more and more wheels...
What a can of worms that opened.... 😅😭
So yeah, the feature I'm working on is the first editable Date type we've ran in to. All the other types (strings, booleans) serialize/deserialize as JSON fine so weaknesses in our typescript weren't obvious. Dates in JSON required some more lifting so it became obvious our types were just wrong.
Blueprint/layout of a house
I love this image. It appears to be a reasonable house with a reasonable layout but the longer you look at it the more you realize how poorly it's designed.
This house would be terrible to live in. Building software isn't hard. It's designing it to be livable and maintainable, that's the hard part.
This sounds obvious but it's important to reiterate as you can only trust well typed code you've written and tested.
Legitimate sources that should make you question that trust:
- Explicit or inferred "any" type
- Abusing "unknown" types
- Untested code (types can't replace tests)
- Javascript
You also need to have a realistic understanding of what typescript is. Type safety is literally only at compile time.
The debugger statement is javascript is great. Breakpoints can shift around during transpiling but the debugger statement is resilient.
Having ADHD and coming back to code you haven't touched in months. So many unstaged changes, project doesn't build...
So in related news my attention has drifted back to programming language design and implementation. 😅
I know some folks criticize Typescript type system complexity but honestly it's kind of amazing considering that it's designed to gradually type a dynamically typed language.
Yes, a lot of it's patterns make no sense sense for other languages but it's really brilliant for a language like javascript
I wrote a bit more on the circuit-bent PS2 (with more photos) and how recontextualizing gameplay becomes part of the creative process:
I just found out that I've hit merge instead of approve more than once in someone else's PR in the last week... 😵💫
1. That's so embarrassing. I'm mortified.
2. Gitlab's UI is hot garbage
A group of contractors asked to join already. That will almost double our numbers already.
It's prep work for a 3 amigos session before I start working on the story. A lot of the time the story is too big or doesn't have enough information.
How the story will be tested or accepted is unclear. If those are unclear how can you possibly start working on something?
The first thing that I like to do after picking up a story is reviewing it then asking some questions
- Does this still need to be done?
- How will I test this?
- How will the stakeholder accept this?
These usually lead to
- Do I have all the information? Is it accurate?
- Is it too big?
One of the worse things you can do when picking up a new story is start writing code.
In my experience it's rare that a story has enough information or that information is accurate. Even a story refined the day before could be out of date. I've seen that happen.
I've been trying to get a developer community of practice going and just got the first meeting scheduled. 🤩
Some how Google's search results continuously get worse. A lot of results aren't related to my query at all. Kill search engines so they can sell you language models?
Claude is down so developers: this is a "take your brain to work" day.
compiler people love to complain that users only care about syntax... but syntax is the primary affordance that users use to interact with your tool! of course it's massively important what that syntax is!
This has really helped me stay focused and making actual progress on building something useful.
My projects often have a lot of features I want to implement. I've started defining 3 milestones to throw stories in to:
1. MVP - Bare minimum and should be done first
2. Refined - Easy to medium lifts that support the MVP version
3. Polished - Medium to hard lifts to enhance the refined version
One thing I've learned from technical coaching is the gap between desire and effort can be (and often is) vast. Lots of folks wanting to improve...
Prototypes that delivery the most value, for me, are ones that can be tossed.
You aren't shipping that prototype code to production are you?
It's great when it works but I'm using watchexec in there, running the server and frontend in parallel (for hot reloading). If something really fails to build it's not always obvious until you go look at the running justfiles output.
I think the biggest pain points I have with this setup is the large amount of orchestration I have defined in justfiles. On save the types are recompiled, then the frontend (which pulls in the compiled and transpiled types), then the server is built (embedding the built frontend files).