always be side projecting

I should probably listen to my own advice more. I took a summer break from side projects, since I was exhausted from experimenting with alternative tech stacks for Ciklus, which included spending time in SwiftUI and learning some Rust.

shime @shime_sh

Never work full time. Always be side projecting.

This experimentation slowed development to a grinding halt, and I felt like my time could’ve been spent on better things, which probably caused the energy drain. See, I don’t enjoy learning Rust as much as I enjoy building cool shit from my imagination.

This was a big lesson for me because I realized that I can spend a lot of time on useless engineering that doesn’t improve the product in any meaningful way, but just evaporates hours. Learning new tech carries an opportunity cost since I’m spending my time learning instead of building. It’s fine if the goal is improving one’s skills, but one has to be careful with it when building products.

The most important thing that I would like to mention is how rewarding the whole experience is. Working on a project for a long time without any input from others feels wonderful. The opposite of instant gratification.

Building something on my own, creating it from my imagination will never stop being magical to me. The building process is a reward in itself and love from other people is just a bonus. I wish everybody would experience this.

It’s so rewarding for me that I even neglected writing this past week. It started to feel like pure theory, while building this product feels like pure practice. I want to be a practitioner and not just a theorist, but that’s a topic for another article.

Jon Yongfook @yongfook

The longer you’re in the startup game the more you realize how big the gulf is between people who talk and people who execute.

I don’t want to explain the technical aspect of building something like Ciklus, but I want to list my thoughts on the process:

1. Solving problems for myself iteratively is more fun than any game I have played. Building an app that I can change however I’d like without anyone’s permission is just amazing. Other modern apps are rarely customizable and usually don’t listen to feedback much and even when they do need months to implement the suggestions, which is why I’m enjoying this so much.

2. Quickly going from idea to implementation is deeply satisfying. Being a solo builder, I can iterate quickly and test my implementation in the real world, on myself. This is probably the main reason why I find it hard to concentrate even on reading books currently — I keep having new ideas for improvements and fixes.

3. Building side projects is generative, just like writing essays. Building them generates ideas for other side projects. Getting new ideas is the easy part. The hard part is resisting the shiny object syndrome and finishing what was started. I’ve started a new project recently, but I’ve put it on hold until Ciklus is complete, because I felt guilty.

4. Blog posts, books and even courses are just an abstraction of learning, there is no better way to learn than to build. One’s reach should exceed one’s grasp. I have never built a functional desktop app before. I have never had to deal with Apple. I have never built a product with paid subscriptions before.

5. The first thing that surprised me is the amount of complexity. What looks simple on the first thought and when planning and estimating, has become much more complicated when I’ve started implementing it. Reality has a surprising amount of detail. That’s the main reason why I did a poor job with the estimate and broke the initial one and postponed the launch date by a whopping 12 months.

   In retrospect, I think postponing was the right decision, because I want to deliver high-quality products to people. I don’t want to half-ass it. While everybody talks about the risk of launching too late, saying that the more you delay the launch, the smaller the chance of ever launching it, I think there’s another side of that coin: launching too early.

   I don’t think half-assing it and rushing to hit the market as soon as possible is the right strategy. Yes, I am aware of the danger of building something without feedback and the risk of working on something for many hours and then realizing that that’s not what the market wants. But, since I’m building a product that solves my own pain, by using a product I also give myself feedback. And I want to build something that is amazing for my use case and then get feedback on it from others, and not the other way round. Time will tell if this was the right decision.

6. The second thing that surprised me is how hard it is to write something maintainable. I wish every programmer worked on a project long enough to see all the flaws in their own code. Working solo on a project is a different experience than working in the team. The finger of git blame always points back at me.
   
   My biggest mistake was thinking that I don’t have time to write tests. A classic fallacy that might be true when a project is small and simple, but every project grows over time. And I now regret not writing tests from the beginning.

7. The third thing that surprised me is that good UX is iterative, just like software. I can’t figure out a good design before using it on my own. So, my current process is just to implement the simplest thing possible, see how it feels and what I don’t like about it, and then fix it. That keeps things simple and clean and is easier than coming with simple and clean before hand, without trying it out. Seasoned UX designers can probably come up with simple and clean from the get-go, but I don’t have much experience with it.

8. Speaking of UX and design, by building all of this myself, I’ve finally started appreciating designers. No, they don’t just draw rectangles and circles on the screen that we developers have to implement later.

9. Good software is hard to write, but easy to maintain.