eldelto
Created:

Building More Faster Part 3 - The Need for Speed

This is the last part of this three-part rambling series. The other posts can be found here:

The biggest limiting factor with any hobby project is always time. I only have so much to spare time I can poure into projects that I have to make up for it in another way. This is what this post will be about - gracefully cutting corners.

First, let's try to identify what sort of tasks eat up most of my time, are not directly related to the problem I want to solve and how I could mitigate some of them.

The Cost of Making Websites

Probably the single biggest cost is my knee-jerk reflex as a web developer to make everything a website. There is always that voice inside of me that pushes me in that direction because it might be useful to someone else and maybe, just maybe I am lucky and it will be the next hit on the interwebs.

Even though making a internet-facing website does open the door to many possibilities it also comes at a huge cost. All of a sudden my simple local application has to deal with:

  • Authentication
  • Deployments
  • Persistence
  • Security

... and many more.

Which really raises the question - is it worth it? And who am I trying to impress?

I'm not a big marketer so the chances that one of my websites gets discovered by a large audience is pretty slim. So when I'm not optimizing for discoverability I should optimize for getting things done, meaning I should stop and really consider if a simple CLI tool couldn't do the job as well. They are straight forward to build and one can still build beautiful and very usable applications that are solely text based.

Project Boilerplate

Should I still decide to make a website (damn you inner web-dev!), I suddenly have to deal with a lot of complexity. Software needs to be deployed, data wants to be stored securely and somewhere user management plus authentication also gets thrown into the mix.

As before the question should be, what do I really need? Often times the first instinct is to go with an industry-proven solution which, more often then not, is total overkill for what I want to do but for sure a lot more work. Some examples from the past where I could successfully replace some best-practices with more pragmatic choices:

  • Deployment via Docker containers on either Docker Swarm or Kubernetes => Has been replaced with running binaries on a bare-metal server as systemd services. This way I still get automatic restarts and even centralised logging via journald, while the whole setup is usually just a single .service file.
  • Stand-alone database server (e.g. PostgreSQL) => Has given way to embedded key-value stores for most projects as it is just another thing that needs to be managed and most of the time I'm fine with storing/loading blobs of data.
  • Project setup => Now a thing of the past since most of my new stuff lives in a single mono-repo and there is very little overhead in starting something new.
  • User management / authentication => That's still a big one. I mostly just don't support multiple users or put it behind basic-auth but it is not very satisfactory, so at one point I should implement a simple authentication mechanism once for good.

Long story short, I think a lot of the pure boilerplate-based overhead can be mitigated by either aiming for a simpler solution or to implement it once properly so it can be reused by multiple projects in the future.

Devious Design

Web design is likely to be the single biggest sink hole for any project I've done. For once because I'm not very good at it and second there are just always things one could improve - a different border here a slight drop shadow there, it's difficult to say when it's good enough.

The best solution would, once again, be to completely sidestep the problem and just don't build a website when the target audience is mainly myself.

The second best thing to do is to throw my ego out of the window and just settle for a utilitarian design without any bells and whistles. It still gets the job done and the time to build it is probably 1/10th of a pretty solution.

Tech Stack Paralysis

Ahh, my favourite guilty pleasure - never really starting a project because it actually might be better to do it in Elixir, Rust or ol' reliable Java?

I can't count how many hours I've already wasted by working on a project a bit, reading a blog post about <insert trendy tech of the day> and thinking to myself that I should probably use this more productive tech stack instead, yippiiiee!

Although it is quite valuable to experience different angles to problem solving, it also comes with a huge cost to change technologies, especially programming languages. Every time I switch, I have to go through the hassle of figuring out how projects are laid out, how to build all the resulting artifacts I need, how dependency management works, which libraries are well maintained in the ecosystem and the list goes on and on.

All of these issues are mostly eliminated if I just stick to what has worked for me in the past (as long as there is no techinical limitation that a given tech stack is not a viable choice). It's pretty great when I can reuse previously built code for a new project and this effect just compounds with every project I build.

Verdict

Saying no to potentially cool features is hard and only solving the problem at hand without wandering off and solving a more interesting but purely theoretical problem is even harder.

With some discipline it is for sure possible to arrive at a working solution in a short amount of time but exploration is also a big part of what makes programming fun for me. As with all things it's a probably a question of balance - finishing up before motivation runs out but still explore alternative tech to learn something new.