In Our Last Issue...

In our previous issue, we met Dawson Webhart, a junior frontend software engineer at a fashion tech company. We learned that Dawson's company wants to adopt Web5, a new technology that ensures users can control their privacy and data portability. Nadia, Dawson's bestie at work and in real life, hopes they lead the company's shift to Web5. Dawson also faced a personal setback when her favorite social media app took Dawson's username without her consent. These challenges piqued Dawson's interest in Web5, driving her to seek control over her digital presence.

Artist credit: scribblndibbl

Meet Dawson's boyfriend

When she gets home from work, Dawson pops a bag of popcorn and sits by the kitchen island, recapping her day with her boyfriend, Justin. As opposed to Dawson’s carefree and forgetful nature, Justin is prepared and meticulous, traits instilled by his immigrant parents. A physical trainer by profession, Justin's interest in the latest technological trends makes him the ideal sounding board for Dawson’s adventures.

Artist credit: scribblndibbl

“Dude, I can’t believe Francis Francino stole my handle. I’m never using that app again,” Dawson spills about her day, disbelief and frustration coloring her tone.

Justin nods empathetically, "It’s crazy how much of our data we don’t actually own on the internet, like your username situation. JungleGym games, the video game company, announced they're removing our access to certain games that no longer have tech support. It's ridiculous. If I had a physical copy, they couldn't just take it back. Makes me wish we could carry our digital purchases across different platforms."

Dawson lights up, "That's exactly what Nadia was saying about Web5—taking your data wherever you go. That’s why I’m thinking of really diving into it."

Justin shifts gears with a playful nudge, "Word, I support it. I also support you packing your bags for our weekend friend trip to Orlando. Our flight is tonight. Don't forget."

Caught off guard and trying to hide her forgetfulness, Dawson rushes upstairs to pack. “Psh, I did not forget! I just wanted to tell you about my day.”

She hastily packs, muttering under her breath about the number of outfits and shoes needed for a 2-day trip. And of course, she can’t forget her laptop.

Artist credit: scribblndibbl

A New Way to Travel

As they drive to the airport, Dawson runs through a checklist with Justin to ensure they haven't forgotten anything.

Artist credit: scribblndibbl

"Suitcase, carry-on, keys, debit card, and ID?" she inquires, ticking off each item.

"I left my ID at home. It's all on my phone now, remember? Nadia filled us in on Digital Travel Credentials. They are the next big thing in identity verification," Justin explains.

When they stop at a red light, Justin briefly pulls out his phone to show Dawson his Digital Travel Credentials.

Artist credit: scribblndibbl

“All I have to do is show this to the TSA and they will let me through,” he explains. Dawson shrugs. She was unimpressed and preferred the traditional method – her physical passport.

Artist credit: scribblndibbl

Dawson and Justin meet up with their friends, including Nadia and Nadia’s partner, at the airport. Everyone but Dawson swiftly passes through the Digital Travel Credentials (DTC) lane by showing their Verifiable Credential and tapping their phones on a card reader.

Artist credit: scribblndibbl

“Sorry, girl. You should’ve gotten your digital credentials like I mentioned in the group chat,” Nadia remarks as Dawson heads to the standard line.

Dawson sighs. The standard line is SO long, but then she remembers her CLEAR subscription, a speedier alternative. Her friends aren't the only smart ones, she chuckles to herself.

In the CLEAR queue, Dawson's turn comes quickly. She scans her eyes and smirks, appreciating the smooth process—no extra downloads or purchases necessary, contrary to her friends' approach. Then, a CLEAR employee halts her progress.

“Ma’am, you've been selected for random ID verification.”

Dawson rummages through her bag for her passport. Handing it over, the employee casually notes, “Oh, we share the same birthday! And you’re from the beautiful island of—”

“Yeah..can we just —,“ Dawson strains a smile, but she was cringing on the inside. She wanted to keep up with her friends, and she was disturbed by the unnecessary sharing of her personal details.

The Growing Popularity of Verifiable Credentials

Dawson reunites with her friends at the gate, venting about the invasive CLEAR employee. "You should report that," Nadia advises. "Next trip, get a Digital Travel Credential. The TSA didn't need to see my birth date or anything."

Nadia's enthusiasm grows as she elaborates on her motivation. "I pushed for everyone to try Digital Travel Credentials because I wanted to test them myself. They're a type of Verifiable Credential. Web5, the technology we're adopting at work, has a Software Development Kit to create credentials. Also, Verifiable Credentials are increasing in popularity. Companies like Microsoft, Auth0 by Okta, and Workday are all experimenting with Verifiable Credentials."

The Experiment

On the plane, Dawson immediately opens her laptop and connects to the in-flight wifi to learn about Verifiable Credentials.

Artist credit: scribblndibbl

What are Verifiable Credentials?

Verifiable Credentials (VCs) are digital proofs that confirm certain facts about individuals, organizations, or entities. They can look like digital badges. VCs are stored securely in your smartphone's wallet app—similar to a debit card in Apple Wallet or a gym membership in Google Wallet. At their core, VCs are protected by cryptography, specifically through a JSON Web Token (JWT), ensuring their authenticity and integrity.

Image credit: Auth0 Lab's Verifiable Credential Proof of Concept Designs

Flexible Use Cases of Verifiable Credentials

Let's say you need to prove you're of legal drinking age without revealing excess personal data. Instead of showing your full ID, you could present a VC to a vendor. The vendor recognizes the credential as proof of age and provides you with alcohol in exchange.

Similarly, Dawson's friends used Digital Travel Credentials to prove they were eligible to board their flight.

VCs can represent virtually any claim or certification, including but not limited to:

• Educational achievements

• Employment history

• Membership in clubs or organizations

• Authenticity and accuracy of content

• Online identity verification

• Trustworthiness as a seller or business partner

• Financial standing, including creditworthiness or proof of income, useful for loan applications. See: FormFree, a company using Web5's Verifiable Credentials to empower borrower's during the loan process.

Key Roles in the Verifiable Credential Process

There are typically three to four key players through the Verifiable Credential exchange process:

1. Issuer: is a trusted organization, entity, or individual who created the verifiable credential and signed the credential stating the information is true.

2. Subject: This is the organization, entity, or individual who the Verifiable Credential is about. They will store the verifiable credential in their phone's wallet and present it to the verifier.

3. Verifier: This is the entity requesting proof. This entity evaluates the VC's validity and the issuer's credibility before granting access or services.

4. Holder: Sometimes, a designated entity holds and presents the VC on the subject's behalf. Although, many times, the subject and the holder are the same.

The Flow

1. The issuer creates a VC with claims about the subject.

2. The issuer cryptographically signs the credential stating that the claims about the subject are true.

3. The subject stores the VC in their phone’s wallet.

4. The subject (or holder) presents their Verifiable Credential to a verifier.

5. The verifier runs a series of checks to determine if the VC is real and valid. They also determine if the issuer is real and trustworthy.

What Does 'Cryptographically Signed' Mean?

I think of cryptography as using code to create a digital lock that protects information. When we say something is "cryptographically signed," it indicates that an item has been marked with a unique digital fingerprint. This is similar to back in the day when a king would seal a decree with a ring.

An algorithm generates the signature, ensuring it's unique to the document and the person who signed it. The digital fingerprint is composed of a private key and a public key. While your private key is kept a secret, your public key is shared with others to verify that the signature was made with your private key and the document hasn't been tampered with.

Together, these keys perform a dual function: they confirm the authenticity of the document and its signer AND maintain the integrity of the document by detecting any alterations post-signature.

Tutorial: Create a VC in JavaScript

Dawson wants to try creating a Legal Drinking Age Verifiable credential to help her apply the concepts she learned.

Package dependencies

Dawson starts by installing and importing the packages needed to create a Verifiable Credential with Web5.

She runs the following command:

npm install @web5/credentials @web5/dids

She creates a file called verifiable-creds.js and imports the packages in that file:

import { DidDht } from '@web5/dids';
import { VerifiableCredential, PresentationExchange } from '@web5/credentials';

Creating the issuer and the subject

Each participant in the Verifiable Credential process is linked to a Decentralized Identifier (DID), a W3C-standard alphanumeric string that serves as a unique identifier for individuals, organizations, or entities.

Dawson thinks the Department of Motor Vehicles or the Passport Office could be potential Legal Drinking Age Credential issuers. For learning purposes, she creates a DID to simulate an issuer similar to the Department of Motor Vehicles, naming it "Fake Department of Motor Vehicles" or "FakeDMV."

const fakeDmvIssuerDid = await DidDht.create();

Subsequently, Dawson generates her own DID to act as the subject of the credential.

const dawsonDid = await DidDht.create();

Inspect the DID

Dawson examines her DID's details:

console.log(dawsonDid)

She observes the DID document, particularly the DID string and public key:

console.log(`this is the DID string ${dawsonDid.uri}`)
console.log(`this is the DID’s public key information ${dawsonDid.document.verificationMethod}`)

Creating the credential

class LegalDrinkingAgeCredential {
    constructor(name, dateOfBirth, isOfLegalDrinkingAge, city, country) {
        this.name = name;
        this.dateOfBirth = dateOfBirth;
        this.isOfLegalDrinkingAge = isOfLegalDrinkingAge;
        this.city = city;
        this.country = country;
    }
}

const vc = await VerifiableCredential.create({
    type: 'LegalDrinkingAgeCredential',
    issuer: fakeDmvIssuerDid.uri,
    subject: fakeDmvIssuerDid.uri,
    data: new LegalDrinkingAgeCredential('Your Name', 'Your Date of Birth', true, 'Your City', 'Your Country') 
});

Signing the credential

The "Fake DMV" signs the credential with their DID:

const signedVC = await vc.sign({ did: fakeDmvIssuerDid });

Inspect the Signed VC

Dawson prints out the signed verifiable credential, and she finds that the verifiable credential is now an odd alphanumeric string.

eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsImtpZCI6ImRpZDpkaHQ6MWZmd25mNHduZW94cng5M2ZzYTF4NHA3eDg3Y210ZHJicWtkMXcxeTF4bmNtN2FrcWRleSMwIn0.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiTGVnYWxEcmlua2luZ0FnZUNyZWRlbnRpYWwiXSwiaWQiOiJ1cm46dXVpZDo5ZGZhYjcyMS0xY2IwLTRmNDYtOTgxZi05YjhjZDZkY2E1NzUiLCJpc3N1ZXIiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkiLCJpc3N1YW5jZURhdGUiOiIyMDI0LTAzLTA2VDA0OjExOjA2WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmRodDoxZmZ3bmY0d25lb3hyeDkzZnNhMXg0cDd4ODdjbXRkcmJxa2QxdzF5MXhuY203YWtxZGV5IiwibmFtZSI6IllvdXIgTmFtZSIsImRhdGVPZkJpcnRoIjoiWW91ciBEYXRlIG9mIEJpcnRoIiwiaXNPZkxlZ2FsRHJpbmtpbmdBZ2UiOnRydWUsImNpdHkiOiJZb3VyIENpdHkiLCJjb3VudHJ5IjoiWW91ciBDb3VudHJ5In19LCJpc3MiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkiLCJzdWIiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkifQ.4_wXY3bWZvnvxqUIVsYkqHvrXQmmyYG9FTV7Zydq893yArGaZYCjia81KGFk4EQ241uaKP9i9dwaoeI_fcpJCg

She learns that signing her Verifiable Credential encoded it as a JSON Web Token (JWT), so that no one can modify the Verifiable Credential.

When she pastes the value of the JWT in a tool like Auth0’s jwt.io, she can see the decoded value of the Verifiable Credential, including claims and decentralized identifiers.

Showing your credentials to a verifier

When you go to a verifier, you will share your Verifiable Credential with them. This is often done in a computerized way where maybe you scan a QR code or click a link.

The verifier can check to verify that the Verifiable Credential is real by running the code below:

try {
    await VerifiableCredential.verify({ vcJwt: signedVC });
    console.log('\nVC Verification successful!\n');
} catch (err) {
    console.log('\nVC Verification failed: ' + err.message + '\n');
}

Now, you can start the Presentation Exchange process. This is where your phone’s wallet and the Verifier’s application communicate.

The verifier has a Presentation Definition. The Presentation Definition sets the specific criteria that the verifier is looking for through the Verifiable Credential.

Dawson defines the criteria the verifier is looking for in the Presentation Definition:

const presentationDefinition = {
    id: "presDefId123",
    name: "Legal Drinking Age Presentation Definition",
    purpose: "for verifying legal drinking age",
    input_descriptors: [
        {
            id: "legalDrinkingAge",
            purpose: "Are you of legal drinking age??",
            constraints: {
                fields: [
                    {
                        path: ["$.credentialSubject.isOfLegalDrinkingAge"],
                    },
                ],
            },
        },
    ],
};

This setup allows for a verification process that checks the credential against the verifier's requirements.

try {
    PresentationExchange.satisfiesPresentationDefinition({
        vcJwts: signedVC,
        presentationDefinition: presentationDefinition
   });
} catch (err) {
    console.log('Presentation Definition not satisfied: ' + err.message + '\n');
}

Tutorial: Create a VC in Kotlin

Dawson wants to try creating a Legal Drinking Age Verifiable credential to help her apply the concepts she learned.

Package dependencies

Dawson starts by installing and importing the packages needed to create a Verifiable Credential with Web5.

She adds the following code to her pom.xml file:

<repositories>
    <repository>
        <id>mavenCentral</id>
        <url>https://repo1.maven.org/maven2/</url>
    </repository>
    <repository>
        <id>danubetech-maven-public</id>
        <url>https://repo.danubetech.com/repository/maven-public/</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>xyz.block</groupId>
        <artifactId>web5-credentials</artifactId>
        <version>0.0.11</version>
    </dependency>
    <dependency>
        <groupId>xyz.block</groupId>
        <artifactId>web5-dids</artifactId>
        <version>0.0.11</version>
    </dependency>
</dependencies>

She creates a file called VerifiableCreds.kt and imports the packages in that file:

import web5.sdk.crypto.InMemoryKeyManager
import web5.sdk.dids.methods.key.DidDht
import web5.sdk.dids.DidResolvers
import web5.sdk.credentials.VerifiableCredential
import web5.sdk.credentials.PresentationExchange
import web5.sdk.credentials.model.*

Creating the issuer and the subject

Each participant in the Verifiable Credential process is linked to a Decentralized Identifier (DID), a W3C-standard alphanumeric string that serves as a unique identifier for individuals, organizations, or entities.

For the legal drinking age credential, Dawson thinks the following organizations could be potential issuers such as the Department of Motor Vehicles or the Passport Office. For learning purposes, she creates a DID to simulate an issuer similar to the Department of Motor Vehicles, naming it "Fake Department of Motor Vehicles" or "FakeDMV".

val fakeDmvIssuerDid = DidDht.create(InMemoryKeyManager())

Subsequently, Dawson generates her own DID to act as the subject of the credential.

val dawsonDid = DidDht.create(InMemoryKeyManager())

Inspect the DID

Dawson examines her DID's details:

val resolvedDid = DidResolvers.resolve(dawsonDid.uri)
println(resolvedDid)

She observes the DID document, particularly the DID string and public key:

println("this is the DID string ${dawsonDid.uri}")
println("this is the DID’s public key information ${dawsonDid.didDocument?.verificationMethods}")

Creating the credential

data class LegalDrinkingCredential(
    val name: String,
    val dateOfBirth: String,
    val isOfLegalDrinkingAge: Boolean,
    val city: String,
    val country: String
)

val vc = VerifiableCredential.create(
    type = "LegalDrinkingCredential",
    issuer = fakeDmvIssuerDid.uri,
    subject = dawsonDid.uri,
    data = LegalDrinkingCredential( 
        name = "Dawson Webhart",
        dateOfBirth = "Your Date of Birth",
        isOfLegalDrinkingAge = true
        city = "Your City",
        country = "Your Country"
    )
)

Signing the credential

The "Fake DMV" signs the credential with their DID:

val signedVC = vc.sign(fakeDmvIssuerDid)

Inspect the Signed VC

Dawson prints out the signed verifiable credential, and she finds that the verifiable credential is now an odd alphanumeric string.

eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsImtpZCI6ImRpZDpkaHQ6MWZmd25mNHduZW94cng5M2ZzYTF4NHA3eDg3Y210ZHJicWtkMXcxeTF4bmNtN2FrcWRleSMwIn0.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiTGVnYWxEcmlua2luZ0FnZUNyZWRlbnRpYWwiXSwiaWQiOiJ1cm46dXVpZDo5ZGZhYjcyMS0xY2IwLTRmNDYtOTgxZi05YjhjZDZkY2E1NzUiLCJpc3N1ZXIiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkiLCJpc3N1YW5jZURhdGUiOiIyMDI0LTAzLTA2VDA0OjExOjA2WiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmRodDoxZmZ3bmY0d25lb3hyeDkzZnNhMXg0cDd4ODdjbXRkcmJxa2QxdzF5MXhuY203YWtxZGV5IiwibmFtZSI6IllvdXIgTmFtZSIsImRhdGVPZkJpcnRoIjoiWW91ciBEYXRlIG9mIEJpcnRoIiwiaXNPZkxlZ2FsRHJpbmtpbmdBZ2UiOnRydWUsImNpdHkiOiJZb3VyIENpdHkiLCJjb3VudHJ5IjoiWW91ciBDb3VudHJ5In19LCJpc3MiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkiLCJzdWIiOiJkaWQ6ZGh0OjFmZnduZjR3bmVveHJ4OTNmc2ExeDRwN3g4N2NtdGRyYnFrZDF3MXkxeG5jbTdha3FkZXkifQ.4_wXY3bWZvnvxqUIVsYkqHvrXQmmyYG9FTV7Zydq893yArGaZYCjia81KGFk4EQ241uaKP9i9dwaoeI_fcpJCg

She learns that signing her Verifiable Credential encoded it as a JSON Web Token (JWT), so that no one can modify the Verifiable Credential.

When she pastes the value of the JWT in a tool like Auth0’s jwt.io, she can see the decoded value of the Verifiable Credential including claims and decentralized identifiers.

Showing your credentials to a verifier

When you go to a verifier, you will share your Verifiable Credential with them. This is often done in a computerized way where maybe you scan a QR code or click a link.

The verifier can check to verify that the Verifiable Credential is real by running the code below:

try {
    VerifiableCredential.verify(signedVC)
} catch (err: Exception) {
    println("VC Verification failed:" + err.message)
}

Now, you can start the Presentation Exchange process. This is where your phone’s wallet and the Verifier’s application communicate.

The verifier has a Presentation Definition. The Presentation Definition sets the specific criteria that the verifier is looking for through the Verifiable Credential.

Dawson defines the criteria the verifier is looking for in the Presentation Definition:

val presentationDefinition = PresentationDefinitionV2(
        id = "presDefId123",
        name = "Legal Drinking Age Presentation Definition",
        purpose = "for verifying legal drinking age",
        inputDescriptors = listOf(
            InputDescriptorV2(
                id = "legalDrinkingAge",
                purpose = "Are you of legal drinking age?",
                constraints = ConstraintsV2(
                    fields = listOf(
                        FieldV2(
                            path = listOf("$.vc.credentialSubject.isOfLegalDrinkingAge")
                        )
                    )
                )
            )
        )
    )

This setup allows for a verification process that checks the credential against the verifier's requirements.

try {
    PresentationExchange.satisfiesPresentationDefinition(
        vcJwts = signedVC,
        presentationDefinition = presentationDefinition
    )
} catch (e: Exception) {
     println("VC does not satisfy Presentation Definition: " + err.message)
}

Dawson taps a half-asleep Justin as they land in Orlando, "The planes landing, and I just made my first Verifiable Credentials in JavaScript and Kotlin," she says with a grin.

Please note: The information in this tutorial may become outdated as we update our SDKs towards the 1.0 release.

Build your own VCs and follow TBD's progress as we build Web5

• Documentation

• Discord

• Dev.to

• Twitch

• YouTube

• GitHub

Artist Credit

I did not do any of the art. My talented little sister drew all the art. Check out her work at: https://linktr.ee/scribblndibbl

Residual Income Knowledge Index (RIKI)

The Fair Isaac Corporation score, better known as a FICO score, is a three-digit score that helps lenders in the U.S. evaluate the likelihood of a borrower repaying a loan. A higher score indicates greater reliability. However, achieving a high FICO score — or any credit score — largely depends on accruing and gradually repaying debt. This may come as a disadvantage for various groups of people who may not have a credit score, including veterans, formerly incarcerated individuals, immigrants, young adults, and folks who prefer cash transactions.

To provide a more holistic view of a person's creditworthiness, FormFree developed a new system called Residual Income Knowledge Index™ (RIKI™). Instead, RIKI analyzes monthly income and spending. Integrating this method into our existing credit system provides greater opportunities for home ownership, car purchases, and other essential loans.

"It's like Tinder for banks!"

During the live stream, FormFree Software Engineer, Jon West, showcased their Passport product. The demo highlighted Passport's ability to match borrowers with lenders. This feature inspired an audience member to comment, 'It's like Tinder for banks!'"

Here's how it works:

• Borrowers securely connect to their bank account.

• FormFree analyzes the account records and creates an anonymized credit profile for the borrower.

• Lenders review these anonymized profiles and decide which borrowers to extend offers to.

• Borrowers can now review offers from lenders and choose their preferred option.

• All necessary borrower data is shared with the lender once a match is made.

Typically, borrowers endure aggressively pitched products from dozens of lending institutions. FormFree shifts control to users for more tailored loan consideration.

How FormFree Uses Web5

FormFree uses the following Web5 technologies:

• Decentralized Identifiers (DID) - After sign up, the application associates a user's account with a DID.

• Verifiable Credentials (VC) - A borrower's credit profile is secured as a Verifiable Credential enabling the borrower's information to stay anonymous and tamper-proof.

Coming Soon - tbLend and Credential Selector

As part of our incubation program, organizations such as FormFree, Sophtron, and MX are working in partnership to build Web5 protocols that will help their products evolve.

• tbLend - A Web5 protocol that connects the lender and borrower to exchange money securely.

• Credential Selector - A Web5 protocol that enables developers to embed the Verifiable Credentials (VCs) into their application and allows users to select and retrieve VCs.

Rewatch the full episode

Learn more about what FormFree is building and watch the full live stream here.

This post highlights key moments from our collaborative live stream with leaders and builders at FormFree. Join our weekly live streams every Friday at 12pm ET/9 am PT. We're learning how innovators and community members are advancing the Self-Sovereign Identity and Global Payments industry. Tune in next time via Twitch or in our community Discord.

Between 2019 and 2021, devtool startups recognized they needed more than elite coding skills for their product to succeed in a competitive market. They needed strategies to boost product awareness, education, and adoption among developer communities to sustain investor funding. Since developers, as consumers, are naturally skeptical, traditional marketing wasn't sufficient.

The solution involved hiring DevRel professionals, employees who can combine a deep understanding of technology and the developer mindset with exceptional communication skills and the creativity needed to engage effectively with tech communities. As a result, this led to a surge in hiring Developer Relations professionals. However, in 2022 and 2023, another shift occurred; a large influx of DevRel professionals left the industry. Some departures followed company layoffs, as businesses didn't see immediate return on their DevRel investments. Simultaneously, disillusioned individuals left voluntarily, often sharing their frustrations with unrealistic company expectations through YouTube and blogs.

DevRel Dissatisfaction

Goodbye DevRel for now by Alexander Reelsen

Snarky sidenote: I often believe companies replaced DevRel departments by adding 2023's favorite buzzword to their marketing slogan: "AI."

When I first became a Developer Advocate, a role within the field Developer Relations, I grew weary of the numerous blog posts asking, "What is DevRel?" These posts were initially helpful as I explored the field, but after I gained experience, defining DevRel felt repetitive. I thought it was so surface level, and I craved deeper discussions around:

• Increasing community engagement

• Modifying your DevRel strategy for various regions

• Building relationships across your company

• The art of public speaking

After two years and three months in this profession, I now understand the ongoing need to define DevRel in blog posts. Employers' dissatisfaction with DevRel's effectiveness stems from a lack of understanding what DevRel really is. This misunderstanding adversely affects our performance. Developer Relations is a medium to long-term investment. We are not "swiss army knives" that can lead all your product, marketing, engineering, and support efforts. Most importantly, to achieve true success, Developer Relations requires the involvement of the entire company. In this blog post, I'll discuss why company-wide involvement is essential for DevRel success and how to achieve it.

My Credibility

While I appreciate the respect from those familiar with my work, I occasionally encounter comments questioning my competence and credibility.

Example of skepticism ^

This skepticism might stem from my tendency to underplay my achievements, coupled with societal biases, as I am a young black woman. I welcome constructive debate and thought-provoking questions in the comments, but not dismissive remarks. To address this, I will highlight why my insights are valuable:

• Alongside two other people, I took an early stage nonprofit from a vision to something tangible by developing and running 10-week online coding courses for women of color and nonbinary people of color. Over four years, I taught over 60 individuals, many of whom are now software engineers.

• I made a huge impact as a Developer Advocate at GitHub by significantly contributing to projects like GitHub Copilot. My impact on GitHub Copilot was so great that when I joined a new company, I found a list of resources for learning how to effectively use GitHub Copilot, and they were written by me.

• I am currently a Staff Developer Advocate at a fast-paced startup operating within Block.

• I've held previous roles as a Software Engineer at early-stage companies, as hire number 7 and 20 respectively.

• My educational background includes both a coding bootcamp and a computer science degree from Boston University.

• Before I learned to code, I was a help desk technician and a phlebotomist.

My point is that my varied experiences across different roles and organizational sizes equip me with a holistic perspective. I understand the challenges and nuances of working in DevRel at both large corporations and smaller startups. I also know what it's like to work outside of DevRel.

Defining Developer Relations

Developer Relations, nicknamed DevRel for short, is a field made up of multiple roles including Developer Experience Engineers, Developer Advocates, Community Managers, Technical Writers, Developer Marketers, and moreThe primary objective of a DevRel team is to facilitate communication between technologists and the business. Although many enter the field with altruistic motives, the underlying mission is to expand the customer base in a scalable, one-to-many approach.

I'm a Developer Advocate, so I will focus more on that particular role. When engaging with the company, Developer Advocates represent the developer community. Alternatively, when engaging with the developer community, Developer Advocates represent the company. Developer Advocates raise awareness about the company's products within the developer community and provide the community's feedback to enhance the developer experience within the company.

• Creating awareness can take various forms, such as discussing the company's developer tools on podcasts, giving conference talks, and writing blog posts.

• Engaging with the developer community involves direct interactions, like one-on-one conversations in forums, audio spaces, or at conferences.

• Improving the developer experience often involves relaying feedback to engineering or product teams, maintaining documentation, creating user-friendly sample applications, and developing open source SDKs that complement the company's product.

Ultimately, these strategies foster trust and education of the product. The developer community wants to use the company's developer tooling and understands how to use it well resulting in increased revenue. One of the most rewarding parts of this strategy is that it inspires community members to participate in DevRel activities, too! Often, community members are so engaged by DevRel's approach that they voluntarily start creating content or speaking at conferences. This enthusiasm can create a ripple effect, further boosting adoption within your company's developer community. However, seeing that increase in users and revenue can take a long time, ranging from months to years.

A Common Mistake in Developer Relations Teams

I admit that Developer Relations teams are not perfect, especially not me.

Developer Relations demands a careful balance between external activities and internal activities. Internal work, like community engagement and content creation, builds awareness and amplifies the company's presence. However, some DevRel teams focus too heavily on internal work, and then they struggle to make them product more known. Conversely, teams mainly focused on external efforts might neglect keeping documentation and example apps up to date.

You can have good docs, but no one reads them, or you can have unintuitive APIs, and folks walk away with a bad impression of the product.

I wrote a blog post outlining tasks you can do to make an impact internally and externally.

The Mismatched Expectations of DevRel

On the outside looking in, Developer Relations seems like a glamorous field promising tech celebrity. Behind the social media posts featuring people traveling the world to deliver conference talks and hanging out on social media, many developer advocates are grappling with the challenges of balancing rest, networking, and their core workload. A year into my first DevRel role, I detailed the job's demanding aspects in a blog post.

It can be both exciting and overwhelming to have your day-to-day work look like:

• Hopping off of a Twitch stream

• Jumping on to a plane

• Refining your conference talk on the plane and practicing your code demo

• Publishing resources for the most recent release in your hotel room.

• Delivering your conference talk the next day

• Fielding questions from the audience

• Going to dinner with other developers

• Heading to your hotel room to answer questions from the community

• Managing your social media interactions

• Writing a trip report as you travel back home

This hectic schedule can be frustrating, especially when faced with upper management's questions about metrics and the tangible impact of these efforts.

Many argue that DevRel job descriptions, like those for Developer Advocates, are overly broad and lack standardization, reflecting the diverse nature of DevRel across companies. While this viewpoint is valid, I see the flexibility as a positive aspect. Developer Relations encompasses a lot of cross-functional work. We might have to work with Marketing, Product, and Engineering. We might have to produce videos, write blog posts, and write code. I don't think that's unreasonable. Many DevRel professionals, including myself, enjoy the cross functional chaos. The apparent lack of standardization stems from the varying needs of different companies;

Developer Advocates often act as gap fillers, addressing specific weaknesses within the company. For example, some companies might be doing really well on the developer marketing side, so they need DevRel's coding skills to improve the developer experience. Or vice versa, some companies might have enough engineers to create a great product with a smooth developer experience, but they're struggling to engage with the community. Therefore, the level of ambiguity within Developer Relations roles seems fair to me.

Sidenote: Daniel M. Phiri wrote an interesting article on gap filling as a developer and as a developer advocate.

Another side note: Jason Lengstorf also has a great video on identifying gaps to fill in a company as a Developer Advocate.

{% youtube 3X-EUEOg638 %}

The real issue lies in the unrealistic expectations placed on DevRel teams, such as expecting the teams to:

• Juggle too many tasks at once rather than focusing on specific objectives at different times, especially in smaller teams. Larger teams have bandwidth to delegate distinct areas like video production, blogging, or SDK maintenance.

• Deliver quick results in areas like community growth, reputation building, and technology adoption. Such processes naturally take time. People don't instantly embrace new technologies after hearing about them. They require an engaging onboarding experience, positive interactions with the team, accessible documentation, and fun building processes. Establishing a smooth onboarding process might take several months, and improving documentation could take up to a year.

• Operating in isolation without support from other teams. While DevRel supports other teams within the company, reciprocal support isn't always there. For DevRel to truly succeed, other departments must invest time and resources in helping DevRel achieve its objectives.

Creating a DevRel Culture

Making DevRel an all-company endeavor can look like:

• Early Engagement in DevRel Activities: Even at an early stage, try performing DevRel activities BEFORE hiring a DevRel team. This firsthand experience builds empathy, respect for the role, and a clearer understanding of the specific gaps that a DevRel team would need to fill. It could also save you some money.

• Inclusive Strategy and Product Discussions: Involve DevRel in meetings regarding strategy, product development, and engineering. DevRel should be informed and participate in the process if there are changes to the code or new company initiatives.

• Encourage non-DevRel staff to contribute to DevRel initiatives: While DevRel leads content creation and public speaking, other employees should also be involved. For instance, an engineer sharing their perspective on tool development can boost the company's repertoire.

• Practice working in public: This is especially important and easy if your company has an open source product. The community needs to know the roadmap and how you're thinking about building the product so that they can make valuable contributions. Working privately and expecting DevRel to publicize internal developments can lead to communication gaps. Open source thrives on mutual learning, often requiring more than code commits.

• Keep open lines of communication: Maybe you're not on the DevRel, but you heard some feedback at a conference or when talking with a community member. Share that feedback with the engineering team and the DevRel team. Regular feedback sessions can help bring community insights into company processes.

• Transfer knowledge from engineering to DevRel - Engineers know how the product should work because they built it. Transferring knowledge empowers DevRel to create more relatable and engaging content, documentation, and use cases for the community.

• Integrate DevRel Principles in the Company Mission: Embedding DevRel and open source principles into the company's mission aligns everyone's efforts with fostering a collaborative and open developer community.

Is this Realistic?

You might read this and wonder if such a comprehensive approach to supporting DevRel is too idealistic, especially given companies' time constraints.

My snarky response: If that's your immediate reaction, then perhaps you're not fully invested in the success of your product.

But let's go with a less snarky take: The most successful companies with admirable DevRel teams have other departments fully backing them up. They invested early in DevRel activities, even before establishing formal DevRel teams.

Take GitHub as an example, a company where I previously worked and which, in my view, excels in DevRel. GitHub was effectively practicing DevRel long before it had a formal team. One of the first blog posts on the GitHub blog was called How to undo (almost) anything. This was written by Joshua Wehner, a software engineer and trainer at GitHub. In 2017, Mike Stowe wrote an article called A Brief History Of Developer Relations Programs: How DevRel Evolved Into Developer Communities.

In the article, Mike highlights GitHub's involvement in the developer community, "the most successful—and underrated—developer relations program belongs to a company known as GitHub, a company that hasn't invested in their program the same way as Twilio or Sendgrid has, but still boasts the largest and most active developer community…focused on grassroots approaches over extensive event strategies. That's not to say that they didn't go to events. GitHub was famous for sending their myriad of creative Lisa/Octocat stickers to conferences around the world. But that wasn't core to their strategy. Their strategy was built around community, highlighting individuals' contributions, and providing a resource developers could rely on to continue growing in their careers."

Mike also recognizes companies like StackOverflow and Twilio for their effective DevRel execution.

Another admirable example is Astro, a JavaScript metaframework. This is a startup founded in 2019 with less than 12 employees. They don't have a DevRel team (from my knowledge), yet they're popular in the JavaScript community because they:

• chronicled their progress via blogs BEFORE they hit version 1.0

• actively live stream and join other streams

• invested in stellar documentation

• made engaging and easy to follow sample applications

• speak at conferences

• made it easy to take existing JavaScript framework knowledge and apply it to the Astro framework. Ex: if you are a Next.js dev or a Svelte dev, it's easy to pick up Astro.

From the outside looking in, each employee at Astro is heavily involved in the developer community. Additionally, there are so many developers and developer advocates with influence that create courses and write blog posts about Astro, which helps to spread awareness.

I understand that small startups and their teams might not have the capacity to invest in DevRel activities if they're not on the DevRel team. I remember working as a Software Engineer just trying to complete my tickets. I would be overwhelmed if I also had to write blog posts. However, things changed when I joined Botany as their seventh hire. My manager cleverly carved out time within the sprint for engineers to write blog posts recapping what we learned throughout the sprint. This was done to help us retain knowledge and become more effective engineers. However, companies can take this idea and repurpose it to support DevRel initiatives. If this strategy is adopted by upper management, and they allocate the necessary resources, then non-DevRel staff can feel empowered to participate in DevRel activities without feeling overburdened.

Developer Relations is not just a team department or an isolated function. It's a philosophy that the entire organization needs to adopt. While it feels gross to say this, the company's developer community is the most valuable asset, so why not invest?

Feel free to leave a comment with deeper insights because although I do have experience, I don't have the same experiences as you all. The comments section is a space for us to learn and grow. I may only get a chance to respond to some, but I will read every comment.

Thanks for reading!

When I built my first Web5 application in July, I explored how to store data in a Decentralized Web Node (DWN)—a personal data store in the Web5 ecosystem. I can write, edit, delete, and read data, also known as records, to my DWN.

To interact with data in my DWN, I need a Decentralized Identifier (DID). DIDs are unique IDs in the digital world. DIDs also act as keys to accessing and manipulating data in a DWN. I think of it like a password to access a database.

Although these were fairly new concepts, I drew parallels to help me understand. In my mind, I compared a DWN to a database and a DID to credentials that help users access a database.

However, there were some technical guidelines that initially confused me. For example – by default, I cannot write data to someone else's DWN unless I have been granted permission to do so. I wasn't sure how to grant permission for a user to write to my DWN. Similarly, I wasn't sure how another user could give me permission to write or read data on their DWN.

Apparently, the solution is to use a protocol! A protocol, structured as a JSON document, outlines the data structure, defines data types, and establishes rules for data access and interaction within a DWN. In other words, protocols enable users to control who can read or write specific types of data to your DWN.

Defining a protocol

I wrote a protocol definition for a chat application:

 const chatProtocolDefinition = {
      protocol: "https://blackgirlbytes.dev/ChatProtocol",
      published: true,
      types: {
        message: {
          schema: "https://schema.org/Message",
          dataFormats: ["application/json"],
        },
        audio: {
          schema: "https://schema.org/AudioObject",
          dataFormats: ["audio/mp3"],
        },
        video: {
          schema: "https://schema.org/VideoObject",
          dataFormats: ["video/mp4"],
        },
        image: {
          schema: "https://schema.org/ImageObject",
          dataFormats: ["image/png"],
        },
        gif: {
          schema: "https://schema.org/ImageObject",
          dataFormats: ["image/gif"],
        },
      },
      structure: {
        message: {
          $actions: [
            { who: "anyone", can: "write" },    
            { who: "author", of: "message", can: "read" },    
            { who: "recipient", of: "message", can: "read" },
          ],
          audio: {
            $actions: [
              { who: "anyone", can: "write" },    
              { who: "author", of: "video", can: "read" },    
              { who: "recipient", of: "video", can: "read" },
            ],
          },
          video: {
            $actions: [
              { who: "anyone", can: "write" },    
              { who: "author", of: "video", can: "read" },    
              { who: "recipient", of: "video", can: "read" },
            ],
          },
          image: {
            $actions: [
              { who: "anyone", can: "write" },    
              { who: "author", of: "video", can: "read" },    
              { who: "recipient", of: "video", can: "read" },
            ],
          },
          gif: {
            $actions: [
              { who: "anyone", can: "write" },    
              { who: "author", of: "video", can: "read" },    
              { who: "recipient", of: "video", can: "read" },
            ],
          },
        },
      },
    };

This protocol definition supports various message types: text, audio, gif, video, or image. It also grants permissions to different groups of users. In this particular example, anyone can create a message, but the author and recipient also have permission to read messages. For clarity, this means anyone can write a message to the DWN, but only the recipients and senders can read the messages that they sent and received.

Sidenote: This method is an amazing way to intentionally architect applications.

Here's a brief explanation of some of the properties listed in the protocol definition:

• types - Defines all the elements used in a protocol

• structure - Outlines the relationship and interaction rules between different types

• $actions - Specifies a set of permissions outlining who is allowed to perform specific actions like reading or writing on a given type

Installing a protocol

After I defined my protocol, I installed the protocol to my DWN. Installing the protocol enables my DWN to recognize and adhere to the rules and structures I've established. Here's how to install the protocol for the chat application:

const { protocolStatus } = await web5.dwn.protocols.configure({
  message: {
    definition: chatProtocolDefinition,
  },
});

Problem: I want to filter for specific records

My protocol is defined and installed, so I can use it now! But there's a problem. I only want to return GIFs for a new feature in my chat application.

This new feature will display a gallery of users' most frequently used GIFs to help users conveniently retrieve the GIFs they want to use during conversation. I could fetch all the records on my DWN and then filter using an Array method on the cl. But, that could be inefficient.

Solution: Query by protocol path

One way I can address this is to query by protocolPath. I can pass the name of my structure as a value for my protocolPath property. In the protocol definition, gif is nested inside a message structure. Therefore, the protocol path for a gif is message/gif.

The query below will only fetch the GIF records:

const { records } = await web5.dwn.records.query({
  message: {
    filter: {
      protocol: "https://blackgirlbytes.dev/ChatProtocol",
      protocolPath: "message/gif",
    },
  },
});

Other ways to query records

There are other ways to query records using the Web5 JS SDK. You can find a list of filterable record properties in the documentation. I’ve listed a couple of examples for your convenience:

Query Records by Record ID

The snippet below will return a record with the record ID: bfw35evr6e54c4cqa4c589h4cq3v7w4nc534c9w7h5

const { record } = await web5.dwn.records.query({
  message: {
    recordId: "bfw35evr6e54c4cqa4c589h4cq3v7w4nc534c9w7h5",
  },
});

Query Records by Data Format

The snippet below will return all records that have an application/json data format.

const response = await web5.dwn.records.query({
  message: {
    filter: {
      dataFormat: 'application/json'
    }
  }
});

Read the documentation

Remember that this technology is evolving rapidly! Web5 is in active development and technical preview. For the most current information and guidance on querying records in Web5, always refer to the official Query DWN Records guide.

Knowledge check

Excited to continue learning

Every Friday, the Developer Relations team has been spending time learning in public about Web5. Join us on Twitch.tv/tbdevs. Check out a preview below

You can watch the full episode here

Like this content?

For more content like this, follow TBDevs and me!

Meet Dawson Webhart, a software engineer who's part of the frontend team at StyleByte, a cutting-edge fashion company that uses augmented reality to style its customers. The team focuses on the part of the app that users see and interact with, and Dawson is a key contributor.

Today, Dawson is at her desk, but she's not exactly working. She's scrolling through her phone, watching short workout videos to inspire her next gym session.

"Here are my top 10 tips to getting a peach like Megan Thee Stallion," says the fitness instructor on the video.

Dawson rolls her eyes just as her co-worker, Nadia Noelly, bursts into her office. "Hey, Dawson! The meeting is starting soon, and I want to get there early. They're making a big announcement!"

"Another announcement? What now? More ping pong tables in the lounge?" Dawson sighs, not particularly thrilled but curious enough to find out.

The Meeting

In the meeting room, the atmosphere is electric and cult-like as every tech company is. StyleByte's Vice President of Engineering, Wilson, takes the stage. "We're moving to Web5," he announces.

While Nadia's eyes beam with excitement, Dawson feels a mixture of concern, exhaustion, and frustration. "Web5? We just integrated Augmented Reality, migrated to the cloud, and now this? What even is Web5?"

Dawson has always been cautious about change, especially when it comes to technology. She tunes out for the rest of the meeting, pondering what this shift could mean for her work.

After the meeting, Nadia is practically buzzing. "Wasn't that cool? We're moving to Web5! You know what that means, right?"

"More late nights and stress?" Dawson sarcastically replies.

"No, silly! A promotion! We could lead this initiative and finally drop our 'junior' titles. How does 'Mid Level Developer' sound?"

For the first time, Dawson feels a spark of interest. She's been at StyleByte for three years without a promotion. "Okay, you've got my attention. But what is Web5?"

"Weren't you listening? They emailed us the presentation. Check it out," Nadia says, already halfway out the door.

Back in her office, Dawson opens the presentation and finds a diagram explaining the evolution of the web:

• Web 1.0: Static, read-only content.

• Web 2.0: Interactive, social, and user-generated content.

• Web3: Decentralized, blockchain-based, user-controlled data.

• Web5: Enhanced decentralization, peer-to-peer communication, and self-sovereign identity.

Dawson finds it interesting but isn't entirely convinced. "Seems like a solution looking for a problem," she thinks.

The Ultimate Crisis - a stolen username

Just then, a notification pops up on her phone. It's from her favorite social media app, Incognito. Incognito’s new and very erratic CEO, Francis Francino, has just announced a name change for the app—to WebHeart.

“We will be changing this app’s name to WebHeart because it exemplifies what this company has evolved into. We capture the heart of the web. We will be changing our username to @webheart to reflect that.”

Dawson's eyes widen in disbelief. "@webheart" was her own username, a clever play on her last name, Webhart, and her role as a frontend web developer focused on enhancing user experience. She quickly replies to the announcement, "Hey, that's my username!"

Francis Francino responds almost immediately, "Oh, too bad. How about some free merchandise to make up for it?"

Nadia texts her, "Sorry to hear that. If we were on the decentralized web, this wouldn't have happened. Your username would've been yours, controlled by a Decentralized Identifier. Look it up."

Dawson feels gutted. That didn’t console her at all.

Dawson feels a mix of indignation and inspiration. If there's anything that fuels her, it's the prospect of revenge served cold and promotions served hot. She decides to dive deeper into Web5. Maybe she could build a transparent social media platform where usernames are truly owned by users. Or maybe she'll snag that promotion. Either way, Dawson is now on a mission.

Throughout her research, Dawson asked the following questions:

What exactly is Web5?

Web5 is an evolving incubator project spearheaded by TBD, Block's newest business unit. The goal is to equip developers with the essential tools for building decentralized applications that prioritize user control over identity and data.

From Dawson’s perspective Web5 could be considered:

• Tooling: Web5 provides a suite of tools and APIs designed for implementing Self-Sovereign Identity (SSI), decentralized data storage, and secure peer-to-peer communication. This enables the creation of secure, user-centric, privacy-first applications.

• An Ecosystem: Web5 is part of TBD's broader ecosystem, which aims to empower developers to create their own decentralized applications and protocols.

• Toolbox for Developers: Web5 provides pre-built functionalities for identity management, data storage, and secure communication. This way developers can focus on building their application's features rather than worrying about the complexities of security and identity management.

What is the point of Web5?

Web5 exists to enable Self Sovereign Identity. Self Sovereign Identity (SSI) is the concept that users should have full control and ownership over their digital identities.

Why would someone need ownership over their digital identity?

Because we are not used to owning our digital identity, it may seem like a futile and foreign concept. Here are a few moments when ownership of digital identity is beneficial:

• Social media:

  • There’s no way someone can steal your handle, just like what happened with Dawson's "@webheart" username.

  • You can take your followers and content with you if you decide to switch platforms.

  • You have full control over how your data is shared, reducing unwanted advertising and privacy breaches.

• Healthcare systems

  • You can take your medical records with you, ensuring that you have access to your own health information wherever you go.

  • You control who has access to your medical data, making it more secure and private.

• Banking

  • Your financial transactions are secure, and only you have access to your financial data.

  • You can easily prove your identity for online transactions, reducing the risk of fraud.

How can you build a decentralized app using Web5?

You can build a web5 application using the web5.js SDK.

What is a Decentralized Identifier?

A decentralized identifier (DID) is a w3c open standard. It’s represented by a string of numbers and letters that identifies and verifies who you are on the web. No one can take it away from you, and no one can change it. A DID is not limited to just a person. It can point to an organization, data model, entity, or whatever it is that user is managing online.

She experimented with DID by executing the steps below (you can do it too 😉):

Creating a directory via her terminal

mkdir decentralized-social-app

cd decentralized-social-app

Installing the web5.js SDK

npm install @web5/api

Verifying her package.json looked like this:

{

  "dependencies": {

    "@web5/api": "0.8.1"

  },

  "type": "module"

}

Creating an index.js file

touch index.js

Importing the Web5 package in our pages/index.js file

import { Web5 } from '@web5/api';

Creating a decentralized identifier

const { web5, did: dawsonDid } = await Web5.connect();

Logging the decentralized identifier

console.log(dawsonDid);

Running this command in her terminal

node index.js

Here’s her result

did:ion:EiBiHtKwEIdrqLRph3id0HoyCeuk69t6oWbw38WbyYAjvQ:eyJkZWx0YSI6eyJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljS2V5cyI6W3siaWQiOiJhdXRoeiIsInB1YmxpY0tleUp3ayI6eyJjcnYiOiJzZWNwMjU2azEiLCJrdHkiOiJFQyIsIngiOiIxOTQxS29LZ1RyX1V5cDhwcDJITTdGc3U3TzhMb3JyRXNuaXpTZ3o0T1NNIiwieSI6Im1XLTB3dGZobWxBYklFVFczY1JmZUFDRXVzcGNVTVlnM2kzTXlYUTc2X2cifSwicHVycG9zZXMiOlsiYXV0aGVudGljYXRpb24iXSwidHlwZSI6Ikpzb25XZWJLZXkyMDIwIn0seyJpZCI6ImVuYyIsInB1YmxpY0tleUp3ayI6eyJjcnYiOiJzZWNwMjU2azEiLCJrdHkiOiJFQyIsIngiOiJONFhPWWgzeWRMMHA1UGZrVzRZWmZqWjN3WXpQWmNRb1pNcmpQX04xUmI4IiwieSI6InUzRHBKc1ZkN0FRVUZEYkVaSEVhUkJNM0VCajN1ZEpJMXpUbFVsSnZJaFEifSwicHVycG9zZXMiOlsia2V5QWdyZWVtZW50Il0sInR5cGUiOiJKc29uV2ViS2V5MjAyMCJ9XSwic2VydmljZXMiOlt7ImlkIjoiZHduIiwic2VydmljZUVuZHBvaW50Ijp7Im1lc3NhZ2VBdXRob3JpemF0aW9uS2V5cyI6WyIjYXV0aHoiXSwibm9kZXMiOlsiaHR0cHM6Ly9kd24udGJkZGV2Lm9yZy9kd240IiwiaHR0cHM6Ly9kd24udGJkZGV2Lm9yZy9kd24yIl0sInJlY29yZEVuY3J5cHRpb25LZXlzIjpbIiNlbmMiXX0sInR5cGUiOiJEZWNlbnRyYWxpemVkV2ViTm9kZSJ9XX19XSwidXBkYXRlQ29tbWl0bWVudCI6IkVpQ25tcGxmb1VOemlnX01HWnA1QU1Gel9yRm5rUmtHV01jSXJSbFcyT1dGd3cifSwic3VmZml4RGF0YSI6eyJkZWx0YUhhc2giOiJFaUNnUy1nT21lY3lBeXo0V1VwTEJUQTl3MnFIVUR3ek0wd0JyUkYxbXZZY1V3IiwicmVjb3ZlcnlDb21taXRtZW50IjoiRWlBZnZHWEx2cEhEOFVRbnU3RG1OTDVKdEFMQjRaOTg2bG1VRjFMTERPN1JrQSJ9fQ

Dawson's remaining questions

Dawson was having so much fun learning until she realized it was 5:00 pm and her work day was over. She still had questions like,

And you might be wondering, "Who the heck cares?" That's valid. Job announcements are a little pretentious. However, I believe in transparency regarding my career and technical journey. I want others to learn from my successes and failures, and this blog post is a part of that continued commitment.

In this blog post, I will:

• Reflect on my journey at GitHub.

• Share my next career move and the reasons behind it.

• Delve into the fears that come with such a transition.

• Outline my aspirations and the knowledge I aim to gain in the next chapter of my professional life.

My journey at GitHub

Two years ago, I entered a new era of my career as a Junior Developer Advocate at GitHub. Before that, I was working as a software engineer and was desperate to become a developer advocate. I liked coding (and still do), but it was unfulfilling because my diverse skill set was not the best fit for the role. I wanted to empower, educate, and provide support to other technologists. After a few rejections and a slightly unconventional career journey, GitHub gave me a chance. I signed my offer in August 2021 and prematurely wrote this tweet announcing that people needed to follow me because I would work at GitHub. I didn't even start the job until September 7th 😆.

At GitHub, I:

• Made my first open source contribution

• Empowered others to engage in open source

• Spoke in a keynote

• Wrote blog posts that people actually read

• Live streamed for the first time

• Got my first promotion from junior to mid-level

• Embraced failure as a teacher, delivering less-than-ideal talks, championing questionable ideas, and occasionally flaking or oversleeping due to an overloaded schedule.

The most impactful part for me was the recognition and appreciation of my perspective by my colleagues and the broader developer community. Feeling valued and heard was a new experience for me, and I'm endlessly grateful that my company and the developer community supported my endeavors. I'm thankful that my coworkers, managers, and friends I made outside of GitHub knew how to help me highlight my strengths. As I reflect this week, nostalgia washes over me. I'll miss the relationships I've built over the last two years, from my teammates to the Blacktocats (our Black Employee Resource Group) and even the CEO and his team. I'll also miss the projects I invested so much time in, like Open Source Friday. However, new endeavors are on the horizon.

My next steps

In a few weeks, I will be a Staff Developer Advocate at Block's newest business unit, TBD. Many companies acquire other companies or open source projects to help support their growth. Block, previously known as Square, also acquires other companies like Tidal, but it also supports in-house projects developed by their employees. TBD is an initiative led by individuals who have spearheaded projects at CashApp and other Block subsidiaries, with a focus on building decentralized technologies that advance economic empowerment.

What draws me to working at TBD

In a rapidly evolving tech landscape, companies like GitHub, Microsoft, and OpenAI are pioneering the field of generative AI. I've had the privilege of participating in this exciting industry trend. So, you might wonder why I'm now choosing to transition to a company with a strong focus on decentralization.

Embracing the power of "Yes"

I have a personal policy of saying yes. When I was ~20, I read the book The Defining Decade: Why Your Twenties Matter--And How to Make the Most of Them Now. It's not the best book. (I was reading a lot of self-help books because, for some reason, I thought I failed at life when I turned 20). A quote in the book says, "Yes is how you get your first job, and your next job, and your spouse, and even your kids. Even if it's a bit edgy, a bit out of your comfort zone, saying yes means you will do something new, meet someone new, and make a difference."

As I recently celebrated my 28th birthday, this philosophy holds even greater significance. When I was trying to decide between joining this company or staying at GitHub, I decided I would procrastinate and watch my favorite Black YouTube video content creators instead. I stumbled upon one of Gyasi Linje's videos, in which he quoted the same words from the same book! I took that as a sign. Saying "yes" to ventures beyond my comfort zone has propelled me to where I am today.

Black mentorship

I credit part of my rapid growth as a Developer Advocate to starting my DevRel career under the guidance of a Black manager, Brian Douglas. As I transition to the next phase of my career, I'm fortunate to have Angie Jones, the VP of Developer Relations, as my new manager. Angie is admired for her work and her character among all developer relations professionals. She is also one of the few Black VPs in DevRel that I could think of off the top of my head. As I progress in my career, having a manager who understands how to navigate the industry as a Black woman is paramount. Brian's mentorship was invaluable in my early journey, and I'm confident that Angie's leadership will continue to provide me with the insights and support I need to thrive in this field.

Team

I recently met many members of the TBD team at an offsite, and they were all brilliant and friendly. What adds to my excitement about joining this team is that I already have trust and respect for several team members, some of whom I met while at Resilient Coders, a coding bootcamp I attended. Nick DeJesus and Ebony Louis have expertise in leading impactful, but behind the scenes work. I'm eager to collaborate with them and learn from their expertise. Nick has been a great mentor to me since I became a developer. I remember I joined a company that was using Redux, and he took the time to explain how it worked.

Additionally, Ace recently joined the TBD team as a Staff Developer Advocate, and from what I've observed, he's absorbed so much of the technical knowledge around what TBD is building. I anticipate a dynamic collaboration where we can complement each other's strengths and provide a well-rounded approach to our work.

Title

People say things like money and titles don't matter, but that's a privileged take. I'm a black immigrant woman raised by a single mother of three in the hood; money and titles always matter. They're not the only factors that matter, but they do determine the trajectory of one's life. Due to imposter syndrome, I always sign up for junior roles at every new job. This time, I'm trusting myself to make Staff-level contributions and influence the team, the company, and the industry.

Beyond my own career trajectory, the aspect of representation is crucial. We need more underrepresented folks in leadership positions. It shouldn't even be rare. My goal is to reach a level where I can influence the prioritization of hiring more underrepresented individuals across the board. This step in my career is a meaningful stride towards fostering diversity and inclusion in the tech industry.

Product

When I've mentioned this new opportunity with fellow developer friends, one recurring theme of skepticism has been the product. Understandably, they're unsure about it because it's still in development, and the term "decentralization" can often conjure images of gimmicks and scams prevalent in the crypto industry. Some, including myself, have questioned whether decentralization is a solution in search of a problem.

But as I've explored the technology that TBD is building, I realize:

• We are already searching for decentralized solutions for our social media platforms, especially as we've witnessed the decline and growing distrust of many social media applications. Cough, cough. Twitter/X, Facebook and Instagram/Meta.

• How technology is used determines its ethical implications; it is inherently neutral. For instance, people can use my main passion, AI, for harm and benefit. In the case of TBD, they focus on creating solutions that simplify sending money across borders. While this may not appear revolutionary to everyone, I've personally experienced the frustration of sending money to family members in Guyana and Antigua or friends in Nigeria. It's frustrating to stand in check cashing lines or to wire money successfully between banks. Another example is although there's a large developer presence in Nigeria, they're not eligible for GitHub Sponsors or many of the ways to get paid through open source. Simplifying these financial transactions can make a difference for the global south.

This technology can improve financial equity, and it's not something I will get bored of. In fact, I've said this in a few blog posts and talks before -- I'm tired of our industry; we are too focused on building tools that only benefit privileged people.

There is a steep learning curve to understand the protocols and SDKs, but I welcome the challenge.

Change is scary

While I'm excited, I'm also nervous because change is scary, and I'm not 100% sure what to expect. I like knowing everything that's going to happen all the time. For example, I look up spoilers while I'm watching a movie.

I'll have to adapt to a different work culture, tweak my DevRel strategy for an early-stage company, and learn a lot of new technical concepts. I also anticipate that my unconventional DevRel strategy and personality may take time for the new company to warm up to. Still, I'm fully committed to embracing these challenges and enthusiastically navigating the unknown.

My aspirations

My greatest strengths are my storytelling skills and my ability to break concepts down for beginners, which I think the decentralized web needs more of. There's a lot of complexity around decentralization because it requires a paradigm shift in how we think, build, and use the Internet. Unfortunately, I don't see many resources that break down these concepts in a consumable way. I am most excited about creating beginner content and gradually building that into more advanced content.

In the upcoming months, I also hope to:

• Create sample applications that exemplify the potential of Web5.

• Cultivate meaningful relationships both within the company and the wider community.

• Support the enablement of open source externally and internally.

• Continue my exploration of generative AI and integrate it into my work.

• Evaluate the effectiveness and relevance of the DevRel strategies I've written about and implemented. Perhaps I wrote about those strategies, and they only work at a large company with a well-established DevRel team. Let's see how they work at an open source startup.

I started building a few things for my own understanding of Web5. I built a decentralized to-do list and a DID alias generator. Both projects are incomplete and don't use Web5 to its full potential, but I plan to add more incrementally. The final product could serve as a sample application demonstrating the advantages of Web5, perhaps in the form of an app that allows specific tasks from the to-do list to be shared with different users—whether they be partners, coworkers, or friends. Users could utilize aliases on the DWN instead of a DID (a lengthy alphanumeric string representing your digital identity). These aliases would be connected to their social media accounts, which could be a form of authentication on the shared to-do list application.

Saying goodbye to GitHub is bittersweet for me. I'm immensely grateful for the opportunities, relationships, and growth this chapter has provided. But, I'm also eagerly saying yes to having a voice in the evolution of the web. (If I see anything sus going on, you know I will speak up. 😉) As I embark on this new journey, I hope that, at TBD, we can collectively drive positive change within the industry, shaping the decentralized future of the web to benefit the less privileged. To the community, thank you for supporting me thus far. Just as I did when I took my first steps in Developer Relations, I invite you to continue this journey alongside me. Together, we'll explore decentralization, open source, and AI and make a meaningful impact on the tech landscape.

As much as I would like to deny it, I think it’s evident that within almost two years working as Developer Advocate at GitHub, I’ve made a significant impact both within the company and across the developer community. Instead of being bashful, I’m choosing to embrace my influence and share my knowledge in a blog post.

Keep in mind:

• These strategies worked for me, but developer advocacy is not one size fits all because every company and developer community has different needs and goals.

• This blog post is tailored specifically to Developer Advocates and may not directly apply to the broader spectrum of Developer Relations roles. Roles such as community managers, technical writers, and developer marketers have different objectives and responsibilities.

• It's completely fine if your aspirations don't align with creating a sweeping impact. Your focus can be on diligently executing your role, and that's perfectly valid. I’m not asserting that you must do this; rather, I’m aiming to provide insights for those who wish to explore that path.

• I’m primarily a content focused Developer Advocate with coding and community engagement forming complementary facets of my role.

Why make an impact as a developer advocate?

People like to deny it, but Developer Advocates are influencers. I don’t say influencer in the sense that we’re on Instagram taking pictures with flat tummy tea, but we influence the developer community and our companies.

Sometimes, the impetus driving one toward developer advocacy originates from a sense of disillusionment with the world of software engineering. This pivot opens doors to:

• Exploring and experimenting with new technologies.

• Supporting fellow developers and having fun.

• Establishing a public presence and engaging in meaningful conversations.

• The opportunity to travel and connect with communities worldwide.

Reality check: we live in a capitalist society

While we do get to do these things, companies don’t pay us 6 figures to have fun. Many companies hire Developer Advocate to spread awareness, and ensure their products thrive, leading to increased revenue. We can achieve this through community engagement, conference talks, hands-on coding, and compelling content. The trust established within the developer community directly translates into a willingness to embrace our company’s products. The ultimate goal is to create a ripple effect where the knowledge you share with developers inspires them to educate others, thus amplifying the reach and impact.

Navigating ethical advocacy

But, our job goes beyond promoting a tool. You don’t want to encourage people to try out a technology that’s not actually good or serving them. That’s inauthentic and irresponsible. Our role includes providing honest feedback to our colleagues – whether it's product managers, engineers, or leadership – on areas that need improvement. When you've nurtured strong internal relationships and your impact is recognized within your company, it’s easier to guide the direction of the product.

While Developer Advocacy isn't a popularity contest, nor does it involve forcing people to use your company's technology, your goal is to cultivate relationships and establish a sufficiently strong reputation within both the developer community and your organization. This enables you to best serve developers with integrity and bring value to your company.

Your job is to make an impact that reverberates.

Tips for making an impact

Team and management

Working with a team and manager that sets you up for success is key.

Stay away from managers that:

• Place blame

• Constantly change expectations

• Aren’t invested in your success

Lean into managers and teams that:

• Regularly give positive feedback

• Occasionally give you constructive criticism, so you can improve

• Find opportunities for you to grow

• Positively mention your name in circles that you’re not in

My personal experience

I’m grateful that I had good management throughout my tenure at GitHub because it helped lay a foundation for success. I had the opportunity to do activities like speak in the GitHub Universe Keynote because my colleagues and managers advocated for me and supported me.

Understand expectations

You can gain insights and make a good impression as early as the interview. (I’m not great at this, but I do see how impactful it is when people are good at this). During the interview phase, get an understanding of why the company is hiring and the strengths and weaknesses of the team you'll be joining. People struggle to get dev advocate jobs because they don’t understand why the company is trying to fill the role.

It’s important to understand what the company expects from you because you do not want to work at a company as a developer advocate with misaligned expectations. For example, if you are hoping to maintain and build the community, but they’re hoping you’re mostly going to be writing code, you will be very unhappy and so will the company.

Ask yourself the following questions:

• What’s the company excelling at?

• What do you excel at?

• Do those align?

Jason Lengstrof made a video where he talks about the key to getting a job in Developer Relations is knowing what the company is looking for. I agree with this sentiment because it also helps you determine how you’re going to shine.

Cultivate a Strong First Impression

I’m not great at first impressions because I get super anxious. I believe there are several moments to change people’s minds about you. However, first impressions help set the trajectory of your time at the company. When you make a positive first impression, it’s easier to get buy-in from colleagues and support from the developer community.

My personal experience:

After I got my offer, I made my first contribution to open source, and I wrote a blog post called “Conquering the fear of contributing to open source”. I tweeted the blog post on the first day of my job at GitHub.

Beyond views and retweets, I was asked to do a keynote at All Things Open on this topic. And I turned this into a talk for other conferences. I didn’t write the blog post in hopes of speaking at a conference. I was just over eager about the job, but it helped to craft my brand as authentic, vulnerable, approachable, and passionate about open source.

This showed my team my work’s caliber and resonated within the developer community, placing me on their radar.

Check out my tips on starting your first DevRel job to learn more.

Identify what the company cares about

By identifying your company's goals and aligning your efforts accordingly, you can ensure that your work resonates with the company's strategic direction and contributes positively to the developer community's understanding and adoption of key tools. Read your company and team goals occasionally because those goals will evolve over time.

Here are some helpful questions to ask yourself:

• Does this product make the company more money?

• Did they invest heavily into this product?

• Are they talking about this product a lot in meetings?

• Does it seem like this product aligns with industry trends?

• Is the company and its customers still learning how to use this product and how this product could be valuable?

My personal experience:

For me, GitHub Copilot seemed like something I should invest my time in. When I started working at GitHub, I initially focused on open source and GitHub Pages, but as the company's focus shifted to tools like GitHub Copilot and GitHub Codespaces, I realized I needed to approach my job more strategically. GitHub Copilot received substantial investments from GitHub, Microsoft, and OpenAI. However, throughout the developer community, there were mixed reviews and miseducation about how GitHub Copilot worked. It was also evident that AI pair programming tools and generative AI were an industry trend. At the time, GitHub was still experimenting with how developers could use GitHub Copilot, and developers were still trying to learn how to use it too.

For me, this was a serendipitous time and opportunity to learn about GitHub Copilot. I wanted to figure out: Were the developer complaints valid? If yes, I would try to work with my coworkers to meet their needs. Were they misinformed? If yes, I would figure out how to educate them. And if it was both, I would do both.

Use the product as a beginner

One effective strategy for aligning yourself with your company's goals and deepening your impact as a developer advocate is to fully immerse yourself in the products or tools you're promoting – from a beginner's perspective. It's common for companies to grant early access to developer advocates and other staff members before a product is made available to the general public. Use this as an opportunity to transition from a state of relative unfamiliarity to true expert before the product's official launch.

My personal experience:

When GitHub Copilot came out, I experimented with it. I was skeptical at first. My initial impression: So is GitHub Copilot autocomplete that sometimes doesn’t autocomplete? What’s the point?

As developers started to question the validity of the product and even direct questions toward me, I increased my usage and began to dig into how the tool actually worked. I wanted to confidently and knowledgeably respond to their inquiries.

Over time, I went from skeptic to enthusiast. It's easy to dismiss an innovation at first glance, but using the product to gain my own perspective enhanced my ability to authentically advocate for the product.

Document your first-time experiences

Many times, we prefer to wait until we have an elaborate, complex implementation of a tool, but some products need “getting started” or “hello world” examples.

My personal experience:

At first, I couldn’t get GitHub Copilot to reproduce anything. It would only do something for the first time and never do it again. I finally found success in promoting GitHub Copilot to write a binary search algorithm. I took that example and wrote about it.

Keep in mind, the product you advocate for doesn’t have to be new or groundbreaking. it’s new to you, and it’s new to someone else, so your perspective on getting started is valuable. Sometimes, I would even tweet out my excitement when I got GitHub Copilot to do something that I didn’t expect it to do! Knowledge sharing before you gain ultimate expertise is super valuable for anyone who is a beginner user of that product.

Create fun, memorable demos

People may argue with me about this, but if you’re trying to create awareness about a product, all of your demos don’t have to be practical. It’s okay to create a few demos that are eye-catching or fun to make people curious about the product. To make it fun and memorable, try integrating trending pop culture phenomena, emerging technologies, or both.

The first time I realized the value in small, but creative demos was when I saw Lizzie Siegle do a presentation about Twilio. In her demo, she calls and messages people in the audience, then they get “rick rolled.” Out of all the talks and demos that day, Lizzie’s demonstration stood out. Here are a few developer advocates who I believe are also great at producing creative demos: Colby Fayock, Salma Alam-Naylor, and Hassan El Mghari. One of Hassan’s most popular demos is RoomGPT, which uses AI to redesign rooms.

Reuse that content – take your demo and turn it into a blog post, a conference talk, a webinar, a workshop, a tweet, and a TikTok.

My personal experience:

“I wrote this tweet with Copilot” became almost a meme for me. Every time I presented about GitHub Copilot, I did a demo where I would write a comment prompting GitHub Copilot to generate the code that calls the Twitter API to post a tweet that said, “I wrote this tweet with Copilot and I’m at x conference right now.” True, nobody would typically use GitHub Copilot to publish tweets, but that’s not the point. The goal was to spark awareness of GitHub Copilot. As a result, the tweet:

• Piqued people’s interest: At the time, the developer community was popping on Twitter and I wanted people to wonder “How could GitHub Copilot write tweets? Should I check out this product?”

• Community engagement: I saw other people tweet, “I wrote this tweet with Copilot” meaning they tried out the demo too.

• Invitation from conferences: Some conference organizers invite me to do the talk at their conference because they wanted me to post that I wrote a tweet with Copilot, and I was at their conference.

• Some practical utility: Even though the demo is silly, it showed that GitHub Copilot can help you interact with an API in a language that you are unfamiliar with.

Integration with widely used frameworks, APIs, and tools

When you build with and use a product you're advocating for, you become an expert in it. However, you don’t just have to keep the product within your company’s ecosystem.

Here are my reasons for integrating other technologies with your product:

• It helps you become aware of the limitations of the product

• It makes it easy for developers to integrate the product into their daily workflow. For example: If they’re often using TypeScript, but your demos are only in Python, they may not realize you can use your company’s product with TypeScript.

• You may catch the attention of people who built those frameworks or build with those frameworks, which presents an opportunity to collaborate.

As a result, you can introduce a novel avenue to an entirely fresh audience.

My personal experience

I realized the importance of building examples with other frameworks when people would ask me, “Does this work with React or Astro?”, but I didn’t know the answer. People would also ask me things like does GitHub Copilot work better if you’re using it in a new project or using it in a large codebase with legacy code. I could try to ask other developers for their experience, but with a product so new, I felt more confident saying yes or no if I’ve tried it out on my own.

So, I started to build little projects with different frameworks. I also used GitHub Copilot when contributing to large open source projects. Now, I can confidently answer, “Yes, and here’s how you do it.”

Make it practical

As you build and integrate the product into your daily workflow, the use cases of the product become more evident. Start taking notes and creating content around these use cases. It’s helpful to lean into your developer community to figure out how they are using the product, too. There may be experts among your users that you can feature and collaborate with.

My personal experience

My team and I helped people see the value in GitHub Copilot by showing them that you can leverage GitHub Copilot for:

• Adding code snippets to documentation

• Brainstorming

• Syntax recollection

• Unit testing

• Converting applications from Javascript to TypeScript

I believe this encouraged developers to adopt GitHub Copilot because they realized it was more than just autocomplete.

Listen to developers

As you’re creating content, take a look at the questions and confusion developers have about the tool you advocate for. You may find their inquiries on social media platforms or your company’s discussion board. You can create content answering those questions. I also suggest maintaining a periodic session where you meet with product managers to express the pain points of users and you all can work together to figure out how to solve them. This way you can improve the overall developer experience through content and product improvements.

My personal experience

I often saw development teams wonder if it was worth it to purchase GitHub Copilot for Business. In turn, I wrote a blog post called, “Can GitHub Copilot be a valuable investment for my team?”

I also saw many people complaining that GitHub Copilot’s suggestions were inadequate and distracting. I empathize with that experience. However, I had a ton of tricks for getting optimal results for GitHub Copilot, so I wrote a blog post called, “A Beginner’s Guide for Prompt Engineering with GitHub Copilot.” To my surprise, my CEO shared this blog post with customers to improve their experience with GitHub Copilot. Writing that blog post strengthened my impact on the company internally.

Thought leadership

There is merit in going beyond how to use the product by providing your thoughts on how the product can transform the industry. We can start productive discourse by challenging our industry leaders.

My personal experience

When people argued that GitHub Copilot could limit learning, I wrote a blog post called, “How I’m using GitHub Copilot to learn p5.js”, where I talk about taking an intentional and strategic approach to learning a new programming language alongside an AI pair programmer.

I also wrote blog posts and delivered conference talks about how GitHub Codespaces and other cloud-based IDEs are catalysts for diversity, equity, and inclusion.

Like I mentioned earlier, we are influencers and we have the power to invoke a paradigm shift, challenge norms, and start conversations that can reshape the tech industry.

Ask yourself the question: How can we leverage this developer productivity tool to ethically improve our society?

Teach your company

Developer Advocacy is even more effective when other people in the company are advocating for the product. You’re not the only one who needs to be knowledgeable about your company’s developer tools. Some technologists within your organization like to speak at conferences and write blog posts, too! There are individuals in customer success, support, product, engineering, legal, and leadership who may need to know more about how the product works, so they can successfully do their job. As a developer advocate, you may have the most experience using the product, so share that experience internally.

My personal experience

As GitHub and Microsoft have been focusing more on artificial intelligence and GitHub Copilot, my coworkers have been looking to increase their knowledge on the product, so they could best do their jobs. Some people may have initially been on different teams, but now they’ve moved to a Copilot-focused team. To assist in the knowledge transfer, I shared slide decks and repositories with Microsoft and GitHub, so that anyone can feel confident speaking about GitHub Copilot. I also did presentations:

• Introducing Customer Success managers at Microsoft to GitHub Copilot.

• During GitHub’s Day of Learning, I presented a talk called “How to talk about GitHub Copilot” to the entire company.

• I showed GitHub Campus Experts how to talk about GitHub Copilot as well.

In essence, I’m creating more knowledgeable advocates for the product.

The beauty of this is now I won’t be one of the few people at my company that can speak about GitHub Copilot. Other people can, too! Less work for me, haha.

Conclusion

By embracing authenticity, cultivating expertise, and engaging with tools from a beginner's perspective, you're not just advocating products – you're shaping the narrative of innovation itself.

As you code, create, and collaborate, remember that your influence extends beyond the immediate. It's in the connections you foster, the solutions you inspire, and the conversations you initiate. I believe developer advocacy isn't just about tools; it's about catalyzing change and leaving an indelible mark on the tech landscape.

So, step into your role with confidence. Your journey is a beacon, guiding others through the ever-evolving world of technology. Embrace the power of your impact, and know that your dedication will echo through the codebase, the community, and the future of tech.

The blog post was filled with my opinions, but it’s not the only way to do developer advocacy. What approaches do you take to help you make an impact within your developer community and within your company?

Please note: I used ChatGPT to write my conclusion because I am not great with writing conclusions.

Due to the hectic move of my life, I didn’t have reliable internet, so I couldn't hop on Zoom calls, watch Twitch streams, or host webinars for most of July. This was a blessing in disguise because it was the perfect opportunity to experiment with different technologies, despite the painfully slow execution times due to unreliable internet.

With some of that time, I developed a prototype for a to-do list on steroids, which I’ve named Time Blind. This application allows users to create a to-do list and then expand each task to identify subtasks and estimate how long each task will realistically take.

What is the purpose of the application?

It sounds fictitious, but time blindness is the inability to recognize when time has passed or to estimate how long something will take. Many people with ADHD or autism struggle with this. I struggle with this. I’m really glad I found a term for this condition because I used to be really hard on myself when I was late to appointments

While some might suggest better planning as a solution, it's not that simple for those of us who either overestimate our capabilities or become so engrossed in a task that we lose track of time. For instance, I might plan to attend a party at 2pm and decide to start getting ready at noon. However, in the interim, I convince myself that I can wash dishes, do laundry, wash my hair (a process that takes at least 3 hours as a black woman), cook, and drive. Suddenly, it's 1:55 pm, and I'm just getting into my car.

I once came across an application that addressed this issue, but when I couldn't find it again, I decided to create my own solution.

