Developers in open source projects tend to develop thick skin because it protects you the developer from unconstructive criticism (or worse) which inevitably comes as a project gets more visibility. However, as Haacked points out, thick skin can also lead to you the developer becoming insensitive to the needs of your users. It is good to apply the principle of “you are not your code”, but that is usually easier said than done.
I have written little bits and pieces of code in the few years I have been programming, but like most others, it either just languished on my machine and eventually got lost, or served its purpose at the time and was decommissioned.
The first piece of code which I decided to open source was the Android Contact Picker. I extracted it from the CallingProxy app and published it on GitHub. I did not expect the code to get any attention, after all it was something pretty mundane which a lot of developers could do in their sleep. But I open sourced it anyway.
Months passed and then I got my first email about it from Avi. I must admit there was something very exciting about knowing that someone somewhere was using the library and giving it enough attention to write me about it.
The email is in my opinion a very well written code review. With the author’s permission, I here reproduce that email with a few comments about how I received it.
1. Thanks for the library.
Yay! Finally someone sees the value of my work!
2. As it is it is unusable!
Oh, come on! I was just starting to feel good. Anyway, let’s read on!
You suggest 2 ways of using it.
A. Subclassing your activity – well, it just doesn’t work well, I could always copy all of the resources and then some code, but then it beats the purpose of this library.
But I have used it like this multiple times. It works well, you don’t have to copy anything. (I’m getting defensive.).
B. Hack the code – Well, I assume that when hacking enough I could do anything – but this also beats the purpose.
Ok, you kinda have a point! But you’re a hacker, why should I spoil the fun. (still a bit defensive)
I think that the goal of a library is to separate it’s code from the main code and just access it through a simple api.
In your library, the best expected result will be to just have it as a library and then just call the contacts and get in return the contact’s number.
Instead it Toasts the contacts number (doesn’t really help) and there is no way to get the phone number in my original activity.
I am not just ranting, I want to thank you for what you did till this stage and want to suggest some code which will make this component usable.
Calming down, it’s not about me, its about the code. I’m listening.
This is my suggested code replacement:
At this point, he provided sample code improvements and suggestions for updating the documentation. The “show me the code” argument has never been more applicable. After seeing the code, I was convinced about all the points he made and used the suggestions to improve the library.
Now, one can download your component and use it as wished for, as a way to get a phone number.
3. One last thing, I suggest that if only one phone number exists – you return it immediately without initiating a list of one phone number.
The fix for this last point he also sent in as a pull request and eventually went on to become a regular contributor on the project, which I am thankful for.
Each time I read this mail, there is one thing that stands out, and it is that he makes a clean separation between attacking the code (which he does aptly) and attacking me (which he does not do at all).
Although, as a developer (or any creative professional) you shouldn’t take things personally, it is difficult sometimes to extract yourself from feeling the criticism of your work.
So while we as developers continue to strive to remember that “we are not our code”, we as code reviewers should also strive to make the distinction between developer and code clear when offering criticism.