DEV Community: Burke Holland

How to Replace Yourself with GitHub Copilot (And Still Get Paid)

Burke Holland — Thu, 06 Feb 2025 07:41:00 +0000

Disclaimer: This article is mostly satire. I don’t think Copilot is going to replace you, nor do I think you should engage in any of the suggested behaviour. Feel free to wildly misinterpret my views to maximize engagement.

You’ve probably seen all the articles telling you how to “supercharge your development workflow” with GitHub Copilot. “Write code faster!” they say. “Boost productivity!” “Improve efficiency!”

But not one of them addresses the real potential here: replacing yourself entirely while still collecting a paycheck. Let’s be honest—writing code is exhausting. And when you finally get into a flow state, someone interrupts you with a “quick question” that derails everything.

Wouldn’t it be nice if something else did all the work for you? Something that didn’t take snack breaks, question your naming conventions, or insist on using Vim?

The secret to doing less and accomplishing more

So, how do we completely offload our careers onto an AI without anyone noticing? I’m glad you asked. Here’s how I did it.

Step 1: Install Copilot

Installation is easy, but you should act like it was incredibly complex when explaining it to your manager. Bonus points if you casually drop phrases like:

“Yeah, I had to configure the LSP integrations manually.”
“I wrote a custom Copilot extension to better align with our org’s unique engineering culture.”
“Bro, it’s basically like GPT-4 but, like, for enterprise devs…”

Now everyone thinks you’re some kind of wizard. Great. Let’s move on.

Step 2: Let the AI do the heavy lifting

Here’s the pro move: don’t just let Copilot assist you—let Copilot BE you.

You start typing:

function calculateTax(income) {

Copilot finishes the function before you even remember how tax brackets work. Boom. Done.

Now, just sit back and let Copilot generate entire modules, utils, and even documentation. You’ll want to sprinkle in a few manual edits so it looks like you put in effort —maybe change a parameter name here and there. Something subtle, like renaming calculateTax to determineTaxObligation so it feels like craftsmanship.

Step 3: Ship it before anyone realizes what happened

Now that you’ve got Copilot doing 80% of the work, you need to commit and push frequently to establish dominance.

Write exactly two lines of real code.
Let Copilot autocomplete the rest.
Commit with something vague and impressive like:

feat: optimize tax calculation algorithm

Profit.

Congratulations. You just outperformed half your team.

But what if the code doesn’t work?

Hahaha, oh, sweet summer child. That’s not your problem. That’s what code reviews are for. Your PR will get torn apart, but you can just say:

“Yeah, I had considered that but wanted to get early feedback.”
“Great catch! Totally meant to address that.”
“Ah, good call—I think Copilot auto-filled that from an older function.”

This shifts blame onto the AI while making you look super thoughtful.

The inevitable downfall

At some point, teams will realize that Copilot is doing all the work. Managers will start asking questions:

“Why did you try to implement a GraphQL client in our backend which literally doesn’t use GraphQL?” (Uh, because Copilot said so?)
“Why are all your commits five seconds apart but in perfect English?” (Listen, AI is just built different, okay?)
“Why did you commit an entire Stack Overflow thread into utils.js?” (Research-based development, obviously.)

Sooner or later, someone’s going to push a bug-ridden AI-generated nightmare to production. And then… well, I wouldn’t know. I don’t work here anymore.

Final thoughts

GitHub Copilot is an insane game-changer , but let’s be real: it still makes dumb mistakes because it learned from us. That’s not Copilot’s fault. That’s a you problem.

So, should you use Copilot to write every line of code? Definitely not.

Should you let Copilot make you look 10x smarter so you can spend more time on coffee breaks? Absolutely.

Look, I don’t make the rules. This is just how business works.

Go forth and generate recklessly.

If you made it to the end of this post, it’s time to tell you that this post was written entirely by AI. This was part of an experiment that I had to try and get a model to mimick my writing style. I was pleasantly suprised by the ouput here. Sarcasm isn’t easy, and GPT-4o is doing a pretty remarkable job at it.

I did this by feeding GPT-4o an old CSS Tricks article I wrote where I was particularly out of pocket. Then I gave it a very simple prompt…

Write a blog post about GitHub Copilot in the style of this author

Which means the AI translated my prompt into a pretty engaging idea - replacing yourself with GitHub Copilot. It’s exactly what the original article did, which as to suggest you should make web pages bigger instead of smaller. It was also satire.

There are some parts here that I think are particularly hilarious…

Commit with something vague and impressive like:
feat: optimize tax calculation algorithm  
Congratulations. You just outperformed half your team.

I think my favorite was…

Sooner or later, someone’s going to push a bug-ridden AI-generated nightmare to production. And then… well, I wouldn’t know. I don’t work here anymore.

I mean - that’s pretty great. I think it is at least. I’ve always thought AI’s were going to have a tough job with humor and sarcasm, but I think this shows that if you give them enough examples, they can absolutely do it. Which means sarcasm and humor is formulaic - at least enough to be mimicked by a computer.

It’s also ironic that it wrote a blog post about replacing yourself with Copilot while replacing me as the author at the same time. So meta!

Essential custom instructions for GitHub Copilot

Burke Holland — Sun, 05 Jan 2025 11:58:00 +0000

Prompt engineering - or should I say “Prompt Negotiation” - is (currently) an important part of working with GitHub Copilot. Your success in working with the various available models will be directly related to how well you prompt them. While GitHub Copilot tries to handle much of the prompt engineering for you behind the scenes, there is still a lot you can do yourself to improve the accuracy of answers with the use of Custom Instructions.

Custom Instructions

Custom Instructions are exactly that - custom prompts that get sent to the model with every request.

You can define these at a project level or at an editor level. Often these are demonstrated as specific project level instructions such as a command like prefer fetch over axios. These project specifc custom instructions are quite powerful and can be checked in and shared. You can create a custom instructions file for your project by adding a .github/gopilot-instructions.md file, or by adding a file attribute to the instructions settings. You can have multiple of these file attributes which means you can have multiple different instructions files.

These very specific types of project instructions are super helpful with getting better help from your AI pair progammer. But it’s less obvious what you can/should do with the more global, editor level instructions.

I’ve been working heavily with GitHub Copilot for the past several months, and I’ve added 4 custom instructions that I’ve found greatly increase my productivity with GitHub Copilot. These are more generic prompt engineering “best practices” will help you avoid pitfalls and get better code from the LLM.

You can add the “global instructions” that I’m about to give you by going to your User Settings (JSON) file and adding keys like so…

"github.copilot.chat.codeGeneration.instructions": [
    { "text": "this is an example of a custom instruction" }
]

Ok - let’s do it.

Ask for missing context

“Avoid making assumptions. If you need additional context to accurately answer the user, ask the user for the missing information. Be specific about which context you need.”

The achilles heal of LLM’s is that they are designed to provide a response no matter what. It’s the paperclip problem applied to LLM’s. If you design a system to provide an answer, it is going to do that at all costs. This is why we get hallucinations.

If I said to you, “make a GET request to the api”, you would likely ask me several follow-up questions so that you could actually complete that task in a way that works. An LLM will just write a random GET request because it does not actually care if the code works or not.

Copilot tries to mitigate a lot of this for you with its sytem prompt, but you can reduce hallucinations further by instructing the AI to ask you for clarification if it needs more context.

This isn’t bullet proof. LLM’s seem so hell bent on answering you at all costs that often I find this instruction is just ignored. But on the occasions that it works, it’s a nice surprise.

Provide file names

“Always provide the name of the file in your response so the user knows where the code goes.”

I’ve noticed that Copilot will sometimes give me back several blocks of code, but won’t mention where they belong. I then have to figure out which files it is referring to which takes an extra cycle. This prompt forces the LLM to always provide the file name.

If you are working in theoretical space where you aren’t talking about specific project files, Copilot will provide made up file names for the code snippets. This is fine because it’s a detail that doesn’t matter in that context.

Write modular code

“Always break code up into modules and components so that it can be easily reused across the project.”

I tend to write a lot of frontend code, which is all about components these days. I’ve found that Copilot will often try and do too much in a single file when it should ideally break out UI code into separate components. AI’s are fairly good at organization, so if you ask it to break things out into components, Copilot will do an impressive job of suggesting the right places to decouple. I’ve found this prompt works quite well in non-UI code as well. If I ask for a change in an API, this prompt helps Copilot break out services, repositories, etc.

Code quality incentives

“All code you write MUST be fully optimized. ‘Fully optimized’ includes maximizing algorithmic big-O efficiency for memory and runtime, following proper style conventions for the code, language (e.g. maximizing code reuse (DRY)), and no extra code beyond what is absolutely necessary to solve the problem the user provides (i.e. no technical debt). If the code is not fully optimized, you will be fined $100.”

This prompt comes almost verbatim from Max Wolf’s “Can LLM’s write better code”. In this post, Max decribes trying to get LLM’s to write better by code iterating on the same piece of code with the prompt, “write better code”. He finds that the above prompt combined with Chain of Thought produces very nice results - specifically when used with Claude. He uses the very last line to incentivize the LLM to improve it’s answers in iteration. In other words, if the LLM returns a bad answer, your next response should inform the LLM that it has been fined. In theory, this makes the LLM write better code because it has an incentive to do so when it otherwise might keep on returning bogus answers.

Chain of thought is when you tell the model to “slow down and go one step at a time”. You don’t need to tell Copilot to do this because that is already part of the system prompt.

The model matters more than the prompt

While these prompts will help you get better results from Copilot, in my experience the most effective thing you can do is pick the right model for the job. As of today, I see it like this…

GPT-4o : Specific tasks that don’t require much “creativity”. Use 4o when you know exactly what code you need and it’s just faster if the LLM writes it.

Claude : Harder problems and solutions requiring creative thinking. This would be when you aren’t sure how something should be implemented, it requires multiple changes in multiple files, etc. Claude is also exponentially better at helping with design tasks than GPT-4o seems to be in my experience

o1 : Implementation plans, brainstorming and docs writing. My friend Martin Woodward finds that o1 is particularly good with tricky bugs and performance optimizations.

Gemini : Not widely available yet. I’m using this one more and watching it closely to see where it shines. I have high hopes.

Living instructions

I hope these instructions are helpful for you. I consider them “living” and I hope to keep this list updated as I add more or change these as Copilot itself evolves, new models come along and our general knowledge of prompting improves.

🚀 Introducing VS Code Remote Tunnels: Connect to Remote Machines with Ease!

Burke Holland — Mon, 17 Jul 2023 18:22:52 +0000

Are you tired of constantly moving your code back and forth between your local machine and a remote server? Do you wish you could seamlessly develop on a remote machine without the hassle of SSH? Look no further! The Visual Studio Code Remote - Tunnels extension is here to solve your problems.

In today's fast-paced development world, it's becoming common to work on projects hosted on remote machines. Whether it's a powerful desktop PC or a virtual machine (VM), the Remote - Tunnels extension allows you to connect to it securely from your VS Code client anywhere.

But what exactly does "tunneling" mean? Tunneling is the process of securely transmitting data from one network to another. With the Remote - Tunnels extension, you can access your code and run commands directly on the remote machine, eliminating the need to have the source code on your local machine.

Sounds interesting, right? Let's explore how you can get started with the Remote - Tunnels extension.

🛠️ Getting Started: Two Paths to Remote Tunnels

There are two ways to work with tunnels using the Remote - Tunnels extension. You can either use the command-line interface (CLI) or enable tunneling through the VS Code Desktop UI. Both methods provide the same tunneling functionality, so you can choose the one that suits your workflow the best.

1️⃣ Using the 'code' CLI

If you prefer working with the command line, the code CLI is perfect for you. First, install the code CLI on the remote machine where you want to develop from your VS Code client. The CLI establishes a secure tunnel between your client and the remote machine. And the best part? The CLI is already built into the VS Code Desktop, so there's no additional setup required.

If you can't install the full VS Code Desktop on your remote machine, don't worry. You can download the CLI as a standalone installation from the VS Code download page. Alternatively, you can install and unpack the CLI through the terminal of your remote machine.

curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64' --output vscode_cli.tar.gz

tar -xf vscode_cli.tar.gz

Once you have the code CLI set up, creating a secure tunnel is as easy as running the following command:

code tunnel

This command downloads and starts the VS Code Server on the remote machine and establishes a tunnel to it. You'll be provided with a vscode.dev URL tied to this remote machine, which you can open in any VS Code client.

2️⃣ Using the VS Code UI

If you prefer a more visual approach, you can enable tunneling through the VS Code Desktop UI. Simply open VS Code on the remote machine where you want to enable tunnel access.

From the VS Code Account menu, select the option to "Turn on Remote Tunnel Access." Alternatively, you can open the Command Palette (F1) and run the command "Remote Tunnels: Turn on Remote Tunnel Access."

After logging into your GitHub account, a tunnel will start up on your current machine, allowing you to connect to it remotely. You can open the vscode.dev link from the notification and start coding in the remote environment.

🔒 Secure and Convenient: The Remote - Tunnels Extension

By now, you might be wondering how the Remote - Tunnels extension fits into all of this. Well, when you open a vscode.dev instance through either the code CLI or VS Code UI, the Remote - Tunnels extension is automatically preinstalled.

If you're already working in VS Code (desktop or web) and want to connect to a remote tunnel, you can install and use the Remote - Tunnels extension directly. Once installed, you can connect to any remote machines with an active tunnel through the Command Palette.

The Remote Explorer view allows you to see your remote machines and easily manage the tunnel connections. You can focus on the Remote Explorer using the command "Remote Explorer: Focus on Remote View." The green remote indicator in the lower-left corner of the VS Code window also provides quick access to Remote Tunnels commands.

🌐 Common Questions: Answers You've Been Looking For

What is the relationship between Remote Tunnels, VS Code Server, and Remote Development?

Remote Development allows your local VS Code installation to seamlessly interact with source code and runtime environments on other machines, whether virtual or physical. The VS Code Server, which is quickly installed by VS Code when you connect to a remote endpoint, enables this interaction. The Remote - Tunnels extension facilitates the connection to the remote machine where the VS Code Server is running.

Can multiple users or clients access the same remote instance simultaneously?

No, an instance of the VS Code Server can only be accessed by one user or client at a time.

How do I remove a tunnel or machine?

To stop a tunnel, you can use the shortcut Ctrl + C if you're running the CLI. In the VS Code UI, you can run the command "Remote Tunnels: Turn off Remote Tunnel Access..." to disable tunneling. To remove a machine's association with tunneling, you can use the "code tunnel unregister" command, or unregister it directly from the Remote Explorer view.

How secure are the tunnels?

Accessing a tunnel requires authentication with your GitHub or Microsoft account. Once you connect from a remote VS Code instance, an SSH connection is established over the tunnel, providing end-to-end encryption using AES 256 in CTR mode.

🚦 Usage Limits: Everything You Need to Know

To prevent abuse, there are usage limits in place for resources like the number of tunnels and bandwidth. However, most users will never reach these limits. For example, at the moment, you can have up to 5 tunnels registered for your account. If you want to create a new tunnel and already have 5 others registered, the CLI will automatically pick a random unused tunnel and delete it.

If you require additional usage beyond the limits, you can get in touch with the team at vscodeserver@microsoft.com.

💡 Conclusion: Simplify Your Remote Development Workflow Today!

The Visual Studio Code Remote - Tunnels extension is a game-changer for developers who work with remote machines. It streamlines the process of connecting to remote environments, allowing you to focus on what matters most: your code.

No more syncing code between machines or dealing with the complexities of SSH. With the Remote - Tunnels extension, you can seamlessly develop on any remote machine with ease. Whether you choose the CLI or the VS Code UI, connecting to a remote machine has never been simpler.

So go ahead, give it a try. Install the extension, create a tunnel, and experience the power of remote development firsthand.

Happy coding!

Full Disclosure: This post was written with the help of gpt-3.5turbo-16k.

Programming HORROR Stories

Burke Holland — Thu, 28 Apr 2022 22:11:17 +0000

Programming horror stories: I've got one. You've probably got at least one yourself. And I know that because there is an entire sub-reddit dedicated to the subject.

My horror story is a long one, but we can just summarize it with the letters "XSLT". Apologies up front because you can't unsee that.

But mine kind of pales in comparison to a few of the ones out there that I've heard. Here are two horror stories from good developers like you and me who were just in the wrong place at the wrong time.

The monster hiding in your code

This one is truly terrifying. I couldn't even believe it when I read the original story on reddit. Believe it or not, there is such thing as a "zero width" unicode character and, well, you can imagine the chaos this can cause you if it ends up in your code...

SHEESH.

Can you imagine spending hours looking for a character that you literally can't see? That is the kind of thing that would make you seriously reconsider your career choice. But more importantly, HOW DID THAT CHARACTER GET THERE?!?!

Losing code into the abyss

This one is about the core fear that ever developer has - losing your work. We've got source control for this, but it still happens? How does it it happen? With the right series of events and some small mistakes along the way...

Now yes, you should always commit your work, but the point is that these things happen. Nobody is perfect and it's way too easy to destroy hours of good work with a single click. I know. I've done this myself!

I've seen some 💩

I'm...old. We don't need to get into specific numbers, but sometimes I feel like that Batman meme...

Every last name in the ERP database changed to the same thing. All credit card purchases made in the last 24 hours double charged because asynchronous processing is hard. A 6 month refactor that yields a much slower and worse UI. The nightmare goes on an on.

But what about you? What are your programming horror stories?

How to add your dotfiles to GitHub Codespaces

Burke Holland — Fri, 29 Oct 2021 16:44:36 +0000

One of the first things you are gonna realize after you get started with Codespaces, is that you desperately want your own custom environment setup that you enjoy locally to somehow magically be in Codespaces as well. You can do that using a "dotfiles" repo, and in this post, we're going to look at how to setup a dotfiles repo, and what quirks you need to be aware of to use it with Codespaces.

What's a dotfile?

A "dotfile" is any configuration files that start with a dot. You can view your dotfiles by going to your home directory on your machine (cd ~) and running ls -al. For instance, the ".zshrc" file allows you to tweak how your shell (terminal) looks and works. Behold, the glory of my terminal in Codespaces - powered by my .zshrc file...

For this post, we're only going to focus on the ".zshrc" file as that's where all of my terminal configuration can be found. But this post isn't about oh-my-zsh and how it's the best shell and that's not up for debate. This process will work for any dotfiles.

People like things that come in steps, so here you go...

Step 1. Setup a dotfiles GitHub repo

It's common practice to put your dotfiles in a GitHub repo. There are plenty of blog posts that will tell you all about how to setup the repo, create symlinks, keep everything in sync with cron jobs or something - I don't know. I didn't actually read them. It's the internet and I'm too busy to do my own research.

All you need to know for now is that you need to create a GitHub repo called "dotfiles". Convention over configuration and all of that, but no surprise there because GitHub is a Rails app after all.

So create the "dotfiles" repo on GitHub and then on to step 2.

Step 2. Add your dotfiles

Copy just the ".zshrc" file into your "dotfiles" project. That's all there is for step 2. A paragraph has at last 3 sentences.

Step 3. Update your .zshrc file

Your ".zshrc" file needs a little updating. You need to find anywhere that references your home path directly and replace it with the HOME environment variable. This is because Codespaces don't run under your account so the directory structure is doing to be a bit different.

BEFORE

# Path to your oh-my-zsh installation.
export ZSH="/home/burkeholland/.oh-my-zsh"

AFTER

# Path to your oh-my-zsh installation.
export ZSH="${HOME}/.oh-my-zsh"

Now you can add whatever you like - themes, plugins, stuff you copied and pasted from StackOverflow and you don't remember what it does. You know - all the stuff you normally do in your ".zshrc" file. To keep it simple, I'm just going to do a theme and plugins, but we'll throw a wrench in here and use plugins that need to be installed separately and then cover how to do that. So here's our completed sample ".zshrc" file. Don't forget to source oh-my-zsh.sh!

# Path to your oh-my-zsh installation.
export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME="cloud"

# zsh-nvm and zsh-autosuggestions must be installed separately
plugins=(git zsh-nvm zsh-autosuggestions)

source $ZSH/oh-my-zsh.sh

Step 4. Add a shell script to load your dotfiles

Now if our ".zshrc" file wasn't trying to load plugins that don't exist, we could just use it as is. As long as it's in the root of the repo, Codespaces will copy this (and any other dotfile) to the $HOME directory in your Codespace. Which is where you want them. But we threw some chaos into the situation by including plugins that need to be installed separately, and I did that so we can examine what happens when you need to run a script to properly "install" your dotfiles - which is frequently the case because you'll end up trying to do all manner of crazy things to your Codespace and by God, I want you to realize all your hopes and dreams.

You can add a script file to your dotfiles repo that will be executed when the dotfiles are loaded into your Codespaces. You do have to give it the proper name, but GitHub gives you several to choose from. For this example, we'll just use install.sh. When Codespaces detects a script file in your dotfiles repo, it clones the dotfiles repo to "/workspaces/.codespaces/.persistedshare/dotfiles" and then executes your script file. It expects your script file to do all of the copying of dotfiles to the correct place.

In the script file, you'll need to first make it executable by adding #!/bin/bash. Not all Linux distros include "bash", so if "bash" isn't present in your Codespace, you can use #!/bin/sh.

I like to wrap up all my logic in a function and call that function. This script file is only handling the ".zshrc", but it could handle all sorts of other dotfiles install logic in the future, so having separate functions will make me look like a "real" developer. In this function, we're going to install the 2 plugins: zsh-autosuggestions and zsh-nvm.

#!/bin/sh

zshrc() {
    echo "==========================================================="
    echo "             cloning zsh-autosuggestions                   "
    echo "-----------------------------------------------------------"                    
    git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
    echo "==========================================================="
    echo "                 cloning zsh-zsh-nvm                       "
    echo "-----------------------------------------------------------"                 
    git clone https://github.com/lukechilds/zsh-nvm ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-nvm
    echo "==========================================================="
    echo "                  Import zshrc                             "
    echo "-----------------------------------------------------------"
    cat .zshrc > $HOME/.zshrc
}

zshrc

"Adding" these plugins is just cloning them into the custom plugins directory. Just pay attention to the destination and make sure you are using the ZSH_CUSTOM variable so they end up in the right place.

The last thing we do in that script is overwrite the ".zshrc" file in the HOME directory with the contents of the one from our dotfiles repo. Remember, when when Codespaces detects a script file in your dotfiles repo, it copies the whole thing to "/workspaces/.codespaces/.persistedshare/dotfiles". So it's on YOU to copy those dotfiles to the right place with your script file.

Step 5. Mark the install script as executable with git

Now you need to tell git that this file is executable. I figured this out just last week after getting "file is not executable" over and over and Googling my fingers off. You need to git add the "install.sh" as executable. If you've already added it, remove it with git rm --cached install.sh.

git add install.sh --chmod=+x

You can also mark the file as executable with git update-index --chmod=+x install.sh, but if you do that, every time you change the script file the executable bit will get flipped off and you'll have to run that command again and you will forget and get stuck in a cycle of "file is not executable" and you will subconsciously blame me and I don't need that on my conscience.

NOTE: After you add the install.sh with the +x (executable) bit turned on and commit, git may still show that install.sh file as having changes. Reject those changes because you'll just be flipping the bit back. It's tedious. I know.

Now commit all your files and push them to your repo.

Step 5: Link your dotfiles repo to Codespaces

Navigate to https://github.com/settings/codespaces and select your dotfiles repo at the top. This will link your dotfiles repo to any new Codespace that you have.

If you already have a Codespace, doing a rebuild should pull in your dotfiles. If you change your dotfiles, rebuilding your Codespace will pull in those changes as well.

Step 6: Make sure the right shell is being loaded

By default, Codespaces load "oh-my-bash", which is kind of like "oh-my-zsh", but not at all "oh-my-zsh". You need to tell your Codespace to load zsh as your terminal. Thanks to @brettsky on Twitter for pointing out that the easiest way to that is to add the following to your VS Code settings (Cmd/Ctrl + ,)...

"terminal.integrated.defaultProfile.linux": "zsh"

If you don't do this, your zsh shell just won't be loaded and it will look like your dotfiles are doing nothing.

Take your custom environment with you

Having your dotfiles automatically installed basically lets you configure every Codespace automatically so you always get the environment that you know and love. It's also only specific to you, so someone who forks your repo won't get your terminal. Even though they would be better off if they did and we both know it.

How to use 'Dark Mode' in VS Code

Burke Holland — Sat, 27 Feb 2021 15:08:40 +0000

After my post on how to auto-switch your theme based on the time of day, a few readers pointed out that VS Code “does this automatically”. In other words, you don’t need the extension that I recommended to do this.

I had no idea! Is this true? Kind of…

While VS Code doesn’t have built-in ability to change your theme based on the time of day, it does have the ability to change your theme based on whether or not you are using “Dark Mode” in your Operating System. This is done via the workbench.prefferedLightTheme and workbench.preferredDarkColorTheme settings. You must use these in conjunction with the autoDetectColorScheme setting in order for them to have any effect.

"window.autoDetectColorScheme": true,
"workbench.preferredDarkColorTheme": "GitHub Dark",
"workbench.preferredLightColorTheme": "GitHub Light"

By the way, I think the GitHub themes are the most underrated VS Code themes out there. Both the Light and the Dark are clean, sharp and Burke approved. Highly recommended.

Now this doesn’t really solve the issue I was trying to tackle in the previous blog post about switching themes based on time of day, but it can.

Switch to Dark Mode based on time of day

You can switch your entire operating system to Dark Mode based on the time of day. Dark Mode at night and Light Mode during the day. Or vice-versa if you think society is a platypus.

For macOS

If you’re on a Mac, this is built-in as of Catalina. There is an “Auto” setting when you choose between Light and Dark mode. This will switch you to dark mode with the sun goes down, and back to light when it comes back up. Unfortunately, Apple will decide that for you because let’s be honest - they know what’s best for you. Stop trying to live your life your way.

If you want to control the exact time when this happens, you can use the NightOwl app.

For Windows

This is not yet built-in to Windows, but you can either setup a scheduled task to do it, or consider installing the Windows Auto Night Mode program.

I opted for the scheduled task as I’m not big into installing unsigned .exe’s - even though that one looks legit.

Now VS Code will automatically switch color themes based on the time of day, and you don’t need any extensions to do it.

I’ve been using it for about a week now and…

I’m going back to the extension

I just don’t like Dark Mode. It’s one thing to have a dark VS Code theme. It’s quite another to have it applied to the entire OS. I have trouble reading web pages and discerning parts of the screen. I’ll stick with switching the theme in VS Code and leave Windows alone.

I know we’re all supposed to love Dark Mode these days, but I just can’t get into it. But let this blog post stand as the record that I did try.

How to switch themes in VS Code based on the time of day

Burke Holland — Tue, 16 Feb 2021 19:53:57 +0000

It’s a good idea to switch between dark and light mode depending on what time of day it is. During the day when your body is more awake, it might make more sense to use a light theme where reading comprehension is better. At night, your eyes become more tired and bright screen light can be harder on your tired eyes.

Visual Studio Code doesn’t do this out-of-the-box, but just like Steve Jobs once said, “There’s an extension for that”.

Theme Switcher Extension

The Theme Switcher Extension for VS Code will let you define times of the day at which to apply a different theme.

Open the settings.json file and add in the themeswitcher.mappings property which takes an array of time and theme combinations. The theme will take affect at the designated time (24 hour format). Here’s mine…

"themeswitcher.mappings": [
  {
    "time": "06:00",
    "theme": "GitHub Light"
  },
  {
    "time": "17:00",
    "theme": "GitHub Dark"
  }
]

You can have as many of these “change points” as you like. Change themes every hour if that makes you happy.

Last, make sure you set the “utcOffset” property in settings.json to account for your time zone. The extension doesn’t do that autmoatically. I’m Central Standard Time which is UTC - 6.

"themeswitcher.utcOffset": -6

You can find your UTC offset based on timezone here.

Now VS Code will switch themes automatically based on the time of day. It’s not light theme vs dark theme, it’s enjoying the best of both worlds.

Beginner's series to Dev Containers free video course

Burke Holland — Thu, 11 Feb 2021 14:59:07 +0000

"Knowledge isn't free. You have to pay attention."
— Richard Feynman

Ok, but all “play on words” aside, knowledge is free. That’s the key contribution of the internet, isn’t it? That all knowledge is now essentially free? And this is kind of a recent development. It used to cost quite a bit to learn the skills that will make you successful. I mean, there is still a 700 billion dollar industry built on selling you knowledge.

Even better, you can learn what you need instead of things that you might need. It’s been several decades and I have not once used “Slope Intercept Form”. NOT. ONCE. Well, that’s a lie, I had to use it to help my kid with his homework at which point I Googled it. Like an adult.

But this post is not a shot at Algebra (I love you math people - really I do), this is about MORE free knowledge. Specficially, an 8 part video series on how to use “Development Containers”.

If you prefer reading to videos (you do you) you can get this whole series as step-by-step tutorial on Microsoft Learn.

Development Containers

Development Containers (or Dev Containers) are just Docker containers. But we add a little VS Code magic in the form of the Remote - Containers extension that allows you to develop inside of the container right from the editor.

Now why would you do this? Because once you define a container definition for a project, you can check it in to source as a config file. Then any developer could immediately spin up the right dev environment with zero configuration. No Python install. No copy/paste cryptic terminal commands from Stack Overflow.

So how does this work? I’m glad you asked! Or didn’t ask! Either way, queue up episode 1…

Episode 1:

Start your learning with developing in a Docker container in Visual Studio Code. Learn what it means to configure a container-based development environment, why you might want to develop in a container in VS Code, and what lies ahead in the rest of this video series.

Episode 2:

How to install the Remote - Containers extension in Visual Studio Code and see how it works.

Episode 3:

How to add a dev container to your project in Visual Studio Code using the Remote - Containers extension.

Episode 4:

How to run your configured project in a dev container.

Episode 5:

How to forward a port from your container to your host machine so that you can access the app in the browser.

Episode 6:

How to customize your dev container configuration.

Episode 7:

How to install additional software in your Development container.

Episode 8:

Wrap-up and where to go to learn more about Remote Development.

Enjoy your free knowledge

We hope you enjoy this series on Development Containers. You can check out the full playlist on YouTube or Microsoft Developer Studios.

Using Azure Logic Apps to auto-print sales orders

Burke Holland — Mon, 08 Feb 2021 20:52:29 +0000

No / Low Code tools (NoLow - I just coined that) have been the holy grail of software since I got into programming. I remain optimistic, but skeptical in regards to the idea that some day anyone will be able to build apps.

Optimistic because we really need to get humans out of the business of writing code wherever we can. Less code means less bugs. Skeptical because in the 15 years I’ve been a developer, I’ve watched so many of these tools come and go. The problem isn’t that we haven’t made the right tools, it’s that you still need to have significant level of technical knowledge about how a problem can be solved. And that’s not something you can abstract away with a nicer UI.

I think the strongest case for the success of NoLow at the moment has more to do with what it offers current developers than it’s ability to turn non-coders into application developers.

A NoLow real world use case

My wife owns a small business. It’s one of those yard sign businesses that have exploded in popularity during the pandemic. I was skeptical of the long-term viability of a business built on corrogated blown up letters stuck in your yard, but when she put up a sign for my birthday, it did make me feel special and I can understand why she’s getting 5 and 6 orders a day at around 75 bucks a pop.

I am defacto tech support for all the digital aspects of her business. Since it’s a franchise, nearly everything she needs is provided by the company. And, if I might add, it’s pretty good. She complains, but she has never used enterprise software before so her only frame of reference is her iPhone, on which everything kind of “just works”.

From time to time, she has small automation needs. For instance, she gets orders emailed to her every day. She then has to print those orders out. So she made a simple request to have orders just automatically print out whenever they come in.

I was halfway to building a Node application that auth’d to Gmail, parsed the body with an HTML parser and an npm package to send things to the printer before I realized that this is probably all solvable with low code tools.

So I built an Azure Logic App that does this in - no joke - two steps.

Building the Logic App

First I had some prep work to do.

I added a label to any incoming order email with an “Order” label. Gmail calls these “filters” by the way. The order format ALWAYS starts the same way and they always come from the same sender. Anybody could write this filter.

Note: the easiest way to do this whole thing would be to forward the email once it comes in via the same filter in Gmail - cause you can do that. Unfortunately, this doesn’t work. For some reason, the printer won’t accept forwarded emails. I lost about an hour to that weirdness.

I started with a blank Logic App and added the Gmail Trigger to start. It has the ability to check for new mail, and you can even specify a label to filter on.

The next step is to add an action that sends any emails it found in step one to the printer. I’ve got an HP Envy 5640 that supports HP ePrint - “a cloud-based service that lets you print from anywhere…”. Once you set it up, you get a super ugly email address that looks like kslf11skjflk83@hpeprint.com. But anything you send to that ugliness from a “trusted” sender will print. It works well.

I put the printer email in a Logic App parameter so it’s not part of the program itself. That’s the coder in me. I can’t help it.

This runs every 3 minutes and prints new orders when they come in.

And it is deceptively simple.

Consider what actually has to occur for this to work…

Authentication to Gmail on my behalf, implementing an OAuth flow and storing tokens for future requests.
Querying for any “new” emails with a particular label
Parsing the parts of the email and preserving the HTML of the body
Sending an email on my behalf

10 years ago we would have coded this from scratch and it would have taken a week - at least. And I would consider this “advanced” coding given the auth flow requirements. And think of the bugs, testing and maintenance down the line.

Could anyone do this?

So back to the point - could anyone do this? It is pretty simple. Certainly a user with a moderate amount of technical knowledge could piece the Logic App together. But could they pull the whole thing off by themselves?

I’m not so sure. There are a lot of things that I just glossed over where you could get seriously hung up. Think of what you have to know to build this…

You have to know that you need to query a collection of items (emails) based on a condition (label)
You have to know that modern printers have this “email to printer” capability which requires you to know the printer’s IP address which means…
You have to know about IP addresses, that they are dynamic, that this will ultimately break your app which means…
That you need to change the printer IP to static which means…
You have to know how to log-in to your router and configure DHCP.

Coding is not just knowledge of a language. It is broad knowledge of platforms, and how systems communicate.

I’m optimistic, but skeptical. For now, I think that NoLow apps might work for certain types of applications - a la “forms over data” like Microsoft Access. But the real “arrived” value might, at least today, seems to be enabling current developers to be more productive. It remains to be seen if developers will adopt these tools in lieu of a lucrative career inventing wheels.

Git version control basics in VS Code

Burke Holland — Thu, 28 Jan 2021 16:35:13 +0000

When you're first starting out as a developer, one of the big curve balls that gets lobbed right at your face is the concept of "version control".

I've been a developer for 17 years and version control is a struggle for me to this day. Sometime around 12 years ago, we all simultaneously decided to standardized on Git - which is a prolific, but objectively difficult to use source control management (SCM) tool. It's kind of like standardizing on English as a language for the entire world. Does a building burn up, or burn down? YES.

One of the things that Visual Studio Code tries to do is abstract some of that confusion away for you. There are certain motions that we make every day around source control that VS Code can handle for you. A typical flow might look something like this...

Change a file(s)
Stage your changes
Commit with a message
Push

VS Code is quite good at managing this workflow for you so you never have to drop into a terminal. Even after you get comfortable with using the git command line interface, you'll likely find that the VS Code flow is still faster because there's no context switching.

Check out this video on version control basics in VS Code.

You can do a lot more with Git in Visual Studio Code, and even MORE with GitHub. Visit vscode.github.com for 20 quick video tips that cover everything from how to change your diff view to how to create a pull request right from the editor.

Oh - and not only can you use GitHub from within VS Code, but you can also use VS Code from within Github...

Unifying data with Hasura GraphQL Engine & Azure functions

Burke Holland — Mon, 28 Sep 2020 16:08:47 +0000

GraphQL is one of the newer and more fascinating paradigms for web APIs. The idea is that instead of trying to build APIs which return data for every scenario, you build a generic set of APIs which can return exactly what the frontend developer needs. Essentially, GraphQL gives the frontend developer the ability to query the database in the way that they need without having to implement new endpoints.

Now that sounds great and all, but if you're like a lot of developers, you already have a set of APIs, a mountain of technical debt that you inherited from previous developers, and a disparate system of relational databases. Sometimes it feels like you will never get to play with the new toys.

Trust me. I know that feeling so very, very well.

The folks at Hasura have been hard at work solving this problem for GraphQL. Hasura is a system that you stand up in front of your database. It then allows you to expose data in that database as a GraphQL API. No new services needed.

But as you know, getting just the data is only half the battle. If only life were just that easy. Often, you need an API that actually does something. Perhaps it performs some sort of calculation on the data set or even runs it through a machine learning model. Hasura lets you hook into the calls made to the API, handle them with custom code and then return custom data as part of the results set.

In this session at CREATE : Serverless, I'll be speaking with Allison Kuntz from Hasura on how Hasura works, why it makes GraphQL easy, and how you can extend any API call with a little Serverless.

See you there!

Add Create : Serverless to your calendar 👉 https://createserverless2020.splashthat.com/

LearnShops : A new kind of free workshop built for pandemic days

Burke Holland — Tue, 15 Sep 2020 15:50:37 +0000

When I first found at that I was going to be working from home for the foreseeable future, I thought, AMAZING. I'll have so much extra time to....I don't know what I'll do with it, but I'll have it and that will be awesome because I can do anything.

But it's not been awesome. It's been stressful.

All this time that I would normally spend traveling or with friends now has no purpose and that has caused me a significant amount of anxiety. There have been many evenings where I find myself wondering aimlessly around the neighborhood with no destination.

I feel an intense amount of pressure to be using this time constructively, but I don't want to spend it alone. It seems like there should be a way to combine both - socializing and learning in the traditional hands-on workshop format.

Introducing LearnShops

We're pleased to bring you a new series of monthly events called "LearnShops". You can think of them as a short, hands-on workshop combined with a lively chat.

We'll guide you through a different exercise each month. You follow along with us with the written exercises. We're using YouTube Live and there will be folks in the chat who can help unblock you if you get stuck. We'll also be answering your questions and chatting with you as we go.

When, Where, What's the topic?

Topic: Migrating a Node.js and Express API to Serverless
When: Tomorrow, at 8 AM PST
Where: Watch Broadcast (Add to your calendar: Outlook, iCal, Google Calendar)

Sorry if that's too early for you West Coasters, but we're trying to include as many folks as possible. A strong cup of coffee might be in order.

Learn with us

We'd love to see you there. I would love to see you there. I mean that. I miss the days where we could all meet in a room and learn together. We'll do that again. I promise. Until then, let's get learn together. I promise it's a whole lot more fun that doing it on your own. And maybe you won't find yourself aimlessly wondering the neighborhood.