Beyond Writing Code

Tag: 2023

  • Bug hunting

    Another post I made a while ago on Medium, but this one I updated today with some newer thoughts.

    I once had a colleague who (jokingly) left this comment on a code review, and not in reference to a specific line of code:

    “Missing semicolon.”

    Photo by Nubelson Fernandes on Unsplash

    Case study two

    I once had a QA colleague who reported a bug to me in some code I had just written.

    I made a code fix, but he said it was still broken.

    Another fix, still broken.

    Another, still broken.

    Then he messaged me: “Never mind! User error!” and explained what he’d done wrong.

    I think of both of these case studies often.

    This post originally ended here, with “Yeah, that’s the whole post :)” when I posted it as “Ghost errors” on Medium on 24 August 2023. But I’m posting it again in 2025, and there’s more to say.

    First of all…

    What the above case studies have in common: reviewing something again, even if you’re not entirely sure what you’re looking for, can be a good thing.

    My reviewer colleague was joking about the missing semicolon. I think. Maybe I should just look through the code one more time.

    And my QA colleague was not joking, but the “bug” he was reporting was not actually a malfunction of the software (although it was arguably a design issue if even someone so knowledgeable about the product would be using it “wrong”). Regardless, it led to my finding and fixing three other problems that neither of us realized were there.

    Case study three

    A colleague recently was working on an application that had a bug that only happened at a certain time of day. He asked his AI coding assistant tool to write him a set of tests to test all the places in the code where time of day was a factor.

    And one of those tests failed.

    Questions

    Have you ever gone into your code to look for a bug that wasn’t actually there – but in the process, you’ve found some other things that need fixing?

    Wonder what happens if we send our AI assistants into our code to identify the bugs for us? Have you tried this? I’ve tried asking my coding assistant for suggestions on improving the code, but I haven’t said “there are some bugs in this code, please identify them and suggest fixes.”

    And here’s the question most on my mind right now:

    Do we lose something in using the AI tools? Is this the equivalent of using a dirt mover instead of using shovels – more powerful, less toil but also less exercise, probably better in some circumstances? What am I doing to keep myself in shape in case I need to pick up a (code debugging) “shovel” someday?

  • Thinking Errors – Notes

    Thinking Errors – Notes

    Photo by Austin Chan on Unsplash

    Notes from a post by Sheril Mathews about common thinking errors and how to spot them. First, the ones I suspect I fall into the most:

    • Mind reading — “knowing” what others think, or assuming they know what you think. In my case, both.
    • Jumping to conclusions — x therefore y with little evidence. This seems especially hazardous in combination with the previous — x therefore y, with inadequate evidence provided by mind reading!
    • Mental filtering — exclusive focus on negative (or positive), e.g. “that one thing I did wrong”. Also works in combination with the others. Focus on the one negative thing that I think I mind read from someone else, and then jump to conclusions about it.

    Well, good to know oneself… Here are the others. Not saying I don’t fall into these traps too… just that the ones above seem like my biggest hazards.

    • All or nothing thinking — perfect or total failure, always, never
    • Fortune telling — usually negative, foregone conclusion, defeatism
    • Overgeneralization — from one or two data points, e.g. Don Music “I’ll never get it, never!”
    • Should statements — unrealistic expectations
    • Disqualifying positive — success is a fluke/unreliable, e.g. “they were just being polite”
    • Magnification/Minimization — exaggerating or downplaying importance of something
    • Catastrophizing — assuming the worst, mountains out of molehills
    • Emotional reasoning — mistaking feelings for facts
    • Personalization/Self-blame — it’s my fault
    • Labeling/Mislabeling — extreme overgeneralization
    • Always/Never thinking — seems like overgeneralization + mind reading
    • Entitlement — unrealistic expectations — see also Should
    • Outsourcing happiness — I’ll be happy when…
    • Control fallacy — I control nothing (or everything)
    • Low frustration tolerance — what it says on the box
    • Fairness fallacy — life should always be fair and just — resentment, frustration

    Originally posted 23 August 2023 on Medium.

  • Cloud Resume Challenge

    A piano keyboard, glistening with light effects.
    Photo by Ebuen Clemente Jr on Unsplash

    DevOps Enterprise Summit 2022 closed with a great talk from Forrest Brazeal. As a cloud architect, musician, writer, and cartoonist, he’s got an impressive resume of his own, but he also has a project to help aspiring cloud engineers improve their skills and their resume.

    Forrest’s Cloud Resume Challenge is a set of steps for building oneself an online resume using a variety pack of cloud technologies. It’s enough guidance to tell someone what to do, and not too much guidance on how to do it, which suits me just fine. There are a lot of good tutorials online to fill in any gaps. Forrest’s work gets people past the “I have no idea where to start” point, onward to the “hmm… how would I do that?” point, where curiosity can take over.

    I learn best by doing. Watching someone demo or listening to a lecture only gets me so far. I need to twist the knobs and see what they do, break and fix things several times, go down a few dead ends and have to retrace my steps back. Granted, it can be frustrating — for example, breaking my site that WAS working, and not being able to spot what I’d done to make AWS unhappy. It’s also reminding me just how much I’ve forgotten (CSS…) in a few years of disuse, which is humbling. But it’s all overshadowed for me by how satisfying it is to try out a technology I’ve never used before (like CloudFront) and make it work.

    Here’s Forrest’s talk from the Summit: Transformed! A Musical DevOps Journey. (Registration is free and will get you 10 free videos per month from past conferences — the videos are great, well worth getting on a mailing list.)

    My Cloud Resume Challenge website so far: developerleaf.com

    And yes, it’s back up… for now…

    Originally posted 19 August 2023 on Medium.