This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
The background
This happened almost twenty years ago, in the year 2006, back in my undergraduate days, when I was still studying CSE - I participated in my first and only International Collegiate Programming Contest (ICPC), which was then known as ACM-ICPC.
I was, and still am, one of those programmers who like to take it slow, with full clarity, and try to completely grasp the concepts all by myself before jumping into implementation. As a result, I never was competitive programming contest material!
So then, why did I participate in that contest?
Well, one fine morning, I was working on a project in our university's computer lab, and two of my friends came to me and said, "We want to participate in the upcoming ICPC that our university is hosting, and we want you to join us!"
They even wanted to make me the team lead! I was hesitant at first, but then I thought, "Why not? It will be a good learning experience!" So I agreed to join them. Except for the team lead part, of course, that would have been a bit too much for me, given my lack of interest in competitive programming.
A bit more about my own background
I've never publicly shared this story before, especially because of the embarrassing part of it, but I think it's way past time to share it now, as I feel that it can be a good learning experience for others.
To make sure readers understand the context of my embarrassment, I need to give a bit more background about my programming experiences up until that point.
I started my Bachelor in Computer Science and Engineering (CSE) in 2002, at North South University and I was introduced to programming only in the first semester. Before that, I had no idea what programming was, but I found it interesting from the very first day!
C was my first programming language, but it was only part of a single credit lab course, which ended merely in three lab sessions, one and a half hours long each! So my real taste in programming began in the second semester, with the course named "Introduction to Object Oriented Programming in Java" - if my memory serves me right.
Around the middle of that second semester, there was an intra-university solo programming contest, and I participated in it. I was able to solve three out of six problems, which landed me third place in that contest! I was very happy about that, and it gave me a lot of confidence in my programming skills. But after that, outside my regular course curriculum, I became more interested in math, robotics and software development in general. For some reason, competitive programming never really attracted me that much.
That said, since I was attending that ICPC team contest anyway, I did try to prepare for it for a while. Part of that preparation was going through some problem sets from previous contests. As a CSE student, I was already familiar with most of the algorithms that were needed to solve those problems, so all I needed to do was to practice enough problems to be able to solve them quickly during the contest. We didn't get much time to prepare, so we thought it would be best if we participated in an actual contest before the main event.
Fortunately for us, there was an online programming contest hosted by Topcoder that was happening around that time. That was a solo contest also known as SRM (Single Round Match). All three of us participated in that contest, and all of us were able to solve two out of three problems individually, which was a good result for us.
So, from that preparation, we were expecting to solve at least 50-60% of the problems in the main contest! We weren't expecting to win, but we were hoping to do well enough to be recognized!
As a straight-A student, that was a very basic expectation for me, and I was very confident that I would be able to achieve that. But as it turned out, I was in for a big surprise!
The embarrassment
Now that all the background is out of the way, let me get to the embarrassing part of this story:
We ended up solving ZERO problems in the main contest!
Yes, you read that right - ZERO problems! We were not able to solve a single problem in that contest, and we ended up at the very bottom of the scoreboard!
Doomsday!
Every religion has a doomsday, and if programming were a religion, then that contest was our doomsday!
As I said before, I thought it would be a good learning experience, and I was right about that eventually, but none of us were expecting this sort of devastating learning experience!
Out of ten problems, we were able to solve none! We were not even able to solve the easiest problem in that contest, which was a very basic math problem. I still remember that problem somewhat, and I can still solve it in my head without much difficulty. But during that contest, we were not able to solve any of them!
I clearly remember, the moment I finished reading problem A (the very first problem), I knew that was the easiest problem in the contest.
In every ICPC, usually there's one problem that is very easy, as far as programming contests go, and it's expected that most teams will be able to solve that problem. The first one is not always the easiest, but in most cases, it is.
So I started solving it and probably within the first 5-6 minutes, I submitted my solution. But to my surprise, it was rejected! And the reason was given: "Memory Limit Exceeded". I was shocked! I had never encountered that error before, not in the practice problems we solved, and not in the past two contests I participated in!
It's not that I didn't know what that error meant, but for that particular problem, the input was really straightforward, and there was no way that my solution could have exceeded the memory limit, or so I thought! I was very confused, and I tried to figure out what went wrong, but I couldn't find any issue with my solution. So I submitted it again with some improvement in the algorithm, and it was rejected again for the same reason!
No matter what I did, I was not able to solve that problem, and I was not able to solve any of the other problems either! All three of us kept getting the same error, for all the problems we attempted to solve! We were completely baffled, and we had no idea what was going on!
The contest was four and a half hours long, and we gave up after trying for almost three hours! We were completely demoralized, and kept thinking there must be something wrong with the contest system, or maybe it was about solving those problems more efficiently. But no matter what we tried, we could not figure it out!
After we gave up, we spent the rest of the time gossiping among the three of us, trying to have some fun, as our last unsuccessful attempt to salvage some dignity from that contest.
And right when there were only a few minutes left in the contest, suddenly something clicked in my mind! OMG! I realized what the problem was!
The Aha moment!
Along with the computer, the contestants were allowed to bring some programming or algorithm books, and a pen-drive with some code snippets in it.
To solve the problems faster, the night before the contest, we wrote some code snippets for some common input and output handling - like taking inputs from the console (Standard Input), taking inputs from a file, printing outputs to the console (Standard Output), printing outputs to a file, etc. following common programming contest input output patterns. We wrote those snippets in C, and we were using those snippets in our solutions.
But the problem was: we were taking all the input lines into an array all at once, and then processing the array to get the result based on the problem statement, and then concatenating the result into a single string, and then printing that string as the output. That was a very inefficient way of handling input and output, and it was causing our solutions to exceed the memory limit!
However, since we were only focusing on solving the problems, we didn't realize that our prewritten input and output handling snippets were causing the problem! We were so focused on solving the problems that we didn't even think about the input and output handling part of our solutions!
Sample Code
As it happened long ago, I don't have the exact code snippets we used back then, but I can give you a rough idea of what they looked like.
1. The Flawed Code (Memory Limit Exceeded)
For example, in this version, we preallocated giant arrays to read all input numbers into memory before processing. Then we processed all formatted output strings in another huge array before printing anything to standard output.
With 100,000 per test case across up to 110 test cases, this instantly exceeded the judge's memory limit.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define MAX_NUMBERS 100000
#define MAX_LEN 25
/*
* Flawed approach: Pre-allocating giant arrays to store all
* inputs and outputs in memory before printing.
*/
char input_numbers[MAX_NUMBERS][MAX_LEN];
char output_buffer[MAX_NUMBERS][MAX_LEN * 2];
void print_differing_suffix(const char *start, const char *end, char *out) {
int i = 0;
while (start[i] && start[i] == end[i]) {
i++;
}
sprintf(out, "%s-%s", start, end + i);
}
int main() {
int N;
int case_num = 1;
// Buffer inputs and outputs across test cases
while (scanf("%d", &N) == 1 && N != 0) {
int input_count = 0;
int output_count = 0;
// Store ALL input phone numbers into memory first
for (int i = 0; i < N; i++) {
scanf("%s", input_numbers[input_count++]);
}
// Process stored inputs into output buffer array
int i = 0;
while (i < N) {
int j = i;
// Check for consecutive phone numbers
while (j + 1 < N && atoll(input_numbers[j + 1]) == atoll(input_numbers[j]) + 1) {
j++;
}
if (j > i) {
// Consecutive sequence range found
print_differing_suffix(input_numbers[i], input_numbers[j], output_buffer[output_count++]);
} else {
// Single standalone phone number
strcpy(output_buffer[output_count++], input_numbers[i]);
}
i = j + 1;
}
// Print header and buffered outputs all at once
printf("Case %d:\n", case_num++);
for (int k = 0; k < output_count; k++) {
printf("%s\n", output_buffer[k]);
}
printf("\n"); // Blank line after each case output
}
return 0;
}
2. The Corrected Code
The proper approach should've been to read, process, and print one line at a time, rather than keeping the complete input and output in memory. In other words, we should've never built a giant concatenated output buffer before flushing it to stdout.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define MAX_LEN 25
/*
* Corrected approach: Helper function to print range directly
* to stdout without allocating output buffers.
*/
void print_range(const char *start, const char *end) {
int i = 0;
while (start[i] && start[i] == end[i]) {
i++;
}
printf("%s-%s\n", start, end + i);
}
int main() {
int N;
int case_num = 1;
// Process case by case using streaming I/O
while (scanf("%d", &N) == 1 && N != 0) {
printf("Case %d:\n", case_num++);
char start_num[MAX_LEN], prev_num[MAX_LEN], curr_num[MAX_LEN];
long long prev_val = 0, curr_val = 0;
int in_range = 0;
for (int i = 0; i < N; i++) {
scanf("%s", curr_num);
curr_val = atoll(curr_num);
if (i == 0) {
// First phone number of the test case
strcpy(start_num, curr_num);
} else if (curr_val == prev_val + 1) {
// Phone number is consecutive, extend current range
in_range = 1;
} else {
// Consecutive sequence ended; output range or single number immediately
if (in_range) {
print_range(start_num, prev_num);
} else {
printf("%s\n", start_num);
}
// Start tracking new sequence
strcpy(start_num, curr_num);
in_range = 0;
}
strcpy(prev_num, curr_num);
prev_val = curr_val;
}
// Output the final range or single number for the current test case
if (N > 0) {
if (in_range) {
print_range(start_num, prev_num);
} else {
printf("%s\n", start_num);
}
}
printf("\n"); // Blank line after each case as required by problem specification
}
return 0;
}
Lessons learnt
We thought that programming contests, and programming in general, were all about solving problems very efficiently, but we learned that, in real life, user input and output handling is also a very important part of programming, and it can make or break your solution! We learned that we should always be careful about how we handle input and output, and that we should never assume that the input will always be small enough to fit in memory, or that it will always be in a format that we expect.
We learned that we should always test our code against realistic input and output scenarios, with edge cases.
We learned that, sometimes, in programming, taking breaks and looking at the problem with a fresh set of eyes is essential to find trivial mistakes that we might have otherwise overlooked, while being too focused on the problem, the solution and the efficiency of it.
We learned that, in real life, failure doesn't mean the end of the world, and that we should always be ready to learn from our mistakes, and that we should never give up when it gets tough! As the proverb says:
When the going gets tough, the tough get going!
- While trying to solve the problem after the AHA moment, we realized that we should've used a version control system like Git to keep track of our solutions, so that we could easily go back to a previous simpler version of our code and fix the input/output handling part without having to rewrite the entire solution from scratch, out of all the jumbled code we had written at the later part of the contest to make them unusually efficient! Had we used git, we probably would have been able to solve at least one problem in those last few minutes of the contest, and we would have been able to salvage some dignity from that contest!
The happy ending
After that embarrassing event, we three attended another programming contest, the last one in our life, as a team.
It was not an ICPC, but it was a prestigious inter-university programming contest nonetheless.
We secured 2nd place in that one. 🏆
And last but not least, I started my first job as a Software Engineer a week before my last programming contest. It was a students' contest, but since I was still a student when I registered for it, they allowed me to participate! 😇
Conclusion
I sincerely hope that this story will help others avoid making the same mistakes we made, but more importantly, I hope that you'll learn to rise up from failures - own them, learn from them, and use them as stepping stones to future success!
Disclaimer
I used AI to help with grammar and spelling corrections, but the story is genuine, and the main write-up is entirely my own.
Code snippets above are not the exact code snippets we used back then. They are AI (Gemini) generated rough approximations of what they would look like. So please take the story as the lesson, not the code snippets.
The cover image is AI (Gemini) generated.
I wrote the entire thing from memory. So, although the overall story is real, a few minor details here and there may not be!
References
The Actual Problem Set. I found it after deeply looking for it in the Wayback Machine. Salute to the Wayback Machine for preserving this problem set for so long! 🫡
My Topcoder Profile after attending the only online programming contest (SRM) before the main contest. Thanks to Topcoder for keeping my profile for twenty years! 😍
