Most improved answer
Repost from: 2021
This category is to reward the continued work users put into answers long after they have been posted. After the FGITW effect has dissipated there stops being so much incentive to work on an old answer, but some users put in the effort and really make it shine. The ideal answer here would be one that demonstrates a significant commitment to improvement regardless of the quality of the initial answer. This could be improving the score, or the explanation or both.
Answers in this category don't have to have been initially posted in 2022 but the improvements have to have been made over the course of the year.
This was at first by far the longest Desmos answer to that challenge (at 178 bytes), but I decided to post it becuase I used a slightly different approach. Mine was also scalable.
I initially did some golfing of my own, getting it down to 161 bytes. Steffan then helped me with a 153 byter. I got an insight and golfed it down to 126 bytes. After talking with Aiden Chow in chat, he helped me to get it down to 119. Shortly after, we managed to replace that function with a peicewise, and combining that with a byte saved by emanresu A, we got a whole 47 byte golf. Steffan then contributed a bit more, getting the asnwer to 68 bytes. Removing the scaling feature gets me the shortest Desmos answer to that challenge: 60 bytes.
In all, the answer had been golfed 118 bytes since its posting: 12 by Steffan, 35 by me, 54 by Aiden Chow, and 1 by emanresu A.
Note: there was a 1 byte golf by Aiden Chow to the scalable version, but I have chosen to not list it here because it was made in 2023
Ever wondered what a chain of self-golfs while eating soup and participating in an SQL uni workshop looks like?
I started with a FGITW at 42 bytes (not included in the answer header, but in the revision history). After an hour and 17 minutes, I found there was a
-1 byte shave, which got the ball rolling. At this time, I was not eating soup, nor was I in a uni workshop.
Then, another hour later, the soup started, the workshop was going well, and I found a
-2 byte shave. At the time, my answer was first place, because people were still answering it. But then Kevin came in with 05AB1E and outgolfed me by about 7 or so bytes. This was obviously unacceptable, so I managed to find a
-6 while eating soup, bringing the gap down to roughly 1 byte. After that, I got that gap down to 0 just 5 minutes later.
But I wasn't done. The power of
WHERE clauses and database
JOIN ONs was strong enough for me to find another
-1. Now that doesn't seem like much, but in a golfing language where you already have something you consider short, that's a major thing. After that, I took 12 minutes to find another
-1 (due to reading the challenge specs properly) and left my answer at 30 bytes. I also left the workshop 30 minutes later and placed the empty soup plate away (after cleaning it, duh.)
Then, during my nightly code golfing session (yes, I spend most nights code golfing until 12:30am - don't question my lifestyle (it's 12:09am as I write this nomination)), I managed to find another
-2 bytes at 11:48pm, which brought my answer down to 28 bytes. After adding an explanation 20 minutes later, and probably wrapping a few other things up, I left the answer alone for the rest of the night (and slept.)
The next day
I woke up and saw that my 28 byter was no longer the shortest (stares at MATL and Charcoal coming in at 26 bytes). I said to myself "this is no good. I must reclaim my W". So I managed to find a way to get
-3 bytes (as a
-2 and then a
-1 in quick succession - the revision history doesn't show the 26 byter, probably due to grace period edits or something). My answer was now 25 bytes long, which was enough to reclaim first place. But that still wasn't enough for me. 4 hours later (not all spent golfing this answer, probably only 10 minutes golfing this one answer, 3 hours and 50 minutes doing other things), I felt the need to keep experimenting with ways to shave even more bytes off - which was hard at this stage given that I was already beating the dedicated ascii-art language + the language where graphical output is a thing. There wasn't much room left for golfing.
Yet 25 bytes became 24 bytes at 9:31pm. And another hour later, 24 bytes became 23 bytes at 10:25pm. That's not to say I spent the entire hour golfing, but I probably spent a good portion of that time trying to re-arrange things. And so that's where the story ends - 18 total bytes saved. That doesn't sound like much, but in SBCS languages, a byte save of 18 bytes is probably the same as a byte shave of 100 bytes or so.
1 bowl of soup, a university workshop and 2 night golfing sessions. Who knew that's what you need to go crazy on byte shaves?
A complicated challenge for BQN resulted in a complicated answer. Over the course of a couple days, and with some help from att in the comments, I golfed my answer from 79 bytes down to 51. A little friendly rivalry with Dom Hastings' Perl answer provided extra motivation. At one point, I changed a significant chunk of my algorithm. And after every change, I made sure the explanation section was up to date.
nominated by alephalpha
This is a fastest-code challenge. The original solution was already pretty fast. After several rounds of improvements in ten days, the score improved from 2500000 to an amazing 14000000. It is the only solution that beats the hard-coded solution.