5 life lessons I learned from a programming competition in 1995

Early in my career, I decided to enter a programming competition. Nothing like being humbled. Here's what I learned from that experience.

Written by Jonathan "JD" Danylko • Last Updated: • Business Lessons •
Programming Competition in 1995

One of my favorite times in my career was a road trip down to Durham, North Carolina for a programming competition in 1995. The competition was meant for anyone who thinks they had the best RAD tool on the market.

I was working in Erie, PA at the time and took time off to compete. My co-workers thought I was nuts.

At the time, my language of choice was Clipper (the company was Nantucket at the time). For those who have no idea what I'm talking about, Clipper was a dBase III+ compiler that would build and link (anyone remember Blinker?) the dBase III+ code to create a DOS executable and used the DBF file format for storage, but Clipper could also be extended through C++.

I used C++ in Clipper in a similar fashion as to how I use JavaScript in websites today. I only sprinkled in enough to make it functional and then stop.

During my off-work hours, I built a screen generator, menu generator, report builder, and business logic manager...totally in Clipper.

After I finished the work, I tested it and then decided to show my co-workers. They couldn't believe that I built a click-and-drag system...

...in Clipper...

...for DOS.

I was ready for the competition. It was just me competing.

Cover to the book I received while in Durham, North Carolina

Road Trip!

When I got down there, I had never seen so many coders. Hey, I was a small-time coder who had extreme dreams. :-)

There were people from all over the United States who came to North Carolina to compete and learn from their lessons using their software development tools in a real-world scenario.

The rules for the competition were simple.

  • You could only have 1 or 2 people on a team
  • You wouldn't know anything about what to build until you received the specification at 8:00am when the competition started.
  • You supply your own equipment.
  • No-holds-barred use of any tool to create the application as fast as you can.

The competition would run from October 5th at 8:00a-10:00p and then from 8:00a-12:00 noon the next day.

Yes, a 14-hour day coding, then sleep, then code for another 4 to finish it off...and yes, there were people setting up Mountain Dew IVs (kidding!).

Ready to code!

When the competition started, I was given the specification and read it thoroughly. Some coders were already creating their templates for the application while the others were busy reading the specification and highlighting key points. All I could think of was the old coder saying, "You go find out what the user needs, I'll start coding."

That couldn't be more true. I was at a disadvantage. It was just me.

I won't bore you with the details, but on that night around 9:00p, I looked around the room and people were scurrying around, clicking keys, moving papers, printing reports, and trying to get the majority of their code put together...through the slits of their eyes.

The majority of coders were exhausted, but there were others who felt the "rush of the code" who were fueled by adrenaline and Mountain Dew who continued to attack the keyboard like they were a machine.

I won't lie, it was fun.


At the end of the competition, everyone presented their applications to the judges. The judges would walk around each programmer station to see the walkthrough of the competitors' finished app. 

A majority of the coders never finished the entire application according to the specification, including me, but I would guess that close to 10% finished it.

I didn't win, but it was an awesome experience that I enjoyed a lot. I didn't win 1st or 2nd, or even 15th place. Granted, it would've been nice to have bragging rights, but I'll get to that later (Lesson #2 below)

So what did you learn?

Glad you asked. I was getting to that.

I was definitely humbled while at the competition and I met a lot of people. It was a great experience for a small-town developer.

Some of my takeaways from this competition still follow me to this day. Here is what I learned:

  1. Perform as much of the work upfront as you can.
    Every application has the ole CRUD (Create, Read, Update, and Delete) way of managing data in tables. Even back then, everyone had CRUD screens to manage the data. This hasn't changed in the 20 years I've been coding. So I mastered my language (Clipper) and started building MY tools that would create quick CRUD screens.

    When your tools don't do what you need, build OUT your tools. What I mean by this is put in the time to hone your tools to work in high-pressure situations, but build and personalize additional tools to leverage your existing code.

    In this competition, you had 18 hours to get something done. It was about getting 80% of the application completed and worrying about fine-tuning the remaining 20% according to spec.

  2. Even the little guy can code
    When all was said and done, out of 50 developers, I finished 36. Yes, I know, not very high on the list, but there was something I noticed when I read the list of results.

    There were a lot of companies that sent their top-notch developers with their development tools to this competition. My point?

    Programming Competition Results
    Even though I came in 36th place, I looked down the list and found that IBM Corporation entered the competition with their VisualAge IDE...who finished 44th.

    Whoa! I was 8 places higher than IBM? With my own custom tools? Awesome!

    I learned that as much time as I put into writing my own tools, they were as good, if not better, than some of the other company products at the competition.

    I saw the dividends of my efforts that day.

  3. Never Give Up
    I don't know what the issue was, but there were a few contestants that either dropped out or finished dead last with no score.

    If your computer was dead or wasn't working and you didn't have a backup, I could see dropping out. But having the computer and not submitting ANYTHING? I would've submitted something to get some points. 

    If your computer was dead, borrow a computer. Buy a laptop. Something!

    Dropping out of a competition is not what I was there for. I went all the way to the bell. I wanted the app to be the best the judges would see and even though there were some areas in the app that weren't functional, I focused on making the existing parts better.

    12:00 noon came around and the announcer yelled "PENCILS DOWN! That's it!"

    I stopped and took a deep breath (and a swig of Mountain Dew) and I was happy with my efforts!

    Just Never Give Up!

  4. Take that risk
    While I was coding my tools for this event, I kept thinking, "What am I doing? I'm going to a programming competition with people from all over the world. I won't be able to compete with these people."

    As you can imagine, I ignored that inner voice and decided to finish writing my tools and head down there.

    Even my parents were skiddish about me heading down to North Carolina for a programming competition.

    I am so glad I ignored everyone and took that risk to compete in something that I will cherish for the rest of my life.

  5. Always Network!
    Everyone was there to have fun with creating a real-world application for a real-world client. It was a great time with tons of coders. I met not only coders, but business owners who introduced me to other contacts who needed various applications built for them.

    It wasn't only a competition, but a "hidden" networking event as well.

    "How are you building this application?"

    "How did you do that?"

    "I want to introduce you to someone."

    Granted, back then, there wasn't a LinkedIn, but everyone definitely connected the "analog" way to make new business connections. I contacted people I was introduced to and we started doing business remotely.


Looking back, there were so many benefits to entering this competition. It was also a great getaway for a young kid to experience.

And all because I went to a programming competition to see if I "good enough." ;-)

Did you like this content? Show your support by buying me a coffee.

Buy me a coffee  Buy me a coffee
Picture of Jonathan "JD" Danylko

Jonathan "JD" Danylko is an author, web architect, and entrepreneur who's been programming for over 30 years. He's developed websites for small, medium, and Fortune 500 companies since 1996.

He currently works at Insight Enterprises as an Architect.

When asked what he likes to do in his spare time, he replies, "I like to write and I like to code. I also like to write about code."

comments powered by Disqus