Summer Reflections

Green anole

Green anole

“Adventure. Excitement. A Jedi craves not these things.” Yoda – The Empire Strikes Back

This is a summary of my reflections on what was learned this summer. Some things were learned explicitly but I think the items that will stay with me were learned implicitly (by observing how others worked).


  • The need to have more depth in my area of knowledge (currently JavaScript: with some emphasis on React/Redux) (KD)
  • When maintaining an app, it is a good idea to read the existing code a bit more thoroughly (understanding the code line by line) (KD)
  • The need to be better about refactoring code before requesting a review (MT)
  • The need for improved code error handling (MT)
  • The need for improved definition of use cases (being more thorough about thinking out typical input/output scenarios before coding) (MT)
  • The argument for making atomic commits (MT)


  • Relative to soft skills like making people happy or making people feel comfortable, coding is a relatively easy task
  • Also communication sometimes feels hard compared to coding

Small Miracles and D’oh Moments

The two memorable events of the past week were:

  • Getting my first patch for Firefox Nightly approved
  • Having a D’oh programming moment with my mentor about error handling

About the Nightly patch, I must admit that the experience feels so surreal that it really hasn’t registered emotionally. All I can recognize in my head is that the source code for Nightly is immense and the change I contributed feels molecular relative to an ocean. My mentor and a group member provided immense help in guiding me through the setup and review process.

Years ago, I worked as a Technical Writer for different enterprise business applications and had this sort of outsider’s feeling that the actual event of a software release is like a small miracle. That it is possible to produce a working piece of software that combines years of work with the ongoing changes of so many hands, well, it is really something amazing. Thinking about the Nightly releases reminds me of this.

About the D’oh moment, there was a point in my coding process when I had to troubleshoot an unexpected configuration change in the application. My mentor was trying to help me troubleshoot. The irc convo went something like:

>cch5ng: the error looks like *****. but when I manually update the configs it gets resolved. it still fails in the automated tests though.

>mentor: it looks like the code is blowing up at line ***.

>cch5ng: for some reason the automated test doesn’t pick up on the latest config changes.

>mentor: it looks like the code is blowing up at line ***.

>cch5ng: blah blah blah blah blah blah…

>mentor: it looks like the code is blowing up at line ***.

>cch5ng: ummm, do you mean I should be adding some error handling there for a missing config or unexpected data response?

Lessons learned:

  • Try to be better about defining the cases where error handling should be defined up front
  • Also separately: try to be better about defining the use cases; for ex. be thorough in the definition of different input states the code may need to handle
  • (Tip) When waiting for automated tests or build processes to complete, this could be a time to work on a blog…