Cat Herding 101: The Things That Really Go Wrong For Beginning Programmers

We had a super awesome intern working with us over the summer (I often referred to her as “my” intern, which wasn’t 100% true, but as the one on the team who had done a lot of mentoring before, I felt very mamma bear about the situation). She did some cool things and had done some cool work on her own before working with us but when she needed help and was frustrated out of her mind with a problem (like many of us still often are) it usually ended up being easy enough for a fresh set of eyes to spot the problem.

Cat teamwork

These are the times when having a mentor or even just a partner in crime who’s willing to give a quick code review make all the difference. Unfortunately not all of us get the luxury of a second set of eyes, so we fumble along adding and deleting things until we just throw it all away and start over (been there) or change so many things that one of them magically works but you don’t actually learn anything because what the hell was the problem in the first place (also been there). So for my fresh coder friends, I thought I’d throw together a quick cheat sheet of the things I see most often in my and my mentees code. I bet with any time spent coding you can probably guess a few.



This one hits where it hurts, because it is a stupid mistake. A variable named “container” is not the same variable as “contanier” (and is also an awful, very vague variable name, but that’s a different lesson). This will drive you nuts, I promise – it’s currently driving my spellchecker nuts as I type. Everyone does this. Everyone. Promise. Even that awful person you just had a horrible first interview with and now will never have the job of your dreams, yep, he’s misspelled “first” I bet.
The Quick Fix: If you’re using an IDE (think Sublime Text, or Atom or whatever the kids are using these days). It’s pretty easy to spot. When you go to auto complete a variable starting with “cont” you will see two options and one of them will be not what you want. Go head and do a search for that errant misspelling and see where else it’s been used in the codebase and change it (unless some jerk really did have a variable named “contanier” in some obscure file, then change it and mock him for the next year).


Conditional flaws

This can technically mean a lot of things, but I’m talking about the “if not this or that do this” variety. Unsurprisingly, when you spell it out “If not A and not B” sounds much different from “If not A or not B”, but when quickly writing code it’s easy to forget.
The Quick Fix: Say it out loud! Write out your logic flow using words! Do something that’s easier for your brain to see flaws in than the foreign language that is your code.


Syntax errors

Blech, straightforward and an oldie but a goodie. Syntax errors are common. Everything from a typo to a misunderstanding of how a function works can lead to them. Thankfully most languages have been nice enough to also make them the easiest to solve.
The Quick Fix: Learn how to read those stupid error messages. Each language is usually a little different, but most of them follow a pattern. They generally have a complicated error message and a line number. It’s like they’re giving you the answer for free! Check out that line number, does something look funny? Fix and try again. Does it all look, a-ok? Start googling that esoteric error message. I promise you’re not the first person to accidentally divide by 0.


Incorrectly nested divs

This one is a bit frontend specific but you are a lucky person if you’ve never accidentally had this madness in your codebase, especially frustrating with things like Angular scope. Missing that end div tag or adding one too many in the wrong place can be a nightmare.
The Quick Fix: Always always use good HTML hygiene, indent for every new block.

<div class="outside">
  <div class="inside">

Doing too much

This is a bit of a catch-all and a desperate plea to learn some git basics. Sometimes I’ll go wandering down a rabbit hole and not come up for air until I’ve changed at least four files. This is Not. Good. Do as I say and not as I do kids. This will lead to massive frustration when one part is making the entire thing fail or not compile. But shoot, you just made changes to four major files. So now it will take you at least 4x longer than it took to write to go back and debug. Make incremental changes, save progress with git. It’s like a video game – no one wants to do the boss battle again!

Cat Boss Final Form

We can all make these same mistakes. In fact, I’m positive we all do, but for those of us who’ve been doing this a few years we can just shrug and groan and move on with our day. And this is probably that single point where I see newer engineers go off the rails. They feel dumb and like they’ll never be as smart as their coworkers or mentors. I know this because I remember it and I’ve seen it in people I mentor. My favorite way of taking the edge off, especially when they come up immediately on the defensive with an “I know this is probably stupid, but..” is to help them but then share a time when I’d done the exact same thing. We all had to learn this shit, some of us have just been learning it for longer (and have the dyed grey hairs to show for it).

