Dropping (and Picking Up) Projects in 2021

Hello again

It’s been 2 months (or 2 and a half!) since my last post, and that’s a long time to host a website and not post anything on it! In that time, I dropped a whole project and picked up a brand new one (or two or three).

Dropping a project feels bad and picking up a project feels good, so how do we avoid the perpetual cycle of half-published and unfinished ideas? I’m not exactly sure, but I’ll explore some of the things that I try to keep things shipping.

What I Dropped

For about 1 month from March to May I was working on a knowledge base example app in Scully. The goal was make a scalable knowledge base with some full text indexing (I was looking at ElasticSearch), and build it in Angular. I wanted to use Angular because the company I’m working at uses Angular extensively for their web stack, and this seemed like a good idea if I wanted them to adopt this project. Plus I’d just made a React app and I wanted to try something different

Little did I know that Scully was pretty bad for what I was trying to do. What I should have done instead of using Scully as a static site generator (like Hugo), is build a full Angular app then make it static in Scully, instead of trying to retrofit my experience with Hugo and React into this system.

Eventually after working for a whole month, I had nothing. Not even a simple front end or a splash screen or even a home page that I liked. It was pathetic! Every single other web tool worth its salt at least pushes you past that point, but I was wrestling with every aspect of this project. I had enough and decided that I shouldn’t waste more time on it.

Giving Up Has Benefits

I want to come away from my failure with something, and what I did learn was a few key takeaways. It’s always good to try to frame these as positive statements, because you can walk away from failures with lessons learned and move away from what can sometimes feel like a total loss. In development, and especially web development, failures are invaluable.

Scully Isn’t Ready for Primetime

Gatsby is a better alternative. This is a bit of a mean lesson, but after struggling so much with the Scully system, I tried Gatsby for a spin and it was night-and-day. This led me to React as the primary tool for my next app(s), and the more I dove in the more I like it! This was a great success, because I love learning new tech, and with React there’s a lot to learn.

I’m not saying that Scully is all bad and I have another article in the pipeline where I’ll go over some of the things I found in the project. What I am saying is that there’s other easier to use tools that work on much the same stack, so why learn the harder one on a less popular platform?

Documentation is an Indication of Project Maturity

What I realized when I was trying to work through Scully was that it was missing a lot of what I needed in documentation. I’ve complained a bit about Hugo, but really the Hugo community is amazing because if I find a weird corner the forums almost always someone talking about it, and it’s still active. Whenever I search for help on Scully, I’m more likely to find articles about the X-Files. Key lessons learned for me was that if I want anyone to use the things I make, I need to document it, and I need to document it well to get people to use and stay on projects I build.

To that end I’ve been looking for more documentation writing courses; Google, and Pluralsight have courses about how to write documents but more and more I’ve been interested in the UX of documentation. I’ve been studying some of my favorite documentation sites to try to figure out why they’re so great. Maybe I’ll have another article about that.

Deadlines are important

When I started the Scully knowledge base project, I didn’t have a deadline. That was a mistake, if my goal is shipping.

There’s lots of talk around the mantra, “always be shipping.” To a certain extent I think it applies to personal projects, and for me it’s important to keep a steady stream of things I’m proud of putting out. Finding fulfillment in development work is one of the things I’m most thankful for.

On the other side of the coin, if I’m not shipping things I start to feel bad. This article essentially took months to write because I was bouncing between projects and feeling bad that I couldn’t ship or write anything.

To reign in that negative emotion, I needed a stop point. With my new project, I had another month-long deadline to get “something done,” which isn’t a great deadline, but I’m feeling more accomplished on this project because I cheated a little bit.

What I picked Up

Out with the old and sad, in with the new and glad!

I’ve been working on replacing an old tool from 2012. I won’t say what the old app is but this new app is supposed to be a mobile app. This is new and exciting stuff; I’ve never built a mobile app. The core of an app is a parser for a Domain-specific language (DSL), and my 1.0 goal is 1:1 parity with the old language, on a free mobile / web / desktop app

What I’ve Learned so Far

React is really deep: it’s got modern SPA apps, unified mobile and web apps, and static site generators (Gatsby). With my previous app I used Redux, which in hindsight seems like overkill. For this next app I plan to keep my state a bit more flat, but I also want to implement some actual web features: sharing content, making things available to other users and all that.

This project is also a retrofit of a previous python project, and most of the parser logic was working correctly already… and then I got distracted. When the time came for me to pivot from my previous failure and rework what I’d done I wanted to use what I’d already done to help out. Luckily translating between Python and JavaScript is almost painless. I was actually able to copy most of my work, rework the indentation, brackets, mappings, for loops, etc. and get a usable mess to debug. But that’s when my last lesson came into play.

Finally, TDD. Test driven design is great for apps like parsers. It’s so useful that I don’t know how I’d even start to work this project. So far, it’s revealed parser errors, math material logic errors, and mapping errors in the original code that are now squashed!

Smaller Projects

I tend to burn out on projects if I hit them too hard (maybe I’ll write about how I deal with that in detail in another article), so if I can slow burn by having smaller and easier to knock out projects then I keep a small backlog.

Spruce Up The Site

I’ve been told that this site is a bit spartan: I’m looking at adding more pictures and flair to some of the design. I did update the GitHub icon! I’m also working on getting more visuals in a few ways: one of which will get an article. All those and more will be coming, but most won’t get a major article or update; you’ll just see them!

Vue on the Horizon

I’ve made sites in Angular, React, and plain-ol C# .NET. I want to try out the last of the big 3, Vue is last on the list. From what I’ve seen, it’s nothing too odd or out there, but we’ll see what happens.

Get your Game on!

I’ve seen a lot of interesting jobs that deal with C and C++. It’s been a long time since I worked in those languages, and while I’m sure I could swing it, I really gotta re-hone my skills with those tools. For an engine that lets you get in and mess with stuff and lets you write c++ code, I’ve seen the Godot engine. Other options include the Source (and Source 2) engine… but I’ve heard tales of that being particularly tricky: there’s spaghetti monsters in there.

I don’t have anything set-in stone, but I want to try at this specifically.