DEV Community: Kara Luton

A Guide to Perfecting Pull Requests

Kara Luton — Thu, 20 Jul 2023 16:51:26 +0000

I don't know about you but I love the feeling of getting to hit the merge button on my code and sending it off to production. That's our ultimate goal as software engineers - to get our code out there into the world. However, unless you're living life on the edge, there's a big hurdle to overcome before getting to push that merge button - getting approvals on your pull request. Let's talk about how to make the best of your PRs that way your reviewers know exactly what they're looking at and you get to hit that merge button faster.

Pull requests are telling the story of your changes. They are a conversation between you and your reviewers and as the author of the story you want to make sure the process of reviewing your PR is as easy as possible. It is vital that our PRs give everything to our reviewers that they may need. They should concisely describe our motives and thoughts behind our changes all the while preemptively answering any questions our reviewers may have.

Outlining Your PR

Just like a good story, our pull request should begin with an outline of its chapters. In our case, our chapters are our commits. We've all seen commits that provide absolutely no insight into what has gone on but each commit message should show a progression in your pull request story.

The subject line of your commit should give an overview of the changes made while the body should provide additional context such as why the changes were made, any possible future implications, and a reference to the ticket or issue number.

Using conventional commits can help provide even more at-a-glance insight.

Organizing Your PR

Having explicit commit messages is important but in order for your story to be understood those commits need to be organized in a way that makes sense. You want to make sure your reviewers can easily follow the story you're telling about your changes.

But what if you have to implement a fix or refactor something later on and you've already made commits? That's totally ok! As developers, we have the power to change history with rebasing. If you aren't familiar with rebasing it allows us to rework our commits. You can change the order, rewrite your commit messages, or even squash two or more commits together. Here's a quick TLDR on the difference between rebasing and merging.

Paying Attention to the Size of Your PR

If our commits are the chapters to our pull request then our actual code implementations and changes are the story itself. It's important that we pay attention to the size of our story. There's a computer programming principle called the Single-Responsibility Principle. It states...

Every module, class or function in computer programming should have responsibility over a single part of that program's functionality, and it should encapsulate that part. All of that module, class or function's services should be narrowly aligned with that responsibility.

To summarize, a single module, class or function should only focus on one thing. That same concept applies to pull requests. You may think that a PR that touches a lot of files would receive more comments than a smaller PR but a study revealed that developers should review no more than 200-400 lines of code at a time. Beyond 400 lines of code, the ability to find defects diminishes.

So by breaking a large pull request into several smaller ones you're actually increasing the chance that you'll receive feedback and the potential for your reviewers to catch a bug they may have missed if the PR was larger.

Your PR's Introduction

We’ve covered the chapters to our PR story and the story itself but what’s a good story without an introduction? That’s where our title and description come in.

A pull request title is the first bit of information you're providing to your reviewers for what they are about to look at. It needs to give a concise overview of what is happening in the PR. The description is where you can provide more detail for your reviewers or anyone looking at your PR in the future.

Remember to never assume the reader's prior knowledge of the area of the codebase you're working in. It's your job as the author to provide the context to them. You can do this through including information on the "what", the "why", and the "how" of your changes.

The what should provide explicit details on the changes in your pull request. Remember how our commits are the outline of our story? This is where they come into play. Use your commit messages as a baseline for explaining your changes to your reviewers. Expand on what you wrote previously with a bit more detail. This section of your description should also include any lingering TODOs linked to their follow-up ticket.

The why should explain the reasoning behind your changes including any architectural decisions you made and any possible implications from those decisions. This can include user stories for why this specific feature was added, thoughts behind refactoring you did, or even explaining your thought process.

Lastly is the how. How are your reviewers supposed to test your code? Go through the steps to reproduce your changes in a demo environment. You want to be as explicit as possible - provide direct links for the route that needs to be tested and any feature flags or permissions they may need. You also want to make sure the exact scenarios you want tested are laid out. For example, certain steps your reviewers may need to take to show an error state.

Become Your Own Reviewer

