Ending Ugrad #2 with Sam

Over the past couple of weeks I’ve been wrestling with setting up user login and authorization using Google Cloud Services. More than anything I’ve worked on, this project has made me appreciate how important it is to find a way to go out and try to apply everything you’ve learned to reinforce it. I thought that taking care of authorization would be easy! I’d done it before in CS493 in multiple projects. However, I quickly realized that the cloud course involved only a simple server-side application, while my group is developing a web app with a front-end and a hosted database. I’ve been desperately trying to expand my simple experience to my group’s project, and it’s been an incredible challenge. 

The API that I was familiar with is soon to be deprecated, and I’ve had to learn a new set of methods that currently have minimal documentation. It’s been an enjoyable learning experience, and an interesting lesson in the way that larger projects can be held back by unsuspected problems. In order for my team to integrate all of the endpoints that we need for the various pages in our web page, the user must be associated with all database queries. I’ve felt a bit more pressure to complete my portion of the project to not hold up development. Perhaps for the first time during this degree, I’m experiencing a work-like feeling of tough time-constraints. This has been a welcome feeling during the final few weeks of the term, and I’m looking forward to more struggles and puzzles to solve over a long career.

During the initial stages of my group’s project, I’ve taken on the task of designing our database structure. In a couple of recent courses I’ve done some back-end development to store some entities in a data warehouse. However, I haven’t had to put together the details so specifically in an ERD or schema since the databases course. Over the past week I’ve spent a lot of time reviewing database concepts, but all that review didn’t prepare me for something I haven’t had to do yet: make actual decisions about the type of database to be used and the framework used to make it.

The differences between NoSQL and SQL were certainly covered in the databases class, but I don’t think the decision had been left to us for that class’s project. It’s been interesting to be faced with options and delve into some of the reasons to choose a particular framework, hosting service, etc. Don’t worry, I won’t bore you with an exhaustive list of all of the pros and cons of these choices. As a novice programmer, I find these kinds of decisions to be the most obviously challenging part of the profession. Sure, almost anyone can learn how to implement all sorts of data structures in a variety of languages, but knowing exactly when to utilize each of them is the hard part.

I felt fairly lost reading through descriptions of various DBMS. The scale of my group’s capstone project is fairly small, so a less-optimal choice for a DBMS would likely not set us back too far. However, I think we made the correct choice to use a SQL database and PostgreSQL as our DBMS. Our data model is almost guaranteed to stay fixed after the initial schema is set, the data is not hierarchical, and we’ll likely need to perform some complicated queries on the data [1]. Even if PostgreSQL isn’t perfect, it’s a DBMS that I haven’t used, so I’ll be eager for the chance to see something new (that will certainly be acceptable for our project).

References
[1] B. Anderson, B. Nicholson, SQL vs. NoSQL Databases: What’s the Difference?, IBM, 2022.

About 4 years ago, I left my career in the actuarial field with no clear alternative in mind. My primary reason for exiting was a concern with being trapped in the insurance industry for the rest of my career. I may have been foolish to leave a stable field that is widely considered one of the most comfortable jobs in the world, but I knew I wouldn’t be able to remain in that sector until retirement.

During my first undergraduate degree at a STEM school, I heard almost no conversations about the industries that my peers wanted to work in. The prestige of the job they were after was the only important factor. I thought this was concerning then, and as I’ve gotten older, I’ve found this personal distancing that STEM workers do from their work interesting. We all have a set of values that inform our decision making, yet I rarely see this inform people in STEM’s job choices.

Data from the Bureau of Labor Statistics is not as granular as I would like, but it does show that as programmers, we’ll have a bit of choice in the sector we end up in. The table below shows the distribution of the largest employers for programmers as of 2021.

There are obviously a lot of additional employers missing, but almost all of these data points encompass a variety of industries. As someone privileged enough to have a comfortable office career with some choice in where I work, I’ll always be drawing personal lines in the sand around certain industries (and ruining my opportunities at some prestigious companies). If you’re lucky enough to have the freedom of job mobility, I’d encourage you to always think about the material impact of your work on the world – good or bad!