Beyond Writing Code

Author: leafjessicaroy

The dangers of “who” and “why”: post-incident reviews
Originally posted 23 September 2023 on Medium.

Five valuable lessons, including one that really threw me for a loop when I read it.

In one of his LinkedIn posts, Jeff Gallimore posted some thoughts about retrospectives and post-incident reviews:

Just a PSA and periodic reminder about things to keep in mind when conducting retrospectives and post-incident reviews.

1. No one comes to work to do a bad job.
2. Everyone is doing the best they can given the information they have at the time.
3. There is no single root cause. There are multiple contributing factors.
4. Counterfactual thinking (i.e., “I/We should have done…”) isn’t productive.
5. Leading with “How”, “What”, and “Tell me more about…” is more constructive than “Why” and certainly “Who”.

Psychological safety. Learning. Generative culture.

Now, the first four reminders are important, and I’ve been getting better at catching myself as the years go on. But that fifth one was a new one for me, and I’ll admit, it stung a bit when I read it, because I often ask why and who.

My image search here was for “investigation”… this felt about right. Photo by Emily Morter on Unsplash

Asking “who”

I have no intention of assigning blame. I don’t find the “blame game” useful. Usually, I’m not trying to exonerate myself or my team, although I can admit to there being a little bit of motivation to do that. Mostly, when I’m asking “who” or “why” questions, I’m trying understand what happened so we can figure out what needs to be addressed. Specifically, if I’m trying to find out who was involved, it’s only because I want to know what they were experiencing in that moment. It seems like only someone who was there can truly report on what was happening at the time.

That said, I’ve had people refuse to tell me who did something. At the time, this was frustrating. My thought was: how can I prevent this problem from happening again if I can’t even talk to the person involved to find out what was going on?

Just reading that thought back to myself, though, raises a good counter-argument: why does it need to be me who finds out what happened and figures out how to prevent it?

If you’re guessing that I’m thinking of a specific instance, you’re correct. In this scenario, the team affected (mine) and the team that appeared to have caused the problem had a history of conflict. Trust was low on both sides.

I can only guess that when they saw someone asking “who did this,” they were motivated to protect one of their own from possible criticism. I might have believed that I would interview that person without blaming and shaming, seeking only to understand and to help. But I hadn’t established that trust with the other team, so they had no reason to share that belief. It makes sense that asking “who” would put them on the defensive. Not helpful.

Could I have asked “why” instead? Would that have been better?

Asking “why”

