DEV Community: Jacob Herrington (he/him)

SQL From Scratch Part 1 - Getting Started with SQL

Jacob Herrington (he/him) — Wed, 20 May 2020 18:52:30 +0000

Welcome to the first article of what will hopefully be a pretty long and useful series on SQL.

Before I dive into writing SQL, I want to make sure everyone is one the same page. Let's set the stage for this topic.

Just a heads-up, I'm assuming a very small amount of knowledge about your computer's terminal in this article, but feel free to drop questions in the comments if you get stuck.

Why learn SQL?

@dabit3 recently pointed out that most web apps are basically lists and forms (and you can build a pretty solid career around making those lists and forms).

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

But what happens to the data submitted in those forms, and where does the content that populates those lists come from? Nader hinted at the answer: Usually it's an API that talks to a database.

SQL is the language of databases. If you want to understand what you're hooking those lists and forms into, what they represent to the application, SQL is the best tool for exploration and understanding.

These days direct knowledge of SQL isn't strictly necessary for writing software backed by a database. We can build web apps with Rails leaning on an ORM so that we never even see SQL, but that is a surefire way to build inefficient applications.

If you're not a web developer learning SQL might seem less interesting, but SQL databases aren't used exclusively in web apps. SQL is used all over your operating system, it is used to build mobile apps, and if you have any interested in data science or business analysis, SQL is a necessary tool.

Even folks with less technical focus can benefit heavily from learning SQL. If you were a product manager looking to figure how many users sign up for your application each day, would it be easier to ask a developer to write a query for you or spend a few seconds typing up a query? If you wanted to figure out how many of those users were on the west coast of Japan? Basic knowledge of SQL could help you answer those questions and many more similar questions in a few seconds.

Want more data? SQL is everywhere, it shows up every single year on StackOverflow's Developer Survey.

Most popular programming languages according to StackOverflow:

2019

2018

2017

2016

2013

If SQL is running all over the place, most developers should have a grasp on the basics. It's a marketable skill and a super useful one, so a better question might be "why not learn SQL?"

What is SQL?

Structured Query Language (SQL) is a programming language that dates back to the 70s, but it is still in wide use today. The site you're using right now is running SQL queries to show you the content you're browsing.

Developers use SQL to interact with databases. If you've built websites using Rails or Django, you're probably familiar with using Ruby or Python to interact with a database, but in reality your application is generating SQL based on the code you wrote in Ruby or Python.

When we write SQL we are usually trying to accomplish one of four "CRUD" actions, or we are directly administrating a database. We'll talk more about CRUD later, but you should know that CRUD actions are all about manipulating data. For example, we might store sales records in our database and need to change a record to reflect a refund or discount. We might want to figure out how many of our customers bought Christmas trees in August. Those are tasks we can tackle with SQL.

