Hey, you! Guess what happened this week? I joined a certain community on Discord, a big community, and through our interactions, several of the other members and I were chatting for over 3 hours as a group!
Because of this, I got to know at least 8 specific people, and learned some of their interests, passions, even their struggles and worries about themselves and how they think others might think about them, building up the beginnings of relationships.
I did make some mistakes though, and not everyone was as interested to chat with me, because I was maintaining a sort of distance for reasons that now I realize don’t actually matter, at least in that community, and because of that I missed some opportunities to connect with even more people.
But learning is learning, and improvement means those mistakes are only in the past, opening the future to even more exciting chances, and I’ll be excited to see which of these 8 people (and more, soon) will be interested in Ugeddit and our mission.
On the product side
- For the current Ugeddit alpha, we’ve fixed up a new outstanding bugs, and even made the chat typing area at the bottom more beautiful
- For the beta release, I’ve started building a v2 for Ugeddit’s app from scratch that implements several very important standards which our v1 is missing
- Clean Architecture (CA)
- A high-level separation of different internal pieces of an app
- Currently, our app is monolithic, which basically means in order to change one thing, we need to consider all the interactions that one thing has with other parts of our app.
- Using CA helps keep our code organized and makes each individual piece of our app independent so when we change one thing we only need to touch that one thing
- Sound Null Safety (SNS)
- A compiler upgrade that prevents coding-level mistakes from happening
- Currently, we have to consider many different functions in our app that may or may not cause problems if they return null values
- Using SNS means we can completely forget about managing this, and the compiler points out any null issues automatically, saving huge time and stress
- Test-Driven Development (TDD)
- A strict workflow that ensures outcomes are well-defined, effectively implemented, and well-documented
- Currently, when we create a feature or make a change to our app, we need to manually test and check to make sure first that it works, then second that it doesn’t break anything else, and “anything else” means we need to manually re-test the entire app
- Using TDD, we code tests directly into the app, and when we create or change any part of the app, we simply run the test and it instantly tells us if anything ANYWHERE in the entire app has broken because of it, and even lets us know exactly what broke, and WHY it broke, so we can fix it very quickly. Do you have ANY idea how much time this saves? A LOT.
- Conventional Commits (CC)
- A set of commit (code submission) documentation standards that improve readability and comprehension of what was changed
- Before, we were using general commit messages that only communicated what specifically was changed, but gave no additional information. Imagine you needed to review 100 tasks, and you forgot what 90 of those tasks were supposed to accomplish.
- Now, we’re using CC to make sure our commit messages contain the most useful, yet succinct, information that makes reviewing them later much easier. These include
- The purpose (and context) of the change
- The specific change that was made
- Any warnings about the change breaking other features
- Additional details (if needed) about why this change is important
- Clean Architecture (CA)
I’m super excited to build these relationships (and new ones!), and to rebuild the app with much, much easier structure to manage, test, and scale!
What do you think?
What ideas do you have (or even just thoughts) that can help us more quickly reach our mission to help 100 people understand each other better online?
We’ll be right here, excited to hear your ideas.
Let’s do this!