Yesterday a comment on HackerNews got me thinking about the horrible horrible code I used to produce as a young human (and to this day)

To be honest, I wouldn't worry too much. Everyone is like "I was programming since I was 10!" Nobody ever asks what they were programming at 10, most people wrote relatively simple stuff until they grew up and got a professional job. Now to wait for replies from people who designed OSes when they were 12 :)

I started programming when I was 9 because there was a class at my school. Without that class I'd probably become something silly like a writer or a linguist. Thank you ZRI and the awesome professor whose name I can never remember. You guys are great!

Back then I used Logo, which was fun, but the real fun started when they let me loose on Pascal at 11. I have no idea how good a coder I was for an 11 year old, all I know is that I was a terrible coder by real standards.

Here is a non-exhaustive list of the worst monstrosities I have created in the past 13 years.

Age: 11

Tech: Pascal and text "graphics"

I wanted to make maths exercises and present them to the user. Use random to produce infinite examples.

But, I didn't know about GotoXY yet and couldn't print things at specific points on a text screen. That's why I implemented the welcome screen as a set of procedures that would print an increasing number of empty lines before the "WELCOME!" line.

I needed many procedures because I didn't know about loops either - each had a hardcoded number of empty lines. They were called as a huge chunk of code with a _ delay _ to make it smooth.

Code lost to history.

Age: 11

Tech: Pascal and BGI graphics

I called this game space invaders - I had no knowledge of the real space invaders game. Mine was just two spaceships floating above you that you would shoot at from below.

I discovered BGi graphics so I could draw pretty things on the screen. I even knew loops this time. The problem was that I didn't know about arrays yet so there were roughly 200 global variables in the code. I remember the main problem being that Pascal said "Hey, your line of code can't be _ that long!" _ so I had to break up variable definitions into separate lines.

Code lost to history.

Age: 12 to 13

Tech: Pascal, text graphics and a mouse driver

I wanted to make a general interface to my computer that looked just as cool as Turbo Pascal 7 did. I called it an operating system even though it was really just a visual shell running on top of DOS.

It had a lot of general programs for doing various tasks - I can no longer remember how many, but I know there were a lot of menus you could click around to get to stuff. You could even run native programs (I often used it to launch Doom). You could, of course, set up different settings for how things looked and even sign in as different users.

There was a secret way to type a password so you could go into Admin mode and mess around with settings of other users!

Version 2 featured a much slicker GUI. (no screenshots remain, sorry)

I eventually had to learn how to properly use functions and procedures because the GOTO instruction couldn't jump around the 4000+ line monstrosity anymore. And all those "programs" you could run? Monolithic codebase, not actually different programs.

Oh and I still had the problem of having to split up global variable definitions into separate lines.

Code lost to history

PS: I later tried to implement this in BGI graphics, but never got past the stage of drawing windows

Age: 12 or 13

Tech: Pascal and BGI

At this point I still had no knowledge of the real Space Invaders game, so I made a game where you were fighting against two opponents flying to and fro above you. When you shot them down new ones would fly in.

