A while back, I read one of Lj Miranda’s blog posts about his year in commits, which inspired me to write a similar reflection now that I’ve reached two years of committing code.
If you’re unfamiliar, a Git commit is simply a snapshot of your work. Each box in a commit graph represents a day: green means you wrote code, gray means you didn’t.
In this post, I’ll look back on my first two years in commits as a second-year Computer Science student: what my graphs looked like, the mistakes I made, and the lessons I plan to carry forward.
In retrospect
March 18th 2024, the day I created my first commit, says GitHub at least.
I only started programming not so long ago around late 2023. My first ever real project was TagLID which was built for our research. I might have known a little bit about Git at the time but didn’t bother to use it for a while. It wasn’t until I started working on Aklish, a project also built for another research, that I began using Git.
Aklish was my last project in high school. When I started college, I finally built my personal portfolio website. To continue the momentum from Aklish, I began a larger project for Miagao Valley called Kulasisi. I spent the rest of the sem with this side project. During this time, I started using GitHub Projects and created my first issue. I also joined my first hackathon, where I collaborated with others on GitHub and opened my first pull request (PR).
For the next sem, I focused almost entirely on Kulasisi. I neither finished it nor started anything new during that time. Looking back, it was a mistake to stay locked into a single project without exploring other ideas. Despite the graph staying green, it felt like my growth had slowed and that I wasn’t really moving forward.
Despite that stagnation, I joined another hackathon where I collaborated with more people over a longer period of time. It was there that I began to understand the workflow itself (properly creating PRs, reviewing code, etc.). Up to that point, I had mostly treated Git and GitHub as backup and a way to show progress. That experience finally showed me how they’re actually used in real software development.
After hell month (I call a stretch of long exams), I finally started new things again. I started working on UniGlyphs, renux, and Backlogs, all projects for the CS50 courses. I also revamped my website using Astro, the version you’re probably viewing right now. During the same break, I began taking additional online courses, mainly focused on data science and machine learning.
This sem, I became more involved in extracurriculars and organizations. I joined a Capture the Flag (CTF) competition which we won. I also started working on the Pagbutlak Website and finished some workshop tasks on UP Data Science Society.
One of the courses this sem required us to build a project in Java from scratch. For it, I created a simple game named Tidal Island, which I worked on for almost a month. This was where I fully utilized issues and pull requests, even as a solo dev.
This year, we started working on Manobela for a hackathon I joined. This is one of the biggest projects I’ve built and led so far. Because of its scale, it was also where I learned the most about the software development process. It was my first time leading a team: creating and assigning tasks, managing pull requests, resolving conflicts, and reviewing code daily. Throughout January, it often felt like 10% of my day was spent on GitHub. The experience reshaped how I approach building and managing software projects today.
Some lessons learned
I made many many mistakes early on in this two years of mine. I might not be close to qualified to offer advice, but perhaps you’ll still find the lessons I learned helpful especially if you’re also starting out:
- Learn best practices and conventions early - I know I know, while many of these things are learned over time, applying them early can save you headaches later. Examples include atomic commits, conventional commits, branching strategies, and rulesets.
- Don’t be paralyzed by the above - Although following best practices helps, don’t get stuck trying to do everything perfectly. Progress matters more than perfection.
- Use issues and PRs thoughtfully - Early on, I treated GitHub as a personal backup and showcase. Now I see the value of using issues to plan work and PRs to organize changes
- Don’t get stuck on one project - Spending too long on a single project without diversifying led to my stagnation with Kulasisi. Multiple manageable projects help you experiment and learn faster.
- Do more collaboration - As frustrating teammates can be, it pushed me to learn workflows I wouldn’t have practiced alone.
- Create your own personal website/blog - I know some people might have told you these things are not worth taking up time for (and they might be partly right), but having a place to showcase your work and write about it is a great way to keep yourself sane.