What Is This?
This is an article that takes a look at the reasons developers might feel too fatigued to start researching something new and what I did to solve some of these issues. The specific solutions may or may not be useful to your use case, but I do have a suspicion that this sense of fatigue may be pervasive enough in our industry that on some level the themes will connect with a good many developers.
Caveats
I whine in this article. I am also solution oriented I think, but still... the whine in this article is strong. If you have an (understandable) aversion to whining you've been warned!
Not all of the problems or solutions in this article will make sense to you. I swear this comes from a place of reasonable competence with technology and I'd probably be happy to discuss the reasons why I went with particular solutions, but I likely won't take the time to address it in the article itself because a point by point comparison of potential solutions to these problems isn't what I'm interested in here. What I am interested in addressing is the larger theme of how small annoyances if left unaddressed can pile up to a point where something that was once fun no longer is.
A Very Familiar Story 📖
Hi Im Matt the developer 👾, and I just saw that Deno hit 2.0 and I read the blog and boy-oh-boy it looks neato-toledo! Well, at my job I only use Python and Node and the powers that be (you know silly people with odd amounts of cash) have no interest in me using an unproven, semi-unknown coding language on their very expensive production servers and I can't think of an internal tool I could justify using it on (I probably could I'm very creative but you get the point). Well what do I do to get myself interested in using this new very cool looking piece of tech 🤨 I know! I'll make a side project... And there it is... the fatigue 😱
If you are anything like me when you make a test/toy project you don't intentionally make it poorly. You try to think of your project, no matter how toy-ish as a real piece of software. This is a practice reinforced by many of the teachers I respect and the tools these days sort of push you in this direction anyway, but then you end up in the following traps that lead me, and maybe you too, to saying:
Ehhh I'm not even gonna bother...
For me the following internal conversation:
Oh
<insert-technology-here>looks really cool. Maybe I'll make a little project with it.Oh yeah that's right making the sorts of toy projects that I'm interested in with
<insert-technology-here>is gonna lead to me dealing with<see-traps-below>. I won't even bother.
has become so commonplace that I have found my passion for technology in general diminishing and that's sad. As any sort of professional in any field knows, the day in and day out of a job is never always fun. So what keeps us from disliking our jobs is the experience of personal growth and mastery in our craft, and when obstacles consistently arise that block these edifying experiences you can look up and find that a job you used to be passionate about has somehow beneath your feet become mundane and soul-sucking. No one wants this! So let's talk it through and see if we can figure out what exactly these issues are and see if we can create something to counteract the passion sapping issues that prevent me (and maybe you too) from learning about what's happening in the genuinely exciting field of technology.
The Traps 🪤
So what are these recurring issues anyway? Well for me there are a few broad categories. Since the ideas here are meant as a basis for solutions rather than the core of this article I'll likely just gloss them, but the issues here may be familiar to you and so you likely don't need them explained to you in deep detail and if these aren't the exact same traps you are familiar with consider trying as I am to define what traps you are experiencing and see if you can create solutions using a similar methodology.
The Traps:
- Tedium / Perfectionism
- Security / Financial Risk
- The Software Industry / Hucksterisms / Nonsense 🤣
The Tedium / Perfectionism Trap 😑
TLDR: A lot of work goes into everything around a piece of technology that isn't the technology itself, but it is an "entry fee" to using it.
This first one is the one where I usually stop and go on a walk.
Continuing on with the example above the process might look something like this:
- Oh look Deno 2.0 came out.
- Oh wow this seems cool I want to try out Deno now!
- What sort of toy project should I make 🤔
- Ummm... Well I am mostly a web dev so I will try out the Fresh 🍋 framework to make something simple like an app where a user can log their mood (why not 🦀)
- Ok cool I have an idea let's fire up Zed (or VSCode 😴) and try this thing out 🛑
Stop Right Here
Do you realize what you just signed up for for like the MILLIONTH time? The first thing you are gonna do if you are new to this process is make a web page for logging a mood only to very quickly realize that in order for this app to be meaningful it's going to need users, which means a place to store them, which means a database, which means passwords and authentication and authorization, and it means database setup scripts, and probably it means a docker compose config, and it means designing a schema no matter how simple, it also means migration processes for your database, I can go on and on I promise 😵💫
So the first trap for me is the following decision:
I accept that this toy app doesn't really make sense in the real world and I can't actually leverage a lot of the intent of the tool because the tool isn't MEANT to be used improperly and so my impression of the tool will never be complete because I didn't ACTUALLY try to use the tool as prescribed and instead hacked something together that has some very confusing sharp edges.
I create all the necessary plumbing for the MILLIONTH time knowing that it's for a toy I don't intend to actually use and further knowing that none of the work in setting up even a very simple user management system from a database point of view translates to me getting familiar with the technology I actually found interesting in the first place!
I've done both lots of times... Sometimes I strike the right balance of valid set up to learning about a new topic, but most of the time I find myself going "Why I am setting up a User schema in a Postgres DB again? Oh yeah that's right Deno 2.0 was released... and me remembering how to declare tables in Postgres is... relevant... somehow"
The Tedium / Perfectionism Solution 💁♂️
TLDR: Look for opportunities to automate "just enough" to remove the chores that suck the joy out of learning!
So we have a pretty solid grasp on the kinda yucky choice laid out above... Well, how can we solve it?
My brain very quickly says: Automate Something!
Thanks 🧠 I agree! But knowing what to automate and what not to is kinda an art so let's think about what precisely I will find myself wanting very regularly:
- A containerized database of some sort Postgres is fine
- A table in said database with a users table properly configured for just about ANY application.
-
id,created_at,updated_at,activated_at,deactivated_at,hash,password,first_name,last_name,email,phone_number,country_code,extra - With that schema I can probably get a decent way towards making any app
-
- Bolierplate statements in SQL for: Insert, Updating, Finding, and Removing (optional) users
- Scripts to backup and restore the database instance.
With these desires in mind I created matty-cale/users-table which is a very portable Makefile and a couple of SQL scripts thats will hopefully strike a balance ⚖️ for me that I find useful. In total it's about 70 LOC in a Makefile and the SQL is about 10 LOC. Pretty small. You should be able to grok pretty much all of it in about 15 minutes which I think saves you about 10 minutes of dev time the first time and potentially more the more you use it.
This doesn't solve your auth boilerplate, but that's gonna be driven by your code and is an exercise you can't get away from regardless, BUT at least you don't have to worry about the following chores anymore:
- Setting up shell scripts to automate the creation of your DB
- Creating SQL statements for creating the users table
- Creating SQL statements for inserting users into the users table
- Creating scripts to back up or restore a database
I hope this inspires you to look for the tedious chores that keep you from starting a project and automate them away using simple and portable solutions!
The Security / Financial Risk Trap 💰
TLDR: Home networks are error prone and insecure, and Cloud Services cruelly don't like to make billing transparent or simple to control (because they are greedy).
Ok, cool so with one or more little automations taking care of the tedium problem what else consistently blocks me from trying out some new piece of technology?
Deployment! So when I create a project no matter how simple I want to put that thing on the internet and there has never been a better time to "just get something out there" than now, BUT the world doesn't (typically) cater to the little guy (we lack money and that makes people uninterested it seems). What am I talking about most specifically?
Spend limits!
What I mean by this is a VERY simple feature that states something to the tune of "If my bill reaches X value please unplug all my services" until I manually address it.
Q: Could this heavy handed feature possibly hurt large apps?
A: Sure, but you wouldn't have to turn it on.
However none of the big guys offer this obviously simple feature and what's more even though there are loads of posts on the internet about this topic they seemingly never call out that it's a highly requested feature and this drives me nuts! Here are some random way you can find out how the big guys address this issue.
So what else can we do? Well, maybe we could host it from an extra laptop we have sitting around and then make sure that we REALLY understand network security because we are about to open up our home network to everyone on the planet 😵💫
The Security / Financial Risk Solution 💁♂️
TLDR: Use fly.io with pre-paid credits.
This one was actually really simple... for me at least...
So, for the big guys, if this is your preference for several very understandable reasons, both GCP and AWS allow you to automate this process by round about means where you can use one service to monitor your billing and then another service / set of services to perform operations that take your services down. This definitely feels like a middle finger to users but there you are.
However as of this writing I did find one really terrific solution that works really well for me trying to launch projects in a safe and understandable way.
It's: fly.io
They have pay ahead billing (starting at $25). The peace of mind that I could likely run for a very long time enjoying all of the services I want to try out for this one time cost (yay one time costs) is incredibly valuable to someone of my disposition. And if you run out? Well, yeah they shut down your stuff, but they won't just let you rack up an enormous bill that you then have to beg them to remove if your toy app ever gets attacked by some jerk, or (a more likely story) you accidentally allow some script you didn't really understand to create a bunch of really expensive operations.
fly.io, while not as feature rich as AWS or GCP provides everything I (and likely you) need to deliver production ready experiences if your side project ever becomes something you want to really try out and I'm supremely grateful for it. Thanks fly.io and feel free to send me swag 😉
The Software Industry / Hucksterisms / Nonsense Trap 🤡
TLDR: The software industry is changing. The way we work and how we are managed is changing. It can be hard to get excited about growing as a technologist in this environment.
Ok, so the final trap is something that has become more noticeable in the last few years for me in the industry. There is a general sense of anxiety about what we (software developers) do and how we do it. This anxiety is fed by several different factors: impending AI industry takeover, financial pressures on specific software companies, large scale economic issues, and natural developments that lead to software companies becoming more like traditional companies as time moves on and technology becomes better understood and therefore more systematically monetized.
Any one of these elements may, on any given day, be louder or quieter, but the overall effect is the same. Our industry and therefore our way of life is changing. I count myself incredibly lucky to have come into the field when I did. I came in at a time when many companies were trying to launch their first attempts at a SaaS offering and there was so many unknowns that the "Research" side of the "Research and Development" departments were given a great deal of deference. This is not the feeling I have about the industry as it stands now.
The most popular large scale web apps while still vastly unique in their composition and quality do seem to be coalescing around particular product principles that do seem to have real staying power. This shift away from (more) equal parts Research and Development, and towards a much greater emphasis on Development means that much of the joy of discovery and the personal satisfaction of finding a novel solution to a problem is fading. This is sad for those of us who see our jobs as both Researchers and Developers. But what are we to do?
The Software Industry / Hucksterisms / Nonsense Trap
💁♂️
TLDR: Keep your eyes open for what inspires you and allow yourself the space to reflect and fix what's really bugging you. Maybe all the small things you fix will create the world you want to be in.
So how do we overcome this issue of the industry changing and no longer valuing the same sorts of behaviors that it previously valued? Honestly, I don't know. I don't think there is anything for it. The future is coming and the only thing we can ever say for certain is that tomorrow will be different than today. I know this is not really a solution, but at least it's a human's honest assessment (and that can feel rare these days).
I think that something that helped me was writing this article. I was so inspired and interested in the work that went into Deno 2.0 and I was so saddened by the realization that due to my fatigue I wasn't even going to try it out that I got a chance to reflect here on why I feel this way. Sometimes it's that I just need to take 45 minutes to an hour to write a Makefile so I can remove the elements of learning that have become mundane and annoying. Sometimes it's that I need to do more research on what product offerings are out there that fit my needs. Sometimes it's that I need to be inspired enough by my peers that I take a second to investigate my apathy and fatigue and try to solve it.
For now, if you need me I'm gonna be seeing if I can scrap together something fun using Deno and Fresh, and trying to keep my chin up as I wait to see what the future holds. Stay safe out there and be open to being inspired.
Credits:
Photo by Philip Oroni on Unsplash
Top comments (0)