Friction and Learning

I heard someone comment that the friction that you find when trying to implement an idea is useful as a learning exercise and also as a way of giving you hints that maybe you are going about things the wrong way. I think that is pretty accurate from my experiences.

My code process is normally:

1. Reading the existing documentation, playing around with the code, and creating some minimal working examples of the thing I want to accomplish without much regard to clarity or best practices. I’m just playing in the space.
2. Rough draft of what it is I want to accomplish and taking the path of least resistance towards that goal. This will often times mean going back to step 1 again and reading through more documentation.
3. Writing any required tests around the code. Allowing these tests to fail first and then writing code that gets the tests passing. These may be actual unit tests but they could also just be a list of manual steps I go through.
4. Commenting is done throughout 1 – 3 but at this point I’m explaining as much as possible usually in an overly verbose manner with myself as the only intended audience of these comments.
5. Finalizing whatever tests I think need to be in place, pushing up the PR to github and reviewing the code there.
6. Writing a summary in the PR description in what new features are being added / bugs fixed. This should include some of the reasoning behind decisions made whenever possible. If there are paths not taken, there should be an explanation as to why the path I did take is better.
7. Going through the code, cleaning up comments that are overly verbose, cleaning up the language so that it is easily understood by everyone, deleting any unnecessary code, cleaning up the PR description, and doing a final retest before presenting the requested change to the rest of the team.