I think this was mostly due to limitations in the code (array size? number of variables for opponents? don't know).

The coolest thing about this game was that you could purchase new weapons and ammunition and that the AI players could run out of ammo as well, at which point they would just crash into you.

For some reason there was a potato head guy on your dashboard, offering encouragement and tips. There are no more screenshots, but I could probably reproduce the GUI with pen and paper.

By this time I had gotten past my obsession with GOTO jumps, but records were still beyond my grasp. I didn't know about readability either so most of the variables were a, aa, ab and so on. But I finally started indenting my code! That was lovely.

Code lost to history.

Age: 13

Tech: Pascal, 24-bit graphics, mouse driver, BMP sprite library

This was my first game that started looking good. Due to limitations of memory and such you could still only play against four opponents at a time, but they finally started flying around in 2D space instaed of just left-right at the top.

You could also fully play with a mouse this time so your spaceship replaced the mouse cursor and you could click to shoot. That was lovely. And so was the fact I started using BMP sprites and 24-bit graphics - it was all really shiny!

Unfortunately just drawing the parallax effect on the stars in the background wasted so much resources there wasn't much that I could add to the game beyond moving around and shooting. I also had a lot of trouble with array size and the amount of bullets that could be drawn on screen.

Eventually I scrapped the project because I kept getting the equivalent of a "null pointer" error and I didn't know what a pointer was.

Code lost to history.

Age: 13

Tech: Pascal, 24-bit graphics

I wanted to make a 3D engine and failed miserably. designed it around the idea that the universe is a cube and when I update whatever is on the screen, I simply have to update everything else that you don't see as well.

After adding two objects to the screen my computer would run out of memory (16MB of RAM) and it took forever to update a single step anyway, so the "game" was completely useless.

Code lost to history.

Age: 14

Tech: Delphi

I think this app was some sort of way to keep track of tasks and stuff. It would show you a calendar - that I implemented manually of course. You could add events and stuff to get reminders later.

Except I didn't even know how to properly calculate when it's a leap year (hint: not just "is it divisible by 4"). But it did win me the 3rd prize in a national program developing competition.

Code lost to history.

Age: 14

Tech: Delphi

You know you're bound to fail when you set out to make a 2D shooting game in Delphi with the idea that you can make a running animation by quickly changing sprites on an object in a window.

After spending a few months getting the game menu just right, with good pictures and ominous music I lost interest and never even started working on the gameplay itself.

Code lost to history.

Age: 15 to 16

Tech: PHP

I can't pinpoint a specific project from this era. There were many smaller ones and a few big websites designed for the webcomics I thought I could make in those days.

The main issues I had were understanding that I can't just pass state around like I'm used to in a dynamic program, HTML being a stateless protocol confused me to no end. Most of my code also relied on register globals and other monstrosities like that.

Figuring out how sessions work took forever.

Code lost to history.

Age: 17 to 20

Tech: PHP

After I got frustrated with the phpBB system of mods and extensions I started working on an opensource system for creating websites so that modules didn't have to know about each other at all.

Essentially a good idea that even got used in the wild by some large-ish websites because I convinced a web agency that they should hire me because I can use this thing.

There were at least several failings

I used relational databases very incorrectly (at first). To the point of not knowing how a many-to-many table works

I wrote my own template engine and language - complete with a poorly implemented template-to-php compiler

There was a package manager that couldn't resolve dependencies and was implemented as a 2000 sloc function

Everything was a singleton

others I can't think of

Code still lives on sourceforge: Chlorine Boards

Age: 19 to 20

Tech: PHP, Perl

Around the time Zemanta was launching with a very well implemented text mining system, I started working on my own. From scratch. In PHP. It grew out of a tag cloud generator and was actually pretty cool - could even make out sentences, find collocations and so on.

But I should have known something was terribly wrong when I had to implement some key regular expressions in Perl because PHP's regex engine wasn't fast enough.

Word of warning: don't write a sentence extractor as a regex. Even if PCRE does let you do that.

I think the guy who inherited that codebase still hates me.

Code lost to NDA's.

Twitulater screenshot

Age: 20 to 21

Tech: Javascript, Adobe AIR

The idea was simple - a twitter client that lets you filter conversations based on what's happening. Put links in different tabs, have happy tweets here and conversation tweets there. Modeled very much after TweetDeck, but better! Better in oh so many ways!

Except it was utterly buggy and complete crap. There is something terribly wrong when you have 20,000 lines of spaghetti javascript on your hands, created by a guy who doesn't know enough about very simple things ... such as how Javascript handles closures and how exactly events work.

Code is archived on github: Twitulater

Age: 22

Tech: python, django, databases

Without much machine learning experience I decided that thinking of a graph as a set of objects with forces acting on them would be a good idea. Then you can just run a particle simulation and eventually the nodes that belong together will float to one another and you can pick out overlaps with a grid-segmentation algorithm.

When new data flies into the system in real-time you can just tweak the forces between related nodes.

Simple stuff.

Except that's not really how one goes about finding cliques in a graph. I didn't even know the name of the problem was "finding cliques in a graph" and thought I was breaking some awesome new ground.

At first I even implemented this inside a relational database and, as you can predict, everything broke down. Calculating a single result would take seconds, even minutes ... just getting the nodes out of a database was completely untenable. The problem was slightly alleviated once we moved to App Engine and its BigTable.

In retrospect, I should have used a graph database. They were just getting popular around that time too!

Or, you know, use an algorithm that doesn't use an incredibly slow and complex process for the first part and then a very slow process for the second part. That might've helped.

Code lost to pure shame.

Did you enjoy this article? 👎 👍

Published on July 9th, 2012 in Games, GOTO, Graphical user interface, Pascal, Source lines of code, Space Invader, Space Invaders, Turbo Pascal, Uncategorized, Video game

Learned something new?

Want to become a high value JavaScript expert? Here's how it works 👇 Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths. Start with an interactive cheatsheet 📖 Then get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career. "Man, love your simple writing! Yours is the only email I open from marketers and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌" ~ Ashish Kumar Your Name Your Email Your Address Subscribe & Become an expert 💌 Join over 10,000 engineers just like you already improving their JS careers with my letters, workshops, courses, and talks. ✌️

Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

Ready to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️