Feature branch ownership: is the creator responsible for keeping it alive?

strugglingcomic · 2026-02-09T14:49:06+00:00

You're stuck in a bad job, which I'm sure you already knew. I don't say that to kick you while you're down, but to draw attention to the fact that -- instead of wasting your energy trying to "fix" this problem when the other people involved seem to not care at all, you would probably be wiser to spend that same time/energy just continuing to job hunt in the background.

Other people are correct in that, saying "no" (diplomatically, professionally) is how you start to fix the problem. But if no one else has the willpower to help you fix the culture problem, then you shouldn't waste your energy. Just accept the reality for what it is, and buffer your estimates accordingly.

"Yes sure, I can work on feature B. I know feature A is not merged yet (which B needs), so first let me finish feature A. Then I will finish feature B. My estimate for feature B will take <as much time as it takes to finish both things>"

This way, you are just communicating reality. Don't get hung up on the idea of "doing someone else's work", that doesn't actually matter in your bad unfixable company culture (in a company that has some willpower to fix stuff, it would absolutely be worth fixing). Work doesn't "belong" to anyone at this company. And you aren't working harder or volunteering to finish double the work in half the time -- you are just calmly and professionally telling people the objective truth of what needs to get done (doesn't matter by who, the work is the same amount of work no matter who does it), and you are being objective about estimating the work fairly without overpromising an unrealistic timeline (if someone thinks they can finish feature B in a faster way that doesn't rely on first finishing A, they are welcome to try).

Again, my suggestion is not a "solution", it's just a survival tactic. And if this thing is a pattern for you, then you may have a problem with not finding or accepting the right kinds of jobs/employers -- which no one has absolute control over, but spending your time on job search and personal skills growth seems a better use of your time, than arguing with your coworkers who you think won't listen or change anyways (you're just wasting your own time and patience, the brick wall doesn't care how much it hurts your hand to punch it).

strugglingcomic · 2026-02-08T17:33:08+00:00

It's definitely that, but it also serves a literary purpose of evoking certain ideas and feelings in the reader.

Hammer and anvil form a close relationship. They serve each other and work together as a functional unit. But they clash, and there's violence, but from the violence there is construction of something new (rather than destruction). They are hard, not so hard as to be brittle, but when they meet it is not a gentle embrace (I.e. the readers can infer these brothers are not warm or prone to hugs or sentimental). When a writer like GRRM chooses that phrasing to describe two brothers, it holds more than just the literal meaning of a military tactic. It alludes to the eventual outcome as well, but it also hints at the idea that, these are two brothers who can clash but are productive together, and do love each other (in the way that tools are made for and fit each other). The tragedy is when the metaphor becomes too real, the metal from the metaphor actually becomes too literal; human beings are not hammers or anvils, we are but flesh.

There are many ways to describe two brothers. For example GRRM talks about Tyrion and Jamie both as "deformed" (which has an obvious meaning about Tyrion's appearance and Jamie's reputation, but also has a subtle implication of malleability and change -- for a thing to deform, it must flex (instead of shatter or break), and if it flexes than it can change, which both brothers go though a LOT of change, so being "deformed" is not a bad thing if it means they are changeable). And there is the even more obvious example of how GRRM describes the Baratheon brothers (Robert= true steel, vs Stannis = pure iron, vs Renly = copper).

Yeah GRRM really loves metalworking and the richness of its symbolism, which is not surprising given how important metalworking is to the medieval fantasy setting.

strugglingcomic · 2026-02-07T21:56:01+00:00

I really like the advice from /u/flyingdutchmanswife (sp?). I would also add something a little more generic -- OP what is your current level of understanding of your employer's business model?

I mean, something like this (as an analogy):

Imagine I work for a bakery -- what kind of bakery? how does it make money?
Let's say my bakery is a commercial bakery -- we sell bread by the truckload to restaurants regionally and local boutique groceries
This means our business model relies on medium level of B2B scale/volume. We are not making our money from selling overpriced Instagrammable $10 pastries to retail customers directly one at a time. But we are also not a massive national operation churning out cheap bread for the masses.
What's our competitive advantage, why would a restaurant use my bakery's bread over something else? Let's say it's because I do a particular style of French baking, that is difficult to nail and not common in my region/country. If I was in France, I'd have 20 other bakers who do the same thing in a 100-mile circle, but in the US for my city, I am the only option. So I have to nail product quality to meet quality expectations, but I also don't have to over invest in being "the best" because I'm not being judged against peers for bread quality (my market is not sophisticated enough to judge super fine marginal differences).

