DEV Community: Kimberly Myers

🏢 Top Copilot Questions from Corporate Office Professionals

Kimberly Myers — Wed, 16 Jul 2025 17:38:52 +0000

Professional clarity isn’t just helpful—it’s powerful. Whether you’re drafting a presentation or replying to an urgent email, Copilot helps corporate teams work smarter and sound sharper. Here are the top questions office pros ask Copilot every week:

✍️ 1. Can you rewrite this message to sound more professional?
From rewording blunt replies to adjusting tone for leadership, Copilot makes your communication polished and clear without losing your intent.

📬 2. How should I respond to this email or post?
Whether navigating a tense update or delivering quick feedback, Copilot drafts responses that strike the right tone for every audience.

🧠 3. Can you explain what XYZ means?
Perfect for meetings where a buzzword drops unexpectedly. Copilot gives you confident context—without sounding like you just Googled it.

🎤 4. Can you help me build a presentation on XYZ?
From slide structure to speaker notes, Copilot lays out clean, focused decks that make your story resonate.

📚 5. Can you simplify this documentation or report?
From technical SOPs to long-form project summaries, Copilot transforms dense text into readable, digestible workflows.

✨ Bonus Questions That Boost Efficiency

Summarize this document for a quick overview
Visualize this data for a polished report
Prep me with talking points for this meeting

Bottom line: Copilot helps you show up prepared—whether you're presenting to execs or posting in Teams.

🧑‍💻 Top Developer Questions for Microsoft Copilot—and Why They Matter

Kimberly Myers — Wed, 16 Jul 2025 17:34:24 +0000

Developers thrive on clarity, speed, and clean code. That’s why Microsoft Copilot isn’t just helpful—it’s a force multiplier. These are the go-to questions developers ask to keep momentum high and mistakes low.

🔧 1. Can you create unit tests for this class?
Test coverage is critical. Copilot helps generate modular tests with setup/teardown logic, mocking strategies, and clean assertions—making your testing framework smarter and more scalable.

Tip: Add more context for the language and tools you want it to use

🔍 2. Is there anything wrong with this code?
Copilot becomes your second pair of eyes. It flags syntax errors, logic flaws, and performance bottlenecks before they escalate—especially handy when you're neck-deep in a pull request.

🧠 3. What does this error mean?
No more deciphering stack traces solo. Copilot translates error messages into actionable explanations, often with suggestions on how to fix them—and where the issue originated.

🛠 4. Can you create this method to do XYZ?
Whether it's transforming data or making clean API calls, Copilot drafts structured, maintainable methods with comments that clarify the logic and intent.

⚙️ 5. Can you create this workflow to do XYZ?
From CI/CD automation to repository update pipelines, Copilot lays out scripts and workflows that make manual effort feel obsolete.

✨ Bonus Questions Worth Asking

Refactor this code to follow best practices
Mock this dependency cleanly for testing
Review this pull request for missed edge cases

Pro tip: Copilot is more than autocomplete. It's your debugging partner, your code stylist, and your testing strategist—all rolled into one.

Understanding URL Path and Parameter Errors in API Testing

Kimberly Myers — Wed, 18 Sep 2024 18:36:39 +0000

When testing an API endpoint, it’s important to understand how the URL path and parameters work together.

Base URL path: This is like an address that tells the server where to go to start.
Parameters: These are parts of the URL that provides additional information that the server needs to process the request and find a specific resource.
Endpoint: A specific URL within an API that performs a specific function, corresponding to an action or resource
Request Type: is the action you want to perform on a resource (e.g. GET, POST, PUT, DELETE)
Request Body: the part of the request that contains the data you want to send to the server

URL Path Examples for CRUD Methods:

https://my-domain.com is the Base URL path
/application is the path for the specific endpoint for application resources
Parameters are wrapped in brackets {}

1) GET - get all or specific resource

get all resources

GET https://my-domain.com/application

get a specific Resource

GET https://my-domain.com/application/{applicationId}

2) POST - create a resource

POST https://my-domain.com/application/

3) PUT - update a resource

POST https://my-domain.com/application/{applicationId}

4) DELETE- update a resource

DELETE https://my-domain.com/application/{applicationId}

Valid vs. Invalid Tests:

Valid Test: This is when you provide the correct URL path and the necessary parameters. The server understands the request and processes it.
A valid test may produce a valid response code such as 200 OK or 400 Bad Request, depending on the expected test results.
Invalid Test:
If you do not provide the necessary parameters, the URL path might be pointing to a different endpoint that can lead to errors or unexpected responses.

Error Codes:

400 Error (Bad Request): This happens when the URL path exists, but the request is missing required variables or has incorrect data. The server understands the path but can’t process the request correctly.
404 Error (Not Found): This occurs when the URL path doesn’t exist and/or the server can’t find the resource you’re trying to access.

You might encounter a 400 error when the URL path is correct, but the request lacks the necessary parameters or includes incorrect data in the request body. This indicates that while the server recognizes the path, it cannot process the request due to missing or incorrect information.

Similarly, a 404 error can occur if the URL path exists, but the parameters provided do not correspond to any specific resource. In this case, the server acknowledges the path but cannot locate the resource with the given parameters.

Therefore, to properly test an endpoint, ensure you provide the correct URL path along with all required parameters. Failing to do so will result in invalid tests and unexpected outcomes.

Effective Code Review

Kimberly Myers — Mon, 16 Sep 2024 21:54:17 +0000

Purpose of Code Review

Although the main objective of code review is to identify defects before promotion, it also aims to improve code readability & maintenance, and to facilitate knowledge transfer, helping developers enhance their skills and become better programmers.

Establish Processes, Standards and Tools:

Create documentation for code review standards.
Implement tools (e.g., StyleCop, CodeQL, Linter) to enforce style and rules for consistency and automate security checks.
Set up a process for generating code review requests, also known as Pull Requests in Git.

Pre-Review Preparation:

Review the requirements outlined in relevant documentation
Review the description of the code review request to understand the purpose of the change.
Examine commits, files changed, and comments to identify the code changes you are reviewing.

Code Review Process:

Focus on reviewing only new code or changes to existing code.
Check the functionality of the code to ensure it works as intended as well as test or debug the changes, if possible, to verify they meet the requirements.
Ensure the code structure is maintainable, readable, testable, portable, reusable, and adheres to coding standards. The code should be clean, well-organized, and follow best practices.
Verify that the code properly handles errors and identify potential exceptions or issues, such as null references or file locks.
Evaluate the code for potential performance issues and security vulnerabilities, such as high memory usage, hard-coded credentials, SQL injection risks, and HTTP redirects.
Check for thread safety to identify code that could potentially cause deadlocks or race conditions.

Feedback and Discussion:

Provide positive feedback, be specific and clear in your comments.
Offer suggestions for improvement and explain why the changes are needed.
Encourage discussion to foster better solutions and learning opportunities.

Post-Review Follow-Up:

Follow up to ensure the suggested changes are implemented and provide appropriate approval as necessary.

Keep in mind that there are multiple ways to approach a coding task, however there's always an opportunity to improve and learn.

Create Multiple GitHub Actions in a Single Repository

Kimberly Myers — Mon, 16 Sep 2024 18:46:44 +0000

You can create and package multiple GitHub Actions in a single repository that are written using TypeScript/JavaScript, allowing each action to run separately. Below is how to accomplish this using vercel/ncc, which allows compiling modules into a single file with its dependencies eliminating the need to include the node_modules folder in your repository:

Create and Configure Actions:

Create a separate folder for each action and configure the action.yml file within each folder

📁 test-action
-❕ action.yml
📁 test-action-2
-❕ action.yml

Add Source Code:

Place your source code for each action in the src folder

📁 src
-📄 test-action.ts
-📄 test-action-2.ts

Create Distribution Folder:

Create a folder named dist to store the packaged source code
📁 dist
Create separate folder for each action under dist folder
📁 dist
-📁 test-action
-📁 test-action-2

Update package.json:

Add a separate script to "scripts" in the package.json file for each action that calls npx ncc build command passing the TypeScript source code file and the output distribution folder for the action. Each script will be used to package your TypeScript source file as JavaScript in a generated file called index.js.

"scripts": {
  "testAction": "npx ncc build src/test-action.ts -o dist/test-action --source-map --license licenses.txt",
  "testAction2": "npx ncc build src/test-action-2.ts -o dist/test-action-2 --source-map --license licenses.txt"
}

Add a script to bundle all packages and copy the generated JavaScript source to the distribution folder

"scripts": {
  "bundle": "npm run format:write && npm run testAction && npm run testAction2 && copy src/*.js dist"
}

Run the bundle script:

npm run bundle

Update the action.yml to call package source in distribution folder for each action:

runs:
  using: node20
  main: '../dist/test-action/index.js'

runs:
  using: node20
  main: '../dist/test-action-2/index.js'

Create a GitHub workflow to test

on:
  workflow_dispatch:

jobs:
  action_test_job:
    runs-on: ubuntu-latest

    name: Test multiple actions
    steps:
      - name: Checkout
        uses: actions/checkout@v4

- name: Test Action
        id: testaction
        uses: ./test-action

- name: Test Action2
        id: testaction2
        uses: ./test-action2

References