Software Engineering in WordPress, PHP, and Backend Development

Tag: AI (Page 1 of 2)

Software Developers and Technical Articles in the Era of AI

Site analytics are funny things regardless of how you use them (that is, through marketing, engagement, content, and so on). I say this because analytics give us information about:

  • how long people are reading our content (per article, even),
  • how many people are reading what we write,
  • how much people are reading what we write,
  • how often people are returning to read what we write,

And all of this coalesces into informing the things about which we write and how we write about it. At least, this is my experience.

The day to day experience of understanding analytics through the use of two mice.

Despite having all of this analytical information available, AI is changing the type of content we publish.

For technical writers specifically, this should give us pause on if there’s not a slightly wider range of related topics about which we can write that continue to contribute to the field in which we work.

Technical Articles in the Era of AI

As far as analytics, SEO, AI, and all of the other related technologies to blogging are concerned, I still hold to the mantra I’ve had for over a decade:

Write what you want on a given topic and don’t over think it.

This has proven the most useful and has transcended whatever changes have happened within the industry.

I primarily write because I enjoy the process, but it’s afforded opportunities that wouldn’t otherwise be available (the least of which isn’t developing solid friendships with people I’ve met in conferences or online).

Even still, I – like anyone else who’s maintained a site for a reasonable amount of time – still pay attention to some level of information analytics provide.

On Analytics

I rarely do a legitimate deep dive on the analytics of my site. Generally, I like to see:

  • the number of visitors over time,
  • how much time they are spending on the site or on each article,
  • and the bounce rate.

I’ve developed this habit in part because I’ve been writing technical content for so long it’s of some interest to see if people are [still] paying attention to it. But, as the advent of AI (see this post) has hit the mainstream of this industry, there’s been a change in how we all look up technical content.

And where analytics may have been useful for a very long time, there’s now another dimension to the field.


Given blogs and technical articles have helped train the LLMs we’ve so quickly adopted, it raises questions.

Is it useful to continue writing technical articles?

  • If the content we wrote helped train the LLMs then are new articles also continue to add to the data set the LLMs are using?
  • If more and more developers – myself included – are going to an LLM to help solve problems first (versus a search engine), how much less valuable are other sites and blogs becoming?

I still think there is value in treating a blog like a public notebook of sorts even if it’s just for personal reasons.

If not, then what else is there for technical writers to publish?

  • I don’t think there’s any shortage of content engineers have to write because so much of our job is more than just development, architecture, and so on.
  • The amount of things tangentially related or even adjacent to our work provide plenty of content that’s useful for other people to read (take articles like this and or this, for example).
  • As the technical aspect of our jobs may be enhanced – or substitute whatever word you’d like – by AI, there is still a human factor.

Clearly stated: As long as a human experience exists as something unique, it has potential to be an article that cannot be wholly generated through the statistical probability of words assembled through generative AI. (Though I’d be foolish to say that it can be a challenge to discern the difference between what a person has written and what has been generated.)

Writing technical articles does not have to be published into the void.

Though it may be easier to refer to ChatGPT for a technical question rather than a blog, that doesn’t mean a developer has nothing about which to write in relation to the field. For example, just as I could write about my day-to-day in working from home as a father of three an trying to maintain a schedule for reading, writing, exercising, music, work, and continued growth in what I do for a living, so can any one else. (Or so should everyone else?)

Software Developers Should Expand Topics

Ultimately, the way our work is altered through the advent of AI is undeniable. And though it may mean there are some changes in how we get our work done, it also informs how we can continue to contribute content related to what we do in our day-to-day. (This is something I used to do way back when, too.)

In other words, looking up how to properly sanitize data before it enters a database is going to be something the current – and the next – generation will ask an LLM. But looking up how to be productive as a remote engineer living in rural Georgia in a family of five, three of which are kids, is something AI cannot answer.

And perhaps that’s an area in which we could easily – and should – expand our content

Writing About WordPress in the Age of AI

Periodically, I review the content I’ve written over the last decade or so and am surprised to at some of the things I wrote about in the past (like My Day-to-Day). I also find it interesting that I stopped doing so. Then again, I likely exhausted that particular topic. At least for that time.

Specifically, I’m surprised that I used to write about such things despite the topics not really being relevant to what I consider my core content.

