Every time I write, refactor, or merge code, I expect something to break.

I don’t stare at the screen when something eventually goes wrong, thinking, “I’m a terrible developer.”

Instead, I think, “Interesting. What did I miss?” or “Which part didn’t work exactly?”

What do I do when I get an error?

Sometimes the mistakes are very simple, like overlooked typos or faulty conditions.

Annoying, but generally easy to fix.

Sometimes they are complicated. Maybe not even reproducible and occasionally occurring.

There can be thousands of ways to cause an error.

The important thing is, my brain doesn’t immediately jump to “I’m a terrible engineer” when something breaks.

I take a breath and do what developers do:

• Look at the error/logs
• Compare the recent changes
• Retracing steps
• Form a hypothesis
• Test the hypothesis
• Repeat till it works
• If all else fails, ask for help

This process has not yet failed me. The profession is built on this.

We anticipate problems, which is exactly why debugging exists.

I’ve noticed something interesting: I often don’t apply the same logic to my own life that I use in coding. When I fail to accomplish something or feel like I’m not performing well, I tend to engage in self-blame. I often assume it’s my own shortcomings or lack of motivation, rather than taking the time to analyze the situation and understand what went wrong.

Somewhere between my coding environment and my everyday life, I seem to have forgotten the methodical approach I rely on to solve problems. What happened to that structured plan I use to address challenges?

Well… when the code breaks, I don’t feel like I am broken. The problem exists outside of me. It is something I can observe, understand, and work on. But when something goes wrong in my own life, that distance disappears.

I realized I saw difficult moments as evidence that something was wrong on my part. A missed goal felt like proof that I wasn’t disciplined enough.

I was skipping the part where I investigate. I was skipping the questions that help me understand the root cause.

“What was the main issue?”

“What can I try differently next time?”

The same curiosity that helps me solve problems every day tends to disappear when the problem is my own.

Maybe that’s because our lives are much harder to debug than our code. There is no clear error message indicating where and what went wrong. Emotions, memories, fears, and expectations are all intertwined in the situation. However, I realized that the same process may still be applicable.

Here are my takeaways:

• I will try not to judge myself before understanding the problem.
• I will remind myself that, as a human being, it is okay to make mistakes.
• I am not gonna assume that the only culprit is me.
• I am not gonna treat every mistake as a reflection of who I am.

Software engineering has taught me that problems are not failures. They are invitations to investigate.

The next time something in my life isn’t working, I want to stop asking:

“What’s wrong with me?”

And start asking the question I have asked countless times while debugging code:

“Where should I start looking?”

Software Engineering Taught Me a Better Way to Fail was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with threads always feels hazardous to me.

Non-determinism limits how much we can exercise with simple tests. Stress tests can shake out some bugs, but they’re slow and potentially flaky. I don’t like flaky tests.

So I have a few concurrency patterns that I trust, and I use ’em a lot. AtomicReference is one of them. It’s got a lot of concurrency power and a easy-enough API. I can make sense of programs that use AtomicReference.

The drawback of AtomicReference is that I usually need a while loop to update it. The atomic compareAndSet() function returns false if my thread loses a race and must retry. After writing a whole bunch of these tricky loops yesterday, I factored out a helper testAndSet() function in order to split difficult business logic from difficult concurrency code.

In one situation, my code sets a state variable to Canceled, but only if the current state is cancelable. It must also tell the task it has been canceled.

private val state = AtomicReference<State>(State.Idle)

override fun cancel() {
  while (true) {
    val previous = state.get()
    if (previous is State.Running || previous == State.Idle) {
      if (!state.compareAndSet(previous, State.Canceled)) {
        continue // Lost a race.
      }
      (previous as? State.Running)
        ?.callback
        ?.onFailure(this, IOException("canceled"))
    }
    return
  }
}

That loop really complicates this code! And it’s an ugly loop, with a return break out at the bottom.

Here’s the cleaned up version that uses testAndSet():

override fun cancel() {
  val previous = state.testAndSet(
    condition = { it is State.Running || it == State.Idle },
    newValue = State.Canceled,
  )
  (previous as? State.Running)
    ?.callback
    ?.onFailure(this, IOException("canceled"))
}

Getting the signature for this was difficult! Once I realized that the function should return the previous value (and not a Boolean), everything snapped into place.

The testAndSet() code is a tad bit fancy ’cause I’m using tailrec instead of a conventional loop.

/**
 * Updates this reference to [newValue] if the previous value matches
 * [condition].
 *
 * It is possible that a [condition] is invoked multiple times in a
 * single call to this function. This will occur if this state object
 * is updated between fetching previous value and replacing it.
 *
 * Returns the previous value. This will always be the replaced value
 * if the value was updated.
 */
internal tailrec fun <T> AtomicReference<T>.testAndSet(
  newValue: T,
  condition: (T) -> Boolean,
): T {
  val previous = get()
  if (!condition(previous)) return previous
  if (compareAndSet(previous, newValue)) return previous
  return testAndSet(newValue, condition) // Lost a race, retry.
}

I’m particularly proud of how this small function successfully separates business logic and concurrency logic.

Programming. It’s fun.

Most Core Web Vitals audits follow the same checklist. Compress the hero image. Preload the LCP element. Fix the ad slot that shifts layout. Trim the JavaScript bundle. All of that matters, and none of it touches the one element that loads on literally every page of your store: the mega menu.

That’s the part that gets skipped, and it’s also the part with the highest compounding cost. A slow hero image only hurts the homepage. A bloated mega menu hurts every product page, every category page, every blog post, every checkout step where it’s still rendered. If your navigation is heavy, you’re not paying that cost once. You’re paying it on every single pageview.

Nobody thinks of navigation as a performance risk because it doesn’t feel like “content.” It’s not a banner, it’s not a slider, it’s not a video embed. It’s just the menu. It’s been there since the site launched, nobody touches it, and so nobody audits it.

But look at what a typical mega menu actually contains: a full category tree, sometimes with product thumbnails, static blocks, promotional banners, icons for every top-level item, and JavaScript to handle hover states, flyouts, and mobile toggles. On a Magento 2 store with fifteen or twenty top-level categories and subcategories nested three levels deep, that’s a lot of DOM.

And because it renders on every page, whatever weight it carries gets added to every single Core Web Vitals measurement Google takes for your site. A homepage with a heavy hero image is one problem. A site-wide navigation element with bloated markup is a problem multiplied by every URL Google crawls.

Google’s official Core Web Vitals guidelines set three thresholds you need to hit for at least 75% of real user visits: Largest Contentful Paint under 2.5 seconds, Cumulative Layout Shift under 0.1, and Interaction to Next Paint under 200 milliseconds. Here’s where a mega menu tends to fail each one.

This is the most common one, and it’s almost always self-inflicted. Flyout panels that push page content down when they open. Menu icons or thumbnails loading without reserved width and height, so the browser doesn’t know how much space to leave. Custom fonts for menu labels loading late and swapping in, which reflows every menu item at once. Any of these can quietly tank your CLS score, and because the menu is present on every page, the shift happens on every page too.

The mega menu itself is rarely the LCP element, but it can delay it anyway. If the menu’s HTML and CSS block rendering, or if its JavaScript has to execute before the browser can finish parsing the page, your actual LCP element (usually a product image or hero banner) ends up waiting in line behind navigation code that the user doesn’t even need yet.

This is the one most stores never think to check, and it’s also becoming the hardest metric to pass. Recent field data puts INP as the most commonly failed Core Web Vital across the web, largely because fixing it requires rethinking JavaScript architecture rather than just compressing an image. A mega menu with dozens of hover and click listeners attached to a deeply nested DOM tree is exactly the kind of thing that produces laggy taps on mobile, especially on mid-range phones where most of your real traffic actually happens.

You don’t need anything exotic. Open Chrome DevTools, go to the Performance tab, and record a page load with the mega menu open. Look at how much of the layout thrashing and paint time is attributable to the nav versus everything else on the page.

Then run PageSpeed Insights on a handful of representative pages, not just the homepage. Look at the “Avoid large layout shifts” and “Reduce JavaScript execution time” flags specifically, and check whether the elements called out belong to the menu or to page content.

Finally, check your DOM node count. If a huge share of it comes from the navigation markup rather than the actual product or content on the page, that’s your signal. A menu that renders 40 categories with icons and thumbnails can easily add hundreds of nodes to every page on your site before a single product shows up.

Render the menu server-side, not via late JavaScript injection. If the menu HTML has to be built client-side after the page loads, you’re adding delay and shift risk to every page. Server-rendered markup, filled in before the browser starts painting, avoids both problems.

Reserve space for flyout panels. Give dropdown and mega panels fixed dimensions in CSS so they don’t push content when they open. This alone eliminates a large share of menu-related CLS.

Lazy-load anything below the immediate visual priority. Category thumbnails inside a mega menu don’t need to load with the same urgency as your hero image. Defer them.

Reduce DOM depth. Flatten unnecessary nested wrappers around menu items. Every extra div and list layer adds parse and layout cost that repeats on every page.

Debounce hover and click handlers. On a menu with many nested interactions, unthrottled event listeners are a common source of slow INP on mobile.

If you’re running Magento 2 and evaluating mega menu extensions, this is the part of the spec sheet that usually gets ignored in favor of “how many layout styles does it offer.”

The performance-relevant questions matter more:

• Does it render server-side or does it depend on heavy client-side JavaScript?
• Does it reserve space for images and flyouts by default, or does that fall on you to configure?
• Is it built to work with full-page caching like Varnish, so the menu doesn’t become the one uncached element slowing every request?

MageDelight’s Mega Menu extension for Magento 2 is one example built with these constraints in mind. It’s Varnish-cache compatible out of the box, supports a drill-down style specifically for stores with deep category hierarchies (which keeps the DOM lighter than rendering every subcategory at once), and ships Hyvä-ready, which matters if you’re already prioritizing frontend performance on a modern Magento theme.

None of that replaces a proper audit of your specific implementation, but it’s a reasonable baseline to start from instead of retrofitting performance onto a menu that was never built with it in mind.

Core Web Vitals work usually starts and ends with images and third-party scripts, because those are the obvious, visible culprits. The mega menu doesn’t get the same attention because it feels static and permanent. But static doesn’t mean free. It renders on every page, it often carries more DOM weight than people realize, and on mobile it’s frequently the source of the laggy taps that show up in INP data without anyone tracing them back to navigation.

If you haven’t checked your mega menu’s contribution to CLS, LCP, and INP specifically, that’s worth doing before your next round of image compression. It’s the one element on your site that never takes a day off.

Here are answers to a few common questions about mega menus and Core Web Vitals.

Every page it renders on, which for most stores means the whole site. That’s what makes it different from a homepage banner: the performance cost compounds across every URL Google measures.

Flyout panels and dropdowns that don’t have reserved dimensions, so they push page content when they open. Fixed-size CSS containers solve most of this.

Yes. If its markup or JavaScript blocks rendering, it can delay the actual LCP element (usually a hero image or product photo) even without being the LCP element itself.

Generally yes, since it comes down to JavaScript execution and event handling rather than image compression or CSS dimensions. Debouncing hover and click listeners and reducing DOM depth are the most direct fixes.

Not necessarily. Start by auditing your current setup with DevTools and PageSpeed Insights. If the extension itself renders client-side, doesn’t reserve space for flyouts, or isn’t cache-compatible, that’s when switching becomes worth considering.

Source: developers.google.com/search/docs/appearance/core-web-vitals — Google Search Central, Core Web Vitals thresholds

Core Web Vitals and Mega Menus: The Navigation Element Nobody Optimizes was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our previous article, The Transactional Outbox, we built a rock-solid, Postgres-backed staging area. We guaranteed that high-throughput analytical data from BigQuery safely reaches Google Pub/Sub without a single dropped event.

But what about our downstream microservices?

Network flickers… consumer crashes… transient ACK timeouts… What happens next?

Imagine you spin up a GKE worker or a Cloud Run service that does the following:

• Listen to a Pub/Sub subscription
• Pull a message
• Execute the business logic (e.g., update database state, hit a payment gateway)
• Acknowledge the broker (broker.Acknowledge())

If the network blips after your business logic completes but before the delivery confirmation reaches Google Pub/Sub, the broker will redeliver that exact same message to another pod in your GKE cluster. Your database gets hit again—and this time, it's a duplicate.

If forgetting to process a message means you forgot to charge a client $50k, processing it twice means you just double-billed them. Try explaining to your compliance team that it wasn’t corporate fraud, it was just a “highly available network retry”.