Before adding any reviewers to a pull request I become my own reviewer. I look through each of my commits to make sure they're linear and self-explanatory and take a look at the code itself too. While doing this I often annotate my own PR commenting on specific lines of code that may leave your reviewers with questions. You can use this to explain why you chose to do something a particular way like if the direction to go was a little outside of the norm or you can highlight a line of code to get more opinions on it.

Continuing the Conversation

Now that you’ve put together the story of your pull request, added your reviewers, and officially opened your PR you would think that things end there, however, the conversation around your changes are only beginning. The entire point of a pull request is to get eyes on your code so others can catch bugs or provide feedback. An essential part of the PR process is responding to that feedback.

Pull requests are a story and you should be having conversations around that story with your reviewers. Whether you only get one or two comments or ten, you’ll want to make sure to reply to every single one. Pull requests should not be merged until every comment has been addressed whether that’s implementing a suggestion or not. If you do apply a suggestion from a reviewer be sure to acknowledge that.

Not all comments will be within the scope of your pull request, however. Ultimately, it’s your decision what is and is not within scope but if something is outside of the scope then you need to create a follow up ticket. The key to a great pull request is being completely transparent. Explain to your reviewer why their suggestion is out of scope and include the link to the follow up ticket where it will be addressed.

After all comments are addressed it’s finally time - you get to push the merge button! You’ve accomplished your goal of merging your code to production and that’s another ticket marked off your to do list. Now it’s just time to start the entire process again with a new one.

What are your tips for making a perfecting pull request? Comment below!

Be sure to follow me on Twitter or Threads for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

The ABCs of HTML Elements

Kara Luton — Wed, 27 Jan 2021 20:03:00 +0000

It can be a little overwhelming when first learning all of the HTML elements. Here's a quick overview of some of the more common elements for each letter of the alphabet!

A: Anchor <a>

The anchor tag defines a hyperlink which is used to link from one page to another.

<a href="https://dev.to/karaluton">Kara Luton's dev profile!</a>

B: Button <button>

Every website or web app has one - a button! The <button> tag defines a clickable button. Inside the button you can put text and you should always specify a type attribute to tell browsers what type of button it is.

<button type="button">A cool button</button>

C: Code <code>

Ever wanted to display a snippet of code on your website? The <code> tag allows you to do just that. The content inside is displayed in the browser's default monospace font.

You can see the use of <code> right here in this article in the examples above.

D: Div <div>

Ahh the <div> - one of the basic building blocks of HTML. The <div> tag defines a section in an HTML document.

<div>
  <h1>DEV is an awesome community!</h1>
</div>

E: Em <em>

The <em> tag is used to emphasize text. The text inside of an <em> tag is often displayed in italic.

<em>This text is EMPHASIZED!</em>

F: Form <form>

Used to create an HTML form for user input and it can contain several form elements i.e. <input>, <textarea>, <button> and more!

<form>
  <label for="name">Name:</label>
  <input type="text" id="name" name="name">
  <input type="submit" value="Submit!">
</form>

G: ¯_(ツ)_/¯

H: Headings <h1>-<h6>

The <h1> through <h6> tags define HTML headings. <h1> is the most important while <h6> is the least important heading.

<h1>This is my main header</h1>
<h2>I'm important but not as important as the h1</h2>

I: Image <img>

Let's add some visuals to your page! The <img> tag is used to embed an image in an HTML page. There are two required attributes: <src> which specifies the path to the image and <alt> which is the alternate text for the image.

J: ¯_(ツ)_/¯

K: Keyboard Input <kbd>

This is similar to the <code> tag, however, <kbd> is used to define keyboard input.

<p>To copy text you will need to press the <kbd>Ctrl</kbd> + <kbd>C</kbd> buttons.</p>

L: List Item <li>

The <li> tag defines a list item and is used inside ordered lists <ol> and unordered lists <ul>.

<ul>
  <li>Franklin</li>
  <li>Maggie</li>
  <li>Kara</li>
</ul>

M: Main <main>

The main content of a document. This element should be unique to the document and not contain repeated content like sidebars, navigation links, etc.

