Copilot offers a variety of AI tools that have radically streamlined my experience as a software developer. I've used it to generate code, tests, and even simple applications. It's also great for debugging, refactoring, and documenting existing code.

Weirdly, using Copilot has caused me to develop features faster than business stakeholders can review them.

It's important to note that AI tools, including Copilot, can be blatantly wrong, apologize (or not) when corrected, and then confidently produce the same error. But as long as you're aware of the downsides of AI tools, and have enough coding knowledge to recognize when they're incorrect, you can mitigate them on the path to substantially improved productivity.

How to Setup GitHub Copilot

For setup and basic usage of Copilot, check out the docs. You can add on Copilot to an individual or business account, and there's a free trial and reasonable pricing after the trial.

After adding Copilot to your GitHub account, you'll want to install the plugins for your IDE and log into GitHub to access Copilot.

In this article, we'll use these Visual Studio Code extensions:

Notes:

1. This info is up-to-date as the writing of this article, but will likely change as GitHub evolves these products.
2. I haven't yet received access to Copilot Voice or Copilot (X) for Pull Requests, so my perspective on these are limited and based on GitHub's preview docs.

Privacy

Before jumping into some key use cases for Copilot, a quick note on privacy: Basically, if you trust GitHub to host your source code, you can likely trust what they do with your Copilot prompts and code snippets. [See their FAQ docs and Privacy Statement.]

Use Cases for GitHub Copilot

The uses cases for GitHub Copilot are numerous, especially when you add in the preview features of Labs, Chat, and Voice. Using Copilot's features can really streamline the development process.

Here are some great ways to leverage Copilot extensions:

Code Generation

Copilot is known for its code completion features. If it's given a comment in the code or you type the beginnings of a line of code, Copilot will suggest a solution that you can accept, ignore, or explore alternatives. It's referred to as "ghost text".

Once you have the Copilot extension installed and you're logged in, code completion is as simple as typing instructions and hitting the Tab key once the suggestion comes up.

A comment prompt in Ruby that Copilot uses to create a method and invocation

Taking code completion one step further, Copilot Chat can take a single prompt and generate instructions for building an entire application.

I asked it to create a REST API in Node with CRUD functions for "products", and it generated functional code. Impressive overall. Given the same prompt, ChatGPT also gave me instructions for how to run the code, which was nice.

Copilot Voice can also write or edit code based on voice commands. Most of the time, using the keyboard with Copilot code completion is faster than dictating lines of code with Voice. But it's compelling to think about using Copilot Voice to create and run code without having to type or stare at a screen.

Explaining Code

I often have to stare at a screen to figure out what a block of code is doing. Sometimes it's legacy code where I don't understand the business context. Sometimes it's using a particular library I'm not used to. Sometimes I curse the person who wrote it, even if it's me.

Below is some code generated by Copilot Chat from my "REST API in Node..." prompt from above:

app.get('/products/:id', (req, res) => {
  const id = req.params.id;
  const product = products.find((p) => p.id === id);
  if (product) {
    res.json(product);
  } else {
    res.status(404).json({ error: 'Product not found' });
  }
});

I took this code and fed it into the "Explain" feature in Copilot Labs. Here's the response...

Here is the explanation for the code above:

1. We define a route with the route path /products/:id. The colon : in the path indicates that it is a route parameter. The value of the route parameter will be available in req.params. For example, if the route path is /products/:id and we make a request to /products/5, then the value of req.params will be { id: 5 }.
2. We get the id from req.params and find the product with the given id from the products array. If a product with the given id exists, we return it. Otherwise, we send a 404 error response with the error message Product not found.

This is a pretty straightforward segment of code, and the response is clear and straightforward as well. It would be easy to add this as documentation in a code comment above the function.

Another good example is regular expressions. I understand how regular expressions work but I don't often have the patience to figure out what a particular regex is doing. I fed Copilot Chat this giant regex statement for email validation:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

It explained the regex at a high level, indicating it was broken into the local and domain parts, representing before and after the "@" sign in an email address. Then it described allowable characters in each part. Quite helpful.

Language Translation

Developers are often required to quickly learn new languages and frameworks. Copilot Labs and Chat make this pretty easy. Here's an array of products in JavaScript and Ruby that was converted by Copilot:

let products = [
  { id: '1', name: 'Product 1', price: 10.99 },
  { id: '2', name: 'Product 2', price: 19.99 },
  { id: '3', name: 'Product 3', price: 7.99 }
];

