DPS911 Blog #11: The importance of patience
Tags: opensource
Published: 2021-04-04 02:59:28

First of all, thank you David for being there for me this week. I definitely needed that boost of confidence. Go read his stuff [here](http://blog.humphd.org/). You won't regret it.

This week, I took a break from the microservice hell I was in and wrote a PR to create a Search Context for our search related props. You can find that PR [here](https://github.com/Seneca-CDOT/telescope/pull/2046). I ended up coding the initial context in about 20 minutes which wasn't so bad. The real problem came with reviews...

So, I only got like about 2 reviews only for this PR. I wasn't expecting such a low turn-out, especially considering this was for a piece of the front-end which most of our group was working on. Probably because I did alot of testing, and I hated having to rebase my PRs so frequently, I merged the PR in myself. Suffice to say, while the github actions tests were all green, I re-introduced a bug that we had fixed months ago, which was the search bar making a request on every letter typed. You can imagine my surprised when I was working on some other work for other classes and got a message that it was broken.

I got cocky and impatient and it ending up biting me pretty good. I quickly went about searching for a fix, and it took an hour of looking at the code, but it was simple. I just needed to also include the textParam that we had as a context value so the search results component used that value instead of the actual text when making the network request. We have a useEffect that gets ran in the context everytime the text changes, so that's what was causing the bug. I went to file the PR and...

My remote master was ahead of all my other branches, and thus, it was bringing in merge commits and other commits from other students as well. Great, so now I have to fix my git history once and for all. This was occurring for a few days and it affects all my current PRs up including the PR to introduce the search service to the front-end (Once the search service is merged in), and the PR to increase the jest e2e timeout seconds so our github actions doesn't lag and cause a random failure for no reason. You can find both PRs [here](https://github.com/Seneca-CDOT/telescope/pull/2012) and [here](https://github.com/Seneca-CDOT/telescope/pull/2059). In any case, it was a pretty demoralizing week, and as a result, I didn't really do much in the way of reviews.

One thing that the Covid-19 pandemic has done is ruin any sort of live discussions. I try and be active in slack by talking as much as possible on current work I'm doing, but it's been clear that the majority of the other students aren't as active. School and life in the home certainly play a factor, but when only a few people are talking at any given point, it really ends up begging the question, "Why am I on Slack at all?". If I just need to shut-up and do my work, what's the point of even being there? I guess it doesn't help that I'm one of the few people working on microservices, so any PR I put up is going to get very few reviews. Chris is also feeling the same way with his User service since we don't learn Firestore/Firebase in Seneca. I've tried to help alleviate that by learning as much of Firebase as I can on my free time in order to be able to provide some sort of help whenever possible, but I can certainly do more.

I hate rebasing so often, because it means that any PR I have up is either not getting reviewed enough, or it's blocked by another piece of work not in the repo yet and I have to wait. I was talking about my SearchContext PR during this week's triage to make it as simple as possible for others to review and yet, I find the lack of reviews very discouraging to be blunt. I think we have a great group of developers this year working on Telescope. We've done alot of work since January, and I wanna ask in this post that everyone step up and at least try to review PRs that they don't feel comfortable reviewing. Our microservices are just as essential as the 2.0 UI updates. Even if it's easier to review front-end code since it's mostly UI based, and even if CSS is one of my weakest points in web development, I STILL make the effort to try and review UI PRs, because at the end of the day, I still learn something valuable that can help make me better with CSS. Especially now with the github cli available, making it very easy to go into another person's PR and actively test it locally, we have the potential to do much better, and I know we can.

There's only 3 weeks left until 2.0 launches and I'm starting to realize that many of the things I wanted to work on will probably not happen. If it's possible for me to continue working on Telescope past DPS911, I'll take that opportunity. With this in mind, I've decided to drop work on the redis data loss feature. I left a comment discussing what a solution can be for any future developers working on this feature [here](https://github.com/Seneca-CDOT/telescope/issues/1365#issuecomment-812073822). If I can continue working on this after this month, it'd be great. I feel like this solution would be most ideal at solving this redis data corruption issue. I'll be updating the posts service's health check path to also check Redis to make sure that works once Redis is ported over to Satellite, and then, there's the JWT related stuff I wanted to look over as well. I think I messed up by taking on way too many issues and so I plan on dropping a number of them in the coming days, not because I can't do them, but because there's not much time and it'd be unrealistic for me to look at every one of these issues considering the time. 

With this in mind, that about raps up this post. Made on Saturday instead of Friday due to the Good Friday long weekend. We'll be back on track next week. Until then, stay tuned!