Just sat in on a talk by Cory Foy entitled “When Code Cries: Listening to What Your Code is Saying”.
(Warning: there will be anthropomorphizing of source code in this post)
One thing I wanted to pull out of it is the idea of listening to your code. Really listening. Like it was a person.
I don’t think it is just listening to code - but a conversation with code. The programmer is talking about what they need, and the code is telling the programmer what it needs. It is a give and take like any conversation. If one side of the conversation tries to dominate, or ignores the other, the outcome will not be successful. Like any conversation the failure may not be immediate but later when misunderstandings between the parties of the conversation cause problems.
Listening is not easy however. To really listen you have to:
- Decide to listen
- Listen for the whole message
- Let go of your personal agenda
- Be patient
- Be curious
- Test for understanding
I personally have problems with listening patiently for the whole message. I tend to jump in, trying to add things, perhaps of my own agenda, saying things starting with “So what you’re saying is…” instead of just waiting to find out what is being said. With code this comes out when I too quickly jump to refactorings or thinking that my coding task is done - because I’m not listening to the code.
Having a conversation with code is not easy either. Mike Clement @mdclement likened it to talking with his 18 month old child. They can’t talk - but they are trying to communicate. One needs to be patient in order to get the message.
I am working on being a better listener, with people, but I can see that I need to work on those skills for my code as well.