Creating a welcoming space for beginners

Before I became a programmer, I was a teacher. For the most part, I taught academic English to speakers of other languages at a University. Although I’ve switched careers, I find that my teaching experience becomes applicable very frequently in my job, and I love taking on a teaching role whenever I can.

About a year ago, I studied at Enspiral Dev Academy, a coding bootcamp based in Wellington, New Zealand. After completing EDA, I worked there as a teaching assistant, helping bootcamp students navigate the course, providing help with coding challenges, and helping to develop the curriculum.

I’m also part of the team that organises RailsN00bs — it’s a meetup group that meets once every three-ish weeks in Wellington. We’re open to all people who want to learn about Rails, or get into programming. We get a wide variety of attendees every session — folks who are professional programmers, who have been programming in other languages for many years, but want to learn about Ruby and Rails;  People who have never seen command line before and have never written a line of code, but would like to learn; People who have been teaching themselves online, and want to connect with other programmers IRL.

So, I’m frequently a beginner, but I’m also frequently in a position where I am helping and guiding other beginners, at many stages of their career. From my experiences, I’ve learned a few things about helping beginners, which I shared at a talk at RailsCamp NZ 2016, and have subsequently written up here.

So. How can you create a welcoming space for beginners?


It’s important to frequently reassure beginners that it’s okay to ask questions, even (or especially) if they seem ‘dumb’ or ‘simple’. Often when I’m learning something new, the person teaching me or the group will say this once. It’s important to re-iterate this often, though. Beginners frequently feel intimidated and unsure of themselves, so frequent reminders that it’s okay to ask questions, it’s completely cool to not know something, and that it’s fine to be wrong about things, are always welcome. Remind people multiple times, every day, until your audience becomes comfortable asking questions. If your learners seem reticent, it’s your job to remind them, and encourage them.

Never ask ‘Does that make sense?’

This was the first thing I learned in teacher training. Never talk at a learner and then ask ‘Does that make sense?’


Let’s be honest, when someone asks you ‘does that make sense?’, your immediate instinct is to reply ‘yes’, even when it doesn’t. You want to please the teacher by giving them the answer that they want.

Let’s be even more honest — most of the time when someone asks you ‘does that make sense?’ you haven’t even had enough time to parse and analyse the information that they’ve given you, so you actually have no idea whether or not it makes sense at all. So, you’ll reply ‘yes’, because the asker is waiting for an answer and wants to move on. It’s only later on, when you try to implement the knowledge that has been given to you, do you realise that the explanation didn’t make sense at all.

So what to do instead?

Ask specific questions. Ask questions directly related to the information you’re trying to impart. For example: “Can anyone tell me what sorts of attributes at User model might have?”, or “Who can tell me what a controller does?”

By asking specific and relevant questions, you’ll be able to gauge your learners’ understanding of what you’re trying to teach. If no one can answer, you need to refactor your explanation!

Embrace silence

After asking a question, and receiving no answer, wait three seconds longer than you usually might before answering your own question. Embrace that slightly awkward silence, and give your learners a little more time to formulate words. You might be surprised at how often, in those three seconds, someone hesitantly raises a hand, and gives an answer that’s spot on. In fact, even if the learner’s answer isn’t quite right, getting them comfortable having a go at answering a question is valuable in itself.

Too often, I find that teachers and presenters move on too quickly. Taking the time to slow down and having a learner answer a question can be hugely valuable for everyone — you might learn a new perspective, or if a learner answers wrongly, it might shed light on a mistake that you’ve made in explaining a concept. By seeing a learner answer a question, other learners will gain confidence in their own abilities to do so, and perhaps pipe up next time. Just give them those three seconds.

Define everything

Perhaps this is my background in English teaching coming through, but I am a big fan of defining jargon right off the bat, to lower the barrier-to-entry for beginners. At Railsn00bs, when we do our Intro to Rails session, the first thing we do is create a new Rails project, and bring up the default welcome page that every Rails project comes with. There’s lots of helpful info on that page, but it’s littered with jargon.

We start of by highlighting every piece of jargon on that page and asking the class to help us define each of the terms — models, views, controllers, migrations, and so on. We write down the definitions, and save them to refer to throughout the session, and for learners to access later when the session is over.

Not only does this serve to get everyone on the same page, it also gets learners thinking about what they already know, and thinking about how to apply that to Rails. Building this confidence early is really important to getting learners excited about Rails and trying new things.

Use real-world examples

