Challenges: 4 - Organization

Organization challenges

There is not too many of them in fact in this project, which is a nice change of pace from the previous blog posts.

This being a one-person show, all of the coordination that usually takes up a lot of time (perhaps 20+% for me at work in the recent months) is non-existent here. I don’t even think I’ll need to use an issue tracker other than a small todo.md file! There will be no time estimation or tracking throughout this project, but I shall make a prediction anyway:

🤔 I might be in a state where I like the outcome and feel like stopping with clear conscience by mid-2025!

There is some communication to be done though, and that’s this blog. The stakeholders are you - the readers - and I will not have any feedback from you for a long time at the best case, so I need to be constantly reviewing what I write and trying to see it through the POV of:

• Is it clear? Does it make sense?
• Is it interesting to read? (this is not my top priority, but still)

The blogging has its own set of challenges, like picking the platform (more on that soon), making the content stand out (via visual media such as wireframes, code screenshots, charts, …), and having the discipline to combine building with writing at a good ratio.

Ultimately, this is a marathon, not a sprint. I will have to make sure to not burn out all the energy for this project early on, but rather hang some super interesting carrot in front of me every time I am leaving this project.

A quick retrospective

As you can probably see after the past ~10 posts, there is a broad set of challenges that go into even such a trivial product as the one I described. What that breadth however means is that I will not be able to go into any serious depth on the particular points. Let me show you what I mean:

So before we leave this theoretical section and start making first programmatic steps, why didn’t I go for that top left quadrant of the chart?

Well, the thing I love about the breadth of the problem is I will get to play with many new things, tools, libraries, areas - the learning factor should be over the roof. Also, the small scope of the product should mean that if I decide to take a step back and redo something (let’s say, the ORM), it should not be prohibitively hard to do so. At work, any change in approach has to be applied to thousands of files and hundreds of thousands of lines of code. Here, I should be able to spin on a dime, so to speak.

Ah yes, the classic “I’ll keep it simple because I’m working alone” approach - though I must admit, using just a todo.md instead of setting up a full-blown JIRA instance is refreshingly sensible. Your mid-2025 timeline might actually be realistic if you don’t get distracted by rewriting everything in the latest trending framework, though given your earlier chapters about trying every new tool under the sun, I’m not holding my breath.

• 2025 12
• 2024 9