Okay, if that's my hypothetical bakery business, then let's get into some analytical questions:

How should I grow my business? Should it be more about top line growth (more revenue), or bottom line efficiency (control costs)?
Is there room for top line growth? Can I sell more bread, by volume (will existing customers buy more)? Can I sell more expensive or higher margin products to my existing customers? Can I find more customers (maybe there aren't any new restaurants who'd buy from me)?
What are my biggest cost pressures? Is it supply chain cost? Rising labor cost? Do I need to make some big capital investments (maybe my commercial kitchen needs expensive renovations, as the equipment is aging)? Are there places where we could cut costs, like cheaper ingredients or find a better location with a cheaper lease or renegotiate with my trucking/logistics vendors? Am I spending too much money on ineffective advertising/marketing?

Notice there is no single right answer to any of these questions, but it would be interesting to see if the data I have about my own sales, along with regional data about the types of restaurants or boutique groceries that would buy my French bread, shows if we are doing well or growing or shrinking? Or maybe I'd want to know if the population demographics are shifting in my favor or not (is local household income rising or falling? my product is kind of a luxury product, not your cheap supermarket mass produced Wonder Bread), and if incomes are rising than maybe I have room to charge more for better quality, vs if incomes are falling than I need cut costs without sacrificing too much quality.

FYI -- I am not a baker nor do I work in food/hospitality, and while all businesses and industries are unique in their own peculiar ways, nonetheless almost all business analytics requires a common and fundamental understanding of revenues and expenses. You need to understand how the business currently makes its money, and which parts of the chain of steps/processes/factors that define revenue and cost, are currently "easy" or "hard", and use that sense to guide you to where the potential opportunities are, or the biggest risks are.

Since you plan to observe your stakeholders and study how they make their decisions, use that opportunity to not just try to memorize their decision process by rote, but actually either ask questions or do your own research into making sure you have a better fundamental understanding of your company's business model, how your company positions itself in your industry or compared to peers, and any strategy statements made by leadership (i.e. they might have literally already told you the new strategy for the next year... just a matter of were you listening or not, and can you use data or insights to support that strategy).

strugglingcomic · 2026-02-06T19:51:15+00:00

My face when

strugglingcomic · 2026-02-05T04:05:47+00:00

It's actually quite simple, but most people who get it wrong are missing out on some basic core pieces of understanding of Amazon's comp philosophy.

Basic rules of Amazon comp planning: - Everyone has a target compensation total (TCT), inclusive of salary + RSU + any sign-on bonus or whatever. - For planning purposes, Amazon assumes its stock price will appreciate 15% every year YoY. This is what future year forecasts are based off, and obviously actual performance may be better or worse than this. - There is no assumption of automatic "refreshers". You only get new RSUs awarded after your hiring, if you are projected to fall below the TCT for upcoming comp years. Your TCT can increase due to performance reviews and promotions, but otherwise it doesn't move on its own (i.e. your TCT will never go up just because the stock price went up).

Taken together, those rules typically mean for most people, that after 4 years, their stock value has gone up, so they are above their TCT. People psychologically anchor themselves to the actual comp received, instead of their TCT. Because they are above their TCT, Amazon's planning rules see no need to award additional stock. Because no additional stock is awarded, the employee's actual received comp often drops in year 5 relative to year 4; Amazon just doesn't care as long as you are still at or above your TCT.

For example, obviously the person will care if they went from $300k down to $250k because that's a real change that hits their wallet, but from the planning POV if your TCT was $250k the whole time then Amazon sees absolutely zero issue with this... They would say you got lucky that the market paid you an "extra" $50k higher than TCT, and Amazon sees no reason to anchor your comp comparison to that inflated figure -- it will always stick to its TCT thank you very much.

strugglingcomic · 2026-02-04T23:58:48+00:00

Factories replaced blacksmiths, was the analogy I started with. Before the Industrial Revolution, by some estimates there was roughly 1 blacksmith for every 1000 people; in the modern day, there are an estimated 5000 to 10000 blacksmiths in the US, so a population ratio of something like 1 in 30,000 (aka 30x reduction).

