Intro
When I realized that I had been coding for over half my life in late 2024, I started to consider what that means.
- What kind of benefits does that fact afford me?
- What kind of bad habits have I developed as a result?
- Are there opportunities unique to me as a result of having so much code in my history?
The Benefits
The benefits are hard to quantify. What is the ratio of hobby years to professional years? I published my first compiled Java application in 2012, does that mean I could technically boast 12 years of Java experience at the time of this writing?
Truth is, I haven't touched Java in probably over a decade - how many recent graduates can say that, though?
A significant portion of the students that I connected with at Oregon State University wrote their first lines of code at that very school; I had written my first lines nearly 10 years earlier while I was in middle school (go Knights).
The benefits are hard to quantify. What is the ratio of hobby years to professional years?
What that longevity of coding means is that code isn't a foreign language to me, I'm fluent. I think in code, often dream in code, and have no trouble expressing myself in code.
Very seldom do I need to struggle through how to apply an idea programmatically, and very seldom does a new language stump me when I am given a moment to familiarize myself with the syntax.
Over half a life of code I've also learned what not to do! So much of my early code (what I can excavate of it) is indicative of a fresh mind that saw the world of computing as infinite and magical.
In my proudest Minecraft mod, I had written a nested for-loop to shake the heavens - SIX LAYERS deep. This function ran on every generated chunk (16x16x128 block section of the game world). At the time, I had no concept of complexity, I just knew that I needed a certain number of steps repeated (or so I thought that was the only way at the time).
My only regret is that I don't have the source, I'm sure that the comments would've been a treat.
Pain is an excellent teacher. — Zenyatta
The Lessons
There is so much to be learned from mistakes, and after 13 years I have plenty of them in the well. Many prevalent learning theories posit that it's the interconnectedness of concepts that foster learning, and being able to connect failures with new concepts has made me quite an adept coder, debugger, and designer.
In the beginning, YouTube and failure were my only teachers - I was entirely self-taught. It wasn't until my first round of university that I took a formal coding class (and it was a single Java course, 99% of the content of which I already knew). It would be another four years before I started on my Bachelor's in Computer Science.
So many bad habits came of making my own rules.
It's not uncommon for more junior programmers to be allergic to proper use of a debugger, but after having not known that such a thing even existed until I had been writing code for years did feel like a major hurdle when it came time to actually learn to use them.
The same goes for releasing projects. For so long, it just wasn't that important. I had no community to share things with, they were really only for me and the friends that were immediately near to my screen. There was no audience with which to share the projects, so I never ran into the "well it works on my machine" excuse.
For so long, it just wasn't that important.
If I could go back and teach my younger self a few things, they would pretty much all boil down to "yes, it will eventually become important."
Whenever I see this in others, I really try to be a gentle guide into how important it is that one always be forward-facing.
Sure your projects might be small now, but why not learn how to debug a program (better than simple debug prints) while it's small so that you can learn the tool without the overhead of a massive project?
Sure you might not think that your project will be the next big thing, but why not learn about publishing so that when you DO come up with the next big thing it's just one fewer concept to learn?
Yes, it will eventually become important.
For me, the worst habit I held was letting projects die simply because I didn't know how to (nor care enough to) learn to publish them. There are a couple little games that I wrote back in high school which definitely could have gone on some kind of platform, and could have served as more milestones in my coding journey.
But that lack of understanding did give me something: a drive to overcome it.
Since I really knuckled down and started bridging the gap between prototype and deployment, I've developed into a burgeoning DevOps practitioner and dove head first into the deep end to make up for lost time.
Unique Opportunities
The original project was a monolithic, vanilla JavaScript, memory-leaking monster with a basic and only nearly usable interface.
I can brownfield! Some of the projects I have (that weren't lost to the sands of time) are so old that revisiting them is very much akin to legacy code: outdated patterns, dependencies no longer supported, and unrecognizable code written by a past self.
Most people wouldn't be particularly excited about this "opportunity," but I celebrate any chance to learn something that may be applicable to my career.
Legacy code exists in a lot of companies' codebases, and having some kind of an idea of when to treat something like a black box, when to rewrite, how to read archaic comments, and how to interface with older protocols can't possibly be a bad thing.
A specific example I have is my project "riceCAD" which was originally written before I even started using GitHub effectively. The original project was a monolithic, vanilla JavaScript, memory-leaking monster with a basic and only nearly usable interface.
In WebDev I at OSU, our term project was to use Express and Handlebars to write a simple website. I proposed we revamp riceCAD, keeping only the core playcanvas.js viewport and textarea editor while redoing the rest of the interface and adding an API. This is the version which is currently featured on my GitHub (and in the hall of fame that year!).
Some of the brownfield decisions made during this rewrite were: to keep the data the same (wasteful matrices of numbers), to treat the core viewport as a black box, and to greenfield the rest of the interface.
The data was kept the same to prevent scope creeping into the system that consumed the data (workers inside a game); while the other decisions were prompted by the requirements and resources available per the assignment.
We had to display the use of handlebars and express, so we opted to focus on simply rewriting the interface and not devoting any of our precious few weeks on the viewport.
Conclusion
There are some interesting quirks I have as a result of my early start to coding, that's for sure. I struggle to represent a lot of the advantages I have, most of them are very "soft" and not readily evident.
I'm interested in learning about the hard-to-represent skills that others have developed over time, and how they feature them! Word of mouth and more personal approaches like this blog post seems like a decent enough manner, but surely there are other ways.