Categories
Uncategorized

Speaking at SDSU – Careers in Sciences Computer Science Panel

In July 2022 I received a message on LinkedIn from someone who was not a connection of mine, or even a connection of a connection. He said he found my profile through the Cal State San Marcos alumni page and was wondering if I would be interested in speaking on the San Diego State University Careers in Sciences Panel for Computer Science in October 2022. Excited and interested, but skeptical, I responded asking for more information in the hopes that that was real and not some sort of scam. I am not a Cal State San Marcos alumnus, I have never even applied or attended a Cal State school, and I would say I have barely had a career in computer science. Why did I look like a good candidate for this panel?

While waiting on his response, I some quick research and found out that this person that messaged me did work for SDSU. OK, so not a scam, but why me?

When he responded, I learned a few reasons why they saw me as a good candidate: I live and have worked in San Diego County, I identify as female, and I have had multiple internships, two of which were with Northrop Grumman, a huge donator to the Engineering department at SDSU and a vocal supporter of women in computer science.

This was the opportunity of a lifetime for me – I love talking about my journey in Computer Science. Up until finding the OSU post-bacc program, I was surrounded by software engineers that have been coding since they were five years old, or who followed the standard path of completing their first bachelor’s degree and immediately hopping into their software engineering career at 22. Here I was, completing an associate’s degree and a second bachelor’s degree at (nearly) 27 to be where my friends were at when they were 22. Don’t get me wrong, I have been very lucky in that almost all of these people have been supportive and excited that I decided to follow this path. But when I started, I couldn’t have felt more alone. Most of the professors and older engineers that I spoke to couldn’t relate to my situation at all, and the advice that they gave, while I appreciated every piece of it, wasn’t always relevant.

I have always felt like it was important to tell my story. If I feel like this – like my path is abnormal and that no one has had a similar experience – there is no way I am alone in that. And by being on this panel, and talking to students anywhere from freshman to senior, I can share that with people who may feel the same way, or maybe feel like they have chosen the wrong path.

I think my story is important to share for two reasons:

  1. If you’ve already started, finishing your (first) bachelor’s degree is the most important step, whether it’s what you want to do for the rest of your life or not.
  2. You can start doing what you want later than 18. You’re not falling behind or failing in computer science just because you haven’t been coding since you were a kid or started when you were 22.

And I hope that there will be more opportunities for me to share my story in the future.

Categories
Uncategorized

I Accepted a Job Offer but Why am I Not Excited?

I am fully aware that the title may sound a little dark but stick with me.

I recently accepted a job offer at the company that I interned with over the summer. All things considered I should be extremely excited. I like the team, I like my manager, the pay is good, I’ll have medical and dental insurance (you know you’re an adult when…), I don’t have to worry about scrambling for a job after graduation, and I won’t have to worry about any more technical interviews for the time being. Like I said, I should be extremely excited, elated, over the moon. But I’m not. And that’s OK.

So why am I not absolutely stoked about my situation?

Well, like many others my ideal job would be as a software developer. If I’ve learned one thing about myself over the last 4 years, it is that I am happiest in my jobs when I am coding, and I quickly get bored and antsy when I don’t. If you asked me a year ago where I thought I would be now, I would probably say I would be an Engineer I, developing software at a mid to large-size company in San Diego. But here I am, having accepted an offer as a Test Engineer 1 at a small company in San Diego. At least one of my expectations came true!

As sarcastic as that may read, I am happy that I get to stay in San Diego.

While I would prefer to be at a larger company with more structure and more specified roles, and I would prefer to be on the development side of software rather than the test side, I see this job as a steppingstone. It will teach me how to interact with multiple groups, from upper management to software developers to hardware developers and even to the sales team. It will teach me how to properly generate and annotate test cases for when I am the one developing the software. It will teach me how to be a better developer for the testing team I work with in the future. I know I can succeed in this role, and that will show when I choose to move on.

The short of it is, having this experience will make me a better developer.

I don’t need to be excited about my new job, role, or title. But I should be and am excited for the things that this job will teach me, and I am excited for what may come after. Over the last 9 years that I have been in the workforce, one thing is abundantly clear. Every role has something you can take from it. Skills I learned when I was 18 managing a group of 15-year-old lifeguards still carry over to the work I do today.

Every job experience has value.

Categories
Uncategorized

Shared Version Control – Best Practices

I have used Github and Bitbucket for version control of various projects – personal and professional. Both system are extremely easy to use if you are the only developer on a project, but things can get a little more complicated when there are multiple developers involved. In the past four years I have had one week of dedicated training, and unfortuntately, I have run into too many scenarios where I was just glad there was a commit history to roll back to. I am definitely not the only one with a novice understanding of how to use git and version control, especially in a multi-developer scenario.

I volunteered to set up the GitHub repository for our Capstone project, and thought it might be a good idea to put together some GitHub Standards to avoid as many roll-backs and hiccups as possible. I wanted to share this short list of “Do’s and Don’t’s”, some definitions I have found helpful, and an example workflow, in the hopes that it could help another team, enjoy!

DO:

  • Select one team member to set up and manage the repository.
    • In the repository set up, require at least one other collaborator to review and accept any code changes before they are merged.
  • Select one team member to be the “Branch Lead” in charge of merging changes to the main branch.
  • Work out of a development branch off of the main branch instead of directly out of the main branch. This creates a “safe” space to debug and test without sacrificing the main branch with working code.
  • Notify other collaborators when a major change is made that might affect a feature or branch that another other collaborator is working on.
  • Always add a comment/message to each commit.