Disclaimer: This article is not a step-by-step tutorial, but rather a journey through my thought process and experiences as I explored these technologies. My aim is to inspire and provide insights into how these tools can be utilized in different ways. Please bear in mind that this was my first encounter with some of these technologies, so there may be instances where I haven't followed best practices. That's part of the learning process! This project was created for fun, and as such, the focus wasn't on aesthetics. The UI is basic (a little ugly to be honest) and functional, as my expertise lies in developer relations rather than design. Enjoy the read!

The Tech Stack: A Blend of the Familiar and the New

In this project, I've combined tools and technologies that I'm well-versed in with some that were new to me.

Familiar

• Next.js - This React framework is a favorite of mine, particularly for its ease in defining serverless API endpoints.

• GitHub Pages - A free hosting solution for frontend web apps, it was a perfect fit for the initial iteration of my project (before I added a backend).

• GitHub Actions - I leveraged GitHub Actions to deploy my Next.js app to GitHub Pages.

• Copilot Chat - This was handy for generating JS Doc comments and unit tests for my code.

• OpenAI GPT-4 - While I wouldn't call myself an expert, I've dabbled with OpenAI's models before. For this app, I used GPT-4 to break tasks into subtasks and estimate the time each subtask would take.

• GitHub Codespaces - I love using this because of its boilerplate templates, which save me from writing boilerplate code myself. It also makes it easier to create shareable demos for other developers to try out.

New to me

• Web5 SDK - This is an SDK for building decentralized web apps with DIDs, VCs, and DWNs. The central goal of Web 5 is to empower users with full control over their identity and data. This sets it apart from Web 3 protocols, which primarily identify users through crypto wallet addresses. In contrast, Web 5 introduces innovative features like self-owned decentralized identifiers, verifiable credentials, and decentralized web nodes, enabling secure data storage and message relaying. The value of decentralized applications became more evident to me after Elon purchased Twitter. He’s made so many changes that I don’t appreciate. Elon even changed the name of Twitter to X and took someone’s handle. That made me realize how easily someone can take the handle @blackgirlbytes. All of those factors piqued my interest in decentralization. The ease of storing data in the DWN was a bonus, requiring less overhead than a SQL database.

• Web5 assistant - There’s a ChatGPT plugin for the Web5 SDK. It was really helpful in navigating a technology that I’m not familiar with.

• Applitools - I used this to implement automated visual tests to my application.

• Playwright - I used Playwright for unit tests.

• Railway - I needed a different hosting solution since GitHub Pages only supports frontend applications. I initially chose Vercel, but the long API calls to OpenAI would time out on the Hobby plan. Railway didn't have this limitation, but I'm currently using the trial plan, so I'm not sure how long I can use it for free.

Building the application

GitHub Codespace Next.js template

Ah, GitHub Codespace templates – the reason why I will never run npx create-next-app@latest. I don’t hate running this command; I’m just a bit of a lazy developer. GitHub Codespace templates have a ton of ready-made boilerplate applications written in various, popular frameworks which makes it easy for me to get up and running in a sandbox environment.

You can create a Next.js GitHub Codespace template by navigating to https://github.com/codespaces/templates. Then choosing the “Use this template” button for Next.js. This will trigger a codespace to open with boilerplate Next.js code with a browser preview.

What I particularly appreciate about this setup is the pre-configured dev container. It ensures that anyone who opens my project gets a running environment without any additional configuration on their part. This feature significantly streamlines the process of setting up a development environment, especially for new contributors or team members.

GitHub Codespaces also supports environment variables and secrets. This means you can open my repository in a GitHub Codespace without worrying about generating an API key. I've already stored one in my repository settings, so there's no need to figure out how to securely share environment variables with multiple people.

Understanding Web5 basics

Authentication

To authenticate users, Web 5 uses a W3C standard called Decentralized Identifiers (DID). A decentralized identifier is a verifiable id that can connect me to Web 5. The identifiers we use today are often tied to a specific service provider. For example, I’m @blackgirlbytes on Twitter and GitHub. In the Web 5 ecosystem, my id could look something like:

did:key:z6MkhvthBZDxVvLUswRey729CquxMiaoYXrT5SYbCAATc8V9

Here’s how you can instantiate and connect to a DWN using a decentralized identifier:

const { web5, did: aliceDid } = await Web5.connect();

Here’s what how I implemented this for Next.js in my src/pages/index.js file:

const [web5Instance, setWeb5Instance] = useState(null);
const [aliceDid, setAliceDid] = useState(null);

useEffect(() => {
    async function connectToWeb5() {
      const { web5, did } = await Web5.connect();
      setWeb5Instance(web5);
      setAliceDid(did);
    }

    connectToWeb5();

  }, []);

CRUD

Similar to REST APIs, a user can interact with Distributed Web Nodes (DWN) using CRUD principles. The DWN is our personal data store, so we’ll need to create, read, update, and delete data to interact with our store.

Create (write) records

const { record } = await web5.dwn.records.create({
  data: "Its me, snitches",
  message: {
    dataFormat: 'text/plain',
  },
});

console.log('writeResult', record);

Read records

const readResult = await record.data.text();
console.log('readResult', readResult)

Update (edit) records

const updateResult = await record.update({data: "Professional bug maker"});
console.log('updateResult', updateResult)

Delete records

const deleteResult = await record.delete();
console.log('deleteResult', deleteResult)

Starting with the To Do list

Before building Time Blind, I started by building a to-do list. I wanted to get the core functionality down, especially since I was new to the Web5 SDK. I built a few components that leveraged the methods I mentioned above.

Here’s an example:

async function addTask(event) {
    event.preventDefault(); // Prevent form from submitting and refreshing the page
    if (web5Instance && aliceDid && newTask.trim() !== '') {
      const taskData = {
        '@context': 'https://schema.org/',
        '@type': 'Action',
        name: newTask,
        completed: false,
      };

      const { record } = await web5Instance.dwn.records.create({
        data: taskData,
        message: {
          dataFormat: 'application/json',
          schema: 'https://schema.org/Action',
        },
      });

      // Send the record to the DWN.
      await record.send(aliceDid);

      setTasks((prevTasks) => [...prevTasks, { id: record.id, text: newTask }]);
      setNewTask('');
    }
  }

When a user creates a task, the application uses the dwn.records.create method from the Web5.js SDK. This method creates a new record with the task data and sends it to the Decentralized Web Node (DWN) associated with the user's Decentralized Identifier (DID). The task data includes the task name and its completion status.

You might’ve noticed that I’m using a schema. By using a schema, I’m ensuring that my tasks have a consistent, predictable structure.

If you want to check out the code for this to-do list, here is the repository.

Copilot Chat for generating tests with Playwright and Applitools

I’m not super familiar with Playwright or Applitools, so I leaned on Copilot Chat to help me generate tests for me. Below are examples of interactions I had with Copilot Chat to generate the unit tests.

Copilot Chat generates more tests for me

I asked Copilot Chat for clarification on some code it suggested

I asked Copilot Chat for alternative suggestions after realizing the initial suggestion won’t work in my codebase.

Copilot Chat gave me advice on how to navigate the Applitools Eyes interface.

Deploying with GitHub Pages with GitHub Actions

I used a GitHub Action to deploy my Next.js app to GitHub Pages.. It's important to note that this approach is suitable for applications without a server. . Upon successful deployment, the workflow automatically generated a URL for me: https://blackgirlbytes.github.io/decentralized-to-do-list/.

Here’s what the action workflow looked like:

# Sample workflow for building and deploying a Next.js site to GitHub Pages
#
# To get started with Next.js see: https://nextjs.org/docs/getting-started
#
name: Deploy Next.js site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["main"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Detect package manager
        id: detect-package-manager
        run: |
          if [ -f "${{ github.workspace }}/yarn.lock" ]; then
            echo "manager=yarn" >> $GITHUB_OUTPUT
            echo "command=install" >> $GITHUB_OUTPUT
            echo "runner=yarn" >> $GITHUB_OUTPUT
            exit 0
          elif [ -f "${{ github.workspace }}/package.json" ]; then
            echo "manager=npm" >> $GITHUB_OUTPUT
            echo "command=ci" >> $GITHUB_OUTPUT
            echo "runner=npx --no-install" >> $GITHUB_OUTPUT
            exit 0
          else
            echo "Unable to determine package manager"
            exit 1
          fi
      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: "16"
          cache: ${{ steps.detect-package-manager.outputs.manager }}
      - name: Setup Pages
        uses: actions/configure-pages@v3
        with:
          # Automatically inject basePath in your Next.js configuration file and disable
          # server side image optimization (https://nextjs.org/docs/api-reference/next/image#unoptimized).
          #
          # You may remove this line if you want to manage the configuration yourself.
          static_site_generator: next
      - name: Restore cache
        uses: actions/cache@v3
        with:
          path: |
            .next/cache
          # Generate a new cache whenever packages or source files change.
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-${{ hashFiles('**.[jt]s', '**.[jt]sx') }}
          # If source files changed but packages didn't, rebuild from a prior cache.
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-
      - name: Install dependencies
        run: ${{ steps.detect-package-manager.outputs.manager }} ${{ steps.detect-package-manager.outputs.command }}
      - name: Build with Next.js
        run: ${{ steps.detect-package-manager.outputs.runner }} next build
      - name: Static HTML export with Next.js
        run: ${{ steps.detect-package-manager.outputs.runner }} next export
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v2
        with:
          path: ./out

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v2

Incorporating AI for task breakdown and estimation

With a functional to-do list in place, the next step was to incorporate AI to dissect each task on the list and provide estimated completion times. I added this on the server rather than the frontend to maintain the confidentiality of the API key required to make calls to the OpenAI model.

In my request to OpenAI, I specified that I wanted to use the GPT-4 model, I gave the model an identity, and I made a request. You can see the code below:

openai.createChatCompletion({
      model: "gpt-4", // Using GPT-4
      messages: [
        { "role": "user", "content": `You are a helpful planning assistant. Please help me break down the following task on my to-do list with an estimated time that it could take: ${task}` },
      ],
    });

My request prompts the AI model to act as a helpful planning assistant, breaking down the specified task and estimating the time it might take to complete.

Copilot Chat for documenting my code

By highlighting the code, I can prompt Copilot Chat to generate JS Doc comments for my code.

Here’s an example of the JS Doc comments that Copilot Chat generated for my API endpoint:

/**
 * This function is an API endpoint that generates a task breakdown using OpenAI's GPT-4 model.
 * It expects a POST request with a body containing a 'tasks' property.
 * If the OpenAI API key is not configured or if the 'tasks' property is not provided, it responds with an error.
 * If the OpenAI API request fails, it responds with the error returned by the OpenAI API.
 * If the OpenAI API request is successful, it responds with the generated task breakdown.
 *
 * @param {Object} req - The request object. It should have a 'body' property with a 'tasks' property.
 * @param {Object} res - The response object. It is used to send the response back to the client.
 * @returns {Promise<void>} - A Promise that resolves when the response has been sent.
 */
const { Configuration, OpenAIApi } = require("openai");

const configuration = new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
});
const openai = new OpenAIApi(configuration);

export default async function (req, res) {
  if (!configuration.apiKey) {
    res.status(500).json({
      error: {
        message: "OpenAI API key not configured, please follow instructions in README.md",
      }
    });
    return;
  }

  const task = req.body.tasks || '';
  if (task === '') {
    res.status(400).json({
      error: {
        message: "Please enter a valid task",
      }
    });
    return;
  }

  try {
    const completion = await openai.createChatCompletion({
      model: "gpt-4", // Using GPT-4
      messages: [
        { "role": "user", "content": `You are a helpful planning assistant. Please help me break down the following task on my to-do list with an estimated time that it could take: ${task}` },
      ],
    });

    const result = completion.data.choices[0].message.content;
    res.status(200).json({ result });
  } catch (error) {
    // Consider adjusting the error handling logic for your use case
    if (error.response) {
      console.error(error.response.status, error.response.data);
      res.status(error.response.status).json(error.response.data);
    } else {
      console.error(`Error with OpenAI API request: ${error.message}`);
      res.status(500).json({
        error: {
          message: 'An error occurred during your request.',
        }
      });
    }
  }
}

Deploying with Railway

I chose to deploy my application to Railway because I needed a hosting solution that supports full stack applications. This worked perfectly for me! However, I did encounter a few challenges while navigating through Railway's user interface. For example, I just wanted to deploy my repository, and I got stuck in a loop of configuring the GitHub App for Railway. The part of the documentation I checked lacked visual aids, and I’m a visual learner, so that was hard for me. I ended up watching a YouTube video to navigate the platform. Despite these minor hiccups, my overall experience with Railway was positive, and I was particularly pleased with the successful deployment of my application.

Final thoughts

Struggles

The app is unbearably slow. My proficiency in performance optimization is admittedly lacking, as I've never held a role where optimizing an application's speed was a primary responsibility. I believe the key to enhancing my application's performance lies in the GPT-4 calls. I was told making my prompt more specific should help, but I’m not sure how. If you have suggestions for improvement, feel free to make a pull request. I would love to learn from folks.

I had fun

Coding for fun is therapeutic. Hopefully, I make time to do this again.

Be easy on me

Like I mentioned, this is not a perfect application written in perfect code. I’m just sharing it as a means for learning in public, for insight, and to start a conversation.

Check it out

Decentralized to do list

You can access my decentralized to do list here: https://blackgirlbytes.github.io/decentralized-to-do-list/

If you want to improve it, you can make a pull request: https://github.com/blackgirlbytes/decentralized-to-do-list

Time Blind

You can access my Time Blind app here: https://time-blind-production.up.railway.app/

If you want to improve it, you can make a pull request: https://github.com/blackgirlbytes/time-blind

If it stops working, you can open an issue in my repository!

What are your opinions on the different technologies that I’ve leveraged? What tools and technologies should I try next? Comment below.

Part of the issue is that we’re laser-focused on the wrong things. We often build our products and companies that fine-tune the lives of those who already have a head start. For example: we have multiple platforms that make sharing documents easier or share code. We’re using artificial intelligence to accelerate developer productivity. However, we are missing technological breakthroughs that address fundamental human predicaments such as hunger, homelessness, and the glaring lack of diversity in the tech sphere. I’m not naive. I acknowledge that this is because these problems take more effort to solve. Perhap, it doesn’t have to be such a heavy lift. The tools we’ve developed to solve first-world problems have the potential to uplift those marginalized by circumstance. Specifically, I believe that while container technology streamlines software deployment, it also shatters barriers, paving the way for a more equitable landscape. In this blog post, we’ll explore the powerful synergy between containerization and equity in the tech industry.

We’ll break this down by understanding the definitions of:

• Privilege

• Equality

• Equity

Then, we will take a look at:

• Why we use containers

• The history of container technology

• And how they promote equity in our industry

Privilege

Privilege is a good thing, but the word can sometimes evoke unintended negative reactions. The term “privilege” is often misconstrued as “you didn’t work for your achievements.” However, privilege refers to the fact that you have access to something that other people may not have. It's a universal truth: everyone holds some form of privilege. There are different types of privilege including, but not limited to: race, education, sexuality, gender, class, language, ethnicity, ability, and age.

A prime example of someone who doesn’t always acknowledge his privilege is Drake.

While his song "Started from the Bottom" chronicles his path to stardom, it sometimes obscures the fact that he had a head start due to his acting career as a child star on Degrassi: The Next Generation. Since becoming a rapper, he’s amassed over:

• 5 Grammys

• 7 studio albums

• 3 compilation albums

• 4 extended plays

• 7 mixtapes

• 140 singles

• 84 music videos

This is not to diminish his accomplishments, but rather to highlight how privilege plays a role. He worked hard to be one of the few Canadian rappers who are popular in the United States.

On a more personal note, my own life is full of disadvantages—living in homeless shelters, being an immigrant, a woman, and Black. But amid these experiences, I acknowledge the privileges I hold— a supportive family, access to education, a role at GitHub, and a public platform as a Developer Advocate.

The important thing is that we use our privileges to uplift others.

Equity vs. Equality

Equity and equality are terms that are often used interchangeably, but they have different meanings.

Equality means each individual or group of people is given the same resources or opportunities. Equity recognizes that each person has different circumstances and allocates the exact resources and opportunities needed to reach an equal outcome.

What is a container?

According to the official Docker website, “A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another”

The way I think of it is: a container holds code for the app, other tools that it depends on, and settings that make sure it works consistently across different computers. In this way, the application will behave the same regardless of whether it resides on your computer, production, or your uncle's 2015 Dell machine. Containers enable software engineers to program in a consistent environment. Your dev environment mirrors production with the same operating system, configurations, and dependencies. This ensures bugs and features behave the same across all environments.

Why containers?

If you’re a developer, and you’ve ever said the words, “It works on my machine”, you know the pain and embarrassment of working tirelessly on a project, but you’re unable to show the fruit of your labor to your coworkers because it doesn’t work on their computers or on a different environment. Because of this, the software industry has spent years in pursuit of a solution to running and shipping software automatically reliably from one environment to another.

It was an incremental climb to developing a solution.

A brief history on container technology

Chroot

We started trying to solve this problem in the 1970s with chroot, which stands for “Change root.” It allows developers to change the root directory for a running process and its children. Developers can use chroot to create a new isolated environment with its own root directory. Creating isolated environments to build and test software helps developers ensure that software can run in specific environments and avoids potential conflicts with system libraries and dependencies.

Cgroups

In the 2000s, the industry created Cgroups, also known as control groups. They fairly manage and divide resources like CPU, memory, and storage among processes or groups of processes. This way each application isn’t fighting for resources. Cgroups are one of the building blocks of containerization because they help containers ensure they are receiving a fair share of resources.

Docker

Then, in March 2013, folks like Solomon Hykes popularized the use of containers. Docker, an open source platform, introduced a suite of management and packaging tools for containerization. It enables developers to create, deploy, and manage applications within containers. Overall, it made containers more accessible for technologists.

How container technology promotes equity

The reason that software development teams are not diverse is not because of a lack of interest from people of diverse and even underprivileged backgrounds. Common factors for a lack of diversity at a tech company are:

• Barriers to Entry: Many potential talents face difficulties accessing the field in the first place.

• Stunted Growth and Inclusivity: Even when they manage to enter, they often encounter challenges in advancing and feeling valued and included within their teams. After years of feeling stuck or excluded, disenfranchised people may feel more tempted to quit.

Barriers to entry exist for many reasons, including the following:

• Limited access to computers or limited access to devices with strong computing power

• Lack of knowledge on how to initiate their journey into software development.

Access

Container technology ushered in the emergence of other tools like Replit, GitPod, and GitHub Codespaces, which empower people with low computing power or limited computing resources to code even on devices like their phones or iPads. These tools run in your browser, which means that you consume less of your machine's resources, so you don’t need heavy computing power.

Time-to-start

Whether you are joining a team, contributing to an open source, or you’re just trying to learn how to code, setting up your environment as a new developer is an overwhelming task. For companies, project configurations can be automated, ensuring that any developer contributing to the codebase can effortlessly set up and run projects. If you’re a single developer, trying to learn a new programming language or framework, you can leverage GitHub Codespace Templates. We have templates for frameworks and languages like, Next.js, Ruby, Django with boilerplate code. This immediate access circumvents the time-consuming setup phase.

Stunted Growth and Inclusivity

From onboarding to deployment, minorities don’t always get the mentorship and sponsorship they deserve, which can lead to feeling stuck in your career and excluded.

Onboarding

Navigating outdated documentation during onboarding can be frustrating, underscoring the value of tools like GitHub Codespaces.

Getting help

Collaborating on remote teams can pose challenges in sharing local environments with coworkers. GitHub Codespaces provides solutions through features like port forwarding and liveshare, facilitating seamless collaboration and troubleshooting.

Deployment

Leveraging container technology like GitHub Codespaces minimizes the risk of discrepancies between local, staging, and production environments. This ensures a more consistent and reliable development experience.

The hard part

I work at GitHub, so I’ll focus on one tool I know most intimately: GitHub Codespaces. Although GitHub Codespaces streamlines the onboarding process, it uses configuration-as-code to establish a consistent development environment.

In some of my past blog posts, I outline how to set up a development container in GitHub Codespaces for a:

• Next.js/Typescript project

• Python project

The TLDR, to make GitHub Codespaces install and run your project, you should provide your devcontainer with the following:

• Installation commands like npm install

• Execution commands npm run dev

• The port you want the project to run on like [forwardPort: 3000]

• And Codespace lifecycle properties like [postCreateCommand] - These control when the commands you provided should run.

Below are examples of two devcontainer.json files that I created for specific projects.

Python

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  "postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

 // Configure tool-specific properties.

  "customizations": {

        "codespaces": {

            "openFiles": [

                ".well-known/ai-plugin.json",

                "openapi.yaml"

            ]

        }

    }

}

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Next.js/TypeScript

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
{
    "name": "Node.js & TypeScript",
    "image": "mcr.microsoft.com/devcontainers/typescript-node:0-18",
    "waitFor": "onCreateCommand",
    "updateContentCommand": "pnpm install",
    "postAttachCommand": "pnpm dev",
    "customizations": {
        "vscode": {
            "extensions": [
                "streetsidesoftware.code-spell-checker",
                "dbaeumer.vscode-eslint",
                "esbenp.prettier-vscode",
                "DavidAnson.vscode-markdownlint",
                "ms-vscode-remote.remote-containers"
            ]
        }
    },
    "portsAttributes": {
        "3000": {
            "label": "Application",
            "onAutoForward": "openPreview"
        }
    },
    "forwardPorts": [3000]
}

This is only a start

Containers help you standardize environments and use less of your local machine's resources. This lowers the barriers for folks with:

• Low computing power

• Low access to coding education

• A tough onboarding process

Looking forward, I hope that we can invest more time and effort into the following technological advancements:

• Bridging the digital divide by improving internet access for folks in more underdeveloped countries or rural areas

• Introduce coding to underrepresented folks at an early stage

• Prioritize accessibility for developers with visible and non-visible disabilities

I’ll leave you with these thoughts: rather than ignoring the value of DEI, how can our industry build upon already existing technologies to drive impactful change for DEI? And what issues do you hope our industry addresses in the near future?

Because I’m an avid advocate for GitHub Copilot and other forms of AI-assisted programming, people often ask me the same questions: “Does GitHub Copilot stunt learning? Will it limit my ability to learn code? Will I become overly reliant on it?” Concerns about stunted learning, limited coding abilities, and over reliance are valid. However, based on my experience, intentional use of GitHub Copilot has actually sharpened my coding skills. I’m an experienced JavaScript developer who used GitHub Copilot to gain proficiency in reading, writing, and debugging Python. While I successfully combined my existing coding expertise with GitHub Copilot's code generation abilities, I am not great at verbally explaining how I used it as a learning tool. In conversations with developer friends and even in a recent conference talk, I felt I could not deliver convincing evidence that this works for me and can work for others, too! My inability to express my thoughts makes me feel like I’m mindlessly advocating for a company’s product just because I work there. I want to demonstrate its value as a learning tool rather than a crutch to empower developers. Generative AI is here to stay and evolve whether we like it or not. We can either cower in fear or learn to leverage it for the well-being of society.

In this blog post, I aim to articulate this methodology effectively. Writing helps me organize my thoughts, so I'm sharing my insights with the hope of benefiting others. While the primary reason I write is for myself, I also believe that using my company's tools and sharing best practices is part of effective Developer Advocacy. By understanding how GitHub Copilot can be responsibly used as a learning tool, readers can explore more use cases for AI-assisted programming. Throughout this post, I will illustrate how to use GitHub Copilot to learn a programming language or framework, with a focus on my current experience with p5.js.

What is p5.js and why am I learning it?

P5.js is an open source JavaScript library for creative coding, with a focus on making coding accessible and inclusive.

I opted to learn p5.js as a means to rekindle my dormant creative side. Ever since I learned how to code, I stopped tapping into my creative side. I’ve learned that the purpose of creative coding is to make something expressive instead of something functional, and I need that in my life.I aspire to create purely expressive works, unburdened by the need to cater to a broad audience or meet functional demands. It's liberating to code free from concerns such as fixing bugs for a company's financial impact or facing potential criticism on blog posts about the usefulness of my demos.

What is GitHub Copilot?

It's an AI pair programmer that draws context from comments and code and suggests individual lines and whole functions instantly!

Here are some past posts I've written about GitHub Copilot if you want to learn more:

• How to send a tweet with GitHub Copilot

• A beginner’s guide to prompt engineering with GitHub Copilot

• Could GitHub Copilot be a valuable investment for my team?

• How to use GitHub Copilot: prompts, tips, and use cases

• How I used GitHub Copilot to build a browser extension

• 8 things you didn’t know you could do with GitHub Copilot

• How to build a markdown editor in two minutes (with GitHub Copilot)

Here are some other informative posts about GitHub Copilot I didn't write:

• Inside GitHub: Working with the LLMs behind GitHub Copilot

• The economic impact of the AI-powered developer lifecycle and lessons from GitHub Copilot

• Survey reveals AI’s impact on the developer experience

• Responsible AI pair programming with GitHub Copilot

• Web Summit Rio 2023: Building an app in 18 minutes with GitHub Copilot X

How I learn programming concepts