products = [
  { id: '1', name: 'Product 1', price: 10.99 },
  { id: '2', name: 'Product 2', price: 19.99 },
  { id: '3', name: 'Product 3', price: 7.99 }
]

This is a very simple example, so let's try making this into a class and going the other way (from Ruby to JavaScript):

class Product
  attr_reader :name, :price

  def initialize(name, price)
    @name = name
    @price = price
  end
end

class Product {
  constructor(name, price) {
    this.name = name;
    this.price = price;
  }
}

This checks out. For good measure, I tested TypeScript as well, and it worked perfectly, too.

Debugging

This is a very handy feature. You can give Copilot Chat or Labs problematic code or error messages and it will indicate what it thinks the issue is.

Copilot Labs "Fix Bug" Brush Feature

I can't tell you how many hairs I've pulled out because I couldn't find what amounted to a syntax error. Copilot's ability to fix bugs just makes me happier and hairier.

You can also give Copilot Chat an error message with no other prompt and it can tell you the issue. I arbitrarily removed a dot from the Node REST API code:

products[productIndex] = { id, ..req.body };

I copied/pasted the error message in Chat, and it responded with...

Looking at the code excerpt you provided, it seems that the issue is on line 49 where there is a syntax error in the object literal. The ".." before req.body is causing the error. It should be just one dot instead of two.

This is both correct (the line and source of the error) and incorrect (that it should be only one dot). It then gave me a code snippet with three dots, which is also correct.

As I mentioned at the outset, you've gotta double-check AI's work. Still, I'm impressed by Copilot's ability to parse an error message, describe what it thinks is wrong, and suggest a fix.

Refactoring

Another great use case is refactoring. Consider the code below:

def price_with_discount
  price - (price * discount_rate)
end

This simple price calculation doesn't factor in nil values, strings that should be numbers, or reasonable values for price or discount_rate. We need the code to do this:

1. Ensure price is an integer or float (not nil)
2. Ensure price is not negative
3. Ensure discount_rate is a float (not nil)
4. Ensure discount_rate is not negative and less than or equal to 1

Copilot Chat handles this with ease...

def price_with_discount(price, discount_rate)
  raise ArgumentError, "Price must be a positive number" unless price.is_a?(Numeric) && price >= 0
  raise ArgumentError, "Discount rate must be a float between 0 and 1" unless discount_rate.is_a?(Float) && discount_rate >= 0 && discount_rate <= 1

  price - (price * discount_rate)
end

Test Generation

Using Copilot to generate tests is technically a subset of "Code Generation" above, but I felt it was so useful it warranted its own mention.

Generating unit tests for code can be tedious if you're trying to cover happy and sad paths, primary use cases and edge cases. Our price_with_discount code above needs test cases to ensure an error is raised if price or discount_rate don't meet the requirements. In addition, we might want to test the following:

1. A price without a discount_rate
2. A price with a reasonable discount_rate (for example, a 10% discount)
3. A price with a 100% discount_rate (for example, if we want to give the product away)

With these and our previous error cases, here's what Copilot Chat generated, after a little fine-tuning (re-prompting) and switching from Minitest to Rspec.

RSpec.describe Product do
  describe "#price_with_discount" do
    context "when given a valid price and discount rate" do
      it "returns the price with the discount applied" do
        product = Product.new("Test Product", 100, 0.2)
        expect(product.price_with_discount(product.price, product.discount_rate)).to eq(80)
      end
    end

    context "when given a nil price" do
      it "raises an ArgumentError with an appropriate message" do
        product = Product.new("Test Product", nil, 0.2)
        expect { product.price_with_discount(product.price, product.discount_rate) }.to raise_error(ArgumentError, "Price must be a positive number")
      end
    end

    context "when given a price less than 0" do
      it "raises an ArgumentError with an appropriate message" do
        product = Product.new("Test Product", -100, 0.2)
        expect { product.price_with_discount(product.price, product.discount_rate) }.to raise_error(ArgumentError, "Price must be a positive number")
      end
    end

    context "when given a nil discount rate" do
      it "raises an ArgumentError with an appropriate message" do
        product = Product.new("Test Product", 100, nil)
        expect { product.price_with_discount(product.price, product.discount_rate) }.to raise_error(ArgumentError, "Discount rate must be a float between 0 and 1")
      end
    end

    context "when given a discount rate less than 0" do
      it "raises an ArgumentError with an appropriate message" do
        product = Product.new("Test Product", 100, -0.2)
        expect { product.price_with_discount(product.price, product.discount_rate) }.to raise_error(ArgumentError, "Discount rate must be a float between 0 and 1")
      end
    end

    context "when given a discount rate greater than 1" do
      it "raises an ArgumentError with an appropriate message" do
        product = Product.new("Test Product", 100, 1.5)
        expect { product.price_with_discount(product.price, product.discount_rate) }.to raise_error(ArgumentError, "Discount rate must be a float between 0 and 1")
      end
    end
  end
