What I learned from the engineers on the Blockly open source project

It's Computer Science Education Week and I am really glad to see how much it has grown over the years. I expect this year, more people will become aware of the benefits of computer science and how learning to program provides you with powerful tools to create and innovate than in any year prior. If you haven't tried the Hour of Code I highly encourage you to check it out. The ability to program transformed what I was able to do in my classroom and has opened up many opportunities in all areas of my life.

In my last post, I shared my brother's story about how a Computer Science MOOC opened up a new world of exciting projects and ideas for him so now I'd like to reflect on one of the projects I've been working on for the last few months. I already know a bit of computer science, I've learned how from books and tutorials over the years. Nevertheless, no matter how much I learned, it never seemed like I was getting any closer to developing the kind of software professional engineers create. I had access to all of the same resources the professional have but I just could not figure out how to cross this chasm and write more complex programs.

I became much more painfully aware of this issue at Google where I am surrounded by experts in computer science. I realized there was something that was missing, and our team's technical manager told me I needed code reviews, the feedback and guidance one receives when someone more experienced looks at your code. He suggested I join an open source project.

It just so happens that I sit next to +Neil Fraser (blog/tutorials) and +Ellen Spertus (Mills College Faculty Page) who work on +Blockly (Google Code page, demos) and before that App Inventor. Over the next few months, through their kind, helpful, and specific feedback; I was able to build on what they had developed. It is one thing to read about a topic but actually using version control, following style guides, and following the DRY principle taught me lessons that books and tutorials alone never could.

Their willingness to help me improve as a programmer motivated me to learn quickly so I didn't squander their time and mentoring on simple syntax/logical errors (always run the linter!). After improving the readability of my code, I was able to implement additional features and it was so satisfying every time they replied with an LGTM. Not one of my code reviews was accepted the first or second time which tells you:  I still have a lot to learn, Neil and Ellen maintain a high standard of code quality, and that they were both very patient. Code reviews are an incredible way to grow as a developer and as long as you follow Ellen's advice to, "check your ego at the door", you will learn a lot.

I've pointed out the benefits of feedback and refinement for students over the years but I was unprepared for how much and how quickly my programming skills would improve. I am all the more convinced that anyone who is interested in learning how to do something really well cannot learn in isolation. A mentoring/feedback loop is essential to continue growing.

Software developers are always learning new technologies, languages, APIs, quirks, idoms, and styles all the time. Even after all that, things never work like they should, and debugging takes just as much, if not much much more of your time as writing the original code. To be a software engineer is to be very cognizant of how one learns best, where to find answers to abstract questions, and troubleshooting mysterious issues. I am humbled to have worked with both of them, and in general I am inspired by how willing engineers at Google are at helping one another (provided you have done everything you can to figure it out for yourself).

Based on my experience, I would highly recommend joining an Open Source project:
  1. You will learn more than you ever could just from reading books or taking classes. It's a great way to put into practice what you are learning.
  2. There is a great deal of satisfaction in supporting a community/project that has a laudable goal.

I've been told that not all open source projects are created equal so if you are looking to join one, here are a couple of tips:
  1. Find one you care about. You may end up spending a lot of time on the project so pick one you find worth supporting with your time and effort. There are no shortage of projects out there so whether you pick one because of it's purpose, the programming language it's written in, or whatever else, make sure you have some good reason so you are willing to stick with it.
  2. Are you going to learn from it? Look at the code repository, can you tell what the code does, is it readable? Do they follow a style guide? I was working with two experts in computer science at Google so your results may vary. If you are not going to get valuable feedback then you will not learn as much as you could.
  3. Test the waters. Submit a small patch and see what their feedback is. While personality types differ and some can be more snarky than others, a code review should not be a disheartening experience, feel free to join a more appreciative project if you feel like you're being treated poorly.
  4. Supporting a project does not have to involve writing code, Blockly and other projects are always looking for translators, documentation, etc and you can commit as much time as you have to offer.
I love that no matter how much I learn, there is more to discover and improve one's skills/knowledge. I hope you will take this perspective into the new year and model it for your students.