Hack the Chart, Impress the Party: A (Totally Ethical) Guide to GitHub Glory

We’ve all been there—no exceptions, literally all of us. You’re at a party, chatting up a total cutie, the vibes are immaculate, and then she hits you with the: “Show me your GitHub contributions chart.” She wants to see if you’re really about that open-source life.

Panic. You know you are mid at best, when it comes to coding. Your chart is weak and you know it.

You hesitate but show her anyway, hoping she’ll appreciate you for your personality instead. Wrong! She doesn’t care about your personality, dude—only your commits. She takes one look, laughs, and walks away.

Defeated, you grab a pizza on the way home (I’m actually starving writing this—if my Chinese food doesn’t arrive soon, I’m gonna lose it).

Anyway! The responsible thing to do would be to start contributing heavily to open-source projects. This is not that kind of blog though. Here, we like to dabble in the darker arts of IT. Not sure how much educational value this has, but here we go with the disclaimer:

Quick note: This trick works on any gender you’re into. When I say “her” just mentally swap it out for whoever you’re trying to impress. I’m only writing it this way because, that’s who I would personally want to impress.

Intro

I came across a LinkedIn post where someone claimed they landed a $500K developer job—without an interview—just by writing a tool that fakes GitHub contributions. Supposedly, employers actually check these charts and your public code.

Now, I knew this was classic LinkedIn exaggeration, but it still got me thinking… does this actually work? I mean, imagine flexing on your friends with an elite contribution chart—instant jealousy.

Of course, the golden era of half-a-mil, no-interview dev jobs is long gone (RIP), but who knows? Maybe it’ll make a comeback. Or maybe AI will just replace us all before that happens.

I actually like Copilot, but it still cracks me up. If you’re not a programmer, just know that roasting your own code is part of the culture—it’s how we cope, but never roast my code, because I will cry and you will feel bad. We both will.

The Setup

Like most things in life, step one is getting a server to run a small script and a cronjob on. I’m using a local LXC container in my Proxmox, but you can use a Raspberry Pi, an old laptop, or whatever junk you have lying around.

Oh, and obviously, you’ll need a GitHub account—but if you didn’t already have one, you wouldn’t be here.

Preparation

First, you need to install a few packages on your machine. I’m gonna assume you’re using Debian—because it’s my favorite (though I have to admit, Alpine is growing on me fast):

apt update && apt upgrade -y
apt install git -y
apt install curl -y

Adding SSH Keys to Github

There are two great guides from GithHub:

• Generating a new SSH key and adding it to the ssh-agent
• Adding a new SSH key to your GitHub account

ssh-keygen -t ed25519 -C "[email protected]"

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 # <- if that is what you named your key

Then copy the public key, you recognize it by the .pub ending:

cat ~/.ssh/id_ed25519.pub # <- check if that is the name of your key

It happens way more often than it should—people accidentally exposing their private key like it’s no big deal. Don’t be that person.

Once you’ve copied your public key (the one with .pub at the end), add it to your GitHub account by following the steps in “Adding a new SSH key to your GitHub account“.

Check if it worked with:

ssh -T [email protected]

You should see something like:

Hi StasonJatham! You've successfully authenticated, but GitHub does not provide shell access.

Configuring git on your system

This is important for your upcoming contributions to actually count towards your stats, they need to be made by “you”:

git config --global user.name "YourActualGithubUsername"
git config --global user.email "[email protected]"

You’re almost done prepping. Now, you just need to clone one of your repositories. Whether it’s public or private is up to you—just check your GitHub profile settings:

• If you have private contributions enabled, you can commit to a private repo.
• f not, just use a public repo—or go wild and do both.

The Code

Let us test our setup before we continue:

git clone https://github.com/YourActualGithubUser/YOUR_REPO_OF_CHOICE
git add counter.py
git commit -m "add a counter"
git push

Make sure to replace your username and repo in the command—don’t just copy-paste like a bot. If everything went smoothly, you should now have an empty counter.py file sitting in your repository.

Of course, if you’d rather keep things tidy, you can create a brand new repo for this. But either way, this should have worked.

Now the code of the shell script:

#!/bin/bash

# Define the directory where the repository is located
# this is the repo we got earlier from git clone
REPO_DIR="/root/YOUR_REPO_OF_CHOICE"

# random delay to not always commit at exact time
RANDOM_DELAY=$((RANDOM % 20 + 1))
DELAY_IN_SECONDS=$((RANDOM_DELAY * 60))
sleep "$DELAY_IN_SECONDS"

cd "$REPO_DIR" || exit

# get current time and overwrite file
echo "print(\"$(date)\")" > counter.py

# Generate a random string for the commit message
COMMIT_MSG=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 16)

# Stage the changes, commit, and push
git add counter.py > /dev/null 2>&1
git commit -m "$COMMIT_MSG" > /dev/null 2>&1
git push origin master > /dev/null 2>&1

Next, you’ll want to automate this by setting it up as a cronjob:

17 10-20/2 * * * /root/gh_champ.sh

I personally like using crontab.guru to craft more complex cron schedules—it makes life easier.

This one runs at minute 17 past every 2nd hour from 10 through 20, plus a random 1-20 minute delay from our script to keep things looking natural.

And that’s it. Now you just sit back and wait 😁.

Bonus: Cronjob Monitoring

I like keeping an eye on my cronjobs in case they randomly decide to fail. If you want to set up Healthchecks.io for this, check out my blog post.

The final cronjob entry looks like this:

17 10-20/2 * * * /root/gh_champ.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://ping.yourdomain.de/ping/UUID

Conclusion

Looks bonita 👍 ! With a chart like this, the cuties will flock towards you instead of running away.

Jokes aside, the whole “fake it till you make it” philosophy isn’t all sunshine and promotions. Sure, research suggests that acting confident can actually boost performance and even trick your brain into developing real competence (hello, impostor syndrome workaround!). But there’s a fine line between strategic bluffing and setting yourself up for disaster.

Let’s say you manage to snag that sweet developer job with nothing but swagger and a well-rehearsed GitHub portfolio. Fast forward to your 40s—while you’re still Googling “how to center a div” a younger, hungrier, and actually skilled dev swoops in, leaving you scrambling. By that age, faking it again isn’t just risky; it’s like trying to pass off a flip phone as the latest iPhone.

And yeah, if we’re being honest, lying your way into a job is probably illegal (definitely unethical), but hey, let’s assume you throw caution to the wind. If you do manage to land the gig, your best bet is to learn like your livelihood depends on it—because, well, it does. Fake it for a minute, but make sure you’re building real skills before the curtain drops.

Got real serious there for a second 🥶, gotta go play Witcher 3 now, byeeeeeeeeee 😍

EDIT

There has been some development in this space. I have found a script that let’s you commit messages with dates attached so you do not have to wait an entire year to show off: https://github.com/davidjan3/githistory