Instead of blindly trusting the network, we make the database the ultimate arbiter of truth. We introduce a simple inbox table with a unique constraint on the message ID.

Instead of a fragile, multi-step process, we execute a single, atomic database transaction:

1. The Gatekeeper (Deduplication): The worker pulls a payload from the broker and attempts to insert the unique message_id into the Postgres inbox table.
2. The Execution (Business Logic): If the insert succeeds, it means this is a brand new message. We execute the business logic in the same transaction, commit, and then tell the broker that the message was successfully processed. If the insert fails (because the ID already exists), we skip the business logic entirely and simply notify the broker we are done to prevent further retries.

By pushing the deduplication logic down to Postgres, we eliminate race conditions across our entire GKE cluster. We wrap the deduplication and the business state changes in a single transaction.

// 1. Begin a single atomic database transaction
tx, err := db.Begin()
if err != nil {
    return err
}
// ALWAYS defer a rollback to prevent connection leaks if the function returns early.
// If tx.Commit() succeeds later, this becomes a safe no-op.
defer tx.Rollback() 

// 2. Attempt to insert the message ID. 
res, err := tx.Exec(`
    INSERT INTO transactional_inbox (message_id, created_at)
    VALUES ($1, NOW())
    ON CONFLICT (message_id) DO NOTHING;
`, msg.ID) // Don't forget to pass the actual msg.ID variable here!

// 3. CHECK THE ERROR before touching `res`
if err != nil {
    return err 
}

rowsAffected, err := res.RowsAffected()
if err != nil {
    return err // Handle potential driver errors
}

// 4. If rowsAffected is 0, another pod already processed this.
if rowsAffected == 0 {
    // We can explicitly rollback early, or let the defer handle it.
    // We still acknowledge the broker to stop redeliveries.
    broker.Acknowledge(msg.ID) 
    return nil
}

// 5. Execute your core business logic within the SAME transaction
// err = executeBusinessLogic(tx)
// if err != nil {
//     return err // The defer will safely roll this back
// }

// 6. Commit the transaction and safely acknowledge the broker
if err := tx.Commit(); err != nil {
    return err
}

broker.Acknowledge(msg.ID)
return nil

I often hear developers argue: “Why add database overhead? Just use an in-memory cache like Redis for deduplication!”

Here is the reality:

Caches get evicted; ledgers are forever.

If your Redis cluster restarts, or a key expires too early, your line of defense vanishes. Idempotency isn’t just a fancy backend buzzword — it is the firewall protecting your revenue.

Imagine your service processes finances. When the monthly financial reconciliation report runs, your CFO does not care about transient network partitions or broker availability limits. They only care that the ledger balances. By anchoring your deduplication to the exact same ACID-compliant database that holds your financial state, you guarantee that a message is only ever applied once and the client is billed correctly.

The Redelivery Trap: Building a Safe Transactional Inbox for Google Pub/Sub was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dear Readers,

I still remember my first week as an intern — sitting at a desk that wasn’t quite mine yet, unsure whether to ask questions or just quietly figure things out.

Ugly Truth — Nobody hands you a manual for how to be liked, trusted, or remembered in those first few months.

Looking back, the interns who stood out weren’t the loudest or the most brilliant; they were the ones who understood something subtle: that trust is built in small, unglamorous moments, long before anyone hands you the big project. This is what I wish someone had told me back then.

In my pursuit to help and share my experience, I present 5 ways, unglamorous but impactful little ways, to win over your internship boss.

Arrive on time, ideally before your boss does, and don’t be the first one out the door either. This isn’t about clocking hours; it’s about signaling that you take the role seriously before you’ve had the chance to prove it any other way.

Example: An intern who’s at their desk five minutes early, every day, without being told to, quietly tells the team something no resume line can: I’m reliable. Compare that to an intern who’s brilliant but always ten minutes late; the talent gets remembered, but so does the lateness.

Takeaway: Consistency is a form of communication. Before your boss knows what you’re capable of, they’ll notice whether you’re dependable.

How you present yourself shapes how seriously people take you, often before you’ve said a word. This isn’t about expensive clothes — it’s about reading the room and matching it.

Example: Walking into a client-facing meeting in the same hoodie you wore to a casual team lunch sends a mismatched signal, even if your work is excellent. Dressing one notch sharper than the room, rather than blending in with it, tends to leave a better impression.

Takeaway: Your appearance is often the first data point people use to judge your judgment. Make sure it says what you want it to.

Check your ego at the door. Ask questions without fear of looking inexperienced — because you are inexperienced, and pretending otherwise is far more obvious to your boss than you think.

Example: An intern who says, “I’m not sure I understand this feedback; can you show me an example?” builds more trust than one who nods along and delivers the same mistake twice. Bosses remember who took correction well far more than who never needed it.

Takeaway: How you respond to feedback is often a better predictor of your future than the mistake that prompted it.

Don’t wait for tasks to land on your desk. Talk to your teammates, understand what they’re juggling, and when you have bandwidth, ask if you can help.

Example: Instead of refreshing your inbox while waiting for the next assignment, ask a colleague, “I noticed you’re behind on the report — want me to take a first pass at the data cleanup?” That one question can turn you from “the intern” into “someone we can actually rely on.”

Takeaway: Initiative is remembered longer than any single task. It shows you see the team’s problems as your own.

Double-check your work before it leaves your hands. A typo in a slide, a wrong number in a report, a sloppy sentence in an email — these feel minor in the moment, but they quietly shape how your judgment is evaluated.

Example: Sending a client email with the wrong date might get fixed in five seconds, but it also plants a small doubt: what else did they not check? One caught error, on the other hand, builds quiet confidence that your work doesn’t need a safety net.

Takeaway: Precision is a habit, not a talent. Bosses trust people whose work they don’t have to re-check.

None of these five habits are complicated. What makes them hard is that they ask for consistency, not a single grand gesture. An internship rarely rewards the one big moment you were waiting to shine in—it rewards the accumulation of small, steady choices that quietly tell your boss: this person can be trusted with more.

A writer is nothing without a reader. If this article helped you, share it with a friend preparing for internships or entering corporate for the first time. Nothing would make me happier :)

If you enjoyed this article, here are a few others you might like —

