why does this blog exist? why is it the way that it is?

i’m not too fond of the shape in which this blog exists. the file structure is messy. i’ve set up a backend but it doesn’t have everything that i want. i can probably imagine ten different ways to improve the frontend design if i were to make a list. i made an amateur logo and downscaled pixel art, probably botching the design in the process. the colours are a bit off, the favicon is probably asymmetric, i don’t really know what i’ll write about. i don’t know how i’ll implement comments or analytics.

i’m using someone else’s theme instead of designing my own. i have twelve tabs of websites bookmarked that i want to base my design off of, but i don’t have the time to make components from scratch. i don’t want to use react or angular or any fancy js frameworks, and i am a backend developer to begin with really. i could probably make it with raw html / css / js, but that would take far too long and probably not be responsive anyway. i don’t know web design.

there’s a case to be made that this site should not exist. it could probably be made far better in pre-production. at a psychological level, i suspect it would be unhelpful to bite off more than i can chew. i want to design a great website, sure, but i also want to be able to write thoughts as and when i have them. i don’t know yet about what the structure of this site will be. i have some ideas, but i’m not taking them to completion until i get a few posts written first.

i’m not a designer. i’m far from a good artist. but design is not just making sites and objects look pretty. design is a necessity even for backend developers, data scientists and arguably people in other professions as well. good DevX is paramount, and thus is good code organisation. packaging, style guides, naming and namespacing conventions. good.

i have moments of “genius” every now and then when writing code.

if i wrote a VSCode task connected to a bash script that ran a makefile build task and uploaded the result to AWS, i could save so much time uploading lambda functions!

and then i remembered that i don’t really know how to programmatically upload a lambda to AWS (OAuth? yucks). i could learn, and that might take time. but i have my own deadlines to meet, and this might not be all that helpful (it wasn’t! bootstrapping CD doesn’t make sense in early development, you should be testing locally). but i did write down the makefile. and that was kind of helpful. and if i ever want to make that fancy task (i probably won’t), i can.

does that anecdote prove a lot? probably not. but this isn’t about proving any point. i want to write down the ten concrete things i dislike about this blog, otherwise they’ll be a hundred vague things in my head. coincidentally, this is why TODOs are a great idea (if you actually keep track of them). likewise, this is why i like markdown blogs far more than something like wordpress, substack, or medium. i can write in whatever i want. all the code that runs my site is publicly available. if i want to move things around myself, i can! ymmv.

and for all the crying, i still put a lot of work into designing this blog. besides the research, i spent a good amount of time customising the Stack theme. thankfully, it’s code written well enough that you can modify it somewhat conveniently. it’s not perfect, but i love it more than i would love most other blogs. and that’s enough for me.

and yet, i will probably improve on everything about it. if i want to change colours, logos, or structures, i can do so in less than an hour. i’m sure i’ll eventually find something that makes me take back these words, but i do expect this to fare well in most cases. here’s to the future of Something Radical.