Flagrant

Delightfully Friday Junior: Rose, Thorn, Bud

2026-04-20T05:28:00-05:00

This week’s Delightfully Friday Junior (if you’re catching up on what this is, learn more here) involved a roundtable sharing of Rose, Thorn, Bud. It’s a great activity in reflecting and learning about our teammates and the full, rich lives we each lead.

Everybody shared at least one Rose, Bud, Thorn from their past week.

A Rose is a highlight, success, small win, or something positive that happened.

A Thorn is a challenge you experienced or something you can use more support with.

A Bud is a new idea that has blossomed or something you are looking forward to knowing or understanding more.

This exercise was a great reminder that while we’re here for a job and have work to do, each person on the team contains multitudes of things that are weighing on them and bringing them joy in the day to day.

Developer Roundtable - Clojurescript

2026-04-10T08:00:00-05:00

This developer roundtable, Casey showcased learnings from his experience using ClojureScript. He is a senior UI/UX engineer and worked at Flagrant previously. He created a game with ClosureScript called Counterspell that was inspired by Strands, the New York Times game.

But first, what is ClojureScript? ClojureScript lets developers write code in a style known as functional programming, and then run that code anywhere that JavaScript can (like web browsers). It is built on top of Clojure, which is a programming language and a dialect of Lisp on the Java platform. ClojureScript uses immutable data structures, or more plainly, once you create information you cannot change it. Additionally, from what I have read from blog posts and related content, ClojureScript fixes a lot of pain points that Javascript has like inconsistent type comparisons, truthy/falsy inconsistencies and unintended type conversions to name a few. To read more about this, here is an article that goes more in depth than this surface level explanation.

Now that we got the foundation for what we are talking about out of the way, let’s get into the meaty bits.

Counterspell, the game Casey created to learn ClojureScript, had a main goal to create words on the board from the options of letter tiles. After you create 3 words, a score will show on the screen letting you know, scrabble points style, the amount of points left on the board. So, the goal is to find 3 words with the highest points so that the remaining letter tiles will be the smallest amount possible. He learned a lot about ClojureScript and here are some take-aways.

The Wins

Interactive development: The whole idea with interactive development is you are taking the notion of REPL (Read-eval-print-loop), all the way to its logical conclusion. You have your text editor and the running session connected to each other. Casey showed an example of the editor open and looking at all the state he had stored in one file (atom file). When changes were made on the running local server, you could see the states of variables, updating in real time. So if he were to select three letters in the application running on his local server, you could see those letters show up in this file live. And this is true also in reverse. If he makes changes on the variable states, those changes show up on the application that is running locally. Pretty neat!

Structure editing: lisp code has all the parentheses and nested lists everywhere describing the tree structure of your program.

Clojure immutable data structures: As described above, if you describe a vector somewhere, you can count on that always referring to the same vector. Even if someone else comes along and tries to get another reference to that vector. This solves the errors that can occur if you have aliases to the same data structure and multiple places where you are editing it.

The Frustrations

Mental model error: Conflating seq and vector.

Sequence abstraction (seq) is one of the central organizing ideas to Clojure’s standard library. A seq is a logical list but it is specifically an abstraction. Like a vector or a list or an inherited Javascript type. The core definitions of seqs are: the function first, which gives you the first thing from the list, and rest, which gives you everything else. Sounds simple but the ramifications are super powerful. Important to know, seqs are lazy. Which means they’ll only evaluate members of the seq that you are asking about specifically.

Vectors are ordered, indexed, immutable collections of values. A fundamental data structure in Clojure, kind of like arrays in other languages. But the big difference is the immutability. A property of vectors is that they are associative unlike seqs. You can care about any position on them, just like an array. Associative means that we’re mapping between key and values but Clojure takes it a step further and says, since vectors are mapping keys that are integers, they are also associative.

The issues with the mental model error was thinking that seqs and vectors are interchangeable. This is obviously not true. The abstraction goes one way. Lots of confusion was had when working with vectors of vectors but using seqs.

Big functions: The base of this is more tactical. Mistakes were made due to being in an unfamiliar programming language. In functional programming, specifically Clojure, the functions are smaller than anticipated. In JavaScript it’s easy to write a big messy first draft and then pull out smaller functions from that bigger one. This is a mistake in Clojure. You want to start small and build the big out of the small. One of the big benefits for doing it this way, is you accrete an abstraction layer around your data by writing small functions.