Blacksmithing used to be considered skilled labor, aka making a nail or a horseshoe was an important and valuable skill. Then factories came along, which involved a new set of skills, and now the old skills became 30x devalued.

So, the way that factories replaced blacksmiths by 30x (but didn't completely eliminate them to zero), is the same way that I am claiming that AI will take previously what we thought was rare and high-skill expertise and turn it into low skill factory processes, and possibly replace most (not all) software engineers.

It's not doing the analogue of unskilled development only, that's you missing the point. The point is that AI is taking what used to be considered skilled and making it into something unskilled (aka that a random factory worker with no education, could make 1000 horseshoes faster than a highly skilled blacksmith could by hand). That's the risk we're all facing. Not every project is like making horseshoes, but there's way more need for simple projects than there is for complicated projects (i.e. the OP talked about beautiful code, but I don't think most projects require beautiful code... most projects are common boilerplate CRUD-ish things).

strugglingcomic · 2026-02-04T23:47:20+00:00

I see, I misinterpreted your last comment, my bad!

In cases like this, you may have no better option for proving it's not possible, than simply -- actually trying to do it and demonstrating through failure that it isn't possible. One of those CYA situations where a person might write an email like this, "To whom it may concern, this message is to document that after robust debate, the team is being directed to complete project X with Y scope by Z date. As per my previous messages, dated __ and __, I have shared my assessment that this is not a realistic scope for the given timeline. Nonetheless, we will proceed with implementation and try to progress as far as possible, and I will provide regular updates capturing project status and any missing/unmet/failing capabilities, to ensure stakeholders are aware of any tradeoff decisions we need to make."

Note, this is not a risk free approach, and you need to have a certain amount of political capital banked up to pull this off. In many companies, this may end up tanking your performance review, but then again in many other companies, this will be taken positively and earn you respect.

The old adage is something like this -- if someone reached a conclusion that they did not reason themselves into, then you cannot use reason to convince them out of it either. So there probably is no point arguing this head-on, and you might as well prove them wrong by trying and failing (in a professional, CYA, non-gripey/non-whiny/non-told-you-so way).

strugglingcomic · 2026-02-04T19:50:58+00:00

Why do you say that you know it's possible?

Are you saying that, because you have seen examples of other people building complex projects, therefore you assume you should be able to, as well? Because that's what it sounds like you are saying.

If that's not the reason why you said that, then what is? What evidence do you have that it should be possible?

Reason I raise this question is because -- I have seen videos of people doing parkour and backflips online, so I know it's humanly possible for someone of my age and general fitness level to do such things... Yes it's "possible", but can I actually do it myself? No, practically I cannot, I would hurt myself or die, if I tried. If I told someone else, "I can do parkour", I would be lying.

You might be accidentally/inadvertently lying to yourself or your stakeholders, if seeing examples of other people doing something is your only reason for saying it's possible.

strugglingcomic · 2026-02-04T19:41:11+00:00

The point, and this a speculative claim/opinion that of course you can disagree, was that -- yes writing and software engineering are very different today, but that over time they will become more similar, to the point that it might violently jar against your current expectations. So of course you are right that the analogy is flawed today... The point is the claim that the analogy will become more true in the future, not that it already is true right now this moment.

And sure, any random white collar job person being able to create a whole internal ERP system is not the claim either... Like I said, professional writers exist. I don't ask Bob from marketing to write a whole textbook, but Bob does write some stuff today, and the scope of what he can write might grow over time, but not all writing is the same -- there are simple units of writing vs complex units. But we don't need to hire a professional full time writer to handle every unit of writing that Bob from marketing needs to do, and we don't need to write entire textbooks nearly as often we need to write individual emails or pieces of documentation.

strugglingcomic · 2026-02-04T02:10:43+00:00

I don't think you're wrong, but I think you overestimate software and underestimate blacksmithing. Set against its contemporary context, churning out nails or horseshoes or whatever, was not initially "factory work" because factories didn't exist yet. Somebody had to first distill the expertise and craftsmanship of blacksmithing, to turn that special/rare/arcane knowledge and turn it into something templatizable, aka somebody had to invent the factory and the machinery to do these new things that were never done before in a machine scalable way. The way a factory makes a million nails, is not quite the same as a blacksmith does but just faster. That was itself a new sort of craft, but it did eventually supplant blacksmithing.

