How I Started Programming
How You Can Start Programming Too!
Let's Begin!
Hello! My name is Tyler Serio. At the time of writing this I am a Python developer with more than a decade of experience with the language. I have done data analysis for hydrogen fuel cell researchers, matched 14,000 year old DNA to the closest modern organisms, have automated laboratory systems with programmable logic controllers, applied machine learning models to experimental data to identify trends, and even designed a few websites (like the one you're on right now)! I've got experience with HTML, JavaScript, CSS, and dozens of Python libraries.
In this article we'll be talking about how I started, and hopefully this will show you how it can start for you too! If you don't want to read the entire thing, there is a handy "too long, didn't read" section for you at the bottom (I know you're busy too). This section contains the basic steps I believe you need to take to start programming right away and I'd recommend giving it a read if you want to quickly get into it.
The easiest way to begin something is to just begin it. It doesn't matter what language you pick (though I would highly recommend Python). And it doesn't matter where you start either, so long as you do. Just pick a problem and jump right in and prepare to make lots of mistakes, because that's part of the job. I'll tell you how it all started for me below. Fond memories.
The Indian River State College science building. Spent a lot of time here!
Image from GreaterPonce665 on Wikimedia Comons. License: CC BY-SA 4.0.
How Programming Started For Me
When I was in college I was working at a warehouse and looking for volunteer opportunities to pad my resume. I didn't know I was going to become a programmer, though I did take a basic Python course while in school as part of the general education requirement. I believe I took the class as an elective. My friend Zach in high school taught me a little bit of the language a few years earlier, but I hadn't used it much by then for anything besides text adventure games and silly print statements. My original major was electrical engineering, and later biology (and eventually computer science). And so I wasn't picky about which volunteer positions I applied for so long as they were what I would call "science-adjacent". At one point I volunteered to do data entry at a small aquarium in a city called Fort Pierce, for instance.
The opportunity I settled on was as a volunteer with an organization called OVIASC (the Old Vero Ice Age Sites Committee). This was a group funded by local millionaires who wanted to research an archaeological site discovered about a century earlier by people digging a canal. They were excavating the site, collecting artifacts and fossils, cataloging soil layers, and searching for signs of prehistoric humans. A fun fact is that the original workers on the canal called the police after finding human remains. When they realized the bones were much older than expected, the place was called the Old Vero Man Ice Age site. Years later, if I am remembering correctly, researchers found out the bones did not belong to an ancient man but two different prehistoric women. The name was never changed because the "Actually Two Different Old Vero Women Ice Age site" was just too much.
My job as a paid volunteer for this organization was to show up to the Indian River State College main campus a few times a week and sort dirt under a microscope. We sorted grain by grain with an iron pick, separating quartz from any bits of flora and fauna we found, and especially saving any pieces of charcoal we happened to find. The charcoal pieces were assumed to be indicative of human presence, which was especially important to the committee, and knowing which soil layer the charcoal was found on was useful information to them. Perhaps one of the most exciting days we had in that lab was when we found nearly all the pieces of a prehistoric cockroach. The ancestors of the modern animals look very much as ugly as their descendants. Awhile later I would relive this glory as an intern in a benthic laboratory. While picking through a mason jar of lagoon mud to catalog the species contained in it, I managed to find all ten limbs belonging to the body of a crab that was less than the size of a dime.
Working as a dirt sorter was fun. I got to see big fossils up close, as a small museum was created in the lab to draw attention to the project. These included giant sloth teeth, giant armadillo wrist (ankle?) bones, and all sorts of strange rock-like shapes that were once part of giant prehistoric animals. I listened to Margaret (another volunteer) tell us about the viral (or maybe bacterial) lab that she managed in Georgia, how fast she could speed down I-95, and her love of Kraken and Coke (a delicious rum combination). The lab manager, Dave, told us stories of flying down to South America in his youth. I met a lot of other folks too as we sorted dirt under microscopes together.
This task itself was not related to programming, but what it lead to was Dave introducing me to a biology professor, Robert, who had another job for an intern and was looking for help. This professor was collecting DNA from the archaeological site, sending it to a lab to be analyzed, and then was receiving the genetic sequences back listed as characters in a digital file (called a FASTQ file). In order to find out what organisms these sequences belonged to they needed to be input into a database to retrieve accession codes. Then those accession codes were inserted into a different database to retrieve organism information about the sequences. This is where I would eventually be able to apply my developing programming skills.
A Florida terror bird. Never found one of these under a microscope.
Image from Amanda on Wikimedia Commons. License: CC BY 2.0.
Finding A Programming Problem
Dave introduced me to Robert one day at the lab, who then described his problem to me in his office. These DNA sequence files were hundreds of thousands of lines long. And he had a lot of files. Each sequence matched to some organism. To learn what organisms might have been present at this archaeological site 14,000 years ago, he needed to know what organism each of the DNA sequences in these files matched too. He was having interns manually execute this process. For dozens of files with hundreds of thousands of lines each this process would have taken decades if you wanted to use the power of interns alone.
This is how it went. An intern would open a sequence file and go down it line by line. They would copy and paste a DNA sequence into an online NCBI (National Center for Biotechnological Information) database of accession codes. Then they would copy and paste the accession code they just retrieved into another NCBI database to get the organism information. DNA sequences might match to mouse liver cells, or drosophilia eye cells, apteryx lung cells, or anything on this earth. Some sequences match to very strange things (sometimes things like "crystalline organism", and I still don't know what that is). And to complicate things further the DNA sequences listed in the file aren't always exact matches to DNA sequences listed in the database, meaning there is a continuum of probable organisms related to any one DNA sequence. Maybe it's gorilla DNA, or orangutan DNA, or chimpanzee DNA. You can't be entirely certain given the possibility of DNA damage or the sheer random chance that can be introduced in the actual sequencing. And so when it came to stating what organism any DNA sequence might have belonged to the interns would just copy and paste the most probable organism listed and leave it at that, which means you potentially lose out on some relevant information. For instance, terror birds existed in Florida 14,000 years ago, and they may have genes similar to either kiwi birds or ostriches, but if you only choose one of those organisms to look at you could miss something important about terror bird genes (if anything). Here you can see an obvious flaw in relying on human brute force, as it becomes impossible to take into account some information that might prove very useful, while a computer program can overcome this limitation with relatively little extra cost in running it.
I did this process myself for a little bit. I enjoyed it. There was something cozy about mechanistically discovering what DNA was related to what organism, despite the obvious tedium. I don't remember for how long I did this for, but I do remember recognizing that this problem had an obvious programming solution being that it was so mechanical and repetitive. You can already see how this process is carried out.
Open the text file of sequences.
Copy the line with the next sequence.
Access the NCBI database webpage.
Insert the sequence into the text input field, and press enter.
Retrieve the accession code from the database output.
Access the other NCBI database webpage.
Insert the accession code into the text input field, and press enter.
Retrieve the organism information from the database output.
Paste the sequence, accession code, and organism information into the columns of an Excel spreadsheet.
Repeat.
Close the NCBI database webpages and the text file of sequences when finished.
It was a tad more complicated than this. The sequences don't come back to you in a file where each line holds a single sequence. They come back from the lab in what is called a FASTQ file. Rather than one sequence per line, you get four lines per sequence. One line is a header for the sequence, the next is the sequence itself, the third is a separator character, and the fourth is a list of characters as long as the sequence with each character representing a confidence score (the probability that the nucleotide stated is the actual nucleotide present in the DNA).
I won't bore you with all the minutia right now, but you get the gist of what the problem was and how it was solved.
.jpg "The humble kiwi.")
It's pretty cute, but if it were 6 feet taller you'd have a problem.
Image from Kimberley Collins on Wikimedia Commons. License: CC BY-SA 4.0.
.jpg){kind=link}
Actually Writing the Solution
I was young and excited to be working on something that seemed useful and unique. I spent a sleepless weekend working out how to make the program. How can I make Python open a file, so that I can get a line from it to place into the text field of the online database? Well, Python can natively open files, so a quick Google search led me to the language's documentation, some Reddit posts of the same question, and some code snippets on Stack Overflow. That's the first part of the problem solved. How do I close the file? Well, same thing, it's in the documentation. Reading the lines of a file is too, and from there saving a line of information is as simple as assigning a variable the same value as that string. There was some formatting that needed to be resolved, such as removing invisible escape sequences (things like "\n" and "\t" that denote new lines and tabular spaces), and making sure no extra spaces were in the string I was about to place into the online text field. How do I access a website with Python? There's a library for that. How do I copy text from a website in Python? There's a beautiful library for that. How do I slow down my program so that I stop getting my IP address blocked by the servers hosting the database?
This email is a trophy of sorts.
Image from... me! License: Sure, you can use it.
All these questions lead to search engine queries that brought me to the library I needed, or the post I needed, or the guidance of someone who knew more about what I was trying to do then I did. These questions also brought up more questions from strangers online. Uncomfortable questions, questions like "Why do you even want to do this?" and "Why don't you know how to do this?" and "Why wouldn't you just use [entirely different language or approach]?" It's important to consider these questions, and usually a good idea to ignore them. You will eventually find the knowledge that you seek, or come up with it yourself.
For the purposes of this story, the actual code I wrote is not important. The process of learning is what is important to you. It cannot be stressed enough, you are going to make piles of mistakes. Some of these mistakes are going to feel impossible to surmount. You're going to get mad about it. Then you'll solve the problem and realize it was way easier than you thought it would be. Just get in there and try to make it happen and you'll learn a lot.
The Results
What I came up with was a program that could open a FASTQ file, copy a sequence from it, paste that sequence into an online database, copy information from that database and place it into a different database, and then copy the organism information retrieved from that second database, and then place the sequence with its accession code and all relevant organism information into a single line of a different file. This was repeated over and over again for ever sequence in the file until the end of the file, and what we ended up with was tons of files that now had sequences matched with the organisms they were related to. From there, Robert and I worked together for years developing other DNA analysis methods along similar veins.
The literal end result of this specific programming endeavor I talked about above is the lead authorship of a paper about the DNA analyzed at the Old Vero Man Ice Age site. After years of development the professor and I created what we called the Bailey Pipeline, a novel DNA analysis pipeline that made use of the original process of comparing DNA sequences to some databases, with about a dozen other added steps like judging the age of the DNA sequences, removing certain kinds of thymine ends, and removing low-confidence sequences altogether. This is an entire other story itself and this article is already pretty long, so let's go ahead and finish this one.
From there I've programmed professionally at a marine benthic laboratory and a hydrogen fuel cell research laboratory. I've written my own websites, created my own programs for fun, and dabbled in video game development, all rewarding experiences in themselves, and all because I had some basic programming experience before having the opportunity to work on a big and interesting problem. This is how it starts, and how it can start for you too.
Learning how to program has been an important process in developing a tool I've carried with me in every part of my life since. At its core, software development isn't about the language you choose or the computer you use, or what you work on. It's about solving problems programmatically, and a strong ability in problem solving is a major advantage in every situation. I can confidently state that programming has better equipped me to deal with the world in general and that I've gotten much farther in all aspects of my life because of it.
In Summary
And after reading all that, you can see how things snowball from small beginnings to something greater. It started in high school with a friend teaching me to make print statements and text adventure games using a crazy thing I had never heard of, Python. Then I was volunteering as a dirt sorter, and happened upon a problem that could be solved programmatically. From there, my skills developed to meet the challenge I had taken on. Then eventually I had enough experience in programming to start working on much more complicated things, which then led me into research labs and to solving problems with software for a living.
TOO LONG, DIDN'T READ
Pick a programming language. It really doesn't matter which one, though Python is highly suggested for beginners.
Learn the absolute bare minimum to install the language and create a file that can be run. This process is commonly called "Hello, World!" and is half of your first battle.
If you are an enterprising and forward thinking individual, read through your chosen language's documentation. This is the far more difficult second half of your first battle.
It's okay if you don't understand the documentation. Most people are bad at writing it. Just give it a shot and see what you can figure out.
Next, find a problem to solve. Pick something simple that can be broken into steps like "copy a line from a file, access a website, input that line into a field on the website, then press enter, and retrieve the returned information from the website."
Start working on the problem by learning how to accomplish each step, then try to make it happen. When you're first starting out every single step is going to be an entire process by itself (these will be questions like "how do I import a library?" and "what library should I use?" or "why isn't this function working [perhaps that specific library is outdated]?" and "what is the difference between a function and a method?"). This is where most of your learning at the start will happen.
For instance one of the very first, infuriating things I learned when I started with Python as a teen is that "def _init_" and "def __init__" are two very different things. You will learn little things like this, whether you want to or not, and it will become second nature.
Use internet resources like GitHub, StackOverflow, Reddit, and other online forums to search for solutions that other people have created that are related to what you're working on. DO NOT copy and paste their solutions. Learn from them.
Once again, refrain from copying and pasting solutions. You should instead review the code that you believe will help you, learn why it works, and then type out your own version. The important part is that you write it yourself so that you can understand WHY it works. If you absolutely must copy something, TYPE IT OUT by hand.
I once typed out more than a thousand lines written by someone using the PyTorch library to apply a neural network to fuel cell data. I didn't understand most of it, and I learned a LOT through that exercise.
Make profiles on those internet resources listed above so you can ask questions and seek guidance. Be prepared for lots of questions like "Why would you even do it that way?" and "Why aren't you using [other thing]?"
If you use AI to ask questions, take EVERYTHING with a grain of salt. Double check everything. They make up gibberish often!
Once you get a program working, try to break it. You are going to make tons of mistakes. Some of them will be so simple you'll have trouble fixing them. Stay observant!
One very important tip: leave comments in your code so you know what specific sections of it do, and why you did things the way you did. Keep them concise. Keep them short and informative. It really makes a difference.
Happy Programming!
Good luck! Others have done it, and you can do it too. It's easier than you think to learn, and fun too!
Guido van Rossum believes in you!
Image from Doc Searls on Wikimedia commons. License: CC BY-SA 2.0.