DON’T:

  • Work directly off of the main branch.
  • Allow updates to be pushed to a repo without review of at least one peer.
  • Start working on code without understanding the existing code.
  • Forget to fetch or pull updates.
  • Forget to communicate with other developers on the project.
  • End the day with uncommited changes or updates.
  • Leave a commit comment blank.

A few helpful definitions

(These definitions from GitHub but are relevant to most version control systems! )

branch: “a parallel version of a repository. It is contained within the repository, but does not affect the primary or main branch allowing you to work freely without disrupting the “live” version”

checkout: “use ‘git checkout’ on the command line to create a new branch, change your current working branch to a different branch, or even to switch to a different version of a file from a different branch”

clone: “a copy of a repository that lives on your computer [locally] instead of on a website’s server…[it] is still connected to the remote version”

collaborator: “a person with read and write access to a repository” all developers on a project should be collaborators, as well as anyone who needs to keep eyes on the project.

commit: “an individual change to a file (or set of files)…usually contain a commit message which is a brief description of what changes were made”

fetch: “[adds] changes from the remote repository to your local working branch without committing them…allows you to review changes before committing them to your local branch”

git: “Git is an open source program for tracking changes in text files”

merge: “takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a “pull request””

merge conflict: “A difference that occurs between merged branches”

pull: “fetching in changes and merging them” but does it without allowing you to review the changes first.

pull request: “proposed changes to a repository submitted by a user and accepted or rejected by a repository’s collaborators”

push: “send your committed changes to a remote repository”

rebase: “To reapply a series of changes from a branch to a different base, and reset the HEAD of that branch to the result.”

revert: “revert a pull request on GitHub, a new pull request is automatically opened, which has one commit that reverts the merge commit from the original merged pull request”

An Example Workflow

In this simple example, you are a developer working on a Windows machine who is a new collaborator on a repository that has some existing code. Your first order of business is to clone the existing repository to a folder new_dir. After cloning is complete and dependencies are installed, you can checkout the development branch and create a branch of your own off of the development branch to write code and make edits. If you think your edits are ready, checkout the development branch, merge your changes with the development branch and push those changes to the remote repository.

> git clone <remote_url> new_dir
> git checkout dev_branch
> git branch personal_branch dev_branch

# now you are writing code on your personal branch! #

> git checkout dev_branch
> git merge personal_branch
> git push origin

# now that you have merged your personal changes, go to the VCS and create a pull request so that your team cabn review your code#

Once the changes have been pushed, you can go into the VCS and make a pull request (usually a visible tab, you may even be prompted to make one) which allows other collaborators to review your edits before they are officially commited to the repo.

Happy coding!

Resources:

https://docs.github.com/en/get-started/quickstart/github-glossary\

https://www.atlassian.com/git/tutorials/using-branches

https://www.atlassian.com/git/tutorials/making-a-pull-request

Categories
Uncategorized

Capstone Adventures: The Beginning of the End and a Guardian Angel

If you’ve found your way here, welcome! My name is Lauren Ruff. I am a soon-to-be-fully-fledged software developer currently finishing up my last quarter at Oregon State. I’ve experience more than a few major life changes in the past few months and graduating will be no exception. So to start my “beginning of the end” I’d like to share a little about me and how a “guardian angel” changed my life trajectory.

I grew up on the east coast just north of D.C. but I had known since middle school that California was where I wanted to be. I was accepted to the University of California Santa Barbara and promptly left my family in Maryland to pursue a degree in marine biology with plans to be a doctor or a vet for aquatic mammals. I still can’t believe that my parents let their oldest child attend college 3000 miles from home without any friends or family within hours of where that child was going to be, but hey, I think it all went alright!

Two years into my degree, while absolutely failing microbiology, I came to the sad and life changing conclusion that I was not meant to pursue medicine – human or animal. I didn’t know what I was going to do. I had no plan, was too far into my current degree to try to switch or figure out something new, and I felt like I was letting my parents down (now is a good time to mention that my mom is an ICU/OR nurse and my dad is a Plastic Surgeon, both very accomplished in their fields). I did know, however, that I could keep my promise to my parents and graduate in four years, so I did. I graduated in 2018 with absolutely no plan and no prospects – yay (sarcastically).

Six months after graduating, struggling to stay motivated in my job and probably depressed about not knowing what I was going to do with my life or how I was going to afford to stay in California, an old friend from high school contacted me out of the blue. We hadn’t spoken in years. He reminded me of the programming class we had taken in high school, how aweful of an experience it was, and how after years of not knowing what he was going to do he decided to do bootcamp for data science. After a long chat and catching up, the first thing I did was look into boot camps and the field of software engineering/computer science – I was hooked from the beginning

This friend was my “guardian angel”. The idea of a “quick fix” peaked my interest, but I new my brain didn’t work that way, so instead of a boot camp I pursued formal education. This all leads me to today, with an A.A. from my local community college in computer programming and am now finishing up at OSU with a degree in computer science. I’m excited to finish this chapter of my life and start the next one – but first we have a capstone project to finish!

Quote of the day: Ends are a means to beginnings.