Work From Home Friday: Don’t be Afraid of Rebasing

Little late today, I was busy working/running around/watching paint dry, so I’ll keep this brief. I’ve mentioned before that git can be like a game save, it protects your butt if things go wrong and you need to get back to a certain safer place. But I also like to use git commits as a well crafted story, or at least that’s what I want to present to the outside world. Having a lot of why doesn't this work or it does the things or rainbows and ponies (a real pr of mine at a job at one point) doesn’t really mean anything to anyone but me. And unfortunately it probably doesn’t mean much to me if I go back and look at it even a day later. So what’s a girl to do? Tell her own story of course.

First let me say, “rewriting history” in git is a bit of a controversial subject for some people. But at multiple jobs and in my preference I don’t have a problem with it as long as you’re not rewriting master or other people’s history. So what does that leave us? The ability to craft a really well documented pull request. I can explain you through the choices of my work. I can easily split out frontend and backend changes if different people need to look at different parts. I can make changes easier to find if they all happen on one file in one commit.

I’ve gotten lazier about this at my current job, but my goal is to get back in the habit. It’s good hygiene and leaves my mental health intact.

For better words than mine check out Nathan LeClaire’s Don’t Be Afraid of Git and a good visual tutorial can be found from the amazing Thoughtbot blog.

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).

How to Git Ignore without .gitignore

So I had this problem at work. I’m running a virtualenv instance on our main git repo for all my python packages. The global .gitignore obviously doesn’t know about it the way it knows to filter out node modules and other fun bits of localization and I sure as heck don’t want to add my own one line fix to the global .gitignore file.

So what’s a girl to do? Does she just ignore that one annoying untracked file line every time she does a git status from the terminal? Nope, she uses git exclude.


So for me this meant I had to create a info folder in my .git folder in the repo. Then I created a file called exclude (no file extension). The syntax in that file is exactly like the .gitignore file, it’s just very very local (to your computer and only for that repo).