DEV Community

AmasiaNalbandian
AmasiaNalbandian

Posted on

Preparing for Burn Out

As we start to embark the end of our journey for Telescope 3.0, there are some things to begin thinking about to prevent burn-out as we get close to the finish line. In every team, to be successful there has to be a good balance between give-and-take. To provide some insight to this, we can look to these 5 questions provided by Dave:

1. Which part of Telescope 3.0 do I own?

Finding out the answer to this provides some insights to what kinds of issues/questions I should be participating in. I should be more present in discussions about these topics to not only help educate others who are new, but to keep myself updated on the new changes which might come.

From previous blogs, I've done a lot of work on the Search bar, and search service. I would say anything related to the search functionality I could definitely help out on. As we start exploring new issues such as autocomplete, I should keep myself updated on how the Search works and what code has changed.

2. Which existing Issues are part of this? Which new Issues do I need to file in order to properly describe the work? When will those issues be filed?

Although this is really 3 questions.... I will argue it is one. If you've ever come across S.M.A.R.T. goals you would notice the pattern immediately. We need to start addressing S.M.A.R.T. goals (our issues), in order to successfully pave the way.

It's funny timing, because in my last PR I talked about how I was already breaking up the search UI into smaller issues. I can imagine for my case, I might need to do some more issues as we come across them. However, I will summarize what I mentioned in my last post:

These are all the open issues we have right now to complete the advanced search bar. In addition, I know that Roxanne is exploring autocomplete for the search bar.

3. Who can I depend on for support in development, debugging, testing, and reviews? I can't do this alone.

This is always the hardest question. Personally, from experience, it is difficult to depend on others, but I've learned in this field - you NEED reviews. In addition, this question is extremely important. If we don't have a good idea of who we can turn to for support, we usually will get stuck and make no progress. Therefore it's important, to be successful, to prepare for everything.

In the upcoming weeks, I am hoping to depend on the sheriffs for reviews(debugging, testing etc). In addition, I know I might run into problems with React Syntax so I am really hoping that if I write on Slack someone will be able to help - as has been the case in the past. However, I will probably continue to add Roxanne and Jerry to the PRs as they seem to be engaged in this area as well, and it will help keep them up to date with the changes I am making.

4. What are the risks that I see, which could prevent me from getting this shipped?

This question prepares us for any "grey areas" that we might need to prepare for. For example, in the last PR I posted about the searchbar, I already have some concerns I am seeing that I can't seem to address easily. For example:

  • Updating the search after any character change in the input fields (very wasteful).
  • Implementing an onEnterKey press.

Additionally, we always have the usual suspects of development:

  • Waiting for PR reviews
  • A service breaks

So for now I have those four, but because the search is complex and touches most areas of the projects, I can imagine I might get blocked again by more.

5. How will I mitigate these risks?

In order to prepare better for our potential risky areas, it's important to have a game plan. We don't need to have a solution right away, but an idea of what you need to do in order to waste less time. A great example of this is when you go to a soccer game. You're going to bring a first-aid kit. You have no idea what might go wrong, but you have a strategy and some tools for when you do.

One of the more recent things I've noticed working in this project is the best way to work is to move your code quickly. You get feedback on your PR, address it right away - and put it up to get another review. It's easier for others to review 5 times in the same day, than 5 times in the same week. Therefore one of the ways to mitigate risking long PR review processes, is to keep updating your code after the feedback you receive.

As for the grey areas, for the first issue about the character change, if I can't figure something out, I will probably have to make another PR to clean up the code to make it work better (tie it up differently). For the latter, I imagine the React syntax is incorrect, and I need a peer to help me review this.

Conclusion

In summary, after writing this post I see a clearer image of what is to come in the upcoming weeks. I can feel more at ease, as long as I stick to the plan.

Top comments (0)