The Big News

Today, I want to take a break from writing a Gameboy game to talk a little bit about some exciting news in my life – I got a new job, and it’s with Major League Baseball! It’s part time but pays well, and more importantly, I will get paid to watch baseball. Essentially, I’ll be working on entering data into an API not too dissimilar from what powers MLB Gameday, except it’s for the local Minor League affiliate, the Lexington Legends.

Lexington Legends


What I Want to Talk About

In the tech industry, especially for entry level jobseekers, it’s constantly iterated that it’s important to have an excellent professional portfolio. One thing you can do is contribute to open source projects.

Easier said than done. After all, isn’t what people really mean is that you need to contribute to an established and complicated project (a la Rails or something large) to prove that you’re a super-smart, talented developer that can work with others? Open source can seem very nebulous or even scary til you look at a real-life example of what said contribution looks like.

I don’t think so. In my professional career (short as it is), open-source contributions have led to not only full-time employment but also this new venture that I’m about to take with my MLB gig. I’d like to dive headlong into one project I’ve been involved with since around 2019 from the development side as well as a community perspective. I think you’ll be surprised by how much code I contribute (or, more accurately, how little).


What I Won’t Talk About

I’m not going to be talking a lot about the ins and outs of the MLB API I’ll be working on (or really the job I’m taking) a whole lot. Since I haven’t fully started and I’m bound by an MLB non-disclosure agreement, I’ll err on the side of caution.

This post will be about the journey to get here.


Starting a Career in Tech Without a True Tech Background

I think I’m similar to lots of folks nowadays – I broke into the tech industry without a true tech background. Some people are self taught, or if you’re like me, you either went to or are currently enrolled in a coding bootcamp to level up your skills. I want to talk about how open source contributions contributed to my career progression. Without understanding my career path, it’s impossible.

With that being said, a little about me:

  1. I don’t have a formal CS education
    • I went to Vanderbilt University and got a degree in molecular biology
    • All my friends were CS or electrical engineering majors (in hindsight, I should have been one, too)
    • Fun fact related to the above, I got to play VR Hawken with one of the first Oculus Rift dev kits from a friend – he went on to create VRChat
  2. I was a salesperson for a year and a half (and hated it)
  3. I went to a coding bootcamp through Vanderbilt in 2019
    • I was a teaching assistant for 6 months on the side
  4. I got a job 2 weeks before completing the bootcamp with my current company, where I now work as a backend engineer
  5. My wife really wants a house, so I took the part-time MLB gig to help pay for it

Where Does Open Source Fit In?

Probably halfway through #2. I really hated that job. I had a great boss, but sales – even tech sales like the job I had – is just not my thing. I knew I had to get out. Coding was (and is) the easy solution.

My wife and I weren’t married yet, so I enrolled in a 3 month bootcamp which ironically started the day after we got engaged. From there, I’m sure my progression was like most people, where you’re struggling to stay afloat in coursework while trying to build up a professional portfolio and land a job.

Eventually, I broke even on the coursework and was ahead, so I had some spare time. I looked for other fun and interesting things to do with my newfound skills. I read about Raspberry Pis and thought that sounded interesting, so I bought one. And then after making a light blink, I wanted to make LOTS of lights blink, so I bought an LED matrix and all the parts to make that work. I think at the time in my sales job, they were pushing sales of giant video screens, so even if my bootcamp experience fell through and I didn’t land a different job, maybe I could have transitioned into a different role at the company to program them? It was a thought at least.


First Projects

Obviously, my first projects were simple HTML/CSS/JS websites, which I won’t get into here because everyone should either be learning to make them or already know how to. The most interesting projects involve challenge or introspection. Here are the relevant ones that stand out:

PiClock

PiClock

In learning Raspberry Pi, my first real project was to build PiClock. Most Raspberry Pi projects use Python because (at the time) Python 2.7 comes pre-installed. Because my bootcamp was mainly Ruby or JS, with this I had the opportunity to show that I could learn a new language in Python. I was able to show that I could learn and utilize complicated dependencies – rpi-rgb-led-matrix is a library that “drives” the LED board and provides a useful interface to put text and graphics on the screen – and I was able to integrate with an API (AccuWeather) to provide some additional data. I even learned to solder and implemented a motion sensor to automatically dim or brighten the panel if something came near. All in all, I put a lot of work into this to get it to where it was, but most of that work was to learn the rpi-rgb-led-matrix library.

At the time, this was the project (along with my background in Ruby/Rails) that led to my first job as a developer.

[SOURCE CODE]

MiniTron

MiniTron

(Sorry I don’t have a better image…)

The next step was to start incorporating my interests into my new skillset.

Enter MiniTron. I referred to it as a mini Jumbotron, so of course, it had to be MiniTron. I had totally forgotten parts of this project until writing this article – my bootcamp mentor was big into webscraping, to say the least, and he had pushed me to build one myself. MiniTron consumes the resulting API consisting of data that I scraped from Baseball Reference. Unfortunately, the API and webscraper I wrote is no longer active, so this project won’t function. It did, however, lead me to the open-source project that landed me the MLB job…

[SOURCE CODE]


mlb-led-scoreboard