N: Navigation <nav>

A set of navigation links.

O: Ordered List <ol>

An ordered list that can be numerical or alphabetical. A <li> tag defines each individual item.

<ol>
  <li>One</li>
  <li>Two</li>
  <li>Three</li>
</ol>

P: Paragraph <p>

The <p> tag defines a paragraph. Browsers will automatically add a single blank line before and after each paragraph element.

<p>This is a paragraph about how cool the DEV community is. Isn't it a great place to learn more about being a web developer and software engineer?!</p>

Q: Quotation <q>

When using the <q> tag the browser will normally insert quotation marks around the text.

<q>It's not a bug. It's an undocumented feature!" -Unknown</q>

R: ¯_(ツ)_/¯

S: Span <span>

A <span> is an inline container used to mark up part of a text or document. It's similar to the <div> element but is inline instead of block-level.

T: Table <table>

Defines an HTML table which consists of one <table> element and one or more <tr> - table row, <th> - table head and <td> - table cell elements.

<table>
  <tr>
    <th>Dog name</th>
    <th>Dog age</th>
    <th>Dog breed</th>
  <tr>
  <tr>
   <td>Maggie</td>
   <td>5 years</td>
   <td>Golden retriever and border collie</td>
  <tr>
  <tr>
   <td>Franklin</td>
   <td>5 months</td>
   <td>Mini goldendoodle</td>
  <tr>
</table>

U: Unordered List <ul>

Similar to the ordered list <ol> except that this is an unordered, bulleted list.

<ul>
 <li>Coca-cola</li>
 <li>Pepsi</li>
 <li>Dr. Pepper</li>
</ul>

V: Video <video>
Used to embed a video in a document.

W, X, Y and Z: ¯_(ツ)_/¯

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

My Work From Home Setup

Kara Luton — Fri, 08 Jan 2021 17:38:29 +0000

Now that the majority of us are working from home 100% of the time, having a workstation that inspires you is more important than ever.

I recently moved into a new house and have been slowly piecing together my new office. Here's what I have so far.

Room Overview

Here is my office so far. My office is open to our front hallway and the entrance of my house so I wanted something both aesthetically pleasing and functional for my everyday work.

This is definitely still a work in progress - I'll post update pictures once I get everything finished. I'm thinking of putting a credenza on the left side of my office so I can have some functional storage.

I also really like having a TV on in the background while I work so I'm thinking of splurging on a Frame TV for above the credenza. This way I can have background noise while I work but it also doesn't look like a TV. I also would like to add some hanging planters to add some more greenery to my space.

Desk Setup

As far as my actual desk goes, I have my work-issued MacBook Pro on a Rain Design stand. I mainly use my laptop as a screen for Slack and my email but I like that the stand keeps it at eye level.

My monitor was issued by my work and is a Dell UltraSharp 25". I like that the monitor can be adjusted up or down but I'd eventually like to get a monitor arm to free up some space on my desk.

Even before Covid my team was remote so video calls are a big part of my day-to-day work. My webcam is the LogiTech HD Pro C920 and my favorite part about it is that is has a privacy cover. I also have a Lume Cube on an adjustable tripod to provide some additional light on video calls.

My husband and I built my mechanical keyboard and I am obsessed! He's really big into mechanical keyboard and truthfully is the only reason I have one but I don't think I could go without it now. My keyboard case is a KBD67 with Zeal 62g Zilent switches and Tai Hao Baby Miami keycaps (which are unfortunately not sold anymore).

My mousepad is the Don't Be Afraid To Commit mousepad from SoSplush. I've actually referenced it a ton since getting it! My mouse is the Apple Magic Mouse.

I also have my personal laptop on my desk which is a 2014 MacBook Pro. I don't use this often and have been debating about selling it and getting an iPad instead.

You probably noticed the cup with a million pens on my desk. I recently picked up bullet journaling and that's just a part of my collection. I keep all of my bullet journaling supplies on the shelves on my desk.

