Tips for Growing as a Developer

This week I attended an SF Python meetup about Data applications. I had a chance to chat with a fellow working on Google Cloud and these are snippets of our conversation. The reason why I’m posting is because I didn’t have a ton of knowledge/experience to offer him but I did pepper him with a lot of questions so I’m trying to help spread his knowledge.

  • his tips for growing as a developer
    • learn things that you feel might be a little above your level of understanding/comfort
    • keep working on projects
    • pick something specific to grow on (he gave an example of project scope/self-management and finishing them)
  • he also talked about Spanner (SQL-based data store for cloud apps which is horizontally scalable; I have no experience with the product and cannot make any recommendation yay or nay)
  • for testing, his group uses a custom version of pytest

Kanban pros and cons

On Friday, we had a presentation (by Omnivore) about software development lifecycle methodologies (waterfall, scrum, and kanban) at Hackbright. This was the first I’d learned about kanban in a level of depth.

This is my high level brainstorm about what I believe some pros and cons of kanban may be. Since I have not worked in a company using kanban, this is all with a grain of salt.


  • designed for max efficiency of resources (people, materials, product)
  • sounds like it could result in faster delivery than scrum
  • this sounds like env which is friendly to full stack engineers
  • this sounds like the engineers get to work on a variety of parts of the product, including qa (which I considered acceptable to jump back and forth in jobs from eng to qa and back)
  • the company is less dependent on any single employee (a lot of tech folk may change jobs); so when one employee leaves, the rest of the dept is able to fill in for their knowledge smoothly; (intellectual insurance for the company)


  • maybe this means the engineers are less of an expert in one part of the product and more of a generalist; maybe less sense of ownership over one significant part/feature (area); I do wonder if the devs still feel their work is meaningful if they are not working continuously on a large feature/bug
  • unsure if this is really a con but this means that each dev has to adhere to the coding guidelines for that company; and the code has to be super readable (easy to understand and easy to maintain) b/c from week to week (day to day) anyone might be touching the same chunk of code

General Coding Tips

Conclusions made from reviewing Udacity students’ code (for any level programmer).

  • Simpler is better.  Sometimes highly intelligent people write convoluted code. I think they feel the complexity must reflect their intelligence. However the downside is this makes the code harder to share and harder for another programmer to debug. The best code I’ve seen balances readability with abstraction and conciseness. Sometimes super abstract code is harder to understand or is error prone because it doesn’t handle all basic use cases.


  • Don’t code for yourself, code for the next programmer. This is closely related to the first point. But it speaks to items of consideration like including just enough inline comments and providing readable code. Writing code which is as clear as possible is considerate to those who share your code. This is reflecting a concept that as a programmer, you have 2 types of users (the application user and developers who work with your code base).

Tips for Young Programmers

As a Code Reviewer for Udacity, I go over a lot of students’ code. These are some observations based on common patterns.

  • Make sure to understand requirements. A lot of students are in a hurry to turn in the solution and get to the next assignment. Sometimes assumptions are made about the requirements or the student revises the requirements to what they think the app should behave like. Making assumptions takes more time to fix in the long run. Ask questions and get clarifications before you start to plan the solution.


  • Get the basics right first, then add enhancements. A minority of students are eager to show off nice to have enhancements like design or added features or complex interactions. But sometimes this extra effort is made before basic requirements have been met. Make a checklist and meet the core requirements first. Then add special features. Then refactor. Sometimes overly abstracted code leads to more bugs. Test everything on your checklist.


  • Try to code without libraries at first (as much as possible). Try to code with vanilla JavaScript before frameworks. Try to code with plain CSS before Bootstrap/Sass. By all means, learn the JS frameworks and CSS pre-compilers and accompanying libraries. But try to code everything by hand first (for ex. sometimes using a library to handle forms in react or redux abstracts the logic that makes it difficult to troubleshoot when an input handler goes wrong).


  • Show that you care about your work. Looking at someone’s code and app UI/interactions, it is quickly obvious how much pride the coder takes in their work. It is clear when the student is just trying to pass or is truly bringing their A game. When taking a course, really try to learn the best practices and ask questions. Skimming through a course (even when busy with a full-time job) is not really getting value out of the experience. Take the time to learn to do the job right during a class because frequently when the skills are put to use in a job, there may not be enough time to dot all your i’s and cross all your t’s. You’ll want to know all the tradeoffs you are making and why.



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…