Cover photo - contextualelectronics.com

tl;dr What DOES work

The 3 F's

When I think of tooling, I think of my dad's electronics shop, a big sprawling room, filled with random parts, power supplies and oscilloscopes. I used to spend my Saturdays with him as a kid. He would "put me to work" and I would help with small tasks, unsolder some old burnt-out capacitors, or log data on faulty power supplies. Nothing critical, but it was neat getting to learn and play at the same time. Anytime there was a big project around the house, my dad would rope me in. Fix a car, build a shed, my dad always had the right tool for the right job, form, fit and function.

... he would say. This was in stark contrast to an uncle I had, who would always go out and buy the absolute "best" and most expensive version of what my dad owned. Why buy a 14-inch chainsaw, when you can buy a 20-inch? I later learned that less is more, but god knows sometimes overkill is just fun. But here's the thing, should work be "fun"? Does having that shiny new toy, make the process more enjoyable, or are you just showing off to the next person? It's ok to want nice things, but how much, is too much?

Everything but

The friends and family with "the knack" tend to like their cars and trucks set up the way they like them, and desks the way they like them. Keyboards of all shapes and sizes, to suit each person. Perpetual tinkers, the lot of us.

As developers, we sit on the shoulders of GIANTS. As a result of this, it's easy to get bogged down in the latest JS framework, or Python library. When all you have to do is pip install antigravity or npm, it's easy to throw in everything and the kitchen sink at projects. Exploration is healthy, pushing boundaries, and learning new things. I (at times) have been very fond of chasing after the latest and greatest libraries when working on hobby projects. But there comes a point where how much, is too much. Do you NEED that extension, is that plugin going to HELP you? It's easier to not think TOO hard about it and sink into the mindset of "Just another library, it's less code I have to write..." or "This plugin seems helpful* for X".

Projects like CookieCutter are great for setting up template-based repositories, for consultants in particular. A nice repeatable structure, that follows a known pattern, can save time and energy. There is a catch, as with all good things. A lot of smaller projects I've seen on GitHub dump heaps of neat toys, on otherwise simple codebases. Do I need (...checks notes...) twen... TWENTY-FOUR (I'm looking at you hypermodern-python) .. test modules for writing a library to turn a light switch on and off? The answer is no, not for anything this simple. For larger, more complex projects, maybe. For example, I use quite a few dev helpers on my personal projects, not because they are essential, but because they automate annoying tasks and let me think about my app, and not about structure (Black & Flake8) or security (Bandit, Tartufo & Whispers). (Shh, it's 14 🙃)

I've lost count of how many plugins I have installed in VSCode, I'll admit. Each one was curated over many years of finding things that suit my taste. The same goes with my custom-tailored PyCharm, a bit less so, due to the sheer genius of JetBrains's developers thinking of so many things that Microsoft left up to the community. Open source vs closed source, give the people what they WANT, vs. give the people what you think they NEED.

There is no kill, like overkill, but sometimes, we lose sight of the problem we are trying to solve...

Too many options

People tend to be creatures of habit, finding comfort in the routine. This goes double (if not triple) for engineers of all trades. This idea is in stark contrast to the kitchen sink philosophy. I know what I know, and it gets the job done. Phrases like "I just want it done now" erode creativity. Tight deadlines, and angry clients for sure, make haste. Phrases like "it needed to get done yesterday", can lower quality. There's a phrase that comes to your mind.

"Jim Jarmusch once told me Fast, Cheap, and Goodpick two. If its fast and cheap it wont be good. If its cheap and good it wont be fast. If its fast and good it wont be cheap. Fast, cheap, and goodpick (2) words to live by."

-Tom Waits Spills the Beans to Tom Waits, Sound Effects Blog, Boston Globe, May 22, 2008.

When we don't give ourselves room to dabble, we can turn around three times and still be using COBOL... because it works (sorry if I'm being reductive). There is value sometimes to building a better mouse trap, but I've also seen folks fall prey to the "not invented here" syndrome. This battle of buy vs. build impacts us all. OpEx vs. CapEx, now vs. later, what's the "best" answer?

We like what we like, and we like to do things the way we've always done them before because it works.