The plant on my desk is a Sansevieria 'Starfish'. It's pretty hardy and has survived me forgetting to water it quite often.

Artwork

I recently hung up these three photos from Society 6. They really add some warmth to my space and a touch of personality. I specifically chose the line art of the ballerina since I used to dance.

Do you have a dedicated office space or an on-the-go setup in your house? I would LOVE to see your workstations - comment below!

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

HTTP Methods Explained

Kara Luton — Tue, 11 Aug 2020 14:35:50 +0000

As a frontend developer you'll most likely be interacting with a lot of APIs. It's especially important to understand the different methods you can use when interacting with an API and the responses you receive back.

We'll be going over HTTP methods for REST APIs. So first let's talk about what in the world a REST API is.

REST stands for "representational state transfer" and is a set of rules developers need to follow when they create their API. REST APIs have five types of methods aka the type of request you send to the server.

Those methods are the following:

GET
POST
PUT
PATCH
DELETE

Each method performs one of four possible actions:

Create
Read
Update
Delete

You may have heard these actions referred to as CRUD before.

Let's dive into each method and what responses you get for both a successful and invalid request.

GET

What it does: Requests retrieve resource information.
Action: Read
Successful response: 200 OK
Error response: 404 not found

POST

What it does: The server creates a new entry in a database
Action: Create
Successful response: 201 Created
Error response: 404 not found or 409 conflict - if the resource already exists

PUT

What it does: Updates an existing resource
Action: Update
Successful response: 200 OK
Error response: 204 no content, 404 not found or 405 method not allowed

PATCH

What it does: Very similar to PUT but makes a partial update on a resource
Action: Update
Successful response: 200 OK
Error response: 204 no content, 404 not found or 405 method not allowed

DELETE

What it does: Deletes resources
Action: Delete
Successful response: 200 OK
Error response: 404 not found or 405 method not allowed

A quick summary of the responses you may see is that anything in the 200 range means the request was successful, anything in the 400 range means an error has originated from the client and the 500 range means an error has originated from the server.

Have you stumbled upon any cool APIs that you've worked with before? I'd love to hear about them in the comments!

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

Reflecting On One Year of Remote Work

Kara Luton — Thu, 27 Feb 2020 15:37:09 +0000

When I was first presented with the opportunity to work remotely I was ecstatic. What could be better than no commute and working from the comfort of my own home?! And while both of those things are great perks, learning to love the remote life took some time.

To be completely honest, there was a point where I didn't enjoy working remotely. I'm naturally an introvert but I still enjoy socializing with others. I missed having those in-person interactions that I would get in an office. But now, one year later, I'm extremely happy working remotely and I'm reflecting on what has made it easier for myself. Hopefully, these tips can help someone else who is joining the work from home movement.

Have a dedicated office space

You may be tempted to work from your couch or even your bed when you first start to work from home but it isn't the best idea. You need to separate your workspace from your home space. I have my desk in our very underutilized guest room. I hardly ever go in this space on the weekends so I have that clear separation of work time and relaxing time.

Stick to a schedule

As a type A personality who loves routines, sticking to a schedule has made me love the remote life more. I like to have some downtime in the mornings so I wake up a few hours before I need to start working, jump in the shower, eat breakfast and get ready for the day. I act the same way I would as when I would go into the office each day but I wear much comfier clothes now.

I also am sure to take a lunch break away from my desk. Being at home, it's super tempting to eat at your desk and work through lunch but it's important to take that time for yourself.

Get out of your office once in a while

Something that has really impacted my opinion on working from home is that I now try to get out of my home office at least once a week. I enjoy checking out coffee shops and working from there for the day. I usually invite any friends that also work remotely or I send a message on my local Slack group to see if anyone wants to join me. While I do miss my giant monitor at home, it's nice to change up the scenery every once in a while and get out into the "real world".

Participate in team offsite trips

My team is highly distributed so while the majority of my team works remotely as I do, others work in various offices. My team gets together a few times a year in one location. These offsite trips are absolutely a necessity in my opinion. The difference they make is huge and I really suggest to have an offsite if you work on a remote team.