No News is Good News? or A Short Discourse on Pair Programming

Things have been quiet here at casa de Lindsey which is good for me, but probably not as exciting for the people who (maybe, sometimes?) read this thing. Since April I’ve been relearning why I love being a software engineer in a supportive and awesome culture at Scripted. It’s a small tight-knit team and I was a little worried about coming in as a newbie to a solid team but they’re amazingly lovely people and I love learning with them and from them. Front-end only land has been so busy I still haven’t had time to really even touch my first love of backend APIs (which would require me to learn Rails to do it justice at Scripted) but I haven’t really mourned that loss. Instead as one half of a front-end team of two, I’m running around like crazy helping our backend/full-stack team be better front-end engineers, sitting down with our designer to craft better UX, and handholding our marketing team through WordPress template changes when the stars align correctly.

This brings me to my continued sermon on mentoring/pair programming and how much I luuuuuurve it. I keep reiterating it, but I’ll continue to reiterate. I love mentoring other engineers, I love pairing with people. It can be super awkward at first because even if you’re the one who is supposed to be mentoring you won’t have all the answers. But that’s not the point! The point is for you to foster learning, for you as well as the other person. Software engineering is not a perfect set of knowledge that you can learn once and then just churn out the same thing over and over, but it’s also not always about going down the rabbit hole of discovery (especially if you have to earn a living writing code for a living). Mentoring and pairing almost feel like cheating to me, because I don’t have to solve all the problems myself. I might not even have to come up with the original idea for something, just help refine it and still get to take partial (but deserved) credit in the end.

Also, there are so[1]How to Pair Program many[2]Code Quality is the Least Important Reason to Pair Program better[3]Pair Programming vs Code Reviews resources than my stream of consciousness musing on pair programming (and a MAJOR SHOUTOUT to a study on the benefits of pair programming for women – hint: it benefits everyone). Please check them out, give it a shot if you can. It is really, really hard at first and it’s definitely not for everyone but for me and most of my pairs it just takes so much stress of the engineering cycle.

Expect more posts soon, I’m thinking of trying my hand at “teaching” since I can never have enough “lemme just show you this one cool thing” moments. If it all works out it will probably be a series of posts a la “I don’t want to make another to-do app in JavaScript to level up my skills”.

On to Smaller and Better Things!

My time with Udacity has come to an end. I made some amazing lifelong friends out of it and learned enough to fill a book but I decided it was time for me to trundle along to a new opportunity. So I’m excited to announce that I’m joining Scripted as a JavaScript Engineer! It’s going to be a bit of a brain warp focusing most of my efforts on the front end but I’m ridiculously excited for the opportunity and working with the awesome new coworkers that I’ve met so far. The team is much smaller and very careful to cultivate their culture and I just felt right at home the minute I came on site for my interview with them (as an aside: sort out culture fits first or you will be miserable no matter how potentially amazeballs you think a project is). I really look forward to diving back into my JavaScript roots and being able to geek out about all the upcoming changes.

My other hope in this transition is to get back into mentoring more. Working in Mountain View and attempting to mentor in SF was super draining on me, but now that I’ll be working in SF, I want to pour more of my free time back into mentoring and helping others join this awesome ride that is the tech industry. So I’ll be spending some time thinking about how to approach that aspect.

Reminder: Choose For Culture!

Lately I’ve been interacting more and more with people trying to break into the tech industry. It’s something I’m keenly aware of as a recent wall breaker myself and my general desire to mentor and champion other people to do what they want.

I recently had the privilege with my co-host and awesome, awesome person Jennie to lead a talk for Udacity Nanodegree students on how to get into the industry and how to make connections/get a job/etc. I wish I could link you all to it, but it’s behind a paywall currently. Lies! Youtube video:

The talk itself was pretty standard:

  1. Network, network, network.
  2. Recruiters can be your friend/spy.
  3. People are generally nice, especially when you don’t spam them and actually ask them things that are relevant to them.