Overall, it seems like from the conversation that ClojureScript is a really nice expansion and allows for some awesome interactive development as long as you keep the underlying organizing ideas of Clojure in mind. Happy coding!

Welcome to Claudeville

2026-04-06T08:43:00-05:00

For the past couple of weeks, I’ve been reluctantly using Claude Code. This is “reluctant” for a host of reasons I don’t want to get into at the moment, because I don’t want to turn this into a diatribe or rant, or a series of rants (no promises). Instead, I just want to talk about what I’m experiencing.

So first of all, why am I using it? I could say a lot about the genie being out of the bottle, or trying to keep up with the times, or whatever else. But the real truth is that I was deep in the doldrums and I was having a hard time thinking of what would make me feel worse. And I had access to an account, so I thought I might as well try it out.

Now here I am, two weeks later, with my meds adjusted, and I’m still using it. And I’m still reluctant, but less so. However, no small part of that lessened reluctance has made the lateral-at-best move to wariness.

And there’s the vigilance. So much vigilance. I’m doing so much checking and re-checking — verifying the code does what it should, and does what it says. Verifying the tests do what they say, and cover what they should. Verifying all this sticks to the plan.

Yes, the plan. That’s one significant reason I started using this and am continuing. And it’s not “plan mode”, but picking up a workflow I saw that really spoke to me. Let’s call it “ADR-driven development”.

Seeing this pattern really made me think this could actually be a thing. Because I didn’t want to use these tools to do small things. And I didn’t want to use them in fully-autonomous ways. Really, even what I’m doing now feels too much like managing and not enough like building, especially for someone who cares about “the craft” as much as I do. But what else do I care about? I care about ADRs. I care about documentation. And I don’t always have the time and energy to do these things when I also fall into the common trap of “working code is what matters”.

So what’s “ADR-driven development”? It’s just a fancy name for using Claude Code to write up an ADR based on what I want to do. How does that compare to “plan mode”? I’m not 100% sure because I don’t use “plan mode”, but I gather the most-significant difference is that the “plan” lives in the session and is maybe saved in a file that could be who-knows-where, whereas an ADR lives and is tracked in the repo, in a directory of more ADRs that get created over time, so you can see a history of decisions and changes. If you can’t tell, I consider an ADR a useful artifact in and of itself, something worth saving and sharing.

No small chunk of time and effort is spent creating that ADR. There’s the initial creation and reading it over, and then there’s the refinement loop of checking things out, suggesting changes, reading over the changes, checking things out, suggesting changes, &c. Sometimes “suggesting changes” takes the form of asking for clarification or fleshing out some points, and sometimes it takes the form of pointing out something in the ADR is just plain wrong, or there are inconsistencies. Sometimes “checking things out” takes the form of a quick jaunt into a console to see how some code works, and sometimes it takes the form of reading documentation, cross-referencing it with forum or blog posts, and going further than just a quick jaunt for the testing. In one case, where I wanted to consume and process webhooks, these two steps together took the form of giving up on documentation and capturing several real responses to feed into the context. This not only finally got past a cluster of mistakes, but it also meant I had more useful documentation to save and share in the form of those sample webhook responses. And don’t worry — it was all staging / test data.

It’s only when I’m satisfied with the ADR that I allow it to be committed, and then the next step is just to request an implementation of the ADR. But that’s only the single very next step. That has its own check-suggest-read refinement loop, which can involve pointing out inconsistencies between the implementation and the ADR (and deciding which one should change), or finding more wrong things like bad assumptions when integrating with external services, or any of a host of problems from violating style guidelines (either personal or configured in the linter) to large structural issues. And for the most part, I’m checking everything over and reading it all myself, but I’m requesting Claude Code do the changes.

I don’t know where the workflow will end up, but this is what I’ve been doing, progressing from an initial tentative dipping my toe in the water to making basically no edits myself. I’ve been going for an immersive experience, trying to feel out what the tool can do. It’s partly an attempt to adapt, partly an attempt to best use whatever energy I have for work after waking up in the morning and remembering that I live in this world.

But it’s still tiring, and frustrating. And takes so much vigilance. Claude Code provides results that are so much better than any of my previous attempts, which were all painful and maddening: just arguing with a chatbot about the obviously-wrong things it’s doing, and having it go back and forth between previous wrong solutions as I attempt to provide more context. But sometimes better is worse? Those obviously-bad results were so easy to dismiss. The problems and mistakes I’ve been seeing here are smaller, subtler, more insidious. I need to be so careful and review so much.

