Are Ya Contributing Son? Open Source Dev Surrounded by Failed CI Checks

Level 1: Red X Report Card

Imagine your dad walks into your room while you’re working on a school project and asks, “Are you getting it right, kiddo?” Now, picture that on your desk in front of you is your project or test paper covered in big red X marks from the teacher – meaning a lot of things are wrong. You’ve tried a few times, but each time you still got many answers wrong (hence all those red Xs). You’re sitting back looking frustrated because nothing you’ve done so far has gotten a passing mark. That’s basically what’s happening in this meme, but in a coding world. The dad is asking if the child is “contributing” (doing well in his coding work, kind of like asking if he’s winning or succeeding). But the child’s computer screen is showing a bunch of red X symbols, which are like the computer’s way of marking “Nope, that didn’t work” on each attempt. It’s as if the kid’s report card is full of failing grades and Dad just walked in at the wrong time. The reason this is funny is the big contrast: the father is all hopeful and upbeat, thinking his son must be doing great, while the son is actually surrounded by signs of failure (those red Xs) and probably feels pretty defeated. It’s a bit like a parent asking, “Did you win your game?” when the screen clearly says “Game Over” again and again. That mix of encouragement and obvious struggle makes it humorous in a relatable way – we’ve all had someone cheerfully ask us how something is going when, in reality, it’s going badly!

Level 2: Broken Build Blues

Alright, let’s unpack what’s going on here in simpler terms. This meme takes a well-known internet comic format – the “Are ya winning, son?” – and gives it a programmer spin. On the left, we have a dad peeking into his son’s room, asking *“Are ya contributin’, son?”* This is dad’s way of saying: “Are you doing something productive with your coding? Maybe contributing to a project?” It’s like a parent checking if you’re doing your homework, but here it’s about coding contributions (potentially to open-source projects or your own work). The funny part is that he’s using the word “contributing” in a very developer-specific way (as in contributing code), which is a bit unusual for a dad – that’s intentional for humor.

Now, on the right side, we see the son – who is a developer – sitting at his desk with headphones on, presumably having been coding for hours. Instead of looking victorious or proud, he’s leaning back in defeat. And why? Because his computer screen (and even the area around him) is plastered with red X marks. These red Xs are universally recognized in software development as “fail” symbols. Specifically, on platforms like GitHub, when you make a commit (which is basically saving a batch of your code changes in a version control system like Git), there are automated processes that run to check your code. These processes are part of something called Continuous Integration (CI). CI systems automatically build your code and run tests on it every time you push your changes to the server, to make sure everything works.

If everything passes, you get a nice green checkmark (✓) or a green badge saying “✔ All checks passed”. But if any of those checks fail – say your code doesn’t compile, or it breaks a test, or even if your code style is wrong – you get a red X (×) indicating a failure. In this meme, everywhere the poor kid looks, he’s seeing those red Xs. The meme even shows a snippet from a GitHub interface: it says “authored 6 hours ago · × 1 / 2” next to a commit hash (like 728ffdb). This likely means that for a commit he made 6 hours ago, 1 out of 2 checks failed (so overall it’s marked with a ×). Below that, another commit from 4 hours ago (0e92dbb) is also marked with an × (failure). Essentially, he’s tried multiple times over the last several hours, and each time some automated check has failed. Build failure after build failure – that’s why we call it the “broken build blues.”

Let’s clarify some terms:

• Commit: A commit is like taking a snapshot of your code at a certain point with some changes. It’s a way to record changes in Git, which is a popular version control system developers use to track code history. Commits are identified by those funny-looking hashes (e.g., 728ffdb) you see in the meme. Think of a commit hash like a unique ID for that set of changes.
• Pull Request (PR): This is a way to propose your changes to be merged (added) into the main codebase, especially on platforms like GitHub. When you open a PR, other developers can see your commits and the changes you’ve made. It’s called a “pull” request because you’re requesting that your changes be pulled into the project.
• Continuous Integration (CI): This is an automated system that runs every time you push commits, especially on a PR. It typically compiles the code, runs tests, and maybe checks code style or other quality guidelines. The idea is to catch errors early. In practice, it means every time you make a change, a robot is going to double-check your work.
• Red X / Failed Check: When CI runs those tests and something fails, the result is a red X status on your commit/PR. For example, if 100 tests run and even 1 test fails, CI will report a failure (often with a red X icon). You then have to fix whatever caused that failure and commit again. In our meme, those red X icons scattered around mean multiple things have failed across multiple tries.
• Code Review: In addition to automated tests, a human (usually a teammate or project maintainer) will look at your code changes – this is called code review. They might leave comments or suggest improvements. If they are not satisfied, they’ll mark the review as “Changes requested” (on GitHub, this might show up as a red icon or just a note that changes are needed). Essentially, it’s another form of “not done yet.” In many projects, a PR needs at least one approval from a reviewer and all CI checks green before it can be merged. That’s why the meme description mentions “code-review blocks” along with the CI failures. The combination can feel like a double whammy: you got the code working only to have a person say it needs more work, or vice versa.