When helping beginners, use real-world examples where possible. At Railsn00bs, we often build a project such as a super simple blog, or gallery. Something that learners are familiar with, and that we can talk about by relating to already familiar concepts. People generally have an idea of what a User, a Post, or a Category are. We use that prior knowledge, and build from there.

Where possible, avoid `foo`, and `bar`, and `baz`. I find that learning something new is often stressful enough, and talking only in abstractions can be even more intimidating for beginners. Don’t make someone think more than they have to! Take the guesswork away by providing something more solid for the learner grasp on to.


Get into the habit of enthusiastically praising your learners for trying things, for getting things right, and for working hard. It can feel awkward (particularly for Kiwis — we can be a reticent lot), but as a learner, I certainly appreciate a few words of praise. That sort of encouragement can help keep me going when I’m stuck on something, or when I’m finding things particularly hard. It can be the difference between giving up, and trucking on.


On that note, thanks for reading, reader. I hope you found a small nugget in here, something that you can take away and use in your day-to-day work, or try out the next time you’re in a position to teach. I’d love to hear more about your strategies and experiences, as a learner, as a teacher, or both. Comment here, or chat to me on Twitter!


Continuing your learning as a post-beginner programmer (part 3)

Missed Part 1? Or Part 2? Read them for more strategies on how to continue your learning as a programmer.

Hands up if this has ever happened to you:

You’ve been learning something new, and maybe working with it for a few weeks. You run into a problem. You Google it. Someone on StackOverflow has asked the same question. Good!  you think, here’s the answer I need!

And then you read the answer, and none of it makes any sense. You know some of the words, but they’re arranged in unfamiliar ways, creating sentences you don’t understand. There’s probably a few words you don’t know in there too.

Congratulations! You have just turned a (or several) unknown unknown into a known unknown.

First, let’s talk about those concepts. What’s an unknown unknown? What’s a known unknown? To illustrate, I made you a super fancy diagram:

known known

Okay, so ideally we want to discover those unknown unknowns (thus making them known unknowns), and turn them into known knowns. Let’s do it!

Learn your vocab

Granted, this is coming from a former English teacher. Trust me, though — it’ll help. Sometimes by Googling for a definition and reading a few, you’ll discover that you’re already familiar with the concept in question, you just didn’t have that particular name for it. Congratulations, your known unknown is now a known known!

Take a Detour

Oftentimes, though, it’s not that simple. You might uncover a treasure trove of Things That You Don’t Know. That’s okay! Again, don’t panic! But, it might be time to re-assess your trajectory.

I like to call these discoveries unanticipated prerequisites. It’s time to take a detour! You may not be able to achieve your original goal, but you now have a better idea of what you do need to learn in order to get there. It’s a good idea to write all those things down, and start ticking them off. For each thing that you know you don’t know, start learning. You might use the same process that I’ve been suggesting in this series of posts, or you might come up with a different way. Different types of learning challenges may require different approaches — perhaps one item may just require a quick video and some tinkering, while another might require you to build an app, make mistakes, and learn more lessons.

Remember, all of this is okay! Don’t beat yourself up if you’re unable to achieve your original goal right now. Keep working on the objectives that are right in front of you, and you’ll get there eventually.


I am really, really bad at reflecting on my learning. There’s always something new and shiny to move on to, it’s easy to take for granted the fact that I have learned an enormous amount (particularly in the last year). I don’t do it often, but I find that whenever I reflect on my progress, I feel good about myself and my journey.

Take a moment to appreciate how far you’ve come. You might look at some old code that you wrote, or re-do something that was challenging for you a few months ago, and find that it comes easy now. Smile, and pat yourself on the back. Well done!

So, that’s it! That’s my strategy for continuous learning as a programmer. I hope you found a useful nugget or two in there. I’d love to hear from you too — how do you keep your learning going? What strategies do you use? Comment below, or tweet me @raquelxmoss

Don’t forget to read parts one and two of this series

Continuing your learning as a post-beginner programmer (part 1)

If you’re anything like me, your process for learning something new — say, a javascript framework, a design pattern, or a language — looks something like this:

  1. Read the documentation, check out a basic tutorial, and get Hello World up and running, pat yourself on the back.
  2. Look up several tutorials, pick the least intimidating-looking one, and make a basic app — something like a To Do List.
  3. ???
  4. Profit?

We’re going to focus on the ??? part. By the time you’ve reached step two in the process, you’re probably feeling pretty damn good about yourself. You’ve glimpsed some of the potential of The New Thing, you’ve implemented a few basic concepts, and perhaps you’ve even solved a few problems. You’re probably excited to start building stuff with The New Thing. Let’s do it!