And what’s most tiring and frustrating is seeing what happens when people don’t do this review, or neglect this vigilance. It’s tiring and frustrating to spend my time and energy being careful with 90-95% of this and get worn-out and sloppy for the last 5-10%, and that’s where I miss a problem. And it’s tiring and frustrating to have to spend my time and energy being careful with code someone else has produced using a tool like this, without checking it over themselves.

And it’s tiring and frustrating to be well aware of the long history of complaints about new technologies, going back to the invention of the written word — famously (and ironically? or fittingly?) immortalized in Plato’s Phaedrus. So I know that I sound (and sometimes even feel) like an old man shaking his fist at the clouds when I complain about this, but I also have some significant concerns. Three main ones, in fact:

Not understanding what’s going on with the code you’re producing and should be responsible for. I think it’s great to use higher-level things and appreciate the abstractions — I moved on from C and memory management long ago — but it’s not great if you don’t have an understanding of what’s going on underneath it all, especially when things go wrong or the abstractions start to leak.
People disparaging themselves and their own skills, also connected to anthropomorphizing the tools. Some people will have conversations with the tools, reach an understanding, and attribute that understanding to the tool. They’re essentially rubber-ducking, but since it’s happening with something that talks back and affects a personality, they feel like it’s all external and not something they did themselves.
Depending on more external tools and services to do the work. No internet: can’t work. Payment stops: can’t work. Tokens ran out: can’t work. And this dependence being not on something that’s a commodity or a public good, but instead belonging to a private company with a vested interest in extracting as much value from you as possible.

I acknowledge that I may be a curmudgeon, and that caring about the craft doesn’t necessarily mean one particular thing. You’re not less of a woodworker if you use power tools or machines instead of hand tools, and you’re not less of a programmer if you use a higher-generation programming language instead of assembly (or binary). But this does feel different to me, and as a difference of kind rather than merely of degree. As I said before, I feel like I’ve been delegating and managing, rather than building. Other people might not feel that way, or they may be fine with it. I’m not a big fan. It does not spark joy.

Running Playfully Productive Brainstorms

2026-03-20T04:39:00-05:00

Flagrant has been experimenting with spending our internal time / non-client facing time in building meaningful things. Everything from our new Shop page to our Bookshop are artifacts of the team coming together to create our own work. We want to continue creating but when the team is faced with “Ok what can we build next?,” we’re left scratching our heads looking at looming, blank canvases:

We decided a brainstorming session would be fruitful (or at least act as a springboard) to generate ideas. If you’re anything like me though, having to come up with ideas on the spot in front of a bunch of people is a hard no thank you.

Instead, thoughtful exercises and accessible practices were incorporated to create a mindful brainstorming space for everybody on the team.

Avoid groupthink

In a world that favors extroverts and the outspoken, it’s important to make space for individual thoughts and for the quieter people who do their best work independently. I set up individual workspaces in a shared FigJam so everyone was working concurrently but independently.

Define the problem first

As a group of largely developers and designers, we’re accustomed to solving complex problems and great solutions come out of well-defined problems. Each team member shared a problem(s) they encountered recently at work. It didn’t matter how complicated or simple the problem was, just that they outline their problem statement with the following template:

Get out of your own head

Let’s be real, solving somebody else’s problem is much easier than solving your own. When it came to solutioning, I instructed everyone to choose a problem that wasn’t their own. For people who don’t normally ask for help, this opens up new perspectives from others (including people who don’t work on the same client project).

Timeblock

Spending hours, days, months trying to think of The Next Best Idea™️ tends to lead nowhere and is also, real exhausting. Every moment of this session was timeblocked to ensure people took action rather than sitting around and mulling. It’s a lesson in trusting instinct while also allowing for mistakes.

Quantity over quality

A former design professor of mine expressed, “If I ask for three drafts, I’ll maybe get one good idea in there to talk about. If I ask for twenty, then maybe I’ll get 3–4 good ideas in there and now we’ve got things to work with.” This mindset has stayed with me for years and repetition is shown to be a huge factor in making progress and pushing past limits.

We did Crazy 8’s—a design sprint activity from Google Ventures—as a way to embolden the team to generate distinct ideas and at the same time, stretch themselves beyond initial, safe solutions.

Go analog