SQL is largely unique from the modern programming languages we use to build websites, mobile apps, and video games (C#, JavaScript, Ruby, Python, etc).

We can describe one of the biggest distinctions between SQL and a language like Ruby in one word: Declarative. SQL is a "declarative" programming language. In layman's terms, this means that when we write SQL we don't typically need to describe how our code runs, rather we just declare what we want to happen.

Here is some SQL-like pseudo-code that might clarify the idea:

# We want a list of Twitter usernames
# for all the user accounts on DEV

Show me every DEV user's Twitter username
From the database's user table
Where the user has linked a Twitter account

If you've seen SQL before, you might notice some similarities between this pseudo-code and a real-world query that would return a similar dataset:

SELECT twitter_username
FROM users
WHERE twitter_username IS NOT NULL

This SQL doesn't look much like the code we write in JavaScript or Python. That's probably because in those languages we'd have to tell the programming language a lot more about retrieving information from the computer's memory. In SQL, we just tell the computer what information we want, not how to retrieve that information.

There is a lot of information online about the history and development of SQL, but I think this is enough information the conversation rolling.

Setting up a SQL playground

If we want to learn SQL, we'll need an environment to write SQL and some data to explore. We'll need a database.

There are a lot of tools out there for creating and interacting with databases. You've probably heard of a few (SQL Server, PostgreSQL, MySQL, CockroachDB, SQLite) and you might have a favorite, but you shouldn't spend too much time worrying about that!

Each database provider is going to be a bit different, but generally the things you learn on one kind of SQL database is going to work on the others.

For the purposes of these articles, I might jump between several environments, but a lot of my examples will come from the DEV database. DEV uses PostgreSQL which can be quite a bit of work to set up locally, so I don't recommend jumping down that rabbit hole if you are just looking to get a feel for SQL.

I recommend setting up SQLite for your SQL learning environment. It's easy to get started, easy to fix when something goes sideways, and doesn't require much of your system.

If you're on Ubuntu, like me, you can install SQLite3 with this command:

sudo apt-get install sqlite3

If you're on MacOS, I'd probably go with the brew option:

brew install sqlite3

For Windows users, it is a bit more complicated, and I'm not a Windows user so you'll have to flex your Search Engine muscles here. If you're a Windows user and have installed SQLite before, feel free to drop some links or guides in the comments (I might include the comment in this part of the article later).

You can test your SQLite installation by running sqlite3 in the terminal. It should look something like this:

The next step for setting up your playground is a dummy dataset. There are a lot of datasets available online for learning, but a really common one called "Northwind" is easy to get running with SQLite.

You'll want to create a new directory on your machine for the database, then go grab the Northwind script from GitHub.

I think it's easiest to grab this file with cURL and pipe it into a file:

# Go check the URL in your browser before you blindly cURL something!
curl -LJ0 https://raw.githubusercontent.com/jpwhite3/northwind-SQLite3/master/Northwind.Sqlite3.create.sql > nw.sql

If that looks foreign to you, don't worry too much. This is grabbing the file from a repo on GitHub and putting it into a file in your current directory called nw.sql.

Once we have the file on our machine, we'll make a new database and run the script to populate it with dummy data.

# Create the database
sqlite3 Northwind.db

# You'll be dropped into the database's command line interface
# Run the contents of nw.sql with the .read command
.read nw.sql

If you followed the steps correctly, you should see your console spitting out a lot of information (hopefully no errors)!

When the console slows down and you see the sqlite> prompt again, try typing (not pasting) this simple query in and see what happens:

# Don't forget the semi-colon!

SELECT ContactName FROM customers LIMIT 5;

Before you hit enter, try to imagine what this will do. It's really similar to English, so you might get closer than you think.

Maria Anders
Ana Trujillo
Antonio Moreno
Thomas Hardy
Christina Berglund

This query returns the names of 5 customers from our customers table.

If you see something similar to my results in your console, you've got SQLite and your Northwind dataset ready to go!

This should give you an environment that is safe to explore SQL without fear of causing damage to a real world database. You can also delete your Northwind.db file and recreate this database at any time by following the steps again, so don't worry about breaking anything!

In the next article we'll set up a tool to make visualizing our database much easier, we'll define some database words (tables, rows, and columns galore), and we'll talk about writing a query from scratch.

Bonus

If you want to explore the Northwind dataset a bit more in your terminal, you can use the .tables command to ask SQLite for a list of tables in your database.

See if you can figure out how to get a 5 employee's first names. I'll drop the answer in the next article.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

Easily Squash, Reword, Amend, and Sort Commits with Git Rebase

Jacob Herrington (he/him) — Tue, 19 May 2020 18:25:35 +0000

Recently (not that recently), I wrote an article explaining the oft-misunderstood git command: git rebase.

There I tried to ensure that anyone could glean the purpose and basic application of git rebase.

In this article, I'm going to explain a more intimidating application of git rebase. Choosing to rebase in this way allows me to convey the purpose and reasoning behind commits with clarity.

I'm talking using git rebase in the optional interactive mode. It is my preferred method of organizing code changes; good organization makes git a more powerful tool.

If you're unfamiliar with rebase, I'd give the previous article a look before reading this one. This article will provide a glimpse into more powerful applications of the command.

Running git rebase -i invokes a rebase in interactive mode.

Why is it called the interactive mode? Glad you asked. Interactive mode allows the programmer to influence how rebase executes. In the previous article, we used rebase to bring upstream changes into our branch, but we didn't manipulate any commits in that process.

In many ways, the process we previously followed is ideal; we didn't have to do any work, git handled everything for us!

Unfortunately, the real world is rarely ideal.

When it comes to git, we frequently make incomplete commits, forget to include important changes, or make bad commit messages.

In our scenario, we can imagine that we've got a branch called some-feature which looks something like the following:

47a0a7008b Add a rea322ally cool feature
6dbc838bae WIP forgot something from that feature
f2ee0378f9 WIP fixing a bug
f0978af68d Fixed the very annoying bug
61b6f8ea3e Fix a typo from my doc changes
8340051649 Update documentation
f8a81956e2 Fix documentation formatting

There are a few things that we might not like about this git history. For example, we have a couple of WIP (work-in-progress) commits that could be removed, a typo in one of our commits, and a commit that fixes a typo that we introduced in a previous change on this branch.

We are planning to merge this branch into another branch called master.

To fix the obnoxious git mistakes in this branch, we can use git rebase -i master.

When you run git rebase -i with another branch you'll be dropped into a text editor with the following prompt:

pick 47a0a7008b Add a rea322ally cool feature
pick 6dbc838bae WIP forgot something from that feature
pick f2ee0378f9 WIP fixing a bug
pick f0978af68d Fixed the very annoying bug
pick 61b6f8ea3e Fix a typo from my doc changes
pick 8340051649 Update documentation
pick f8a81956e2 Fix documentation formatting

# Rebase a6305fd0a..4a5782397 onto a6305fd0a (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

The prompt is extremely helpful, but sometimes a wall of text like this one can be intimidating.

In this view, git is showing you a list of the commits that exist in your branch, but not in master. They will be replayed on (or added on top of) the history in master. Each commit has a "command" alongside it.

For example, pick 47a0a7008b Add a rea322ally cool feature shows the command pick on the commit 47a0a7008b followed by its commit message.

Each command does something unique, you can read through the commands listed in the prompt if you like, but my most used commands are: squash, reword, and fixup.

To progress in the rebase you should replace the pick command with your preferred commands, then save and close the file.

I'd fix our example history like this:

reword 47a0a7008b Add a rea322ally cool feature
fixup 6dbc838bae WIP forgot something from that feature
pick f2ee0378f9 WIP fixing a bug
squash f0978af68d Fixed the very annoying bug
pick 8340051649 Update documentation
fixup 61b6f8ea3e Fix a typo from my doc changes
squash f8a81956e2 Fix documentation formatting

A few things happened.

First, I grouped the documentation commits together. This makes it easier to squash and follow the git history.

Secondly, I chose to squash or fixup several of the commits that were work in progress commits or fixes for issues I might have created while working on this branch (minor typos, formatting, work-in-progress commits).

Finally, I chose to reword the first commit message because it contains a typo.

Upon saving and closing this file, git will go to work. Each time a commit is squashed or reworded, I will have an opportunity to write a new commit message.

For example, when I hit the first commit I can reword it to "Add a really cool feature." When I hit one of the squash commits, I'll have the option to merge both commit messages or rewrite it entirely. Those commits with the fixup command are treated exactly like the ones with squash except that the commit message is completely dropped.

Assuming we don't have any merge conflicts, once the rebase has completed, the git history might read something like this:

47a0a7008b Add a really cool feature
f2ee0378f9 Fix a bug
8340051649 Update documentation

Those commits are much easier to follow and should make for a cleaner PR.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

Interview with Charity Majors: 6 Key Career Lessons From the CTO of Honeycomb

Jacob Herrington (he/him) — Wed, 08 Jan 2020 17:03:08 +0000

Late in 2019, I met a person who I had only know through their (fantastic) blog and Twitter feed: Charity Majors.

Charity is the CTO of Honeycomb, building production monitoring tools that champion observability (we use Honeycomb at DEV).

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

Years ago, when I started following Charity online, it was her willingness to share her opinion with conviction without being insufferable (despite usually being right) that drew me in. Charity's unique perspective on most problems lends itself to uncommon revelations.

Those revelations show up in conversation, as Charity frequently drops subtle wisdom bombs without fanfare. As a result, the second time I listened to this interview was nearly as valuable as the first. Hopefully, that quality shines through in this recording.

Engineer and CTO Charity Majors

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

1. The speed of change opens doors

Charity got me excited right out of the gate when she called tech "the one growth industry," and that the speed of change in this industry opens doors and enables possibilities that are not available elsewhere.

It was said in passing, but this is deceptively valuable insight. If you have a nose for sensing which areas of this industry are rapidly undergoing a metamorphosis, you can position yourself to be in the first crowd that steps through those newly opened doors.

That isn't to say you should become preoccupied with new tools and shiny concepts (something Charity talks a bit about later in the interview), but keeping in mind that the pace of this industry can be incredibly rewarding is key to thriving in it.

2. Management is not a promotion

During our conversation, it became evident that Charity is an expert in both engineering operations and people management. I found that this interview was particularly relevant for technologists who are looking to take on management roles or add leadership tasks to their current position.

Charity said that management is not a promotion; it's a job change. I think that this idea is profound and worth remembering. It's tempting to view management as the step after individual contributor, but in reality, it is a whole new discipline.

Compounding on this idea, Charity mentioned that there should be growth avenues for individual contributors that enable leadership and ownership outside of the traditional management career path.

As a software engineer or technologist, it is worth keeping in mind your eventual career goals (which Charity refers to as "what you want to be when you grow up."), and whether or not those goals include learning the skill of management.

3. Agency and ownership

When I asked Charity for advice regarding management skills, she immediately turned to the dual concepts of agency and ownership.

Charity described her relationship with ownership and how it ultimately reflected in her tendency to over-identify with her work.

However, she also described an engineer who took ownership of something a "gift." From a manager's perspective, someone who takes ownership over a task is freeing the manager up to focus efforts elsewhere.

As engineers and technologists, it should be a goal to take ownership of projects and products (each according to their level of comfort; work/life balance is essential). Especially in the case of those who want to grow into leadership or management-oriented roles.

Side-note, I found a great Twitter thread from Charity on this subject:

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

4. Grow a network of peers

I talk a lot about mentorship, but Charity challenged that idea. She suggested that a network of peers is more valuable than mentors.

Without a doubt, Charity encouraged seeking out peers more experienced and knowledgeable than yourself, but she said friendships are healthier than mentors.

Generally, I agree with this idea, and I've written about my experiences making friends in tech in the past.

For Charity, this takes the form of social gatherings with other technologists and going to conferences for the "hallway track."

Regardless of your methodology for growing a network, this advice is solid: Surrounding yourself with peers will enable career growth, help you find solidarity and friendships, and allow you to invest in others.

5. Don't fight your biology

Charity shared some pretty useful advice later in the interview. Specifically, she talked about fighting your biology.

In Charity's case, she was referring to her relationship with the operations side of engineering. Something about Charity pushes her to seek out the most pragmatic and necessary tasks; those tasks become the most interesting to her.

Therefore, when she's looking to learn new skills and invest in her technical knowledge, it becomes necessary to label that task necessary. Doing this allows Charity to carve out time for growth intentionally.

Many of us have tendencies to gravitate towards certain areas in our careers or shy away from things we don't enjoy. Charity's advice, in this case, is to avoid setting yourself up for failure by fighting your biology. Frame the things that are important to you in a context that fits your predispositions.

6. Celebrate the good things people say about you

Near the end of the interview, we talk about some of Charity's weaknesses.

Specifically, Charity talked about her internal dialogue and relationship with shame. At one point in her career, Charity chose to challenge the way she viewed herself by cataloging all of the kind things people said about her.

Recording the positive feedback and small wins she encountered helped Charity to realize her potential and fight back against the insecurities that we all feel (some more intensely than others).

In my own life, I've made an effort to record wins and positive feedback when I can. Interestingly, I've heard something similar to this in many of my interviews; keeping a record of things that make you feel good (sometimes called a brag sheet) is one of the most effective methods I've encountered for challenging self-doubt.

My conversation with Charity was incredibly encouraging, and I learned a ton from her. These concepts were some of the ones that resonated with me, but the value of her thoughts really can't be overstated. I hope that others get as much from this interview as I did.

Engineer and CTO Charity Majors

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

If you're interested in learning from veteran engineers like Charity, subscribe to my newsletter and follow along with the podcast. I have upcoming interviews with engineers all around the world who have built amazing careers for themselves.

Git Rebase Explained Simply

Jacob Herrington (he/him) — Fri, 03 Jan 2020 04:12:25 +0000

Rebase might be the most misunderstood git command.

Nearly every junior developer I pair with is terrified of git rebase.

Ironically, rebase is one of the few git commands I find myself using almost daily. Generally speaking, I rebase at least once for every pull request I make on GitHub.

I rebase to ensure that my commit messages make sense and that my branch won't have any serious, unexpected merge conflicts.

Using the git rebase command doesn't have to be complicated or intimidating, once you've got a handle on how it works and why it is useful.

Imagine you have two branches.

The first one looks like this:

3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...

The second one looks like this:

242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...

If you're looking closely, you'll have noticed that these two branches are identical from their bases until 13363dd3, where they diverge.

The first branch, which I'll refer to from now on as our working branch, has three commits that don't exist in the second branch.

The second branch, which I'll call master in this example, has eight commits that don't exist in our working branch.

In reality, it's extremely easy to end up in this situation. You can easily replicate this by working on a project with many other developers (like DEV) when you create a feature branch.

If your feature branch exists for a few days, it's likely that master will change before you are able to merge your branch back into master.

In that case, it'd be really convenient if you could catch your feature branch back up to master and bump your changes to the top of the git history.

If we caught our working branch back up to master and put those three commits on top, it might look like this:

3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)
ba424854 Enable cache logging in development if requested (#5330)
51df3255 Change MentionJob to MentionWorker ...

Doing something like that would make a pull request against master much cleaner and help us avoid merge conflicts.

Luckily, that is effectively what rebasing a branch does!

Let's talk about the name of this command: Rebase. What does that mean?

If you think of these two git branch like a tree trunk (the tree metaphor is constant in git), you can imagine that we'd like to replace the base of our working branch with the base of our master branch.

In other words, we'd like to "re-base" the working branch with the master branch.

Let's walk through a rebase.

I almost always use the -i (aka interactive) flag when I rebase because it makes it easier to reword commit messages, squash commits, or resort the order of commits. Those features of the git rebase command are beyond what I want to get into in this article, so we'll skip that for now, but I encourage you to try out the interactive flag.

Instead, assuming we have working-branch checked out on our local machine, rebasing is this simple:

git rebase master

You'll see some console output:

First, rewinding head to replay your work on top of it...
Applying: Some change that I made
Applying: Another change I made
Applying: One more change that I made

You can see that git is "replaying" our work, like a recording, on top of the master branch. That's not a bad metaphor for understanding how rebase works either.

When we log out our git history, you'll see that our changes have been replayed on top of the master branch.

3def6294 One more change that I made
579db95b Another change I made
f261ebba Some change that I made
242c6eb5 Change from after_create to ...
c64bfdb6 Handle missing commentable ...
cb98b3b5 pages bust cache job sidekiq refactor (#5338) [deploy]
df042d6b Refactors ActiveJob ...
783d43b7 Change create first reaction job to worker (#5327) [deploy]
c1638cfd Create UpdateAnalyticsWorker to replace UpdateAnalyticsJob (#5331)
040b36bc Fix event propagation for click on tag rules in editor (#5280) [deploy]
ba230eca Allow language-xxx class detection on pre tags in ReverseMarkdown (#5299)
13363dd3 Rails 5.2 features: enable cache ...
73188cd8 Sidekiq: add test helpers (#5326)

...

In other words, we "re-based" our branch with master.

If using rebase still scares you, try making a copy of your working branch before you run the rebase command, just to be safe!

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

How I Handle the Fear of Rejection

Jacob Herrington (he/him) — Fri, 13 Dec 2019 17:42:23 +0000

This is a slightly edited version of a short blurb I sent out to my email subscribers in November.

Howdy 🤠

This is my first time writing to you, so thanks for all of your patience, and sorry if you were enjoying the silence.

I'm sitting in a coffee shop before RubyConf kicks off, listening to one of my favorite songs (2112 by Rush), and thinking about a DM I got on Twitter recently.

A 20-year video game industry veteran just reached out to me. He has worked for Blizzard, Twitch, and a bunch of other cool companies.
He also runs a hosting service that is really cool and unique (he is running it at cost as a hobby)!

He works remotely from Portugal, and I guess it's been tough being a remote worker in the esports industry over the last few years.

Right now, he is searching for a new job and struggling to find a good fit. In particular, he is interested in technical roles because he spent the beginning of his career in a SysAdmin role.

I actually think he'd be a great fit for any company looking to grow an SRE team. (If you're looking for an SRE or developer with great communication skills shoot me a DM!)

Anyway, I'm writing to you so I can share some advice that I've given 100 times, but never written down. Our friend in Portugal is having some fears concerning rejection as he searches for a new job. That fear of rejection is universal; I feel it, and I'm sure you feel it.

Being someone who really feels the effects of social anxiety, the fear of rejection has always been a big part of my life, but I've gotten to a point where I do a pretty good job of coping with it.

People frequently mistake me for an extrovert because I'm always advocating for networking and transparency, but in reality, I'm super introverted. I've just become really comfortable being uncomfortable.

My strategy for overcoming my fear of rejection (and extroversion in general) is the same strategy I used to get comfortable taking cold showers. It's sort of a homebrew version of exposure therapy.

Every day, I spent 10 extra seconds standing in cold water before I turn on the warm water. I started with 30 seconds. At this point, I could easily take a 3 or 4 minute cold shower. I'm pretty comfortable with that level of discomfort.

The same tactic can work for dealing with any discomfort. I faced my social anxiety by making cold calls and reaching out to people on LinkedIn years ago. I wrote about why I did that on DEV last week.

After I had been rejected a few dozen times, I started to feel a lot more comfortable with that feeling of rejection, and it became easier to shrug off the feeling of defeat when someone didn't respond the way I had hoped.

I think, when it comes to job hunting, a big resource for this fear of rejection is the idea of "requirements."

Think about the last job posting you looked at, did you focus on the blurb about the company, or did you scroll down to the bold requirements heading?

When I look at job ads, I frequently ignore the requirements section completely (sorry recruiters) because I've found both as an applicant and as someone hiring engineers that the "requirements" are really just a wish list.

In reality, 90%* of the applicants to any given job aren't going to meet the requirements. Most of them don't even come close.

I'd be willing to bet that I haven't met the requirements for any tech job I've ever had.

All you're doing by looking deep into the requirements for a job is fueling that fear of rejection.

In fact, this applies to almost everything in life: Asking an attractive person on a date, joining a club or team, asking for a promotion, whatever.

We have perceived requirements for all of the things we do, and those requirements are like gasoline for the fear of rejection.

I sometimes catch myself thinking, "Well, I don't have X, so Y isn't realistic for me." When that kind of thinking creeps into your head, you've got to stop and remind yourself that the absolute worst outcome of this sort of interaction is a resounding, "No."

And that is a great thing! Because a hearing, "No," is just another opportunity to get comfortable with the discomfort of rejection.

Ultimately, it won't have any effect on the outcome of your next attempt to apply for a job you want, even the ones you aren't "qualified" for.

So my advice is this: When you're applying for a job, reaching out for coffee, asking for a raise, or whatever, ignore the perceived requirements.

The worst outcome is that you get a little more comfortable with rejection.

Thanks for reading!

Shoot me an email if you've got any thoughts on rejection.

If you want to hear more of my ramblings, you can sign up for my emails.

*Disclaimer: I made that stat up.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

How to Find Mentors, Grow a Network, and Make Friends

Jacob Herrington (he/him) — Tue, 12 Nov 2019 19:37:00 +0000

Recently, I wrote about my success building a career on relationships and networking, and about my definition of networking: finding ways to help others.

Sometimes because I spend a lot of time trying to help other people, I end up playing the role of mentor. More typically, however, I'm the one looking for guidance.

I think there is a lot of misinformation on the internet about what mentorship should look like and how one should go about finding their mentors.

Maybe that's unfair, but when I was first entering tech, I felt like most of the information I found on the subject was misleading at best.

These days, I don't really struggle with finding mentorship from those more experienced than me, in fact, I've been reasonably successful building a podcast around my efforts to do that, interviewing a fair number of my heroes:

Open Source Maintainer Steve Klabnik

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Honestly, I've found that finding mentors is mostly about legwork. Before I explain what I mean by that, I'd like to dispell some of the things I thought about mentorship when I started in tech.

Mentorship myths

Primarily, I'd like to challenge the notion that mentorship is a formal relationship. This is something that I think people are more open about these days, but when I was looking for my first guides into the tech industry, I felt I needed to find someone willing to spend hours with me each month to receive effective mentorship.

One of the most valuable mentors I have meets with me on an irregular basis for coffee. We probably chat for a few hours every two or three months. In those hours, we talk about Star Wars and coffee as much as we talk about our professional lives, and we talk about his professional life as much as mine (even though he is the CEO of a YC company you've heard of).

You'd think that in our relationship, I'd have no significant value to offer on the ideas he is chasing. Ironically, he is probably getting quite a bit of value from hearing my (ignorant) thoughts on his projects, if only because I'm not invested in them.

This relationship is informal in most ways, and we've never really talked about the idea of "mentorship" in any formal capacity.

Another person I've had the good fortune to be challenged by, both synchronously and asynchronously, has nothing resembling a formal relationship with me.

The first time I ever listened to a programming podcast, it was one hosted by Avdi Grimm. I'd say that Avdi has always been a central figure in my journey as a developer, only recently as something that I could describe as a mentor.

Gourmet Ruby Chef Avdi Grimm

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Even before I met Avdi, I was being mentored asynchronously by him, in the form of his courses and blogs. Now, I've had the opportunity to ask for Avdi's professional guidance once or twice. He recently gave me some excellent advice about dealing with my responsibility and privilege when I'm pontificating on the internet (which he dove into on a blog post).

I'm sure there are people out there who have incredibly fruitful mentorship relationships that are formal and carry some amount of routine, but the best guidance I've been given has been informal and in the form of friendship.

Secondly, I'm going to challenge the idea that finding a mentor has to be time-consuming.

When I first searched for a mentor, I spent an excessive amount of time trying to determine who I should ask for advice. That was completely unnecessary. Instead of searching for someone that I thought would be a good mentor to convince, I should have been going to the people who were already offering their time.

Right now, there is an awesome service called CodingCoach that Emma Wedekind (who gave me advice when I was first starting my podcast) has been working on. CodingCoach will pair you up with people who are looking to share their knowledge.

UX Engineer and Coding Coach Founder Emma Wedekind

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Alternatively, I am part of an organization called Ask-a-Dev that hosts events in dozens of cities. The organizers are people who want to provide mentorship and openly volunteer their time to anyone who wants to be present. If this organization has a meetup in your city, it's probably the fastest way to find a tech mentor.

If all else fails, you can just ask a handful of the people you look up to on Twitter or DEV. That's how I reach out to pretty much everyone that I interview on my podcast. It's been pretty effective so far.

Finally, I want to challenge the idea that mentorship is a one-way relationship.

In my opinion, if your mentor has nothing to gain from mentoring you, you're probably seeking out the wrong kind of mentor anyway.

A really solid mentor will be humble enough and wise enough to realize that your knowledge and experience differs from their own, which can make for useful insight.

In all of my relationships with the people I'd describe as mentors, there is some give and take. Generally, the more experienced person is going to be giving advice and guiding the less experienced person, but that doesn't mean there aren't opportunities to help your mentor.

Keeping an eye out for those opportunities can help create a healthy mentorship relationship.

If a person who is guiding you doesn't expect or ask for some thoughts in return, you might want to reconsider taking their advice.

Even Mr. Miyagi had things to learn from that snot-nosed punk Daniel.

Finding a mentor

If you can accept the stuff I've said so far, you might realize that finding mentors isn't nearly as intimidating as most people make it out to be.

You don't need to ask someone to commit to an hour every week, you don't need to sell someone on your potential, and you don't need to go looking for some wise sage with nothing to learn from you.

When it comes to finding mentorship, it's not unlike building a friendship. You simply need to reach out to someone and ask for a few moments of their time on a problem you're facing.

I've done this with my podcast. I wouldn't have had even half of the incredible guests I've had if Kent C. Dodds hadn't been willing to spend a half-hour helping me to find my first ten guests.

JavaScript Expert and Content Creator Kent C. Dodds

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

I've also done it with technical and career problems. Asking for advice on a situation someone else has been in can be as simple as a Twitter DM about your question.

However, it would probably be good to include some caveats here:

Don't ask for a significant time investment if you're not providing some similar value. This is rude and presumptuous. It's harmless and innocent to ask a question that will take ten minutes to answer, but asking someone to solve a bug for you could potentially be asking someone for hours of their time.

If someone doesn't have time for you, don't take it personally. Some of the people you'd love advice from don't have time to answer every question they get. They have families, hobbies, and obligations outside of answering Twitter DMs.

Find a way to be useful in return to people who help you. It could be as small as sharing the project they are working on with your network or submitting a PR to their Open Source project. If they are a freelancer, you might be able to direct work their way. Relationships are all about give and take. If you only take, you're not fair to your mentors.

When you're looking to create a long term relationship with a mentor, reciprocating is key. while many people try to mentor their junior peers out of charity, it is time-consuming. It's always going to be appreciated if you can make that time more valuable for the people who are sharing it with you.

A network of mentors

This is part of what I meant when I said finding mentors was about legwork. Finding opportunities to do the legwork for your mentors is a huge part of building a network of mentors.

When I say a network of mentors, I'm talking about surrounding yourself with people who can build you up.

That takes significant legwork.

It's not always wise to invest deeply in building a single relationship with one mentor; things could change. That person might not have the time or energy to guide you in the future.

Instead, you can find many mentors who are your peers and senior to you by putting yourself in the spaces those people occupy.

I'm going to share a list of ways I've put in "legwork" to build an extensive network of mentors:

Volunteer at a conference
Start a podcast (duh)
Write blog posts featuring other people's work
Engage with someone frequently on social media
Contribute to Open Source (do the grunt work)
Refer people to freelance opportunities and jobs you know about
Help others find candidates for their job openings

The thing about these tasks is that they are reasonably menial and don't require a ton of knowledge or experience to do in the first place, but they are helpful.

I've met some fantastic people by speaking and volunteering at conferences. In some cases, I've just been a CFP reviewer; in others, I've taken on the responsibility of fundraising.

Neither of those tasks require a ton of knowledge, but they are critical when it comes to hosting a good conference.

You can even volunteer to do something like hand out T-shirts or something. The odds are good that you'll have the opportunity to get to know a few organizers and speakers. Those people tend to make great mentors as they're already volunteering their time to build a better tech community.

My podcast has introduced me to more awesome mentors than I can name (not just the people I've interviewed)!

Doing this kind of legwork, which isn't glorious or cool, will help you to start your relationship with mentors from a place of usefulness.

Once you've found a few people who are willing to get coffee from time to time, answer your DMs, or do a video call now and again, you've found your network of mentors.

At this point, maintaining those relationships is all about good communication and follow-through. When you get good advice, try to apply it and report back, let your mentors know they are helping you. Of course, keep looking for opportunities to return the favor.

If you've got a network of peers and informal mentors who can offer you advice and guidance, you've got the added benefit of not over-taxing a single mentor with your questions and problems. You can disperse those over several people and get multiple opinions. You might also find that you get along with some people better than others.

Informal mentorship

Approaching from mentorship from this angle is transforms the relationship from formal to informal.

A considerable benefit of shifting your perspective on mentorship from a formal one to an informal one is that there is no pressure to extract value from a mentor at every turn. Instead, you have the freedom to ask for your mentor's guidance when you need it and provide value in return when you see the opportunity.

There is no pressure on you to force these relationships. You can treat like any other relationship with a peer or friend.

Eventually, if you're growing the relationship in the right way, your mentors might even become your friends.

In my experience, this is a much healthier and productive way to go about finding and receiving mentorship than trying to force another person into providing some kind of formal mentorship. I also think your odds of building a long-lasting relationship is much higher if you approach your potential mentors with an offer of friendship instead of asking to "pick their brain."

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

How I Got Hired at DEV (and Every Other Tech Job)

Jacob Herrington (he/him) — Fri, 01 Nov 2019 16:54:35 +0000

On tech jobs

There has never been a better time to join the tech industry. These days we have all kinds of resources for self-teaching (like I did), connecting with other technologists (DEV), and building a career in tech. It seems like every time I go to a coffee shop or get in a Lyft, someone asks me about becoming a developer.

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

I usually share my story, or a piece of it, about dropping out of college and working through a few low-paying internships until I found a Rails shop that would take a chance on me. As it happens, that was a pretty harrowing experience and launched what will probably be a lifelong relationship with imposter syndrome.

You'd think that with all the people being told to hop on the tech industry gravy train, finding a developer job would be easy.

Ironically, finding a job in tech can be difficult, and that difficulty is usually multiplied exponentially for those coming from underrepresented demographics.

On privilege

Before I share the story of how I got hired at DEV, I want to take a few seconds to recognize the considerable role that my privilege has played in my journey.

I wouldn't be where I am if I didn't start with some serious advantages.

I don't come from wealth (I'm probably making more today than anyone in my family tree has ever made), my parents didn't go to college, and I received a public education in a state that competes for the worst education ranking in the United States. Still, I am among the most privileged people in the world.

I am a white, straight, cis-gendered male who knows more about Star Wars than 90% of the population, and while I didn't grow up around other technologists, I started writing code before I was in high school. When I walk into a room, people think I look like a software engineer; that has been a huge part of my journey, and I want to make that clear before I talk about the things I did to break into tech.

I can't give advice in good conscience because some of the things I did won't work for people who weren't born with the same advantages I have, but I can share the things that have worked for me. Hopefully, others can pull some inspiration or value from my story.

Some context

I'm pretty young. I rarely share my exact age with people because I learned early on in my relationship with startups that young people aren't always treated with equal respect (specifically by investors and older founders).

A handful of years ago, I was in college and working through Air Force ROTC (a commissioning program for officers in the USAF). After a series of seemingly unfortunate events, a weight-lifting injury, and a couple of heart-to-heart conversations with veterans in my family, I left my goal of becoming an officer in the Air Force behind.

For me, leaving what was supposed to be a lifelong career path was pretty scary. I didn't know what to do and stopped going to school. During this period, I achieved the peak of Counter-Strike career by reaching DMG, but that's another story.

After a few months of not doing much, I enrolled in a local community college, pursuing a business degree. I'll pretty much leave my academic career behind in this story, but I dropped out at about a semester shy of a BS in Information Systems at some point during this journey. Honestly, I wish I would have done it earlier.

While I was screwing around and trying to get a degree, I decided college wasn't teaching me what I wanted to know, so I started searching for internships. This is where my strategy for finding jobs was born.

Spoiler: I don't apply for jobs

To help convey exactly how I ended up getting a job at DEV, I'm going to tell the story of how I found my first internship because it was actually a really similar pattern.

I've had a job since I was old enough to work (and also before). I'd been a lifeguard, a janitor, worked in a movie theater, a summer camp, a bookstore, had a job selling MacBooks, and worked at Lowes' before starting in tech. That being said, I had no idea how to go about getting an office job.

My first internship was at a Fortune 500 transportation and logistics company called J.B. Hunt. I got the internship by using a method that would only be employed by someone who had never tried to get a corporate job before: I called the first phone number I could find online and asked for a job.

It turns out that there is a straightforward way to get past auto-filters and ATS pipelines, even at the largest and most slow-moving corporations on Earth. It's as simple as not applying, at least not until after you're in contact with a hiring manager.

I got lucky with this first experience; somehow, I got through to a hiring manager before I hit an HR roadblock. By the time I had sent my resume to the company, I'd already had a phone interview with someone hiring interns for the IT organization within J.B. Hunt.

After that experience, I haven't actually applied for a job (that I've taken) since.

I had something like five internships while I was "going to college" (I had dropped out by the time I was doing the last couple of internships). I got every single one of them (except the one at J.B. Hunt) by cold calling someone with the letter "C" in their job title.

The advice I share with people trying to find a job in startups or medium-sized companies falls in line with the method I used to find each of my internships: Get coffee with someone who can hire you. Ideally, you can build a relationship with someone who can hire you without asking anyone else; CTOs, CEOs, COOs, and Co-founders are the people you want to get to know when you're looking for a job.

There is a secondary benefit here, even if you aren't looking for a job, these people are wonderful contacts and mentors (and sometimes great friends).

On networking

This is the part of the story where people start to wonder if I'm going to use the evil, sleazy word "networking." The honest truth is that nearly all of the things you could define as success in my career have come from networking.

I've found, at least among engineers, that networking is really misunderstood.

I got into tech because I love helping people. That's the reason I started in IT; solving someone's immediate problem was extremely rewarding for me.

As it happens, good networking is just that: helping people. I'm always on the lookout for ways to help the people around me, the way some of my mentors helped me. I invest a serious amount of time in helping junior engineers to find jobs, start contributing to Open Source and get more involved with the tech community. I do that because I really, really enjoy helping people grow, but it also tends to pay back in dividends.

This is a bit of a tangent, but what I'm getting at is that networking isn't evil, especially if you're coming from a place of trying to help others and build community.

On getting internships

So, if you're able to get in contact with a decision-maker at a company you'd like to work with, you've done the hard part of getting an opportunity to work on that team.

In my experience, once you're able to get in contact with someone, you can get to know what they need. I always shoot for meetings over coffee because it allows me to find out if I can provide some value to these people.

In my case, each of the internships I ended up working stemmed from a problem that I thought I could solve for the person who took the time to meet with me.

I also made a point to learn during these coffee meetings and turned them into short mentorship sessions, complete with a list of prepared questions about the things I was trying to achieve or working on.

More often than not, I faced rejection when trying to set up meetings with the people I was looking to meet.

Early on, I'd say 80% of the people I sent emails or LinkedIn messages never replied or told me they didn't have the time to meet with me.

Even those people who met with me didn't always mesh with me or sometimes felt that I didn't have enough to offer them. Once in particular, I asked a mentor for the chance to intern under him, and he said, "You're trying to play in the NFL, but you don't even play football yet." That was pretty rough.

Here is the point: Getting in a room with someone who can offer you an internship is the most challenging piece of the struggle. The second step is finding a problem you can take off of their plate, which is easy to do if you come prepared with questions and thoughtfully consider the answers they give you.

On getting full-time jobs

I was able to repeat the internship process in some form or another quite a few times. I found some great internships and some terrible ones by getting to know people who could offer me a job and trying to be helpful.

When it came time to get my first full-time job, I was actually working two internships at the same time. I was working a lot more than 40 hours a week, and it wasn't healthy (and interns don't make much money), so I was looking for an out.

Because I had invested in networking, someone reached out to me about joining a super high-quality Rails shop in my area, and I ended up (somehow) getting through a five-round interview process.

After a very difficult year (which I spoke very briefly about at 200OK), I went back to my strategy of networking with founders to find a job at a startup in my area.

I reached out to the CEO of a brand new startup called Engine with this LinkedIn message:

Remember how I said 80% of the people I reach out to end up ignoring me? Probably by accident, John never got back to me in 2017. I tried again in 2018.

By meeting with John over coffee, I was able to have a very human connection with someone who didn't need to go through some HR process to hire me. As the CEO of a startup, John could decide to hire me based on our attempt to connect as humans rather than my ability to navigate an interview process.

Long story short, I joined Engine as a "Junior Developer." That job was a decrease in title and a nominal increase in pay, but it ended up being one of the best career decisions I've made so far.

Engine gave me a platform to expand my professional network by getting involved in Open Source.

During my time at Engine, I doubled down on my involvement in the tech community: I started organizing conferences, speaking at small events, blogging, and I started a tech career podcast. Those time investments in the tech community ended up exponentially increasing my network and exposing me to mentors that I'd never dreamed of getting to know.

Surprisingly, networking is pretty cool.

A few months ago, I accidentally replicated my process for finding jobs with DEV.

On getting hired at DEV

I met Ben through my podcast.

DEV Webmaster and Founder Ben Halpern

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Actually, I met Ali, who told me to talk to Ben.

Teacher and Developer Advocate Ali Spittel

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Don't stop reading just because you don't have a podcast. Let me tell you a secret about my podcast.

My podcast is two things: 1) a trick — 2) a useful service to the people who talk to me.

I never set out to build a big following or a serious listenership for my podcast. I came up with the idea while sitting in my wife's office, wondering if Avdi Grimm had struggled with imposter syndrome the way I had.

Gourmet Ruby Chef Avdi Grimm

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

It took me about 20 minutes to email five or six of my heroes and ask them to talk to me about the things they struggled with. Once a few had agreed, I had a podcast.

The "trick" is pretty well encompassed by something Kent C. Dodds told me after I interviewed him, "I can't sit down and talk with a thousand people, but I can record this interview and send the link to people who ask me these sort of questions."

JavaScript Expert and Content Creator Kent C. Dodds

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

Now that I've had some awesome guests on my podcast and a handful of dedicated people listen to my interviews, it's pretty useful to the people I interview. They can have the "mentorship" conversation with me once, and thousands of people can benefit from the same conversation.

The kind of people I was trying to meet (generally well-known, experienced engineers) were busy people. I wasn't going to get an hour of their time just by asking for it, but if I could give them something tangible in return, they might be able to make time for my questions.

Just like when I was looking for a way to solve problems for my mentors, I am now trying to solve a problem for my role models.

Ironically, when I met with Ben, I wasn't looking for a job.

I wanted to interview him because someday I'd like to start a company like DEV, one with strong values and a close connection to the Open Source community. It just happened that DEV had the resources and interest in bringing someone like me on-board.

At the end of the interview, when we had stopped recording, I asked Ben something along the lines of, "Is DEV going to hire soon? What does your company look for in people?" I honestly wanted to know what kind of skills I should be investing in to prepare for starting or working with a company like DEV, but by serendipity, Ben was looking for people at that moment.

Pattern recognition

If you've read this rambling post to this point, I'm impressed. I've told a few versions of this story over the last few years, some pretty painful and others (like this one) more hopeful.

Ideally, there is some value in the story. I'll try to find that for those of you who've read this far!

After some reflection, here is the pattern that I can extract from my journey finding developer jobs.

1) Identify companies you want to work for

When I decided to leave my first internship, I wrote down 10 "dream companies." At this point, I've worked for about half of them (and interviewed with most of them).

2) Build a relationship a decision-maker

This doesn't need to be something you do intending to get a job; it can just be an opportunity to learn from someone you admire. That being said, never underestimate the power of networking (even if you think it's sleazy).