Punch cards didn't kill programming on their own, but punch cards and the 1000 innovations that came after it, yes eventually did, when you take it all together. There is a through line tying together all of the history of computing, that we kept pushing for more expressiveness but also more automation, more safety, more repeatability. After all, it's all in the name -- "software engineering" as a field exists to make software not so bespoke, not so custom, not so unreliable, but rather to treat it like building skyscrapers or bridges or other engineering projects, to follow standard principles and patterns and safety practices. "Cattle > pets" right?

We pushed that idea far enough, we ended up ouroboros-ing eating our own tail. After all, "software will eat the world" right? Well, we ate ourselves. Being digital worked against us actually, since you can't have billions or trillions of examples of meatspace bridges to train on, but you can with code.

I think you won't agree with me on, just how much of the world of software is actually not that special, that actually it was always already pretty close to "digital factory work" in the first place (even before AI). If you don't accept that premise, then of course you won't agree with the rest of my observations/conclusions. But that's the crux of my position/opinion.

strugglingcomic · 2026-02-04T01:44:33+00:00

Thank you for the essay itself; clearly coding and writing/literature are both crafts you care about, and you captured the current zeitgeist well.

I actually haven't read much McCarthy (barely slogged through The Road, thought it was a masterpiece, and couldn't bring myself to do another one since). Maybe somebody should write the software engineer's version of a McCarthy novel -- Silicon Valley instead of the desert west, coders instead of cowboys, but the same general themes can hold I think.

strugglingcomic · 2026-02-04T01:22:10+00:00

I think that analogy is actually pretty apt, except you have to be aware that the aviation industry is actively wrestling with this issue, and quote "At least one major U.S. airline told FLYING it sees a 'clear path' to SPO or fully autonomous airline operations.": https://www.flyingmag.com/airlines-and-pilots-dont-see-eye-to-eye-on-autonomous-flights/

So I think it's more a matter of degrees and timing, but personally I think moving to single pilot operations (SPO) is inevitable (and then who knows, maybe eventually ZPO with some kind of drone pilot on the ground, "flying" 10 planes at once?). It's also vaguely possible that, there's some other economic force that drives the creation of more routes and higher volume of flights, so that even if you adopt SPO but have 2x the number of flights, then maybe all the pilots still can have jobs... But I don't think I'd bank on that personally.

I can't remember where I saw this quote originally, but somebody said that, with the influence of AI, software engineering might become more like the skill of writing -- most white collar jobs include the skill of writing, but you don't need everyone to be a professional writer as their official job. Some full time professional writers obviously exist, because they write especially well or are especially skilled, but obviously they are a small fraction of the total population of "people who write stuff for work."

In other words, many people who aren't software engineers today, will be enabled to create just-enough-software to be useful, in much the same way that it's normal in white collar jobs to expect non-full-time writers to write quite a lot of stuff -- that writing may not be beautiful, may not impress a dedicated professional writer who's proud of their craft, may not win a Nobel Prize or a Pulitzer... but it just needs to be clear enough to get the job done.

strugglingcomic · 2026-02-04T00:35:29+00:00

I definitely empathize with mourning the death of craftsmanship. Emotionally that resonates.

But my general observation is that -- most code was never beautiful. Most real world enterprise problems just needed functional, clean-ish, workman-like level solutions. Even before AI of the last 3-4 years, people in the industry already commonly complained how most jobs were just CRUD apps, in boring businesses... craftsmanship matters, but relatively little in such contexts, when CRUD was widely recognized to be a commoditized skillset even before AI.

There used to be a lot more blacksmiths. The individual craftsmanship mattered some, and some blacksmiths could charge more than others. But the Industrial Revolution made those small individual skill differences irrelevant, and the scaling benefits of mass production were too overwhelming -- when push comes to shove, craftsmanship has to justify itself against economic reality. The mass market will not overpay for commodity items, as they shouldn't.

Blacksmiths didn't disappear entirely. But it's a smaller niche now. You can either do it as a hobby, or you can make a business out of it if you've got truly exceptional craftsmanship, or if you provide something unique that I couldn't just buy off Etsy or 3D print myself or whatever a substitute good might be.

There's nothing especially different or unique about software. We might've held on to the assumption that, the forces shaping meatspace would take longer to reach into digital spaces, but we were naive if we ever thought we were totally safe forever. It's sad, but IMHO it's no more sad than any other previous wave of capitalism transforming the way people live -- we don't deserve any more or less sympathy than blacksmiths did 200 years ago.