Personally, a lot has happened in the last, say, roughly five years alone – between changing jobs, growing the family moving, pursuing additional hobbies, and more – one of the things that’s taken a back seat is writing. Then again, though, isn’t that how it goes?

We have a finite number hours on how to spend our time and as that time gets allocated to other things, something gets squeezed out. And that’s what has happened with writing.

This gentleman fears the amount of time that’s passed. The perpetual ticking that surrounds him isn’t helping.

For a while, I felt guilty about it. Partially because writing daily was something that I enjoyed doing and that I did habitually. Partially because it had become such an habit that when I didn’t do it, I felt as if I was dropping the ball on something.

And though there’s truth in some of that (such as I miss writing every day), that doesn’t mean I’d trade out some of the things I’m doing that occupy that time now. Some of it’s related to my day-to-day work, some of it’s related to my family, and some of it’s related to other hobbies.

Over the holidays (and as I’m trying this, I realize I didn’t write a short Christmas post for this year which is likely the first time since I can remember not doing that), I had time to think about a lot different things some of which included both how I want to spend my time and how I currently spend my time.

Though I’m not one for setting resolutions, I’m for settings goals. And I was planning different goals for myself over the coming year, I couldn’t help but reflect a bit on this site.

Apparently, this is how Meta imagines me doing exactly what I just described. I’m drinking something out of a pepper container.

Sure, the goals would be fun to share (and maybe I will in a future post – I always enjoy what other people are planning!), I found myself thinking a little bit about software development, WordPress, the WordPress economy, where things have been, and where things are headed.

But writing about WordPress in the age of AI especially as developer is proving its own set of challenges. Of all types of people, though, shouldn’t we be here to meet it?

And with the rise of popularity in AI, the more-or-less standardization of the Block Editor, and the upcoming changes to the administration area UI, there’s a lot that can be discussed and there will likely be a lot about which to write (either via commentary or tutorials on how to achieve something).

When thinking through that, though, I found myself remembering all of things about which I used to write that weren’t always dedicated to programming but were still dedicated to what I, as a remote developer working in software developer in WordPress, was doing.

Why did I stop doing that? And what’s to stop me from doing that again?

I used to write differently about things. How did I get here?

Just as I do think tools such as ChatGPT has wrecked some of the content I (and others) have historically written, it’s by no means a call to inaction – or a call to stop writing. It’s just a call to adjust and keep moving forward.

Though I don’t know if I’ll ever write daily again, I do think there’s plenty I can share that extends beyond:

  1. Here’s what you may want to do in WordPress using PHP or JavaScript
  2. Here’s how you can do it.

So at the end of 2024, we’ll see how I’ve done. Here’s to a greater variety of content all the while still keeping the focus on the type of content about which I’ve historically written.

The Most Useful (Or Popular) Articles from 2023

Last year, I wrote the first type of article that I’ve written in a very long time (if ever) given the amount of time that I’ve been writing. The Most Useful (or Popular) Articles from 2022.

There was generally derived from analytics data but also I used light engagement metrics via X/Twitter, LinkedIn, and even email to determine what were considered the most useful (or popular) posts.

This dude is completely scared of the fact that the calendar is nearing the end of another year.

And given that we’re nearing the end of 2023, I thought I’d do the same this year. So, in keeping with the previous trend, here are the most useful (or popular) articles from 2023.

2023: Most Useful Articles

For the last few years, I’ve claimed that I want to write more than the year before and get back to how much I was writing in a few years prior. Truth is, I don’t know if this is possible given how much has changed since this. Work is different, life is different, and the way my day-to-day is structured is different.

It’s all great, but it’s different.

Regardless, I still urge everyone with a blog to continue doing the same and then syndicating out to the web. It helps surfacing your content in search engines, on social media – be it X/Twitter, LinkedIn, Facebook, whatever, – and on RSS (which is still my personal favorite).

Father Time wrapping up another blog post for the end of another year.

Anyway, these are the posts for this year. On to 2024.

ChatGPT Wrecked Our Type of Content

A few days ago, Carl and I were talking about the impact that ChatGPT and related technologies have had on those of who spend – or spent – a lot of time writing long form articles showing how to achieve things within the context of software development.

Both he and I, among others – perhaps including some of you who are reading this post or regularly read this blog – have been around long enough to remember what it was like growing up online, learning how the machine works, how to write code, and perhaps even studying it in both high school and college, and maybe beyond that.

The 90s

