With Chris Coleman traipsing around Europe on his annual jaunt, it’s time for my yearly “Friday Q&A: Inside TSL” edition. Lots of good questions as always — and some repeated ones.
Our ongoing technical issues and the news about John Rocovich being removed yesterday severely impacted my time to write this, but it looks like I wound up with a huge article anyway, so that’s good.
First of all, an update: We are still trying to get through the server transition part of our technology stack update. This has gone on way longer than we expected. From what I understand, we have transitioned all of the physical connections over to newer hardware. The difficulty that persists is tying all the software back together on the new setup so it works as well as it did on the old hardware.
The current TSL was built over the course of 15 years, patching together various pieces of software written in various languages and operating on various databases across various physical pieces of hardware. Migrating everything and getting it to communicate successfully again is a chore, as you can tell.
At the moment, there are still pathways that simply do not work. For example, when I click my notifications, the “mystery man avatar” — the gray silhouette that displays for users who never selected their avatar – is broken. It’s trying to display this image to me:
https://virginiatech.sportswar.com/i/mysteryman.jpgThat produces a “Page Not Found” error. (Clearly, it’s an image, not a “page.”)
But the same mystery man avatar on the message boards displays properly, because it’s coming from a different place:
https://virginiatech.sportswar.com/static/assets/avatars_coming_soon.jpgThat’s just one example of a pathway that was broken coming from the old setup to the new. There are a bunch of these, and they all have trickle down effects. We’re gradually stomping them out one by one.
The new dev website has been delivered: Earlier this week, I turned the new version of the TechSideline.com website over to our developer, John Donna.
John — as he continues to button up the server transition — will review the new code module by module, and once that’s complete, he’ll start tying this new site, which has existed in a development vacuum, into our live databases: message boards, articles, tables, user data — all of it.
We’ll eventually have a dev site that is running off live data, so as we post articles to the live site, they will appear on the dev site. I’ll be able to use the dev site to read the live message boards and respond to posts over there, and they’ll appear on the live site. Recruiting data from the live site will be displayed on the dev site, and so on.
Once we feel we’re ready to flip the switch over and make the dev site live, we’ll do so, and that’s when all hell will break loose, as thousands of users hit a site that has previously only been accessible to a few people. This will reveal new bugs and operational flaws, and we’ll work on getting them corrected as quickly as possible.
Once everything is complete, you’ll be living on a new website that is faster, more cohesive and packed with features that we’ve only been able to dream about.
The majority of these features center around message board posting, reading and administration. Not everyone cares about the message boards, but from an operational standpoint, they are the one thing that creates the most email, most customer service, most complaints, etc., and they’re the thing I’ve thought about the most over the years, as far as features I’d like to add.
I’ve also packed a lot of admin features into our sponsor administration and reporting, but you’ll never see any of that or care about any of that.
I could go on and on, but this is a Q&A, not a status report, so let’s get to it … with a question about the new site.
Tell us about your experience and challenges with coding. — HokieHill
If you’ve missed the recent message board discussions, I’ve revealed that I have been developing the new website myself using an AI coding agent called Code Puppy, which is built on the Anthropic Claude Opus artificial intelligence Large Language Model (LLM).
I access Code Puppy — my particular instance of Code Puppy is named “Jack” — via a terminal interface. Here’s Jack after he’s booted up and is ready to go:
Let’s give Jack a task. Here’s the page where we administer the schools (universities) in our recruiting database, meaning the schools that a recruit can show interest in, commit to and sign with:
I’ve decided that I want to change the “Abbreviation” column heading to “Abbrev.” and want to switch places between that column and the “Name” column. So, I type into Jack’s terminal:
Morning, Jack. On the “Colleges” tab of the Recruiting DB Admin page, I want you to switch positions between the Name and Abbreviation columns of the table, and I want you to shorten the “Abbreviations” column header to “Abbrev.” (enter)
Jack then charges off, reads the existing code base, figures out what he wants to do and proceeds to write and deploy code. During the process, he “talks” to himself by writing text in gray on the terminal display, and he “talks” to me by writing text in white on the terminal display.
When he’s done, he tests his code, commits it, then reports back to me:
Boom, done, changes made:
That’s a pretty simple task. I have given Jack much harder stuff to do, and at times, he has spent a lot of time figuring things out and writing code.
You have to pay attention to Jack while he’s working, because even good coding AI will go off the rails. For example, I built a profanity-filtering feature into the boards. I told Jack to sniff out common vulgarities and substitute asterisks for curse words.
In Jack’s first attempt to implement the profanity filter, he put it on the front (display) end, meaning he put a filter in place to read the post before displaying it, and to filter out profanity when displaying. That means the filter has to be run every time a post is displayed. That’s processing-intensive.
I told him instead to filter the post when it is submitted by a user and to replace profanity with asterisks before storing the post in the database.
Jack responded with, “Oh, yeah, that makes more sense. Much more efficient. Let me get on that.” And then he proceeded to revert everything he had done, and then did it the way I told him to (which I should have done the first time instead of being vague).
With my engineering and programming background — which literally all happened in the previous century — I have enough technical chops to pay attention to Jack and course-correct him when needed.
I’ve only spent (checks spreadsheet) about 115 hours working with Jack to code the new website since starting in late February. Over the course of that time, Anthropic has updated the Claude LLM many times, and it’s been a blast to watch it get gradually more intelligent and less mistake-prone about how it does things. Recently, Claude went from version 4.6 to 4.7, and that was a HUGE leap in how Jack operated. It was billed as a 30 percent improvement in capability, but to me, it felt like more.
It’s been a lot of fun coding the new site, and I could have kept going, with lots of “feature creep,” but I eventually had to turn it over to John Donna and start getting it ready for public launch.
How close have you become to just hiring internal IT help? — VTPez4Life
Interesting question. John Donna has been our developer for over 15 years. He, and only he, knows our code base and its many interrelationships and complications. To bring a new person on board, even a very capable one, would take months of training on the site before he or she would even begin to understand how everything works.
It’s a classic case of having a giant code base written by one guy, and only that guy understands it. If that guy gets killed by a venom-spitting dinosaur, Jurassic Park-style, you’re in deep doo-doo.
But one goal of this entire code migration and rewrite is that the next iteration of Tech Sideline — and every other SportsWar site, as we roll the code base out to them — will be much more portable and “learnable” by a new person. We will no longer be as dependent on John as we have been.
If we ever do hire an internal, on-staff IT person, that person will just use an AI agent to maintain and update/upgrade the code base.
That person will actually be yours truly. Once we launch this new site, if you want a new feature, I’ll just fire up Code Puppy and get Jack to do it.
For example — I’m not necessarily promising this, just spitballing — I’ll tell Jack to implement a “Buy or Sell” competition in which logged-in users will be able to compete in the same weekly “Buy or Sell” sessions during football season that the TSL staff does, and at the end of the season, we’ll be able to crown a site-wide Buy or Sell champion. (We will undoubtedly need some tiebreakers, but it can be done.)
Jack will be able to whip that out in less than an hour, under my direction.
Did you find a bug in the system? Tell me. I’ll tell Jack. He’ll fix it. Right away. Any day, any time.
So yeah, we’ll have internal IT help: me and Jack. In the rare instances where we can’t figure something out, or I need a set of eyes on it, I’ll email John and have him take a look, but John will no longer be a single point of failure. It’ll be me and Jack, and if I take him for a walk and we get hit by a bus and both get killed, literally anyone with a minimum understanding of how this stuff works will be able to step in and take over and keep things going.
How many customer service emails do you typically receive in a day? — GretnaHokie
During our current technical issues, as we migrate the server setup? Pfffffft. A lot. 15? 20? It’s not just the volume, it’s the … hmm, how do I put this? It’s the fact that most are coming from people who can’t even phrase the question or follow-ups properly.
Example:
“Will, can’t access site. Thought I had a subscription. Can you check?”
— “You’re currently subscribed, yes. Thanks so much. What exactly is happening?”
22 Comments