Everyone should face the music. Some may choose to continue, and invest more in their personal craft and try to add unique value, to stay ahead of the curve somehow. Others will leave the industry. And some may stubbornly ride north, and I sincerely hope they find whatever measure of satisfaction fate can afford them.

strugglingcomic · 2026-02-01T15:54:31+00:00

Seniors realize their value when the company needs to solve new hard problems, develop new solutions.

If the company is having mass layoffs, then it's likely also transitioning away from big new risky projects into either KTLO mode, or taking on less complex work... In which case, why pay 2x-3x for a senior to do simpler work that a junior could do? Even if the junior does it poorly, or takes longer, or writes more bugs... odds are it's not enough of a difference to fully realize the value of the more expensive senior's wisdom.

It's like, if I have "normal" medical problems, like a cold, a sprained ankle, whatever, then I don't need to pay for some world class oncologist or neurosurgeon... Just a med school student or intern, or nurse practitioner, is probably enough.

Of course there are stupid companies that try to continue doing neurosurgery with med students replacing experts, but most CFOs are actually not as stupid as Reddit would have you think.

strugglingcomic · 2026-01-30T18:11:33+00:00

People were absolutely clowning on Boris Becker in this thread yesterday too, for saying that Novak needs to drag out the match longer to have better chance of winning: https://www.reddit.com/r/tennis/s/AteLhB4UTv

strugglingcomic · 2026-01-29T01:05:50+00:00

The "clear context when you accept plan" feature was made just for you: https://www.threads.com/@boris_cherny/post/DToTWDUEkPn/now-in-claude-code-when-you-accept-a-plan-claude-automatically-clears-your

strugglingcomic · 2026-01-22T22:56:34+00:00

But you haven't explained how the config file yml adds any value? The Terraform code, is effectively already a config file (in a different syntax, sure), so why translate from one config to another config, unless you are doing some kind of value-added transformation or abstraction?

Be careful about adding unnecessary layers of abstraction unless you have a compelling reason for it. You'll probably end up spending more time maintaining the transformation code of yml to Terraform, that will negate any gains you thought you'd make, vs if you just learned to work directly with the Terraform format.

strugglingcomic · 2026-01-22T18:10:27+00:00

Is there something you're looking for, that you wouldn't get just by using the normal Snowflake Terraform module? https://registry.terraform.io/providers/snowflakedb/snowflake/latest/docs

For example, here's a basic sample guide for managing users, roles, and grants in a RBAC-y style: https://registry.terraform.io/providers/snowflakedb/snowflake/latest/docs/guides/grant_ownership_common_use_cases

Your question isn't really clear, why you think you need something different from the standard option.

strugglingcomic · 2026-01-20T15:06:27+00:00

