When I was around 17 or 18, I first heard about PHP. I honestly can't remember where or how I heard about it though. What I do remember was I thought the concept of variables within building a website was amazing, after having been through algebra, trigonometry, and some calculus. I loved math, and if I could apply it to websites?! Awesome!
I found (the older version of) php.net and had no idea where to start.
Browsing around the index, I landed on reading about
In the past (when I was 14) mail-form handlers were always intimidating to me. You know, the stuff that went in the
cgi-bin folder. This was in most cases, a perl script I had copied and pasted.
But for some reason at the moment of hearing about PHP, form handlers, variables and includes I was excited. Like Christmas morning excited.
This was not breaking news at the time. Just news to me.
I rushed to build my first form handler. And here it is, in all it's glory:
My little form to calculate my one rep max on bench
Easy. I was equipped with the skills to build my first online software as a service. Right? Well I believed it. So I went for it.
I was a pretty heavy AOL Instant Messenger user at the time. I decided I would build a tool that would allow you to customize your buddy profile, and circumvent the 500 character limit (or whatever it was) in the process.
Hence, "Infinity Profiles" was born.
Again, not a new concept, but I wanted to do it myself. Here is an example of another service that did the same thing: Firebolt
I set up a process of steps for the user to create their profile. They needed to choose a background color, a font color, a title size, a title color, and enter content.
For the color picker I built a 256 cell table that looked something like this, but used radio buttons.
Yup, hand-coded that bad boy of 256 table cells with hard-coded background colors and a radio button for each. I don't remember exactly, but it was someththing along the lines of this:
<tr> <td bgcolor="#000000"> <input type="radio" name="font_color" value="#000000"> </td> <!-- ... more td's... --> </tr>
You might be dying while you read that. Or you may have done something just as awsome last week :)
But it get's better.
Through all 8 steps of the customization setup process, to configure their entire profile with content and everything, I was not using a database.
The whole reason I discovered this multi-step configuration process was even a possibility was because I found the global
At the end of the steps, it would save their profile settings as a file, and give them their generated code to copy and paste into their buddy profile.
Yup you read that right, I was storing all of the data and options they configured in the session, and then a file. One per user.
You bet I was. Horribly wrong.
Was it ok?
It was just fine. Several people used infinity profiles without any major problems. I used it myself. It worked.
There was no major bottom line affected. There were not lives and jobs on the line. It was an opportunity to learn how something worked, and I did it.
Looking back at the project I was able to see why it was so horrible. But in the moment, it seemed perfectly right.
In fact the very next project I did, when I stumbled across the
mysql_connect function, I was able to see how silly using session data was.
Over the years, I've had plenty of experiences like this. In the moment, the planned and prescribed approach seemed to fit perfectly. Then a month later, I learn how wrong I was.
Sometimes it was on client projects. Usually it was on side projects.
But David Heinemeier Hansson said it's best to ...
Sometimes you have to put technical religion aside. And just do it.
There is always a better way to do things, but the important thing is, you're doing it.
When there are critical factors on the line for a project, it might not be the best time to experiment or take risks. So if you're able spin up a new side project to test things out, break things and learn what works.
There are a couple points in this story that have continued to repeat themselves over the years, I have noted to myself.
1) Doing it wrong gives you perspective*
You will be much more sure of the right route when you have spent time going down the wrong route.
2) Doing your best, is doing it right
You can't be expected to know everything, to have benchmarked every divergent option, and to have the perfect solution for every circumstance. Most of the time, your best will have to do. If you just plain don't know enough, ask for help.
3) If you see flaws in your past projects, you're doing it right
If you can't look back at past projects, and see what you did wrong, or what you would do better this time around, you might not be learning or progressing enough. It may be time to come to terms with what you don't know or to start a new side-project.
If you enjoyed this article or found it helpful, you will enjoy my newsletter: