Joshbot - why it’s ok to write bad code

---

Table of Contents

1. Reluctance
2. Who is josh?
3. Joshbot, Reimagined
4. A retrospective

Reluctance

My approach to programming projects for the longest time was, in a word, reluctant. I’ve always been one to open up Github and see all the new projects that are popping up each day, and have always been inspired by projects ranging from small, elegant, efficient utilities/scripts, to massive, robust programs and libraries. So, when I would see these cool projects getting the recognition they deserved, it gave me a huge motivation boost to get out there and start writing software and starting projects.

But that’s where the reluctance became an issue; I was (and still am) hesitant with my coding skills, and could never think of any game-changing ideas that motivated me enough to start a project. I would wrack my brain for any ideas that sounded cool, and then I would become disappointed when I couldn’t think of anything, or when I didn’t even know where to start.

I’ve gone back and forth with this mindset a lot throughout my life. But ultimately, I’ve come to realize that I enjoy writing software when the software that I write either:

1. does funny things
2. teaches me something

At the end of the day, writing software is learning how to make computers do what you want. In a professional sense, it’s great to have really scholarly projects under your belt, and to have a ton of stars on github, or even to be a contributor to a large project (check out my commit to xterm.js it’s like 2 lines). But outside of what looks good on paper, I’ve found that doing projects that fit into one of the above categories is the best way for me to actually consistently improve.

Joshbot is a project that fits both categories. It is unoptimized, relatively convoluted, was created in a very short amount of time altogether, and yet it has become one of my favorite personal projects to date.

Who is josh?

For reasons that would be far too humorless without the requisite context of several long-running inside jokes, my friends and I have a discord server named ‘josh’. There are very few members, all of whom are nicknamed ‘josh’, and there is only one text channel: #josh. The rules are simple. On this server, you only say the word ‘josh’, and you must be nicknamed ‘josh’. Failure to comply results in deletion of messages and/or being kicked. It’s a very exclusive group. (If you are a recruiter for a top tech company, please skip this blog post).

Now, if you’re like me and you’ve taken a bunch of Cyber Security classes, you’re probably wondering: “How can I protect my beloved josh server from threat actors (people who send messages other than ‘josh’)?!” It’s truly a problem that kept me up at night. The problem is that these Non-Joshes (NJs for short) could pose a potential Denial of Service attack; if enough NJs started spamming, the admin joshes (AJs) would be unable to delete each message quick enough. The AJs would likely just ban the NJs, but if the attack was posed while the AJs slept, there could be hundreds or even thousands of malicious messages to clean up!

This is where joshbotv1 came in. This was a bot I wrote years ago that simply deleted any non-josh messages, and had a utility command to go back through the chat logs and delete any non-conformant messages. But, after years of relative silence in the josh discord, I awoke one day with a simple idea: to not only bring back joshbot, but to reinvent him entirely. A simple re-write and language switch wasn’t enough. Joshbot needed to be robust feature-rich and useful exciting.

Joshbot, Reimagined

With that, my work on the project began, and from the outset the momentum was already extraordinary:

Joking aside, I started with a simple Go port of the bot to get used to the discord wrapper library that I was going to be using. Once I started, though, the momentum slowly built, and I started implementing new, funny ideas as soon as they came to me. Before I knew it, I was consumed in making this very silly bot for several weeks, and it ended up being a huge operation.

All told, joshbot went from a bot that simply deletes messages to doing the following:

• keeping track of new users when they joined the server, applying roles and renaming them to josh
• deleting non-josh messages
• renaming users to ‘josh’ if they choose to forgo the alias
• logging each message sent in josh, the user who sent it, and whether it’s a valid josh (VJ) or a non-josh (NJ)
• sending said logs to an internal API, which, among logs, also stores josh-relevant information about resident josh members (RJs).
• pulling from the internal API to display statistics and leaderboards on a website
• choosing a user to be ‘josh of the week’ every week (it’s an honorary title, has no power, all RJs are equal)
• awarding users a fictional currency (‘joshcoins’) based on consistent ‘josh’ messages

Also produced during the process were:

• a set of scripts to create graphs based on josh log data, such as:
• The Joshle, a wordle-like minigame with the exception that the word is always josh.

All of this was new to me, but it used familiar parts. I had made discord bots before in C# years ago, with an outdated version of the discord API and, to be entirely honest, a codebase mostly comprised of copy-paste operations. I had some experience with making websites, especially with my own personal websites (like this one!), but I’d never dealt with making actual REST APIs, nor had I made any websites with react outside of some simple ones for my classes (that mostly other team members handled anyway). So, when the time came to put all these little bits of experience together, things got hacky. But I found that making hacky things that worked was the best way to actually learn; knowing that they were hacky and unoptimal was the first step of understanding how they could be improved.

A retrospective

I spent a very long time making these features during the intense several weeks I was mainly working on the project. When I wasn’t doing schoolwork or hanging out with friends, I was working on joshbot. It brought me an immense amount of joy, despite the seeming futility of it all.

Each time I would think of a new idea, I would think about how silly the whole project was, how it would never garner any attention from recruiters, and how it was all a waste of time. And yet, a rebellious part of me still wanted to add those features, simply because they were funny. I wanted to see my friends laugh at this needlessly complex software ecosystem surrounding probably one of the dumbest inside jokes we have. And so I continued to add things, continued to implement ideas until new ones arrived.

There came a point where I was happy with the work I had done, and work slowed. This isn’t to say I finished the project by any means, because there are still things left to be added, optimizations to be made, and portions to be refactored. In fact, throughout the whole build process, I did all of my serialization through a combination of JSON files and CSV files. This means that each API event involved serializing or deserializing CSV/JSON data. In retrospect, this is horrible. I should’ve just used a simple SQL database. In fact, there’s a branch of the project right now whose purpose is to do just that; migrate the tables over to SQL. The joshcoin system is still largely unimplemented, and uses the same (bad) JSON serialization for everything. The bot probably would never scale well if the server ever started getting tons of messages, and/or if the user count went beyond the measly handful it’s always been. While I tried to write code that was fast and not too convoluted, I didn’t spend much time refactoring, optimizing, or even trying to write code that was necessarily clean/well-documented.

The code was a means to an end, and really the thing I strove for was the satisfaction of having my friends laugh at this silly thing I used my expensive degree to make. And this realization is what cemented this project as one of the best byproducts of my CS degree (there’s slim pickings, I know). By simply not worrying so much about how the project might appear on a resume, I was able to set aside my reluctance and learn so much more than I expected.

While I doubt this project will blow up on Github and get worldwide recognition, I gained so much more from this project than really anyone would have ever thought. And honestly, the biggest takeaway that I’d like to share from this whole experience is that it’s ok to write bad code. Writing bad code is better than writing no code, and the process of writing out the bad code almost always teaches you so much more about good code than reading some dude’s blog post ever will (present blog notwithstanding).

So, my advice to you is to be willing to do projects that don’t necessarily look good on a resume. Write programs that you want to write. Use your incredibly expensive degree for something that makes you and your friends laugh together. What’s the point of computers at all if we can’t use them to do things that are endlessly funny and fundamentally futile?