This is pretty nuanced; if you set out to take advantage of people or manipulate them, you're doing this wrong. Set out to help people. If those people want to reciprocate great, if not, then take joy in helping other people solve problems.

There is also a difference between networking and harassment. Please don't be persistent when people aren't interested in networking. It's super rude.

3) Provide some value to your new acquaintance

Learn how to solve the problem they are having, give them a platform, or connect them with someone you know that might be able to solve their problems. Helping other people is rewarding, and it frequently helps you to build great relationships with the people you're helping.

At DEV, I was able to give Ali a platform to promote DEV and later give Ben the same platform. I also made a couple of small PRs to the repository.

4) Ask for the thing you need

You can't expect people to know that you're looking for a job unless you tell them. Even if you don't think those people are hiring, you can ask them for advice on working for a company similar to the one they work at, that is precisely what I did when I was talking with Ben.

This isn't advice

I want to reiterate that I don't consider this advice, it's just the path I took. Unfortunately, the vast majority of people would have a much harder time doing this than I did; I have a lot of serious advantages that came into play during this journey.

My goal is to share this story in a hopeful light because I promise there were some dark chapters on my journey to DEV, but I like to think there is something in every story that can be useful to the audience. I might be wrong in thinking that the pattern in my job finding methodology is helpful, but maybe something else in this story is useful to you as a reader.