But between that and a lot of the recent articles on tech interviewing/culture (which I’m not going to give my opinion on in this post as it’s nuanced and hard, but spoiler: pair programming interviews are the bomb) I’m a little dissatisfied that I didn’t mention my number one rule for finding a job:


I’m not going to pass judgement on different cultures as people are, shockingly, different. Just know that if you have the luxury, which thankfully is often the case in tech, please, please don’t choose a job just for prestige or some weird convoluted inner turmoil. Make sure your coworkers are rad. You will need them, a lot. Many of my best friends now are former/current coworkers. We have nerdy parties, we play video games, we send each other stupid cat gifs (okay, that’s just me sending them out to everyone else, but they appreciate them damn it!), but more importantly they have my back. They can help me troubleshoot stupid mistakes or understand my inner rage at a feature or just geek out with me over the hot new programming hotness.

I think a person I follow on Twitter put it best when he said:

Interviewing with Impostor Syndrome

As my abilities grow at Udacity, so to do my responsibilities. I give code reviews, I help mentor some of our junior engineers, and I lead my small internal team as a sometimes engineer/sometimes PM. But probably the scariest monster I have had to face was the idea of interviewing others. Even with all of the awesome things I know in my brain I’m doing here, my jerkbrain asks me how am I supposed to interview other people when I’m not even sure I could get through this on the interviewee side of the table?

Like many people, I’m not so good at taking my own advice, but maybe, just maybe my advice can help someone else, on either side of the table.

Dont listen to your jerkbrain

  1. Listen to the manatee. You are smart and pretty. Say it, say it again, say it while power posing. The stupid phrase “fake it until you make it”, unfortunately it’s right.
    Afraid of myself
  2. You’re just as afraid of it as it is of you. (caveat: unless “it” is an asshole, but you don’t want to work for/with assholes, amiright?) On either side of the table you care about what the other person thinks of you and not sounding dumb (the only upside to being on the interviewer side is that you’re not usually going it alone, there are other people interviewing as well).
    Let me hug you
  3. They just want to be loved. Generally the number one thing I’m looking for in either case is whether or not I think I could work with this person. Honestly, even if you’re giving me a tech answer and it’s not right but I can see where you’re going and you’re been an awesome person to talk to and work with the problem on, I’m going to leave that room feeling pretty favorable about you. On the interviewer side, I really want you to like me and be comfortable and do well, it feels like a failing on my side if I haven’t helped you with that (recheck my caveat about working with assholes if you’re not feeling it).
    It's not you, it's me.
  4. It’s not you, it’s me. We all have off days and, maybe unfortunately, we’re all human. If you completely fumble or you don’t understand why we could have passed on you. It might be us. We know our team, we know our product and maybe we know that you wouldn’t be happy here or don’t think we’d all have an awesome time working together. For interviewees, off days happen, interviews might tank. Reflect, move on, it sucks but it’s not the end of the world. Even if that was your dream company of rainbows and ponies, they probably weren’t. There are probably lots of other companies doing equally cool things that would be thrilled to have you.

I Don’t Have To Choose

My favorite story when I was trying to describe myself while looking for a job involved the fact that I had a very non-traditional path to Software Engineering. I wear it as a badge of honor that I am able to do all of this without a degree in Computer Science. I went to a boot camp, worked my butt off, and got my dream job at Udacity.

As I explain it, I came to a breaking point about a year and a half ago where I knew I wanted to be a software engineer but I had no background and not a lot of skill and as a woman, I wasn’t really feeling welcomed.

So I decided to do something drastic. I decided I needed to quit. But then what? I’d been taking CS classes at my local community college in hopes of maybe getting a Masters and I’d learned about these cool bootcamps in San Francisco. In fact I told my best friend about them and she’d just been accepted to one (of course, she already lived in the Bay Area).

I made my decision when I realized I didn’t have the patience or money to sit around for three years before maybe feeling like I could get a job. I wanted to go out and solve “real” problems and not get a meaningless job to get me (maybe) through a Masters in three years.

I still really want that Masters. Honestly, it’s something that I need for selfish reasons. To prove that I can do it. But also to feed that craving for more academic knowledge. So I applied to the Georgia Tech Online Masters Program. And last night I got my acceptance letter.