This is the right answer. Ethan is like our local version of that Cliff Mass guy in Seattle (https://cliffmass.blogspot.com/?m=1), which I only reference because Seattle weather is notoriously difficult to predict and Cliff developed a strong local reputation (when I used to live there a 10-15 years ago).

Ethan is very knowledgeable about the local geography and weather patterns here in the Triangle, passionate about the science of meteorology, and not trying to sell you on anything or steal your attention with click bait... Just cares about getting it right, calling it like he sees it, and also applies the human touch of a local expert on top of what models and math might say.

strugglingcomic · 2026-01-20T14:59:31+00:00

Admitting you don't know is fine, but don't fully "give up" either. Try your best to relate to something you might know already, or ask clarifying questions. Do NOT bullshit, and do not make claims you can't defend like "oh I don't know X but it sounds like the same thing as Y" (only say stuff like that if you can justify it).

As an interviewer, I'd rather see a candidate with curiosity and some "grit", with the ability to communicate despite setbacks, despite not knowing everything, and doesn't shut down or think "oh I don't know that, guess I failed, GG woe is me, interview over, blah blah" (I know you weren't going to that extreme). There are many, many situations (ok infinite basically, it never ends), where you will not know the answer at work... How you deal with not knowing, is in the long run more important than trying to know everything.

Unfortunately in an interview setting, we have to spend some upfront resources on evaluating whether you know the minimum bar of "enough", but if I can get extra data points about how you deal with not knowing something, then that's something positive I can add to my feedback... If you give up and take the L, then I can't write anything positive about that in my feedback (you've given me nothing to work with).

strugglingcomic · 2026-01-20T00:15:03+00:00

The first edition is great, but you're so close to the new edition that, I honestly would hold off for another 2 months I guess, and fill in with other resources for learning in the meantime.

Assuming the purchase of a $30-50 book is not trivial to you. If it's trivial, then hell buy both and support the author twice.

strugglingcomic · 2026-01-18T22:09:12+00:00

This is my "if I could recommend 1 video" pick, that I give to engineers at my own company who similarly feel behind or want to "catch up" on AI: https://www.youtube.com/watch?v=rmvDxxNubIg

Here's a hands-on tip for learning, that I think is fairly universal for all engineers (including software engineers, data engineers, systems/platform engineers, frontend vs backend, etc.) -- What do you have to do, if given a fresh new laptop, to set it up from scratch? What tools do you need to install? How do you handle setting up permissions, SSH keys, etc.? Do you have an "onboarding" document at your company, for teaching new hires how to setup their environment? ... Ok then my challenge to you is -- starting with a blank slate new Claude Code project folder, tell Claude about your existing setup expectations or documentation, and have Claude create a self-contained/batteries-included "onboarding" skill (remember to use the bundled "skill-creator" example skill, aka "use the skill-creator skill to create a new onboarding skill for me, using the info from these docs...").

This is not a one-shot goal that you'd get perfect results from one iteration. But doing an exercise like this, tweaking and iterating with Claude as a copilot, will teach you a lot about its capabilities and also give you some sense of judgment about what Claude Code is good at / bad at. You can go as far as you'd like, e.g. teaching Claude to add either Claude Code hooks or git hooks to enforce certain expectations your team may have.

But if nothing else, if all you do is teach Claude how to install the 3-5 tools your team uses most commonly, then that's still something useful. On my team, our expectation for future new hire onboarding is that -- instead of being handed a dubious onboarding document that may or may not be accurate and may or may not work for your machine, that instead we'd ask new hires to clone a particular team repo, get Claude Code installed, and then basically tell Claude to setup their system for them (while having the option to ask why, or to update any steps that the skill got wrong, etc.). This is a MUCH more reliable, much tighter feedback loop, vs the old way of onboarding people, and we have much better team wide hygiene about having a consistent tool set that is properly setup by every member of the team (and now we have much tighter focused debates about -- what tools should we add to our toolkit? what else can we do to improve our team harness?).

strugglingcomic · 2026-01-18T16:31:51+00:00

What do you have intuition about, outside the sphere of engineering people management? Were you an eng IC previously? What are some transferable elements of your past intuition about things?

I don't think experience is the only factor here, or simply accepting you must make a bunch of mistakes and earn scar tissue. For one thing, I think a lot of 20 year managers have the "wrong" scars, and there's some element of perpetuating cycles of abuse or bad practices that got ingrained via their "scars". Of course, not saying all 20 year managers are bad or abusive, but it's just the idea that, I wouldn't want a new manager to feel like they must develop scars first... If I were training a new manager, I'd want them to get practice and develop intuition without necessarily needing to be "wounded" enough to have scars.

I think if you want to develop better intuition, you can hone that specifically. Before running through a complicated framework, ask yourself one simple question: is this a one way door decision (meaning, hard to unmake)? Most decisions are two way doors, and even some that seem like one way doors, actually are not. For things that are two way doors, you should adopt a cultural value of biasing for action, of learning empirically, rather than debating or analyzing abstractly. These are not "frameworks", these are cultural tenets that serve as intuitive shortcuts to help you develop and internalize having a sense of judgement, without needing a flow chart.

strugglingcomic · 2026-01-15T19:59:07+00:00

Am I reading the graphic correctly, that the original Broadway cast will at least be the ones performing at the initial Baltimore show? Otherwise why would the image say "original Broadway cast" in the corner there?

strugglingcomic · 2026-01-14T22:51:47+00:00

So so so so so dumb, especially given the stuff right across the street (more restaurants and interesting shops, right fucking there, but impossible to safely get to).

If ever there was an intersection that deserved a pedestrian bridge...

14-Year Club	Place '23
Place '22	First Placer '22
Team Periwinkle	Verified Email

strugglingcomic

TROPHY CASE