For me, it was a combination of AOL, the the programming forums, VB3, and then onward and upward to other languages, operating systems, and platforms from there. True story: The first copy of Linux I ever received was Slackware that someone I met in IRC sent to me via USPS. The site doesn’t look enough different today.

So many afternoons, nights, and evenings were spent hopping between playing games like King’s Quest (Six is the best and I’ll fight you for it) and then signing online to see what certain people were building (such as a TCP/IP checkers game built fully in Visual Basic) to random proggies people were using to manipulate AOL, and from trying to wrap my head around C++, to trying to make sense of Dan Appleman’s Programmer’s Guide to the Win32 API.

The 00s

Fast far forward to the early two thousands and sites like Stack Overflow come online (from the minds of long-time bloggers Joel Spolsky and Jeff Atwood, no less) and begin having perhaps the largest scale and gamified way to get your programming-related questions answered quickly.

In fact, I remember listening to the podcast on my iPod Shuffle while running through the suburbs of the north Atlanta metro area. They’d talk about how they were discussing certain aspects of the site from an object-oriented programming standpoint, the technology stack they were using – which was .NET – and they were using Subversion as their version control system.

And I’m old enough to be one of the double-digit user accounts. And I remember them growing into what was originally called The Stack Overflow Trilogy. It was a really cool time to be a young software developer working in web application development.


All of this is to say:

I don’t recall a single new set of sites and/or technologies being introduced that so quickly impacted what those of us who do what we do for a living.

On Blogging

Sure, certain technologies or libraries or languages or tools have come and gone, but when I think about major inflection points of utilities that have impacted software developers, Stack Overflow and ChatGPT (along with its related technologies such as Copilot) are the first thing to come to mind.

I’m shooting from the hip as I’m drafting this late at night and should be giving this more thought, but I digress.

Anyway, during the conversation with Carl, he made the following claim:

I think ChatGPT wrecked our type of content

I’ve been rolling it over in my mind for the past few days not so much because I disagree – I actually firmly agree – but I’ve been thinking about the following two points:

  1. It’s paradoxical. Bloggers wrote the content that helped train a massive LLM that ultimately negate the need for that kind of content. Granted, we could continue to feed the machine, so to speak, but LLMs can learn from themselves given the right interaction.
  2. The goal was never to provide a quick way to copy and paste a solution, but how to learn how to solve a problem when you weren’t sure how to approach it. (And this is something that I think serves anyone in the field of applied computer science well.)

When you’re someone who enjoys writing about technical concepts for yourself and others, the ultimate goal isn’t to show someone how to quickly do something. More so, it’s to show how to approach problem solving in the abstract and to understand the tradeoffs of various solutions.

On Social Media

Then I got to thinking about all of the people in WordPress I’ve met over the years, then I got to thinking about all of the people in adjacent groups I’ve met over the years. Those work work in:

  • backend languages,
  • front-end languages,
  • content creators,
  • podcasters,
  • and so on.

So I decided to hop back on to X/Twitter for a bit to see how those people have been using the platform since ownership changed hands earlier this year.

And what I found during my, what you may call, straw poll was that there’s a lot of people who haven’t abandoned the platform at all. Instead, they subscribe for access to the premium features of the platform, who are writing long form content, who are sharing longer form content than I think we’d more likely see on some blogs just five years ago.

So then I brought all of this back to what I’ve traditionally written about and in the field in which I work, and I’ve noticed that there are a lot of people spending a lot of time writing about development work as it relates to WordPress on X/Twitter rather than on their blog.

And here’s why that strikes me as strange:

Old school tweeting was one thing because it included short statements that felt more like parts of a conversation. A very loud, boisterous, crowded conversation, but a conversation of sorts nonetheless.

Now, though, people are writing essays on their premium accounts about content related to a platform that targets the democratization of publishing. An essay does not a conversation make.

Further, publishing content on a platform about the software on which you work that aims to give people the goal to publish content so they can maintain it seems incongruent.

I don’t think anyone should have to make this claim but I’m not someone who cares one way or the other who owns X/Twitter or what’s going on with it from a socio-political-or-economic perspective. The observations I’m making wouldn’t matter who owns it.

Bringing It All Together

So how do I bring the various and seemingly disparate thoughts on all of this together to try to make a cohesive article? I’ll do what I can.

  • Writing about software development and trying to provide quick solutions to common problems are not the same thing.
  • Writing long form articles about the concepts in software development and looking for an answer from ChatGPT or related services are not related.

