Honestly, I've rewritten my blog more times than I can't count. Why? Well, I don't have a perfect answer, but I think it's because I'm constantly inspired by the amazing blogs created by other developers out there.
Some of these blogs have advanced features, while others are simple yet elegant. Finding the right balance between complexity and simplicity is tricky. Sometimes I build complex sites with lots of features that I'm proud of, but eventually, I feel the urge to change things up because I'm not completely satisfied.
Maybe it's because I don't plan out how to build my blog or website very thoroughly. I don't go for fancy designs; I just have a rough idea in mind, inspired by other great blogs, and make a basic sketch of that idea. Then I add new stuff and features as I go along.
Last year, I didn't change anything on my blog because I was pretty happy with how it looked and worked. It had a minimalistic design and only a few features. But then I felt the need to simplify it even more. I wanted something easy to maintain and meaningful, while still looking good and modern. Now, I've ended up with an even more minimalistic blog, and hopefully, it'll stick around for longer before I change my mind again.
Avoid over engineering
I believe developers often overcomplicate things when writing software. We tend to focus too much on covering every possible scenario or following the "Don't Repeat Yourself" (DRY) principle.
Finding the right balance isn't easy, but it's essential. We shouldn't let sloppy or messy code end up in production.
Instead of rushing to add new features, it's important to take a more cautious approach. Always question whether a new feature is truly necessary, and consider waiting until we're certain it's needed before implementing it.
Businesses often request additional features without knowing if those features will actually be used. This can waste both time and money for developers and the company.
I've encountered this situation many times, especially when building new React components. While it's important to make components reusable and generic for future use, such as an "add-to-cart" button, it's crucial not to overthink it right away. Instead of immediately planning for all possible future uses, it's better to focus on the current scope and function of the component.
It's usually easier to start with a simple solution and then add more features later. For example, it's easier to begin with a basic "add-to-cart" button and then expand its features gradually.
Be lazy
My teacher once said that the best programmers are the lazy ones. At first, I was confused by this statement. How could lazy programmers be the best? But after four years of professional experience, I understand what he meant.
Being a "lazy programmer" doesn't mean avoiding work, it's more about thinking strategically. It involves asking yourself if someone else has already solved the problem you're facing, or if the problem even needs to be solved in the first place. The goal is to minimize writing unnecessary code. As Jeff Atwood famously said, "The best code is no code at all."
Jeff Atwood: “the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options.”
And another good quote by Robert Galinski
Robert Galanakis: “The fastest code is the code which does not run. The code easiest to maintain is the code that was never written.”
Indeed, it's true that the less code we have, the easier our work becomes to manage. But, we should remember that we might need to add new features or start something new eventually. It's about having the mindset to not overcomplicate things and avoid unnecessary work. It's a common tendency in our industry to add more features than we actually need, whether it's because we're working on a personal project or because our company's business department requests it.
So what did I actually change?
Not much really but I started from scratch once again creating a new Next JS application, using Tailwind css for styling. I changed the color palate with a different shade of gray. Reducing some features like filtering through the blog posts since I was not hundred percent happy with it. I will probably introduce it again but with a different approach. I will think through it a bit before I start implementing it. Other than that there are some smaller design and UI changes. I am happy how it works and looks and I will probably add some more stuff to it. Something I was thinking to add from a technical perspective is unit test and perhaps integration tests. But I. Will see how it goes with that.
Summary
The main idea here is that simplicity is better. I'm satisfied with how my personal website is coming along, although it's not complete yet. I anticipate I'll need to revise it later, either because it's too complex or because it's missing key features for a good user experience and interface. It will definitely not be the last time I rewrite or re-design my blog.