To code or not to code, that is the question.
On balancing activities when building in public
My last post is already a bit more than 2 weeks old. Damn.
It’s not like I’ve been idle all this time though, on the contrary.
That’s why this post will probably feel like when you’ve coded for a long time without committing anything to Git 😬
In the last two weeks, I have…
Set up my Rails project for Speakerine. I had already done the very basic rails new speakerine. I went a bit deeper into the app’s configuration and setup, re-reading Rails guides when needed.
Lost myself in some front-end tech rabbit holes. I haven’t touched Ruby on Rails for like … 14 years 😅
It’s refreshing to see that the framework has remained generally the same, but of course it has evolved a lot since Rails 2.3/Rails 3.0. So there are a lot of things I have to discover and learn, especially on the front-end side where technologies have moved a lot in the past years.
Since I have a TailwindUI subscription, I wondered whether I should use React with Rails. That led me into exploring the assets pipeline options for Rails, and how to integrate React with the backend. Which almost inevitably leads to building an API-only Rails and a heavy front-end.
At some point I thought « that’s getting too complicated », and that’s when I decided to stop .
So in the end, I decided to go with Rails’ defaults: Import maps, Hotwire & Stimulus, and using TailwindCSS for styles.
I actually tweeted about this:
With regards to my usual tweets performance, this one had a decent reach!
It encouraged me to try and continue sharing on X about my building experience.
I do find it complicated to identify what I should share, though.
That’s why I started journaling, also as a result of reading
I’ve always found the journaling exercise quite complicated to integrate into my routine, and I’ve yet to manage to do it more than two days in a row.
I found I need to be much more intentional about it, instead of waiting for things to « click » and implement themselves into my life.
But more on that later.
Let’s go back to Speakerine for now.
If I’m being honest, I am once again not going in a straight line towards my objective.
I have started by working on authentication using the Devise gem. I’ve spent quite a long time on this, much more than I had anticipated.
No matter how good I was on Rails 14 years ago, I need to shake off the dust and rust on those skills to get up to speed again.
One problem I faced was also solely due to my remote working setup.
I’m using a self-hosted VSCode instance that proxies local open ports through a convoluted URL, which forces me to configure Rails with a URL prefix that messes up URL generation.
Not ideal.
I got things to work though, and continued with setting up my webapp layout.
That’s where I could have probably kept things simpler.
The designs I shared in my last post were quite simple indeed: the app title and a form.
But instead of keeping things that simple, I went on to integrate a TailwindUI application shell with a navigation bar and profile menu.
I try to rationalise by telling myself that I’ll need it and that it’s helping me walk the learning curve to re-learn what I have forgotten.
Which, to be fair, is true.
But it reminds me of an advice a friend gave me a long time ago.
It went kinda like this:
Between learning and shipping, a project can only have one goal.
If you want to learn, start a project you don’t need to ship.
If you want to ship, use tools you don’t have to learn.
It does not mean you’re not going to learn when building something you want to ship, nor that you won’t ship projects used to learn new tech.
Just that the main goal should be one or the other.
And right now, I’m kinda mixing the two.
Maybe it’s a path I have to take anyway since I haven’t developed a full web app for a long time, but I’ll try to be more mindful of this in the future.
Now the next thing I want to get done is tuning Tailwind’s configuration to use the color theme I had in mind.
I’ll try to keep it simple this time. It’s not like I need much branding for the moment.
There, you have it. Two weeks of coding and no writing.
I almost titled this post « To build or not to build, that is the question ».
What I’m realising though, is that building in public is as much about writing than it is about coding.
Striking the balance between the two isn’t simple: once I get into coding, I want to get things done.
But this post is a good illustration of what goes on if I don’t write regularly enough: topics pile on and I can’t get deep into any of them.
As I mentioned before, there are things I need to become more intentional about.
I’ll add writing to that list.