Before we get into how we use GitHub Copilot to learn, I want to debunk some misconceptions about learning programming concepts. From my experience, developers tend to have a shared conventional way that people should learn to code that may make them rebuttal the way that GitHub Copilot helps you to learn. Everyone learns differently. Some people learn by doing, while some people learn through observation. However, I think there’s a difference between how we think we learn a programming language versus the reality of how we actually learn a programming language. Below are a few examples:

Expectation - Learning to code is straightforward

When I look back at my coding education, I remember the experience in a straightforward manner that looked something like:

1. I listened to an instructor (college, bootcamp, or online video) introduce a concept

2. I watched the instructor demonstrate the concept

3. I applied what I learned from the class in my homework

Reality - Software engineering is a non-linear career path that involves various steps

The reality is coding is a continuous, non-linear journey. The “curse of knowledge” or “knowledge bias” often leads us to forget what learning code was really like. The curse of knowledge refers to the cognitive bias where individuals who possess knowledge or expertise in a particular subject find it difficult to remember or accurately assess the difficulty and challenges faced by novices or learners who are still acquiring that knowledge.

When I started teaching beginners to code, I sometimes felt frustrated. Why aren’t they quickly understanding the box model? I showed them a fun, but comprehensive illustration. They should get it.

Then, I realized how confusing learning the CSS Box Model was for me when I first learned to code. I remembered that there are senior engineers who still confuse padding with margin. And I remembered that I continue to struggle with other concepts every single day. (I still get confused with the useEffect hook and the Promise.all() method).

In practice, learning to code involves troubleshooting, reading documentation, copying code snippets, browsing Stack Overflow, and grappling with the frustration of code not working as expected during assignments. This aspect of the learning journey is often overlooked but is a common experience when mastering a new programming language or framework. Even today, when working with new technologies, I encounter similar frustrations.

Expectation - To get better at writing code, write more code.

Some of the most common advice for novice and experienced developers looking to improve their coding skills or to learn a new programming concept is to write more code

Reality - Improve your coding skills by reading code

Writing more code helps, but reading code is even better. My friend Ramón Huidobro introduced me to this book called The Programmer's Brain.

“What Every Programmer Needs to Know about Cognition" by Felienne Hermans. While Felienne acknowledges that writing code is important, she also emphasizes that our field doesn’t place enough importance or instruction on reading code. She believes in personalizing the learning process so that you can comprehend the code and improve your short-term, working, and long-term memory to become a better programmer. Watch one of Felienne’s presentations to learn more!

I believe that while you may not always understand snippets of code, it’s helpful to read code, so that you can recognize the notation and feel less overwhelmed by it over time.

Expectation - You have to understand why you write every single line of code

While I believe that code comprehension is key, I think there will always be times when we don’t understand code and that comprehension can grow over time. One of the biggest frustrations I had when I worked as a software engineer was that my coworkers wanted me to understand every single line of code that I wrote.

Them: Why did you write that? Me: I’m not sure. It’s something I saw online. I thought it was an interesting approach, but I don’t fully understand it. Them: Don’t just copy things you see online.

You might agree with my past coworkers, and what they’re saying holds some truth, but read the next paragraph to understand why I don’t fully agree with this mindset.

Reality - Copying code and procedures supports ritualistic learning

I’ve found that many engineers like the idea of knowing the why before the how. I, on the other hand, learn best from learning how to do something then after that I learn WHY I am doing something. It clicks better in my brain this way. Like I mentioned earlier, everyone learns differently.

Here’s an example: for 3 months straight from January 2018 to March 2018, I knew how to push code to GitHub, but I didn’t understand what any of the commands meant._ Why was I writing them? I had no clue. _I just knew I needed to type them in the terminal to get my code on GitHub. However, when I encountered problems, such as being unable to push due to lack of repository access or facing a merge conflict, I would Google the issues and gain more context about the solutions and how each command worked. After a few months, I learned the meaning of these commands and I knew how to navigate problems that came up around those commands. The approach didn’t inhibit my learning in any way because now I work at today’s most popular web-based hosting service for Git repositories.

This is not a made up way of learning. This approach is called ritualistic learning. It involves following a set of instructions or steps without necessarily comprehending the underlying principles or reasons behind them. Over time, as you gain more experience and exposure to the subject matter, your understanding gradually develops.

How GitHub Copilot helps me learn

For the sake of clarity (and me wanting to feel fancy), I’ll name the framework for using GitHub Copilot to learn a new programming concept: AI-Driven Learning. It incorporates 5 steps including:

• Conceptual Pseudocoding

• Syntax Familiarization

• Iteration

• AI Rubber Ducking

• Self-Directed Application

Let’s dive into each of the steps to understand what they mean and how to apply them!

Conceptual Pseudocoding

I discovered the importance of conceptual pseudocoding while planning my segment for the GitHub Universe Keynote in 2022. Collaborating with Jonathan Carter, the Technical Advisor to the CEO, we aimed to create a fun and visual demonstration of GitHub Copilot that could fit within the allotted 5-minute timeframe.

During our Slack brainstorming session, I had an epiphany! Why not showcase GitHub Copilot's capabilities by creating an image with p5.js? Jonathan liked the idea, and we were all set. There was just one tiny hitch – I had never written anything in p5.js before. Why did I suggest it in the first place? But then, a glimmer of hope emerged. Maybe I could grasp it quickly? How hard could it be? Perhaps less than an hour of learning would suffice. And now that I’m looking at code samples of p5.js, I’m not sure why there are so many numbers. Is this math?

After a few attempts of exchanging screenshots and screen recordings with Jonathan, we developed a plan to provide a comment at the top of the file, providing GitHub Copilot with the context of what we wanted GitHub Copilot to build. It said:

/* 
Draw a  draw a green house, 
with a blue roof, 
a red door,
 and two windows 
*/

This helped me to break down the different elements of my p5.js creation.

And just like magic, GitHub Copilot followed all the instructions.

This process helped GitHub Copilot understand our desired outcome and helped me, the programmer, gain clarity on what I wanted to achieve. Although pseudocoding is often emphasized in college, coding bootcamps, and interviews, it tends to be overlooked once we enter the industry. By writing comments that prompt and provide context to GitHub Copilot, developers can consider the application's functionality and structure thoughtfully.

To illustrate this further, let's create our own example by installing p5.js and GitHub Copilot and writing a high-level prompt to draw an ice-cream cone:

/* draw a light brown ice cream cone with

- a scoop of light pink ice cream

- a red cherry on top

*/

Syntax Familiarization

After you write a comment or some code, GitHub Copilot may suggest code. We call this ghost text. You can accept the ghost text by pressing tab. While many developers acknowledge that tabbing through your code boosts your productivity, they’re concerned that not typing code will reduce their memory for syntax, especially for beginners.

Intentionality plays a key role here. Although you're not actively typing the code, allowing GitHub Copilot to generate it provides exposure to the syntax and typical file structure of the language. At this stage, complete understanding of the code is not necessary, but continual exposure helps prevent it from appearing unfamiliar. This exposure primes your brain to break down the code more effectively, aiding comprehension.

I’ll draw a parallel between understanding complex words and understanding code through syntax familiarization to best illustrate my point.

I’m not afraid of big or unfamiliar words. Perhaps, reading them aloud is not my strong suit, but my brain is able to process the meaning of the words pretty quickly, and that’s because I learned Latin in middle school. I can infer that a word like, “soporific” means to make you sleepy. The prefix first half of the word “sopor” is Latin for “deep sleep”. The second half of the word “fic” is Latin for “to make.” Readers of this blog post might even be able to infer this even if they’re not familiar with Latin. They may recognize the word “fic” from the word “fiction”, which also implies that you’re making or inventing something from your mind.

Just as my previous knowledge of Latin helps me decipher complex words based on prefixes and suffixes, familiarity with code syntax enables you to infer meaning and context. Syntax familiarization offers additional benefits by exposing developers to various programming concepts that can be applied across languages. While specific syntax may differ, underlying principles remain consistent. This exposure broadens developers' mindsets, encourages exploration of diverse approaches and solutions, and facilitates knowledge transfer.

Take a look at this GIF where GitHub Copilot generated code to draw an ice cream cone:

While GitHub Copilot didn’t generate a perfect ice cream cone, I learned a couple of things about the syntax and the structure of the file:

• P5.js file start with a set up function

• The set up function uses a method called createCanvas, which I can infer initializes the canvas for our creation

• P5.js files also use a function called draw and this is where all the elements of our drawing will live

• I can determine the background color by using the method background and passing in RGB color codes

• I can create shapes like triangles, ellipses, and arcs by specifying the name of the shape and passing in numbers. Although, at the moment, I’m not exactly sure what the numbers do. I assume that they determine the size and position of the shapes.

• I can color the shapes using the method fill and passing in RGB color codes

By intentionally engaging with syntax familiarization, developers can leverage their prior knowledge, make inferences, and establish meaningful connections between different programming concepts.

Iteration

During conversations with my developer friends, the issue of GitHub Copilot generating flawed code often arises. They argue that this can mislead beginners and teach them poor programming practices. I won’t lie. Mindlessly trusting incorrect code generative code CAN mislead beginners. However, I believe that encountering imperfect code is an integral part of the learning process, regardless of whether GitHub Copilot is involved. When exploring a new programming language, especially at the beginning of my career, I often resort to copying code from StackOverflow, skimming through documentation, and pasting code snippets haphazardly. Sometimes, the code I copy doesn't even work, but it still provides a starting point and helps me grasp the problem at hand. With time, I learn better practices and approaches, gradually refining my skills.

The same principle applies to GitHub Copilot. In the example above, GitHub Copilot attempted to generate an ice cream cone with a light pink scoop and a cherry on top. However, the generated triangle for the cone had the pointy part facing upwards, whereas cones typically have the pointy part facing downwards. While it could be argued that GitHub Copilot misled me, I wouldn't have known how to create a triangle without its guidance. This presents an opportunity for me to debug and iterate on the generated code, enabling me to learn and develop a deeper understanding.

Though I may not fully comprehend the numerical notation used, I can modify the values to achieve the desired result.

Check out the GIF below to see how I adjusted the values to flip the triangle in the desired direction:

When GitHub Copilot offers code suggestions that contain minor errors or imperfections, it allows learners to adopt a hands-on approach. By attempting to execute the suggested code, identifying and resolving encountered issues, and subsequently refining the code to correct errors, learners gain practical experience in writing and editing within the given framework.

AI Rubber Ducking

With trial and error, I achieved the desired result, but I still don’t truly understand the numerical notation or why it worked. I can now see that the numbers for each triangle represent vertices, but I don’t know the formula. In this situation, I would love to have a conversation with someone more knowledgeable than me to get a better understanding, but I don’t want to bother anyone. Or maybe I can Google, but the search engine results don’t always have the answers for my specific use-case.

Fortunately, I have the option to engage in a conversation with my AI pair programmer using a tool called Copilot Chat. At GitHub, we have a suite of Copilot tools called Copilot X. These tools are made to help developers beyond their editor because we recognize developers do more than just code. One of the products within Copilot X is called Copilot Chat. Copilot Chat is an IDE extension that provides a ChatGPT-esque experience. It offers an IDE extension that provides a ChatGPT-esque experience, leveraging the context of your open files within the editor. From my experience, highlighting the relevant lines of code enhances Copilot Chat’s performance. Copilot Chat can generate code, unit tests, explanations, and more. Learn more about Copilot Chat’s latest and greatest updates for June 2023 here. Try out Copilot Chat’s slash commands to maximize its benefits! \

For our particular scenario, I’ll use Copilot Chat to help me better understand the generated p5.js code. I’ll ask clarifying questions like:

Can you explain this line of code to me? triangle(100, 200, 300, 200, 200, 400);

So is the method structured this way triangle(x1, y1, x2, y2, x3, y3)?

How big is the canvas? How do I know where each coordinate is?

From communicating with Copilot Chat, I’ve learned a few p5.js fundamentals:

• The createCanvas(400, 400) method for defining the width and height of the canvas

• The utilization of the Cartesian coordinate system in the canvas

• The order of vertices for the triangle function: x1, y1, x2, y2, and x3, y3

• The arc function's notation: arc(centerX, centerY, width, height, startAngle, stopAngle)

• The syntax for creating ellipses: ellipse(centerX, centerY, width, height)

If you want to create this modify drawing, here’s the code:

/* draw a light brown ice cream cone with

- a scoop of light pink ice cream

- a red cherry on top

*/

function setup() {
  createCanvas(400, 400);
}

function draw() {
    // light blue background

    background(200, 220, 255);

    // light brown ice cream cone

    fill(255, 200, 100);

    triangle(100, 200, 300, 200, 200, 400);

    // light pink ice cream half-circle

    fill(255, 200, 200);

    arc(200, 200, 200, 200, PI, TWO_PI);

    // red cherry

    fill(255, 0, 0);

    ellipse(200, 100, 30, 30);
}

With my newfound knowledge, I’m ready to challenge myself to create more!

Self-Directed Application

Now that I know how to draw shapes and control the position of shapes, especially triangles, I am ready to take on a more challenging task: drawing my parents' national flag. The Guyanese flag prominently features triangles of different sizes and colors.

Here’s my attempt at drawing a Guyanese flag

Here’s the code for the flag:

// draw a Guyanese flag

function setup() {
    createCanvas(700, 400);
}

function draw() {
    // background is green
    background(0, 153, 0);
    stroke(0);
    strokeWeight(2);
    flag();
}

function flag() {
    yellowTriangle();
    redTriangle();
}

function yellowTriangle() {
   // yellow triangle and white outline
   stroke(255, 255, 255);
   strokeWeight(4);
   fill(255, 255, 0);
   triangle(0, 400, 0, 5, 715, 200);
}

function redTriangle() {
    // red triangle and black outline
    stroke(0, 0, 0);
    strokeWeight(7);
    fill(255, 0, 0);
    triangle(0, 400, 0, 5, 350, 200);
}

I continued to apply my knowledge of shape manipulation to build a snowman with a top hat, a carrot nose, and a few buttons.GitHub Copilot and Copilot Chat came in handy as I explored animation and user interaction. This allowed me to add a background with randomly generated green squares, and now users can draw random brown lines by dragging their mouse across the canvas.

Check out my snowman below!

Here’s the code to leverage for your own modification purposes:

// draw a snowman

function setup() {
    createCanvas(400, 400);
}

function draw() {
    // background is dark blue

    // background(0, 0, 102);

    stroke(0);

    strokeWeight(2);

    snowman();
}

function snowman() {
    changeBackground();

    // call all functions

    body();

    eyes();

    nose();

    buttons();

    hat();

    arms();
}

function body() {
    // snowman body
    fill(255, 255, 255);
    ellipse(200, 300, 150, 150);
    ellipse(200, 200, 100, 100);
    ellipse(200, 120, 75, 75);
}

function eyes() {
    // snowman eyes
    fill(0, 0, 0);
    ellipse(185, 110, 10, 10);
    ellipse(215, 110, 10, 10);
}

function nose(){
    // snowman nose
    fill(255, 102, 0);
    triangle(200, 120, 200, 130, 220, 125);
}

function buttons() {
    // snowman buttons
    fill(250, 0, 0);
    ellipse(200, 180, 10, 10);
    ellipse(200, 200, 10, 10);
    ellipse(200, 220, 10, 10);
}

function hat() {
    // snowman hat
    fill(250, 0, 0);
    rect(150, 65, 100, 20);
    rect(170, 33, 60, 30);
}

// create snowman arms

function arms() {
    stroke(102, 51, 0);
    strokeWeight(5);
    line(150, 200, 100, 150);
    line(250, 200, 300, 150);

}

function changeBackground() {
    // make the background be random green squares
    for (var i = 0; i < 100; i++) {
        fill(0, 255, 0);
        rect(random(400), random(400), random(50), random(50));
        frameRate(2);
    }
  }

  // draw with mouse

function mouseDragged() {
    fill(0);
    ellipse(mouseX, mouseY, 10, 10);
    return false;
}

Building on my understanding of shape manipulation and animation, I embarked on creating a 3D drawing without a specific plan or goal in mind. I let the generative nature of p5.js guide me, focusing on developing elements in 3D, adding shadows, and incorporating lighting effects.

Here’s my 3D creation. It’s giving space!

Check out the code below:

// create a 3d sphere with WEBGL and p5.js

let angleX = 0;

let angleY = 0;

function setup() {
    createCanvas(400, 400, WEBGL);
}

function draw() {
    // background is dark blue
    background(0, 0, 102);
    // set up lighting
    ambientLight(60, 60, 60);
    pointLight(255, 255, 255, 80, -100, 100);
    // set up material properties
    specularMaterial(250);
    shininess(20);
    rotateX(angleX);
    rotateY(angleY);
    // draw 3D sphere
    noStroke();
    fill(255, 204, 0);
    sphere(100);
    // draw 3D torus
    noFill();
    stroke(255, 204, 0);
    torus(200, 200);
    angleX += 0.01;
    angleY += 0.02;
}

As a culmination of the previous steps, I am now able to apply the acquired knowledge and concepts independently while coding. Through repeated engagement with pseudocoding, syntax familiarization, iteration, and AI rubber ducking, I have developed an intuitive understanding of foundational knowledge in p5.js.

Conclusion

Whether you're a novice developer or an experienced professional, the journey of learning and mastering programming is a constant process of growth. It's important to recognize that learning is rarely a linear path and often involves various cognitive methods that are often overlooked. From copying and pasting code snippets to exploring new concepts, these approaches play a significant role in our development as programmers. By intentionally embracing AI tools like GitHub Copilot and other AI pair programming tools, we can enhance our learning experience and leverage the power of generative AI.

To recap, the AI-Driven Learning involves:

• conceptual pseudocoding,

• syntax familiarization,

• iteration,

• AI rubber ducking,

• and self-directed application.

Try out GitHub Coplot, try out my approach, and share your thoughts about shaping the future of programming and redefining how we think about learning and programming.

But before I do that, I want to manage readers' expectations.

• The markdown editor we’re building will be more functional than stylistic. Translation: it might look a little ugly.

• We use a prepackaged React component to render markdown called React Markdown.

• As a bonus, we’ll use Copilot Chat to improve the markdown editor’s user interface. However, this product is in technical preview and not yet available to everyone. If you don’t have access to it yet, you can substitute it for ChatGPT.

• You’ll need access to GitHub Copilot in your editor to get the best out of this tutorial!

• GitHub Copilot and other Generative AI tools are non-deterministic. This means these tools will sometimes generate different outputs. You may receive slightly different output, but feel free to experiment with GitHub Copilot until you reach your desired outcome. Feel free to share what it created for you!

• GitHub Copilot and other generative AI tools are advancing quickly. The advice in this tutorial is relevant for today – June 2023, but it might be outdated in the near future.

Use GitHub Copilot to build a markdown editor

Prerequisites:

• Create a GitHub account (if you don’t have one)

• Sign up for GitHub Copilot

• Install the GitHub Copilot extension in an editor of your choice

Now that we have everything we need let’s get started!

Step 1: Create a Next.js GitHub Codespace template (30 seconds)

I use GitHub Codespace templates when I want to avoid installing boilerplate package dependencies and setting up my environment from scratch. It comes in handy when I want to spin up a quick proof of concept or deliver a demo. In our case, we want to save time installing Next.js and its accompanying dependencies.

You can create a Next.js GitHub Codespace template by navigating to https://github.com/codespaces/templates. Then choosing the “Use this template” button for Next.js. This will trigger a codespace to open with boilerplate Next.js code with a browser preview.

Step 2: Install specific dependencies (30 seconds)

Using a GitHub Codespace template reduced the need to install a few boilerplate dependencies, but we still have more to install.

• Ensure the GitHub Copilot extension is installed. See here for instructions.

• Install the React Markdown npm package. To do this, run the following command in your codespace’s terminal: npm install react-markdown

• Install the styled-components npm package. To do this, by run the following command in your codespace's terminal: npm install styled-components@latest

Step 3: Delete the code in your index.js file (2 seconds)

Every GitHub Codespace template includes boilerplate code to empower developers in experimenting and swiftly prototyping their ideas. However, for our goals, we will write different code in our index.js file; we don't need the existing code.

Keep the index.js file, but delete the code inside.

Step 4: Prompt GitHub Copilot with a comment (4 seconds)

The comment below prompts GitHub Copilot to explain our overall goal and provide context to our AI programming assistant. Learn more about this method from my previous DEV post – A Beginner’s Guide to Prompt Engineering with GitHub Copilot. Copy the comment below and paste it at the top of your index.js file.

/*
Create a basic markdown editor in Next.js with the following features:
- Use React hooks
- Create state for markdown with the default text "## markdown preview"
- A text area where users can write markdown 
- Show a live preview of the markdown text as I type
- Support for basic markdown syntax like headers, bold, italics 
- Use React markdown npm package 
- The markdown text and resulting HTML should be saved in the component's state and updated in real time 
*/

Step 5: Trigger suggestions from GitHub Copilot (18 seconds)

I pressed the RETURN key twice to trigger a suggestion from GitHub Copilot. I usually press the SPACEBAR, ENTER, or RETURN on my keyboard to trigger suggestions from GitHub Copilot after providing context.

💡 When you create a new line, you should see a suggestion, or ghost text, from GitHub Copilot.

💡 You can tell that GitHub Copilot will provide you with a suggestion when the Copilot icon in the status bar is spinning. I like to refer to it as "thinking". In the GIF below, I highlighted the Copilot icon, so you can see how it spins when processing.

💡 You can tell that GitHub Copilot is going to provide you with a suggestion when the Copilot icon in the status bar is spinning. I like to refer to it as “thinking”. In the GIF below, I highlighted the Copilot icon, so you can see how it spins when it is processing.

💡 Because the output for GitHub Copilot is non-deterministic, results may vary.

📝 Here's the GitHub Copilot gave me output:

import React, { useState } from 'react';
import ReactMarkdown from 'react-markdown';
import styled from 'styled-components';

const Index = () => {
  const [markdown, setMarkdown] = useState('## markdown preview');

  const handleChange = (e) => {
    setMarkdown(e.target.value);
  };

  return (
    <div>
      <textarea onChange={handleChange} value={markdown} />
      <ReactMarkdown>{markdown}</ReactMarkdown>
    </div>
  );
}

export default Index;

✨ Feel free to tweak the output to your liking!

Step 6: Save the file and try it out! (30 seconds)

GitHub Copilot generated code that looks correct, but how do we know it works? Let's try writing in our markdown editor's input box to see if it renders an accurate live preview of the text.

I'll test the following markdown elements:

Bullet points

- bullet
- bullet
- this is the markdown for bullets
- ...

Bold

I am **bold**
How to make a word **bold**: 
- sandwiched it between two asterisks on the left 
- and two asterisks on the right

Italic

I am *italic*
How to make a word *italic*: 
- sandwiched it between one asterisk on the left 
- and one asterisk on the right

Link

I am [link](google.com)
How to convert a word into a [link](google.com): 
- sandwiched it between an opening and closing bracket 
- then place an actual link next to it
- sandwich that link between two parentheses

Heading

I am  ###### heading
How to convert a word into a ##### heading: 
- Preface the word with hashtags 
- The more hashtags, the smaller the word gets
- More hashtags indicate the heading is less important
- # Heading 1 - I am super important.
- ## Heading 2 - I am a subtitle
- ### Heading 3 - I am less important
- #### Heading 4 - I am even smaller and less important

💪🏾 We did it! We developed a markdown editor with GitHub Copilot in less than 2 minutes.

Bonus: Use Copilot Chat to style, test, and explain your UI

That was fun, but we can do more. We can write unit tests, style our UI, and get an explanation of the code. We can do independently, but it's exponentially more fun to do pair program with GitHub Copilot for this.

To complete the second half of this tutorial, you will need access to Copilot Chat. Additionally, you need an active subscription to GitHub Copilot to access Copilot Chat. Learn more here.

Copilot Chat is a ChatGPT-like experience in your editor, but it’s not just a chat window. Because it’s deeply embedded into your IDE, Copilot Chat has context of what a developer types and what error messages a developer receives.

Let’s try using Copilot Chat to style, test, and explain the code in our markdown editor!

I feel comfortable with this framework, so I confidently accepted the previously generated code. However, you might be unfamiliar with React or Next.js, so the generated code looks foreign to you. This is a problem because you don’t want to blindly accept code. Understanding code that you will merge into a production environment is vital. Fortunately, Copilot Chat can provide an in-depth explanation of your code.

Step 1: Open the extension!

Following installation, try opening the extension. It should render a panel with a welcome message.

Step 2: Get an explanation of the generated code block

Let’s have Copilot Chat explain the handleChange function.

• First, highlight the code block for the handleChange function

• Right click after highlighting

• Choose “Copilot”

• Choose “Explain This”

After you follow the above steps, Copilot Chat should provide an explanation similar to the one below!

This code defines a function called handleChange that takes an event object as its argument. The handleChange function is typically used as an event handler for a textarea element in a React component. When the user types into the textarea, the handleChange function is called with an event object that contains information about the user's input. The handleChange function uses the setMarkdown function to update the value of a state variable called markdown. The setMarkdown function is a function that is returned by the useState hook provided by the React library. The useState hook is used to add state to functional components in React. By using the setMarkdown function to update the markdown state variable, the component that contains this code can re-render itself to reflect the new state. Overall, this code defines a function called handleChange that is used to update the value of a state variable called markdown in response to user input. The setMarkdown function is used to update the state variable, and the useState hook is used to add state to a functional component in React.