end

One test for valid input, five for invalid input. All six work, and I didn't have to write them!

Code Reviews

One feature of Copilot X is Copilot for Pull Requests. Here are some of the key features:

• Template Expansion – Leverage Copilot to fill in your PR template and explain code
• Gentest – Generate tests for your code based on Copilot's analysis
• Ghost Text – Receive suggestions while you're typing in the PR

Voice-Driven Development

Formerly known as "Hey, Github!", Copilot Voice allows you to use natural language prompts to interact with your code. It looks impressive, boasting these capabilities:

• Write/Edit Code – Use voice controls to trigger Copilot code suggestions
• Code Navigation – Navigate a file without a keyboard or mouse
• Control the IDE – Trigger any VS Code command
• Code Summarization – Get summaries of blocks of code

Summary

GitHub is rapidly producing revolutionary developer productivity tools with its suite of Copilot extensions. It's increasing my joy in programming and decreasing my time spent on mind-numbing tasks. I would encourage you to keep track of enhancements to Copilot as they're happening quickly.

Ignore click-bait promises of a "10x productivity gain", but don't ignore the research of Copilot's impact on developer productivity and happiness.

Spend some time with Copilot tools trying out the use cases above, and I think you'll be surprised by its effect on your productivity and happiness.

Modern life throws a lot at us. We often find ourself struggling to manage anxiety, wrangle responsibilities, adapt to new conditions, and maintain a happy state of mind.

But happiness is a noisy space these days. Self help books, articles, blogs, and meditation apps can’t help everyone, and often increase the mental burden needed to stay content. That’s a serious problem. So, as mental health becomes increasingly vulnerable and solutions become increasingly complex, it’s important to anchor oneself to the fundamentals. That is, we need to refocus our daily lives on the everyday things that make people happy.

Data

This research dives into a handy dataset that can help shed some light on the fundamentals of happiness. HappyDB is a set of 100,000+ happy experiences gathered through Amazon Mechanical Turk from March to June of 2017. It contains the experiences and demographics from tens of thousands of contributors around the world. Interestingly, some basic text analysis methods can help us learn a lot from this data.

By understanding the emotional intensity and keyword patterns drawn from these happy experiences, HappyDB teaches us two valuable lessons.

You can check out the code for yourself on GitHub.

1. Happiness is not conditional on demographics.

This one is counterintuitive.

Most of us experience a “grass is always greener” effect with respect to happiness. Young people anticipate a happy career and family later on in life. Older folks reminisce about a time when they were young and adventurous. Bachelors yearn for companionship. Couples hope for children.

And, despite knowing this, we all think someone else is happier, or some other stage of our life will bring us more joy. Let’s take a look at the data.

Sentiment analysis weighs the emotional intensity of text. Using an R package called “Syuzhet,” I measured the sentiment of these happy experiences to determine how their intensities vary. This created a spectrum of happy experiences that could be broken down by specific demographic groups:

Sentiment of Happy Experiences (by gender, family status)

Sentiment of Happy Experiences (by age group)

Somewhat surprisingly, there’s little change in the spread of happy experiences across these gender, family, and age demographic groups. Here are the highlights:

• Overall, the experiences are definitely positive. But the bottom quartile does have negative sentiment (some happy things poetically arise from discomfort and tragedy)
• The distributions have high-end tails and fairly limited lower bounds — some experiences are extremely positive, and few are strikingly negative
• Self-identifying females have slightly higher sentiment scores than men for most of their experiences (a 0.05–0.1 point difference)
• Married parents have slightly higher sentiment scores than bachelors and childless couples for most of their experiences (a 0.05–0.1 point difference)
• The quartiles of happy experiences (25th, 50th, and 75th percentiles) across age groups are virtually identical

In sum, there is no significant difference in the range of happy experiences reported by different demographics. Although women and parents tend to have marginally more happy experiences to record, the differences on the sentiment scale can’t be taken seriously — they correspond to a fraction of a fraction of a single happy word per experience recorded. That’s a minuscule difference.

This dataset, however, does not include any data fields for race, socioeconomic status, or other identity positions that may materially influence daily experiences. Future happiness research should inspect these relationships closely.

2. Happiness is determined by specific types of experiences.