I felt so much better after my first offsite, which happened to be one week after I joined the team. It made the people I worked with actually feel like real humans and not just a photo.

I'd love to hear any advice you have if you also work from home. Leave a comment below!

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

Aliases: Making the command line your friend

Kara Luton — Mon, 11 Nov 2019 17:54:00 +0000

How many times a day do you write git add, git commit -m and git push in your terminal? Tons! Wouldn't it be nice if there was a faster way to write out the commands you use every day? Well, there is and it's aliases.

I'll be going over using aliases with Zsh which is now the default shell for Macs using Catalina. Zsh is an extended version of Bash but it has a few additional features and has support for plugins and themes.

Making an Alias

You'll need to open your Zsh configuration file (.zshrc) and add the following syntax at the bottom of the file to make your alias:

alias [custom-alias]=["command"]

I use Ember at work so I'm constantly writing out the full command to run my tests. Instead of having to write ember test --server --launch=false every time I've set up the following alias:

alias ets="ember test --server --launch=false"

Now, whenever I want to run my tests I use the command ets and have saved myself a little bit of time typing!

Oh My Zsh

Another advantage of using Zsh as your shell is that you can install Oh My Zsh which is a framework for managing your Zsh configuration.

You can install Oh My Zsh via curl:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Besides having awesome plugins and themes, Oh My Zsh also includes a ton of git aliases. You can see which ones are available by running alias. There are a ton of preconfigured aliases and all you have to do is add them to your .zshrc configuration file.

What's your favorite Git alias? I'd love to know in the comments below!

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

Beginner Python Resources Recommended by the Tech Community

Kara Luton — Thu, 11 Jul 2019 21:17:49 +0000

Besides the occasional dive into PHP, I've only ever worked with JavaScript. I went to a bootcamp for front end engineering and work as a UI engineer so I've never really had the need to look into any other languages. Lately, I've been interested in learning more about Python so I sent out the following tweet and received some great resources about where to begin!

// Detect dark theme var iframe = document.getElementById('tweet-1148400535822884864-338'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1148400535822884864&theme=dark" }

Here are some of the beginner-friendly Python resources that were recommended to me.

Free College Courses

edX's Introduction to Computer Science and Programming Using Python
This is a 14-16 hour/week course that lasts 9 weeks and is provided by MIT. The course is free but you can pay $75 for graded exams and assignments as well as a certificate.

Carnegie Mellon University's Fundamentals of Programming
By the end of the course you'll be able to read, write, design and debug Python code.

Online Resources

The Modern Python 3 Bootcamp
The course includes 29.5 hours of videos as well as downloadable resources, over 121 articles and 135 coding exercises. Udemy courses regularly go on sale so keep an eye on this one if you're interested in taking it!

Real Python
Various tutorials that allow you to learn Python from the ground up.

Python Crash Course by Traversy Media
Covers Python basics in an hour and a half.

Books

Learn Python the Hard Way by Zed Shaw
You'll work through 52 coding exercises when reading through this book. It also includes a DVD with 5+ hours of teaching.

Automate the Boring Stuff with Python by Al Sweigart
You'll learn how to write programs that take minutes to complete what normally would take hours by hand. No prior coding experience is necessary before reading!

Dive Into Python 3 by Mark Pilgrim
Each chapter starts with a real code sample which is broken down and explained.

Streams

Learning Python from Scratch with Brian Clark and Cecil Phillip
Brian and Cecil stream every Wednesday starting around 11 am ET where they document their journey learning Python.

Have another great beginner-friendly Python resource? I'd love if you left it in the comments below!

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

JavaScript 101: Arrow Functions

Kara Luton — Fri, 21 Jun 2019 14:05:44 +0000

Arrow functions - they're the more concise version of regular functions and they've been gaining popularity since they were first introduced in ES6. Not only is the syntax much cleaner but they also provide implicit returns which we'll dive into.

Hold up! If you haven't read the first part in this series, JavaScript 101: Breaking Down Functions, then make sure to check that out.