While most of this session was online and digital, I encouraged the team to use pen and paper (1) because drawing digitally is Damn Hard™️ but also because (2) most of our work time is on a computer. Going back to the basics can jog the brain in different ways than we’re used to.

Embrace play

You know who always be judging me the hardest? Me.

I emphasized to the team before and during the brainstorming session that nothing they could say was too mundane, too stupid, too *gestures vaguely* whatever. Especially regarding their own thoughts. Self-censorship plagues many of us. Letting loose allows for silliness and play to run rampant and inspire everyone around us to remember to have fun and be creative (including ourselves).

Closing time

If you find this framework to be helpful, you can download our brainstorming template here for your own use.

This brainstorm session reflects much of what we do here at Flagrant too! We do these activities with our clients, during sprints, or simply when we get stuck in the rut. They’re great tools for software problems and we’ve seen these processes help bring value to our clients and to unlearn what’s expected to deliver the unexpected. Want some help running brainstorming sessions? You know where to find us!

Suck it up and make things accessible already

2026-03-19T08:58:00-05:00

Though I’m not currently disabled, I spent several years of my childhood chronically ill without a diagnosis (followed by emergency surgery and a full recovery). I’ve suffered shoulder injuries that kept me away from my pottery studio and prevented me from lifting grocery bags. Once, I twisted an ankle while travelling and relied on wheelchair service at the airport to make it home. I have non-verbal relatives in my extended family. In college, I cared for my grandmother as she lost her mobility alongside cognitive decline. I recently spent 10 days with a family member in the neurology ICU, where we faced the real possibility of life and everyday activity looking very different after discharge. All of these experiences, whether my own or someone else’s, are experiences with disability.

Maybe you’ve had similar experiences but haven’t thought about them through the lens of disability—a term I think we hesitate to apply as often as we could and even when it’s relevant. Thanks to ableism (which, whether we like it or not, many of us have deeply internalized), many folks reserve the term “disability” to describe something extreme or that they perceive as rare, like being unable to walk and needing to rely on a wheelchair to get around. But a recurring knee injury or chronic joint pain may require the same accessibility accommodations, regardless of whether the disability is short-term, long-term, or even just situational.

Disability is not a dirty word, it’s an adjective. And we will all experience it in our lives. People with disabilities make up one of the largest minority groups in the United States, and it is the only marginalized group that anyone can join at any time.