It’s easy to think of happiness as a mysterious, ethereal substance that penetrates our experiences in uninterpretable ways. This view espouses a metaphysical understanding of happiness as something beyond human comprehension.

But that’s not very helpful, especially for people who rely on happy and meaningful experiences as the lifeline of their mental health.

Enter Topic Modeling. This method of text analysis (explained here; I use R’s “Mallet” package) provides a constructive approach to explaining what HappyDB’s 10,000+ participants find to be happy experiences.

By segmenting the dataset into documents of each respondent’s experiences, then running an LDA topic model to identify groups of commonly occurring keywords, we can begin to isolate distinct types of experiences that bring us happiness. The topics and related keywords can be seen below, in no particular order:

Topic Model Output from 100,922 Happy Experiences

Time with Family

Seems like a no-brainer. Words like “daughter,” “son,” “husband,” “baby,” “wife,” and “time” seem to show that lots of people reflect very positively on experiences that involve their loved ones. These experiences often involve the most commonplace of settings and derive happiness simply from company and affection.

Try spending more time with loved ones: call your mom, go to your kid’s soccer game. It may pay off more than you think.

Getting Paid

Although people don’t like thinking that money relates to happiness, their experiences sure say the opposite. Getting a paycheck, clearing a credit card balance, or giving money to a friend can make people really happy. And the sense of accomplishment and economic security that comes with would definitely explain why.

Food

People love eating. Cooking a favorite meal, eating out with friends, or gorging on a pint of iced cream in front of the TV can all make someone happy. Good food with friends should definitely play a part in any happy lifestyle.

Sleep Time

Surprisingly, people document lots of happy experiences around sleep: cuddling up in bed, going to sleep with a furry friend, waking up to a promising new day, and so on. There’s lots to be happy about, if one takes a moment to reflect at night after a productive day, or in the motivated morning before something exciting.

Games and Competition

Humans are competitive. They love playing video games, watching sports, and doing other things that stoke their biological instinct to dominate. Play a board game with some friends or get excited about your home sports team. Chances are you’ll be happy you did.

Achievement and Education

After weeks of work, it feels great to finish big enterprises. Finishing a class, graduating from school, or launching a project can all seriously lift a person’s mood. But finishing big undertakings requires a few to start, so go out and start something new! Learning and doing are rewarded handsomely.

Celebrating and Birthdays

Obviously, celebrations make people happy (think birthdays, anniversaries, and friendsgivings). People enjoy finding a reason — however important or silly — to meet up with loved ones, get happy about an occasion, and do something to break up a dull weekly routine.

Mental Balance and Introspection

The act of tuning into one’s mental state seems to provide a lot of happiness in and of itself. Thinking introspectively about one’s wellbeing, head space, and happiness seem to have positive effects on those very things! Try meditating, reflecting on happy experiences, or just being aware of your mental state — it may be the very thing to help boost it.

Spending

Satisfying our material desires, of course, brings lots of people happiness. Finding good deals, finally buying that car or home, and getting something nice for oneself or a loved one all create some sort of happiness. Enjoy responsibly.

Weekend Trips

People like being off work, but enjoy it dramatically more if enjoyed in good company, while doing something different. Go on a trip somewhere, have an outing nearby, or find another novel excuse for spending time with others in new scenery. The data says you certainly won’t regret it.

Reading and Music

Whether bundling up at home with a new book or discovering a song on the bus ride home, lots of people get happy through the simple act of reading or listening. Taking an hour before bed to read something new or skim through Discover Weekly is probably worth the time investment.

Decisions

Decisions also clock in as a big happiness generating activity. It’s exciting to spend time thinking about a big change, decide to do something new, and tell people about it. It leaves a lingering mood boost for lots of folks, too. So make a change you’ve been meaning to for a while; and commit to it!

Wrapping up

These twelve categories of experience represent the foundations of daily happiness for tens of thousands of people. Given that humans are more alike than we often give them credit for, the same can likely be said about you.

This method, like any, is imperfect. Some demographics contribute more heavily than others, which may throw curious words into some topics, or may bias the topics that are represented in the model. Textual data is messy and people also don’t think about happiness in crisply defined categories of experience.

But, using these two lessons as a basic structure for understanding positivity in our everyday lives, I think it can help remind us that happiness is never so far off as we may think.

We already know many of these happy topics to be true on some level. But we rarely recognize the power that they have on our mood, and so don’t structure them into our everyday lives as readily as we should.

These categories are empirically-certified mood boosters. They’re happiness slam dunks.