Umm…. okay. Now what?

First, Don’t Panic.

In my experience, if you panic, you will dither, and you will never get anything done. This part is scary — there’s a whole world of options to explore and decisions to be made. You might feel a bit like you do when you’re at the supermarket — dazed by all the bright lights and trying to select a pack of toilet paper from a wall full of options.

Let’s mitigate that panic somewhat.

First things first:

Be kind to yourself.

Please remember that all of the following things are totally okay:

  • Abandoned repos
  • Not coding for weeks or months
  • Getting completely stuck
  • Deciding you don’t actually want to learn The New Thing
  • Failure

Seriously. If you try to make some things with code and it doesn’t work, no one is going to sit you down and tell you you’re failure, or a terrible person, or that you’ll never be worthy. I can almost guarantee you that people are going to be extremely impressed that you are trying and learning new things, being creative, and tackling problems. If yourself tries to tell yourself that you suck, please try to stop yourself.

Okay. We’re not panicking, we’re okay with the possibility of failure. Now, what do we build?

Figuring out what to build can be pretty intimidating, right? You want to make something useful, or cool, or innovative, or creative. If you don’t have a specific idea, though, don’t try to force an idea to materialise, and don’t let that discourage you from forging onwards. My suggestion is to have a standard app that you build when you’re learning something new. For me, it’s a messaging app. I try to make an app that has users, who send messages to each other. Maybe the messages have different states (‘sent’, ‘read’).

Why do this?

  • Because you can start right now! You don’t have to wait for an amazing idea to come (incidentally, don’t worry — the ideas will come. Be patient).
  • If it’s something you’ve made before, you can relax a little because a whole lot of decisions have already been made for you (for instance, your data model). You can focus your brainspace on The New Thing.
  • You could even clone something that already exists — Reddit, Twitter, IMDB, for example

My second piece of advice is to have an app that you continually add to as you progress in your learning. It’s a lot less intimidating than starting a fresh project each time, and it will give you experience in maintaining and improving projects, which is a huge part of life as a professional developer. Your learning progress might look something like this:

  • Build a Ruby on Rails app
  • Create a snazzy front-end for your Rails app with a Javascript framework, like React
  • Implement a Flux-type architecture so that you can organise your React in a way that makes more sense
  • Learn how to test Javascript and add tests to your React
  • Make your app responsive by learning and implementing Flexbox and Sass

Iterating continually over an existing project can be really satisfying — you improve your project, you improve your skills, and each time you’re able to focus directly on The New Thing you’re learning.

In part two and part three, we’ll be looking at other types of projects you can build while you’re learning, taking detours, and what to do when you get stuck.

Review – Scalable and Modular Architecture for CSS by Jonathan Snook

Over the last year I’ve become increasingly frustrated with CSS. I used to be its champion; when people moaned about how touchy and picky CSS is, I told them “It’s really not that hard! You probably have a specificity problem, let’s take a look”

Since increasing my knowledge of basic programming principles, though, and diving into Ruby and Javascript, I’ve been loathe to spend time on CSS. Every time I touch it I feel frustrated, and this joke hits far too close to home:

“Two CSS properties walk into a bar. A barstool in a completely different bar falls over”



I’m annoyed at my frustration, and I want to get back my love of CSS — this time, by increasing my knowledge of CSS and related tools like Sass. I want to dive deeper and take as much pride and joy in my CSS as I do in my Ruby.

To that end, I finally picked up Scalable and Modular Architecture for CSS by Jonathan Snook (known as SMACSS, and pronounced ‘smacks’) and read it through. SMACSS is a great primer on organising your CSS. It’s particularly useful for CSS beginners, as following SMACSS style will get you into some good habits and leave you feeling less overwhelmed by the hodgepodge of rules, selectors, and properties that can build up the first few times you seriously try to style something. It’s also great for people like me, whose knowledge of CSS built haphazardly over the years — I know how to do some cool things with CSS, but my organisational style left a lot to be desired.

Snook suggests categorising your CSS into a few different groups:

  • Base, which contains all the default rules. There should be no use of class or ID selectors here, only single element selectors
  • Layout, which as the name suggests, specifies how the elements should be laid out on the page.
  • Modules, where the meat of our styling lives. In here you will mostly be using class selectors to apply rules.
  • State, which contains rules that describe how our modules look in different states — selected, active, hidden, highlighted, featured, what-have-you.
  • Themes, for when multiple different ‘skins’ may need to be employed (e.g. a ‘light’ theme and a ‘dark’ theme).


