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…

Mozilla All Hands Meeting

Mozilla Web Compatibility group

Mozilla Web Compatibility group (All Hands Summer 2017). Photo by Dennis Schubert. CC by SA-2.0.


  • I enjoyed having a chance to meet everyone in person, especially those I only knew through their github handles when I was previously a contributor
  • I’m grateful to Mozilla for their generosity with having the interns attend
  • I’m grateful to the entire Web Compatibility group for being kind to me (and Bea, co-intern); in particular Mike T. was extremely generous with his time and planning for everyone to have mornings and evenings filled with interesting things to do
  • Additional thanks to everyone in the group for the generosity of their time and knowledge share (in particular Karl, Tom, and Guillaume)


  • We had an interesting impromptu talk about running functional tests for (Bea clarified the use of running the server in test mode for required fixture files); quote of the week: “This is like space…”
  • Enjoyed listening to all of the engineering group presentations on the last day (especially the Software Architecture group which had clearly articulated slides)
  • Enjoyed Espresso ice cream at Ghiradelli Chocolate shop and jogging through Golden Gate Park (although I could not walk down stairs properly for the remainder of the week)

Group Appreciations

  • Adam: very down to earth and pleasant to chat with
  • Bea: very fun, understanding, and smart to boot
  • Dennis: wickedly funny and smart
  • Eric: pragmatic and interesting to chat with
  • Guillaume: a very nice sense of humor and patient with my questions
  • Karl: a good listener/reader (thank you), smart teacher, investigative reporter of code, and a strong work ethic
  • Mike: makes being a leader look easy, makes big things happen, patient with my D’OH coding moments (more details in a future blog)
  • Ola: humorous, intelligent, and productive; a bold thinker
  • Tom: balances a sense of humility, confidence, and intelligence in his communications; service-oriented in his work outlook

One general observation about the group is that everyone is highly technical but also quite verbally articulate. There is a very interesting balance of qualities…

Coding: The Good, The Bad, and The Ugly

Recently my mentor, taught me about how to conceptualize programming solutions at different levels. In my recent experience, I was used to developing fast hack solutions which I feel is not correct but given short deadlines, I felt little choice about. But instead of thinking about a problem as having only a hack solution or an ideal world solution, my mentor suggested considering the following:

  • The fast and hackey solution (AKA The Bad). Sometimes this is not a bad solution but some time should be taken to document why/how it was done and how it may be refactored when time permits.
  • The middle ground solution (AKA The Ugly… OK, it is more Middle than Ugly). This is often an ideal solution.
  • The ideal world solution (AKA The Good). This is like a “perfect” programming solution (if you had unlimited time and resources). Most likely this solution is going to going to have maximum flexibility for current and future use cases.

Recent Problem and Application

Recently I was working on a issue where there were some record types returned in github issue searches that should be filtered out. The solution that I came up with doesn’t exactly fit within the 3 categories described above (maybe it is somewhere between the hackey solution and the middle solution).

Since the data was coming from 2 Github API types, 2 approaches were needed:

  • For the Github search API, it is possible to intercept the user’s search query, append a custom string (negative label filter since the undesired data had a specific Github label attached) and send the resulting query with the Github API request
  • For the Github issues API, it is hypothetically possible to filter the Github API’s returned JSON results using a JavaScript function. This is not an ideal solution because it causes other issues (such as throwing off the expected records count per page) but it is a possible line of thought for exploration.


Flexbox vs CSS Grid

The purpose of this blog post is to compare and contrast Flexbox and CSS Grid. These are a few points for comparison:

  • How to conceptualize and plan layout
  • Ideal use case scenarios
  • Ease of use

Caveat: My approach to web development is fairly quick and dirty, having come from more startup type experiences (as Tech Writer and FE Dev contractor) than not. As a result, my biases are towards learning the minimal concepts necessary to get about 80% typical use cases done.

How to Conceptualize/Plan Layout with Flexbox

When planning out one responsive layout design in both Flexbox and CSS Grid, I felt like the main difference for thinking about Flexbox were the ideas of:

  • content container
  • how data should flow through a content container

These are some sketches used to visualize how the grid content would flow across breakpoints.

wireframe for flexbox design (mobile)

Wireframe sketch for flexbox responsive design (mobile)

wireframe sketch for flexbox design (tablet)

Wireframe sketch for flexbox responsive design (tablet)

wireframe sketch for flexbox design (desktop)

Wireframe sketch for flexbox responsive design (desktop)