We’ve written about accessibility before (including why accessibility is for everyone, but whether it’s working to help clients understand that or just encountering debates about whether there’s a business case for creating accessible software, misconceptions about the value and relatively low time investment abound.

It still shocks me how often I encounter resistance to investing time and energy in accessibility.

So much of the way I work as a product designer and so many of the specs and standards that stay top of mind come directly from accessibility guidelines:

the minimum size for a touch target (to make something feel “easy” to tap on a touch device)
how far apart touch targets must be (to prevent users from tapping something else unintentionally)
how dark text must be for legibility (to allow people to turn down the brightness on their phone to conserve battery, look at screens in sunny places, or read text from a greater distance than anticipated)
the amount of contrast needed on the outline of a form field (so users realize it’s tappable and interactive)

These kinds of guidelines, for me, aren’t “just for accessibility” with only disabled people in mind. They are guidelines that help keep me accountable and remind me of the long checklist of things I’m responsible for when making a good, stable design with a strong foundation (that hopefully minimizes the need for rework). For everyone. For any user.

Being asked to justify the business case for building an accessible product can feel like being asked why a building should be built to code. Technically you can build a house without following local building code, but you might find that a new washing machine doesn’t fit through the front door, or the weight of a piano causes the floor to sag. And when it comes time to sell, potential buyers will have to contend with the additional expense of bringing something up to code with what could have been built that way from the start. Or you find that by not building to code, your insurance policy will be more expensive.

Accessibility standards make a product usable by anyone, now or in the future. It reduces headaches for Future You, for your designers, for your dev team. What may require 20% more expertise and 10% more time right now will save you a huge time-sink of retro-fitting and refactoring in the future.

Designing and coding to accessibility standards can be:
what makes your product usable on a phone (or a watch, or another yet-to-be-released device you don’t anticipate)
what allows your product to expand to a younger user base with lower dexterity for small touch targets
what makes your product navigable via keyboard by your super users (or by you, if you break your mousing wrist!)
what protects you from a lawsuit that can sink your company

When folks dismiss accessibility as something they don’t need to spend time on or plan for—when they insist that none of their user base will rely on these standards being in place—what they often don’t realize is how expensive and consequential that dismissal is for their team, their business, and their user base. Accessibility standards aren’t simply about accommodating disabled people (who have money to spend! and use your product!).

Natalie MacLees breaks down how ridiculous (and costly) assumptions about accessibility can be: “Blind people don’t rent cameras” assumes that:

blindness always means total blindness
someone’s visions status predicts or limits their choice of hobbies or profession
blind people don’t have friends, family, or colleagues who might want or need assistance renting a camera or performing an online task
blind people don’t have jobs that involve purchasing decisions, including renting professional equipment

Underneath all these assumptions is the biggest one: “that accessibility is about building for a specific group of people you’ve identified in advance.” The thing about digital products and burgeoning businesses? They need to work for as many people as possible. Even people you didn’t know about when you started building.

Accessibility guidelines are standards for a reason. Accessibility is Just Good Design.

—

Some disability and care work resources I love:

Developer Roundtable - Anything counts as a Scotsman Fallacy

2026-03-19T08:19:00-05:00

This time during the Developer Roundtable, we discussed an interesting thought Casey had. The opposite of the No true Scotsman. Anything counts as a Scotsman fallacy

No true Scotsman

The No true Scotsman is a type of logical mistake where someone changes the definition or criteria of a general statement to exclude a specific example that contradicts it. Essentially, it’s a way of moving the goalposts to maintain an argument, even when presented with evidence that contradicts it. The example Casey gave was: someone says, “All Scotsmen wear kilts.” If someone else responds, “I am Scottish and I don’t wear kilts,” the first person might retort, “Well, all true Scotsmen wear kilts.” In this case, the term “true Scotsman” is being used to arbitrarily exclude the counterexample, thus protecting the original, overly broad generalization.

This can be applied to software development as well. Most notably, people who are major proponents of scrum or agile development get accused of this fallacy. Someone might say, “Well, my team tried scrum and it just didn’t work.” Oftentimes you will hear a scrum advocate say something similar to: ‘You didn’t use continuous integration correctly, so you didn’t use scrum right and scrum isn’t the issue here.” The counter example is refuted and excluded as viable evidence.

What if we take this a step further?

To take an interesting twist on this idea, Casey proposed the idea that maybe there is an Anything counts as a Scotsman fallacy, fallacy. Rolls off the tongue, right?

Think of this example: I tried Test Driven Development (TDD) and it just didn’t work for me. Therefore TDD doesn’t work and is trash. Basically, take a concept, idea, framework, tool or whatever you are trying and give it a bad try. Like skimming a blog post and then trying to implement it in your app. Because you couldn’t get the thing to work after taking a few minutes to learn, you conclude that the thing is awful and shouldn’t be used.

And, hey, we have all been here. At least I have and it seemed like most of us on the developer roundtable call felt this same way. We misunderstand a concept, apply it lazily and then throw it in the trash. We might even take it a step further and tell others that the concept is terrible and shouldn’t be used.

An interesting example Max brought up can be seen in recipe reviews. Sometimes you will see a review that is scathing. But when you read the review, it says something like “This fettuccine alfredo recipe tasted awful, I would not recommend…..(further down the review)….I substituted almond milk for the dairy”. Well yea, almond milk would be a terrible substitute in this recipe. Doesn’t mean the recipe itself is awful, the way you implemented the recipe was the problem here.

A possible reason why this might happen in the developer world, stated by Casey, is that when we have a new developer starting out, they often run into problems. The common thing to say is “you aren’t the problem, this [framework/tool] is hard to understand or use”. We label problems early on as the tools fault, not our fault. But over time, we need to scale this mindset back and learn to recognize when it’s our fault and when we are using tools incorrectly. Sometimes we definitely are the problem.

I’m sure we all can think of a time when we are on a time crunch for a feature or wake up feeling low on spoons. You need a tool to accomplish something in your app and search the internet. You find something that looks correct and skim the README or some blog post. You cram it into your app and run into a host of problems that are starting to pile up quickly. You might not have the patience and emotional capacity to make this work or maybe you have a time deadline that is fast approaching. Since this tool didn’t seamlessly work, you label the tool as incompatible or awful to use. You strip it from your app and move onto the next. This is not a tool problem, this is a you problem. The conclusion here should be “I am not able to fully learn how to use this tool” instead of “this tool is too complicated or hard to use”. But we often make this conclusion and don’t think twice about it.

Yossef brought up a good point as we were discussing this. For better or worse, with a career in programming, if you are tired or in a bad space mentally, you often will push through. There are no immediate and salient dangers to doing so. But, in contrast, if you are a wood worker, the dangers of being tired are immediate. You have to stop, you need a break or you will regret and potentially face a physical consequence. As programmers, however, we need to be mentally aware of the consequences that coding in a poor mental state can have. We can run into the Anything counts as a Scotsman fallacy. Thanks for the new term Casey!

Delightfully Friday Junior: Tier List Edition

2026-02-19T05:08:00-06:00

Delightfully Friday Junior comes for us all, and this time it was my turn. (What’s Delightfully Friday Junior? Check this out.)

I thought what we’d do was set up some tier lists for rating things. Rating what? Whatever we wanted! That’s part of the fun of just putting a little bit of structure around an activity — seeing what direction people go once you give them a starting point. And that’s what I really wanted to see.

Sure, I provided not only the tier list template, but also some ideas of things that would be interesting to rate. In the end, though, I think I was the only one who chose something from the list of ideas.

(It was Muppets, by the way.)

(I will be taking no questions.)

But from others, we got to share wonderful things like thoughts on hot breakfast foods (we don’t have time to rank all breakfast foods), or dice used in Dungeons & Dragons (a d4 ranked surprisingly highly, but with an explanation that got me on board). There was an entire run-down of all the stuffies on someone’s living room couch (just the couch — again, we’re operating with limited time here). And I think we all learned a good bit about just how many Barbie movies there were.

And in a moment of delicious meta-ness, we also got a rating of rating systems.

Feeling John Henry

2026-02-17T06:00:00-06:00

This week, for the first time, I decided to try out a coding agent using the Zed editor on a free pro trial. As a seasoned developer I have found patterns that suit my pace and personality so there is often resistance to trying out the latest new tool that might disrupt my workflow.

Of course, AI has already largely replaced much of my searching for answers from documentation, tutorials and Stack Overflow entries. I will also get coding suggestions and copy snippets from chatbots. However, as a software craftsman I feel ambivalent about completely opening up my personal workspace to the powerful yet invasive forces of AI.

When not working at my computer you will often find me outside in my garden. With small scale agriculture you get a visceral experience of both the benefits and cost from using tools. With gardening, there is a clear boundary you cross once you get involved with mechanized devices. While your productivity increases dramatically so do your material costs and dependency on external resources and supply chains. You are also more removed from the long term impact on the soil and ecology that sustains us.

With AI encroaching on my profession as a computer software engineer I now face a similar choice. Here is a task that might take me fifteen minutes of tedious copying and pasting to complete. Even though I know exactly where the files are located and some pretty efficient keystrokes on my trusted primitive editor my fingers and single core brain can only move so fast.

On the other hand, in a few minutes I can compose a prompt for an agent in the Zed editor and if I explain myself clearly and the AI stars align I could end up with success and shave off quite a bit of time.

It occurs to me that for the first time in my career, the specter of obsolescence lurks in my own machine. I am reminded of the story of John Henry, the folklore hero who raced the newly invented steam powered drill to tunnel through a mountain with a chisel and sledge hammer. In the legend our hero competes at the pivot point of a new technology and is still able to keep up with and even win against the machine but only at the cost of collapsing from exhaustion.

In these early days of AI agents I can probably keep up and maybe even perform faster for simple tasks. However, the more I practice and get better at prompting and as the LLM models evolve and become more powerful, it will make less and less sense to physically compose and write my own code. Like John Henry, I will need to choose to adapt or perish.

However, it is worth taking some time to consider some of the larger impacts of these options. Though we are at the precipice of something completely revolutionary and novel, we have many historical precedents to refer to for wisdom and caution.

Take for example, the impact of industrial agriculture. Mechanization, fertilizers and genetic engineering has been credited with transforming human society, ending famine and the drudgery of an agrarian lifestyle.

On the other hand, one could argue that there has been incalculable loss to the ecological health and resiliency of the soils and environment that sustain us. Machines do not have the same relationship with the organisms that protect and sustain human beings. Less hands working the soil and fewer eyes directly observing the impacts means that we are vulnerable to destructive practices on a massive scale.

Today, when we purchase an amazing quantity and variety of food from the supermarket we have little connection with the impact of our choices. We are also disempowered from doing much about it since we are so dependent on the technology that has replaced the centuries of agricultural experience and wisdom now largely lost.

Am I embarking on a similar inevitable process of erosion as I choose to prompt an agent while I am completely detached from the short and long term environmental and cultural impacts? How much are my savings of time and effort subsidized by the reckless financial risks and ambitions of large corporations? How much future employment am I sacrificing to meet immediate deadlines? How much learning and experience am I foregoing, contributing to the atrophy of my craftwork?

While the immediate cost of AI tokens and savings in human work hours are easily tabulated it may take generations to realize the overall balance of AI’s impact on humanity. Will we once again become dependent on a new level of technology we lack the skills and knowledge to maintain and control? How much of our accumulated experience and expertise are we willing to surrender in the name of questionable progress?

I feel humbled by the enormity of the transformation we are presented with; changes we could not have foreseen even five years ago. I can only hope that our culture will find ways to adapt as it has through other major industrial revolutions. With any luck, there will still be a place for the software craftsmen just like the small scale homesteaders that find joy and satisfaction from tending their gardens.

Delightfully Friday Junior: Gingerbread Houses

2025-12-29T03:13:00-06:00

For our final Delightfully Friday Junior (if you haven’t heard of it yet, learn more here) of the year, the team gathered to make gingerbread houses and other digitally baked scenes. As we weren’t limited to the social integrity of the usual marshmallows and graham crackers, we closed out 2025 and wielded our imaginations with a celebration of gingerbread houses, gardens, trains, and a crematorium 🪦😂 Enjoy our silly, festive creations!

Garbage Pile Friends

2025-12-18T07:35:00-06:00

In case you missed it, Flagrant just launched our swag shop! In honor of this, I’m super excited to give you a little BTS of the creation of some of our items and some insight into how this came about.

Quick overview of the problem: Finding a way to show and sell our designs.

We wanted to make a place to sell Flagrant-flavored items for a while now, but could not find a way to do it that was not labor-intensive for the team. One of our previous attempts was through Gumroad, which would handle the listing and money exchange part of the process, but left members of the team needing to find a place to get the item printed (t-shirts, stickers or pins) through a separate vendor, a place to store the items, and handle all of the packing and shipping once an order came through. This was NOT an effective or sustainable way for us to operate our shop. So, thanks to an internal project called #co-shipit (see more about #co-shipit in the footnote) by Max and me, we were able to find a solution that worked for the whole team: Big Cartel!

Big Cartel is a platform that creates a storefront for you to display items and process payments. On the inventory front, Big Cartel integrates with platforms like Printful and CreativeHub. These sites are where you can upload your designs and create items for sale. The items are printed on demand once a customer makes a purchase and is directly shipped to the customer. This takes all the hassle of storage, shipping, and processing away from the team and allows us to focus on other tasks.

The Swag: Why I made what I made

One of the long-time jokes here at Flagrant amongst the designers is that we are like possums guarding our “trashpile” of designs when someone asks to see what we are working on. Because of this common phrase, I thought it would be fun to make some designs to represent this. I started by sketching out some ideas of how I’d like to make the possum, how I wanted the character to look and feel. I also wanted to make sure that the style was repeatable so that I could create a series of related items/designs.

The inspo:

The sketches:

After I had a solid idea of how I wanted it to look, I started making the poses. The poses I made were based on some of the phrases that float around the Flagrant workspace, like partners in sublime, garbage pile kids and unleashing your spark.

I wanted to make all of these phrases into fun, wearable designs that people would like, even if they didn’t know the meaning behind them. So, the following designs were born under the umbrella of “Garbage Pile Friends”, a series of swag designs:

The Stinker (Like “The Thinker”, but with trash)

Partners in Sublime (Possum and Raccoon friends in a famous anime pose, Dragon Ball Z Fusion Dance)

Unleash Your Spark (a junkyard dog making a break for it)

These designs, as well as a few designs from our vault, have been added to the Flagrant shop! We are so excited to finally see them out in the world <3

See some sneak peeks of some of the items!

Our model Jim is showing off the “Unleash Your Spark” t-shirt in “Grape”.

Footnote: Co-ship it is something we do on a biweekly basis. Two individuals pair together in order to ship ‘a thing’. They present the thing during Friday’s clap & cringe, and all of us will get to marvel at the wonder that is teamwork.