A year ago I had recently quit my stable job and left my nice apartment and the state I’d spent my entire life in to live on my friends couch and work myself to exhaustion 6 days a week at Hack Reactor. Now I have that nice apartment and an awesome job and I’m learning things all the time and at the same time I get to work on my Masters without fear of a dead-end job or a tuition bill I couldn’t pay.

So it’s time for a new Category! And a new iteration of numbered weekly posts! And lots more exciting learnings. Heck, maybe I’ll end up making the robot that starts the robot apocalypse. You’ll only find out by following my blog (or possibly the news, if I do end up making that robot).

6 Months Later – A Much Needed Recap

I’ve been at Udacity for over 6 months now. I’m also about a month a way from that fateful day when I started Hack Reactor. Life has been pretty kind actually. I feel like I’m growing as a person. Personally I’m still spending all my free time with friends and trying to do some knitting and and and…

Professionally, I’m enjoying my work more and more and more. I’m back to working on my first love, which is APIs and integrations and making the internal tools that our company needs. I love that part. Throughout my life I have said I always wanted to be the sidekick to the superhero. Some days I wish I could do that a little more literally, but building the tools that other people at Udacity can use to help educate is a pretty good consolation prize.

It’s also time for round two of Hackbright mentorship. I find out who I’m mentoring tomorrow and I’m really excited. I think I learned lessons from the first time around about how to help another person to learn (and I’ve used these lessons with some of my more nontechnical friends). I’m played the token woman in engineering a few times this summer, but I’m happy to do it if it furthers my world domination plans (because that’s obviously what would happen if we had more women engineers).

Last but certainly not least, I’ve gotten antsy to take some structured learning again. And what better way to continue learning that go back and get my masters right? It’s something I’ve always wanted to do, especially to have that extra knowledge actually focused on Computer Science. So I’ve applied and have my fingers and toes crossed and am holding my breath and all that fun stuff. Wish me luck.

I Need to Stop Apologizing (subtitle: Objective-C and ME)

…And start just actually updating this thing. I could tell you about my life changes – finally got my California drivers license! I lost 5 lbs! Or my work changes – Imma try to be an iOS Engineer! Udacity did a short blog article on me to hype up one of our classes! I’m mentoring cool women at Hackbright! Or just daily life – I stopped biting my finger nails!

I think for this update I’ll stick to the code related though. Lemme take a moment to sound like an idiot – I have tried my damnest (not consciously) to forget my Java/C college days and I’m getting ALL the flashbacks while I try to teach myself Obj-C. It took a very long time for me to even be OK enough to actually read Objective-C. But now that the brackets everywhere don’t scare me. I’m starting to enjoy it.

I’ve written all of two or three lines for our actual Udacity app but I’m learning on my own and with the support of our mobile team! In a bit of return I’m working on integrations with them to hook them up to our web backend better. So see kids! You don’t have to know Objective-C to be considered part of the mobile team! I’ve transitioned over and still get to stay in my comfort zone of Python a lot.

I think the most important thing I’ve learned so far is that it’s not the language that is difficult to learn, it’s that iOS development is a completely different mind-set, especially coming from a backend heavy few months. I like crafting functional APIs that do what they’re told and I’ve learned to find map reduces fun. But now I have to think about user experience? And does the button need to be orange? Should the robot picture be above or below the text? Should the background be white or black? Should we AB test this on boarding screen? It’s nuts, but in a good way.

I know backend engineering has had my heart but I never wanted to get stuck there. I wanted to be able to have options. To learn ALL THE THINGS. And my awesome coworkers at Udacity have been nothing if not supportive of that goal. One week I’m learning how to write map reduces, another I’m researching video transcodings for mobile video streaming (and playing with PBS open source software!), and just this week I got to play a mini round of tech support as our Georgia Tech Masters students started their term on Monday. It’s a hell of a ride so far and I’m just getting started. Hopefully now that I’m settling a bit on what I want to learn next (iOS) I’ll get back to a more consistent blogging schedule.

Clojure Makes Me Feel Stupid

