Lessons Learned from Migrating a Blog, Again
8 years ago, I migrated the blog you're reading for the first time.
I was living at Tai Po, Hong Kong, at the time. I graduated from the coding bootcamp, working as a programmer at South China Morning Post. I breathed coding day in and day out. I coded for a couple of hours before I went to work. Then I walked my wife to the bus stop where she took the bus to go to her workplace, and I continued walking to the SCMP office. I lived in a place that is a 20-min walk distance from my office. I coded for another nine hours after I got to my workdesk. Most of the time, I took another walk home after I was off from work. Met my wife somewhere between her and I were at and had dinner before going home. I watched some more coding tutorials after I got home. That was pretty much my everyday life at that time.
I was very happy. I didn't really have a definition of what a programmer is. Some people say he's a frontend guy, she's a backend girl, that's a DBA, and that's an Ops. I just wanted to learn all of these technical topics. Hence, I learned what I can learn in the workplace to fulfill my job responsibility and learned what I cannot learn from the workplace in my leisure time. I was learning all the time. Building random applications on the side became my routine, and the blog was one of those learning materials.
In 2016, I was a programmer.
In 2024, I am a programmer AND a product manager.
The blog is no longer just a piece of learning material. It's the backbone of my company. I need to manage it as a product. The lessons learned are no longer just technical but also product management.
Lesson 1: Don't reinvent the wheel
It's a rule of thumb for any programmer indeed. But if you're a programmer in the learning mode on a certain technical topic. I'd suggest always going to the basics first. Building application is like building a house. You can have a house by getting it from some out-of-the-box source code. You have no idea how it works behind the scene. It's pre-packaged for you. You can build the entire house without knowing how it works. It doesn't serve the purpose of learning.
So after the learning mode is over. You have a full picture. You understand how the data is retrieved from the database with backend, and how it gets propagated to the frontend for presentation. Like the water flows through the pipeline and can be used when it's coming out of the faucet. That's the moment you should consider acquiring some pre-made technical components. For maintaining a blog, they are some web services like CMS, server hosting, DNS, etc.
Lesson 2: Document everything
Writing comments when writing code is a best practice; Writing documentation when building a product is also a best practice. Even though I already have some comments written for the code for my own program, I sometimes still don't understand what I've done in the past when I review the comment.
What will happen if I didn't? It'd be chaotic.
Hence, documentation is very important for product managers. It's a communication tool. You use it to communicate with yourself and your future teammates. I'm just a solopreneur for the time being, but I still need it so bad to let my present-self to communicate with my past-self for the potential future product growth.
Lesson 3: Iterate again later. Satisfy with what you have for now.
The blog you're reading is a version 2.0. It is empowered by ghost.org and its current version is Ghost 5.0. In 2016, the blog 1.0 was built with Ghost 1.0. I wouldn't know it would have server hosting and many other cool services I now have 8 years later.
For example, Chain Executive Officer (it was a different name before) is a private email newsletter that came along with the blog 1.0. I integrated the blog with newsletter services like Mailchimp and ConverKit because Ghost 1.0 didn't have a newsletter syndication service back then. Everything works but the workflow is a bit complicated. Nowadays the newsletter syndication is managed under the hood of ghost.org. It's an all-in-one solution perfect for independent publishers. The workflow for publisher is seamless. The user experience for readers is frictionless.
In other words, if I wait until a perfect solution exists in the market, you wouldn't even have a chance to read this article now. So the caveat is: the future will always be better, and the present will never be perfect.
Don't wait. Take action now.