Majorly, I still love writing code. Do you know why? Because code expresses your intelligence in words that can be processed. And also, it helps others understand what you are trying to communicate in a better way. I believe that writing code is a way of communication and it enables developers understand better than just talking about the concepts or logic in plain english words.
This is the thought process that leads to my today's post.
I came across a situation recently when a Pull Request represented an idea but not an actual implementation. The idea was expressed not in a google document but in a couple of lines, which inherently changes the way the software would work. It meant a big change, but in reality it was not a PR that *has* to be merged, but just something can be written to help others understand what changes it incurs. Mind you, its not a 1000 line change. It was a couple of double-digit line changes.
I would appreciate the developer's smartness in writing the code and then talking about it because it would help the team talk about an approach instead of just drawing pictures on the whiteboard and writing endless documentation. This was the outcome of the exercise - the team understood what they are up against and what are the other changes that they have to solve before attempting the problem.
I think that the above approach also helps implement the agile principle of
Working software over comprehensive documentation
I see the following advantages to it
- Crisp idea of what needs to be changed
- Will initiate a whole discussion in the team about the impacts and what the change entails
- It's easier for team to see PR changes via github (for example) and discuss
- It's a passive mode of finding the discussion points
- Distributed teams can work really well in this mode.
Let me your thoughts in the comments section.
