First Post!

Hello world! I’m Kevin! An aspiring software engineer and data scientist. This blog will be dedicated to documenting my journey into data science and machine learning via personal data science and ML projects and much more!

My hobbies and interests:

• I love programming. Especially in Python, although I am not great at it (yet).
• I love writing, and am trying to get better (which is another reason I started this blog).
• I enjoy reading books and articles. Currently reading Malcom Gladwell’s David and Goliath!
• I enjoy listening to podcasts (such a lifesaver during my hour long commutes)
  • Some of the ones I’m listening to right now are:
    • Talk Python To Me with Michael Kennedy
    • Stuff You Should Know with Josh Clark & Charles W. “Chuck” Bryant
    • Freakonomics with Stephen J. Dubner
    • Software Engineering Daily with Jeff Meyerson
• I love learning and am always looking to learn and get better at things whether it be new programming languages/tools/frameworks or cooking.
• I love being active, such as working out, running, and playing basketball.

Just a couple things about me:

• Currently a part time graduate student at SJSU, majoring in software engineering with a focus on data science
• Currently working as a test engineer (full time)
• Received my bachelor’s at UCSD for electrical engineering with a focus on machine learning.

Follow me on my social media, located on the left hand side (Facebook, Linkedin, and GitHub widgets), and if you want to know more about me (most of it is already in this post, but I will periodically update this page), check out my About page!

To end, I just want to share a Python design principle that I hope to live (by live I probably mean program) by from the PEP 20 release called The Zen of Python:

The Zen of Python

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than \*right\* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!