By scanning the planning sketches hopefully you could get an idea that all that was necessary was to:

  • understand the number of columns per view (also the relative proportion of space needed by each column)
  • understand how content should lay out within the column
  • understand how the repeating pattern of data should display

How to Conceptualize/Plan Layout with CSS Grid

For CSS Grid, I felt like it was more important to sketch out a precise grid, as though the webpage were like a piece of graph paper and I had to lay out the skeleton that would support the content.

wireframe for CSS grid design (tablet)

Wireframe sketch for responsive CSS grid design (tablet)

Note: To be technically correct for a 2 column grid with margins (far left and far right), this should be a 4 column diagram. The far left and far right columns would actually be empty spacers. The resulting vertical line count would be 1-2-3-4-5.

TODO: redraw the grids with proper columns


Ideal Use Case Scenarios

My belief is that flexbox is a better choice when the required grid is relatively simple and when the data to be displayed is dynamic (for example, coming from a database and the total number of records returned from a query is not always constant).

On the other hand, if the required grid is relatively complex and the desired design layout needs to be pixel perfect, CSS Grid allows for a more granular level of control. Also if the data to be displayed is static, CSS Grid could be an option.

Ease of Use

Generally my preferred tool would be flexbox because the same CSS would easily scale to a dynamic size of data.

In contrast, I felt with CSS grid, there would be a bit of calculation and scripting required to make the CSS able to support a dynamic size of data. See CSS in the sample source (about line 60 and later).

What do you think? If it seems like CSS grid is more versatile, please explain your use case in the comments.


Flexbox example: Demo | Source

CSS Grid example: Demo | Source


Resources (not used for this article but a good one)

For Flexbox resources, please see a previous article.


Lately I’ve been reading flexbox docs. There are a lot of really good articles already out there (linked below). I’ll share what I’ve learned using a few practical examples with links to the source and a few observations about the process.

Sample 1 (simulated simple bootstrap grid)

This is not my first time working with flexbox but when I initially compared it to the bootstrap grid, I preferred bootstrap because I felt like I had a little more layout control.

One area where flexbox is much better than bootstrap is in footprint size. There is a lot of code in bootstrap that goes unused and defining a responsive grid using flexbox does not require very much code.

*Please click the upper left corner to get to the pen content and then the Edit on CODEPEN link (upper right) will also be available.

Note: this grid collapses in mobile device view also there are some observations in the content header.

Sample 2 (example of vertical layout)

This example specifically refers to when would you prefer to use

flex-direction: column 

One scenario could be if you have a bunch of dynamic content with similar widths but varying heights (photos or maybe work portfolio samples). Typically a grid system with this kind of content would force an alignment with a bunch of irregular white space between elements.

Tip: When you want the content to lay out with an even bottom edge (desktop/tablet views) you need to mind that the total height for elements in each column would equal the flex container height. Otherwise a jagged bottom edge could result (which I guess could be an option).

Note: This grid collapses in mobile device view.


Sample 3 (simulation of a marketing homepage)

To test the ease of use of flexbox, this is a simulation of a consumer hardware company’s homepage. They do great marketing design. This simulation does not go into the nitty gritty details (like navbar responsive design) but emulates their body/footer responsive design. It did not feel too labor intensive and the code footprint is still very light.

Note: the breakpoints are between mobile:tablet, and between tablet:desktop

Final tip: My initial observation when googling flexbox is that it is potentially a very complex topic to learn. Rather than starting with a site that contains a ton of reference info about each property, I like the link below by webdesignerwall because of their visual style of teaching and simplicity.

Afterward, please search further for more advanced tutorials on flexbox because this is only the tip of the iceberg (but hopefully helpful).



Women’s Tech Panel Talk

(Follow up: Get a list of speakers/titles)

This afternoon women reps from various parts of Mozilla (including HR/Recruitment, Engineering management, Culture) held a Q&A session. There was tons of info and advice but I will try to give brief highlights:

Don’t take things too personally.

Reflect on successes and failures. Decide what you learned from both.

Get a lot of buy in when making really big decisions with large impact.

Go with your guts about people.

Make decisions that give yourself more options.

One manager remarked that her style was to have great personal relationships with people and really tried to get to know people on their level.

After the internship, when job hunting and you get an offer:

     * Negotiate your salary

     * Listen to their offer, tell them thank you and that you’d like to take 2 days to discuss it with your people. Afterward, make your counter offer. Do not take the initially offered salary.

Seek mentors.

Have confidence in your own abilities. Don’t be scared to ask questions.