Skip to content
View gchappel's full-sized avatar
  • Cisco, @CXEPI
  • United Kingdom
  • 01:51 (UTC +01:00)
Block or Report

Block or report gchappel

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
gchappel/README.md
  • 👋 Hi, I’m Gavin (@gchappel)
  • 👀 I’m interested in becoming a better engineer
  • 🌱 I’m currently learning how to stop procrastinating on learning...
  • 💞️ I’m looking to collaborate on anything that's causing you a problem. I like solving problems.
  • 📫 How to reach me
    • Webex

Some things I've learned (and try my best to practice) to help communicate more effectively...

  • Don't just say "hello" - I work for a global company, if you send me just a "hello!" outside my working hours, I'm not going to see it until the next day, which isn't a good use of anyone's time. Help me answer your questions more quickly by just asking them outright. I promise I won't think you're rude if we don't exchange a full three-way handshake of pleasantries first.
  • In a similar vein, don't ask to ask, just put the question out there, whether privately or publicly, but...
  • Preferably publicly. We have a lot of Webex spaces, with a lot of really knowledgable people. Questions almost always belong in a public space. If it isn't something that only I can answer then you'll probably get your answer much quicker. And if it is something that only I can answer, it'll still be there for me to answer the next day as soon as I see it.
  • In a nod to my troubleshooting heritage, the X/Y problem is a useful concept to be aware of. When you're having a problem, ask questions about the problem, not about what you perceive as the solution. This has some advantages:
    • maybe your solution is not going to solve the actual problem, or it will cause different problems. If you explain the problem then people can work together with you on finding the best available solution
    • articulating your problem (particularly in text) can also be a form of rubber ducking; maybe halfway through writing your message about the problem you solve the problem yourself, which is unlikely to happen when you're instead writing a message about a solution that you don't know how to implement

Popular repositories

  1. terraform-dependency terraform-dependency Public

    Minimal reproduction of a TF 0.12.x -> 0.13.x upgrade-related dependency issue

    HCL

  2. pre-commit pre-commit Public

    Forked from gruntwork-io/pre-commit

    A collection of pre-commit hooks used by Gruntwork tools

    Shell

  3. terragrunt terragrunt Public

    Forked from gruntwork-io/terragrunt

    Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple Terraform modules.

    Go

  4. terrascan terrascan Public

    Forked from tenable/terrascan

    Detect compliance and security violations across Infrastructure as Code to mitigate risk before provisioning cloud native infrastructure.

    Go

  5. gchappel gchappel Public

    Config files for my GitHub profile.

  6. terraform-destroy terraform-destroy Public

    A Terraform module with zero resources, for killing things

    HCL