…but I’m kinda in love with it. Thanks to a friend/coworker I’m cautiously dipping my toe into the world of “functional programming”. I’m still not 100% certain I get the full gist of functional programming but, to my newb mind, I’d explain it as programming without consequences. Functions only depend on their inputs and external forces/state cannot muck with your function.

Apparently this makes it easier to predict what’s going on, but I still have issues reading what I just wrote. Parenthesis all the way down dudes. Also prefix notation is technically useful, but warping my poor little brain.

So 1 + 1 in Clojure is actually written as (+ 1 1). Makes sense, right? Sorta, except for the years and years of basic math classes that NEVER LOOKED LIKE THIS. Oh my brain. But it’s kinda cool that instead of 1 + 2 + 3 + 4 I only need to write (+ 1 2 3 4).

But seriously. This is a function in Clojure:

(defn adder 
  [x y]
  (+ x y))

(adder 3 4) ;; 7

Wat? So the first line defines the function name. The second line is the parameters that you give to the function and then the last line adds those two parameters together. I then call the function on line 5 with the arguments 3 and 4 and then the semicolons denote comments and I use that do show what the output of the function is… 7.

As a super ridiculous aside. Parameters vs arguments? Parameters are the things that you define with the function. So x and y on line 2 are parameters. Arguments are what you pass to the function when you want to actually use it. So 3 and 4 on line 5 are arguments. Now go forth and be awesome!

So how do you be Clojure learners too? Currently I’m running through the clojurebridge curriculum on my own. Clojure in 15 minutes looks like a decent-y rundown of most of my syntax options. If you don’t want to put anything on your system yet, or just want to mess around with the syntax, there’s always Try Clojure which lets you program from your browser. And I’ve bookmarked Clojure for the Brave and True mostly for the title, but I haven’t really read any of it yet.

Bored Again – Time to Create

On Repeat

Tomorrow is my three-month reunion for Hack Reactor. I’ve done some cool things since I graduated, but I’m still not doing everything I wanted to. I want to be the change I want to see in the world, or however that goes. I just became a mentor for Hackbright Academy so I feel a little less adrift without a social purpose, but I’m still itching to create things.

I’ve started knitting again, but it’s not solving the itch. I have half-finished things on the needles again, but I’m still bored. I think there is no hope for me. I just need to be coding.

About a year ago. I was sitting in a crappy gelato shop in downtown Burlingame with two of my best friends who already lived in California. I was still living and working in Oregon, but I knew I needed to be moving on soon. I was getting restless. That day we made a pact, all of us before this crazy thing called a dream turned us into a software engineer, a software engineer, and a novel writer. We were The Clever Girls and we were going to create something amazing together eventually. Part of that dream is how I ended up down here and now I’m realizing I need to start doing my share.

So I’m going to dive back into programming completely solo, completely public, with my work, as shitty as a lot of it probably is, committed for all to see on Github. I hope soon the three of us can get back on the same page and actually make something amazing. For now I’ll just leave you with the copy I wrote for a fake starter page a year ago when The Clever Girls were still fresh in my mind:

“Computing is too important to be left to men.”
Karen Spärck Jones

Women are underrepresented in computing not because they aren’t good with computers but because they are never given the opportunity to fall in love with them. The Code Girls‘ goal is to create fun, educational games geared toward younger girls that will teach them the basics of how programs work. Using an easily readable language like Python, girls will code their way through the platform challenges and create fully functioning programs as they progress.

Code Girls present Octavia and the Clockwork Code is the first game in the series. It tells the tale of 12-year-old Octavia, a precocious tween who sets out to win a mechanical competition. Along the way she codes her way through puzzles and helps out friends and competition alike.

The Code Girls is a fledgling startup created by three women who are passionate about women in computing.

Lindsey – The Creator

Founder, primary coder and herder of cats. Lindsey always wanted a game like this when she was growing up. Now that she’s technically grown up, she decided to take the idea into her own hands.

Ava – The Teacher

Our resident little girl expert. Ava has a Masters in Education and a passion for teaching children using methods that create a deeper understanding.

Alyssa – The Storyteller

World builder and character flaw creator. Alyssa creates and drives the stories we tell. She lives and breathes the Code Girl worlds.