The first week on the job at Broadcom was fairly easy: I met with my team, greeted my coworkers from other teams (lunchroom is the best place to meet people), learned corporate rules, team project documentation, and set up my working environment.

“Science Projects”

During the first month of my co-op, I was working on a project that was not related to the main product developed by our team. My manager calls such tasks “science projects”.  This means you should try something without guarantees of success, and results of which might be forgotten in a couple of weeks. I guess working on such projects was my fate since I am a PhD student. And you know what? Such projects are not very rewarding:

1. It is tough to get them going: there is no one to ask for advice.
2. It is not guaranteed that you will get at least some results.
3. It is almost certain that this labour would be forgotten very soon because the main team working on the unrelated product.

And by the way, such projects involve reading massive amounts of documentation, which I am not a big fan of.  After my first “science project” was completed (the results were not very encouraging), I was switched to other tasks that had more relevance to the main team project. The experience of my coop suddenly became much more enjoyable. I already knew most of the software development tools my team was using with the exception of the version control system called git (if you a CompSci student reading these lines, my advice – master this tool ASAP, it highly increases your chances to be hired). I had other people I can discuss my implementation with, and what is most important after some time my colleagues started to ask me for advice!

Self Evaluations

You know, how the coop office always asks you to fill up your self-evaluation for the term and set up learning objectives? Well, mine was to learn project development flow in a big corporation setting.

Here are the results of these goals:

1. We had a team of about 10 people, and we worked on the product day and night; but when you look where it belongs in the end product, you realize that this is just a tiny feature among countless others.

2. Quality is the king when developing software in companies like Broadcom; and you have everything for this: continuous integration and testing, code-reviews by coworkers, version control.

These two conditions are very different from the academia setting! In university setting you aim for speed: the programs should just work, the amount of bugs or the quality of code are secondary. Although I did not start off doing work I was too excited about, I ended up finding my niche.  I was able to accomplish my learning objectives and learn a lot from the experience.