So we should take what we can get. Throw out the self-help handbooks and focus on real happy experiences. You may like what you find.

If you found this article helpful, share it with a friend or give some claps ?.

See the code for yourself on GitHub!

“And it only takes a minute, dude. Sometimes I do it when I’m using the bathroom.”

It was December 2014, and I was at dinner in Santa Cruz with one of my best friends. I can’t remember why, but somehow we were on the topic of “routines” and he was telling me about a daily journal he’d been keeping.

“It’s simple — I just write down at least one dope thing that happens every day.”

When he suggested I try it, I was immediately skeptical. I’d always categorized journaling as one of those “it’s-probably-good-for-me-but-realistically-I’m-not-going-to-keep-it-up” ideas (See “flossing”, “meditation”, and “watching only one episode of The Office at a time”).

But after hearing how much he’d genuinely enjoyed doing it — and more importantly, how easy it was to do — I thought I’d give it a shot. I can now proudly say that, after a little more than two years, I haven’t missed a single day.

What I’m more excited to share, however, is what I’ve found by digging into all of the entries. (Note I’m a former statistics teacher who had way too much free time in India last month.)

Below are three things I learned from the process and my analysis.

Takeaway #1: It’s actually pretty easy to do

I was initially worried about staying consistent, since my track record for maintaining habits is laughably poor. But taking my friend’s advice, I used free moments in the day to make my daily entries: during my commute, on my way back from the gym, or on the porcelain think tank.

Originally, I kept my entries in an Evernote doc, but eventually the file got too large and slowed my phone down. I switched to Day One, which is a beautiful app for daily journaling that allows you to tag entries, add photos, and even set daily reminders so you don’t forget.

(Left): Original two-column table in Evernote. (Right): Example entry in DayOne

I won’t lie, I’d often miss an entire week’s worth of entries and would have to go back later to make it up, which was a pain. But when I’d forget what had happened on a particular day, I’d just look through texts or emails from that day to jog my memory. Even if the post was something as simple as “that amazing pasta with the spicy meatballs,” I didn’t mind — I just wanted to make sure I was making an entry.

Takeaway #2: You have more good days than you think

Not only was it great to scroll through all of these positive entries on a bad day and think “cool, life is not as terrible as it seems today,” but I also used a feature in Day One to “star” days that I thought were especially fantastic. This allowed me to do two things:

1. I calculated how often I had a “kick-ass” day (a.k.a “starred” entry)

I had 211 “kick-ass” days out of 736 total entries…

So basically I now have two years’ worth of evidence to confidently say “at least two days this week will be pretty dope.” Of course, it’s subjective in that it depends on my definition of a “kick-ass” day (see below), but since I’m predicting for my own life anyways, that bias is less relevant.

b) I could understand why these days were indeed “kick-ass”

I exported all of the entries into a spreadsheet and manually tagged each day — yeah, it was totally exhausting — with the specific reasons why that day was “kick-ass.”

Below are the 10 most common reasons:

And for those of you wondering what counts as a “special activity,” here are a few examples:

Takeaway #3: Journaling is more than just “a good habit”

I mentioned earlier that it’s great to “scroll through happiness” on a rainy day, but I’d already expected that benefit when I started.

What I didn’t expect was an improvement in my memory. By virtue of writing down and rereading details, I could easily answer questions like “hey, what was that restaurant we went to over the summer?” or “There was someone I met recently who knows a lot about X,Y,Z. Who was that again?”

I also didn’t expect my journal to give me prescriptive information. I already knew that “meaningful conversations” and “laughter” make for pretty good days, but it’s great to have concrete data to remind me what I should be doing more of (like calling the family in India or planning more weekend trips).

Many of us already spend hours in spreadsheets for our employers, and some of us meticulously track data on our physical health. Why don’t we do the same for our happiness?

I think that’s the kind of “data driven decision-making” that doesn’t get enough attention.

Conclusion

In retrospect, I think the main reasons why I’ve been able to maintain this habit more sustainably than any other is that it had immediate and visible benefits in a very short period of time and gave me a tangible record of my progress to analyze.

That said, I do want to be clear that the point of journaling was NOT the analysis; it took me 10 hours to dissect all of this data, and had that been the end goal when I started, I never would have done it in the first place. (Though it was definitely fun to make this infographic — thanks, Infogram).

The real motivation was way simpler: just chronicle as many great memories as possible because, frankly, it’ll be great to read them every now and then. And that was true :)

I want to thank you for reading this and would love to hear your feedback, your ideas, and your own findings if you’re doing / will do something similar.