So the first question seems to come to something like:

  • When people are given the choice to choose between the two, will they search the archives aggregated via RSS first or go to ChatGPT first?

Though the goals of this question are not mutually exclusive, I think getting an answer fast often outweighs the “I’m looking for an answer but it was neat to also read about someone else’s situation while searching for it.” And this is why ChatGPT has “wrecked” some of the content a bunch of us typically write.

It’s not because we don’t want to write it (and no one is stopping us), but it’s hard to know just how many people come for the content and stay for the answer versus come for the answer and stay for the content.

The answer, then, seems to lie somewhere in between either continuing to write as usual, which is a completely viable option, or do what content creator types do and bring the content to the table in a way that’s compelling enough to keep people coming back (or turning in, or watching, or smashing that subscribe button and remembering to hit the bell).

The second observation, though, is a bit less clear to me. Before X/Twitter changed hands, people were already involved in a number of different areas online such as Slack channels for Post Status or The WP Minute, Facebook groups, but they also tended to maintain their own site while sharing their shorter content on X/Twitter (for reasons that I’ve already covered).

Now, the whole thing is all over the place:

  • Some are spending a lot of time writing long form content on X/Twitter,
  • Some are participating in various Slack channels,
  • Some are participating in various Facebook Groups,
  • Some are blogging,
  • Some have pulled back from the social web,
  • Some are doing none, multiple, or all, of the above.

Having choice is fine and picking where to hang out is great – it’s the whole go where you feel most welcome kind of thing – but the degree and/or ways in which many of us have changed in 2023 alone is really something to observe.

Where We’re Headed Isn’t Clear

And, as I said at the outset, the solution to this isn’t clear. If I had to summarize my take it would be something like this:

Long form posts for those on X/Twitter has increased this year and the amount of content people are sharing on their own blogs and syndicating it to X/Twitter has decreased.

I have to leave it at that for now because I don’t know what to make it of it. Maybe it’s just the way it is.

Anyway, Carl also made the comment in our conversation:

I think there’s still space for teaching and writing about concepts

And I agree with this, too. The thing is, I don’t think the way we’ve historically done is it the way to do it moving forward. I won’t be the guy who’s writing his thoughts on X/Twitter (not as a protest or anything) because I don’t see the medium has particularly useful for that in the long term.

I still think blogging and ultimately publishing content on your own property and syndicating it out to social networks is ultimately better than inverting how it’s done (though that’s what’s happening right now).

People can read the content and then take the social aspect of to social media. Or they can drop an email in our inbox. Or they can consume it and move on.

Regardless, how the content is produced is presented is likely the next challenge for those of us who have historically done long form technical writing. And I don’t know what that looks like right now.

Exciting times ahead.

Easily Set Up and Use Visual Studio Code and Other Tools for Python Development

If you’re to go through the archives of the content here, you’re going to find majority of articles dealing with PHP, JavaScript, HTML, CSS, and variations thereof and all of which will likely be around building solutions on top of WordPress.

But a couple of decades(!) ago, I was working with Python – and other languages – when I was in college. And given some side projects that I’m working on right now, I’m using it again.

This time, though, I’ve got an environment set up that I really don’t want to leave and I want to be able to easily go back and forth between working with PHP and related tooling to Python and similar tooling with as little context switching as possible.

This includes:

  • easily installation of the runtime,
  • working within my IDE of choice (which is Visual Studio Code),
  • easily debugging code,
  • having proper sniffers and fixers for coding standards,
  • easily generating docblocks for the code,
  • and more.

Though it’s obviously outside the content I normally write but given that I’m doing this more and more, I thought I’d share everything I’ve done to set up a Python development environment as a PHP developer.


If you’re curious about everything covered in this article, here’s a list:

  • Installing Python via Homebrew
  • Setting Up Visual Studio Code
    • Installing the Python Extension
    • Configuration the Python Environment
    • Python Coding Standards
    • Debugging Python Code
  • GitHub Copilot
    • Installing the Extension
    • Generating DocBlocks
    • Explaining Code
  • Conclusion
  • Resources

Visual Studio Code and Other Tools for Python Development

Installing Python via Homebrew

The majority of the software I install is through Homebrew and I’ve covered it more extensively in the article I wrote when I first set up the machine I use each day.

