Real talk: I don't like computers. I might even hate them sometimes. We didn't have one in my house until I was 15, and call me old-fashioned--or just plain old--but life felt pretty damn sweet and a lot slower before the known body of information was doubling, like, every two weeks (that's a blatantly made up non-fact). So why am I talking about or even doing any coding?
It's because coding is to computers like wine is to grapes. Except wine comes from grapes and coding doesn't come from computers, but that's not the point of my not-at-all-apt metaphor. The point is that you might hate grapes or you might think they're okay-ish, but if there's a day-old pastry at the bakery and it has grapes in it and it's 50% off, and you're unemployed because you're in a coding bootcamp, you'll buy that cheap, grape pastry and mostly enjoy it. But boy-howdy, you'd way rather have a glass of wine.
Just in case I lost you there (I know: I did. Sorry about that) the day-old grapes is computers. It'll do in a pinch and maybe it's useful, but it's not the best. On the other hand, the grape-related product, wine, is completely amazing. Grapes and wine (or computers and coding) are related to each other, but only one of them gets you tore up. And makes you look classy at the same time.
Coding relates to computers, but what I was shocked to find when I started learning to code is how unrelated it is. It isn't really about the machine. It's all about creativity, critical thinking and analysis, and flexibility.
Take this example. On a project I completed recently, I realized halfway through that I needed to save some information in my database (mySQL) that I hadn't anticipated needing to save. I opened up my file with the schema, put my fingers on the keyboard, nodded in anticipation of the super smart code that was about to pour out of me, then realized I had no idea where to start.
Something I didn't understand about coding at first is that there usually isn't a simple, single, straightforward answer about how to do something. There are as many ways to accomplish a task--like adding some info to a database--as there are people who can do the task. (Okay, maybe not quite that many ways, but you get the point.) So, with this task, I had to figure out a way to preserve some tags--which had previously been saved inside a table called "posts"-in a table of their own while also relating them back to their associated post (posts have tags attached to them, that a user chooses). My first idea was to add a table in my schema that looked like this:
CREATE TABLE tags (
tagId INT,
postId INT,
FOREIGN KEY (tagId)
REFERENCES tags(tagId),
FOREIGN KEY (postId),
REFERENCES posts(postId)
)
That's a one-to-one table, with one tagId for every one postId. But I didn't yet have a table just for tags, so I'd need to make another table, so I made this one:
CREATE TABLE tags (
tagId INT AUTO_INCREMENT,
tag1 varchar (15),
tag2 varchar (15),
tag3 varchar (15),
tag4 varchar (15),
tag5 varchar (15),
postId INT,
PRIMARY KEY (tagId),
FOREIGN KEY (postId)
REFERENCES posts(postId)
)
Ah-ha! I thought. I have mastered you, tags! I'd taken a many-to-many relationship (between tags and posts), split posts and tags up into two separate tables, then made a join table that created a one-to-one relationship between postId and tagId. Perfect.
Except it wasn't.
I talked to my colleague, who was managing front end for the project, and realized that this schema set-up would require us to overhaul about half of what we'd already written. The details of how/why are too esoteric (and frankly too boring) for this little blog post, so I'll spare you them, but suffice to say, I'd spent a not-inconsequential amount of time just trying to figure out how to solve my problem--because many coding problems don't have prewritten, obvious, immediate solutions--then a good bit of time actually implementing the solution I came up with, only to find that it wouldn't work after all.
I had to scrap it all, go back to square one, and start over with trying to find a solution that would better meet our needs. Ultimately, I went through a few more potential ideas, tried out a couple things, and ended up including tags inside the posts table, and had to write a slew of new functions to get info about the tags into the right spots.
So why does this matter? First, it's indicative of a typical pattern with coding. You encounter a problem for which there is no straightforward or prewritten solution. You troubleshoot the problem, figure out what you need to do, and then try to make an educated guess about the best way to tackle it. You give it a shot, maybe get lucky and have something that works on the first try, but likely you have to go back to the drawing board again and again.
All of that means coding is about being a flexible and creative problem solver. Which is what makes me love coding. It's fun to run into obstacles and logic my way through solving them. Every time I get past one, it's like I just beat Diamond on American Gladiators at jousting.
Coding is for people who can be comfortable with uncertainty and who want to forge a path of their own, instead of looking for one someone else already made. And those people have to be willing to let go of code they wrote if it won't work, be creative to come up with unexpected solutions, and adapt to their circumstances. Plus you have to Google shit all the time. Which is why sometimes I like computers.
Top comments (0)