Now, put yourself in the shoes of the developer (the son). He’s been trying to contribute code for 6 hours. Every time he thinks he’s fixed the issue and pushes his commit, something else pops up as a failure. It’s like a whack-a-mole game: fix one bug, another pops out. 🤦 The background of the meme covered in red Xs is a dramatization – it’s saying “failure, failure everywhere!” Perhaps his tests keep failing or the build system keeps throwing errors. This is super common in real dev life: maybe you forgot to update a test after changing code, or you wrote code on Windows and the CI server is Linux so something behaves differently, or maybe the coding standards require a certain format and the automated lint check finds a comma out of place. Each time, the CI system stops with an “❌ Error!” message, and you have to go back, fix, and push again.

While the developer is going through this frustrating cycle, the dad just pops in cheerfully with his coffee, essentially asking “Hey, how’s it going? Making great contributions, champ?” This contrast is the joke. The parental expectations vs. CI reality is front and center. Dad expects to hear “Yes! I’m doing great, writing awesome code!” – similar to a parent asking a gamer kid if they’re winning the game. But the reality is the kid isn’t “winning” at all; he’s stuck in a loop of failures and hasn’t contributed anything yet except a trail of broken builds.

For a junior developer or someone new to this, it’s important to know: this scenario is very normal when working with professional tools. The first time you encounter a continuous integration pipeline, it can be brutal. You might think “My code runs, why is everything failing?” Then you learn about all the automated checks in place: the test suite (which might be huge), code style linters (tools that enforce how code should be formatted or written), security scans, build steps for multiple environments, etc. Large projects, especially open-source ones, often have strict CI requirements. They do this so that no broken code gets into the main project – it keeps the software quality high. But for someone trying to contribute, it means your contribution has to be perfect (or at least meet all the project’s criteria) before it’s accepted. That can take many tries.

This meme resonates with developers because we’ve all felt the sting of those red Xs. It’s basically a DeveloperHumor inside joke. The tags like CodeReviewPainPoints and BuildFailures tell us the theme: it’s about the pain of code reviews and build failures. Seeing a “wall of red Xs” on your PR is almost like getting a report card full of bad grades. And that ties into the dad/son setup perfectly – like a dad asking about your report card when it’s all F’s (ouch). The difference is, in coding, those “bad marks” can eventually be fixed by iterating and learning. In fact, experienced devs will joke about how many CI fails they went through before everything finally passed. It’s a bit of a badge of honor after the fact, but during the process it can be demoralizing.

The good news is, usually after enough debugging and maybe asking for help, you turn those Xs into checkmarks and then you are “contributin’, son.” But the meme humorously freezes that painful intermediate stage – when nothing is working and an outsider innocently asks about success. VersionControlHumor shines through here because only someone who’s been in that situation with Git, PRs, and CI would fully appreciate why it’s funny and not just tragic. (It’s okay, we laugh so we don’t cry! 😅) And if you haven’t experienced this yet as a new developer, don’t worry – you will. It’s practically a universal developer experience to have a day where every commit is a new red X. When it happens, you can remember this meme and know you’re not alone. It’s just part of the journey of making quality software.

Level 3: Pull Request Purgatory

On the surface, this meme comically pits parental expectations against the harsh reality of modern software development pipelines. The left side shows the classic father figure (fedora, coffee mug in hand) enthusiastically asking “ARE YA CONTRIBUTIN’ SON?” – a techie twist on the legendary “Are ya winning, son?” meme. It’s a playful nod to the idea that writing code (especially open-source contributions) is the programmer’s version of “winning.” But the right side tells a different story: the headphone-clad developer (the son) is slouched back, faced with a screen flooded by red X icons. Each ominous red X is the mark of a failed attempt – specifically, failed CI status checks on his commits. In the snippet above his head, we see a GitHub-style commit log: commit hashes like 728ffdb and 0e92dbb with red × symbols and a note “× 1 / 2” (suggesting one of two checks failed). To seasoned engineers, this scene is all too familiar: it’s the dreaded wall of failing builds and blocked pull requests. The humor (tinged with pain) comes from that exact juxtaposition: an eager outsider thinking any code you write is an awesome contribution, versus the reality that every commit must run a gauntlet of automated tests and reviews – and here, they’re all failing miserably.

This “Pull Request purgatory” is a rite of passage in professional development teams and open-source projects alike. The father’s question “Are ya contributin’?” implies “Are you being productive, making valuable code contributions?” He likely imagines his son heroically writing code admired by the community. But the son’s reality is that none of his contributions are getting through. Every push to the repository triggers a continuous integration (CI) pipeline (think GitHub Actions, Jenkins, or Travis CI) and returns with a big red X – meaning something broke. Maybe a unit test failed, maybe the code didn’t compile on the CI server, or perhaps a linter found a semicolon out of place. Whatever the reasons, the result is the same: no green check marks, no successful builds, and thus nothing to actually contribute (because the project won’t accept broken code). It’s a scenario that encapsulates a core CodeReviewPainPoints in real software teams: before your code can be merged, you must battle both machines and humans.