You can check to see if Python is already installed on your system by running $ which python on your machine. At this point, though, you’ll likely see something like python not found. This is because the Python binary is, at the time of this writing, is python3.

So run $ which python3 and if you’re given a path, then you’ve got it installed. If not, run the following:

$ brew install python

After this, you should be able to run:

$ python3 --version

And you’ll see the current version you’re running. For this article, I’m running 3.9.6.

Don’t Forget pip

pip is a Python package manager much like Composer is a PHP package manager so I’ve not found a reason not to install it.

It should be installed by default if you’ve installed Python via Homebrew. Make sure you’re running the latest version. To do this, enter:

$ pip3 install --upgrade pip

Once the process is done, the initial work for installing and setting up Python is done.

Setting Up Visual Studio Code

My goal is to make sure I can swap between PHP development and Python development as quickly as possible by just opening a new instance of the IDE.

Installing the Python Extension

To install the Python extension for Visual Studio Code:

  1. Navigate to the Extensions you have installed (you can use cmd+shift+x on macOS to do this.
  2. If Python is not already installed, search for python and make sure it’s the extension that’s authored by Microsoft. Install it and, if requested, restart Visual Studio Code.

Before getting started with Python in Visual Studio Code, there are still a few things to do.

Configuring the Python Environment

If you’re like me, then whenever you restart Visual Studio Code, it’s going to have Python installed but still look and function much like it would any other time you open it. That is, it’s going to act like it’s a standard PHP editor.

Things change whenever you want to start a new Python-based project (be a single file or something more complex).

  1. Select the Python Interpreter you want to use in your projects. To do this, open the command palette by first pressed cmd+p then typing “Python: Select Interpreter“. Essentially this is asking which version or which binary, of all those that may exist on your system, do you want to use when running your code. Depending on your set up, you’ll see a number of different options (one will also be Global and one will also be Recommended). I favor the Recommended option because it should be the one provided by Homebrew (though it’s possible to have both Global and Recommended be the same, too).
  2. You can now create a new Python file or open an existing one. The Python extension provides various features, including code highlighting, code completion, linting, debugging, and more.
  3. If you opt to create a new file, you’ll need to choose an environment type in the current workspace. There are two types, Venv and Conda. What you opt to use depends on your needs. For the purposes of this article, I’m using Venv.

At this point, Visual Studio Code is ready for Python-based projects along with everything that comes with the environment. This includes IntelliSense, debugging, and running scripts.

But if you’re coming from another development background, you know there’s more to do such as debugging code, coding standards, sniffing and fixing code, docblocks, and and using modern tools like GitHub Copilot to help with any, all, and more than the above.

Python Coding Standards

As is the same with other programming languages, Python has it’s own set of coding standards. When it comes to using Python, all of this is already built into the extension out-of-the-box so there’s very little that we have to do.

PHP Coding Standards, DocStrings, etc.

First though, it’s worth knowing where to look should you need to reference something just in case. At least this is what I find to be the case whenever I’m curious about some standard or decision the plugin makes when it formats my code. Here’s a concise list of resources I have available:

Using the Python Extension to Format Code

Assuming you’ve got a file set up in Visual Studio Code, call it or whatever you’d like, and you’ve selected Venv (or Conda, should you so choose) as your environment of choice, then you’re ready to start writing code, formatting it, and adding inline code to it.

First, in your settings.json file, make sure that you’ve added the following directives:

"editor.formatOnSave": true,
"": {
    "editor.defaultFormatter": "ms-python.autopep8",

This will ensure that even if you miss any formatting in the document, it will format it whenever you save it.

Secondly, start by writing a basic function that’s essentially the classic Hello World except it will accept a string and say Hello to whatever you pass to it.

def hello(str):
    return "Hello " + str + "!"

Obviously this function won’t do anything until it’s invoked. So it’s possible to either just invoke the function by using print or we can get a bit more involved with Python and look at how to accept command line arguments while building out this functionality.

Let’s do the latter. To do this, we’ll need to import the sys package and then look at the arguments that are passed to the script. A very rudimentary way of doing this is to look at the arguments and blindly accept the first argument as the the name.

import sys

def hello(str):
    return "Hello " + str + "!"

args = sys.argv
if len(args) > 1:

Now when you run the script, you can run $ python3 Tom and the output should simply be “Hello Tom!”

But, as mentioned, there are a lot of problems with this implementation the least of which is not blindly accepting output. I’ll come back to this point later in the article.

Before finishing, let’s add one more function that’s formatted like this:

def goodbye(str):
return "Goodbye " + str + "!"

Functionally, this looks fine but it’s ill-formatted per the Python coding standards and if you’re editor is properly set up, then you should see something like the following image:

When you hover over the underlined code, you’ll see a message that reads Expected indented block. So indent the block per the coding standards and you should be good to go.

Finally, update the main file to say goodbye so that it looks like this:

import sys

def hello(str):
    return "Hello " + str + "!"

def goodbye(str):
    return "Goodbye " + str + "!"

args = sys.argv
if len(args) > 1:

Debugging Python Code

When working with PHP, it’s a bit of work to get Xdebug set up and working and configured in Visual Studio Code. It’s not has bad as it once was, but it’s also more of an involved process than it is in Python.

Out-of-the-box, the Python extension for Visual Studio Code handles the majority of this for us. Instead of having to configure any third-party module, enable it in a configuration file, then set up a configuration in the IDE, we simply set breakpoints, add watches, and all of the usual actual debugging tasks in Visual Studio code. Then we just tell the editor to Run and Debug.

But given the code above, we can’t simply press a button and run because it’s expecting input from the terminal. There are two ways to handle this.

  1. We can set up an else so that it defaults to an empty string,
  2. We can edit the code inline during debugging.

Each of these are useful in their own context.

Set Up a Conditional

The easiest route is to first set up an else case. The block of code may not look like this

args = sys.argv
if len(args) > 1:

Now if you run the script from the command line, you should see it output Hello World! It should also output Goodbye World!

Now if you set a breakpoint on either of the function calls, let’s say print(hello("World")) and start the debugger, you’ll see the familiar interface that you see when debugging PHP.

From here, you can do the usual debugging behavior. If you’ve set the same breakpoint as I’ve set above, then click on Run and Debug and you should see see the debugger hit breakpoints, add variables to the Watch list, and all of the usual inspections that you can do to variables, function calls, and so on.

But if you’re debugging arguments that come in via the command-line, what then?

Edit Values Inline

I don’t know how often you’ve done this in the past but I’ve find when working with web applications, this can be extremely useful especially with data coming in from another source (like a POST request).

To do this in Visual Studio Code, simply set a breakpoint as you normally would. Assuming you’ve got a variable name set in the Watch list and the breakpoint is on the line where the variable is invoked, then you can modify it by two-finger Set Value.

This will allow you to change the value in real time and then see the output of the result once done. And if you want to do this with command-line arguments, then set a breakpoint and a watch when args is set and change the value to ['...', 'Tom'] and you’ll find that you’ve now simulated updating command line arguments.

GitHub Copilot

As a developer, one of the coolest or nicest or more useful tools to come out in the last year is GitHub Copilot and GitHub Copilot Chat I’ve talked a little bit about my thoughts on using AI when writing software and I stand by it.

This particular extension has made it easier to more quickly understand code when I’m lacking context, generate docblocks faster and more concisely than I normally can, and even recommend suggestions for making sure I’m following best practices regardless of what I’m doing.

But in the context of using Python especially as someone who’s more rusty on it than other languages, I’ve found it extremely helpful when bringing me up to speed when I want to achieve something (such as how to retrieve command line arguments).

To do this, though, we need to install and configure the extension.

Installing The Extension

First, I recommend installing both of the following:

  1. GitHub Copilot. This utility is primarily focused on helping developers write code more efficiently by providing intelligent code suggestions and autocompletions based on the context of their code. It is designed to enhance the developer’s coding experience.
  2. GitHub Copilot Chat. GitHub Copilot Chat beta provides a natural language chat interface to engage with GitHub Copilot, an AI developer tool or “AI pair programmer,” and get coding information and support for tasks from explaining code to finding issues and fixing them.

Note this is free for open source projects. If you’re working on anything that’s licensed as such, then there’s no need to pay; however, if you’re working on anything that’s closed source, it costs money.

Further, note that whatever license you use, make sure you pay attention to the settings GitHub asks as it will ask if it can use your source code to training their language model. For some, it’s not a big deal; for others, this isn’t something you want to do; however, if you’re working in open source, it’s probably expected to share it.

If you’re ensure and you’re not self-employed or you’re using it for an official project for your employer or for someone else, then be sure to ask them.

Generating DocBlocks

Assuming you’ve got GitHub Copilot and Copilot Chat installed, here’s how you can use it to quickly generate aspects of your code that are generally mundane (such as DocBlocks).

Looking at the following function:

def hello(str):
    return "Hello " + str + "!"

Let’s ask Copilot to generate a docblock for it. There are two ways to do this:

  1. You can ask Copilot to generate it inline using a menu item and then ‘accept’ the results to have them automatically inserted.
  2. You can ask Copilot Chat to generate it and then copy and paste the results into the editor.

We’ll look at an example of the latter in the next section so let’s use the first option to generate a docblock.

First, two-finger click or right-click on the function signature and select Copilot > Generate Docs.

Once it’s done processing the code, you’ll likely see something like this:

For the purposes of this acrticle, I’ll accept it. Once done, your function should look something like this:

def hello(str):
    Returns a greeting message with the provided string.

        str (str): The name or string to be greeted.

        str: A greeting message with the provided string.
    return "Hello " + str + "!"

You can do this for the rest of the functions in this file or whatever file on which you’re working. In addition to making this much quicker, it also follows the coding conventions of Python so you don’t have to tweak it after the fact.

Explaining Code

Now let’s use Copilot Chat to explain a section of code in the chat window provided by the extension. Since we know how to generate documentation, let’s use the feature to explain the conditional we have.

Specifically, let’s look at this:

args = sys.argv
if len(args) > 1:

Select the block of code in Code, then click on the Copilot Chat icon in the Activity Bar. Next, you can either prompt it with something like “Explain this code” or you can use one of the built in commands it offers such as /explain.

If you use the latter, it should return a lengthy response. Something like this, perhaps:

This Python code reads command-line arguments using the sys.argv list. If there is more than one argument, it calls the hello and goodbye functions with the first argument and prints the results. If there is only one argument, it calls the same functions with the string “World” and prints the results.

The hello function takes a string argument and returns a greeting message that includes the argument. The goodbye function takes a string argument and returns a farewell message that includes the argument.

This code demonstrates how to use command-line arguments in Python and how to call functions with arguments. It also shows how to use conditional statements to handle different cases based on the number of arguments passed in.

To improve the readability of this code, we could add comments to explain what each part of the code does. We could also use more descriptive function and variable names to make the code easier to understand. Additionally, we could use f-strings to format the greeting and farewell messages instead of concatenating strings.

If you want to make the code more succinct, leave the block of code highlighted then prompt Chat with “Make this code more succinct.” It should return something like this:

arg = sys.argv[1] if len(sys.argv) > 1 else "World"

And for good measure, let’s ask it to generate a single-line comment to explain what this block of code is doing. We can use a more specific prompt such as “Explain this in a single line comment.”

The first result may be something like this:

This Python code reads a command-line argument and calls the hello and goodbye functions with the argument, or “World” if no argument is provided, and prints the results.

But given that I’m coming from a PHP background, I’m used to inline comments being no more than 120 characters so I’ll prompt Chat with the following: “Shorten the last answer to no more than 120 characters.”

Then it returned this:

Python code reads command-line arg, calls hello and goodbye with arg or “World” and prints results.

And since we’re in Python, we can remove the “Python code” phrase and just go with:

Reads command-line arg, calls hello and goodbye with arg or “World” and prints results.

The final version of your IDE may look something like this.

And that’s it for the initial primer on how to use Visual Studio Code and Other Tools for Python Development.


I obviously contend that AI is more of an assistant to writing software than anything else, but I found this to be a unique case to document. This covers how to use things such as GitHub Copilot and Copilot chat, but also how to set up a new language in Visual Studio Code and leverage modern tools to get easily onboarded or get brought up to speed on how to do certain things in the language.

It’s easy to feel utility to technology fatigue with so much happening in our space. Each month, it seems as if there’s some new pre-processor, linter, JavaScript utility, security analyzer, or something else that promises to make us more product or write better code or get things done in such a way it’s more maintainable.

Perhaps some or all of that is true.

But in all of the years of writing web applications, I’ve yet to really find anything that’s increased productivity and learning so much as I have with using GPT-based tools. And though it’s useful in my day-to-day work in writing PHP and related code, it’s also been extremely useful in getting up to speed with writing, debugging, documenting, and being brought up to speed on Python, too.


« Older posts

© 2024 Tom McFarlin

Theme by Anders NorenUp ↑