• You Don't Suck at Coding. You're Just Meeting a Real Codebase.
• How Senior Engineers Actually Debug (It's Not What You Think)

5 Ways To Win Over Your Internship Boss was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

♦“Flow is an antidote to transactional reality.” – Dave Evans, on Hidden Brain with Shankar Vedantam 

(Note: This post qualifies as a “long read,” so take your time.)

I call myself a writer, but in practice, my medium is the simple state of flow.

Flow focuses on task, not outcome. Flow draws me into a sensory experience, a somatic experience that links mind and body and spirit seemingly effortlessly—how? In flow, I am wide open to the world around me, as if “I” were not bound by my edges, but a drop in an ocean.

Last week, I was mainlining episodes of Hidden Brain, the podcast by Shankar Vendantum that focuses on social science, psychology and communication. Recent episodes have been dovetailing with my interest in spiritual care. (I’m returning to school in September to start an MA in Theology, with a focus on Spiritual Care and Psychotherapy.) I’ve been jotting down notes, transcribing, and reflecting on the skills developed during thirty years, or more, of practicing the craft of writing, specifically creative writing, writing in pursuit of beauty, writing to illuminate some meaning that’s just out of reach, writing to sink into mystery.

“Flow is the experience of full and deep engagement, where time stands still.” – Dave Evans, again

From practice, I know—a simple flow state is ever-available, it is always here to step into, just waiting for me to arrive. Like a river, the flow runs alongside the distracted, anxious, needy experiences that riddle my life (aka being human!), and this river is here for me to swim in, drink from, dip my toe into, stare at, always available, so long as I am available, too.

I am not talking about heightened experiences of flow, about the “apex” flow experience. I am talking about simple flow. (Thanks for naming that distinction, Dave Evans.)

♦“Flow can occur when you’re operating in the flow channel. The flow channel [aka river?] is a place of experience where the task you are currently involved in and your skills to perform that task are in approximate balance. You’re neither over-talented, so you’re bored, nor under-talented, so you’re anxious and nervous you might fail. You’re right at the edge of your capability, which means this task is demanding your full attention.” – Dave Evans (and, here, he cited the work of Mihaly Csikszenmihalyi; see below)

I have been trying to find a name for a skill that seems to come easily, for me. I’ve called it, at times, “creating a welcoming space,” and it’s a skill that I’ve applied in different areas of my life, from running a workshop, to coaching soccer, to reading to kids, to hosting a party. Sometimes this skill gets called “leadership,” but that’s not quite accurate. It’s a directional skill that is also about ceding control. Essentially, I have become skilled, through practice, at ushering not just myself, but others, too, into simple flow moments. In these moments, we are in a flow channel—my river, their rivers, our river—and our collective capacity meets the collective task, so we neither feel anxious that we won’t be able to do the thing and also are engaged and present.

Basically, it’s directing attention toward a particular task that brings us in concert: into the same space, the same moment, so that we are part of a shared experience, which may be delightful, reflective, comforting, challenging, fun, but most importantly, is as spacious and as focused as possible.

“Each person allocates his or her limited attention either by focusing it intentionally like a beam of energy, or by diffusing it in desultory, random movements. The shape and content of life depend on how attention has been used.”  – from Flow, by Mihaly Csikszenmihalyi

In practice, “directing attention toward a particular task that brings us in concert” (I need a better phrase for this) requires a certain amount of design, while leaving space for the unknown. Elements that can be considered in advance include: the removal of barriers or friction, an understanding of constraints, and a clear articulation of the goal and the tasks that give structure to the process. That sounds super-vague, and maybe I should be inserting an example here, but the details and context really make a difference in appropriate design; I tend to boil my design down to the simplest and clearest options for communication purposes, with the fewest foreseeable barriers to participation. The limitations and practicality of my design become clarifying only when the experience is rolling. I can see what’s working, and what’s not. I can make changes as needed—though preferably not in a reactionary way; I have to be comfortable with discomfort—my own and others’. Afterward, I may suffer from doubt, need to debrief, and seek to learn from the experience and tweak my design; but in the moment, and this is pretty much no matter how the task is unrolling, I experience a spaciousness and calm that feels freeing.

I am fully inhabiting my self and I am not bound by my self.

I think others feel it too, at least some of the time. And I think that’s all that’s happening—I am in the flow, and others are there with me too.

I’ve begun reading “Flow: The Psychology of Optimal Experience,” by Mihaly Csikszentmihalyi, and I’m reflecting on the concepts of “differentiation” and “integration,” which on first glance appear oppositional. How can I be both unique and connected at once? (It’s a big Life question for me—how to be an artist, which requires ridiculous amounts of time and energy focused on the particularities of a craft, while also being an attentive and connected parent, partner, friend, daughter, sister, etc.).

To be confident within my expression of self while feeling connected across barriers and boundaries—in communion with other people, ideas, art, nature. That’s flow.

Being myself fully and being fully myself with others—this is kind of the ultimate joy in life, isn’t it?

♦“This simple truth—that the control of consciousness determines the quality of life—has been known for a long time; in fact, for as long as human records exist.” – from Flow, by Mihaly Csikszenmihalyi

You don’t have to make art to be in a flow state. What’s required is your attention. Attention is always possible, but not always available. Practice helps. Mindfulness is a starting point, meditation is good practice, but so is holding an infant and pairing your breath with theirs, so is sitting with a child who is sounding out letters on the page, so is getting up early to move your body, so is dancing, singing, walking with a friend and listening closely and learning to ask good questions, or watching the birds in your backyard till you feel like you know each one. The more you practice steering your attention toward what matters to you, the easier it becomes to inhabit liminality, to step from here to there, into the flow.

It’s so wonderful, it’s a wonderful state to inhabit, but there are so many distractions, our attention is constantly being pulled, and we only have so much to give.

How much control do we have over where our attention goes? 

“With consciousness, we can deliberately weigh what the senses tell us, and respond accordingly. … Power returns to the person when rewards are no longer relegated to outside forces…. The most important step in emancipating oneself from social controls is the ability to find rewards in the events of each moment. ” – from Flow, by Mihaly Csikszenmihalyi

Where are your inner resources? I used to say this to my kids when they were small, and bored, needy, fighting, rolling on the floor. How I wanted them to have inner resources to pull from—imagination, creativity, curiosity, resilience, playfulness of spirit. (And I think they did, and they do!) How I want that for everyone, actually, myself included. And it’s not always possible, and that’s hard sometimes. There are times when external events knock me to my knees, and my attention fades, my “psychic energy” is poured into attempting to solve the insoluble, I become confused by ugly emotions, by grief and loss and self-doubt and pain.

And then … I need reminders, I need well-worn paths that lead down to the river, or even just get me close enough to hear the water rushing past, to trust that it’s still there. I need to give myself over. Maybe it’s a kind word from a wise friend at the right moment. Often I find entry into the simple flow most easily through my body—breathing; walking; stretching; sweating at the gym. Get me out of my bicycle, and suddenly I am more alive, more open to what’s flowing.

My discipline is writing. My practice is flow.

xo, Carrie

The last two Blog postings I have been listing some contaminated wellfields in Waterloo Region as well as some of the dirty polluters who did the deeds as well as the toxic chemicals that they either intentionally or gratuitously deposited into the soils and into our publicly owned aquifers. Today I'm filling in some missed data as well as giving my overall impressions as indicated in the title above. 

Firstly B.F.Goodrich (Epton) and Kaufman Rubber should be on the known polluter's list versus merely suspected as I posted last Friday.  Greb Shoe on Hayward Ave. (Kit.) also needs to be listed here. Regarding contaminated wellfields we also have additions as I've been rereading somewhat. The Lancaster Wellfield located near Lancaster and Guelph St. has been disconnected for many years. The source of the problem was the former Panill Veneer Co. near Louisa and St. Leger St. in Kitchener. The real culprit however was a well known local illuminary who owned the original grossly contaminated property known as the Breithaupt Tannery.

Various landfills causing off-site contamination include the Caroline St. location of a former landfill as well as the Erb St. Landfill which is located far too close to the Erb St. Wellfield. Despite cute drawings pretending that the Erb. St wells do NOT pull contaminated water from the known contaminant plume below and off-site of the landfill; that seems highly improbable. Of course the Ottawa St. Landfill has enhanced the Greenbrook Wellfield as most likely has the larger landfills in Cambridge. In Elmira we have the Bolender Landfill leaking into the Canagagigue Creek with Uniroyal stuff, the First St. Landfill leaking more into the "Gig" a little further downstream and the M1 and M2 Landfills. The second is on the Uniroyal/Lanxess property and prior to 1992 helped enrich Elmira's drinking water groundwater. Varnicolor Chemical in Elmira also deposited toxics at various Kitchener, Waterloo and Woolwich Landfills.

Back to "problematic " we have the Waterloo North Wellfield roughly near the Laurel Ck. Conservation Area with one " disconnected "well which is then described as a "flowing well". This could mean that it is a Purge or Interceptor well being used to catch the front of a sub surface contaminant plume and pump it to waste such as into a ditch or surface water body. The very contaminated William St. Wellfield (TCE) has one purge well pumping as well as one or two others removed from service. The Erb St. Wellfield has well 6A described as "problematic" and not pumping as well as W6B being on "standby". Gee all these pumping wells with provincial PTTW (Permits To Take Water) that either aren't pumping at all or are vastly under pumping what the province has permitted them. You'd almost think that we had excess water available here. The Foxborough Green Wellfield has one well "disconnected" and the New Dundee Wellfield has one well "abandoned".  All the Pompeii & Forwell Wells have been "disconnected" for decades and the Woolner river wells just downstream have been under pumping and or closed off and on. The Strasburg Wellfield has one well that is "disconnected". Likely well E7 at the south end of Elmira will continue as a Purge well in order to protect the never been used for production well yet E10 further south at Scotch Line Rd. 

It isn't just the provincial and regional refusal and failure to stop gross groundwater pollution from 1955 until 2000 that upsets me. It's the blatant lying and denial since to seriously clean up at least the worst of the contamination affecting groundwater, wildlife and human life. Nothing but excuses, drivel and puffery bragging about how technically advanced they are while poisoning everybody. For years I thought that it was misplaced loyalty to both important business people and pro business ideology but now I think that it is worse. It is a long held pie in the sky belief that Lake Erie water will allow permanent growth and expansion in order to keep the money flowing to our industrial and business class also forever. We are on a horrific death spiral and we are being led by greedy idiots.

Fast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.

Rust 13.9k 1 issue needs help Updated Jul 14

An open source design system that's fully customizable and agent ready

TypeScript 8.7k Updated Jul 13

Simple positioning for Active Record models.

Ruby 416 Updated Jun 29

Deploy web apps anywhere.

Ruby 14.4k Updated Jul 1

The React documentation website

JavaScript 11.8k Updated Jul 13

The modern toolkit for building drag and drop interfaces

TypeScript 17.4k Updated Jul 13

An implementation of the OmniAI interface for Google.

Ruby 5 Updated Jul 13

OmniAI standardizes the APIs for multiple AI providers like OpenAI's Chat GPT, Mistral's LeChat, Claude's Anthropic, Google's Gemini and DeepSeek's…

Ruby 254 Updated Jul 13

The Greater Kitchener Waterloo Chamber of Commerce (GKWCC) provides strong, continued service to over 1500 members in one of Canada’s marquee pioneering and entrepreneurial business communities. For the past 140 years, dating back to the Chamber’s founding as the Berlin Board of Trade, we have expanded into one of the largest and most innovative Chambers in Canada by focusing on the needs of all our members, big and small. For more information, please visit GreaterKWChamber.com. 

The GKWCC is seeking an Event Lead to join our other Event Lead within the Events Team. Our Event Leads are responsible for managing and executing their own portfolio of events within the Chamber’s annual event calendar, supporting volunteer committees, and carrying out the day-to-day administrative functions of the Events Department. While each Event Lead has primary responsibility for specific events, they operate as equal members of a collaborative team, sharing accountability for the overall success of the department and the quality of the Chamber’s event experiences.

Event Leads are expected to actively support one another throughout the event lifecycle, including planning, problem-solving, event-day logistics, set-up, execution, and tear-down, as required. Successes and challenges are viewed through a departmental lens, with both Event Leads working together to ensure a consistently high standard of service, professionalism, and event delivery.

The Event Leads receive direct oversight from the Director, Community Engagement & Strategic Programs (hereby known as ‘Director’), who provides strategic direction, coaching, and oversight.

Department Operations

In addition to managing their assigned event portfolio, Event Leads contribute to the day-to-day operations, planning, reporting, and administration of the Events Department. They share responsibility for maintaining organized processes and supporting departmental goals.

• Provide Event & Committee Updates for monthly Board Reports.
• Maintain accurate and up-to-date project plans, timelines, and task lists within Asana to ensure visibility, accountability, and effective collaboration across the Events Team.
• Monitor event budgets and ensure final expenses, revenues, and reconciliations are completed accurately and in a timely manner following each event.
• Prepare monthly event performance reports, including recommendations and action plans to support continuous improvement and achievement of departmental goals.
• Proactively identify budget concerns, operational challenges, event risks, or other issues and communicate them to the Director, along with proposed solutions and recommendations.
• Collaborate with the Marketing Team to maintain the Events E-Blast Content Calendar, providing content, revisions, approvals, and event-related updates as required.
• Prepare and submit event-related content for Chamber communications and publications, including “Mark Your Calendars” and “Event Highlights”, and other materials as required.
• Participate in and contribute to regular Marketing/Events Team meetings to support cross-departmental communication, alignment, and project coordination.
• Support Chamber Young Professionals (CYP) marketing initiatives through content development, social media planning, blog contributions, and execution of assigned deliverables.
• Draft press releases, media advisories, and other communications materials as directed.
• Provide support for departmental initiatives and special projects, as assigned by the Director.

Event Planning & Execution

Coordinate and execute high quality events. Each Event Lead is assigned their own portfolio of events however, all events are a collective team effort. Both Event Leads support one another throughout the planning, promotion, execution, and evaluation of all events, including event-day set-up, registration, logistics, tear-down, and guest experience.

• Execute virtual, hybrid, and/or live events.
• Secure venues and coordinate all event logistics, including venue requirements, room layouts, technology, accessibility considerations, and virtual event platforms.
• Coordinate keynote speakers, panelists, moderators, and other presenters, providing event details, timelines, and content guidance as required.
• Develop event agendas, run-of-shows, briefing documents, and event scripts.
• Develop promotional materials and ensure event information, registration details, and website content remain accurate and up to date.
• Liaise with vendors and suppliers required for successful event execution, including production, décor, catering, entertainment, and other event-related partners.
• Review contracts, negotiate services where appropriate, and confirm event requirements with vendors and suppliers.
• Welcome and support attendees, sponsors, dignitaries, VIPs, speakers, exhibitors, volunteers, and other stakeholders throughout the event experience.
• Prepare and distribute pre-event, event-day, and post-event communications to attendees, speakers, sponsors, exhibitors, and other stakeholders.
• Prioritize the health, safety, and well-being of guests, volunteers, staff, and vendors.
• Complete post-event evaluations, wrap-up reports, debriefs, and thank-you communications.
• Submit invoices and supporting documentation for processing in a timely manner.

Sales & Sponsorship

Work collaboratively with the Sales and Sponsorship Teams to maximize event revenue, strengthen member engagement, and deliver value to sponsors and partners.

• Build and maintain relationships with event attendees, sponsors, partners, and members to support lead generation and business development opportunities.
• Identify new sponsorship opportunities within existing and future events.
• Recommend new ways to engage, showcase, and support Chamber members through event programming.
• Support event registration and ticket sales efforts among current and prospective members.
• Conduct membership retention and relationship-building outreach as assigned.

Volunteer Committees

Support and guide volunteer committees that contribute to the planning and execution of Chamber events.

• Schedule, attend, and facilitate committee meetings.
• Prepare meeting agendas, minutes, and supporting materials.
• Respond to committee inquiries and maintain regular communication with volunteers between meetings.
• Recruit, onboard, engage, and retain committee volunteers.
• Review and update committee mandates, guidelines, and policies annually.
• Ensure committee members receive, understand, and adhere to applicable policies and expectations.
• Support volunteer recognition and appreciation initiatives.

Administrative Tasks

Contribute to the efficient operation of the Events Department through timely communication, organization, and administrative support.

• Respond to event-related email and telephone inquiries in a timely and professional manner.
• Maintain and update internal event calendars and planning documents.
• Update event tracking tools, project management systems, budgets, and departmental records as required.
• Maintain accurate event files, records, and documentation.
• Support departmental projects, initiatives, and operational priorities as assigned.

Other Duties as Assigned – As you would expect, the Event Industry is unpredictable and requires you to adapt to many different situations at a moment’s notice. As such, there are always “other duties” that come up unexpectedly that you should be prepared for.

• Top-notch organization: You love lists, colour coding, and calendar invites. You can meet deadlines and achieve outcomes even when there are numerous other priorities and distractions. You’re extremely attentive, thorough, adaptable, and focus on the little details.
• Experience in a fast-paced environment: You are willing to tackle projects independently and push through until the job is done. You’re an exceptional multi-tasker, and a self-starter with the ability to take initiative and ownership of your responsibilities.
• Excellent communicator: You keep everyone informed and can do so efficiently, effectively, and professionally – in written and verbal. You’re also empathetic and enthusiastic and feel comfortable socializing with people you may not know. You’re excited at the opportunity to expand your network and build relationships within the community.
• Thrive under pressure: You stay calm, approachable, and in control during stressful situations, by focusing on the solution, not the problem. As this is a customer-facing role you may face some negative feedback and criticisms.
• Leader, not a follower: You’re innovative and think outside the box. You enjoy pushing the limit (creatively), and set trends, not just follow them.
• Tech Savvy: You are comfortable adapting to new forms of technology and using various platforms (social media, video communications, virtual events, etc.). You are also proficient in Microsoft Office.
• Support Local: You make regular trips to the corner bakery, participate in #KWAwesome community groups on social media, and generally enjoy supporting Waterloo Region business owners.
• Helpful, but not required: Experience in photography, videography, video editing, live productions, graphic design, project management, and/or public speaking.

If this sounds like you, or what you’re striving to obtain, then please apply. We look forward to learning more about you and what you could bring to this role.

To Apply: Please send your application to Carolyn Marsh at cmarsh@greaterkwchamber.com. When applying, please provide a resume, and either a cover letter or 60-second self-introduction video.

Next Steps: We thank all those who apply, however, only those candidates who are selected to move forward in the application process will be contacted. The posting will remain open until the position is filled. The start date for the successful candidate is flexible, but preferably they will start in early August 2026.

Position Type: Full time, Permanent.

Hours of Work: Monday – Friday, 8:30am – 4:30pm, with a 30-minute unpaid lunch for a total of 37.5 hours each week. Evenings/early mornings will be required, based on event schedule. Although extremely rare, some weekend coverage for events may also be required.

Travel: Hybrid work environment, with minimum 2 days per week in-office (80 Queen St. N., Kitchener), with additional travel required around Waterloo Region to event venues and/or scheduled pick-ups and deliveries of supplies and donations from partners. Mileage will be reimbursed for work-related activities, but this role requires a valid driver’s license and access to a reliable vehicle.

Compensation: $42,000 – $46,000 annually, plus benefits. Compensation within this range will be based on experience & qualifications.

Benefits:

• Healthcare including dental and vision plan, as well as an EAP program, which all starts 3 months into employment
• RRSP matching, which starts 3 months into employment
• 2 weeks’ vacation + stat holidays + lieu time for hours earned for events
• Monthly mental wellness half-day Friday (subject to change)
• Hybrid work model
• Professional Development opportunities
• Parking included

—

The Greater Kitchener Waterloo Chamber of Commerce believes that everyone is free to be their true self and receive the same respect and opportunity, regardless of ethnicity, gender, culture, identity, sexual orientation, age, beliefs, language, or disability. We have an inclusive work environment that is a safe and welcoming space for all and we encourage applications from all qualified candidates. If you require accommodation at any time during the recruitment process, please email cmarsh@greaterkwchamber.com.

The post Job Posting: Event Lead appeared first on Greater KW Chamber of Commerce.

♦

Registration for socializing is encouraged, but not required. 
kwgranite.com/index.php/club-events/event-registrations/179-open-house-2026/individual-registration

Curling Mini-game - Registration will open soon for a 1 hour mini-game, starting every hour from 3:00 to 8:00 pm.
This will be individual registration with the option to name a teamate. This a quick, fun game, and an opportunity to meet members from other leagues.

Vim Just Syntax

HTML 120 Updated Jul 11

🧐Justfile ecosystem analysis tool

Rust 37 Updated Jun 11

TCE is very popular.  Trichloroethylene  can be fatal as a number of persons in the Bishop St. community of Cambridge have learned the hard way. Usually however it leads to years of sickness and ill health first. Dinoseb is some sort of pesticide that we were advised caused the contamination in the northern part of Cambridge. Plasticizers and phthalates have been found in the Grand River and the groundwater at the south end of Cambridge. TCE is also in the same groundwater right beside the Grand River. 1,1,2 Trichloroethane has been found in the groundwater between Bishop St. and the Grand River also throughout the Bishop St. community.

Waterloo has been blessed with TCE in their groundwater and the major wellfield near the downtown. Obviously with coal tar constituents nearby it's difficult to believe that some of them (PAHs?) haven't also been dissolved and mobilized into the wellfield. The same goes for the coal tar found on Gaukel St. in Kitchener by the very old post office. 

Speaking of Kitchener we have TCE in a number of wellfields. It is combined with some other VOCs (volatile organic compounds) that freshened the air inside a former local tire factory. Many workers paid the price for working there. More exotics include P.C.B.s which are better known as floaters on the water table i.e. LNAPLS or light non aqueous phase liquids. Nevertheless they have a small solubility in order to add spice to the groundwater's flavour. Chlorinated solvents as well as oil and gas PHCs (petroleum hydrocarbons) also add to the groundwater mixture between Fountain St. and the Grand River near Breslau.

Elmira literally has dozens to hundreds of chemicals in their groundwater although our authorities have only focused on NDMA, chlorobenzene and ammonia. Lots more PHCs in Elmira as well as Heidelberg. Probably low levels of DDT and Dioxins are also dissolved in the groundwater here.

This is but a sprinkling of the variety available in our groundwater. Let's not forget Glyphosate (Round Up), salt and Nitrates. Lots for everybody  

CHATHAM-KENT - The Kitchener Panthers hit five home runs, and converted two big innings into a rout of the Chatham-Kent Barnstormers.

The Panthers defeated the Barnstormers 15-3 Friday night in the final game before the All-Star Showdown in Chatham.

A pair of six-run innings led the way for Kitchener.

Trent Lawson went yard twice, while Yosvani Penalver, Malik Williams and Zane Skansi had home runs of their own in the win.

Former IBL rookie of the year Matt Fabian got his first start as a Panther, walking three times and scoring two runs.

Dionys Rodriguez registered the win in his CBL debut, going three innings and giving up just one hit. Evan Elliott gave up two runs on four hits in three innings in the start.

Kitchener improves to 10-15 on the season, but trail Guelph by 4.5 games for the final playoff spot. Chatham-Kent falls to 7-18.

Kitchener will have plenty of representation at the All-Star Showdown, including Josh Williams in the home run derby and Petey Kiefer in the bunting accuracy competition.

Kitchener returns from the all-star break with a home date with Hamilton Thursday at 7:05 p.m.

GET YOUR TICKETS NOW and #PackTheJack!

There is a belief that circulates in engineering teams, usually unspoken, that shows up in how decisions get made under pressure.

Testing takes time. Deadlines are real. When the two come into conflict, testing is the thing that gets compressed. A quick manual check instead of a full suite run. A “we’ll add tests later” comment in the PR. A deployment that goes out on a promise rather than on evidence.

The belief underneath these decisions is that software testing is a cost- something that slows the team down, that competes with shipping, that produces value only in proportion to the bugs it catches. Under this framing, skipping or compressing testing when pressure is high is a reasonable tradeoff. You pay a small quality cost to meet a deadline.

What actually slows teams down is not testing. It is the fear of breaking things that accumulates when testing is absent or unreliable. That fear shows up in deployment anxiety, in excessive manual checking before releases, in the organizational weight that attaches to every deployment when the team cannot fully trust what they are shipping. The fear is the tax. Testing is what reduces it.

The question of what is testing often gets answered narrowly- testing finds bugs before users do. This answer is accurate and incomplete.

Testing’s deeper function is producing knowledge. Specifically, it produces verified knowledge about how software behaves under defined conditions. A passing test suite does not just mean no bugs were found. It means the team has evidence- structured, repeatable, documented evidence- that the software works in the ways the tests cover.

This distinction matters because it changes what testing is competing against. If testing is only about finding bugs, it competes against the assumption that the current code is probably fine and shipping it quickly is worth the risk of being wrong. That is a bet teams make regularly, sometimes correctly.

If testing is about producing knowledge, it competes against uncertainty. Shipping without adequate testing does not eliminate the uncertainty about whether the software works. It just defers encountering that uncertainty until production, where the cost of being wrong is higher. The question is never whether to deal with uncertainty. It is when and where.

Engineering teams that skip testing to ship faster do not actually ship faster over time. They ship the first release faster and then slow down progressively as the codebase becomes something nobody fully trusts.

The slowdown is not dramatic. It accumulates in small increments that are easy to attribute to other causes. Pull requests start taking longer to review because reviewers are checking things the test suite should be covering. Deployments acquire more manual verification steps because the automated checks are not trusted. On-call rotations become more stressful because incidents that should have been caught in development surface in production instead. Senior developers spend more time on “just checking” tasks that junior developers could own if the testing infrastructure gave them sufficient confidence.

Understanding the fundamentals of software testing is what allows teams to break this cycle. Not because knowing testing theory eliminates bugs, but because teams that understand what their tests are actually covering, and what they are not- can make informed decisions about where confidence is warranted and where caution is still needed. The fear of breaking things is highest in teams that do not know what their testing covers. It is lowest in teams that understand exactly what their tests verify and can deploy within that knowledge rather than in spite of its absence.

Testing meaning, in the context of team velocity, is not primarily about quality gates or coverage metrics. It is about the relationship between a team and the software it ships.

Teams with reliable software testing have a different relationship with deployment than teams without it. Deployment is not an event that requires preparation, coordination, and anxiety management. It is a routine output of a process that is already running. The testing that makes this possible is not the testing that catches every possible bug- no test suite does that. It is the testing that gives the team accurate, current knowledge about what the software does, sufficient to make deployment a decision rather than a hope.

This relationship with deployment is what velocity actually looks like in practice. Not a team shipping as fast as possible regardless of what they know, but a team shipping as confidently as possible given what they know, and continuously expanding what they know through testing that stays current as the software evolves.

For teams working with API-driven systems, one of the most common sources of eroded confidence is integration test coverage that has drifted from current service behavior. Mocks that were accurate when written become historical artifacts as downstream services continue to deploy and change. Tests keep passing against the old mock while the actual integration has quietly changed. Keploy addresses this by capturing real HTTP traffic between services and keeping integration test coverage grounded in how services currently communicate rather than how they communicated when someone last updated a mock file. The confidence that comes from testing that reflects current reality is qualitatively different from the confidence that comes from testing that reflects a past state, and it is the former that actually reduces the fear of breaking things.

The teams that have stopped treating software testing as a cost and started treating it as infrastructure describe a specific change in how engineering culture feels.

Developers stop hedging in pull request descriptions. “This should work” becomes “this is tested against current behavior.” Deployments stop requiring the same people to be available just in case. Junior developers start owning more of the release process because the testing infrastructure gives them the context they need to make informed decisions. Senior developers spend less time on manual verification and more time on the work that actually requires their judgment.

None of this happens because the team became more careful or more diligent. It happens because the testing infrastructure removed the uncertainty that was generating the fear that was generating the caution. The team did not slow down to be safe. The team built the infrastructure that made moving fast safe.

Software testing does not slow teams down. Uncertainty slows teams down. Testing is how teams reduce uncertainty to the point where moving fast and shipping confidently are the same thing rather than a tradeoff between them.

Software Testing Does Not Slow Teams Down. The Fear of Breaking Things Does was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

In honor of Disability Pride Month (July), today’s newsletter is focused on how we can be better allies for people with disabilities. I hope you find it helpful. And if you have other suggestions, please reply to this email and let me know. I look forward to learning from you.

What if your workplace held a disability awareness event where participants wore blindfolds, used earplugs, or navigated an obstacle course in a wheelchair?

It may sound educational, but disability advocate Emily Ladau argues it can do more harm than good.

In her book Demystifying Disability: What to Know, What to Say, and How to Be an Ally, Ladau explains that such simulations won’t help you understand a person’s entire life experience and identity.

Instead, they often leave participants with feelings of pity or fear rather than understanding.

She also shared this story from when she was in college:

A resident assistant asked to borrow Ladau’s wheelchair for a disability awareness obstacle course in her dorm. She remembers thinking, “What was I supposed to do while she was using it? Sit stranded in my room?” More importantly, she writes, the event wasn’t about learning from disabled people. It was about letting nondisabled people pretend to be disabled for a few minutes.

She declined.

Instead of trying out a disability, Ladau recommends learning directly from disabled people:

• Read books and essays by disabled authors.
• Listen to podcasts.
• Watch documentaries.
• Seek out conversations with people willing to share their experiences.

Share this action on Instagram, LinkedIn, or YouTube.

This week’s Better Allies content is sponsored by:

Inclusive leadership starts with communication. The words leaders choose, the stories organizations tell, and the conversations teams have shape culture every day. Double Forte helps organizations communicate with clarity, credibility, and purpose during the moments that matter most. Learn more at double-forte.com.

In Just Listen, the American Institute for Stuttering (AIS) sends a powerful message: that people who stutter aren’t asking to be fixed. They’re asking to be heard.

This one-minute video includes a cameo by the actress Emily Blunt, who has had a stutter since childhood. On a recent episode of the Today Show, Blunt expressed how lonely and misunderstood people who stutter can feel.

To be better allies for those who stutter, AIS recommends:

• Don’t finish their sentences or guess what they’re trying to say.
• Skip advice like “take a breath” or “slow down.”
• Be patient. Don’t rush them or signal that you’re in a hurry.
• Focus on what they’re saying — not how they’re saying it.

AIS has additional resources, if you’d like to learn more.

A few years ago, a disability advocate taught me something I hadn’t considered.

They asked if I could stop using italics for long passages of text because, as they explained, “Italics result in decreased reading rate and can be challenging for individuals with vision and neurocognitive disabilities.”

Up to that point, I regularly formatted long quotations in italics.

Thanks to their feedback, I changed my editorial style. Today, I use quotation marks for long quotes and reserve italics for book titles, publication names, and the occasional word or phrase I want to emphasize. (You may have noticed this approach in #1 in today’s newsletter.)

As I learned, italics can help give meaning to content, but only if used sparingly.

On a recent afternoon, I was shopping with some friends in downtown Healdsburg, CA. I noticed someone really struggling to push a woman seated on a rollator (a mobility device) onto a sidewalk. I could hear some frustration between the two of them, and it was clear they were having a difficult moment.

I wanted to rush over and help. But then I remembered a best practice I’ve shared in previous newsletters.

Don’t assume someone with a disability needs assistance. Ask first.

So I walked over and said, “That looks hard. I have some experience helping my mom with her rollator. Would you like some help?”

Both immediately smiled and said yes. And I helped the woman and her rollator get safely onto the sidewalk.

While offering help is kind and a good thing, asking first respects someone’s independence. It also fits in well with the disability rights principle of “nothing about us without us.”

This week’s action from the Better Allies community comes from a subscriber who wrote,

“I recently attended a webinar on living with disabilities that featured a panel of speakers. And every person on that panel indicated that they prefer the terms ‘disabled’ instead of ‘different-abled.’ This was partly because they felt like ‘different-abled’ was infantilizing, but even more so, because they felt the reframing from ‘disabled’ to ‘different-abled’ erases the need to provide additional resources and support.”

Thank you very much for sharing the panel’s advice. And, as I’ve explained previously, “disability” is not a dirty word.

If you’ve taken a step towards being a better ally, please reply to this email and tell me about it. And mention if I can quote you by name or credit you anonymously in an upcoming newsletter.

That’s all for this week. I’m glad you’re on this journey with me,

Karen Catlin (she/her), Author of the Better Allies® book series

Copyright © 2026 Karen Catlin. All rights reserved.

Together, we can make a difference with the Better Allies® approach.

• Say thanks to Karen and buy her a coffee ☕ (Need a receipt for educational reimbursement? Reply to this email, and we’ll take care of it.)
• Sponsor an edition of this newsletter
• Follow @BetterAllies on Instagram, Medium, or YouTube. Or follow Karen Catlin on LinkedIn
• Read the Better Allies books
• Tell someone about these resources

Don’t “Try Out” a Disability, and Other Actions for Allies was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Flash Sale appeared first on Grand River Rocks Climbing Gym.

The post Flash Sale appeared first on Grand River Rocks Climbing Gym.

Well at least Canada is civilized enough (so far) to cause abhorrence and shock at the title above. That said I just bet that by the end of this post there may just be a few who think it's not that bad of an idea. A little radical and a lot permanent, regardless.

Yesterday's post painted the broad strokes. We have way too much salt, nitrates, pesticides and solvents in our groundwater.  Yes it is fair to suggest that the Region of Waterloo are trying to educate the public about the health threats from two of them namely salt and pesticides. Good but nitrates is at least a little verboten (forbidden) to lecture about because after all it's our farmers who feed us and the world. Politically a no-no. Nitrates are very bad for our older citizens especially those with heart problems. Have we forgotten cryptosporidium I wonder. That's a virus I believe found in cattle crap (dung).  It actually killed several people here in Waterloo Region in the early 1990s. Cattle doing their business in and along rivers and creeks introduced it into the water supply eventually through the Grand River at Mannheim which golly gosh our authorities hadn't considered that special treatment was needed.

The really big one however is solvents which also could include some chemicals also used in pesticides although the Region's focus on pesticides has been primarily garden and lawn overuse. Back to solvents. The following wellfields have measurable, concerning levels of toxic chemicals from industry in them. By the way if you think going after agriculture/farmers is a political no-no; Waterloo Region would prefer to cut off your heads rather than point the SHAME finger at our local industrialists and major polluters. Here goes:    Greenbrook, Parkway, William St., Strange St., Pompeii, Erb St., Middleton, Elmira still!, plus one or two more in Cambridge which have temporarily slipped my mind.  

The business/corporate names include  Ciba-Geigy, Northstar Aerospace, Cnd. General Tower, Canbar, Sunar, possibly the former Seagram's, likely the former Uniroyal Tire on Strange St. (Kit.), Kaufman, Budd Automotive, Safety-Kleen (Breslube), Uniroyal Chemical/Lanxess Canada (Elmira), Strauss Fuels (Elmira), former Strauss service station (Heidelberg),  Kitchener Gas Works (Gaukel St.), Varnicolor Chemical (Elmira), Regina St. Waterloo (coal tar).

Now I've reviewed this list in my memory banks and I'm sure that I've missed several others and as well  I'm wondering now about Kaufman Rubber. Let me transfer Kaufman Rubber at least for now onto the suspected list only, along with B.F. Goodrich formerly at the corner of King and Victoria St. in Kitchener.    

Kitchener, Waterloo, Cambridge and the Grand River. Our municipal, regional and provincial politicians have all been grossly negligent in protecting our groundwater mostly originating from the Waterloo Moraine on the west side and a little north of the tri-cities and actually partially extending under them. In reference to yesterday's Blog post let me just say that nitrates are very bad in Wilmot Township presumably due to commercial fertilizers used to grow crops. The other problems in Wilmot include the Region's admitted over pumping in the Mannheim West Wellfield (Wilmot) AND the hydrogeological connection between the Erb St. wells (Wilmot) and the Erb St. Landfill.    

Speaking of landfills how smart do you have to be to locate a landfill anywhere near a drinking water Wellfield? The Region have done it at least twice maybe more if you look carefully in Cambridge.  The second one is the Ottawa St. landfill in Kitchener which has donated 1,4 Dioxane to the Greenbrook Wellfield causing it to be shut down in 2005.  Engineering solutions translate into more and more expensive treatment of our groundwater. By the way reading the Rules & Regs for all of these landfills means very little. Back in the day I exposed mostly Varnicolor Chemical dumping 45 gallon drums of liquid solvents, illegally, into the Ottawa St. Landfill. That did make the K-W Record at the time.

Our groundwater isn't what it used to be and some of the perpetrators are listed here.  

♦

Fieldstone Community Housing is a forming Nova Scotia non-profit building affordable, sustainable small-home rental communities in rural Nova Scotia. Our first project is a pilot community of up to 12 homes, pairing private rental housing with shared green infrastructure to support long-term housing stability. We’re currently pre-incorporation and recruiting our founding board.

Location: Rural Nova Scotia (site exploration currently focused on East Hants / Colchester County)

Opportunity: Founding Board Director

We’re looking for 5-9 founding board members to help incorporate as a non-profit society and guide the organization through its earliest stages. We’re especially hoping to fill these areas:

• Finance/bookkeeping
• Legal/governance
• Construction/property
• Community members with strong roots in rural Nova Scotia

We also need at least one director who is a Nova Scotia resident able to serve as our Recognized Agent.

Commitment: Founding directors will attend an initial organizing meeting, sign on as a subscriber to our Memorandum of Association, and take on ongoing board responsibilities once incorporated.

How to apply: Interested candidates can reach out to fieldstonecommunityhousing@gmail.com

More info: fieldstonecommunityhousing.netlify.app/ 
www.facebook.com/profile.php?id=61591891947495

The post Fieldstone Community Housing appeared first on Capacity Canada.

“Right now, I am five months and 18 days gamble-free. I think that’s probably the longest I’ve gone.”♦

For Lori, her struggle with online gambling started in 2022 with a small, $20 bet on an Ontario Lottery and Gaming Corporation website. It didn’t take long for her gambling to spiral out of control.

“It was another 20 bucks and another 20 bucks, and then I started looking for other websites,” said Lori. “And I found them.”

For a while, Lori managed to keep afloat. She’d win some, lose some, and it wasn’t a problem. But slowly, she started losing more money.

“That hurt, and I needed to tell my husband. He had no idea.

“I’m paying off debts now that I still have another three years to pay,” said Lori. “It took me a lot of stupid places that I thought I would never go, like borrowing and borrowing, taking out stupid loans at 35 per cent.”

Lori has been unable to work since 2014 due to a progressive physical disability. Her job, running a showroom at an industrial supply company, was physically demanding, and soon became too much.

Being at home all the time and not having a focus to her days was difficult for Lori, and meant that online gambling had a strong attraction. The easy access – and ease of hiding the extent of her gambling – meant that it was a hard habit to break.

Through House of Friendship’s Community Counselling program, where participants are connected directly with their own counsellor, Lori began to dig deeper into the reasons behind her addiction.

“Kelly, my counsellor, helped me bring out a lot of stuff I had never dealt with,” said Lori. “She helped me get to the root of my problems, and face a lot of the hard things I’ve dealt with in my life.”

Counselling helped Lori develop the tools she needs to keep away from online gambling, and she has begun to build a support network for herself to stick to her goals.

She also gets to meet weekly with a Zoom gambling support group facilitated through House of Friendship.

“It’s a huge help talking to other people with the same addiction,” said Lori. “We cheer each other on.”

And now that she’s starting to have some success, Lori wants others who are struggling to know something important.

“This doesn’t define you,” said Lori. “This is not the end of your life. If I can get past it, you can get past it. Everyone deserves the chance to break free.”

The post Everyone Deserves the Chance to Break Free appeared first on House Of Friendship.

Picture this. You’ve got a bulk-import job. It parses XML files and generates transaction templates for new clients. It’s been tested up to 3,000 templates, and it runs fine.

Then a real onboarding event hits it with 15,000 templates in one go.

The app melts. Processing time climbs past 90 minutes. Then out-of-memory errors start showing up. The whole thing falls over.

Nobody touched the code that week. So what happened?

Somewhere in the codebase was a query that looked like this:

@Query("SELECT t FROM Template t JOIN FETCH t.collectionA JOIN FETCH t.collectionB WHERE t.id = :id")
Template findWithDetails(@Param("id") Long id);

It reads clean. It compiles. It even returns the right data when you test it on one record.

The problem only shows up at scale, and it’s a sneaky one. But before we get to why, it helps to be clear on what JOIN FETCH actually is: it's eager loading. So let's take a quick step back.

Every ORM gives you two ways to pull related data. Both are trying to solve the same problem, but they make very different tradeoffs.

Eager loading: bring everything now.

You ask for a User with their Orders eagerly loaded, and the ORM’s logic is basically “I’ll grab the user and all their related data in one trip.”

Under the hood, it builds one query, usually a LEFT JOIN:

-- The ORM sends this single query immediately
SELECT u.id, u.username, o.id, o.amount, o.order_date
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.id = 1;

• Good: one round trip to the database. Once it lands, everything’s ready to use.
• Bad: if that user has 10,000 orders, you just pulled all of them into memory, whether you needed them or not.

Lazy loading: wait until I actually ask.

Fetch that same User lazily, and the ORM’s logic flips to “just give me the basics for now, I’ll go back for the orders if someone actually needs them.”

This happens in two steps.

First, a lightweight query for just the entity itself:

SELECT id, username FROM users WHERE id = 1;

Instead of pulling the orders, the ORM drops in a proxy, basically a hollow placeholder sitting where the real data would go.

Then, the moment your code actually touches it (user.getOrders(), user.orders.length, whatever), the proxy wakes up and fires a second query on the spot:

-- This runs ONLY when you try to access the orders property
SELECT id, amount, order_date FROM orders WHERE user_id = 1;

• Good: fast initial query. Saves memory and bandwidth if you never end up needing the related data.
• Bad: this is where the N+1 problem comes from. Fetch 100 users and loop through reading their orders, and you’ll fire 1 query plus 100 more, one per user, and your app crawls.

So here’s the tension. Lazy loading protects you from over-fetching but can quietly turn into hundreds of tiny queries. Eager loading solves that by fetching everything up front in one trip, which is exactly why JOIN FETCH looks so appealing.

And that’s the setup for our bug. JOIN FETCH Is eager loading working exactly as designed? The problem starts when you eagerly fetch two collections in the same query.

When you JOIN FETCH two different collections in the same query, Hibernate doesn't fetch them side by side as you'd expect. It cross-joins them.

Say a template has 5 records in Collection A and 5 in Collection B. You’d expect 10 rows back. You get 25.

That’s exactly what’s happening below. Every dot is one row Hibernate hands back to your app for a single template.

Now do that math for 15,000 templates instead of one, each with more like 10 to 20 records per collection. That’s how you end up with 50 million rows in memory for a job that should’ve touched a few hundred thousand.

Here’s the part that makes this bug genuinely hard to catch.

If those two collections were mapped as List (Hibernate calls this a "bag"), the app would refuse to even start. You'd get a MultipleBagFetchException on boot and know immediately something's wrong.

But these were mapped as Set. So the app boots fine. Tests pass fine. It's only once you throw real production volume at it that the cross-join starts eating your heap alive.

That’s the trap. Small data, small tests, everything looks healthy. Then one big onboarding day and it’s a 2am page.

Three steps, nothing fancy:

1. Pulled a heap dump from the live incident and ran it through JProfiler. Millions of duplicated entity instances, way more than the actual record count.
2. Turned on Hibernate SQL logging. Found a single generated SQL statement that was thousands of characters long. That’s usually your first clue something’s cross-joining.
3. Checked Hibernate Statistics and confirmed it: the number of rows coming back from the database was nowhere close to the number of actual entities we had stored.

That combination (a monster query plus a wildly inflated row count) is basically the fingerprint of a Cartesian product bug.

1. Split the query into two.

Instead of one query joining both collections, fetch each collection separately. Hibernate’s session cache automatically stitches them back into one entity behind the scenes, no cross-join needed.

@Query("SELECT t FROM Template t JOIN FETCH t.collectionA WHERE t.id = :id")
Template findWithCollectionA(@Param("id") Long id);

@Query("SELECT t FROM Template t JOIN FETCH t.collectionB WHERE t.id = :id")
Template findWithCollectionB(@Param("id") Long id);

2. Let batch fetching handle the rest.

For everything else, @BatchSize tells Hibernate to grab child records in batches using a IN clause, instead of one query per collection per entity.

@OneToMany(mappedBy = "template")
@BatchSize(size = 20)
private Set<CollectionAItem> collectionA;

3. Clear the session periodically.

Bulk imports run in one long transaction, and Hibernate’s first-level cache just keeps growing the whole time. Adding flush() and clear() calls at fixed intervals stops that cache from becoming its own memory problem.

Row count dropped about 9x. Processing time dropped 15x. And the thing that actually mattered at 2am, the OOM crash, just stopped happening.

• One JOIN FETCH per query. If you need a second collection, give it its own query or use @BatchSize.
• Actually look at the generated SQL, not just your JPQL. Three clean lines of code can turn into a monster query underneath.
• Compare row counts to your actual table size. If Hibernate’s fetching way more rows than exist, something’s multiplying.
• Set won't save you from this. It just delays the failure until production traffic finds it for you.
• Long-running imports need session cleanup. Flush and clear on a schedule, or your first-level cache becomes its own leak.

Hibernate is genuinely great at hiding SQL from you. Most days that’s a gift. The day your dataset gets big enough, it stops being a gift and starts being the thing that pages you.

Ever had a Hibernate or JPA bug that only showed up once real traffic hit it? Drop it in the comments; I want to hear it.

Hibernate Turned 11,000 Records Into 50 Million Rows was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who are they kidding? At some point in time there will be another water crisis in Waterloo Region. It's a given. This one however won't mostly consist of developers and builders demanding their profits keep on increasing. This next one will be citizens being told that they are on water rationing. They will be told that there will be so many hours per day when their taps will not provide water. Regional Councils and municipal councils are going to want to fortify their council chambers and administrative buildings. Citizens will be outraged as well they should be.

Here is the good news, sort of.  The Region will vehemently protest that it's not their fault. It's Global Warming & Climate Change. Their staff are world class leaders in water protection, water conservation, water distribution and all that. They will go to great lengths to suggest that anyone and anything other than themselves have caused this catastrophic shortage. They might even blame the Federal government and ...holy crap...actually suggest that maybe, just maybe 1,000,000 people in Waterloo Region by 2051 wasn't such a hot idea afterall. Perhaps we should have found more water first. Perhaps we should have built more sewage treatment plants before the influx. Perhaps hospitals, doctors and nurses shortages should have been remedied first. And on and on.

Here however is the reality. We and by we I mean our politicians at all levels have given business and industry a free ride for the last century. Frankly they have done the same thing with our farmers and agriculture in general. We are now reaping the rewards of exempting those two industries from environmental laws, environmental enforcement and environmental stewardship. Perhaps cars and roads are also culprits with he alleged amount of salt now in our aquifers. Agriculture has contributed Nitrates en masse to our groundwater. Industry have contributed solvents including TCE, NDMA and chlorinated solvents. Oil and gasoline are also big culprits whether from service stations leaking tanks or other sources. 

The Region of Waterloo have talked a good game. Unfortunately they started way too late and they've continued heavier with the talk and the reports and studies while ignoring enforcement. They haven't even had the backbone to stand up to the impotent and incompetent Ontario Ministry of Environment (MECP). Contaminated soils and aquifer remediations are a pathetic joke even when they do happen. Underfunded for decades, the MECP get pushed around in and out of court by large industry at will. 

Our aquifers are a mess from all these mentioned contaminants. Never fear because the same folks who made money polluting them will now jump on the PIPELINE bandwagon and invest in bringing polluted Lake Erie water here to Waterloo Region. Money will be made just not by you and me. That is not our purpose in life. We, the public, are here to pay the bills via our taxes. The price of water and water treatment will continue to rise until it's a great excuse to build a pipeline. Taxes will still go up but at least we'll have a secure supply of crappy water for a while. God bless democracy.

Earlier this year I decided I needed a change, so I started looking for a new job. I interviewed across five companies: a quantum computing company, a big pharma company, a big tech company, a medical imaging startup, and an AI company in real estate, all while working full-time. I wrote about the coding interview formats I encountered. This is time I’m writing about preparation.

I ended up with offers from three of them, no offer from the big pharma company, and pulled out of one of them after the first round because it felt too close to my current role. The constraint throughout wasn’t knowledge; it was time and precision. Five different roles, five different things they actually cared about, and a full-time job I wasn’t willing to let slip in the process.

That last part matters. The standard advice for a job search is to treat it like a second job. That’s fine if you’re between roles. It’s less fine if you’re midway through a Shape Up cycle and still responsible for shipping the work you committed to. What AI made possible was targeted, high-quality prep. Without it, I’d have been choosing between preparing properly and showing up properly at work.

This isn’t about using AI to cheat in interviews. It’s about using it as a coach before them: to go deeper faster, to connect your actual experience to what a specific role needs, to sharpen how you communicate what you already know. The experience has to be yours. AI helped me prepare the parts I already had.

The failure mode was also obvious. If I gave it a broad brief, it gave me broad advice. If I gave it a role description, it sometimes tried too hard to make every project sound perfectly aligned with that role. In the prep sessions, the same work could be made to sound relevant to almost anything: pharma infrastructure, medical imaging data loading, agentic systems, real-estate document AI. Some of those connections were real. Some were only adjacent. The useful step was making the overlap visible, not accepting every framing it suggested.

Here’s what worked.

If you’ve been following my blog so far, you probably gathered that I’ve been using AI to help with my day-to-day work for a while now, so using it for interview prep felt like a natural extension. It already has context on what I’ve built. Why not ask it to help me figure out what to actually showcase?

For each role, I’d paste in the job description and ask: what have I worked on that maps directly to this? The useful thing isn’t that AI knows more about my work than I do. It’s that it can make connections quickly across a lot of context without me having to sit and think through months of projects from scratch.

For the big pharma role, it flagged the way we used pre-signed S3 URLs for secure uploads as a strong example for their infrastructure questions, because the security model (credential isolation between untrusted edge nodes and cloud storage in a HIPAA-compliant pipeline) gave me a way into what they cared about. I knew that work well. What the AI gave me was a clear train of thought going in: here’s the example, here’s why it’s relevant, here’s how to frame it for this specific audience.

For the medical imaging interview, I was meeting their principal ML scientist. I found an article he’d written about 3D CT medical imaging: the computational bottlenecks, why standard tooling wasn’t fast enough, what his team built to replace it.

I brought that article into a prep session: here’s who I’m meeting, here’s what he’s written about publicly, here’s my background. What’s the genuine overlap? What will resonate vs what will sound like it came from a generic ML resume?

The output was specific: the angle he’d find interesting was data loading efficiency and the full execution path from file iteration to model call, because that’s where his team had spent the hard engineering effort. That gave me a more concrete way to frame my work: not as a generic tour of my ML background, but as examples that connected to the problems his team was working on.

One company built their process around ML research papers. The first round was a discussion of a generative modelling paper. The second was a more specialised ML paper. The final round was a short presentation on how I’d test a research hypothesis connecting the two.

For the discussion rounds, I used AI to sharpen my read before going in: what’s the core thesis, what’s genuinely novel versus a synthesis of prior work, what are the likely discussion angles, what are the strong takes and the interesting critiques.

The most useful thing it gave me was framing. For one paper, the useful position was: this is a clarification of the design space, not a new benchmark-chasing result. That’s a defensible read, and it changes the conversation. You’re not just summarising the paper; you’re making a claim about what kind of contribution it is.

The slides round was more hands-on. I built the presentation iteratively with AI: draft a slide, get feedback on technical precision, refine, move to the next one. It flagged places where my experimental design made implicit assumptions and helped me anticipate the questions a researcher from a different technical background would push on.

By the time I presented, I still had to defend the experimental design myself. The useful part was that the weak spots had already been named.

For one interview I knew the format would involve open-ended AI systems design questions: design an agent, evaluate a system, think through production instrumentation.

I ran mock sessions with AI as interviewer. The point wasn’t to find out if I knew the material. It was to sharpen how I communicated it under time pressure, with someone actively probing.

The feedback was specific enough to be useful:

• An agent design answer scored 7.5/10. The architecture was right, but I hadn’t made the human-in-the-loop gates explicit enough for the interviewer to follow the reasoning.
• A precision/recall answer scored 5.5/10. I was framing the metric correctly but hadn’t connected it to “good enough for the specific action we’re taking,” which is what the question was actually asking.

I mostly needed that feedback at inconvenient times: late evening, before work, or between interview rounds. Mock sessions surfaced it before the real interview, not afterward.

I pointed AI at my personal website, work history, and public writing before prep sessions for behavioural rounds. Then I’d work through questions like: who inspires you, what do you like doing, tell me about a technical disagreement, and tell me about a time you handled ambiguity.

The useful part was not getting a polished STAR answer. It was having the model pull candidate stories from my actual work. For “what inspires you to learn something new,” it picked up a pattern I probably would not have phrased as clearly on the spot: friction. Repeated manual triage, repeated review comments, repeated context loss between AI sessions. That was a better answer than “I like learning new technologies,” because it connected to how I actually work.

For disagreement, it surfaced a code-review pattern: one person seeing a design as over-engineered, another seeing it as necessary for the planned architecture. The useful framing was to move the discussion away from preference and back to context: what requirement was this complexity serving, what alternatives existed, and what were we giving up if we simplified it?

Again, I had to edit the answer back into my own voice. AI tends to make behavioural answers sound cleaner than real work feels. But it was useful for finding the story.

The pattern across all of this was not that I asked better-sounding prompts. It was that I stopped treating interview prep as a generic category.

If I asked, “help me prep for an ML interview,” the output was exactly what you’d expect: broad topic lists, common questions, and answers that could have belonged to anyone. The useful sessions started once I gave it the actual situation: the role, the format, the interviewer if I knew them, the job description, and my own raw material.

The difference looked like this in practice. “Explain RAG” was too broad. “I need to discuss RAG tradeoffs at the senior engineer level; what decisions matter, and where do interviewers usually probe?” was useful. “Help me present this project” was vague. “I need to present this log-analysis and issue-triage workflow in an interview; help me structure the problem, architecture, guardrails, and tradeoffs” gave me a usable narrative. “How do I design a story-writing agent?” would have produced a toy answer. “Reason through this as a production creative system: planning, memory, structured outputs, evaluation, safety, and user control” forced a much better discussion.

The same was true for behavioural prep. “How should I answer behavioural questions?” produced template answers. “Here are the questions and here is my actual work history; which stories are strongest, and which ones sound forced?” gave me something I could work with.

Then I would ask for something narrower than an answer. Not “write my response,” but: what is this role really screening for? Which of my projects are directly relevant, and which are only adjacent? What would this interviewer probably probe on? Where does this answer sound overstated? Which behavioral story is strongest for this question?

That distinction mattered. If I asked for a finished answer too early, the model made it smooth before it made it true. It would produce something plausible and well structured, but a little too convenient. Asking for candidate examples was better. I could reject the weak ones, correct the overfit ones, and keep the parts that actually mapped to my experience.

The prompt I came back to most often was some version of:

Here is the role. Here is the interviewer. Here is my background. Find the strongest overlap, but separate direct experience from adjacent experience.

The second half of that prompt did a lot of work. Without it, AI is very good at making your experience sound aligned with whatever role you put in front of it. For interview prep, that is both the useful thing and the dangerous thing. You want help seeing the overlap. You do not want to accidentally turn every adjacent project into a perfect match.

So the real workflow was: bring the context in, ask for the overlap, challenge the output, then rewrite it back into something I would actually say.

That’s where AI was most useful: not as a source of interview answers, but as preparation help. It made the prep faster, more specific, and easier to fit around work. The answers still had to come from me.

What’s the most targeted thing you’ve done to prep for a technical interview?

How I Used AI to Prep for Interviews While Working Full-Time was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to think deployment confidence was something senior developers just had. They would push code with a calm that felt almost casual. No hesitation before hitting merge. No checking Slack obsessively for twenty minutes after a deployment to see if anything broke. Just — ship, and move on.

I spent a long time assuming this was about experience. That at some point you just know your codebase well enough to ship without anxiety. What I eventually figured out is that the calm was not about knowing more. It was about trusting the right things.

The thing I was trusting- my regression test suite- was not trustworthy in the way I thought it was. And the habit I changed to fix that transformed how I think about shipping code entirely.

Three years ago I was working on a platform with about twelve services. We had a regression suite that covered the core user journeys, the main API endpoints, and most of the integration points between services. Coverage was around 68 percent. Not perfect, but solid.

We ran the suite before every deployment. It passed most of the time. When it failed, it usually caught something real. I felt good about it.

Then we had an incident that took me a long time to fully understand.

We deployed an update to our notification service on a Tuesday afternoon. The pipeline was green. The regression suite passed. We shipped and closed our laptops.

By Wednesday morning, a subset of users could not complete the checkout flow. The error was in the order service — a service we had not touched in the Tuesday deployment. The order service was calling the notification service and receiving a response shape it was not designed to handle. The notification service had changed how it structured its error responses in a previous deployment. The order service’s tests had not caught this because they were running against a mock that reflected the notification service’s behavior from six weeks earlier.

Six weeks. The mock was six weeks out of date, and nobody knew.

The regression suite passed because it tested everything it knew about. The problem was that what it knew about was six weeks behind reality.

After that incident, I started paying attention to how our regression coverage actually worked. What I found was uncomfortable.

Every integration test we had was running against a manually maintained mock file. A developer had written those mocks when the integrations were first built. They specified how downstream services would respond — what fields they returned, what error shapes they used, what behavior they exhibited under edge conditions.

The mocks were accurate on the day they were written. Then the downstream services kept deploying. Response fields got added. Error handling got updated. API behaviors changed in small but consequential ways. Nobody updated the mocks because nobody knew they needed updating. There was no mechanism that connected a downstream service deployment to a prompt for updating the mocks in every service that depended on it.

I had been trusting a regression suite that was secretly running against a historical snapshot of the system. Not the current system. The system as it existed weeks or months ago. Tests passed because the snapshot was internally consistent- not because the actual integrations were working correctly.

This is the habit I did not know I had: I was writing regression tests and then assuming they stayed accurate. They did not. They decayed.

The realization that mock files decay changed how I think about the source of regression testing coverage.

The old approach was specification-based. I specified how services should behave and wrote tests against those specifications.

The problem I kept running into was simpler than it sounds. I was writing down what I thought services would do. But what I thought and what they actually did kept diverging- slowly, silently, without anyone noticing until something broke.

I started asking a different question. Instead of “what should this service return,” I started asking “what does this service actually return when real traffic hits it.” Those two questions sound similar. The answers are often very different, especially six months into a product that has been shipping weekly.

That reframe is what shifted the approach. Stop specifying. Start observing. Use what the system actually does as the baseline for what the tests should verify, not what I assumed it would do when I was writing the integration code at midnight on a Wednesday.

The specific implementation I work with now uses Keploy — an open-source API testing tool that captures real traffic from running services and generates regression test cases and dependency mocks from those actual interactions. When a downstream service changes its behavior, new traffic captures from the updated service automatically reflect that change. The mocks in my regression suite stay calibrated to current service behavior without requiring anyone to remember to update them after each downstream deployment.

The shift sounds technical. The practical experience of it is simpler than that. When the regression suite passes now, I know it is passing against how the system currently works- not against how it worked six weeks ago. That distinction is what changed how shipping code feels.

After making this change, I understood something about the calm senior developers had that I had been misreading.

It was not that they knew the codebase so well that nothing could surprise them. It was that they had built or inherited testing infrastructure they genuinely trusted. They knew what their regression suite was checking, and they knew it was checking current behavior. The confidence came from that knowledge, not from experience alone.

The anxiety I used to feel before deployments was not irrational. It was an accurate read of the situation. I had a regression suite that was partially checking a version of the system that no longer existed. Of course I was anxious. My tests were not telling me what I thought they were telling me.

When the coverage source changed, the anxiety changed with it. Not because deployments became risk-free- they never are- but because the risk became legible. I knew what my tests were validating. I could look at a deployment and make a real assessment of whether the relevant behaviors were covered rather than hoping that something I had not thought to check would not break.

That is the distinction between false confidence and genuine confidence. False confidence comes from green pipelines you have stopped questioning. Genuine confidence comes from understanding what those green pipelines are actually verifying.

If I were to pass one thing on to developers earlier in their careers than I was when I learned this, it is to interrogate your regression tests not just on whether they pass but on what they are actually checking.

Specifically, when did you last verify that your mock files reflect current downstream service behavior? Not when did you last update them, but when did you last confirm they are accurate? The difference between those two questions is where most regression testing confidence problems live.

The habit of keeping regression test coverage grounded in current system reality rather than historical assumptions is unglamorous. It does not show up in any metric that gets reported in planning meetings. Coverage percentages look the same whether the mocks are accurate or not.

But it is the habit that makes the difference between a deployment that feels like a coin flip and a deployment that feels like a considered decision. Between checking Slack obsessively for twenty minutes after a merge and being able to close your laptop and move on.

I did not learn this from a course or a book. I learned it from an incident that traced back to a six-week-old mock file. I would rather you learn it this way.

The Regression Testing Habit That Changed How I Think About Shipping Code was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tostan Canada is a registered Canadian charity dedicated to advancing transformative, community-led development in West Africa. Since 2012, we have partnered with Tostan International to mobilize Canadian resources for programs that empower communities to lead their own development and advance the rights, education, and economic participation of women and girls.

We believe in the power of local leadership, holistic education, and sustainable change. Our support helps communities gain the knowledge and confidence to make informed decisions that improve the lives of their families, their communities, and future generations.

For over 30 years, Tostan’s flagship Community Empowerment Program has fostered community-driven change in West Africa through holistic, human rights–based education. More than 3,000 communities have led initiatives that improved health, education, governance, and economic opportunity.

Through the generosity of Canadian donors, Tostan Canada has supported programs in Senegal, Mali, The Gambia, Guinea, and Guinea-Bissau. Thousands of women, girls, and community members have gained vital skills in literacy, health, and entrepreneurship—resulting in higher literacy rates, increased school enrollment, improved prosperity, and stronger women’s leadership.

Tostan Canada is seeking a Treasurer to join our Board of Directors. Our Board is a highly engaged, small group of volunteers that support our National Director in raising awareness for and support for Tostan’s work in Africa. The Treasurer is an officer of the board, and plays a key role in overseeing the financial management and ensuring compliance with Revenue Canada charitable requirements.

This is a hands-on, volunteer position. Tostan Canada is a small, lean organization. The Board Treasurer personally carries out the organization’s financial functions, in addition to fulfilling the fiduciary duties of a Board member. The Treasurer provides financial expertise to the board and ensures that the Board has the financial information and tools needed for effective financial governance and oversight for the organization. Tostan Canada has a budget of approximately

$2 million, and fewer than 100 transactions per year. The Treasurer position requires approximately 8-10 hours per month, with a bit more during audit season.

Tostan Canada Board members hold office for three-year terms, with the possibility of renewal.

Financial Record-Keeping

• Maintain the organization’s general ledger.
• Record all income and expenses accurately and on a timely basis.
• Maintain organized financial files and supporting documentation (invoices, receipts, statements, etc.).

Banking and Reconciliation

• Monitor and reconcile bank and other financial statements on a monthly basis.
• Process deposits and oversee disbursements and payments, acting as a signing authority per Board policy.

Donation Receipting

• Oversee the issuing of official donation receipts in accordance with Canada Revenue Agency (CRA) requirements.

Financial Reporting and Oversight

• Prepare and present financial reports at Board meetings.
• Ensure that the organization maintains and adheres to appropriate financial policies, internal controls and reporting systems.
• Chair the finance committee and meet as needed.

Budgeting

• Support the National Director in preparing an annual budget
• Monitor actual spending against the approved budget throughout the year.

Audit Oversight

• Assist in selecting an auditor
• Coordinate and oversee the annual audit or financial review.
• Liaise with the external auditor/reviewer and provide requested documentation.
• Present audit findings and recommendations to the Board.

Regulatory Compliance

• Ensure the organization’s financial records support accurate and timely completion of the CRA Registered Charity Information Return (Form T3010), due within six months of the fiscal year-end.
• Retain financial records and supporting documents for the minimum period required by the CRA (currently six years).
• Stay informed of CRA requirements relevant to a registered charity’s financial administration.

Other Board Responsibilities

• Participate in quarterly board meetings
• Provide strategic oversight and governance to ensure alignment with Tostan Canada’s vision, mission, and values.
• Communicate and promote the organization within the community, serving as an advocate.
• Ensure compliance with all legal and regulatory requirements.
• Stay informed about issues and trends that may affect the organization.

• Proven experience in financial management and accounting (CPA or equivalent is preferred).
• Strong understanding of financial reporting.
• Experience with nonprofit finance is preferred.
• Excellent organizational skills.
• Board governance experience is desirable
• Knowledge of international development issues would be considered an asset in understanding the organization’s context and funding environment.

We are looking for a treasurer to join Tostan Canada in the fall of 2026.

If you are interested or would like to talk to us about the position, please contact kellybaxter@tostan.org or sophiechampagne@tostan.org.

Tostan Canada welcomes and encourages applications from members of equity seeking groups, including people living with disabilities, Indigenous, Black, and racialized individuals. At Tostan Canada, we are dedicated to building a diverse, inclusive, authentic and accountable workplace. If you are excited about this position but your experience does not align perfectly with every qualification, we encourage you to apply, as you may be the ideal candidate we are looking for.

The post Tostan Canada appeared first on Capacity Canada.

Like many across Waterloo Region, we were disappointed to learn of the closure of 570 News Radio. We believe this is a significant loss for our region and, particularly for our local business community, which has long relied on the station for trusted local news, business information, and community connections.

As business organizations, we understand that companies must make decisions to ensure their long-term viability and profitability. However, we believe every effort should first be made to explore ways to continue providing an important community service by working collaboratively with local partners to identify solutions that balance business sustainability with the needs of the communities they serve.

Rogers did not reach out to our organizations, or to our knowledge, to other business and community leaders in the region to discuss possible alternatives before making this decision. We can’t help but wonder what opportunities might have emerged had there been a collaborative conversation.

That said, Waterloo Region has always been resilient, innovative, and forward-looking. We will find new ways to stay connected, informed, and engaged.

For more than 16 years, our Business to Business radio show has brought listeners meaningful conversations with business leaders, subject matter experts, elected officials, and policy makers. With more than 700 episodes produced, it has become the longest-running talk show in the station’s history, helping explain the issues shaping our economy, highlighting the successes of our business community, and demonstrating how, together, we can influence positive change.

While the radio station may be closing, Business to Business is not.

The show will return soon as a podcast, available wherever you listen to your favourite podcasts. This new format will allow for even more candid conversations, deeper business insights from Chamber members, and the return of familiar voices, including our regular Parliament Hill contributor, JD Bellavance, Ottawa Bureau Chief for La Presse.

There will also continue to be advertising and sponsorship opportunities for Chamber members who want to connect with Waterloo Region’s business community.

Click here to share your contact information with us and subscribe to updates. We’ll let you know as soon as new episodes are available, so you won’t miss a conversation

The post Closure of 570 News Radio appeared first on Greater KW Chamber of Commerce.

• What: 5th Annual KW Palestine Festival ♦
• When: 1:00pm to 9:00pm on Sunday 12 July 2026
• Where: Carl Zehr Square (Kitchener City Hall)
• Location: 200 King Street West, Kitchener, Ontario Map
• Online: www.instagram.com/kwpalestinefestival
• Contact: sporasscattered@gmail.com
  

The 5th Annual KW Palestine Festival introduces Ounadikom, or Palestine Calls on You.

Hosted by the Palestinian Youth Movement and Sporas Scattered.

As the genocidal Zionist entity continues its campaign of ethnic cleansing against our people, and the cancer of Zionism continues to spread in our region, our people remain standing, steadfast and unshakable in the face of bombing campaigns, imprisonment, forced displacement and more. They refuse to bow down or accept the barbarity of the Zionist regime, resolute in their pursuit of complete and total liberation.

This year, we call on you to join us in honoring their steadfastness and resistance as we come together for the fifth annual KW Palestine Festival, Ounadikom. We will renew our commitment to the Palestinian cause, and ground ourselves in the role we play in the diaspora through various exhibits, performances, presentations and a celebration of our culture.

♦

Hello, My Digital Friends and Family, Did Y’all Miss Me??

Ms.DataBtye has just started in the corporate world and was busy trying to find her life amidst the “logical” errors. On a frustrated night, at 2 a.m. I was doing what every emotional fool does… scrolling through old chats with my ex.

Not because I missed him. Not because I wanted closure. And definitely not because I was trying to decode why he thought replying “hmm” was an acceptable response to a paragraph message. (Like wth bro?)

Look, the internet has turned texting into an Olympic sport. Everyone suddenly becomes a relationship strategist the moment a conversation screenshot goes viral.

“Wait three hours before replying.”
“Never double text.”
“If he wanted to, he would.”
“Be mysterious.”
“Play hard to get.”

Apparently, finding love now requires the tactical planning of a military operation and the emotional availability of a houseplant. And the weird part? People swear by these rules!

Every dating coach has a formula. Every TikTok relationship expert has a theory. Every friend has that one story about how ignoring someone for three days magically makes them obsessed.

But nobody ever seems to ask the obvious question: Where is the data?

As someone who spends an unhealthy amount of time turning messy human behavior into charts, I couldn’t help myself. The more relationship advice I heard, the more suspicious I became. Because, let's be honest, humans are terrible at remembering patterns. And I cannot survive anymore breakups.

We remember dramatic moments. We remember the breakup text. We remember being left on read for six hours. We remember the one argument that ended everything. But we rarely notice the hundreds of tiny signals that happen before the ending.

So You already know my views on Internet Wisdom, I’m Ms. DataByte. I don’t trust internet opinions; I analyze them. My goal isn’t to expose my ex. (But how much I wish to…)

I collected thousands of relationship discussions, breakup stories, and texting experiences from Reddit communities like r/relationships, r/relationship_advice, r/dating, r/BreakUps, and r/texts using Reddit’s API. I supplemented this with relationship articles and communication research from sources like Psychology Today, Verywell Mind, and The Gottman Institute. After cleaning and processing the data, I used text mining, sentiment analysis, and keyword extraction to uncover the patterns behind texts, effort, communication, heartbreak, and everything that happens before someone decides to leave a relationship or leave a message on read.

Quick Disclaimer: This analysis explores emotional dms through real statistics. Any observations regarding gender, age, or behavior are based on dataset averages and are intended for educational (and entertainment) purposes only. No feelings were harmed in the making of this Python script.

One of the strangest things I discovered was that some people text as if they’re communicating in person.

You send a message, and they reply in dull sentences (Even random words). You answer with long explanatory paragraphs with emojis and feeling…But they just show they are not worth it.

Now, before anyone says, “But that's their way of texting!”

Sure, it's their way of texting. But nobody is accidentally switching their feelings off while talking to their partner.

I thought a relationship is about feelings, so why let them hide and suffer?

The data showed something interesting.

Nobody is bothering on the breakup texts, or ghosting… What they are actually fighting is about their texting methods. Which Influencer’s text advice are you taking and whyyy

Be yourself, express, and let your texts talk about your thoughts. Do not text bland and dull, be expressive!!!

Turns out people wanna talk when the other is invested in talking too.

One of the strangest things I discovered was that some people text as if they’re communicating through carrier pigeons.

Some people don’t communicate. They perform disappearing acts. One minute you’re discussing dinner plans. The next minute, they’ve vanished with the efficiency of a government witness protection program.

Then three days later, they return with: “Sorry, been busy.” Busy doing what? Building the pyramids?

The data behind ghosting discussions revealed something surprising.

Most disappearances weren’t sudden. Communication quality usually starts declining weeks beforehand. Fewer messages. Shorter replies. Less curiosity. The ghost was haunting the conversation long before it officially died.

Its Important to understand that if you are ghosting someone, you are literally playing squash with their hearts. I get it that it might be difficult or you both want privacy, but when you pull out this move… The other person just spirals down into overthinking. Being the June girl I am, I can definitely tell you how much it hurts spiraling and overthinking.

If you are not interested or invested, it's better to talk and leave. Give closure, speak your heart out, and show the person why you wanna ghost. Don't hurt the person. The bar chart isn’t lying; it is miserable to even look at.

Relationships are fascinating. Especially when one person thinks they’re a partnership and the other thinks they’re a subscription service.

One person starts every conversation. Plans every date. Carries every discussion. Meanwhile, the other contributes the occasional “lol”.

OUCH! Now that’s some data…

According to the data, the healthiest conversations showed a surprisingly balanced effort distribution. Not perfectly 50–50. But close enough that neither person felt like an unpaid intern.

The fastest dying conversations often had one common feature: One person was doing all the work.

Some people text like they’re being controlled by multiple personalities sharing one phone. One day, they’re all lovey-dovey, and the next day, they are over you. (Why do SUCH people exist?)

The data showed that consistency mattered more than intensity. People don’t build trust from occasional bursts of attention. They build trust through reliability.

A relationship shouldn’t feel like you’re refreshing a broken Wi-Fi connection.

Nothing creates confusion faster than mixed signals.

“I like you.”
“I don’t know what I want.”
“You’re special.”
“I’m not ready.”
“Where is this going?”
“Let’s not label things.”
“I want You!”
“I’m Confused.”

At this point, we’re not dating anymore… We’re solving a murder mystery.

One pattern repeatedly appeared in breakup stories. People weren’t hurt because of rejection. They were hurt because of uncertainty. They were hurt because they over-analyzed.

Human beings can process bad news. What destroys them is contradictory data.

There is something fascinating about modern relationships. People will share their location. Share their passwords. Share their Netflix account. But what about sharing their feelings? Absolutely not!!!

Somewhere along the way, we’ve convinced ourselves that expressing emotions is embarrassing. So instead of saying, “That hurt my feelings,” we become detectives, mind readers, and part-time FBI agents looking for clues in text messages.

He replied with a period instead of an emoji. She took two hours longer than usual to respond. He liked my story but didn’t text me. Congratulations. We are now conducting forensic investigations instead of having conversations.

The truth is, feelings are data. Not the kind that fits neatly into Excel spreadsheets, but data nonetheless. Every feeling tells us something.

When I analyzed relationship discussions and texting patterns, one thing became painfully obvious: relationships rarely collapse because people talked about their feelings too much.

The healthiest conversations weren’t the ones where people never felt hurt. They were the ones where people felt safe enough to say they were hurt. And that’s an important distinction. Communication isn’t about sending more messages. It’s about sending honest ones.

Because no matter how advanced technology becomes, there is still one thing a text message cannot do: Read your mind!

“Your partner cannot fix a feeling they don’t know EXISTS. They cannot reassure an insecurity you’ve never shared. And they certainly cannot respond to a conversation that only happened inside your head.”

After analyzing thousands of conversations, breakup discussions, and relationship stories, I expected to find some secret formula.

A perfect response time. A magical texting frequency. A scientifically optimized number of emojis. Instead, the data kept pointing toward something much less exciting and much more important.

Communication.

The data revealed something surprisingly simple: When relationships struggled, the most common advice wasn’t “play hard to get,” “make them jealous,” or even “move on.” It was: Talk. Communicate. Because healthy relationships aren’t built on clever strategies. They’re built on consistency, honesty, and effort.

What surprised me even more was that people rarely described themselves as angry after a breakup. They described themselves as hurt, broken, and in pain. Maybe that’s why we invent texting rules and dating games. “Pretending not to care feels safer than admitting we do”.

But every chart in this investigation pointed to the same conclusion: Connection doesn’t need mystery. It doesn’t need mind games. It needs two people willing to invest.

Because eventually, every relationship becomes a balance sheet … and when one person keeps depositing effort while the other keeps making withdrawals, bankruptcy is only a matter of time.

If turning heartbreak into a dataset taught me anything, it’s this:

The healthiest relationships aren’t the ones where nobody gets hurt. They’re the ones where both people care enough to talk before the hurt becomes permanent.

Ms. DataByte Signing off… The most painful datasets tell the most honest stories.

I am Leaking My EX-Boyfriend’s Chats to Show How Not to Text. was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.

I want to tell you about the most demoralising week I’ve had in product development in a while.

I’d built a working full-stack app using one of the popular AI builders. Frontend, backend, database, the whole thing. It looked good. It worked in the preview. I showed it to three people who said they’d pay for it. I was ready.

Then I tried to deploy it.

Six days later, I was still debugging environment variables, reading Supabase RLS documentation I didn’t understand, and watching CI builds fail for reasons that felt completely disconnected from anything in the code I’d actually reviewed.

The AI that built everything could not help me with any of it.

Here’s what the demos don’t show you: the building part is genuinely fast now. By 2026, 41% of all code globally is AI-generated, and tools for spinning up applications have gotten remarkably good. You can go from zero to a working demo in hours. That’s real.

But then there’s a wall.

It’s not a wall most tools warn you about. You find it when you try to move from “this works in the preview” to “this is running in production.” Suddenly you need a Dockerfile. You need environment variable handling that actually works across staging and production. You need a CI/CD pipeline that doesn’t break when you push to main. You need someone, human or machine who understands how Kubernetes orchestrates your containers.

The AI builder that wrote your code? It was not designed for this part. And you feel that gap immediately.

The developer community has started calling this the “deployment wall”, the moment infrastructure abstraction breaks down and you realise you need either a different tool or an actual DevOps engineer. I hit it hard.

Before I went through this, I genuinely didn’t have a clear mental model of everything that sits between “working code” and “production deployment.” I do now:

• Dockerfile — so your app runs consistently in any environment, not just your laptop
• docker-compose — so the app, database, and services start together correctly
• GitHub Actions workflow — automated build, test, and deploy pipeline that runs on every push
• Kubernetes configuration — orchestration layer for scaling, health monitoring, service routing
• Helm charts — package management for Kubernetes deployments
• Health checks — endpoints that tell your infrastructure whether the app is actually running
• Environment separation — staging and production configured separately so you can test without breaking live

None of these are optional in a real production deployment. Every single one of them falls outside the scope of most AI builders.

After my experience, I started asking around about what this actually costs when you hire it out.

Freelance DevOps consultants charge $75–$200 per hour. A proper production setup, containerisation, CI/CD pipeline, Kubernetes config, environment management takes a competent engineer 3–5 days. That’s your number. And this isn’t a one-time cost: infrastructure needs maintenance, security updates, scaling decisions over time.

For a bootstrapped founder, this math is rough. For a non-technical founder who assumed the AI builder handled this, it can be genuinely shocking.

When I went looking for what I wished I’d had at the start, the gap in the market was pretty obvious: most AI builders generate application code. They were designed to solve the coding problem. Deployment is a different problem that they haven’t attempted.

There are a few platforms trying to close this. The one I found most interesting was 8080.ai, it runs a multi-agent system with an actual DevOps agent, so Dockerfiles, Kubernetes config, Helm charts, and GitHub Actions workflows come out of the build process alongside the application code. Their framing is “production architecture from day one” not something you configure afterward, but something that’s generated as part of the build.

I haven’t used it for a full project yet, but the architectural decision makes sense to me. If you’re going to automate the engineering process, stopping at the application layer and leaving deployment as a manual problem feels like an incomplete solution.

Before you pick an AI builder for your next project, I’d ask one question: what does this platform actually hand you at the end, and what do you still have to figure out yourself?

The answer determines whether your timeline is hours or weeks.

Research shows that getting from 0% to 90% of an app is easy with vibe coding, it’s the final 10% (authentication, deployment, edge cases) where things get genuinely hard. That last stretch is where most of the time and cost lives.

Vibes, as it turns out, don’t scale to production by themselves.

If you’ve hit the deployment wall yourself, I’d love to hear how you got past it. Leave a comment or reach out.

Vibe Coding Got Me to the Demo. Then I Spent Two Weeks Trying to Ship It. was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.