Who Am I?

My name is Bones. I’m a self taught C++ and Python developer, focused on fast, efficient, open-source software. I specialize in low-level C++ coding, as well as high-level Python scripts. I believe that software should be fast, intuitive, and free for everyone to study and improve. I learned how to program the hands-on way - reading documentation, experimentation, and sharing what I built. My goal is simple: write programs that respect the user, that respect their time, that run smoothly, and that don’t harbor any bloat or hidden agendas.

My Programming Philosphy Link to heading

My approach to programming is simple yet effective, and is built on three core principles.

KISS - Keep It Super Simple Link to heading

Nothing kills a project faster than disorganized, over-engineered code. When I design a solution, I aim for the simplest method that meets all the requirements. Sometimes you also need to plan ahead for future changes, but generally speaking, simplicity is often the most powerful tool for writing clean, maintainable code.

SRP - Single Responsibility Principle Link to heading

Code should do one thing, and do it well - that is the essence of the SRP. Small, self contained units of code are much easier to test, reuse, and extend. Decoupled code naturally will have fewer dependencies, so it can be lean and efficient.

DRY - Don’t Repeat Yourself Link to heading

Code duplication multiplies bugs and maintainence work. Programming is about automating - write once, execute forever. A codebase free of copy-paste logic stays lean, readable, and easy to develop.

These principles all reinforce one another. Following KISS naturally leads to SRP, and SRP naturally leads to DRY. It’s a beautiful cycle, don’t you think? Nevertheless, it’s important to review your code often. Have other people review it too, if possible. Studies show that having even just one other person reviewing your code pays massive dividends compared to reviewing it solo - that’s Linus’s Law in action. If you’re the one planning the project, don’t delay fixing bugs or glaring issues - the longer they’re around, the tougher it will become to fix them later. Better to be proactive - do it right the first time, or prepare to have to refactor it all over again.

Why Am I A Programmer? Link to heading

I love programming, and I wanted to do it as a living because programming is my passion. Software Development is an art, a delicate balancing act between complexity and completion. Many modern apps ship with glaring bugs, or sluggish performance - but it’s not because developers lack the skill to fix either of those things. In my humble opinion, software isn’t hard to make, nor is it hard to fix or debug. The root of the problem is this: business priorities reward new features and short-term profit over long-term quality. I believe software can be elegant and efficient when teams put clarity, intuition, and reliability at the forefront of their ethos. I reject the trend towards endless feature creep, invasive data collection, clunky UIs, and apps bloated with irrelevant features. Hardware gets better every year; our software should be getting better with it. Many businesses in software development use hardware advancements to justify these practices, but where’s the logic in that? If hardware keeps getting better, but software keeps getting worse, we’ll be stuck in a limbo of metiocrity. I reject this notion - I think apps should be optimized, regardless of how good hardware gets. That’s where I come in. I write code that fixes all these problems. I may be just one guy, but I prioritze code that is performant, intuitive, and easy to maintain and extend. My programming bleeds with my passion - with care, thought, and all my hard-earned expertise.

How Did I Become A Programmer? Link to heading

I was never formally taught. I didn’t have any fancy coding classes in school, I never went to college, I’ve never even read a book on the topic. I learned programming by, well, doing it. I looked up how to do it online. Every time I didn’t understand something, i’d read the documentation. And when that failed (it often did), I either used trial and error, or I found a convenient YouTube video that explained it better than any 5 page document of tech jargon. Why did I want to program? Well, maybe I just liked technology and wanted to know more about how it worked. Back then, it was just curiosity and a fleeting feeling I wanted to chase. But now? I want to program because I want to be able to tell my PC exactly what I want it to do. But don’t feel left out - I want other people to be able to do that too! That’s why all my code is Free and Open Source Software. I don’t just make an app and call it a day - I make an app, then I share it with the world. All my hard work will help other people get ahead for less, and that’s the definition of cool right there. Not to wear stylish clothes, or to talk a certain way, or even to memorize a complicated handshake - it’s to help your fellow man, to contribute to the progress of humanity. That’s the whole goal. I want to help indie game developers get their start, or maybe some AA studios who need extra man-power. I want to help fellow software engineers like myself make programs that do their job and do it well. I want to actively help anyone who goes against the industrial norms of half-assedly working on software, because that’s how I contribute to a better tomorrow. If you want to see change, then be the change. Create the change. Start a movement. And that’s just what i’ll do: i’ll make software great again - one line of code at a time.