Code Inventory

I occasionally meet younger developers and having our conversations about software development. I often hear the same question: “You have been in this industry for such a long time. Do you have any advice on how we can improve as software developers ?”. My answer is always the same: “Yes, be curious, try new things out and build a code inventory”. I think, if you are on social media, you will enough motivation videos on “stay hungry, curious and foolish” but in this article, I will rather focus on the inventory part.

I recall the days when I started writing my first line of code on my Pentium 75 PC. It was the late 90s and the economic forecast in my home country was bleak. High inflation rates relentlessly squeezed the mid-class to the brink. Six days workweek was almost the norm in Turkey. My dad worked tirelessly, but a PC was actually a luxury item. Savings were dwindled long before we could afford to buy a PC.

So it took a decade before we could afford a PC. In the meantime, I grew up and started high school in my hometown. I already had a few programming hours under my belt at the high school, which was unusual for a state school at that time to offer students a computer lab and teach programming. Basic was the very first programming language that I learned. The progress of learning sped up as I got my first personal computer. Pascal, Delphi, C, C++, and many more. I was trying to write a software to chat with other people over a barely connected computer via a 56K modem. Or to understand how to develop my own VCL components in Delphi. Even I tried to write my own operating system with C but quickly lost my focus once I discovered the speed of feedback loop with web development.

I wrote countless lines of code across many programming languages. One habit became second nature: backing up my code. Initially, I relied on copies on a separate hard-disk partition, but later, after I purchased a second-hand 4x CD-writer, started burning them onto CDs. I still have the copies from the 90s today and review my code thirty years later. I eventually created a personal code inventory, which I can pull out when I need to revive my coding skills in a specific programming language. Today, the compact disks maybe do not exist anymore, but there are better options than burning data onto a hard medium. The service providers like Gitlab, Github, Bitbucket, etc. offer free version-controlling options, which you can use to create your inventory within seconds.

But, what is the value of creating a personal code inventory and maintaining it? A code inventory is like a collection of old photographs—it lets you compare your current coding skills to your past ones. I occasionally dig up old projects and review them just for fun. Sometimes, the old code disappoints me, and it can even be a little embarrassing when I realize I published my spaghetti code online without any tests. But that’s okay. More often than not, though, I’m amazed by the solutions I came up with in my mid-20s or the elegant designs I crafted from scratch.

An inventory can also help you kickstart new projects by repurposing reusable components from past ideas. That’s why it’s important to aim for higher standards, even when working on hobby projects or prototyping ideas. Keep in mind—the code you write today might still be valuable years down the line.

Maintaining a public project inventory also gives you the opportunity to collaborate with other developers. By publishing your projects on public Git repositories, you can contribute to the open-source community. When sharing your code, it’s important to maintain high-quality standards because the code you publish is visible to everyone and becomes a reflection of your expertise. This process encourages you to think and act like an engineer, helping you shape and strengthen your engineering mindset.

I have many personal projects in my code inventory that I still re-use in my daily work. I’m passionate about challenging my skills and implementing ideas I find interesting, even if someone else has already created a widely-used, popular project. There’s immense satisfaction in saying, ‘Look, Spring is an outstanding framework, but I’ve created my own minimalistic dependency injection library.’ It’s rewarding to have walked the same rough path that those industry-leading projects once did. This experience helps me better understand the challenges, think more creatively, and develop new ideas based on existing ones.