💡 You can repeat this step with any individual line of code or code block if you need more clarity.

💡 The more lines of code that you highlight, the less granular the explanation will be. If you want an overview, highlight the entire file, but if you want a granular explanation, highlight individual code blocks.

Step 3: Style your markdown editor

Let's communicate with Copilot Chat to guide us in styling our markdown editor.

✍🏿 Here’s the question that I asked Copilot Chat: “Can you propose code to make my markdown editor have a more modern UX design? Please use styled-components.”

Step 4: Review Copilot Chat’s response

I want to re-emphasize that generative AI and GitHub Copilot have non-deterministic output, so results may vary. Copilot Chat proposed code that handles:

• importing the styled-components npm package

• styling the markdown editor's container

• styling the text input

• styling the markdown preview

See the generated code below:

import React, { useState } from 'react';
import ReactMarkdown from 'react-markdown';
import styled from 'styled-components';

const Container = styled.div`
  display: flex;
  flex-direction: column;
  height: 100vh;
  width: 100vw;
  align-items: center;
  justify-content: center;
  background-color: #f5f5f5;
`;

const TextArea = styled.textarea`
  width: 50%;
  height: 50%;
  padding: 1rem;
  border-radius: 5px;
  border: none;
  box-shadow: 0px 0px 5px rgba(0, 0, 0, 0.1);
  font-size: 1rem;
  resize: none;
`;

const Preview = styled(ReactMarkdown)`
  width: 50%;
  height: 50%;
  padding: 1rem;
  border-radius: 5px;
  border: none;
  box-shadow: 0px 0px 5px rgba(0, 0, 0, 0.1);
  font-size: 1rem;
  overflow-y: scroll;
  background-color: white;
`;

const Index = () => {
  const [markdown, setMarkdown] = useState('## markdown preview');

  const handleChange = e => {
    setMarkdown(e.target.value);
  };

  return (
    <Container>
      <TextArea value={markdown} onChange={handleChange} />
      <Preview>{markdown}</Preview>
    </Container>
  );
}

export default Index;

I reviewed the code, and it looked like a feasible solution to me, so I copied the generated code and pasted it into my index.js file.

Step 5: Check out the results

Here’s what my final results looked like:

I guess this is Copilot’s version of a modern UX design, and it looks a bit better to me, but it could use some improvement. This is a great opportunity for you as the developer to tweak the code to match your vision!

Step 6: Keep experimenting

I spent over 20 minutes experimenting with Copilot Chat to improve my prompt game and understand Copilot’s limitations. I asked it different questions like:

• How do I add a toolbar?

• How do I add a dark mode and light mode theme?

Here’s what it came up with:

🧑🏾‍🎨 Get creative and make your markdown editor your own!

Step 7: Write unit tests with Copilot Chat

While writing unit tests is critical for any production application's longevity, it's also a really tedious process. I'm happy that the industry is moving towards the direction of automating away boilerplate code and repetitive code.

We can request that Copilot Chat generate unit tests for our markdown editor using slash commands.

After I typed "/tests" in Copilot Chat, I received proposed unit tests accompanied by a brief explanation. See the results below:

import React from 'react';
import { render, fireEvent } from '@testing-library/react';
import Index from './index';

describe('Index', () => {
  it('renders the bold, italic, and theme toggle buttons', () => {
    const { getByText } = render(<Index />);
    expect(getByText('Bold')).toBeInTheDocument();
    expect(getByText('Italic')).toBeInTheDocument();
    expect(getByText('Dark Mode')).toBeInTheDocument();
  });

  it('toggles between dark and light mode when the theme toggle button is clicked', () => {
    const { getByText, container } = render(<Index />);
    const themeToggle = getByText('Dark Mode');
    expect(container.firstChild).toHaveStyle('background-color: #fff');
    fireEvent.click(themeToggle);
    expect(container.firstChild).toHaveStyle('background-color: #000');
    fireEvent.click(themeToggle);
    expect(container.firstChild).toHaveStyle('background-color: #fff');
  });

  it('updates the markdown text when the textarea is changed', () => {
    const { getByLabelText, getByText } = render(<Index />);
    const textarea = getByLabelText('Markdown Input');
    fireEvent.change(textarea, { target: { value: '# Hello World!' } });
    expect(getByText('# Hello World!')).toBeInTheDocument();
  });

  it('applies bold formatting to selected text when the bold button is clicked', () => {
    const { getByText, getByLabelText } = render(<Index />);
    const textarea = getByLabelText('Markdown Input');
    fireEvent.change(textarea, { target: { value: 'Hello **World**!' } });
    const boldButton = getByText('Bold');
    fireEvent.click(boldButton);
    expect(textarea.value).toBe('Hello **World**!');
    fireEvent.change(textarea, { target: { value: 'Hello **World!**' } });
    fireEvent.click(boldButton);
    expect(textarea.value).toBe('Hello World!');
  });

  it('applies italic formatting to selected text when the italic button is clicked', () => {
    const { getByText, getByLabelText } = render(<Index />);
    const textarea = getByLabelText('Markdown Input');
    fireEvent.change(textarea, { target: { value: 'Hello *World*!' } });
    const italicButton = getByText('Italic');
    fireEvent.click(italicButton);
    expect(textarea.value).toBe('Hello *World*!');
    fireEvent.change(textarea, { target: { value: 'Hello *World!*' } });
    fireEvent.click(italicButton);
    expect(textarea.value).toBe('Hello World!');
  });
});

These tests cover the basic functionality of the component, including rendering the correct buttons, toggling between dark and light mode, updating the markdown text, and applying bold and italic formatting to selected text. Note that these tests assume that the TextArea and Preview components are working correctly, so you may want to write additional tests for those components as well.

Please note: I didn't try out the unit tests, so use at your own expense. I strongly recommend running the tests and reviewing the code before merging into a branch.

💾 ...And we're done! Experimenting with GitHub Copilot and Copilot Chat is always fun for me. For more content like this follow me or GitHub on DEV!

👀 Also, I'd love to hear your thoughts in the comments below.

Technical skill and content creation are equally important for your software development or (software development adjacent) career. Technical skills such as coding help you to perform the job at a base level, but content creation can solidify you as a leader in the industry. I acknowledge that not everyone has the privilege of creating content alongside completing their daily job duties and personal responsibilities, but it is a worthy investment. Creating technical content can make it easier to land jobs, get promoted, and influence the direction of our industry because it enables hiring managers and other tech leaders to take a peek into your brain and your thought process. More importantly, it helps you absorb and solidify concepts that you’ve learned. You can be the smartest, most skilled software developer in the world, but if no one knows who you are, then your opportunities may be limited. Content creation helps you advocate for yourself. It might seem cringe, but you can put yourself out there in a non-cringey authentic way. Folks like Kelsey Hightower established and advanced their careers by sharing their thoughts in an authentic and thoughtful way.

My favorite form of technical content creation is blogging. Thanks to my mom, I developed a passion for reading and writing at an early age, so writing has always been my preferred method of self-expression. I had an endless supply of picture books, cassette-tape audio books, novels, poetry, and half-filled notebooks documenting my childhood experiences. When there was no heat in my house, my mom would bring my siblings and me to the library, so the library became my second home. Disclaimer: I’m not a perfect writer; it’s just something I enjoy doing.

Unfortunately, I abandoned writing in early adulthood because I learned that it’s hard to make money as a writer, and I had one goal in mind: make LOADS of money. I grew up poor, and I was determined to improve my quality of life, so I focused all my energy on a career that makes money: software development.

Years later, I started my third full-time software development job, and my manager Andy Cunningham encouraged me to write what I learned on the job. As part of my sprint, I’d fix a bug or implement a new feature, and then I would write about it. One of my first technical blog posts was about how I used GitHub Actions to sync our repository with our AWS S3 Buckets. Months later, I landed my current role as a Developer Advocate, and part of my role is to blog.

While I was excited to combine my childhood skill (writing) with the skill I learned in adulthood (coding), I was also intimidated. Writing about technology didn’t seem as easy as writing a poem or an essay. With poetry, I had all creative authority, and with essays, teachers gave us guidelines. But, what was a technical blog post supposed to look like? I worried and struggled with the following concepts:

• Will people read it or even care to read it?

• Will people think I’m wrong or stupid?

• Do I have anything valuable to say?

• Is my blog post too short?

• Is my blog post too long and overwhelming?

• I want to tell the audience everything, but when should I stop the blog post?

I didn’t have any structure or strategy for writing my blog posts. After a year of writing technical blog posts and learning from great content creators like Kurt Kemple, I’ve developed a strategy that I’m comfortable with. In this blog post, I’ll share my strategy in hopes of empowering you.

Address your fears

A common reason that technologists don’t write is because they’re scared.

If you’re scared that you don’t have anything new or different to write about… Remind yourself that you don’t have to write about anything revolutionary or inventive, write what you know. While someone may have already written about a similar topic, they won’t explain it the same way you will. And the way you explain and describe information will reach a particular audience that learns and consumes information the same way you do.

If you’re scared that your writing skills aren’t up to par… Remind yourself that this is your platform to practice. You will improve over time, and sometimes blog posts don’t need to have flowery vocabulary and complex sentences. Sometimes, the simpler a blog is written, the easier it is for the audience to consume.

If you’re scared that you don’t know enough… Perhaps, you only know HTML, but you know more than someone who doesn’t know HTML. You will continue to grow and learn over time. You don’t need to wait until you get to a certain point because as technologists, we’re always learning. There will always be something that we don’t know.

If you’re scared of making mistakes… Embrace your mistakes; they help you grow. I make mistakes all the time. Sometimes, I have grammatical errors in my blog posts or even technical errors, and someone corrects me. I learn from those mistakes and I’ve become a better writer, educator, and engineer as a result. Don’t aim to make mistakes, but when you do, know that everyone makes mistakes and it’s part of our journey to greatness.

If you’re scared that you don’t have time… This is totally fair as we all have varying responsibilities and limited time. However, it is a worthy investment to reflect on what you’ve learned and share your knowledge with the world. If possible, work with your manager to carve out regularly scheduled time to write, and your blog posts don’t have to be long. They can be as short or as long as you want. You have creative authority over your content.

If you’re scared of criticism… Remind yourself that you are writing for you. You are writing, so that you can look back and reflect on your growth. You are writing, so that you won’t have to repeatedly Google or ask your coworkers for help on the same questions. The harmful opinions of others don’t matter. You can always delete their comments or respectfully respond and continue to live life. I’ve found that people like to critique others when they feel threatened.

Keep a list of things you’ve learned

As you write code at your job, complete side projects, or contribute to open source projects, keep a running list of things you’ve learned.

I keep a list in my Notes app on my Mac computer and iPhone. It looks like this

### Idea list
Hack.Diversity

- How to negotiate salary
- Write thank you letters after interviews
- How to pass the technical interview
- How to learn / navigate a new codebase quickly 
- Tips for passing the CompTIA+ test
- Code
- Invite Automation
- Teaching to Empower: Supporting Early Career Devs
- Generate Social Cards with JavaScript
- From Code to Cloud — Git Emoji
- Build a Blockchain Simulation with JavaScript
- Make better pull requests
- Fuzzy Search Made Easy
- Overcoming the Fear of Contributing to Open Source
- How to Convince Your Boss to Open Source a Project
- Create the Perfect ReadME for your Open Source Project 
Small things I learned with code

- Linked issues
- Fusejs
- How to make a pull request template
- .github/.github/PULL_REQUEST_TEMPLATE.md
- https://github.com/open-sauced/.github/blob/main/.github/PULL_REQUEST_TEMPLATE.md
- .github
- Issue templates
- Forms yaml 
- Being autonomous
- Turning a Checkbox into a circle
- Handling routing with netlify
- Dependencies vs devDependencies
- React functions run on load or after
- Dealing with broken images in React 
- SEQA 
- Rendering components
- Using classList
- Invite automation
- Automatically generate a social image card
- Pull request template forms
GitHub ideas

- Prompt engineering tips with GitHub Copilot
- Lowering barriers with GitHub Codespaces
- Automatically install extensions with GitHub Codespaces
- Automatically install npm dependencies with GitHub Codespaces
- Automatically run your node app with GitHub Codespaces
- GitHub Actions extension
- Using GitHub Pages to federate your Mastodon identity 
- Building a to do list user interface with GitHub Copilot 
- Sending a toot with GitHub Copilot
- P5.js with GitHub Copilot
- I made a GitHub action with my voice
- I used AI to build AI
- How does GitHub Copilot help businesses

As you can see, my ideas range from simple concepts like "Converting a checkbox into a circle with CSS" to more advanced and creative concepts (like "Building a GitHub Action with my voice"). Some of the ideas are also repeated. Whenever I get an idea or one of my managers mentions that I should cover a topic, I write it down. Keeping a list of ideas is helpful, so that when you want to write, you’re not also wasting energy and time, brainstorming topics.

Choose the topic you feel most excited about

It’s worth noting that I haven’t written about many of the topics listed above. I only write about what I’m most passionate about at the moment or most needed at my job (because this is my job). If it’s one of the ideas on the list, then I will write about it. However, if I have a random spark of inspiration, I will act on the idea immediately. On the other hand, I may also have to write about a topic requested by my coworkers, and I’ll focus on that. I choose the most urgent or the most exciting topic because that helps motivate me.

Also, consider granularity in your topics. If you want to write about a general topic, such as React, it would be difficult to write about every single concept of React. It would take a book or documentation to cover the entire framework. Instead, I suggest creating a general overview of React or picking a very subtopic such as, “Understanding the useEffect Hook” or “How I used React to build a blog”

Read other blog posts for inspiration

Before writing anything, I always read. Reading inspires my:

• Storytelling

• My writing style

• My choice of words and sentence structure

• My perspective

• My writing technique

By immersing myself in various texts, I can absorb different writing styles and techniques, allowing me to adapt and experiment with my own writing. Additionally, reading exposes me to diverse ideas and perspectives, broadening my understanding of the world and providing me with fresh insights to incorporate into my writing. It also helps me identify areas for improvement, such as refining my sentence structure or expanding my vocabulary. You don’t have to read a really long blog post or novel, but reading a quick paragraph is beneficial in refining my writing.

Determine your audience

Now that you know what you want to write about, and you’re inspired to write, it’s time to determine who you are writing for.

As humans, we have a tendency to want to write for everyone. We want to teach and help everyone, and that’s not wrong, but I wouldn’t suggest doing this for a blog post. I often talk with people who have goals around content creation, and they want to target junior engineers, mid-level engineers, and senior engineers simultaneously. If you try to reach everybody, you might end up creating a really long blog post that no one wants to read or you might overwhelm yourself and never actually finish the blog post. Trust me; it’s happened to me before and other technical writers. Even if I do finish it, the blog post ends up having every low engagement and it looks messy.

If you choose a very specific audience, then the other audiences will still benefit. For example, I’ve written blog posts for beginners, but sometimes senior engineers let me know that they still learned something new from the blog post or that they appreciated the way I broke down fundamentals.

The person I usually pick to write for is me, specifically past me. Here are examples:

• I wrote the blog post “Overcoming the fear of Contributing to Open Source” to myself when I was in a coding bootcamp and didn’t really understand open source.

• I wrote “How I used dev containers to enable GitHub Codespaces for ChatGPT” to myself as a GitHub Developer Advocate who was acting as “Customer Zero (well maybe customer 100)” on GitHub Codespaces.

• I wrote “How to speak at conferences when you’re scared of public speaking” to me in high school who was scared of public speaking.

• And I’m writing this blog post to myself before I ever wrote a technical blog post.

I have also written to my future self. Like, I often create advice for open source maintainers, but I only started maintaining a project in 2023. The advice I wrote in 2021 and 2022 is helpful for present day me.

Build an outline

Now, it’s time to plan what you write. Building an outline helps to align your thoughts in a way that readers will understand. Feel free to tweak the outline templates below, but this is what I use to write my own blog posts

Outline for “how-to” blog posts

If I’m writing a blog post guiding people step-by-step on how to do accomplish a task, I will use an outline like the one below:

Intro
- Hook
- Problem statement/What this solves for myself or readers

Step-by-Step Guide
1. Step 1
Optional: brief explanation of the step with supporting links for folks to learn more
2. Step 2
Optional: brief explanation of the step with supporting links for folks to learn more    
3. Step 3
...
N. Final Step

Conclusion
- Recap of the process
- Final thoughts or additional tips
- Call to action (e.g., encourage readers to try the steps and share their results/feedback)

Check out an example that follows this outline: How to send a tweet with GitHub Copilot

Outline for explainer blog posts

I define an explainer blog post as a blog post that explains a topic, but it doesn’t necessarily walk people through accomplishing a task. The main purpose is for readers to get an introduction to a concept.

Intro
- Hook
- Brief overview of the topic and why care

Body
1. Key Concept 1
    - Definition/explanation
    - Examples 
    - Importance or relevance
2. Key Concept 2
    - Definition/explanation
    - Examples
    - Importance or relevance
3. Key Concept 3
    - Definition/explanation
    - Examples
    - Importance or relevance
...
N. Final Key Concept
    - Definition/explanation
    - Examples
    - Importance or relevance

Conclusion
- Summary of the key concepts
- Closing thoughts or implications
- Call to action (e.g., encourage readers to explore further or ask questions)

Here’s an example of a blog post that follows this outline: Why are people developing in containers?

Outline for thought leadership/opinion blog posts

These types of posts are posts where I just share my opinion on the direction that industry is going. Many times, I use it to create productive conversation and share my leadership skills.

Intro
- Hook
- Brief introduction to the topic/opinion and why it matters to me

Body
1. Supporting Point 1
    - Explanation of the point
    - Supporting evidence or examples
2. Supporting Point 2
    - Explanation of the point
    - Supporting evidence or examples
3. Supporting Point 3
    - Explanation of the point
    - Supporting evidence or examples
...
N. Final Supporting Point
    - Explanation of the point
    - Supporting evidence or examples

Counter arguments (optional)
- Address potential counterarguments or opposing views

Conclusion
- Reinforce the opinion and provide a call to action

Here’s an example of a blog post that follows this outline: The Hard Parts of Developer Advocacy for me

Outline for listicle blog posts

These are posts that are often written in list format. The reason they’re written this way is to make the concept fun, quick and easy to consume for readers. These types of blog posts are often have titles to the ones below:

• Top Ten Tips for…

• 5 Must-Have…

• 7 Amazing…

Intro
- Hook or intriguing statement related to the topic
- Brief introduction to the theme or subject of the listicle

Listicle Items
1. List Item 1
    - Explanation 
    - Example
2. List Item 2
    - Explanation 
    - Example
3. List Item 3
    - Explanation
    - Example
...
N. List Item N
    - Explanation
    - Example

Conclusion
- Final thoughts or insights
- Call to action (e.g., encourage readers to share their favorite item or suggest additions to the list)

Here’s an example of a blog post that follows this outline: 8 things you didn’t know you could do with GitHub Copilot

Take a shower

This is an odd suggestion, but I do my best thinking in the shower. I think the sound of running water helps me to focus on my thoughts. In the shower, I can write a whole blog post in my mind. Besides taking a shower, you can try other activities that can stimulate your mind:

• Walking

• Jogging

• Listening to music

• Meditating

Enter a flow state for writing

Disable all distractions and start writing. I strongly recommend that you don’t edit as you write. I find that disruptive for my flow. I fill out each part of the outline that I created in whatever order that I prefer. I write the way I speak, and I just keep going. After I’ve written all my thoughts on paper, I will start editing.

My editing process consists of deleting irrelevant paragraphs, fixing spelling mistakes, and removing unnecessary punctuation marks. I’m a super light editor. I feel that if I edit it too much or spend too much time perfecting my blog posts, then I will never press publish. In the following paragraphs, I expand a bit more on my editing process. However, the way I look at it is, I want to get my thoughts out there. Once I do, someone will reach out to me – like my job and ask for a more refined version of my blog posts. Then, I could use resources my job provides me like professional editors to improve my blog posts. Also, I recognize that it doesn’t matter how much I edit; my blog post will always need more editing. It’s like code – there’s a bug somewhere. Sometimes, I just edit it after I publish. Often, people message me to say that I spelled a word wrong, and I usually update it afterwards.

It’s no big deal. Write for completion rather than perfection.

Struggle with writing? Record your voice

There are some people who find writing difficult, and that’s okay. Brian Douglas told me about a tip that could help folks who struggle with putting words on a paper: speak. Record yourself speaking, upload the audio to your computer, and use a tool that can transcribe those words.

The tool I suggest is Descript. It does a great job of transcribing audio. It may have a few mistakes here and there, so double check what it generates and make small edits.

Read it aloud (or use a Text-to-Speech reader)

Reading my writing aloud enhances the quality of my content. When I read text I wrote in my head, I may notice particular issues, but reading aloud allows me to:

• Improve the clarity and flow

• Enhance the tone and voice

• Spot grammatical and stylistic errors

• Evaluate the rhythm and cadence of my content

• Assess the audience appeal

• Sometimes, I'm too lazy to read my writing aloud or I’m struggling to focus, so I use a text-to-speech reader like, Natural Reader.

Use a digital writing assistant

Digital writing assistants like Grammarly find errors you might have missed. Word Tune is another tool that I find helpful. It’s great because it takes my hard-to-understand sentences and converts them into clear, terse sentences. ChatGPT is another tool, but this one is a little more controversial. While I don’t encourage folks to use it to write whole articles, it does give great feedback. I’ll often prompt ChatGPT with the following:

• What did I do well in this blog post?

• What didn’t I do well in this blog post?

• Can you help me come up with a better title for this blog post?

Share your draft with stakeholders to gather feedback

