working from home (27 Part Series)
Another day, another surprise. Our daughter woke up feeling sick and we immediately got concerned (not thinking about Corona) as she was not at the day care or had any contact besides us.
This made me think how easily something our kids can catch. Our theory is that either she touched sth or we and she end up feeling dizziness and nausea.
Yet, kids are strong. Over the day she went from "I can't walk" to "Can I have ice cream" 😂 so hopefully on Wednesday things will be fine.
As I shared on the yesterday blogpost, I had the hangout with our co-worker.
I expected that he won't be interested in doing smaller PR's and cherry picking as he expressed this clearly in PR comments. I shared with him Why I believe he should have done it. At least, he shouldn't share a big PR after 2 months work. Sure he doesn't want to invest another day or two but the review and my feedback won't be easy. And it will take time. I will not +1 after our hangouts.
At least, I shared with him my concerns and wanted him to have a clear expectation.
All in all, the hangout went really well. I understood why he did what he did. I asked him also, why his Product Manager + Team believes having such a big fat feature is a good ab-test design. How do you know why something was successful, when you introduce 10+ things?
I also asked him why he didn't sliced it and started small or asked Product to rethink it. Yet, here I discovered another difference in the mindset. I care about product. I believe that as developers we should make them happy and proud about the team. But at the same time not sacrificing quality. You can't have both at the same time.
I hope after all my comments, tomorrow I won't wake up seeing him ignoring them or trying to move any improvement to the "future".
I've also discovered sth weird in Github as many of my comments where not saved.
Always save your comments. Always "start the review". I missed that and 20+ comments were gone. By accident it was also a good thing as some comments where not needed.
I'm sharing something I found interesting, shared by my Lead when asked about the difference in peoples mindset and thinking about "do tech debt later." Quoting him :
He (Robert C. Martin) says the first objective of software is that it should have the agility to change and not that - it works. He uses an analogy to prove this.
A. A software that works but not possible to change
B. A software that doesn't work but easy to make change
A. Will stop working because requirements will change and you cannot change the software
B. I can change it to make it work as long as it is possible to make change
So always changeable software over non-changeable.
Sounds logical and clear but we all know it's easy to end up on the right side rather staying on the left.
Level up every day