Let’s break down the elements savvy devs will notice here: First, those commit hashes (728ffdb, 0e92dbb) with red Xs are straight out of a Git hosting interface like GitHub or GitLab. They indicate that the commits in question have failing status checks. Modern workflows often make use of protected branches – you can’t merge your code into main or master until all these checks pass (and until someone reviews your code). So a string of red Xs means the code is essentially stuck in limbo. It’s not getting into the project because either the CI/CD pipeline keeps catching issues, or a reviewer hasn’t approved it. That’s why we call it Pull Request purgatory: the code is neither accepted nor outright rejected – it’s waiting for the developer (the son) to fix all the problems and earn those green ✓ check marks.

Notice the timeline: “authored 6 hours ago… 4 hours ago”. This poor developer has been at it for hours. 😩 Perhaps he started his day optimistic – “Today I’ll finally contribute that feature/fix!” – only to find himself in an endless loop of commit → push → fail → fix → repeat. The DeveloperExperience_DX portrayed here is almost traumatic in its relatability. Every experienced dev has had that PR that took all day (or days) to get passing. For example, you might push a change and see the tests fail due to an environment difference (“But it worked on my machine!” you cry). Fine – you write a fix. Push again. Now the style checker lints your code and finds a dozen formatting nits (forgot a newline, used tabs instead of spaces – another red X). Fix those, push again. Now the integration test times out… yet another ❌. It becomes a cascade of red Xs. If you’ve ever seen a GitHub PR page scroll with a list of checks and several of them are red, you know the sinking feeling. This meme exaggerates it to a wall of red Xs everywhere, even floating around the developer’s head, visually amplifying that “nothing is working” vibe. Meanwhile, the fedora-wearing dad – perhaps a stand-in for any non-developer or old-school boss – is blissfully unaware of this struggle. He just uses the buzzword “contributin’” as if that’s a simple yes/no question. The senior engineers reading this meme exchange knowing glances: oh, if only Dad knew.

There’s also a meta-joke with the father figure smoking a pipe and holding a coffee mug while using tech lingo. It’s a humorous role reversal – usually, parents don’t grok what their programmer kids do, but here’s a dad proudly inquiring if his son is pushing code to GitHub (maybe imagining his child becoming the next Linux kernel contributor or something). The phrase itself – “Are ya contributin’ son?” – is dripping with irony for those in the know. It echoes how the software industry glorifies contributions (like racking up commits or participating in open source), yet day-to-day coding isn’t glamorous victory at all; it’s methodically fixing one failing test after another. The father’s cheerful tone amplifies how not cheerful the son’s situation is. This is a textbook example of expectations vs. reality in software development: outsiders cheer on the heroic coder, while the coder is fighting a hydra of failing builds.

In crisper technical terms, the meme is highlighting CI/CD pipeline failures gating a pull request (PR). The “× 1/2” suggests partial failure – likely indicating that out of 2 required checks, 1 failed (thus the red X overall). Common checks might include “Build & Unit Tests” and “Lint/Style Check”; failing either yields a red X. So “1/2” might mean one of those did not pass. Each commit listed (with its short hash) shows an overall fail status, meaning the PR as a whole cannot be merged. Many of us have stared at that exact GitHub interface: a list of commits with red or green icons next to them. Seeing a sequence of red, with timestamps hours apart, tells a story: the developer is iterating but hasn’t gotten a green build yet. Add to that the possibility of a code review giving a “Changes requested” (which on GitHub also prevents merging until addressed), and you’ve got the full CodeReview nightmare. The meme scribbles red Xs all around to represent review comments or blockages too – basically every direction the dev looks, there’s something saying “Nope, not good enough yet.”

From a senior developer’s perspective, this meme provokes a chuckle (and maybe a groan) because we’ve all been this kid at one point – sitting with our head in our hands while continuous integration runs for the nth time, wondering if we’ll ever get that sweet green checkmark. It’s a shared pain that’s almost comforting in its universality. The next time someone’s non-tech parent or a higher-up excitedly asks, “Hey, did you finish that feature? Are we shipping it?” we might just picture this meme and think: If only you knew… In reality, being a “contributing” developer often means grinding through a gauntlet of automated tests, build scripts, and picky reviewers. It’s necessary for quality – we appreciate it, we really do – but wow, can it turn a simple coding task into an all-day marathon. The meme captures that marathon at its most absurd: Dad’s proudly checking in on what he thinks is a straightforward success (“My kid commits code, code goes in, hurray!”), while the son is basically locked in CI jail until further notice.