But if you'd like my advice

I'm something of an open book.

If you're struggling in your job search or you think I have some experience that you might benefit from, please reach out to me on Twitter or DEV. I'd love to help.

A caveat

It would be untruthful of me to claim that I don't apply for jobs (ever). The truth is that I apply for jobs frequently and like to interview. I see interviewing as a kind of sport, and I enjoy learning how different companies hire employees.

That being said, I've never actually taken a job that I've applied for traditionally. Eventually, I might, but many of those interactions didn't lead to offers or led to offers that weren't compelling enough for a job change.

Every tech job I've had has come through my network in some manner or another.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

What Alternative Text Editors Does DEV Use? (Not VS Code 🐱‍👓)

Jacob Herrington (he/him) — Thu, 31 Oct 2019 18:34:23 +0000

Hey DEV!

I'm a huge fan of VS Code, and I use it for pair programming and occasionally when I want to use one of the awesome extensions that the VS Code community has provided.

However, I'm also a fan of diverse marketplaces. I don't really like the idea that the vast majority of developers I interact with use the same text editor.

I'm the kind of person that uses Ubuntu, Firefox, and DuckDuckGo. Not just because they are great tools (I think I'm having a better time on Ubuntu than the last year I spent on MacOS, honestly), but because I don't like the idea of a single company controlling a market.