Let's start with how the arrow function's syntax is different from regular functions.

Here we have a regular function:

function helloWorld(name) {
 console.log('Hello ' + name);
}

If we wanted to use an arrow function, it would look like this:

const helloWorld = name => {
  console.log('Hello ' + name);
}

There are some key differences with arrow functions. We've dropped having to declare the function using the function keyword. Our parameters are a bit different than before as well. They now come after an equal sign and before the fat arrow (=>).

You may have also noticed that we're now declaring our arrow function as a variable. That's because arrow functions are anonymous functions or functions that are declared without a name. You don't have to assign them to a variable but doing so allows you trace them more easily when you have an error.

🌟 Quick tip: If you only have one parameter the parentheses are optional. If you don't have any parameters then you'll need to use empty parentheses.

Here's our example with multiple parameters:

const helloWorld = (name, emoji) => {
  console.log(emoji + ' Hello ' + name);
}

And our example with no parameters:

const helloWorld = () => {
  console.log('Hello');
}

Now that we've covered the syntax of arrow functions let's talk about another big benefit - implicit returns! This will make your code even shorter than before. Let's take the example we've been using and switch to a return instead of a console.log.

const helloWorld = name => {
  return 'Hello ' + name;
}

Because we're only returning a single line of code we can use the arrow function's ability to do an implicit return and rewrite our function like so:

const helloWorld = name => 'Hello ' + name;

When utilizing implicit returns, you're able to drop the return keyword as well as the curly brackets. This makes for really nice one-line functions.

Implicit returns aren't the only big difference between arrow functions and regular functions. Another big one is how they handle the this keyword.

In regular functions, the this keyword is bound depending on the context in which it was called. However, inside of arrow functions, this is lexically bound meaning that it's static and determined by the scope that it's in.

This is still something that I'm trying to grasp myself but JavaScript Kit has a great explanation if you're wanting to dive in more.

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

Did you transition to tech from another career?

Kara Luton — Fri, 14 Jun 2019 15:16:09 +0000

I'd love to hear if you've transitioned to tech from another career and why you decided to make the switch!

🌟Your answer may be included in my UndergroundJS keynote talk in August! 🌟

JavaScript 101: Breaking Down Functions

Kara Luton — Mon, 10 Jun 2019 15:28:12 +0000

Functions are at the core of what we do in JavaScript so it's essential that we understand what they do and how they work. But what exactly are functions? A JavaScript function is a block of code that performs a specific task and is executed when something calls it. Think of it like a recipe that's giving you the ingredients (parameters) and the directions (function body) for what you need to do.

Defining a function

Here's a function broken down into what you'll need: the name, parameter(s) and the function body.

function name(parameter) {
 // function body
}

The first step in defining your function is giving your function a name. Your function name can include letters, numbers, underscores and dollar signs. For example, your function could be named helloWorld, helloWorld1, hello_world or $helloWorld.

function helloWorld() {
 // 
}

Next, you need to define your function's parameters. Function parameters go inside the function's parentheses and are separated by commas.

function helloWorld(name) {
 // code to be executed
}

Here's an example of a function with multiple parameters.

function helloWorld(name, age) {
 // code to be executed
}

Quick tip! You may have heard the terms parameters and arguments used in the same way. They are very similar but should not be used to describe the same thing. Parameters are used when defining a function (what goes inside the parentheses) while arguments are the values the function receives from each parameter when the function is executed.

So if you define a variable such as const param1 = 'Hello World'; and then define your function function helloWorld(param1) {}. What's inside the parentheses is your parameter while the param1 variable that you defined as 'Hello World' is your argument.

Finally, the code to be executed will be placed inside the curly brackets. All together everything looks like this:

function helloWorld(name) {
 console.log('Hello ' + name);
}

Invoking a function

Great! We have defined our function but how do we get it to run? You can invoke (or run) a function by referencing the function name followed by parentheses. Let's invoke the function we defined earlier.

helloWorld('Kara');

// Hello Kara

Here I'm passing in 'Kara' as our argument and invoking our function. Then Hello Kara is logged to the console!