I received this advice from Kurt Kemple: Share a draft of your blog post with people at work who asked you to write the blog post (product managers etc) AND someone from your target audience. When I follow this advice (because I'm lazy), I always get a high level of engagement and a quality final product. For example, I wrote this blog post called, “How do I resolve merge conflicts?” I shared the draft with my friend Nathan, who recently graduated from a coding bootcamp. Nathan’s feedback helped me ensure that beginners could understand my blog post, too!

Add a cover image

In addition to well-written content, adding a cover image to your technical blog posts can significantly enhance their appeal and engagement. Don’t ignore this step. Including a cover image demonstrates your commitment to presenting your technical content in a professional and polished manner. It shows that you've put thought and effort into crafting a visually appealing and well-designed post, which can elevate your credibility as a writer and technical expert.

I’m not an artist nor am I great at design. I often use the following tools to help me create an image like:

• Canva

• Figma

I’ve also seen folks like Bekah H.W. and Brian Douglas use Midjourney to create cover art. I believe my friend Mayank uses Excalidraw to create cover art.

Several of my covers images aren't that cute, but here are a few that I think look great:

Publish

Publish your blog post on the platform of your choice. You can use:

• DEV

• Hashnode

• Free Code Camp

• Medium

• Or your personal website

You can make the decision on where you want to post based on your target audience and how you want to own your content. I sometimes use a platform called BloggU to cross-post on multiple platforms.

Share it on social media

Congratulations, you posted the blog, but you’re not done yet. Share your post with others helps the post gain more engagement. Sometimes, I receive messages from folks I’ve never met before that my blog post was helpful for them. Social media enables me to reach folks worldwide. I try to share my blog posts on:

• Twitter

• Bluesky

• Mastodon

• LinkedIn

• Discord

• Sometimes I share posts with my coworkers on Slack (could be cringe, but no one is going to know that I created these things if I don’t tell them)

I try not to announce things in a self-centered way. You can if you want to, but I want to show that my intentions are to share knowledge and grow rather than be at the center of attention. So I might add a small blurb that says something along the lines of: “Hey y’all! I used to struggle writing blog posts, but now I’ve gotten the hang of it, so I wrote a blog post to help others develop a good strategy, too. Check it out and let me know your thoughts.”

Additional Resource

The Developer Advocate’s Guide to Content Creation by Kurt Kemple

Conclusion

Writing technical blog content is not easy, but I’m hoping the above steps can help you to stay in the flow and create content that you’re proud of. Again, I want to emphasize that we’re not striving for perfection. This blog itself is far from perfect, but it accomplishes two things: If I ever forget my process or I’m feeling impostor syndrome, I can always re-read this post as a reminder It helps aspiring technical blog writers to level up their careers

Call to action

I would love to hear about different writing strategies to improve your blog content or anything that I listed that’s been helpful to you. For more content like this, follow me!

Stay cool, friends 😎

OR

You're looking for an open source project to contribute to. You follow the documentation, but it's outdated and hard to follow, so you abandon your pursuit of contributing.

OR

You want to try out a new framework and understand how it works behind the scenes, but to do that, you have to npm install 5 million different things, and you're not that interested, so you decide to binge-watch HBO's Succession instead.

These are three very common experiences that happen to software engineers of all levels, whether new to a job or to an open source project. So, what's the solution?

The software engineering industry acknowledges that the time-to-first-pull-request or time-to-first-contribution can be time-consuming and cumbersome. As a result, the industry created many solutions in-browser sandbox solutions like CodeSandbox and Replit. For larger projects, cloud-based development environments like GitPod and GitHub Codespaces streamline onboarding and collaboration. One major hurdle in using tools like GitHub Codespaces or GitPod is the lack of knowledge on how to configure them to automatically run your projects, which is understandable since these concepts are still relatively new in the software engineering industry. Luckily, you have me, and you found this blog post. Disclaimer: I work at GitHub as a Developer Advocate. However, there was a part of me that felt a little intimidated by the process of setting up a development container. Like, what even is a development container? Should I just copy and paste one? After taking some time to truly understand devcontainers, they feel more approachable for me.

In this blog post, I'll walk you through setting up a development container for a static Next.js/TypeScript web application so that it can automatically run in GitHub Codespaces.

My new open source project

On a related note, I'm excited to share that I've started maintaining my first open source project, the Open Contributions Project, alongside Josh Goldberg. Our goal is to advocate for and explain corporate contributions to open source. It's a static documentation website built with Next.js and TypeScript. We welcome contributions in design, documentation, and code, particularly from beginners. Check out the repository below.

I set up a development container and enabled GitHub Codespaces to streamline the development process for the Open Contributions Project. If you launch the Open Contributions Project in GitHub Codespaces, it will install the required dependencies, run the project, and launch a browser preview of the project. You can try it out here or by clicking the button below!

What is GitHub Codespaces?

GitHub Codespaces is a cloud-based development environment that's hosted in the cloud. This helps developers onboard faster, code on any device, and code in a consistent environment. The UI for GitHub Codespaces can resemble your favorite IDE – like Visual Studio Code, Visual Studio, Jupyter Notebook, or JetBrains, but it opens in your browser. You can customize your project for GitHub Codespaces by creating config files. These config files create a repeatable codespace configuration for all users of your project. If you don't set up any custom configuration, your project will use the default built-in GitHub Codespaces configuration.

You can learn more about GitHub Codespaces from the following resources:

• Overview and Getting Started with GitHub Codespaces - GitHub documentation

• Revolutionize your open source workflows: the top 3 reasons why GitHub Codespaces is a must-have for maintainers

• 10 Things you didn't know you could with GitHub Codespaces

• A beginner's guide to learning to code with GitHub Codepsaces

• Technical Interviews via Codespaces

What is a development container?

GitHub Codespaces are built on top of virtual machines that utilize development containers, or dev containers, which are essentially Docker containers that offer a comprehensive development environment. You can configure a dev container to provide a uniform developer experience. You can configure a dev container with these three files: devcontainer.json, Dockerfile, and docker-compose.yml. For a small, static Next.js/Typescript project like ours, we only need the devcontainer.json file.

You can learn more about development containers from the following resources:

• Introduction to dev containers - GitHub documentation

• Dev Containers Specification Guide

• Why are people coding inside containers?

• How to automate your dev environment with dev containers and GitHub Codespaces

• How I used dev containers to enable GitHub Codespaces for ChatGPT

Understanding Codespace lifecycle properties

In this guide, I use a few Codespace lifecycle properties, so I figured I would give a brief overview of what they are and why we use them. Codespaces lifecycle properties are special properties that are run automatically at specific points during the creation and management of a Codespace environment. You can use them to perform customized tasks at specific points during the lifecycle of the environment.

Here are some commonly used Codespace lifecycle properties:

• preCreateCommand: runs before a Codespace is created and is used to set up the environment by installing any required software or dependencies.

• onCreateCommand: runs immediately after the Codespace is created and is used to perform any additional setup tasks that are required.

• postCreateCommand: runs after the environment is created and is used to perform any final configuration tasks.

• updateCommand: updates the environment and is typically used to install any new software or dependencies that have been added since the last time the environment was created

• updateContentCommand: updates the content of the environment and is typically used to update files or data within the environment.

• postAttachCommand: In this context, "attach" means to connect to an existing and already created Codespace. This command runs after a user attaches to the Codespace and is used to perform any tasks that should be executed each time the Codespace is attached, such as starting a development server.

Steps for building a development container for a Next.js/TypeScript codebase

Step 1: Create a Codespace for your project

Let's open our projects in GitHub Codespaces by choosing "Code"> "Codespaces"> "Create Codespace on [default branch]."

Step 2: Add a pre-made dev container

First, open the command palette. We can access the command palette using either of these options:

• Pressing this keyboard shortcut combination Shift+Command+P (Mac) OR Ctrl+Shift+P (Windows/Linux)

• From the Application Menu, click View > Command Palette

• Pressing F1

Then, in the command palette, choose: "Add dev container configuration files."

​​Step 3: Create a new configuration

Then, we will see two options:

• Modify your active configuration

• Create a new configuration

Since we don't have a configured dev container yet, we want to choose "Create a new configuration."

Step 4: Choose the Node.js and TypeScript template

This next step leads us to a list of predefined dev containers, so we don't have to start from scratch! Currently, the "Node.js & TypeScript" dev container is the most suitable start for a Next.js/TypeScript project.

Step 5: Choose your preferred Node.js version

The next screen will prompt us for our preferred Node.js version. I chose 20, but you should choose whatever version works best for your project.

Step 6: Skip the features! Create the dev container

The next step is to add features. In our case, we don't need any features, so we can press "OK." Pressing "OK" adds a .devcontainer directory to your project with a devcontainer.json file that we can further customize.

Here's what our initial devcontainer.json file should look like:

​​// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node

{

    "name": "Node.js & TypeScript",

    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

    "image": "mcr.microsoft.com/devcontainers/typescript-node:0-20"

    // Features to add to the dev container. More info: https://containers.dev/features.

    // "features": {},

    // Use 'forwardPorts' to make a list of ports inside the container available locally.

    // "forwardPorts": [],

    // Use 'postCreateCommand' to run commands after the container is created.

    //"postCreateCommand": "yarn install",

    // Configure tool-specific properties.

    // "customizations": {},

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

    // "remoteUser": "root"

}

Step 7: Automate installing project dependencies

As part of the local setup, I run pnpm install to install my project's dependencies. pnpm is a package manager for Node.js packages. It is designed to be fast, disk space efficient, and feature-rich. It creates a single instance of each package on a disk and uses symlinks to link to the installed packages in other projects.

Your project might use a different command and package manager for installing project dependencies. Perhaps, your project is using yarn or npm, so you don't want to copy me verbatim for this step. Instead, you can use my advice in this step as a guiding example! If you're using npm install or yarn install to install your project dependencies, replace pnpm install with the required command for your project.

Anyways, I wanted to automate this step so that project contributors wouldn't have to manually run pnpm install, so I used my dev container to automate this. In my devcontainer.json file, I added a property called:

"updateContentCommand": "pnpm install"

This will enable my codespace to install the latest project dependencies. I considered delegating the pnpm install command to a different Codespace lifecycle property, but I wanted the benefits of the updateCommentCommand. The biggest benefit of using this lifecycle property is that instead of installing all dependencies each time the environment is created, it would only install new dependencies that have been added since the last time the environment was created.

Step 8: Automatically run the local development server

Because my project is static and doesn't have too many complexities, after installing the required dependencies, I need to start my local environment with the command pnpm dev. Again, I don't want project contributors to manually type this in. I want the project up and running when they open my project in GitHub Codespaces, so I automated this portion in my dev container by adding the following lines to my devcontainer.json file:

"postAttachCommand": "pnpm dev"

This line is saying after EVERYTHING in the codespace is set up, and the user connects to the codespace, start the development server. Please remember that the commands to run your local development server may differ. Maybe you need to use npm run dev or yarn start. Double-check before copying and pasting!

Step 9: Choose your forwarded port

Now that we automated running our local development server in the step above, we can now choose a specific port for Codespaces to forward traffic in the container to a port on your local machine. In the example below, I chose port 3000.

    "forwardPorts": [3000]

As a result, GitHub Codespaces will generate a URL that follows this naming convention:

`https://<your-github-handle>-<a-codespaces-id-which-combines-a-words-and-random-characters>-<your-port-number>.preview.app.github.dev/`

For me, it generated this URL:

https://blackgirlbytes-ubiquitous-couscous-777759vgvpjcrv4q-3000.preview.app.github.dev/

You have the ability to change your port's visibility! To learn more about forwarded ports, check out the following resources:

• Share your locally hosted web app using Codespaces

• Forwarding ports in your Codespace - GitHub Documentation

Step 10: Get a browser preview

My favorite part of GitHub Codespaces is that you can open a browser preview directly within your codespace by adding the following lines to your devcontainer.json file:

    "portsAttributes": {

        "3000": {

            "label": "Application",

            "onAutoForward": "openPreview"

        }

    }

Step 11: Automatically add extensions

We can configure a project to automatically install extensions in GitHub Codespaces. We can do this by right-clicking on any extension and selecting "Add to devcontainer.json."

I added the following extensions:

• Code spell checker

• ES Lint

• Markdown-lint

• Remote-containers

After this, it should add the following object to our devcontainer.json file:

"customizations": {

        "vscode": {

            "extensions": [

                "streetsidesoftware.code-spell-checker",

                "dbaeumer.vscode-eslint",

                "esbenp.prettier-vscode",

                "DavidAnson.vscode-markdownlint",

                "ms-vscode-remote.remote-containers"

            ]

        }

    }

Step 12: Make it synchronous

Using the waitFor property empowers us to have more control over the Codespace lifecycle and the timing of specific commands. For instance, I used the following configuration in my devcontainer.json file:

"waitFor": "onCreateCommand"

This tells the Codespace creation process to wait for the onCreateCommand to complete before moving on to the next step in the Codespaces lifecycle. This ensures the environment is set up before running other commands.

Caveat

I actually don't have an onCreateCommand in my devcontainer.json file at all, so it doesn't make sense that I added this line. Perhaps, it might make more sense if I add the line below:

"waitFor": "updateConentCommand"

I'm still learning about GitHub Codespaces extensively, so that was a mistake I made that I'd like to rectify.

Step 13: The final devcontainer.json file

Let's confirm the final result! In my .devcontainer directory, I have a devcontainer.json with the contents below:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
{
    "name": "Node.js & TypeScript",
    "image": "mcr.microsoft.com/devcontainers/typescript-node:0-18",
    "waitFor": "onCreateCommand",
    "updateContentCommand": "pnpm install",
    "postAttachCommand": "pnpm dev",
    "customizations": {
        "vscode": {
            "extensions": [
                "streetsidesoftware.code-spell-checker",
                "dbaeumer.vscode-eslint",
                "esbenp.prettier-vscode",
                "DavidAnson.vscode-markdownlint",
                "ms-vscode-remote.remote-containers"
            ]
        }
    },
    "portsAttributes": {
        "3000": {
            "label": "Application",
            "onAutoForward": "openPreview"
        }
    },
    "forwardPorts": [3000]
}

Step 14: Try it out!

We can test out our changes to ensure that GitHub Codespaces will install the required dependencies, install required extensions, run our local development server, and open a browser preview by fully rebuilding the container.

To rebuild the container, we'll need to access the command palette. We can access the command palette using either of these options:

• Pressing this keyboard shortcut combination Shift+Command+P (Mac) OR Ctrl+Shift+P (Windows/Linux)

• From the Application Menu, click View > Command Palette

• Pressing F1

Then, in the command palette, choose: "Codespaces: Full Rebuild Container."

Video walkthrough

I live streamed myself walking through the steps to build a development container and planning this blog post. Check it out!

Share your learnings

If you've tried out development containers or picked up any cool tips and tricks for using GitHub Codespaces, comment below!

I had three main reasons for my excitement about adding GitHub Codespaces to the quickstart repository:

• I would gain access to ChatGPT plugins, which I imagine have a never-ending waitlist.

• I would gain experience configuring GitHub Codespaces in unfamiliar environments. My experience with GitHub Codespaces is limited to JavaScript-based projects.

• I'm a nerd.

Last week, I officially submitted a pull request to enable GitHub Codespaces for the project. The Codespaces team has already reviewed it, and I'm now waiting for the OpenAI team to do the same. In the meantime, I'm sharing what I've learned throughout this experience in the hope that you can learn more about GitHub Codespaces too!

Prerequisites:

This is not necessarily a tutorial that you should follow step by step, but if you did want to follow it, you would need access to the following tools.

• ChatGPT account

• ChatGPT plugins

• GitHub account

• It might be helpful to understand the purpose of GitHub Codespaces. You can learn about it from my previous blog post.

A short summary of GitHub Codespaces

GitHub Codespaces allows you to code in a container hosted in the cloud. This helps developers onboard faster, code on any device, and code in a consistent environment. The biggest benefit I see for this particular ChatGPT quickstart plugin repository is that developers can try out the plugin functionality without the hassle of cloning the project locally or running any setup scripts. They can try it out without context switching and leaving GitHub. And best of all, they won’t have to do any of the setup. Note: you can open any project in GitHub Codespaces. The UI for GitHub Codespaces can resemble your favorite IDE – like Visual Studio Code or JetBrains, but it’s just in your browser. You can also configure GitHub Codespaces to install all the dependencies and run the project to reduce the time it takes for developers to start working on a project.

Here are the steps I took and the lessons I learned while setting up GitHub Codespaces for this project:

Step 1: Get the project working locally

The first question I needed to answer before configuring GitHub Codespaces was: how does this project work? What is the end result?

I found my answer by following the local setup instructions found in the repository’s README.md. The instructions were simple: install the required packages and then run the project. Subsequently, the server will run locally on localhost:5003.

In ChatGPT, I chose the ‘develop your own plugin’ option.

As instructed, I provided ChatGPT with the local address that the server was running on – localhost:5003.

After all that, I was able to leverage the plugin to create a simple to do list with ChatGPT.

If you want to try it out, check out the README here.

Throughout this process, I noted that there's no frontend for this project, so I only had one goal—when anyone opens this project in a codespace, the server should run.

Step 2: Open the repository in GitHub Codespaces

This step ensures that any changes I make are actually compatible with GitHub Codespaces. The code from the repository will be accessible in GitHub Codespaces out of the box, but it won't start running my project or installing dependencies without configuration. So, the next step is to add a configuration file called a devcontainer.json.

Step 3: Add a dev container

Development containers, fondly known as dev containers, are Docker containers that set up a customized environment for the project. I can use a dev container to automatically:

• Install the necessary extensions

• Reference environment variables

• Forward ports

• Install dependencies

• Run my project

• Run scripts

• And more

You can add a default development container by opening the Visual Studio Code Command Palette. This default configuration file contains the basic items you need to get a project running. To open the Visual Studio Code Command Palette, use the following keyboard shortcuts: (Shift+Command+P / Ctrl+Shift+P). Then, search for the option to "Add dev container configuration files."

It will prompt you to specify your project's language because each development container is slightly different depending on the language, framework, version, and other environmental factors. For this case, the project is Python-based, so we would choose Python.

Unfortunately, I did not follow the advice of adding a development container through the Command Palette. Instead, at the root of my project, I created a folder called .devcontainer. Inside that folder, I created a file called devcontainer.json. I copied and pasted a development container from a past Python project into the devcontainer.json. I did this because the example development container included examples of how to leverage the postAttachCommand and postCreateCommand. However, this was a big mistake that I don't recommend because I ended up copying and pasting different lines that I thought were arbitrary, but they impacted the project, and I had to delete those lines.

My recommendation is to use the command palette to add a barebones development container, and then customize it from there.

Here's what our boilerplate devcontainer.json file could look like:

My recommendation is to use the command palette to add a barebones development container, and then customize it from there.

Here’s what our boilerplate devcontainer.json file could look like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  // "forwardPorts": [],

  // Use 'postCreateCommand' to run commands after the container is created.

  // "postCreateCommand": "pip3 install --user -r requirements.txt",

  // Configure tool-specific properties.

  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Step 4: Customize the dev container

At this point, the repository now has a development container, but it still doesn’t run or install anything because this development container is just boilerplate, and it has zero knowledge of what my project needs to run automatically.

Install dependencies

Based on the local set up, one of the first steps for this project is to install dependencies by running this command:

pip install -r requirements.txt

I needed to make GitHub Codespaces run this command, so the developer wouldn’t have to manually run it. I added this line to the postCreateCommand. The postCreateCommand is responsible for running commands after the container is created. The line looked like this:

postCreateCommand: pip install -r requirements.txt

So now, my development container looked like this:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  // "forwardPorts": [],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  // Configure tool-specific properties.

  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Port Forwarding

In the dev container, there's an option to define a list of ports where the container is available locally. From the local setup, I saw that the preferred port is localhost:5003, so I added that to the array of forwardedPorts in my devcontainer.json file.

Here’s what the line looked like:

"forwardPorts": [5003],

Here’s what my devcontainer.json file looked like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  // Configure tool-specific properties.

  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Run the project

To locally run the project, developers have to manually run: python main.py, but I wanted GitHub Codespaces to do this instead. I used the postAttachCommand property in my devcontainer.json file to run this command.

The postAttachCommand enables scripts to run in the terminal after the client connects to the codespace. Here's the line I added:

"postAttachCommand": “python main.py”

Here’s what my devcontainer.json file looked like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  “postAttachCommand”: “python main.py”

  // Configure tool-specific properties.

  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Step 5: Test by rebuilding the container

I made all these changes to my development container, but I need to check if it actually works, so I rebuilt my container via the Visual Studio Code command palette and chose the option to "Rebuild container."

After the rebuild was completed, I saw that the Codespace automatically installed the required packages and ran the server on localhost:5003. It also forwarded the port for me to a randomly generated URL that looked like something like:

https://USERNAME-CODESPACE-NAME-vrpqrxxrx7x2rxx-5003.preview.app.github.dev

I copied and pasted the randomly generated URL into ChatGPT, but I received error messages that ChatGPT couldn't find the manifest files nor could it install the plugin.

Step 6: Debugging

Port visibility

I learned that one reason ChatGPT couldn’t find the manifest was because my forwarded port was private, so ChatGPT didn’t have access to the code. Fortunately, I can manually change the port visibility by right clicking the port and switching the visibility from “private” to “public”.

I checked to see if there was a way to have GitHub Codespaces set this port to public automatically. However, after I spoke with the GitHub Codespaces, I learned there was no easy way to do this, and it could cause a potential security breach, so I decided users could manually do this.

Updating the files

Another issue I came across was that there were two files that specified the URL localhost:5003. The names of the files were openapi.yaml and .well-known/ai-plugin.json. However, my new URL was different. It now resembled a randomly generated URL that looked like this: https://USERNAME-CODESPACE-NAME-vrpqrxxrx7x2rxx-5003.preview.app.github.dev.

I felt like I was at an impasse and I had two options:

• I could make developers manually update those files to match their newly generated port. They would just have to follow the directions in the README.md. My problem with this option is that it makes GitHub Codespaces feel clunky. Users already have to update the port visibility and now they have to update the files. (Boo, tomato, tomato, tomato). I wanted to represent GitHub Codespaces in its best light.

• OR I could edit the source code, and replace the words localhost:5003 with something like https://${CODESPACE_NAME}-5003.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}. However, that would ruin the experience for developers who choose to still develop the plugin locally.

I reached out to the Codespaces team for help. They advised me to write a script that dynamically updates the url in those particular files if the repository is opened in a Codespace. The script I wrote looks like this:

#!/bin/bash

set -e

# Determine the value of SITE_HOST based on whether the project is opened in a Codespace

if [ -n "$CODESPACE_NAME" ]; then

        SITE_HOST="https://${CODESPACE_NAME}-5003.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}"

        # Replace "localhost:5003" with the value of SITE_HOST in the ai-plugin.json file

        sed -i "s#http://localhost:5003#${SITE_HOST}#g" .well-known/ai-plugin.json

        # Replace "localhost:5003" with the value of SITE_HOST in the openapi.yaml file

        sed -i "s#http://localhost:5003#${SITE_HOST}#g" openapi.yaml

fi

Instead of having the developer manually run this script, I made my codespace run it automatically by adding the following to my devcontainer.json file:

"postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

Now, before the program runs, the codespace will run this shell script and update the files to use the correct URL.

Here’s what my devcontainer.json looked like:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  "postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

  // Configure tool-specific properties.

  // "customizations": {},

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

I rebuilt the container for testing, and everything worked as expected!

Step 7: Nice-to-haves

Opening important files post-Codespace creation

This is not required, but I thought it would be convenient to have the two most important files opened after the codespace is created. Because this is a new project and just a new concept, I wanted to make it easy for people to navigate the project. And I know there’s a property in a devcontainer.json called openFiles that handles that!

Here are the lines I added:

    "customizations": {

        "codespaces": {

            "openFiles": [

                ".well-known/ai-plugin.json",

                "openapi.yaml"

            ]

        }

    }

}

Here is what my devcontainer.json file looked like at this point:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  "postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

 // Configure tool-specific properties.

  "customizations": {

        "codespaces": {

            "openFiles": [

                ".well-known/ai-plugin.json",

                "openapi.yaml"

            ]

        }

    }

}

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Step 8: Clean up

Everything is working exactly how I wanted, and now I just wanted to clean up any unused properties and confusing comments.

Here’s what my final devcontainer.json file looks like:

// For format details, see https://aka.ms/devcontainer.json.

{

    "name": "ChatGPT Quickstart Plugins",

    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

    "image": "mcr.microsoft.com/devcontainers/python:0-3.11",

    // Use 'forwardPorts' to make a list of ports inside the container available locally.

    "forwardPorts": [

        5003

    ],

    // Use 'postCreateCommand' to run commands after the container is created.

    "postCreateCommand": "pip install -r requirements.txt",

    "postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

    "customizations": {

        "codespaces": {f

            "openFiles": [

                ".well-known/ai-plugin.json",

                "openapi.yaml"

            ]

        }

    }

}

What’s next?

I’ll wait for the OpenAI team to either approve or suggest changes to my pull request. I’m looking forward to seeing it get merged! I'd love to contribute more dev containers to open source projects for folks who want to improve their projects' onboarding experience and enable them to work on their projects within GitHub Codespaces.

If you have questions or any cool things you learned about development containers or GitHub Codespaces, comment below!

First, let's start with the basics for folks who are unfamiliar with GitHub Copilot or prompt engineering.

What is GitHub Copilot?

GitHub Copilot is an AI pair programmer developed by GitHub and GitHub Copilot is powered by OpenAI Codex, a generative pre-trained language model created by OpenAI.that provides contextualized code suggestions based on context from comments and code. To use it, you can install the GitHub Copilot extension available to you in the following Integrated Development Environments (IDEs):

• Visual Studio
• Visual Studio Code
• Neovim
• JetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc)

Can GitHub Copilot code on its own?

At GitHub, we use the terms "AI pair programmer," "AI assistant," and "Copilot" to since this tool cannot work without you – the developer! In fact, AI systems can only perform the tasks that developers program them to perform, and they do not possess free will or the ability to make decisions independently. In this case, GitHub Copilot leverages context from the code and comments you write to suggest code instantly! With GitHub Copilot, you can convert comments to code, autofill repetitive code, and show alternative suggestions.

How does GitHub Copilot work under the hood?

Under the hood, GitHub Copilot draws context from comments and code, instantly suggesting individual lines and whole functions. OpenAI Codex, a machine-learning model that can translate natural language into code, powers GitHub Copilot

What is prompt engineering?

Prompt engineering is the practice of giving an AI model specific instructions to produce the results you want. A prompt is a sequence of text or a line of code that can trigger a response from an AI model. You can liken this concept to receiving a prompt for an essay. You can receive a prompt to write an essay about a time you overcame a challenge or a prompt to write about a classic book, such as the Great Gatsby. As a result, you give a response to the prompt based on what you've learned. A large language model or LLM will behave similarly.

Here's another illustration of prompt engineering: When I learned to code, I participated in an activity where I gave a robot instructions on how to make a sandwich. It was a fun, silly activity that taught me that:

• Computers can only do what you tell them to do
• You need to be very specific with your instructions
• They're better at taking orders one step at a time
• Algorithms are just a series of instructions

For example, if I were to tell the "robot" to make a sandwich, I need to tell it:

1. Open the bag of bread
2. Take the first two slices of bread out of the bag
3. Lay the slices of bread side by side on the counter
4. Spread peanut butter on one slice of bread with a butter knife
5. Et cetera, et cetera, et cetera

Without those clear instructions, the robot might do something silly, like spread peanut butter on both slices of bread, or it might not do anything at all. The robot doesn't know what a sandwich is, and it doesn't know how to make one. It just knows how to follow instructions.

Similarly, GitHub Copilot needs clear, step-by-step instructions to generate the code that best helps you.

Let's discuss best practices for prompt engineering to give clear instructions to GitHub Copilot and generate your desired results.

Best Practices for Prompt Engineering with GitHub Copilot

Provide high-level context followed by more detailed instructions

The best technique for me is providing high-level context in a comment at the top of the file, followed by more detailed instructions in the form of comments and code.

For example, if I'm building a to-do application. At the top, I'll write a comment that says, "Build a to-do application using Next.js that allows user to add, edit, and delete to do items." Then on the following lines, I'll write a comment to create the:

