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