Background

Trying to have/maintain projects in addition to family, other hobbies, and work is something that feels overwhelming sometimes. There are a few project ideas I haven’t even prototyped out due to just wanting to avoid having something to potentially maintain (IE the ‘work’ part of a personal ‘fun’ project).

I’ve been thinking about how to avoid this (or at least make the situation better) and think that the solution that will work for me is a combination of:

  • Standardizing my tech stack
  • Focusing on frameworks where possible
  • Treating testing as a first-class citizen in my projects (shudders)

While each of these things may lead to some inefficiencies (IE my desire to have a standard set of technologies for dev-work may mean that I utilize something that may be sub-optimal for a given application) I think the overall benefits of making it easier to just focus on doing the projects and going deep into a few areas will outweigh the cons.

Tech Stack

I want to make a variety of applications and have projects that span ideas from embedded systems type work, to mobile/desktop/web apps. I don’t want to be constrained to a singular operating system and want to maximize portability. While I use Python extensively at work I’m still not sold on it being a truly portable and compilable language despite a variety of potential packaging solutions. While I don’t yet know the exact full tech stack I’ll standardize around yet the following seems to make sense to me for my personal reasons:

  • Core Logic/Multi-Platform (backend) language - Rust/Golang. My APIs, CLIs, and core backend logic can be written in Rust for cross platform support. Rust will be preferred (firstly because I did a poll on Threads and that’s what won) primarily as its an efficient, memory safe, and new language for me to learn. Obviously, if there are clear domain specific languages for a particular application I’ll utilize them but wherever possible Rust will be my ‘default’.
  • Front End(s) - Going with React and React Native in this space. While potentially bloated in some ways unifying on a singular front-end will allow me to get better with react, utilize a well-known solution, and support essentially all my target cases (web/mobile/desktop). There are some interesting looking alternatives (Flutter, etc) but as my day job is a heavy React shop, figured it wouldn’t hurt to get proficient so that if there are minor tweaks I can potentially contribute quick fixes/improvements.
  • Data Storage - This is where I’m grasping at straws the most. I realize that I think of most things in graph terms and will likely look into the myriad graphdb style offerings. I don’t yet know which solution I’ll go with (or if I’ll wind up pursuing something a bit custom in the space) but I’m hoping that I flesh this out more with some of my next projects.

Frameworks

To make this easier I’m going to also invest a bit into codegen and templatized/automated development options a bit more. The first I’m familiar with is Apache Thrift and while I’m working on staying only in Golang as my default stack it does have rust support if I choose to use that language in the future and also will allow me to support other language if I need to in the future.

As I continue to work on projects, I’ll look for other opportunities to implement additional codegen techniques into my dev flow to reduce overhead - again either through existing frameworks or potentially custom implementations.

Testing

Since I’m not a formally trained Software Engineer (again, a hacker by trade) my code philosophy has always been ’to make something quick and dirty to address the problem at hand’. Maintainability and reliability haven’t really been primary driving factors in my personal projects. One thing I learned with my cryptbreaker project is that investing in maintainability is worth it (spoiler: I didn’t invest there, and maintenance has been a pain/practically non-existent. Will rewrite that project eventually…)

To avoid this going forward I’m going to be focusing much more on ensuring adequate testing (and CI/CD) investments to ensure maintainability going forward.

  • Geoff