Intel Retrospective

Having ending my Intel internship last week, I thought it would be good to document my thoughts on my experience.

The positives:

My favorite aspect of working at Intel was being on a team. I felt respected as a contributor and was able to have insightful and meaningful conversations with my co-workers. I appreciated feedback on Gerrit code review and I felt that the review process made me a better programmer and brought up ideas I had not thought of previously. Furthermore, giving reviews was a learning experience as well because I had to give feedback on a lot of patches that contextually I didn’t know about, but on the code level, could give some valuable insight on. I definitely think my experience as a teaching fellow at UNR helped a lot in the code review process, as I was better able to catch coding mistakes with a glance-over.
I also enjoyed the content that I was writing and the sub-group I was assigned. Working with something physical such as the Solid State Drives we were using at Intel I provided some weight to the code I was writing. Having something tangible that I was testing and being able to analyze the specific bytes of information with specification compliance was a fascinating part of the job. I was the head of the Management Interface (MI) sub-group on our team which meant that I had my own MI spec separate from the normal NVMe spec most of the team used. The MI data was analyzed different and it really allowed me to be more hands-on if I had worked on other areas. Beyond the spec, I got to work cross-team with the MI people from firmware and other validation teams. This created a kind of solidarity in MI which was quite cool. I also had the opportunity to train a new graduate student about MI before I left which forced me to re-learn a lot of the concepts but also led me to create a thorough deep-dive through MI which really solidified my knowledge. Much of that presentation included information I wished I had access to starting my internship so I really hope it will be a useful document going forward with Intel’s MI.

The negatives:

I’ll start with the most obvious, code review. While I mentioned before, I did enjoy some aspects of the code review process, but my biggest issue with the system was the review time gap. It sometimes took a while for a patch to be reviewed and in the meantime, I would start another patch which would lead to a lot of context switching which would get frustrating sometimes and slow down my overall productivity. Furthermore, a patch would stay in review for a really long time as multiple co-workers gave feedback in multiple directions and sometimes people would tend to feature creep and extend the scope of a patch. It wouldn’t happen all the time, but when I had a couple of patches in review for about a month, it got really tiring having to deal with minor comments.
While coding mostly went smoothly, sometimes code review would take place of the compiler when it came to Python. Coming from C#, I thought I would dislike Python on the grounds that it has no types and no semicolons. I thought that would be confusing and hard to read. While it was frustrating not knowing the type of a function parameter sometimes, I got used to the simplicity of Python and enjoyed it for the most part. You really can do whatever you want in that language. However, the aspect of Python that really started to annoy me was the interpreter. Python is not compiled meaning that every error you get in a runtime error. If you don’t run a specific line of code, it will frequently not error. Sure we had “linters” that would take the place of the compiler to a degree, but often bugs were being caught in code review that would certainly be caught by the compiler in another language. We were supposed to thoroughly test each patch, but the degree of micro-testing the code to run every single line frequently wasn’t worth the effort especially because the function validation tool had a degree of overhead and took a little bit to start up every time. Time was much better-spent testing on the functional level than searching for any run-time spelling errors.

Overall I really enjoyed my time at Intel. Beyond the enjoyment of simply coding, I feel and I’ve been told that I’ve made a lasting impact at Intel. At the end of the day, the best job is one that’s meaningful and interesting and I think Intel checked both boxes. I do really want to return, but I do feel I should explore my options and interests.