I’ve been involved with the MLB LED Scoreboard project since late 2019. Essentially, once I realized that my MiniTron project was already realized in a mature project, I decided to contribute my efforts to mlb-led-scoreboard instead. It handled live data rather than my nightly scraped data, and all-in-all, it was just way more valuable.

The MLB LED Scoreboard integrates with MLB’s Gameday API in order to support real-time game statistics – when a pitcher throws a strike, for instance, it shows up on the display. Of specific interest to me was that the scoreboard supports multiple display resolutions like 64x32, 128x32, etc. It didn’t, however, support my board size of 64x64 (probably because it requires soldering a jumper, which most users are not comfortable with).

Clearly, this was a project in which:

  1. I have specific expertise
  2. I am able to share knowledge
  3. I am able to contribute code

Let’s talk about how I managed these three things.


First Contributions

mlb-led-scoreboard 64x64

Because both previous projects and the MLB scoreboard utilized the rpi-rgb-led-matrix library, learning the scoreboard’s syntax was fairly simple.

The repository uses a directory called ledcoords that houses JSON configuration to place all the text and graphics in the correct place on the board.

My first contribution to the project was to simply run it on a 64x64 LED matrix and create a file called w64h64.json.example (the dimensions of the board). It was pretty much just trial-and-error to tweak the position of each individual element. Since the project was already fairly mature, there wasn’t any reason to dig into most of the code – just figure out the X and Y coordinates of the text and graphics, add it to a file, and check that it’s where you want it to be.

I popped the new config file into a PR, submitted it for review, and was accepted by the repository owner. This turned out to be one of my first – and most fruitful – contributions to any project.


Community Involvement

Following my first contribution, I was able to run the scoreboard on my native hardware. From there, I was hooked. The scoreboard project does even more than my old MiniTron – it parses RSS feeds for team news, can show weather, and handles live game data. I took to learning the ins and outs of the repository in addition to the knowledge I already had of the rpi-rgb-led-matrix library. Eventually, I joined the Slack community for the project where I was able to share my knowledge with other people trying to set up the scoreboard for the first time. People can pop into the Slack channel to ask questions ranging from hardware setup to software configuration to anything in between. Parsing people’s needs requires a large knowledge of the underlying APIs (rpi-rgb-led-matrix specifically) as well as the source code to the scoreboard itself.

I have been fortunate to be involved with the MLB scoreboard Slack channel for a few years and it’s been a real joy to be able to coach new users through setting up their Pis for the first time.


Maintaining Open Source

Anyone who’s ever been involved with a project (open-source, enterprise, or even personal) knows that maintenance increasingly takes up more of a percentage of total development time. A mature project might look like this:

Maintenance Ratio

A project on (essentially) embedded hardware is more like 95% maintenance. This is the case with the MLB scoreboard. The project relies on a Python library known as mlbgame. Unfortunately, mlbgame is a wrapper around a deprecated XML API – MLB Gameday now primarily revolves around a JSON API known as MLBStatsAPI.

Most parts of the project continue to function around the existing mlbgame implementation, but it’s a ticking time bomb as it’s deprecated and MLB can change (or remove) how people access the older XML API. This is an ongoing issue as the MLB scoreboard project moves forward.

A big problem arose a couple months ago as the original API removed access to the data for standings, which raised an error for most people trying to run the scoreboard during the regular MLB season. Luckily, I was able to write an implementation in the new MLBStatsAPI, which I may write a detailed article for in the future.

Additional problems include the project’s reliance on Python 2.7, which was sunset over a year ago. This is a constant battle, and since the scoreboard is run as root and only ship with Python 2, there’s no good solution to fix dependencies that are broken other than user reports. I was able to resolve a feedparser Python 2 deprecation issue, and we’re currently tracking a pyowm dependency issue.

Ultimately, we’ll have to move to Python 3, but since I don’t own the repository, a PR will have to do.


Landing My Job Based On Open-Source Contributions

So how was I able to land a job offer based on all this?

Well, I was browsing LinkedIn and saw that a Data Operations position with MLB was open for my area. Given that I have written or contributed to code that consumes the APIs that the position would be working with, I felt it totally appropriate to apply for a part-time position. During the interview, I was able to say that I have a deep knowledge of both the deprecated XML API and the new MLBStatsAPI and wrote code to interface with each.

Today, I am officially an employee of Major League Baseball and couldn’t be happier.

Baseball


Landing Your Own Position (and My Advice to You)

I hope this article has some value for you as I realize this is a very specific example.

If you’re looking to break into the tech industry, my advice is to:

  1. Find something you are passionate about
    • Build (or contribute to) amazing things around it
    • Your contributions don’t necessarily have to be code
  2. Involve yourself in a community of professionals
    • You never know who might be watching
    • Many people in the MLB scoreboard community have reached out with their support
  3. Be able to relate your work to the job you’re applying for
    • This was my strength when applying to the MLB – I love baseball, and go to many MLB games per year (barring COVID), but the fact that I had written parts of an application interfacing with the Gameday API put me over the top

Next Time

Thanks for sticking with me. I hope this article was helpful giving some structure to what an open-source contribution looks like and how it can definitely lead to employment down the line.

Hopefully, I’ll find the time to write an article on converting the scoreboard’s dependency on mlbgame standings to the new JSON MLBStatsAPI.

In the meantime, feel free to check out my Writing a Gameboy Game in 2021 series!

Thanks for reading!