For that reason, I wanted to start a conversation about alternatives to VS Code.

I use Spacemacs, which is a set of Emacs configurations that essentially combine the Emacs and Vim text editors. I really like that I don't have to do much tweaking out of the box, but I still have a lot of the power found in both Vim and Emacs.

Spacemacs 👽

What alternatives do you use? Or, if you don't what about VS Code keeps you from using something else?

Give Your Terminal Super Powers: tmux Cheatsheet!

Jacob Herrington (he/him) — Thu, 31 Oct 2019 03:57:33 +0000

tmux is an application that I use in my terminal to manage several programs running at once. I've used it on Linux and Mac, it's one of the first things I install on a new computer along with Zsh and asdf.

The tmux wiki refers to tmux as a "terminal multiplexer;" basically, it lets you run several programs in one terminal window (and do some other really cool stuff).

It's one of those productivity tools that takes a certain amount of upfront investment to become comfortable. It's not quite as hard to get used to as Vim, but you do have to remember a handful of hotkeys.

Installing tmux

If you want to get your hands dirty with tmux, you'll have to pop open a terminal window and install it.

If you're using Ubuntu, you can install it with a simple sudo apt-get install tmux.

For those of you using Mac OS, you can install tmux with brew install tmux.

I haven't done development on a Windows machine in years, so I'm not sure how to get it running in that environment. If someone does, please leave a comment so I can link to it here, thanks!