• to-do list component, and I'll let GitHub Copilot generate the component underneath the comment
• button component, and I'll let GitHub Copilot generate the component underneath the comment
• input component, and I'll let GitHub Copilot generate the component underneath the comment
• add function, and I'll let GitHub Copilot generate the function underneath the comment
• edit function, and I'll let GitHub Copilot generate the function underneath the comment
• delete function, and I'll let GitHub Copilot generate the function underneath the comment
• etcetra, etcetera, etcetera...

Here's an example of me using this technique to build a house with p5.js:

In the following GIF, I write a comment at the top describing at a high-level what I want p5.js to draw. I want to draw a white house with a brown roof, a red door, and a red chimney. Then, I write a comment for each element of the house, and I let GitHub Copilot generate the code for each element.

Provide specific details

When you provide specific details, GitHub Copilot will be able to generate more accurate code suggestions. For example, if you want GitHub Copilot to retrieve data from an API, you need to tell it what type of data you want to retrieve, how to process the data, and what API endpoint you're hoping to hit.

Here's an example of a non-specific comment (prompt) where GitHub Copilot will be less likely to generate a useful suggestion:

// Get data from API
function getData() {
  //code goes here
}

In the example above, GitHub Copilot didn't generate anything for me besides the name of the function and the opening and closing brackets.

Here's an example of a specific comment (prompt) where GitHub Copilot will be more likely to generate a useful suggestion:

// Pass in user ids and retrieve user data from jsonplaceholder.typicode.com API, then return it as a JSON object
async function getUserData(userId) {
    const response = await fetch(`https://jsonplaceholder.typicode.com/users/${userId}`);
    const data = await response.json();
    return data;
}

Provide examples

In addition to telling GitHub Copilot what you want it to do, you can also show it what you want it to do with examples in your preferred coding style. While GitHub Copilot is using an AI model that is already trained on a large amount of data, providing examples to GitHub Copilot help it understand the context and constraints of a particular code snippet. Showing AI models examples of what you want them to do is a common practice in machine learning.

Here are a few approaches engineers use to train AI models:

• Zero-shot learning
• One-shot learning
• Few-shot learning

I asked ChatGPT to explain the difference between these methods to me like I was 5 years old, and here’s what it gave me:

Zero-shot learning

This is like when you see a new toy you've never seen before, but you know what it is because it looks like other toys you've seen. For example, if you've seen many different kinds of stuffed animals, you might be able to recognize a new one even if you've never seen that exact one before. Similarly, a computer can learn to recognize new things by using what it knows about similar things to make educated guesses about the new thing.

One-shot learning

This is like when you see a new toy for the first time, and your mom or dad tells you what it's called and what it does. After hearing about it just once, you remember what it is and can recognize it the next time you see it. A computer can learn to recognize new things in the same way by being shown just a few examples and learning from them.

Few-shot learning

Few-shot learning is like learning to do something new by seeing only a few examples. For example, let's say you want to learn how to draw a cat, but you've only seen a few pictures of cats before. With few-shot learning, you can still learn how to draw a cat even if you haven't seen many cats before. It's like a magic power that helps you learn new things quickly, even if you don't have a lot of examples to learn from!

Here's what happened when I showed GitHub Copilot examples vs. when I didn't show it examples:

No example

# Create a list of the first 10 prime numbers
primes = []

for num in range(2, 30):
    if all(num % i != 0 for i in range(2, num)):
        primes.append(num)
print(primes)

In the code snippet above, GitHub Copilot will accurately return the first 10 numbers, however it's inefficient because it will loop through all 29 numbers between 2 and 30. We can get more efficient results by providing an specific example of what we want GitHub Copilot to do.

With example

# Create a list of the first 10 prime numbers
# Example: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29]
primes = []

for num in range(2, 30):
    if all(num % i != 0 for i in range(2, num)):
        primes.append(num)
    if len(primes) == 10:
        break
print(primes)

In the above code snippet, GitHub Copilot will return the first ten prime numbers and stop when it's found all 10. My goal was to get accurate but fast results, and GitHub Copilot successfully achieved that after I nudged it in the right direction.

Additional tips

Iterate your prompts

If your initial prompt elicits the desired response, delete the generated code suggestion, edit your comment with more details and examples, and try again! It's a learning process for you and GitHub Copilot. The more you use it, the better you'll get at communicating with GitHub Copilot.

Keep a tab opened of relevant files in your IDE

Currently, GitHub Copilot does not have the ability to gain context for your entire codebase. However, it can read your current file and any files that are opened in your IDE. I've found it helpful to keep an open tab of relevant files that I want GitHub Copilot to reference. For example, if I'm writing a function that uses a variable from another file, I'll keep that file open in my IDE. This will help GitHub Copilot provide more accurate suggestions.

Give your AI assistant an identity

I received this advice from Leilah Simone, a Developer Advocate at BitRise. I've yet to try this with GitHub Copilot, but it was helpful advice. It helps to control the type of response the user will receive. In Leila's case, she requests that ChatGPT behave as a senior iOS engineer. She says, "It's helped her reduce syntax and linting issues."

Use predictable patterns

As we saw in the many examples above, GitHub Copilot will follow patterns in your code. AI enthusiast and Developer Content Creator, YK aka CS Dojo, shares how he uses this to his advantage:

%

Use consistent, specific naming conventions for variables and functions that describe their purpose

When declaring variables or functions, use names specific to the variable's purpose. This will help GitHub Copilot understand the context of the variable and generate more relevant suggestions. For example, instead of using a generic variable name like "value," use a more specific name like "input_string" or "output_file."

GitHub Copilot will also use the naming conventions you use in your code. For example, if you use camelCase for variables, GitHub Copilot will suggest camelCase variables. If you use snake_case for variables, GitHub Copilot will suggest snake_case variables.

Use good coding practices

While GitHub Copilot can be a powerful tool for generating code suggestions, it's important to remember that it's not a replacement for your own programming skills and expertise. AI models are only as good as the data they have been trained on, Therefore, it's important to use these tools as aids and not rely on them entirely. I encourage every user of GitHub Copilot to:

• Review code
• Run unit tests, integration tests, and any other programatic forms of testing code
• Manually test code to ensure it's working as intended
• And to use good coding practices because GitHub Copilot will follow your coding style and patterns as a guide for its suggestions.

Beyond your editor

Currently, GitHub Copilot is an extension that is available in the most popular IDEs. There's also GitHub Copilot Labs, a separate experimental extension available with GitHub Copilot access. Copilot Labs can help you translate, debug, test, document, and refactor code. Additionally, we recently launched Copilot X, a suite of features that improve developer productivity outside of the IDE. Copilot X includes:

• Copilot for Docs - saves developers from scouring reams of documentation.
• Copilot for Pull Requests - helps you write better PR descriptions and to help your team review and merge PRs faster/
• Copilot Chat - a ChatGPT-like experience in your editor with GitHub Copilot chat.
• Copilot for CLI - helps you remember shell commands and flags to run commands in your terminal faster.
• Copilot Voice - write and edit code, navigate the codebase, and control Visual Studio Code with your voice.

Copilot X features/products are currently in technical preview. If you'd like access to one of the features above, sign up for the waitlist at https://github.com/features/preview/copilot-x.

Start practicing prompt engineering with GitHub Copilot

The best way to learn how to use GitHub Copilot optimally is to start using it. You can sign up for access to GitHub Copilot here.

If you're a business leader and you'd like to give your entire team access to GitHub Copilot, sign up for GitHub Copilot for Business here.

Let's keep learning together

Thanks for reading this blog post. I'd love to hear from you! I'm still learning more about artificial intelligence, GitHub Copilot, and prompt engineering. If you're a GitHub Copilot fan and have learned how to use it to improve your developer workflow, share some of your tips in the comments below!

For similar content, follow GitHub and me on DEV.to! Also, check out other resources to learn more about prompt engineering:

• How to get Codex to produce the code you want
• Prompt Design from OpenAI
• Prompt Engineering 101: Introduction to Codex
• Prompt Engineering Guide by Elvis Saravia

What is GitHub Copilot?

GitHub Copilot has helped redefine productivity for millions of developers by introducing them to the magic of AI assistance. GitHub Copilot is a cloud-based artificial intelligence tool developed by GitHub and OpenAI to assist users of Visual Studio, Visual Studio Code, Neovim, and JetBrains by suggesting lines of code and whole functions instantly. With Copilot, you can write a regular expression or interact with an API for the first time without leaving your editor.

Why I love GitHub Copilot

GitHub Copilot boosts productivity because it helps developers spend more time thinking about the theory they are building than about the code itself.

However, beyond productivity, GitHub Copilot helps provide me with psychological safety. Psychological safety refers to the belief that you can speak up, ask questions, make mistakes, and contribute without fear of punishment or humiliation. When employees feel safe to learn, ask questions, contribute, and lead, it boosts the team’s and individual’s overall confidence, morale, and performance.

Unfortunately, the reality is psychological safety is not always common at work. When I’m feeling uncertain about asking for help, or I’m not even sure how to word my questions, I can use GitHub Copilot to help me:

• Brainstorm ideas when I reach a mental block

• Jog my memory

• Retain focus

• Determine if I’m going in the right direction

Why would I build a rock, paper, scissors game?

• I did this for fun

• I did this to build my Python skills. I’m a baby Pythonista. For the past 5 years, I’ve been writing different forms of JavaScript on the frontend and backend, but ever since I started using GitHub Copilot, I’ve taken up an interest in Python. And I want to continue to read, type, and navigate code written in Python. It’s a less verbose language than JavaScript, so it feels easy for me to learn.

• I wanted to create a short, fun activity to help folks learn how to leverage GitHub Copilot because it’s not always obvious how to get started. Hint: Provide as much context as possible through comments and lines of code.

• I remember building a rock, paper, scissors game when I was in a coding bootcamp back in 2018. At the time, the logic seemed so difficult. I’m hoping this can be a helpful tool for developers who are learning to code.

• I want to continue to creatively use GitHub Copilot for different situations to understand its limitations and strengths.

To complete this tutorial, you will need:

• Access to GitHub Copilot

• Open this repository

How does this work?

The CodeTour prompts developers to write comments and lines of code that trigger GitHub Copilot to generate code to create a rock, paper, scissors game.

What is CodeTour?

CodeTour is a VS Code extension developed by my amazing coworker, Jonathan Carter! It allows developers to create and follow a guided walkthrough of a codebase.

What you will find in this repository

In this repository, you will find:

• a main.py file with no contents

• a devcontainer that installs CodeTour and GitHub Copilot when the Codespace is created

• a CodeTour to guide the developer through using GitHub Copilot to develop a rock, paper, scissors game.

How to use the guided CodeTour

Navigate to this repository that I created. Then follow the instructions below:

Step 1

Choose 'Use this template', and 'Open in a codespace'

Step 2

Choose the “Explorer Icon” on the left sidebar of your editor.

Step 3

Toggle the CodeTour panel

Step 4

Press the “Play button” to start the tour.

Step 5

Your CodeTour will begin! Follow the CodeTour’s steps to learn how to use GitHub Copilot.

Your CodeTour will take you through the following steps

Step 1

Introduction: Hi there! this is a guided tour to help you learn GitHub Copilot. We will build a rock, paper, scissors game with Python.

Step 2

Let's give GitHub Copilot some context about what we're building. Write this comment # Write a rock, paper, scissors, game at the top of your main.py file.

Now, let's prompt Copilot to import the random module. Write this comment # import random module on the next line. Press enter to create a new line and accept Copilot's suggestion.

Step 3

Now, let's prompt Copilot to create a main function that handles the logic of the game with a comment that says # define main function that handles all the logic. Press enter to create a new line and accept Copilot's suggestion.

Step 4

Now, let's prompt Copilot to call the main function. Write this comment # call main function on the next line. Press enter to create a new line and accept Copilot's suggestion.

Step 5

Try it out! Let's run the code to see if it works. In your terminal, run python3 main.py. It should start the rock, paper, scissors game. Mission complete! You've used GitHub Copilot to create a rock, paper, scissors game in Python!

Do you have feedback?

Feel free to create an issue in the repo or comment below!! There’s definitely room for improvement, as this is my first time using CodeTour to guide people through GitHub Copilot.

Follow GitHub and me for similar content about GitHub!

I recently developed a small app that lives on the GitHub domain. Developing the application reminded me of all the struggles I used to have as a software engineer. (I don’t miss the stress of coding on a deadline). One of the struggles I encountered was sharing my environment variables with collaborators. I wanted my teammates to try out the app locally, so they could contribute code or review the user experience, but I wasn’t sure how to tell them to set up their environment variables securely.

• Do I share the environment variables in Slack? Nope, that is unsafe.

• Do I share the variables in a password manager? Sure, but now some of the values are ill-formatted, i.e., RSA keys.

Additional mishaps I’ve experienced in the past:

• I forgot to add my environment files to my .gitignore file, so I accidentally pushed my environment variables files to my repository.

• I accidentally deleted my .env file and then had to generate new API tokens and secrets.

I’m sure there are many solutions for securely storing environment variables in sandbox applications, but GitHub Codespaces worked best for me!

Benefits of using GitHub Codespaces for environment variables

The experience was seamless with GitHub Codespaces because it allowed repository collaborators to go to my repository, open the Codespace, and locally run the code. They didn’t have to fill in the values, so I didn’t have to share the secrets explicitly. Behind the scenes, GitHub Codespaces pulled the values from a store within the repository’s settings called Codespaces Secrets.

How to store your secrets in GitHub Codespaces

To illustrate this example, we will use the NASA API because it’s generally accessible to most developers.

Step 1: Generate a NASA API key

Fill out the form on https://api.nasa.gov/ to request an API key. You should receive the API key in your email. (Save this key because we will use it in step 5).

Step 2: Use the React Codespaces template

Quickstart templates include boilerplate code for some of the most common application frameworks, including Next.js, React.js, Django, Express, Ruby on Rails, Preact, Flask, and Jupyter Notebook. Templates provide developers with a sandbox to build, test, and debug applications in a codespace. This means you don’t have to start from scratch with coding. We already have a working project that you can enhance into the project you’re envisioning. You can use templates to understand how developers structure their projects written in various programming languages. And you can use it to understand how different files communicate with each other.

For example, I’ve always wanted to learn more about artificial intelligence and machine learning, but I had no clue where to start. I used a Jupyter Notebooks template to generate AI images. The template already had all the tools I needed; I just had to change a few lines of code.

For this tutorial, we’ll navigate to https://github.com/codespaces/templates and choose the React template.

Step 3: Wait for your Codespace to load

Once our codespace is fully loaded, you will see a live preview of your web app on a tab titled "Simple Browser." (If you don’t see the “Simple Browser” tab yet, give it a few minutes to load). It should look like the image below:

Step 4: Publish your Codespace

We’re not done yet. Our main goal is to store and reference environment variables in a Codespace. However, we can only do this if our Codespace lives in a repository. To do this, we need to publish our Codespace. Take the following steps to publish the current Codespace:

1. In a new tab, navigate to https://github.com/codespaces. Don’t worry about leaving the tab or window because Codespaces will save your changes.

2. Scroll down to the bottom of the page, and you will see the Codespace you created. It might have a silly name. GitHub Codespace automatically generates names for each Codespace as a form of identification. My Codespace is named “ubiquitous acorn.”

1. Click the three dots on the right-hand side and choose the option “Publish to new repository.”

1. Here, you can give your project a more identifiable name, make the project public, and view your repository with the button “See repository.”

1. This will lead you to your repository on GitHub. It will show the different files within the project, too. You can share the link to your repository for other developers to collaborate with you or explore your codebase!

Step 5: Store your environment variables

In your new repository, navigate to Settings > Secrets and variables > Codespaces. You can also find the correct page by navigating to a URL that looks like this: ​​https://github.com/REPLACE_WITH_GITHUB_OWNER/REPLACE_WITH_GITHUB_REPO/settings/secrets/codespaces

The page you land on should look like the image below:

Let’s create two repository secrets:

• REACT_APP_NASA_ENDPOINT=https://api.nasa.gov/

• REACT_APP_NASA_API_KEY= This is where you will add your NASA API key

Now, we can refer to these variables in our codebase using the convention: process.env.{ENVIRONMENT_VARIABLE_NAME}

Step 6: Reload your Codespace

Once you add the new API keys, your Codespace should “automagically” recognize that you added new secrets to your Codespace. If so, a notification will pop up in your Codespace that says, “Your codespace secrets have changed. Reload to apply.”

Press the “Reload to apply” button for the changes to take effect.

Step 7: Install axios

Axios is the npm package we’ll use to make calls to the NASA API. Run this command in your Codespace’s terminal to install axios:

npm install --save axios

Step 8: Create a new file

(I used Wayne Fornworth’s blog post on Medium for this step. I’ve used the NASA API in the past, but I felt a little lazy while building this out. Thank you, Wayne, for your blog post! )

Create a file in your src directory called, HttpClient.js then add the following lines of code to that file:

(Note: Lines 2 and 3 refer to the secrets we created by using process.env.{ENVIRONMENT_VARIABLE_NAME} )

import axios from "axios"

const nasaEndpoint = process.env.REACT_APP_NASA_ENDPOINT
const nasaApiKey = process.env.REACT_APP_NASA_API_KEY

axios.interceptors.request.use(
  config => {
    config.params = config.params ? config.params : {}
    const configUrl = config.url
    if (configUrl.includes(nasaEndpoint)) {
      config.params["api_key"] = nasaApiKey
    }

    return config
  },
  error => {
    return Promise.reject(error)
  }
)

export default {
  getApod() {
    return axios.get(`${nasaEndpoint}planetary/apod`)
  },
}

Step 9: Update your App.js file

Delete the current contents of your src/App.js file and replace it with the following lines of code:

import React, { useState, useEffect } from "react"
import HttpClient from "./HttpClient"

const App = () => {
  const [apod, setApod] = useState({})

  useEffect(() => {
    HttpClient.getApod().then(apodData => {
      setApod(apodData.data)
    })
  }, [])

  return (
    <div style={{ maxWidth: 900, padding: 30 }}>
      <h1>NASA API</h1>
      <h2>Astronomy Picture of the Day</h2>
      {apod && (
        <article>
          <header>
            {apod.title} - <i>{apod.date}</i>
          </header>
          <img src={apod.url} alt="APOD" width="800" height="auto" />
          <p>{apod.explanation}</p>
          <pre
            style={{
              overflowX: "auto",
              whiteSpace: "pre-wrap",
              wordWrap: "break-word",
            }}
          >
            <hr />
            {JSON.stringify(apod, null, 2)}
          </pre>
        </article>
      )}
    </div>
  )
}

export default App

Step 10: Check out your creation

If successful, your simple browser tab should render an image similar to the one below:

Step 11: Make it accessible to others!

Anyone can open your Codespace, but the environment variables will not work for everyone. For folks to see the same results (as in, for the API call to work), you’ll need to add the users as repository collaborators. If they are not repository collaborators, they will say page with a broken image instead. Check out the GitHub documentation to learn how to add collaborators to your repository.

Things to remember

• This is an API call for the NASA Astronomy Picture of the Day, so the image may vary depending on the day that you make this API call. The picture in the image above is for the date .

• Now, if someone with repository collaborator access opens your repository in a Codespace, they can get the same results without filling in environment variables because you already stored the correct values in your repository’s Codespaces secrets.

• Take a look at my repository to double check your code. Please remember that if you open this repository in a Codespace, you will see a broken web page because you’re not a collaborator of the repository.

• This method works best for local development within a Codespace. If you deploy the code to another environment, you’ll need to define the environment variables using the suggested method of your server provider.

• You can use secrets in a codespace after the codespace is built and running. For example, a secret can be used:

  • When launching an application from the integrated terminal or ssh session.

  • Within a dev container lifecycle script that is run after the codespace is running. For more information about dev container lifecycle scripts, see the documentation on the Development Containers website: Specification.

• Codespace secrets cannot be used:

  • During codespace build time (that is, within a Dockerfile or custom entry point).

  • Within a dev container feature. For more information, see the features property in the dev containers specification on the Development Containers website.

Hope this helps! If you liked this post, follow GitHub and me for more content!

Short answer: Yes, GitHub Copilot could be a valuable investment for your team.

Long answer: It depends on your team's specific needs.

I’ll start by admitting that I am biased. I work at GitHub, and I love Copilot. GitHub Copilot helped me rediscover the joy of coding. I used to love coding. Then, I experienced burnout and imposter syndrome, and I struggled with opening my code editor. However, besides those two factors, I think GitHub Copilot solves a shared problem for developers and business stakeholders: speed.

The problem with speed in software development

Businesses need to make money to survive, pay their employees, and continue paying for the technology that supports their applications. Investors expect a return on investment, and customers expect features that meet their needs. In an ideal world, software developers would have the time and resources to write, test, refactor, and deploy code at their own pace. But the reality is that businesses need features delivered quickly. This can lead to pressure on software developers to move faster, but to the non-developers it can feel like software developers aren’t moving fast enough.

Why are software engineers taking so long to code?

Coding is hard. Software developers face numerous challenges, such as:

• Estimating the time it will take to complete a task

• Envisioning all the problems they may encounter while coding

• Being asked to complete a task quickly without understanding the complexity involved

Many times in my career, non-developers like salespeople or product managers have told me, “Here’s the feature we want, but it shouldn’t take you too long.” Spoiler alert: I hate to admit it, but it always takes me longer than expected. Sometimes, it may seem like I just have to update one word or change one picture. However, the request might mean I have to venture into an unfamiliar part of the codebase, learn a new tool, or make a change that could potentially disrupt the entire system. I come from the startup world where we’ve adopted the “Move fast and break things” motto, so my software development process often looks like this:

• Researching possibilities

• Designing the feature

• Reading documentation

• Starting to code while referring to documentation

• Realizing that the initial plan won't work and starting over

• Adding workarounds to meet the deadline

• Rushed testing and deployment

• Fixing bugs after the code breaks in production

This cycle of coding, testing, and fixing can lead to burnout and decreased motivation to continue building skills and contributing to the company's success.

What do software developers want?

Software developers want to feel valued and have the opportunity to continue building their skills. Improving skills can mean watching educational content, building side projects, attending conferences, and more. However, with a heavy workload, finding time to do anything outside of work-related tasks can be challenging. (Yes, many companies provide 10% learning time as a benefit, but it feels like a formality. It’s hard to use this benefit when the engineer’s learning time is not accounted for during the sprint.)

When I’m unable to build my skills, and I feel like there aren’t enough hours in a day, I start fantasizing about working at a different company. Is there a company where coding doesn’t feel stressful, and I’ll feel motivated to learn, blog, build my career, and still maintain a healthy work-life balance?

Enter GitHub Copilot

GitHub Copilot helps software developers write code faster by reducing the time spent sifting through documentation, writing boilerplate code, and trying to remember syntax. With GitHub Copilot, software developers can have more time to focus on their passion for coding, which helps businesses retain investors, customers, and most importantly, software developers. (Yes, you can always replace software developers, but software developers with legacy knowledge of the codebase are invaluable to a company’s success.)

Examples of GitHub Copilot’s positive impact on developers

Less time reading documentation

In the example below, Chris Sev explains that instead of spending too much time reading documentation and context-switching, GitHub Copilot led him in the right direction.

Less time writing boilerplate code

In the example below, Kelsey Hightower used GitHub Copilot to handle writing boilerplate code.

Less time recalling syntax

We all forget syntax sometimes. Memorizing code is not the best use of anyone’s type. In the example below, GitHub Copilot helps Lisa Reiber focus on the logic rather than the syntax.

Bonus: Writing code is more accessible

As an industry, we’re learning to prioritize accessibility for the user. But, what about the developer? The GitHub Next team is making coding more accessible for developers of all backgrounds with the following experimental features:

• Hey, GitHub - a voice-activated AI programmer that allows you to code hands-free

• GitHub Copilot CLI - GitHub Copilot assistance in the terminal

• GitHub Copilot Labs - provides an explanation of code snippets in your codebase

As someone who struggles with impostor syndrome and anxiety (as many developers do), GitHub Copilot gives me an extra boost of confidence and reassurance that I’m going in the right direction.

Additionally, I’ve noticed that GitHub Copilot can understand other spoken languages. Code is American-English centric, which can be a barrier to non-English speaking software engineers. If you write a comment in a non-native language like Spanish or German, GitHub Copilot can still suggest code to help developers build applications.

Will Copilot steal my company's code?

With Copilot for Business, GitHub won’t retain code snippets, store, or share your code regardless if the data is from public repositories, private repositories, non-GitHub repositories, or local files.

Additionally, GitHub built a filter to help detect and suppress GitHub Copilot suggestions that contain code that matches public code on GitHub.

For more information on privacy and fairness around GitHub Copilot, check out the features page and scroll down to the FAQ section.

Learn more

Whether or not GitHub Copilot is a valuable investment for your team depends on your team's specific needs. However, it’s worth considering.

You can learn more about how GitHub Copilot increases developer happiness and productivity by checking out the following posts:

• GitHub Copilot Research Recitation

• How GitHub Copilot helps improve developer productivity

• 8 things you didn’t know you could do with GitHub Copilot