Consider this scenario: A problem was caused (at least in part, see Jeff’s point #3 above) by someone doing action Z. Let’s forget about who this person is. Shall we ask instead: why did this person do Z?

Let’s start by assuming that whoever did Z was doing the best they could with what they had (see Jeff’s points 1 and 2 above). They didn’t come to work intending to cause a problem. Maybe they:
- truly believed Z was correct (or that they were doing it in the correct way)
- did Z without even realizing they were doing it
- did good thing Y that in turn set off Z unexpectedly
- did Z believing it WAS good thing Y
- knew Z was trouble, but they believed they had to do it
- didn’t actually do Z at all
The list could go on and on. Then behind those things there are often other layers: overworked operator, lookalike buttons, alarm fatigue, things changing without notice, culture of fear, information not flowing as expected.

Each of these suggests a different strategy for preventing this from happening again. Maybe someone needs information, training, or just rest. Maybe a misunderstanding needs to be cleared up. Maybe some easily confused things need to be clarified and disambiguated. Maybe speaking up needs to be made safer. Or maybe we need to keep working to identify the cause and the fix.

Again, though, I think it comes back to trust. I have, in the past, tried asking “why did you do this?” or “why did this happen?” as gently and kindly as I could, with people who I thought would trust me… but the responses usually don’t help. “I’m sorry” is one common response — no matter how gentle I think I am, the person still senses danger and apologizing seems safest. “I don’t know” is another common response.

Nobody ever says “because I thought it was the right thing to do,” or “because I’m tired from long hours and I got confused” or “because the instructions weren’t clear” or…

I don’t think asking “why” gets me anywhere.

How and what to do instead

Jeff’s post has helped me identify that I have some strategies that don’t work. His suggestions of “How” and “What” and “Tell me more about…” seem like good places to start.

I’ll assume here that we’re avoiding confrontational non-questions that are really attacks in disguise (“How could you do something like that?” and “What were you thinking?” aren’t especially likely to bring on collaborative problem solving.

Maybe the “you” in these questions is at the heart of the problem. I can see where that might put the focus on a person, rather than on a situation, a process, a circumstance. Does focusing on a person run afoul of Jeff’s fourth point — that counterfactual thinking isn’t helpful? We might be avoiding blame, but are we still ultimately talking about what “should have” or “should not have” happened? This person should have had more training, the documentation should have been clearer, the alarms should not have been so numerous, good thing Y should not have triggered Z?

Perhaps the key is switching to a future focus. How can we prevent this from happening in the future? What could be done to improve the process? How could we make situations like this easier and safer? Tell me more about any barriers you see that could be removed or strategies you’ve thought of for doing things better. Engaging people in the problem solving, rather than trying to be the solver myself.

I posted this on LinkedIn in 2023. But here or there, I’d love to hear your thoughts about how you’ve approached this. What have you found useful in place of “who” or “why”?

Originally posted 23 September 2023 on Medium.
2025-04-27
Don’t do this: my career path

Folks who are new to software development sometimes ask me about my career path. The first time I fielded this question, I told my story in a straightforward way. Hearing myself talk, though, I realized: this way of telling my story is probably not a good idea.

This is not an actual illustration of my career path. Photo by Jack Anstey on Unsplash

People who ask me this question are often actually asking me about their own career path. They see where I’ve landed, and perhaps they imagine they want to land somewhere similar. They might be comparing their path to my own, perhaps to see if they might make some of the same steps that I’ve made along the way.

And my route is almost certainly not the route for someone else.

Step one: pay a utility bill

First and foremost: my story starts with my first tech job, in 1996… or maybe before that, with my undergraduate major in English… or even before that, with my first computer experiences as a kid learning BASIC on Commodore 64s and TRS-80s.

I may have been using computers since I was a kid, but I sure wasn’t carrying one in my pocket until well after I graduated from college. If you were carrying a smartphone when you were single-digit age, we have grown up in very different times. That’s significant. If I wanted to learn how to program a computer, I had to go somewhere that had computers and take a class.

Also, my first job in tech WAS in 1996 — during the “dot com bubble” days. I stumbled into it by trying to pay my gas bill online. The gas company didn’t have a website, so their URL went instead to the small local internet company that was hosting the domain. I poked around the site, discovered that the internet company was hiring for tech support, and I applied. As my boss from that company later told me, “you had the customer service skills, we could teach you the rest.”

You may be starting to see why I don’t recommend that you follow my path. Getting a job by trying to pay a utility bill online and inadvertently stumbling into a company that will train you is not a great career plan.

Step two: impulse buy an education

I moved from tech support to abuse handling (canceling spammer accounts, yay!) to network engineering. Then 2001 happened, the dot com bubble burst, and I got laid off, along with a lot of other people.

I quickly discovered that nobody was hiring the sort of network engineer I was, at least not at the junior-to-intermediate level I was at. They wanted people who could route network traffic within an office building. I only knew how to route network traffic between major cities.

One fine Sunday, while still unemployed, I started to toy with the idea of going back to school. Maybe not for a full degree, but just to get some other interesting tech experience. Worcester Polytechnic Institute offered a several-months-long graduate certificate program in UNIX, C, and C++. I knew some UNIX, and I had a lot of time on my hands. I submitted the “request more info” form.

Later that day, I was out on a bike ride when I got a call back (on my flip phone!) from WPI. The nice lady described the program. It sounded interesting. I explained my background, she thought it was a match for them. I asked when it would be offered next. I could hear her typing. The next round would start [clickety clickety]… on Monday morning. Less than 24 hours later.

I told her I didn’t know how I’d pay for it. She said we’d figure that out when I got there, and if I could arrive early, I could complete the paperwork then. So yeah, I impulse-bought a graduate certificate program while on a bike ride. If you weren’t already convinced that you shouldn’t follow in my footsteps…

To be fair, it worked out. I rediscovered that I still loved programming. But you could perhaps do a bit more research than I did, to better effect.

Step three: work somewhere for a year or sixteen

I was tutoring a fellow classmate during that program, so when he got a job somewhere, I thought “hey, if he can, and I was tutoring him, then I can…” That company had proprietary software, written in a proprietary language, on a proprietary operating system. I was pretty sure I wouldn’t stay longer than a year.

I didn’t stay for a year. I stayed for sixteen years.

I started as a service programmer, which mostly meant troubleshooting problems and fixing bugs with manual code patches. I got promoted. I went back to school, doing an undergraduate certificate in Computer Science. It was perfect — all the coursework I had missed from being an English major, without having to get a full bachelor’s degree again. It was also entertaining, as a senior programmer, to tell my boss I was taking an intro to programming class. 😉

I moved on to being a developer, which was more about working on new features for an application (but still troubleshooting and fixing bugs with manual code patches). I got promoted again. Eventually, though, I really wanted to learn mainstream technologies.

So I went back to school, again.

Step four: go overboard

You know, if you want to be a web developer, even a full stack developer, I’m not at all convinced that you need a master’s degree in software development. Some places will hire you without a degree, some will insist on a bachelor’s degree, but a master’s degree? It’s debatable whether or not I went overboard with that.

I had tuition reimbursement, so work paid for about half of it. And that — plus 16 years as a dev — probably did enable me to come to my current employer at a higher level than I might have otherwise. Also, I am not great about sticking with a self-driven program, but put me in an academic setting, and I’ll slay it (I had a 4.0).

However, if I wasn’t already cringing at telling you my bizarre and improbable story, I’m definitely cringing to tell you about the master’s degree. I don’t want people who are just starting out to think “OMG, to get to where I want to go, I need 25+ years in tech and a master’s degree?? I’m never going to get there.”

But “there” (where I am) isn’t where you want to go. Because here’s the ultimate reason why you shouldn’t follow my path: you’re not me.

Step zero: take your own steps

My path has given me a unique combination of skills, perspectives, and experiences. Do they make me extremely well-qualified to do what I do? I sure think so.

But here’s the secret: I’m doing what I’m doing because I enjoy it… and I’m qualified to do this job that I enjoy because, for 25+ years, I’ve just kept doing, and getting better at, what I enjoy doing.

I didn’t know “what I wanted to be when I grew up” until my late 20s, when I impulse bought that graduate certificate and remembered that I loved programming. Even then, I didn’t know what I wanted to focus on. I tried stuff out. In the process, I discovered what isn’t for me, like network engineering, low-level programming languages, and CSS.

The chances are slim that you want to do exactly what I do. You can see my experience or my title and guess what I do, but unless you’re my manager, you likely have inaccurate guesses about what I actually do. If you do think you find my role appealing, answer this: what do you imagine that I do? What most interests you about that?

Just like how my own starting point is probably not like yours, my own current role is probably not your true target. Therefore, how I got from my “Start” to my “Here” — while perhaps a fine story — is not nearly as useful to you as working out your own path to get from where you are now to your own destination.

“Follow your heart” isn’t quite what I’m recommending here. I’m suggesting something more down-to-earth. Try stuff that appeals to you. Figure out what you most enjoy doing — and, ideally, how you can get paid to do it. Then, do more of that, for as long as you continue to like it. When you get annoyed or bored (or laid off), stop and assess where you want to go next.

Don’t follow me. Your own path awaits.

Originally posted 12 September 2023 on Medium.

2025-04-27
Lessons from Uncle Sidney

Uncle Sidney was notorious. I think even he’d agree to that.

Sidney was his own weather system, with lots of thunder. Photo by Johannes Plenio on Unsplash

He might indeed be someone’s uncle, but he isn’t my uncle or the uncle of anyone I know.

He was the main instructor for one of the programming languages used (and created!) by one of my former employers. But if you said Uncle Sidney, everyone within earshot of him knew who you meant. Sidney was his own weather system, with lots of thunder.

His reputation preceded him, for everyone’s safety.

Portrait of Sidney

Likely in the same moment in which you were signed up for Sidney’s class, you were warned that you DO NOT under any circumstances show up late for class. Leave home an hour early, if you have to. Don’t be late. Your manager will hear about it, loudly and in no uncertain terms.

His insistence on timeliness wasn’t pure whim, or even simply a matter of respect. He had the timing of every day of his class down to the minute. If you delayed the start of class, that would throw him off schedule. And there was no “just start without me, I’ll catch up” in this world. This class was intense, and he needed you on board and attentive for every minute.

Second thing you learned: don’t fall asleep in class. I did this once. You better believe he noticed, stopped the class, and called me on it — loudly, crossly, but not unkindly. We took a short break. Again, he needed our attention for every minute.

The stories could go on and on. Some of the stories were not so great. “Sidney yells because he cares,” we’d say. It helped me to think of being yelled at as a badge of honor, but not everyone can let shouting roll off them like water from the back of a duck.

Some stories were more entertaining. My favorite moment was when he quipped that Friday was actually “fried day” because people were fried by then… and then he laughed so much at his own corny joke that he couldn’t continue class for at least a full minute. Which, of course, threw him off schedule.

I emerged from those classes reasonably conversant with the programming language. It’s been years since I last used it, and most of my knowledge of the language is gone now. However, several other lessons from Sidney stick with me.

Slow down, smart people

I find myself repeating this one as I’m mentoring: smart people have a tendency to rush, especially by jumping to conclusions. We’re gratified to put some of the puzzle pieces together and think we see the whole picture. We see A and B, and we get excited. We immediately decide F and G, therefore K… skipping a bunch of intermediate steps. Then when K doesn’t turn out to be true, we’re confused and stuck.

The answer is often to rewind and start again with A, taking it one step at a time. A, then B, then C, then D… wait, what about E? It turns out E isn’t true after all, which explains why K was a faulty conclusion.

Here’s a concrete example. Let’s say a specific input to a function should be generating a certain output, but it isn’t. We stare at the function, and we don’t see how we could possibly be getting the results we are seeing, given the input we’re passing in — or more accurately, given the input we assume we’re passing in.

Slow down a bit. Check to see if the values we’re passing in are what we expect. They are. Slow down a bit more. Are the values we’re passing to the function the same as what the function is receiving? “How could they not be??” you might ask. Check anyway. Wait, they’re not… I pass 5 and 100 and the function is receiving 0 and 0?? How can THAT be?

And that’s exactly the reason for slowing down: you’ll find those problems that exist in the cracks, in places where you assumed everything was going according to plan. Maybe you never saved your most recent code changes, so the code that is running isn’t the same as what’s on your screen. No wonder E isn’t true.

Don’t always take notes

There’s some evidence that writing things down with pen and paper, rather than typing them, improves retention. Writing by hand might force you to do more processing to put the ideas in your own words, whereas typing lets you record what was said closer to verbatim, without necessarily comprehending it.

Sidney took this a step further, calling me out on my tendency to try to write down everything. He would provide us with notes, he promised. Try putting the pen and paper aside and just listening. Just absorb the ideas and make sure you understand. Too much writing, especially in a class as fast-paced as his, and you might start to miss the current idea because you’re too busy trying to record the previous idea. This can snowball quickly.

Ask the question ASAP

If I’m listening to someone lecture, I often hold a question in my mind, rather than asking it. I am trying to allow for the possibility that they’re going to explain it momentarily, or that I have all the information and I just need to make some mental leap to understanding. This is not a great habit.

With some lectures, the information is cumulative. If you don’t understand the point that was just made, you are going to be confused by the point currently being made, baffled by the point coming next, and completely lost in a matter of minutes. And at that point, it can become hard to admit that you actually lost the teacher several minutes prior and you need them to recap a lot.

Put another way: the best time to ask is as soon as you have the question, or as soon as you realize you’re confused. The next best time to ask is when you’re kicking yourself for not having asked because you’re now completely lost. As challenging as it is to confess being lost, it’s only going to get worse the longer you stay lost.

Could you teach it?

Related to the point about asking the question right away: one of Sidney’s tricks was to ask the class if we all understood something. Are we sure we all completely understood it… yes, nods all around.

Okay, he’d say, then explain it back to me.

Uh oh. Suddenly, we’re not sure we understood it so well after all. Oops.

It’s not necessary that you understand everything perfectly on the first try, or that you could explain it to others after just one hearing. It is definitely useful to know that there are layers of understanding, and to know when you might be expected to be at a deeper layer than you are. Now, I routinely check my understanding: did I just barely follow what I was being told? Could I explain it to someone else if they asked? If not, what do I need to ask to get clarification? Or is my minimal understanding sufficient for now?

You influence others too

Uncle Sidney retired before I left that company. On his last day, I made sure to catch up with him to say my goodbyes and wish him well in his retirement.

And it really hit me — as one of the original developers of that language, he’d taught “generations” of developers how to reason about it. He’d taught us how to slow down, skip the note-taking sometimes, ask the questions, and check our understanding. And everyone who taught the language would do so in his footsteps as well, even if their approaches and teaching styles were entirely different. In that way, his influence on the organization was not so unlike an uncle after all.

What’s your legacy, and what do you hope it will be? When you move on from where you are now, what will people remember about you? What habits will they pick up from you, what lessons did they learn from you, and how did you influence the culture and people around you?

Originally posted 10 September 2023 on Medium.

2025-04-27
Have you been giving your employer money?

I suspect most people would not spontaneously and voluntarily give back part of their salary to their employer. I don’t mean donating to a cause, or chipping in for board games to play at lunch. I mean just handing your employer a wad of cash. “Here, this is for you.”

So don’t do it with your time.

Photo by Eric Rothermel on Unsplash

Your time belongs to you, just like your salary does. Moreover, time is one of the few things money can’t buy more of. You can only — at best — free up time you already have, like paying someone else to do yard work that would take you hours.

Think of it this way: If your company didn’t have health insurance, a retirement plan, an education reimbursement benefit, free food, etc., you could simply buy those things outright if they paid you enough.

If you didn’t get time off today, you couldn’t buy more of today no matter what they paid you. You can’t buy a second evening to add on after you work through the first evening. If you don’t take a vacation this year, you can’t buy a 53rd week. You can’t even buy an extra few minutes between the call that ended at 1:55 and the one that starts at 2:00.

When the time is gone, it’s gone. Before it’s gone, choose to do something with it that is part of your best life. And I am not thinking “side hustle” here (no judgment if that’s your thing). I’m thinking rest, family, friends, health, joy, creativity, meaning.

To clarify

This message isn’t for the people who get paid more if they work more. If you need to work more hours to get paid more to get by, or if you deliberately choose to do that (maybe you’re saving up for something important), that’s a different story.

I’m talking here to people who are paid the same whether they work 40, 50, or 60 hours.

And I’m also not pointing to people who are up and working at 5 am, people who are still in the office at 7 pm, or even both on the same day. I don’t care what schedule you work. I know someone who would goof off in the afternoons, go home, put the kids to bed, and then focus on work for a few hours. Same effort, just a different schedule.

For that matter, this isn’t even about someone choosing to work 50 or 60 hours because their work happens to be their passion. If you are in a divinely inspired flow state in your code, your art, your carpentry, your mission… you rock on for as long as that’s infusing you with life and joy.

But if that isn’t you, and you’re choosing work over taking time off, that raises an important question.

Why ARE you doing that?

I can preach about this, but there’s some reason why you’re so often choosing work instead of stopping.

Stop for a moment and think of those times when you look at your watch and it’s noon and you’re hungry… or it’s late and you’re tired… or your calendar is open and you’re thinking of scheduling time off… and yet you choose work instead of lunch, leaving for the day, or planning that vacation. Why are you making that choice?

I can’t answer that for you, but I can answer it for myself. For me, it’s usually some sort of insecurity. I am unsure if my efforts so far have been enough. I’m unsure if I will be able to meet some deadline, real or imagined. I’m unsure what would happen if I point out that the work to be done has exceeded the capacity to get it done. Or maybe I’m pretty sure what would happen (whether or not I’m correct) and it’s a consequence I don’t want to deal with.

Interestingly, it’s often paired with some sort of false self-confidence. Sure, I haven’t been able to get [whatever] done in the three days I’ve been working on it, but if I can just focus on it for another hour, then I’ll really make some good progress. An hour later, when I’m not further along, I’ll be disappointed in myself. Only further evidence of my inadequacy! I’d better stay another hour.

It’s your job to push back

Regardless of your seniority, but especially if you’re a tenured and experienced employee, it’s part of your job to push back when the work exceeds the time and capacity allotted. I’m thinking of my developers here. You’re the one who is in that code, and you have the full picture of what else is on your plate. Your manager has to rely on you to let them know what’s feasible and what isn’t. They might not like the message, but they need to hear it.

How do you deliver that message? What are the alternatives when there’s more work than capacity? Check out my earlier post on how to handle that situation:

Something’s gotta give

Just remember that anyone who says “too bad, we need it done, so you’ll have to stay late” is saying something akin to “too bad, we need money, so you’ll have to give it to us.”

Originally posted 5 September 2023 on Medium.

2025-04-27
Why people do what they do
Originally posted 30 August 2023 on Medium.

I’m a huge fan of the DevOps Enterprise Summit, (now called Enterprise Technology Leadership Summit). Disney’s Jason Cox (Head of Global SRE) is a fine speaker and storyteller, and my favorite Disney character. His presentation on Creating Digital Magic gave me a lot to think about.

Go check it out now, if you’d like to, because I’m about to give some spoilers.

I’ll wait. [humming a little tune to myself]

Registration is free, and it gets you ten free videos per month, which is a pretty good deal. It gets you on the IT Revolution mailing list too, of course, but I actually like what they’ve been sending me, so I don’t mind.

Okay, so you’ve either watched the video, or you’ve decided you don’t mind the spoilers. There’s more to the talk than this, but here are Jason’s three main takeaways:
1. Listen.
2. Have empathy.
3. Actually help people.
Hooray! Wait…

My first reaction was to cheer. Yes! So many people in tech need these lessons. I’m sure we can all imagine working relationships, past or present, that would be utterly transformed in positive and uplifting ways (or at least made tolerable) if they embodied these three principles. We could stop wondering if we’re talking to a wall, an ogre, or both. We could get some real work done. We’d be happier.

My next thought was: wait… do we really need to tell people to listen, be empathetic, and help?? Shouldn’t that just be a given? As a friend of mine says, “we’re trying to have a society here, people.”

People are baffling sometimes. Photo by Chris Arthur-Collins on Unsplash

What have we come to as an industry, or as humanity, that we need a leader from a major company to get up on the main stage at a conference to tell us that we should be kind to each other? Great message, but kind of awful that it’s so needed.

My third thought: does telling people something like this actually help?

Given everything I’ve heard about the community that has sprung up around the DevOps Enterprise Summit conferences, I imagine that a fair amount of Jason’s audience already behaves in the way he’s exhorting people to consider. I suppose it’s pleasant, for someone who already puts effort towards listening, empathy, and helping to hear a champion of those principles speak about them with enthusiasm. I’m sure there’s an element that believes they don’t behave that way, when in actuality they do, and I suppose the message could motivate those people to try harder.

But what of the people who already aren’t listening, being empathetic, or helping? Do those people actually hear this message and think “you know… he’s right, I really ought to try that”? And if they do think that, is just telling someone this (granted, in a heartfelt and well-presented way) enough to get them to change their behavior?

Underneath it all for me is this deeper question…

Why do people do what they do?

There’s a huge hazard, one that trips me up all the time. The fundamental attribution error is the tendency to chalk up someone else’s actions to something inherent to that person, but one’s own behavior to external factors.

Some relevant examples:
- They didn’t listen to me because they don’t care. I didn’t listen because I was distracted by an urgent issue that came in.
- They aren’t empathetic with me because they’re egocentric and childish. I am not empathetic with them because they’re giving me attitude all the time.
- They don’t help because they’re lazy and incompetent. When I don’t help, it’s because I’m busy and overwhelmed.
We make up stories about other people all the time (“that look she gave me means she’s nervous”) and if we’re not careful, we take them as reality. The fundamental attribution error creeps into these stories and influences the narrative we write. Add to that any other reasons we might be defensive and ready to blame others while exonerating ourselves — e.g., looming deadlines, personal financial woes, traffic jams — and we’ve got a potent combination for believing others to be awful and oneself to be an innocent victim, neither of which are especially useful conclusions.

Just telling people — even yourself — to do something is generally not enough. If you want behavior change, you’ve got to work out a plan for it.

In other words, “great, Leaf, but what do people DO about it?”

What to do

Here are a few things I’ve tried in the service of breaking the habit of telling fundamental attribution error stories:
- I have a sign taped to my monitor that says, among other things, “Is this true, or a story?”
- I’m starting to use being angry or upset as a warning flag that I’ve got a story going on. It’s useful to tune into signals from the body if you can. I’ve spent decades being a floating head, so I get it if that’s hard.
- The phrase “that’s one possibility” is helpful here. Or try my dad’s favorite: “Is that so?” Both are good litmus tests for spotting when you’ve got a story instead of a known truth.
- I just finished Douglas Squirrel and Jeffrey Fredrick’s book Agile Conversations, which suggests a practice of deliberately considering alternate explanations, including some ridiculous ones to get the ideas flowing.
- I try to figure out under what circumstances I might exhibit the behavior for which I’m criticizing someone else.
Let’s try an example.

They don’t help because they’re lazy and incompetent! Hey, I’m angry here, my jaw is tight and my hands are clenched. This might be a story I’m telling myself. So… yes, lazy and incompetent is one possibility.

Maybe they don’t have enough people to handle the workload. Maybe I wasn’t clear in my request for help. Maybe they somehow heard a message that this wasn’t urgent, so they’re prioritizing more urgent work. Maybe they are fending off a zombie attack and I’ll be lucky if they can help at all.

What has caused me to not be helpful to others in the past? Well, I sometimes get requests from people who don’t realize that I’m out of the office, so maybe a key person is on vacation. I keep getting stuck in meetings, which gives me less time to help; maybe they’re getting pulled into too many meetings. And hey, sometimes people are simply asking for something unreasonable. Could it be that my request is not as reasonable as I think it is? Maybe I’d better check into that.

Where I landed

Right then. Jason’s three takeaways — useful, or no?

I’d like to see more speakers go past explaining their ideas to suggesting things to try. But just the same, I’m going with yes, his talk was useful for me. It got me thinking about how we determine why people do what we do. It led me to articulate some things I’ve tried to bring more depth to my conclusions and go beyond accepting the first and likely problematic story that comes to mind.

Have you caught yourself telling yourself stories? Have you noticed times when you’ve made the fundamental attribution error? What might you do differently, or what have you already done or tried to do, to listen more, be more empathetic, or actually help others?

New p.s. for 2025: I’ll be at Enterprise Technology Leadership Summit in Vegas in September. If you will too, come find me there.
2025-04-27
Choosing a mentor (updated)

I’m happiest in a job when I’m learning from someone who knows more than I do.

Last year [this post is originally from August, 2023], I started a new role on a team of engineers who all know boatloads about stuff I don’t. That by itself was a dream come true. Just after I started, we learned that one of my teammates would be going on parental leave in a few months, and it was decided that I would pick up his responsibilities while he was out. So, lots of knowledge transfer was about to happen. Better yet, he’s a great teacher, great to work with, and he works on things I’m interested in.

Luck is not a strategy

Let me clarify before we continue: I’m not telling you to get a mentor by changing jobs to one where everyone could be your mentor and the person who would be the best match from among them just happens to be going on leave half a year later. Nice work if you can get it, but that’s not a strategy, that’s mad luck. And it’s just the preamble to the story I want to tell you.

The downside to this magical plan of knowledge transfer galore became painfully obvious about 5 months later when joyful news of the baby’s arrival meant my new work BFF was suddenly not available.

Side note: it was less than 24 hours before we had a question that only he could answer. 😂😭

I was too busy adjusting at first to notice, but it wasn’t long before I could see I was adrift. I needed a new mentor. But who?

Start with the obvious

First question I asked myself was an obvious one: “who do you know who might be a good mentor?” A worthwhile question, but for me it only generated some names who didn’t seem like good matches. People whose focus was different from mine (including most of my team). People who were probably too busy. People whose skills were too much like mine.

Photo by Desola Lanre-Ologun on Unsplash

I suspect this is where some people get derailed. I can’t think of anyone, or I don’t dare ask because I doubt anyone has time for, or interest in, working with me. And what would I ask them about anyway if we did work together?? The “who do I know” question was getting me nowhere, but it’s worth a shot, maybe someone leaps to mind for you.

Decide what you want

I thought about asking my manager, but then I realized he would probably ask: “what do you hope to get out of mentoring?” Huh, I hadn’t thought of that, beyond “someone to learn from.”

There’s an important distinction here between “mentor” and “sponsor.” A mentor is a guide who can teach you, advise you, help you get unstuck. A sponsor is someone who can advocate for you in rooms you aren’t in, look out for opportunities for you, help you make connections. Identifying a potential sponsor is a whole other post. In this case, I wanted a mentor.

I was looking for someone knowledgeable in topics I was interested in, someone who could answer questions or offer advice I had when I got stuck on those subjects. Someone who could give me a perspective from a vantage point different from my own.

The next question that arose from this was: “what are you interested in?” Again, I hadn’t really given that much thought. I was immersed in this world of NodeJS and Kubernetes and cloud migration, but was that something I wanted to keep focusing on?

I thought about the things I had been learning about recently, and DevOps came to mind. I know that term means different things to different people, so a few examples would be useful here. I had recently read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford (great book!). I had read some writing my new-dad colleague did on the mindset shifts needed for a devops transformation. I’d read a few items from our Enterprise Architecture (EA) team about it, and I’d been to a few architecture “community of practice” meetings where one of my EA colleagues had presented about that. That same person had written the “getting started with DevOps” article that recommended The Phoenix Project.

As you might be guessing, this gave me an idea for who I might ask.

You might also be thinking: great, Leaf, that you thought of someone. What if nobody had come to mind? That’s where I would have reached out to my manager. Having decided what I was looking for, I could start to tap my manager, or other people who have been at the company a while, to see who they knew who might be a good match.

Deal with the doubts

I had a name that seemed like a potential good match to me, but I still had doubts. Would he have time? Interest? Could I even set this up? He was in a completely different part of our tech org. And what would I say?

I decided to deal with most of those doubts by ignoring them. Why cancel an opportunity before you even try for it? There was no way to know what would work unless I asked. I happened to have a 1:1 meeting with my boss’s boss around the time I was thinking about all of this, and I realized he might have the insight into whether this cross-org match would work. I brought it up.

Sure enough, his first question was about what I was looking for from mentoring, so I was glad I had an answer ready. He offered to talk with my potential-mentor’s manager about it, and a few days later, I got the go-ahead.

We scheduled our first chat. That left me faced with the question of what to actually say.

Arrive prepared…ish

I already have a rough framework for how I introduce myself to someone. It’s kind of a mix-and-match set of phrases about me that I tailor for my audience, omitting things they already know and focusing in on what’s relevant. I’ve been a developer for 20 years, I became a tech lead in 2020, I got to help an application grow from empty repository to serving users in production… that sort of thing. It situates me in time (how long I’ve been doing what), space (in the org chart sense), and experience (dev-turned-architect, learning devops). Pausing to invite the other person to share anything from their background or current interests is probably a good idea here, although I don’t think I actually did that, oops.

I also had some ideas of how I was hoping this mentoring thing would go. Maybe meet once a month for half an hour, I’d batch up any questions I had about things I was learning. It was almost a “hey, let’s try this and see if it’s useful.”

Other than that, though, I didn’t arrive to our first meeting with an agenda other than introducing ourselves and setting a cadence. I think that’s fine. I mean, if you have questions to bring already, bring them, you never know… but the first meeting doesn’t have to be a teaching session. It can just be an introduction, especially if you have not actually talked with this person before (I hadn’t).

Bonus points (“wow, I wasn’t expecting that”)

Let me just say that I had no idea what I was getting into with my new mentor. In a good way.

Photo by Marcel Smits on Unsplash. That’s not me, but I did have curly hair like that as a kid.

First? He was actively listening, even taking a few notes as I talked. It was clear that he didn’t want to interrupt me, but he was noting items he wanted to circle back to when I was done. Okay, I haven’t even finished introducing myself yet, and I’m already learning. Win.

Second, I didn’t realize just how experienced a colleague I had picked. Checking someone’s LinkedIn profile first might be a good idea, no? I did not. In this case, my error was only in my favor, as I picked someone with decades of experience working with developers. He’s an astute advisor not just about devops and the tech we work with, but also about interactions with others. I’ve brought him some interpersonal work dilemmas and he’s had helpful insight.

The biggest surprise for me was that this mentoring relationship turned out to be way more of a “two-way street” than I expected. What could I have to offer him, given that he has no particular need to troubleshoot a Jenkins build problem or learn how to use kubectl? Well, I’ve been a developer, a tech lead, and an architect, both doing the work and helping other devs do the work. That gives me a lot of visibility into and perspective on how dev teams in my area operate. And he’s outside of that area, so this is valuable to him. (Don’t fret if you don’t have that kind of experience, though – the perspective of a newer person is more valuable than you may realize.) We’re also working in partnership with each other, because with two different management chains, we have different sources of information, spheres of influence, and organizational contacts. We’re working out ways our teams can support each other’s efforts, and we’re introducing each other to people who can help.

Ask, ask, ask

Start by asking yourself the questions to determine what you are looking for from a mentor and how you imagine mentoring might look. Ask around to find a potential match, and ask for an introduction – if they don’t have time or interest, you’ll find out, and no harm has been done by asking. Keep an eye open for what you might be able to provide for your mentor in return (like sharing an interesting article or introducing your mentor to a colleague). You could ask your mentor outright if you can be of service in some way. Curiosity about yourself and others will serve you well on this quest.

Many thanks to both of my mentors, I can’t imagine the last year and a half without you. Thanks to our management for making the connections (and for being great mentors in their own right). And thanks to “baby G” for disrupting the status quo and opening up doors for me in the process – happy first birthday.

Originally posted 26 August 2023 on Medium.

Epilogue

It is now April 2025, and I am fortunate to continue to have both mentors as friends. I have also stumbled my way into a few other mentoring relationships as well. I wasn’t looking. I’ve simply crossed paths with a few more people whose knowledge and perspective have made them great teachers, whether or not they realize it.

I’ve come to treasure those professional relationships where we can have a once monthly half-hour meeting on the calendar, with no prepared agenda, and we’ll invariably find more than half an hour of useful stuff to discuss. “Hey, I wanted to get your opinion on this…” or “so here’s the dilemma I’m facing…” or “do you have any advice for how I might approach…” or even “is it just me, or have you also noticed that…”

I’ve also been able to be a mentor myself for a few others, folks who have sought me out directly or through their management. But whether I’m someone’s formal mentor or not, I see it as a key part of my role to just listen and be present with others, and to offer anything from my experience that might be useful in response.

2025-04-27
Three reasons not to bring hostility

I enjoy challenges to my “conventional wisdom” about how developers and dev teams work. We can improve. “The way we’ve always done it” isn’t necessarily the best way.

Luckily, I have found people on social media who offer those challenges in their posts. Much of the time, if I don’t agree already, I learn something or at least I have a new point of view to consider.

However, I have noticed two unsettling things about some of this writing: 1. It can be a bit — or a lot — hostile to people who don’t agree, and 2. I found myself enjoying that hostile tone (if I already agreed with the writer myself). Ick.

I get it. It feels good to be certain about being right. Whether or not one is actually right.

And, although I suspect few people want to admit this out loud, it feels good — at least temporarily — to put someone else down. Why else would so many people do that so often?

“You’re just plain wrong… real developers wouldn’t… only immature developers would… doing x is foolish… why even do y, it’s a waste of time…” Mockery, insults, and lots of condescension.

I also understand that sometimes people are simply responding in kind, having been the original target of some hostility from detractors. That kind of thing can push my buttons too, and I can get caught up in defensiveness — here’s the data, or the expert opinions, or the superior reasoning. You’re wrong, I’m right, so there.

The more I reflect on this approach, though, the more it worries me. While I can still learn from others who operate this way, I’m moving away from engaging in and with that kind of hostility, and here’s why.

Be kind

First and foremost: “be kind” seems a good rule of thumb to me. There’s another human being on the other end of the conversation. Disagree, present your case, set limits and boundaries, fine. But be kind about it. As a friend says, “we’re trying to have a society here.”

It’s ineffective

Second: is hostility useful? Does condescending help? Is it likely to change someone’s mind? I think not. Does rudeness towards you change your mind on a topic? Assuming not, why would your return fire change their mind?

Or is the objective not to change someone’s mind? What is the objective, then? Uh oh. For me, if I look closely at it when I am in “fight mode,” the objective is to prove my superiority. Not how I want to show up in the world.

It’s bad for you

Third: it isn’t healthy for the one being hostile. For me, it only feels good temporarily while I imagine myself the better person, the better warrior. After that fades, though, it’s just icky. It hurts your heart.

You can lob poison at someone else, but you get it all over yourself in the process. Don’t do that to yourself.

“But they were hostile first…”

Ahh, the childhood playground defense: “But they started it!” Perhaps they did, but you need not continue it. It’s an internet discussion about technology, not a threat to your well-being. It can be hard to remember that when your nervous system is telling you otherwise!

And for me, responding in kind is an excuse, not a reason. It lets me justify my indulgence in bad behavior to myself.

Someone else’s aggression doesn’t force you to be unkind. You can be kind and still be truthful, clear, resolute, etc. You can kindly disagree, set boundaries, or present counter-arguments. You are also free not to engage, or even not to respond at all (to anyone, hostile or not). Yes, it’s nice to educate, but it’s not your responsibility to do so just because you believe someone is mistaken or just because they left a comment for you to read.

Meet people where they are

I forget, often, that I am fortunate to have had a lot of formal and informal opportunities to learn. I’ve been in environments that support change and growth. I’ve had contact with people and ideas to challenge my status quo.

Not everyone has had the same exposure to the same resources that you or I have had. It may seem that only someone living under a rock could possibly not know such-and-such. Let’s imagine that that’s true (metaphorically or literally!), they just got out from under the rock yesterday, and you are their first contact with a new idea that could potentially transform how they think and act.

I’m suggesting that instead of yelling at them for having been under a rock, we kindly help them. We meet them where they are and listen to what it was like under the rock. We recognize that what’s a given to us may be a new idea to them and maybe a little hard to swallow. “The way we’ve always done it” feels safe because it is familiar, this way is unknown territory and therefore scary. Let’s help people change their thinking instead of putting them down for not already agreeing with us.

We could even be open to changing our own thinking. Could it be that we are wrong?? Unheard of!

I know this “I-know-better” attitude can be an old habit for me, though, so you are welcome and invited to call me on it. If you are interacting with me, whether online or in person, and you see me snarking at someone, gently remind me of my intention to be kind. I’m learning too.

Originally posted 25 August 2023 on Medium, but updated a little when posting it again here.

I’m especially intrigued by my call to action at the end. How comfortable are people in giving me feedback? A topic for another post to come.

2025-04-27
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?

2025-04-26
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.
2025-04-25
Cloud Resume Challenge

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.

2025-04-25