And there you have it! You now know how to define and invoke your function. Just remember, that all functions will always return a value. If there is no function body then your function will return as undefined.

function helloWorld() {}; // define your function

helloWorld(); // invoke your function

// undefined

Be sure to follow me on Twitter for lots of posts about tech, and if I'm being honest, lots of posts about dogs too.

ELI5: Git Rebase vs. Merge

Kara Luton — Thu, 09 May 2019 21:13:18 +0000

Up until now, I had only merged branches into one another but recently I discovered another option -- rebasing! Rebasing and merging are essentially doing the same thing so what exactly goes on behind the scenes for each?

Merge

Git merge combines multiple commits into one history. It will look at the two branches you want to combine and finds a common commit between them. Next, it takes the content of the feature or source branch and integrates it with the target (in our example, master) branch by creating an entirely new commit. This new commit holds the history of both of your branches. Because of that, you'll see all of the commits in chronological order.

Rebase

Rebasing is a bit different. Instead of merging the history of your two branches together from one base commit, you're actually making it seem like you created your branch from a different commit than you originally did. This allows you to keep a linear project history. This makes it a lot easier in the future to revert a change if you have a bug because you won't have to dig through to where the commit was made in the timeline.

So, which do you prefer? Rebase or merge? I'd love to hear in the comments below!

Be sure to follow me on Twitter for lots of tweets about tech, and if I'm being honest, lots of tweets about dogs too.

How To Answer The Dreaded "Tell Me About Yourself" Interview Question

Kara Luton — Mon, 25 Mar 2019 00:14:30 +0000

So, you’ve landed an interview with a company you’ve been dreaming about working at. You sit down and after some small chat the interviewer says “tell me a little bit about yourself.”

This common question results in the first impression at your interview, but is often the most overlooked. In my experience from being on both sides of the interview, I believe that by crafting a unique and memorable answer to this one question, you can land the job. Here’s how.

Don’t recount your resume

A big mistake I see people make is using this question to go over their résumé.

Don’t do this! Your interviewer has already looked over your résumé and probably has it sitting in front of them during the interview. They don’t need you to go over it again.

Practice and prepare answers to any obvious questions your interviewer may have

You wouldn’t show up for a talk you’re giving at a conference without practicing over and over again, right? Make sure you don’t show up for an interview without doing the same.

Sit down a few days before and think of what questions an interviewer may have for you after looking at your résumé. Use this time to go ahead and answer those questions.

For example, I’m a coding bootcamp graduate who used to work in music publicity. A potential employer looking at my résumé may wonder why I wanted to transition from publicity to tech and they’d probably ask about the process I went through.

And so, that’s one of the main things I address in my answer, because I know that will be the biggest question and could cause the most hesitation when it comes to a potential employer choosing me.

Take a look at your own résumé as if you’ve never looked at it before. Figure out what those questions would be for you and be sure those are your main points in your answer.

Find your quirk

For the next portion of your answer, find something that will make you stand out. You want your interview to be memorable and this is a great way to accomplish that.

Have you started your own meetup group? Do you volunteer consistently at a charity? Are you super passionate about a certain sport? Find your quirk. Make sure to mention it and tie it in to why you’d be a great choice for the position.

I personally have mentioned that while I was at The Iron Yard’s front-end bootcamp, I co-founded the Nashville Tech Ladies chapter where I organize quarterly professional development meetups for women in all areas of tech. Sometimes I’ll even mention how I grew up doing ballet. I’ll describe how ballet has taught me many things, like how to pay attention to the little details, that I am now able to translate into my career.

Pick something that is uniquely you, and it will make a lasting impression.

Explain why you applied for the position

Lastly, round out the question with why you want the position and why you are excited about it. You applied to the position for a reason — so tell the interviewer why you did it. They saw something in you and this is a great moment to let them know why you think it’s a good fit.

What are your tips for answering this common interview question? Comment below! Be sure to follow me on Twitter for lots of tweets about tech, and if I'm being honest, lots of tweets about dogs too.