# data[].attributes.body
PRs:
https://github.com/padlet/rn-mobile-app/pull/1495
https://github.com/padlet/rn-mobile-app/pull/1504

Why?
Was not my first mobile contribution but the most complicated feature I had to build so far. Was humbling as I had not done any react since I joined Padlet. Proud that I was able to contribute quickly without having to feel like I am doing something brand new.

# data[].attributes.body
PRs:
https://github.com/padlet/mozart/pull/13577
https://github.com/padlet/mozart/pull/13696

Why?
In general I am proud of the sort posts project as it is the first project where I had full ownership and had to plan how the project would be implemented. I chose the above PR in particular as it was the most complicated one as I had to implement calculating a bayesian avg for sorting by reactions.

# data[].attributes.body
PRs
https://github.com/padlet/mozart/pull/11580

Lesson(s) learned:
Learned that changes to the master db in a transaction are not copied by the replica until after the entire transaction is done. This issue never popped up in local development as there are no replicas in local development. Ideally, you should always read from a replica, but in this case the extra reads on master only happen when creating a section which doesn't happen too often for a padlet.

# data[].attributes.body
PRs:
https://github.com/padlet/mozart/pull/12139
https://github.com/padlet/mozart/pull/12345
https://github.com/padlet/mozart/pull/12358
https://github.com/padlet/mozart/pull/12383
https://github.com/padlet/mozart/pull/12393
https://github.com/padlet/mozart/pull/12324

Why?
First significant frontend feature I contributed to surface since joining the surface team. I felt that the legacy custom image picker was very rigid and coupled to a lot of other parts of the old settings panel. It would have been too complicated if I tried implementing the new image picker in the same way. So I decided to make the new image picker much more flexible so that in the future, if we want to use it anywhere else on the app, we can just import it.

# data[].attributes.headline
Updating privacy policy for user's padlet

# data[].attributes.subject
Updating privacy policy for user's padlet

# data[].attributes.body
Relevant Linear issue:
https://linear.app/padlet/issue/ENG-5573/specific-wall-owner-is-unable-to-access-the-shareprivacy-settings-in

Relevant front thread:
https://app.frontapp.com/inboxes/teammates/6455695/inbox/open/39060460751

Why?
Just speaking as a consumer, when I find and report bugs in other apps and they get fixed promptly it does leave a lasting, positive impression as it is pretty rare and makes it feel like the product is yours. So I like to think I was able to give that experience to the user in this case. Few things more frustrating than finding a bug with an app, reporting it, and then coming back to the app some time in the future and the bug is still there. Makes me want to stop using the app, and I usually do if there is an alternative.

I had no clue what went wrong for the user and was not able to reproduce the error in any way. I initially asked Nguyen for help, but he was busy. And that ended up being a blessing in disguise as it gave me the impetus to investigate it deeper on my own as I knew I was not gonna get help anytime soon . I had some trepidation while fixing this issue as it involved doing a lot of things I rarely do like using the production console, using metabase to look up data about walls. I definitely feel like I would be less hesitant if I got had to fix another issue like this and may not even need to ask for help in the future.

# data[].attributes.headline
When to make changes incrementally and make changes all at once

# data[].attributes.subject
When to make changes incrementally and make changes all at once

# data[].attributes.body
PRs
Mine
https://github.com/padlet/mozart/pull/13753
https://github.com/padlet/mozart/pull/13729
https://github.com/padlet/mozart/pull/13602
https://github.com/padlet/mozart/pull/13571
https://github.com/padlet/mozart/pull/13511
https://github.com/padlet/mozart/pull/13577
https://github.com/padlet/mozart/pull/13571

Junyu's
https://github.com/padlet/mozart/pull/13771
https://github.com/padlet/mozart/pull/13895

Lesson(s) Learned:
This is less to do with something I learned while making one pr and more in retrospect what I learned while having to make PRs that relied on something from arvo.

I made incremental changes which resulted in rounds of updating arvo and then only after updating arvo would I be able to use the updated arvo on the frontend.

I did it the way I did to play it safe as I was concerned that I would make a regrettable and irreversable decision when naming the sort by values. But in the end the only planning ahead required was just naming variables, but I think I could have saved a lot of time and effort if I just committed to a consistent set of variables i.e. the sort by value followed by asc or desc.

Bad names are annoying but at least from my experience they don't really block development since in the end they are just copy pasted, they just make other developers go "this variable should have been named something else", but they have hindsight to make this observation.

I think if I applied the lesson learned instead of all these PRs that all essentially just update and use something from arvo, I could have just done one iteration of updating and using arvo. And that is what Junyu ended up doing when I was in Taiwan.

e

# data[].attributes.body
PRs
https://github.com/padlet/mozart/pull/13690

Lesson(s) learned:
I realized that up until this PR I have pretty much been using typescript the same way since I joined padlet and have not refreshed my knowledge since.

I also learned that I should be more pro active in refactoring to make things more DRY sooner than I think. I am always hesitant to do this initially but end up just forgetting to do it and just using the boilerplate as most of the time boilerplate is just copy pasting. I don't get a wake up call to do it until a PR review like this one where someone points out it is a good time to refactor.

PRs are not reviewed in realtime, so there is a lot more time to polish and refactor PRs to be more DRY and concise. I should follow the urge to do this, rather than ignoring it which I have been doing as it means that I can move on to another PR/issue.