Leader key

In tmux, pretty much every command starts out with the Leader Key, sometimes also called the prefix. By default, you have to press ctrl + b.

For most tmux commands, you'll press the leader key, then the hotkey for the command. Unlike many hotkeys, you don't need to keep the leader key held down while pressing the hotkey.

Sessions

Starting a tmux session

tmux sessions are the interface for using tmux. When you start your terminal, you'll need to launch a tmux session.

This is easy, just type tmux into your terminal, and you're off!

Creating a named session

Sometimes it is useful to give a tmux session a name, so that you can detach from it, and re-attach to it later.

tmux new -s some-session-name

Renaming a session

ctrl + b $

Detaching from a session

You can detach from a session and return to your standard shell without closing the session. This allows you to pick up your work later.

ctrl + b d

Listing existing sessions

You can list existing sessions by name with:

tmux ls or with tmux list-sessions

Attaching to a session

Once you've detached from a session, you can pick up where you left off by attaching to it.

Attach to the most recent session:

tmux a

Attach to a session by name:

tmux a -t some-session-name

If you currently attached to a session you can hop between sessions too.

Attach to the previous session:

ctrl + b (

Attach to the next session:

ctrl + b )

Kill a session

tmux kill-ses -t some-session-name

Kill all other sessions

If you want to kill all the sessions other than the one you are currently using, tmux makes that super simple:

tmux kill-ses -a

Panes

This is the most widely used feature of tmux. When you want a terminal with several windows running different processes, for example: a server, git, and Vim. You'd use a few panes.

The basics of pane splitting are easy!

Split a pane vertically

ctrl + b %

Split a pane horizontally

ctrl + b "

Navigating panes

You can navigate between your panes with the arrow keys. This is the most basic way of moving across your window:

ctrl + b ←
ctrl + b ↑
ctrl + b →
ctrl + b ↓

Jump to the most recent pane

ctrl + b ;

Jump to next pane

ctrl + b o

Close current pane

ctrl + b x

Show pane numbers

Panes can be identified by numbers, you can get a list of those numbers with this shortcut:

ctrl + b q

Swap to a pane by number

ctrl + b q 0 (replace 0 with preferred pane number)

Resize current pane

This is one of the few cases in which you should hold the leader key down instead of releasing it!

ctrl + b + ←
ctrl + b + ↑
ctrl + b + →
ctrl + b + ↓

Move the current pane

To the right:

ctrl + b }

To the left:

ctrl + b {

Windows

If you need a new set of panes, you can create a window. A window is kind of like a tab.

Convert a pane into a window

ctrl + b !

List all windows

ctrl + b w

Select window by number

ctrl + b 0 (replace 0 with preferred window number)

Create a new window

ctrl + b c

Navigate to the previous window

ctrl + b p

Navigate to the next window

ctrl + b n

Close the current window

ctrl + b &

Command mode

Like Vim, tmux has a command mode.

To start command mode, use this:

ctrl + b :

Get help

ctrl + b ?

This is a cheatsheet for me, but hopefully, others find it useful. I'll probably expand it as I think of additional shortcuts I use frequently.

If there is a tmux shortcut you use frequently, feel free to add it in the comments!

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

The Divergence of Open Source Maintainer From Software Engineer

Jacob Herrington (he/him) — Wed, 30 Oct 2019 19:23:06 +0000

In my career, I've had the opportunity to work as a maintainer on a few Open Source projects (one of them being DEV).

Since joining DEV, I've started to identify the seam that exists between the roles of "Software Engineer" and "Open Source Maintainer," where both spend a significant amount of time writing code and having technical discussions, the circumstances under which these people work is quite different. Therefore, the skills they need to succeed diverge at a certain point.

I've decided to write down a few of the points I've determined that these two "crafts" diverge from one another. While they are incredibly similar, and both roles can benefit from mastery over all of the skills I mention here, the allocation of effort across those skills is different. Where one might invest most of their energy into honing a set of technical skills, the other might invest in more holistic communication skills.

Like most of the things I say, there are probably a lot of cases in which I'm wrong, so read this article with a hefty helping of salt.

The tools of the craft

As a Software Engineer, one can expect to write new features and fix bugs while also spending some non-trivial amount of each day discussing the work they do. Occasionally, a traditional Software Engineer may also need to interact with the people who use their software.

In my experience Software Engineers need, at a minimum, intense curiosity and an uncommon drive to learn. However, being successful in the role takes a lot more than just a big mental appetite.

Software Engineers need to be skilled communicators, a considerable portion of the job revolves around being capable of contributing to technical conversations. In many cases, the most capable engineers are good at giving and receiving feedback concerning the projects they work on.

On some level, Software Engineers also need to be reasonably competent self-managers. Skills like time-boxing, project estimation, documentation, and prioritization are ubiquitous in the software field. Even when there are dedicated project managers and business analysts, engineers need to be capable of self-regulating, and the best engineers exhibit a certain level of autonomy when working on projects.

The discipline of Software Engineering is hard to encapsulate in a short article. Still, I'd argue that, at a minimum, those of us building software professionally need to have a grasp on these skills.

Open source maintainership

Some Software Engineers are lucky enough to work on Open Source full-time as contributors and maintainers. A few months ago, I became one of those lucky people when I joined the DEV team, but before that, I spent about a year as a maintainer of the Solidus ecommerce platform.

During that year, I learned a lot about what it takes to be a successful Open Source maintainer.

Much like other Software Engineers, an Open Source Maintainer typically spends quite a bit of time writing and reviewing code. Open Source Maintainers probably spend some of their time in meetings and discussions about the work they are doing. They also interact with the people who are using their software.

Generally speaking, there is a ton of cross-over in the responsibilities and day-to-day life of these two technical professions. So much so, that most people probably don't realize the distinct differences in each skillset.

Most people probably believe that an Open Source Maintainer is simply a specialized Software Engineer, sort of like people with the job title "Frontend Architect" or "Site Reliability Engineer." I think that, also, is generally true, but not universally.

From the time I've spent as a maintainer, I've learned that there is a non-technical aspect of maintainership that could arguably be more important than the software engineering skills that usually come into play: communication skills.

Every Software Engineer needs to be able to communicate, but only a few communicate on the level that is required of a quality Open Source Maintainer. If a Software Engineer needs to be a skilled communicator, a Maintainer needs to be a master.

A large portion of the daily responsibilities of maintainers is centered on that individual's ability to communicate with project stakeholders and users. For example, a maintainer might spend hours every day responding to issues, writing documentation, holding open forums, meeting with sponsors or stakeholders, and reviewing code (an ironically human-centric skill).

In fact, this ability to communicate is so important that there is a space in the Open Source world for non-technical maintainers who are simply world-class communicators. They can write approachable documentation, aide in organizing events, participate in marketing efforts, help people find the answers they need, and assist in the creation and moderation of issues.

This, of course, doesn't mean non-technical maintainers alleviate the need for technical maintainers who are masterful communicators. It just means that communication might be just as important (or more important) than technical skills for Maintainers.

Another deviation from the traditional Software Engineer toolkit arises when we start to think about larger Open Source projects. Open Source flourishes when a diverse community comes together to solve a shared problem. However, in a world where there is so much noise on the internet and even a significant variety in similar Open Source projects, it can be a struggle to build a community around a given project.

As a result, I'd argue that a good Maintainer has some grasp on marketing.

Before you scroll to the comments to tell me how Maintainers should be nothing like those evil marketers, understand that I'm using the word marketing to describe a set of tactics used to connect people with the best solution to their problem; nothing malicious, the opposite.

Adoption isn't the kind of problem that most Software Engineers have to solve in their profession. However, Open Source maintainers do have to think about the adoption levels in their project. Healthy projects should have some degree of adoption. That isn't to say a project should have massive adoption and a Hockey-stick growth curve. Instead, diverse communities and new contributors usually improve Open Source projects, so it makes sense that Maintainers worry about the adoption of their projects.

In turn, Maintainers need to know how to connect with people that would benefit from their projects and should have a good idea of how to onboard those people into their communities. The onboarding of new community members is a key factor in building a diversity of knowledge and experience, which should translate into better software, doing this well will result in the retention of those community members and a more "successful" Open Source project (in my opinion).

The caveat being that growth for growth's sake is actually destructive because a project attempting to force growth will ultimately attract those people who are not best served by the project resulting in a derailing of the project's purpose.

Connecting with people that benefit from your project is marketing.

There is another skill that I think encompasses many of the ones I've mentioned here, but I think it is worth calling out by name: community building.

I think community building might be one of the best ways to describe all of the things that a great Open Source Maintainer has to do on top of being technically skillful.

Community building is all those things great projects do: organizing events, building culture, being inclusive, and hearing the thoughts of others. Ultimately, it comes down to providing a platform to communicate with those people who've invested in the project with their time, money, and mind.

Developing the skill of community building is hard. I've only experienced growth in this arena by learning on the job: running meetups, conferences, and seeking out opportunities to interact with communities (e.g., my podcast and the articles I write).

While there are infinitely more skills that can complement these skills, I've found that a solid understanding of these "more human" skills is crucial to becoming a top-shelf Open Source Maintainer.

In a nutshell

I certainly wouldn't say this is a comprehensive guide to the skills that either Software Engineers or Open Source Maintainers need to be successful, but these are things that have stuck out to me over the last year.

Ideally, this article clarifies something for people who are interested in the practice of maintainership, but I'm sure there are some disagreements and questions that will arise from my opinions. I'd love to talk more about that in the comments or a private message, so please share your thoughts on the distinction between Software Engineering and Open Source Maintainership.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

Setting Up a Svelte Project (in seconds) with Degit

Jacob Herrington (he/him) — Sun, 20 Oct 2019 19:04:01 +0000

Getting started with Svelte can be a little bit intimidating for JavaScript developers familiar with one of the more mainstream front-end frameworks.

Thankfully, Rich Harris (who started Svelte) wrote a useful scaffolding tool called degit. The premise of degit is extremely simple by design -- it copies existing git repositories.

All you need to do is install degit with your preferred package manager:

npm install -g degit

Then, you can use the tool to create copies of a git repository (you can specify if you want to use BitBucket or GitLab, but it defaults to GitHub repositories):

npx degit user/repo-name target-directory

As it happens, Rich set up a template for Svelte projects that should be used with degit. To get up and going with a Svelte project all you need to do is run:

npx degit sveltejs/template my-svelte-project

This will set you up with a copy of the official Svelte template in a new directory called my-svelte-project. It's important to note, your copy will not be a git repository, if you plan to use git for version control, you'll have to run git init.

So what does the Svelte template set you up with?

The template's dependencies are pretty lightweight. Basically, you're getting Svelte, Rollup, sirv-cli, and with a few simple scripts to make development easier.

The basic structure is also super simple; you're given a src directory for your Svelte code and a public directory where your compiled code will be output.

Here is a list of the scripts you end up with:

"build": "rollup -c",
"autobuild": "rollup -c -w",
"dev": "run-p start:dev autobuild",
"start": "sirv public --single",
"start:dev": "sirv public --single --dev"

So, in this case, running npm run build will compile the Svelte code in your src folder, you can set the project to automatically compile on save with npm run autobuild. You can save time by running npm run dev, which will kick off a server for you and automatically compile your code when you make changes.

I'll run through an example, to illustrate exactly how easy it is to make a new Svelte project.

npm install -g degit # install degit
npx degit sveltejs/template my-svelte-project # copy the Svelte template

cd my-svelte-project
npm install # install dependencies

npm run dev # kick off a server and auto-compile

Now I can navigate to localhost:5000 and I'm greeted by a simple Hello world! Any change to a Svelte file will result in a compilation step and be autoloaded by my browser.

There's more...

I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter digest about all of the awesome stories I'm hearing.

You can also follow me on Twitter, where I make silly memes and talk about being a developer.

Interview with Molly Struve: 3 Tactics for Mentoring Others

Jacob Herrington (he/him) — Fri, 18 Oct 2019 16:26:30 +0000

In August, I met a ton of gifted engineers. Among those Engineers was Molly Struve, a Lead Site Reliability Engineer who has been building an SRE team around herself for the last year or two.

Lead Site Reliability Engineer Molly Struve

devpath.fm

Your browser does not support the audio element.

1x initializing... ×

During that journey, Molly has learned a thing or two about mentoring other engineers, and she shared some of her experiences and advice during our discussion.

These are some of the tactics she has used:

1. Use your resources

Part of mentorship is creating a voice for yourself and sharing your knowledge.

Molly talked about her experiences speaking and writing for other people. She mentioned the benefits of getting involved in the community, but she also mentioned her realization that speaking would result in being able to help a significant number of people.

While she was learning to share with the community, she had acquaintances and mentors of her own; they helped her to become a better mentor herself. Leaning on people like this is a way to invest in your mentorship skills.

When you are in a mentorship or leadership position, it becomes imperative to take advantage of your resources. You'll need to find mentors and leaders of your own to guide you as you grow in your role.

Finding mentorship for yourself is a step that is frequently missed when becoming a better mentor yourself.

2. Practice empathy

In my opinion, there is no more valuable skill for a great mentor than empathy.

I call it a skill because I believe you should practice empathy. Practicing empathy is continually working to develop your ability to see the world from another person's perspective.

Molly talks about empathy during our conversation. Empathy is an important component of her mentorship strategy.

She mentioned that it's challenging to remember what it was like to be a newcomer to the tech industry. Learning to step into the mind space of your junior colleagues is one of the most important skills to master as a mentor.

We talked about the idea of unconscious competence and how breaking your knowledge down into things that you can teach is a great way to recognize the experience that you've taken for granted. This has the two-fold benefitting of helping you to be a good mentor and solidifying your knowledge.

3. Share your mistakes

Molly told me about this awesome idea. She does something called "Lunch with Leads," where a lead engineer (like Molly) takes a more junior person out to lunch.

Interestingly, as a part of this practice, Molly likes to share an example of something she did wrong.

I get frustrated with the idea of hero-worship in the software engineering industry, and it's something we can walk into by accident. If you don't share the things you struggle with, then it's pretty difficult for junior colleagues to realize that you also make mistakes.

So, Molly's example of talking about her mistakes openly and keeping herself off of that pedestal is super healthy and something that I'll make an effort to be better about going forward.

If you're interested in learning from veteran engineers like Molly, subscribe to my newsletter and follow along with the podcast. I have upcoming interviews with engineers all around the world who have built amazing careers for themselves.