During a recent pair programming session, I came to the tough realization that I really know nothing about CSS. Granted, I can add in a div tag here and there, and yes, I can make a responsive page using Twitter Bootstrap like no one’s business. But, what do I really know about design? Not as much as I thought I did.

I figured out that this was the case when the designer I was pairing with started using ems and rems. I should probably preface this and say that I have always been a pixel kind of girl. I was formerly of the mindset that you can have any font size you like – as long as it’s defined in pixels.

But, after doing a bit of research, I found that ems and rems actually have an interesting history behind them, and are super helpful when it comes to elastic layouts and responsive design.

Last week, I had my first full-day technical interview. It was a thrilling experience, and so much more fun than I expected. Part of that was because I viewed the whole experience not as an evaluation, but rather an opportunity to learn as much as I could from experienced developers. I also knew that, irrespective of whether I did well or not, I’d learn some new technologies and tricks. And boy, was that the truth.

I left the interview with a long list of things I’d never heard of (why hello, blog posts for the next five Tuesdays!), one of which included the use of decorators in Rails. I was actually kind of surprised that I had never encountered decorators while building my own Rails apps, but it turns out that these are actually pretty advanced topics and there’s a good amount of debate on how and when to use decorators, and whether or not they’re actually useful.

But hey, none these discussions apply or make any sense unless you know what a decorator actually is. So, let’s find out!

It’s a brand new year, and with that comes a renewed sense of self. Also: a rather lengthy todo list. Enter #technicaltuesdays, or my attempt at beefing up my technical chops by posting a blog post every week — specifically on Tuesdays, in case it wasn’t obvious. (Sorry, Thursday, you were a close second, but you just didn’t make the cut.)

So, what’s on the menu this week? JavaScript! New year = new me, you guys. Actually, some of my technical interviews have been a bit JavaScript-heavy, so I’ve been stepping up my curly bracket game.

In honor of the new year, I wanted to use JavaScript to create a quick “New Year’s Countdown” function. Suffice it to say, it was neither quick nor easy. But I learned about two cool timing events in JavaScript – setInterval and clearInterval – and now you can learn about them, too!

Recursion is kind of like the cloud – it’s hard to explain and you might not ever see it, but it definitely is a thing. Yet we deal directly with recursion more than we may realize.

Recursion is the process of repating a procedure or action. In Ruby, we put all of our procedures inside of a method, and we use loops to repeat those procedures again and again. So, if we have methods and loops, what’s the need for recursion?

Well, as Rubyists, we’re pretty lucky to work with a language that’s intuitive and human-friendly. We like to read and write code that’s actually comprehensive and (ideally) can be understood and appreciated by programmers and non-programmers alike. It turns out that recursion is a big part of that. It can make our code more readable and can even help it run faster.

Disheveled hair. Bags under your eyes. Hermit-like tendencies. Suffice it to say, project mode can do a lot of things to a person. It’s the first time you’re on your own, and the feeling of “sink or swim” will, inevitably, hit you in the face at some point or another.

But, project mode also teaches you a lot about what it means to focus and ship software. And it doesn’t really matter that you’ve only been coding for 9 weeks and that your application has only four models and that you’re missing a ton of <div> tags. Why? Because the mistakes you make in your first application are ones that you’ll never make again. So, inspired by Blake’s post on lessons learned from building a web application, here are a few things I learned in the process of shipping my first piece of software:

When I was in my terrible twos, my mom walked in on me writing all over the white walls of our living room with a pencil. I didn’t even know how to write, much less what to write. But apparently, even as a toddler, I knew that writing was exactly what I wanted to do. (Side note: when my dad got home, he made me erase everything I’d written. But I digress.)

Suffice it to say that writing has always been the medium of choice when it comes to expressing myself. So when I set aside my literary pen eight weeks ago to learn how to code at The Flatiron School, I did it with a heavy heart. I knew I’d be learning how to build amazing things with the powerful tools that programming gives you, but I also assumed that I’d be abandoning my one true passion.

But I’ve learned two important things since then: first, you probably shouldn’t assume things randomly. Second, and more seriously, writing and coding are far more similar than they are different. And I’ve realized that coding has not only made me a better writer – it has also made me a better person.

Two weeks ago, I was introduced to the Asset Pipeline. I didn’t really think much of it at first, and part of me even assumed that I’d never really have to see it again. It was a little like going out on a pretty forgettable first date – nothing particularly intriguing about the whole thing, but it somehow leaves you feeling kind of confused and generally rather perplexed.

But here’s the thing: I did see the Asset Pipeline again. And boy was it awkward. After learning JavaScript this week and brushing up on my Rails, I realized that I’m going to run into the Asset Pipeline at some point or another, so I might as well get to know it a little better. Here’s a little refresher just in case you haven’t seen the Asset Pipeline in awhile, either.

Controllers: we all have ‘em. Sure, they put the C in MVC, but how much do we really know about these mysterious creatures? Probably not a lot. Don’t you wish you could just look your Controller in the eye and be all, “Hey dude, what are you?” Well, you can. All you have to do is just poke around a bit in your code.

Let’s start with what we do know. Given the MVC orientation of Rails, we already know that the Controller acts as a kind of mediator, intercepting messages between the client and the server, and passing information between the model and view. But ultimately, Controllers are nothing more than Ruby classes (that inherit from ActionController::Base) with class methods called “ actions”, which are simply meant to render a template for the user to see. But don’t mistake them as simple chunks of code; there are also some pretty amazing things that Controllers can do.

Confession time: I’m kind of in love with object-oriented programming.

I should probably clarify that I don’t always understand OOP, and I sometimes even confuse myself for no good reason whenever the topic of “self” comes up. But hey, every relationship has its ups and downs, and I’ve only really been committed to this one for the past week or so.

OOP is easy to understand mostly because of its strong connection to real life – everything is an object, all objects have properties/traits/characteristics, so on and so forth. But dealing with multiple types of objects across different types of classes gets real tricky, real fast. This especially holds true when it comes to class inheritance.

Confession time: I’m kind of in love with object-oriented programming.

I should probably clarify that I don’t always understand OOP, and I sometimes even confuse myself for no good reason whenever the topic of “self” comes up. But hey, every relationship has its ups and downs, and I’ve only really been committed to this one for the past week or so.

OOP is easy to understand mostly because of its strong connection to real life – everything is an object, all objects have properties/traits/characteristics, so on and so forth. But dealing with multiple types of objects across different types of classes gets real tricky, real fast. This especially holds true when it comes to class inheritance.