"So what do you do?"

I've been asked at many a family gathering, "What do you do?". I usually quip back, "I'm a software developer" or "I work with the cloud", two easy-to-digest answers. The honest answer, convert coffee into code... which gets converted into money by folks savvy in the ways of business. We're in the business of solving problems, usually business problems, sometimes people problems, but always human problems.

(Side note: I did go to school for business... but I also was going to be a social worker as well. What you're good at, and what you went to school for, are sometimes, very different things -😉)

Common ground & finding balance

"The most dangerous phrase in the language is we've always done it this way'."

Admiral Grace Hopper

While I'm primarily a Python (and PowerShell) developer, I know many folks out there use a variety of different languages, each with its specific tooling. What works for Python, may not work for Java C# or Go.

I've compiled a short list from talking amongst friends over the last few years. The whole point of this list is to be short, NOT exhaustive, and list flexible practices. That would defeat the core theme of this blog post if they weren't! All of these tools work on OSX and Linux, and SHOULD also work on WSL if you are working on a Windows dev box. Please keep in mind, that all of these items are current as of 2023, and should be around for a fairly long time, nothing bleeding edge. If you don't like the tools of today, considering making your own, just please do your research online first. We have had enough of a problem with competing standards.

Tools and patterns that work (IMHO) (Platform Agnostic)

• Git

• Docker

• Semantic Versioning

• Mermaid

• EditorConfig

• Tartufo

Tools and patterns that MIGHT work (Platform Agnostic)

• GitHub Actions
  • While there are as many ways to do GH actions as there are software on the internet, one set I keep on coming back to is to generate releases and auto add to-do's. These YAML files go in your .github/workflows/ folder, inside your Git repo.

name: "Generate TODO to Issue"
on: ["push"]
jobs:
    build:
        runs-on: "ubuntu-latest"
        steps:
            - uses: "actions/checkout@v3"
            - name: "TODO to Issue"
              uses: "alstr/todo-to-issue-action@v4"
              with:
                  AUTO_ASSIGN: true


name: Release

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

on:
  push:
    tags:
      - "v[0-9]+.[0-9]+.[0-9]+"

jobs:
    release-gen:
        runs-on: ubuntu-latest
        permissions:
          contents: write
        steps:
        - uses: actions/checkout@v3
        - uses: ncipollo/release-action@v1
          with:
            allowUpdates: true
            generateReleaseNotes: true

    build-and-push-image:
      runs-on: ubuntu-latest
      permissions:
        contents: read
        packages: write
      steps:
        - name: Checkout
          uses: actions/checkout@v3
        - name: Docker meta
          id: meta
          uses: docker/metadata-action@v4
          with:
            images: ghcr.io/${{ env.IMAGE_NAME }}
        - name: Set up QEMU
          uses: docker/setup-qemu-action@v2
        - name: Set up Docker Buildx
          uses: docker/setup-buildx-action@v2
        - name: Log in to the Container registry
          uses: docker/login-action@v2
          with:
            registry: ghcr.io
            username: ${{ github.actor }}
            password: ${{ github.token }}
        - name: Build and push Docker image
          uses: docker/build-push-action@v4
          with:
            context: .
            platforms: linux/amd64 #,linux/arm64
            push: true
            tags: ${{ steps.meta.outputs.tags }}
            labels: ${{ steps.meta.outputs.labels }}
            cache-from: type=gha
            cache-to: type=gha,mode=max

• Conventional Commits

• Change Log Generation

• Commit hooks

• Postman

• Make

• Taskfile

• PyInvoke

Plugins & Apps (Platform Specific)

While I could list off dozens of neat little things I've found over the last year or so, I'll keep this list very short, just a few select plugins and apps that have really helped me be more productive. Please keep in mind that these are either IDE or platform-specific, so YMMV.

• AwesomeConsole

• ShiftShift

• RayCast, Wox & ULauncer

Conclusions

While I know this blog post has been very VERY long, I do hope it helps those who come across it to not only improve their tooling but to also improve HOW they think about the tools they choose and choose NOT to use. I hope this blog post inspires those who read it to try some new toys... err tools!