The rationale here is that by categorising CSS this way, you can avoid repetition and keep your CSS DRY.

SMACSS contains lots of relevant examples that show exactly how such organisation can result in more sensible CSS. Unfortunately, if you’re reading on an e-reader, the code examples can look a bit out-of-whack (I’ve found this for all programming books, though).

My read-thorough of SMACSS was pretty gratifying. As it turns out, the way I’ve been writing CSS, particularly over the last six months, has been pretty close to SMACSS style anyway. You may find this too, particularly if you’re familiar with CSS libraries such as Bootstrap and Pure, which mostly encourage SMACSS style. Reading the book gave me a bit more context as to the why of doing it the SMACSS way, rather than just the how.

My understanding of the organisational structure is much better, and I’ve identified lots of areas where I can improve. In particular, my state rules have mostly been contained in my modules. From now on I’ll start separating them out. I’ll also admit that my organisation of CSS properties is very spotty. Though I’ve been aware of the suggested structure of box, border, background, text, other, my adherence to it has been on a when I remember and can be bothered looking up the order basis, which hardly leads to consistent code. Here’s an example that follows the property order suggested by Snook:

p.featured-text {
  position: relative;
  top: 20px;
  display: block;
  width: 80%;
  padding: 10px 20px;
  border: 2px solid #efefef;
  border-raidus: 6px;
  background: #fff;
  font-family: Gotham, Arial, Helvetica, sans-serif;
  line-height: 2;

Some of the examples in the book are, of course, out-of-date. The author takes care to mention IE6 support, but only a really sadistic client would force a developer to support IE6 these days. There’s also a lot of guff about vendor prefixes which we are privileged enough to ignore now thanks to tools such as Bourbon.

If you’re into LESS, you’re out of luck when it comes to the pre-processors section of the book. Snook gives examples exclusively in Sass. It’s not hard to translate to LESS, but let’s face it — Sass seems to be winning the pre-processor game. Notably, Bootstrap 4 will support Sass rather than LESS, and if you’re a Rails developer, you’re probably using Sass exclusively too.

SMACSS is a quick and painless read. There’s no crazy jargon and if you have a passing familiarity with HTML and CSS, you’ll keep up with no trouble. I recommend reading it if you’re just getting into CSS, or you’re looking to optimise and improve your CSS organisation.

Becoming comfortable with being uncomfortable

Last time I blogged I wrote about how programming was something that comes unnaturally to me. The post seemed to resonate with lots of people — several reached out to share their own experiences, which was extremely encouraging. If you ever want to chat to me about the id, the ego, the superego, and programming, by all means do!

What I didn’t really explain very well in that blog post is how I get things done, on a day-to-day basis, if the stuff that I’m doing doesn’t come to me naturally. The answer, simply, is to get used to being uncomfortable.

Doing things that you’re not naturally great at is uncomfortable. Every step of learning is a struggle and you’re constantly battling your own limitations. The most common feeling I have is that I can recognise good code when I see it, but I’m damned if I can implement those same techniques in my own work. I guess it’s like any language — often learners are able to read and listen a lot better than they can speak and write. Unfortunately for me, Spanish verb conjugations make a lot more sense to me than programming design patterns.

It’s okay though. I’m not an expert at this by any means, but I’m learning to embrace the discomfort and get shit done. When I go to work, or sit down to do some coding on a personal project, I know that I’m going to experience a lot of frustration. I know that whatever I do, I’m going to run into things that I don’t understand. Or, more likely (and more frustratingly), I’ll encounter concepts that I almost understand, but are just outside my grasp enough that I struggle to recreate what I’m seeing.

I also know that I am going to experience fear. The main fear I experience when starting a project is that, obviously, I’m not going to be able to do it. This is a trap! If I let this fear put me off, I can dither for weeks before trying anything. It’s a silly, unfounded, and generally unhelpful fear that can stall my productivity for too long.

To give you an example: for several weeks I had been putting off writing the code for API authentication in my personal project Gifery. It’s something I hadn’t done before, didn’t really understand, and didn’t really know who to consult about. I knew that it would be a frustrating process and I just wanted it to be magically done for me. So… I didn’t do it. For weeks. I let my project stagnate, and the guilt build up as my Github streak floundered and faded.

Finally, yesterday, while lying in bed with a terrible hangover and gassy cat (my Sundays are generally this glamorous, yes), I decided just to get that shit done. I found some resources online, I trialled and I errored for an hour or two. Surprisingly, it works! But even if I hadn’t reached working code, I shouldn’t have let that stop me.

Too often I’m afraid to program because my work won’t be ‘perfect’. I’m scared that people will tell me that I’m doing everything wrong, that I’m a terrible programmer, and that I should go back to my books and verb conjugations.

The thing is, though, coding is not a competition. I know it feels like it, most of the time. It is so easy to compare yourself to others who are smarter, quicker, and more productive to you — especially with everyone blogging, sharing their projects on Github, speaking at conferences, and tweeting about all of the above. But comparison is the thief of joy, and when I start comparing myself to others I can easily spiral into a grumpy and counter-productive mood.

You know where this advice is leading: compare yourself to your past self, celebrate your own successes, and learn everything you can from others. You’ve heard it before, countless times. But that shit is hard. When you’re deep in a period of discomfort, you feel like everything you do is sub-par, and that your successes are puny, it is hard to be happy for other people and to focus on your own growth.

I don’t really have any helpful advice for you on how to work through that. But just try to remember these things:

If your code doesn’t work, it’s okay. You probably learned something along the way, right?

If your code is terrible, it’s okay. During the process, you probably ran into a whole bunch of problems, and you’ll know how to do things different next time, right?

If you’re afraid to start something because you don’t think you can do it, just start it, okay? If you need to, set a timer for an hour, or even just half an hour, and see how far you get. You’ll figure things out as you go. And if you don’t, see the first point above.

If you’re trying, you are learning. If you’re learning, you are growing. The only way to get better is to keep on learning and growing. Amazing skills aren’t just going to magically manifest while you sleep. You’re going to have to struggle onwards. I’m sorry, that sucks. I don’t make the rules, and all I can offer is solidarity.


For most of my life I’ve avoided doing things that don’t come naturally to me.

I quit maths at school after gaining University Entrance, because I was only getting Merits. Same for all the sciences. I wasn’t any good at playing the flute, so that ended soon after it began (my mother, thankfully, had the foresight to rent an instrument rather than to buy one). And of course, not being athletically gifted, or a good team player, I stopped playing netball as soon as my mother no longer insisted, and dropped P.E. from my curriculum as soon as the school would let me.

I dropped out of university papers that weren’t clicking with me so that I could focus on the ones I knew were easy As. I even spent most of my education working towards being a teacher, because I knew that I would be good at it. I really didn’t give it much more thought than that.

It’s curious to me, then, that as a teenager I picked up coding as a hobby, continued to tinker with it through the years, and eventually made it my career. Programming is not something that comes naturally to me, but unlike year 12 Chemistry class, I love doing it.

Programming isn’t easy for me. It doesn’t just ‘click’ like it does for some people. The concepts are hard for me to wrap my head around and sometimes it’s difficult for me to process and explain my own thought processes around code. Sometimes it’s like a deeper level of my mind understands, but I can’t quite access it right now. If you’re pair programming with me, you’ll often hear me say infuriating things like ‘I feel like it’s something to do with this function that’s being called on line 12’. More often than not, I have feelings about code, rather than logical, coherent arguments.

My ineptitude at programming is very clear in the way I approach it. If you ask me to write 3000 words on Matisse’s ‘La Danse’, and give me a deadline, I’ll wait until the day before the deadline until I finally sit down to write. When I do write, the words will mostly flow fluently from my mind to the screen, and I’ll often need to edit my thoughts down to fit the word limit. I won’t really pay much attention to what I’m doing — It’ll just sort of happen, and to be honest, I probably didn’t learn all that much.

If you ask me to build an app to a set of specifications, though, I’ll start almost immediately. I’ll be anxious about the deadline, and nervous that I won’t get the work done. I’ll code for hours, refactor, and pay very careful attention to what I’m doing. I’ll be constantly worried that what I’m doing is not good enough, even if it gets the job done. In the process, I’ll make endless mistakes. I’ll break everything, and fix it again. I’ll be mostly unhappy with the finished code, but I’ll be thrilled with all the learning I’ve done in the process.

Programming challenges me in ways that I’ve never really chosen to challenge myself before, and the rewards are so exciting that the struggle always seems worth it, even when I’m frustrated by the poor quality of what I’ve written.* Unlike P.E. class, where the reward (or so it seemed to my disgruntled teenage self) was a gloriously red face, sweat, and embarrassment in front of my peers, the reward for writing some functional code is pretty powerful: the immense satisfaction of knowing that you made a computer do the thing you wanted it to do. It’s as close to being a witch as I’ll probably ever get, and it’s one of the best feelings in the world.

There’s probably several lessons in here for my teenaged self, but I guess the main thing I’ve learned is that challenging myself with something I love to do, but find difficult, makes for a much more meaningful existence than effortlessly doing the things I’m good at without struggle.

*Having only recently started pursuing programming seriously, I’m still in ‘the gap‘ — I can recognise good code, but rarely can I write it. One day.

Becoming a better developer day-by-day

I’ve been experiencing a lot of anxiety lately about my life as a developer. The narrative will be familiar to anyone who’s ever pursued programming in a meaningful way; even if you write code every day, and learn something new every day, the nagging feelings of inadequacy are hard to escape.

It’s easy to be overwhelmed by the depth and breadth of material out there. There are hundreds of programming languages, libraries, frameworks, design patterns, and philosophies, all of which have their own associated jargon, preachers, and naysayers.

Similarly, there’s your peers, all of whom seem to know and understand more than you. You know that feeling you get when you browse Instagram and all your friends are in exotic places, meditating and/or eating gelato, and you just have to close the damn app before you work yourself into an envious knot? That’s how I feel about programmers most of the time.

Of course, as Teddy Roosevelt said, ‘Comparison is the thief of joy’.* I know that I should stop comparing myself with others and start comparing myself with myself. Of course, that only works if my rate of development is ‘satisfactory’. The problem is that I am the one who defines exactly what satisfactory progress looks like, and I tend to be pretty hard on myself.

This isn’t the first time I’ve written about Imposter Syndrome, and it likely won’t be the last. Like anyone who experiences Imposter Syndrome, I have a hard time internalising my own successes, which makes tracking my own progress difficult. If you have strategies for this, I am completely open to suggestion. Generally, though, I try to learn something new every day, and apply it to my daily programming.

In a day-to-day sense, though, what does that mean? It varies. It depends on my mood, energy levels, and state of intoxication (I’m kidding, somewhat). Some days progress means going to a MeetUp and chatting with other devs. Other days it’s as trivial as learning a new zsh command. Sometimes it’s blogging about my struggles and hoping that someone else out there understands. Occasionally, I’ll reflect upon where I was three months ago and try to consider my progress… this strategy generally doesn’t work, though (see previous paragraph re: internalising success).

A few things I’ve found helpful:

Setting a focus

At the moment my focusses are Rails APIs and React. This happened quite organically when I picked up a Rails API/React project at work, while also working on a Rails API for my own project Gifery. When your peers are all gabbing about Ember, Swift, functional reactive programming, and Node.js, it can be easy to feel like an idiot for knowing next-to-nothing about those things. In the midst of that panic, reminding yourself of your focus can be a useful centering technique.

Reading technical books

You probably know that I’m a champion reader. Recently I’ve put my sci-fi and pop-sci mainstays aside in favour of programming books. If that sounds desperately dull to you, let me reassure you that I love reading them. The trick is absorb and understand what you can, and let the other noise wash over you — it’ll eventually make sense later.

Watching programming videos

If you’re a visual learner, watching others code can be a useful way to absorb some knowledge in your downtime. Embarrassing confession: I’ve been glad lately when a TV show I watch has either ended or turned so crap that I don’t bother to watch it anymore, thus removing that obligation from my life and allowing me more time to watch programming videos. Yes, obligation. *hangs head in shame*

Learning to love the theory

I’ve always been a very practical programmer. As a self-taught php gal turned bootcamp graduate, my focus has always been on producing code that works. Which is good, but I can definitely feel my lack of theoretical knowledge creeping up on me. Embarrassingly, I’ve avoided doing much about this for several years because… well, no real excuse except fear of living up to my own expectations, I guess. Which, again, is silly. So I’m making an effort now to read more computer science theory. If you have recommendations, tweet them at me.

Teaching others

This one almost goes without saying. You know the old theory ‘See one, do one, teach one‘? It works. In my spare time, I do a bit of volunteering for Railsn00bs. The other week, I did some live code for group and I was a lot more nervous than usual as the topic of the session was rspec, something I’m…not great at. I fucked up several parts of the presentation and felt like a total idiot while doing it. But, since then, my rspec has gotten a lot better. In the past two weeks I’ve written over 50 rspec tests, and I keep referring back to the material I prepared for Railsn00bs. We’ll call that a win.

*was anyone else under the false assumption that Eleanor Roosevelt said that? The patriarchy wins again.