This is the difference between tinkering, experimentation and engineering. All of these have their proper place. There is no shame in having a shoddy piece of code as long as it is within a lab environment. Trouble usually starts when this kind of code changes hands and finds serious users.

I joke that I have an ever growing private repository of code I'm too embarrassed to publish publicly. Only partly joking; it's actually several repositories. But as others have said, people who are programmers more than just professionally do this all the time. There's very few things that involve using a computer that I run into day-to-day that I don't think, "I could do this faster with a dirty script[0]"

I used to do interviews and would often encounter candidates who had no public repositories, anywhere, GitHub or otherwise. I learned quickly to be very disarming before even asking and settled on something along the lines of "Look, I know when you write things for yourself, you're doing it with very limited time and for an audience who is more interested in it doing 'The Thing' without regard for anything resembling best practices, or even typical practices. I fully expect lousy code and that's perfectly fine, but I really need as many recent samples as you can possibly give me before this evening to be prepared.[1]"

What wasn't probably realized by the candidates was that if I'd made that phone call they were getting the technical interview regardless of the code quality and I was barely going to glance at their code until the interview. And the best thing they could do for me was to give me code that was on the bad side of things[2]. The first question I'd ask is "OK, imagine you have all of the time you'd ever need to make this perfect. The goal is to get there in stages and maximize the improvements as early as possible. What would you change and in what priority." There's no way in their development career that they're not going to encounter something as awful as they've written in production and be asked to fix it, and they're going to have to start with "make it work again" and in a limited number of stages "get it to the best state; hopefully to an ideal state" but the goal is to get to as stable of a state as possible before you're pulled somewhere else.

[0] Or better, stop doing it at all by putting that dirty script in a cron job that won't have any logging, I'll probably be really happy with for the first few weeks, then forget it was there and not realize a few months later when it stops working.

[1] It was kind of a dick move and I always felt a little guilty, but I know that my instinct would be to spend an evening cherry picking the best examples which I'd then go without sleep to clean up as best I could before morning. And it wasn't a situation where I wanted to judge them at their worst "Well, if their worst code looks this good, they must be good."; if I got a code sample that was too good, I figured it was the rare script that was cared about but that the developer didn't want to unleash on the world and feel like they had to support. When this happened, it was always from a candidate who gave me one maybe two things while claiming to be a code addict and I always asked those candidates to rectify their love for software with only having a couple of very small, albeit well-written code samples. I recommended one guy who admitted he had a lot of other code but was too embarrassed by it and then logged into his BitBucket repo.

[2] Which I found worked best when I simply just asked candidates for their worst code and told them, generally, that I'd like to get a feel for how they handle eliminating technical debt. If the code was too good, I'd have to find something that I felt they should be able to quickly understand well enough to offer ideas for improvements; that rarely worked out well -- it's always easier on the candidate when it's code they've written because they're, at lease possibly, likely to be familiar with it.