Journal of senior iOS developer part 2
I always thought pair programming was a way for junior to be benefitted at the expense of senior developers. It might be the case sometimes. However I now understand multiple other benefits and use cases.
- You can understand and start working with Other people’s code faster When you are working on another developer’s code. The other developer’s code may be clear as day or confusing and convoluted. In cases where it could take you a day to a week to just understand that developer’s code and whether it makes sense to do to it what you want to do, I highly recommend a brief pair programming experience where you have the opportunity to
- Vocalize your understanding of the code to the developer who wrote it. In my experience, every developer tends to think their code is as clear as their vantage can see. So when you vocalize they ultimately want their code to be clear. This leads to an opportunity for:
- Early buy in. Because the other developer will have more empathy for your concerns about the code, you pepper them with requests to refactor naming conventions and other changes before marking a pull reqeust as ready to review.
Don’t tell me what I don’t need to know
There was a function that I need to call that needs Result<MySpecialType> as an argument. It really doesn’t use Result<MySpecialType> , it only used: MySpecialType and so I worked on an api call method that provides MySpecialType . When I looked up, I realized I provided a mismatching type and now I have to refactor my code to provide a value that the method asks for but doesn’t actually care about. Code is made better when it doesn’t have to change as much. Create functions that don’t ask for more than they need. lets call these “Needy functions”.
