Back in October, I announced that I would be blogging about my thesis, and talking about the day-to-day process along the way.
(Here’s the background and basic gist of my thesis. I’m building Catch, an iOS app that is a Tinder for femme clothes trading, and writing about the design and architecture decisions I made during development. More on Catch’s specs later.)
A few things have changed since then. Here are some updates:
I broke up with my Economics major 🙁
I decided to drop my Computer Science and Economics double major down to a Computer Science major and Economics minor, so that I could focus on other projects during my fourth year of college. I had taken all the required classes to graduate, but at my school, a thesis or project in the desired major is mandatory in order to get the degree. Early last semester, I was told that doing product research and iteratively coming up with a startup business model for my app wouldn’t be enough to satisfy requirements for an Econ thesis.
Economics was my first academic love, and while it sucked to have to give up my double major, doing so allowed me to intern in San Francisco and do a bunch of other cool things I wouldn’t have been able to do otherwise.
My thesis is all about app-building now
Since my thesis is now a purely computer science one, I’ve decided to focus on the software engineering aspect of it and create a minimum viable product (MVP) of my app that will testable and demo-able by the time I defend my thesis in late April. An MVP contains only the essential features; it was quite the exercise to take a knife to my project and cut out the parts that weren’t necessary. I decided that I won’t be publishing my app in the App Store until the thesis is over — Catch has features such as real-time chat, the ability for users to upload pictures and item descriptions of their own, and trading, all of which involve some legal stuff that is outside the scope of what I’m trying to accomplish (how can one block users? What can’t be posted as an item? How does the app deal with those who break the rules?). By keeping my shit simple and not having grand illusions of what I can accomplish in two months’ time, I’m minimizing a lot of stress.
Note: I want to cover a wide breadth of Data Structures & Algorithms topics this semester, so I’m only going to touch on concepts that I either a) believe are essential to understanding the subject, or b) struggled finding existing accessible resources to on the Internet. Once all the essentials have been covered, I’ll return to do articles on more nuanced topics (such as Sororitree Rush).
Linked list operations in this article are limited to ones that are used when implementing stack and queue data structures. Check out this great post on linked lists for a more robust description.
Have you ever wondered about how the Back and Forward buttons on your browser work? Or how your favorite clothing website determines your place in line during an online sale?
Stacks and queues, that’s how. Your browser uses a stack data structure to implement the changes in state as you toggle the buttons on the upper left corner. That clothing website uses a queue data structure to stick your access request in line, and only lets you into the store when someone else comes out.
Stacks and queues are separate data structures, but have similar operations and are implemented in similar ways.
‘Tis the season for love … or for phenomenally bad pickup lines.
I would be lying if I said I wasn’t a shameless fan of the latter. There’s something so satisfying about throwing a line out there so cringey that it makes your recipient groan.
I’ve been collecting tech-related ones for a while now (did you really expect me not to?). Here are a few of my favorites that you can send to your favorite programmer/computer scientist:
I also liked building stuff, sure. If you got into a time machine and traveled back ten years, you’d find eleven-year-old me making my first forays into photo editing with Photoshop knockoff software and DIYing jewelry based on cool stuff I’d seen on the Internet. Programming is like like doing arts and crafts with an understanding of how complex systems work.
But I was never satisfied with just making stuff. I wanted to know why code ran the way it did, how integrated development environments (IDEs — the place you write and run your code in) were built, how they could autocomplete and highlight syntax, and how people figured out how to put all the stuff together.
(and vice versa)
It’s often implied that my two chosen careers are distinctive.
Upon first glance, they do seem contradictory — the mental image of posing in a put-together outfit is at odds with the one spent furiously typing away on a keyboard. It’s “interesting” how I model despite the fact that I also write code professionally, or how I program despite the fact that I also pose for photos professionally. But are the two really that different?
Not really, as it turns out. I started my blog around the time I started programming, and I got serious with shooting and editing photos as I started considering being a full-time software engineer. When I refined my skills in the two areas, I started noticing how the mentality and best practices I picked up from one trade easily translated to the other.
Both are highly technical at the core, but require a certain amount of intuition and creativity to enjoy. Both are essentially creating something (hopefully beautiful) out of nothing. Both require solid project management skills and an eye for detail.
I use tools from the two trades on an everyday basis — I gather requirements, estimate work times, and use a Kanban board for my shoots. I debug and approach code reviews with the perception of a model after the perfect shot. I’m not an engineer despite being a model, or a model despite being an engineer. I am one (at least a far better one) because of the other.
When I first started learning to program, one thing irked me above all: the amount of goddamn time it seemed to take me to get the smallest thing to work.
I dreaded each hands-on assignment at first — not because I didn’t enjoy coding, but because I knew that it would take me twice as long as I’d wanted, and that I’d spend at least 60% of the time looking at a screen full of errors.
In cases like these, it’s easy to get discouraged or think that you’re not smart enough for whatever task you set out to accomplish. Oftentimes, though, it isn’t a lack of intelligence but rather a lack of foundational knowledge that causes you to seem “slower” than others at picking up a new concept or skill.
A question I’ve been asked a lot is: why did I choose iOS development in particular?
There are a couple answers I usually give. Swift is a really beautiful language (I actually think its verbosity is one of its stronger traits), I’m always astounded of the amount of meticulous thought that has been put into the design of iOS, an app is a program that you can take on the go … the list goes on.
But those reasons all start sounding shallow after a while. Why did I really want to pursue iOS development? It’s important to step back and re-assess these big life choices every now and then. I thought about it for a long time, and realized that the one reason that all the others stem from is this:
I’ll be in San Francisco this winter working as an iOS engineer for Motiv, a company that makes fitness-, heart rate-, and sleep-tracking rings designed to be on your finger 24/7.
I’m really stoked. It’s terribly hard to concentrate on finals right now (if this post reads really choppily, it’s because I’ve been at it all day and should really sleep).