Beyond Writing Code

Category: work

  • The dangers of “who” and “why”: post-incident reviews

    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.

    A dark hallway with a large glowing question mark on the wall at the end.
    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.

  • Have you been giving your employer money?

    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.

  • Why people do what they do

    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.

  • Choosing a mentor (updated)

    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.

  • 33 Things You Don’t Need on Your Desk

    33 Things You Don’t Need on Your Desk

    Friends, writing on Medium (and getting photos from Unsplash) taught me that I’ve been doing it all wrong.

    Back in 2021 […pause here while I yet again grapple with the fact that it’s not still 2020, and that 2021 was in the past], I decided to update my home office environment. I replaced my desk, which had been a beat up kitchen table that I bought used from a coworker ten years ago. I got a handsome sit/stand desk — rubberwood top, nice big work surface, electronic height adjustment. Sweet.

    But now here I am, adding photos to my Medium articles, and I start to see a theme emerge as I search. Consider this:

    Nature lover, two plants (Photo by Domenico Loia on Unsplash)

    And this:

    Nice skull and crossbones (Photo by Geert Pieters on Unsplash)

    And this (I like the dual beverage situation here):

    Books as plant stand (Photo by Daniel Korpai on Unsplash)

    And so many, many more like it.

    What have we learned here

    Here are the things you should have on your desk: a laptop, a beverage, your mobile device, a plant. Optional: a monitor, a lamp, a wireless mouse, and ONE additional decorative item (candle, books, second plant).

    That’s it.

    If necessary, you can swap out the beverage or the mobile device for one more item (like audio equipment), or just omit them:

    Photo by Remy_Loz on Unsplash
    Photo by Sora Sagano on Unsplash
    Photo by Christopher Gower on Unsplash

    But in general: laptop, drink, device, greenery.

    No wonder I haven’t achieved the minimalist state of bliss yet.

    What I’m doing right(-ish)

    At the moment, I do in fact have a laptop, a beverage, and my phone on my desk. I have the monitor — bonus points, perhaps, for having it on an arm so it floats above the desk? I have a wireless mouse, albeit a clunky ergonomic mouse, not a sleek Mac mouse.

    I have several plants… on a shelf nearby. Does that count? I have the lamp. And I do actually have a candle.

    Already I’m in trouble, though. First of all, I have two laptops, one on top of the other, both of which are on a laptop stand. I also have two beverages — a travel mug with no lid for coffee, and an unsightly Nalgene bottle (how last decade of me!) for water. There’s a coaster, which I’m not using under my coffee, because today I have hot coffee, not iced. A mouse pad rests under my mouse. A glass plate under the candle protects the desk.

    I’ve got a camera positioned on top of the monitor. Putting things on the monitor seems like cheating, like violating the spirit of the law, if not the letter. I don’t think the monitor is supposed to have little notes taped to it either, like the reminders to myself to “enable captioning” on meetings and to “GO OUTSIDE” already.

    You can tell this person is away from their desk — there’s no beverage. (Photo by Ján Vlačuha on Unsplash)

    And there are… drum roll please… WIRES. Oh no, not that. 🙄 I have a docking station to serve up the monitor/camera/power combination, and there are wires for those items, as well as the lamp. My device charger is currently charging one of the two sets of AirPods on my desk, and a set of wired earbuds hangs out nearby as a backup.

    Uh oh, that’s [counting on my fingers here… second laptop, stand, Nalgene, coaster, mouse pad, plate, docking station, wires, phone charger, two pairs of AirPods, wired earbuds] twelve things already and I haven’t even strayed from the original list yet.

    Okay. At the moment, I also have…

    Writing, the old fashioned way

    13. Paper, with notes scrawled on it. My notebook was out of reach and I needed to jot some stuff down. It’s actual three-ring-binder style notebook paper, which I haven’t bought in like 20 years so it’s old. I don’t know why I still have it.
    14. Said notebook, now in reach.
    15. Five metal tins full of pens, pencils, and markers. I’m an artist. I’m going to count all five as one item, on the premise that if I weren’t an artist, I’d only have one.
    16. My journal.
    17. Post-It notes.

    I suppose if I weren’t working with paper, I wouldn’t need these items either:

    18. A stapler
    19. A scotch tape dispenser
    20. A lone paperclip
    21. White out. Do I need to explain what that is? Like a tiny bottle of white paint you can use to cover up errors you’ve made with a pen.
    23. A kneaded eraser, which honestly I only have for art purposes, and which even more honestly I use more as a fidget toy than an eraser.

    Photo by JESHOOTS.COM on Unsplash

    So, should I stop this foolish “writing” nonsense and just type everything into a Google Doc or a flat text file or something? Not going to happen, I’m afraid. Even though I own…

    23. …a really weird ergonomic keyboard. The Kinesis 2 puts my wrists, my arms, my shoulders, my back in a neutral position. I figure that it’s cheaper than surgery.

    Side note: Did that contraption take a while to get used to? You bet it did. I kept hitting the Enter key when I meant to hit the space bar, so I had

    leaf 8:08
    a

    leaf 8:08
    lot

    leaf 8:08
    of

    leaf 8:08
    slack

    leaf 8:08
    conversations

    …that looked like the above, where I sent some poor colleague one word at a time for several seconds before I noticed what was happening. Also, I kept typing Z when I meant X, which doesn’t sound so bad — except that my project was called “Apex,” so I was typing that wrong all the time.

    Self-maintenance

    The modern developer clearly functions on beverage alone. I haven’t transcended physical needs yet, so I have:

    24. A box of tissues
    25 & 26. Two bottles of hand lotion (one scented, one not)
    27. Hand sanitizer… okay, I don’t know why I have this on my desk
    28 & 29. A spray bottle of eyeglasses cleaner and a cloth
    30. A bowl and spoon left over from breakfast

    This person has stepped away to take a call — no mobile device present. (Photo by Rich Tervet on Unsplash)

    With the exception of the hand sanitizer, though, I would not be surprised to find any of the above 28 items on a typical desk. Maybe the keyboard and mouse would be a little less ergonomic, but they all seem like normal stuff.

    And then there’s this…

    How about:

    32. A skunk

    Specifically, a Folkmanis mini skunk finger puppet. She is my “emotional support skunk.” I highly recommend having a soft, hand-sized plush creature to keep you company. She’s usually just out of sight when I’m on a stressful Zoom call.

    Or how about:

    33. A packet of Click and Grow plant pods (one basil, two marjoram)

    I mentioned having plants nearby — that’s the Click and Grow, sitting on a shelving unit next to my desk. I put in new pods a few weeks ago, combined the leftovers from two packets into one, put the packet on my desk… and immediately forgot about it.

    You see, the laptop(s) and stand have a sizeable unused space behind them. I don’t see it most of the time, because the laptop blocks the view. It wasn’t until I started writing this article that I actually noticed the abandoned packet of pods.

    I could move it to join the other packets, but I think instead I’ll put the other packets in that otherwise unusable space. It’s right next to the Click and Grow, and if it’s out of my sight most of the time, that seems like a fine place to store stuff.

    Wait, do some of the pictures above have things hiding out of sight behind those laptops? What could be behind this, for example:

    Photo by Kevin Bhagat on Unsplash

    The beverage, perhaps? Uh oh. Fear that. Don’t put your beverage behind your laptop. You’ll forget it’s there, move your laptop, and spill your coffee everywhere. Granted it will only ruin four other items on your ultra-minimalist desk, but one of those is your laptop. Don’t do it.

    You live at home and that’s OK

    Listen, I’ve got nothing against minimalism (no pun intended). If you are a real person whose real desk is populated only by your laptop, coffee, mobile, and a plain white pot containing either a succulent or a patch of grass, I applaud your dedication to tidiness and order. Especially if all of it is either parallel, or at 30 degree angles, to the edge of the desk. I see you, shutting off Slack and email and clearing your mind to focus uninterrupted on your Ruby coding. It’s lovely. Keep on keeping on.

    For those of us whose desks have more than five things, though, a word of encouragement: no, you’re not doing it wrong. This trend is just the Medium and Unsplash equivalent of the houses you see in magazines: kitchens where the only items on the counter are decorative plus a basket of fruit or baked goods…

    Photo by Collov Home Design on Unsplash

    …living rooms where everything is white…

    Photo by Spacejoy on Unsplash

    …or tidy refrigerators full of fresh fruits and vegetables in matching containers.

    Photo by Ello on Unsplash

    The pristine pictures are of a fantasy world. If you’re living that dream, okay. But if your real life desk (or house) doesn’t match this fantasy,

    you

    have

    not

    failed.

    But do avoid putting your beverage behind your laptop. That advice is for real, y’all.

    What’s the state of your desk? Minimalist glory with all four items at right angles and a tiny low-maintenance plant? Chaotic sprawl including last night’s dishes (and not like “a plate and a fork” but like “every item you used to make last night’s lasagna including a 9″x13″ baking pan and a spatula”)?

    Most of all, is it working for you? Or is it time for a change?

    Originally posted 20 June 2022 on Medium.

  • Why Everyone Else Knows More Than You Do, and What To Do About It

    Why Everyone Else Knows More Than You Do, and What To Do About It

    The developers you work with know stuff that you don’t, and you know stuff that they don’t. Obvious, right?

    So why does it seem like everyone else knows more, and you’ll never catch up? Why does it seem like you’re a little kid on a tricycle, trying to pedal faster while the big kids zoom by on their bikes?

    This is how I feel sometimes. Not shown in photo: all the big kids on their big kid bikes. Photo by Tommy Bond on Unsplash

    The answer is that it’s true: everyone else you work with does know more — collectively. Taken all together, everyone else knows more than any one person does.

    The mistake you’re making is the subtle assumption that if one person in the group knows something, everyone else — or at least most people, other than you — must already know it too.

    Let’s say someone asks a networking question, and you don’t know the answer, but one of your colleagues does. Then you’re having trouble getting API authentication to work, and one of your colleagues advises. Another developer helps you with a thorny NodeJS issue. Someone else teaches you how to fix a build failure. And another colleague whips up a quick script to get you some data you need. After a while you start to worry if you are the least knowledgeable person in your group… your company… maybe ever.

    Everyone else is on their tricycles too

    Here’s what you’re not seeing: Your network-savvy colleague might have been the only person on the team who could field that question. It’s not true that just because one person knew that, everyone else did. Also, that network pro might not have a clue about API authentication, or Node, or build failures, or scripting.

    Even harder to see: you definitely know things others on your team don’t, and I’m not just talking about your bank account password or the name of the imaginary friend you had when you were little enough to ride an actual tricycle. You have job knowledge, industry knowledge, business knowledge that others around you do not.

    For many years, I had a hard time seeing this. I assumed that everyone around me must already know all the things I do, for some reason. But again, it’s not true that just because one person (you, in this case) knows something, everyone else does.

    The person who helped you with the API might not know React like you do. The developer who solved the Node issue might not write clean code like you do. The script-writing whiz might be totally lost if you start talking about code security.

    Sometimes you’re the big kid on the three-speed bike, and one or more of your colleagues are on their trikes, wishing they could zip around like you do.

    You can DO that?

    Years ago, I worked with an experienced developer named Nick. Knowledgeable, skilled, kind, thoughtful — Nick was a role model for me. He’d written a lot of the code for the application I was working on.

    One day, when I was still new to the team, we were in a staff meeting. The boss started talking about some technology I’d never even heard of. I was just a little kid on her tricycle, trying to keep up with the knowledgeable big kids, so I decided it was best not to interrupt the meeting to ask.

    I was making a note to myself to ask someone later, when Nick politely interrupted the boss and said:

    Photo by Marcos Luiz Photograph on Unsplash

    “I have no idea what you’re talking about. What is this?”

    Yep. In a room with some super-knowledgeable peers, Nick had just admitted to not knowing something. The world did not end. Nobody rolled their eyes, or hinted that Nick should know this already, or otherwise had any judgmental reaction. In fact, a few people looked relieved. I’m sure I was one of them.

    The boss apologized for getting ahead of himself and took a verbal step back to explain what he was talking about.

    You know, I don’t even remember what the technology was. I don’t think anyone even mentioned it again after that meeting. But, twelve years later, I remember being floored that someone who I thought “knew everything” could just state calmly, in front of his colleagues, that he didn’t know something.

    Ask, and ask publicly

    In that moment, I saw that it was part of the role of a lead developer to speak up and ask when you didn’t know something, because your newer colleagues might not have the courage yet. Since I wanted to be a lead developer, I was going to have to get used to speaking up.

    Photo by Brett Jordan on Unsplash

    Later, I saw that the pressure to appear knowledgeable is universal, no matter what your experience level. If you’re new, you might feel you have to prove to your team that you know what you’re doing. If you’re more experienced, you might feel like others will judge you for not knowing as much as they thought.

    Let’s smash the stigma around asking questions or asking for help. There’s no shame in not knowing something. The problem arises when you don’t take action to try to find out — either you don’t try at all; or you do try, but when you get stuck, you don’t ask for help.

    How do we smash the stigma? Ask questions, and ask in a way that others see it. I know, it’s less intimidating to message a trusted colleague privately. When you keep it quiet, you maintain the illusion for others that everyone around them knows everything. When you model the behavior of humbly asking for help, you teach others that it’s okay to do the same. When others start to join you, you’re changing the culture for the better.

    Photo by Mars Sector-6 on Unsplash

    Pro tip: modeling good behavior, teaching others, and changing the culture for the better are things leaders do. When you speak up, you’re not highlighting your weakness, you’re demonstrating your strength. No joke. My boss told me recently that one of the key factors in hiring me was that I was not afraid to ask questions.

    Furthermore, when you ask your questions publicly, others can benefit from the knowledge transferred. Someone else, when they encounter the same problem or question, will get stuck just like you did. When you ask in a more public way, everyone else benefits. When Nick asked our boss for more information during our staff meeting, the whole team learned.

    Change that culture

    So, raise your hand in that staff meeting, post that question to your team, or use (or establish!) a Slack channel specifically for developers across teams to ask questions and help each other out.

    When a colleague asks something you don’t know, add a comment that you’d like to know as well. They, and others, will see that they’re not the only one with that question.

    Photo by Randalyn Hill on Unsplash

    When a question comes through that you do know how to answer, share your knowledge! Some days, you’re the big kid on the bike, and someone else is calling out to you from their tricycle, trying to keep up.

    Above all, always be kind, regardless of the question or who is asking. A question might seem basic or obvious to you, it might be answered by a simple web search, it might be better asked in another forum, it might have been answered two days earlier in the same forum… it doesn’t matter. Be kind. Establish the norm that questions are always responded to with kindness and without judgment.

    That’s what a leader does.

    Do you feel like that little kid on the tricycle sometimes? What do you do to help the people around you feel more comfortable admitting when they don’t know and reaching out for help? Let me know in the comments.

    Originally posted 13 June 2022 on Medium.

  • Naming things, in spades

    Naming things, in spades

    Naming things is hard. One of the hardest things in computer science, as the saying goes.

    I once spent a full day trying to find the perfect name. Does that seem excessive? Well, consider these factors:

    • I was coding a major feature of the application. All users, whether they were customers or colleagues, would use whatever name I chose. It would even be an option on the main menu.
    • A large part of the codebase would also use the name. Developers would see it a lot.
    • I refused to choose an obscure name or a name so long that it would get abbreviated. Nobody should have to ask what it meant.
    • Many potential names were already in common use for related, but not identical, concepts. Some of those names would even appear on the same screens.

    I finally found the perfect name. We integrated it into the application design, the code, and the way we talked and thought about that feature.

    You know where this is going, don’t you…

    Many months later, we changed one of the tools we used as developers. The new tool used the same name for yet another related, but not identical, concept. 😭 After much agonizing, we changed the name of the feature, and I spent another full day updating every reference to it across the entire application and all of our documentation.

    So, as someone experienced in the sport of naming things, I can help. Let me make it easier for you.

    S

    That’s right… S.

    True story: I once spent hours trying to troubleshoot a program where all of the variables had single letter names. By the time I figured out how C, D, E, H, P, M, N, R, S, and W all fit together, I had forgotten what I was looking for and why.

    Also, it was causing a production issue, and it was several hours past my bedtime. I was groggy and desperately trying to fix everything before user traffic started to pick up in the early morning hours.

    Photo by Surendran MP on Unsplash

    “It seemed like a good idea at the time,” the code’s author said when I confronted him about it the next day. 😠

    Would it help to have comments telling you what C, D, E, H, P, M, N, R, S, and W all represent? Maybe, but sooner or later someone’s going to change the code without updating the comments, and then the outdated comments might actually make things more confusing.

    So, rule one: No single letter variables. Please and thank you.

    The only exception might be a small for loop where it’s clear that c or i is a simple counter, like this:

    for (let i = 0; i < 9; i++) ...

    Otherwise, please call a spade a spade, not an S.

    Say what you mean

    That said, info is not much better than i. Info about what? You can do better than that.

    92.84% of the time, adding info and data and details doesn’t contribute to the conversation. It’s okay for customer to refer to an object with all the details about the customer. You don’t need to call it customerDetails or customerInfo. Think of how much nicer it will look when you use dot notation: customer.firstName beats customerData.firstName.

    Granted, 7.something% of the time (I can’t be bothered to do the math on my made-up statistic), you won’t have a choice. You have to differentiate between customer and customerDetails, and there’s just no getting around it. You’ll know those times when you see them. Keep it simple until the code strong-arms you into doing otherwise.

    Rule two, then: call a spade a spade, not a digToolInfo.

    Someone using a digToolInfo to unsettle() some plantingSubstrate. (Photo by Anaya Katlego on Unsplash)

    Keep it short

    You don’t call the bank and ask “what is the current value of the total amount of money in my account?” You don’t call the bank at all these days, but that’s beside the point. You’d just ask: “what’s my balance?” No need to call it currentValueOfTheTotalAmountOfMoneyInTheAccount when it’s a balance.

    It might be a currentBalance if you need to distinguish it from some other kind of balance — previousBalance, maybe, or projectedBalance. If balance is just as clear, though, use it.

    How DO people get their bank balances these days, anyway? I log in to my bank website and look it up, but I bet by now that’s old school. Probably you record a video of yourself dancing to a song about your bank balance and post it to TikTok, and a bot from your bank will text you with the value and a relevant movie clip as commentary.

    Just checking that bank balance (Photo by Amanda Vick on Unsplash)

    Rule three: it isn’t acompactToolUsedForDiggingInOrderToPlantInTheGarden.

    Okay, I think you’re getting the idea. Call that spade a spade, and you’re good to go.

    Have you ever had to deal with code that just made no sense? Did you get angry at whoever wrote that garbage, only to look it up and find that you wrote it, six months prior? I feel you. Worst programmer ever is Me From The Past.

    Think of it this way instead: you’re so much better of a programmer now than you were six months ago! Learning and growing, that’s how you’re rocking it. Go you!

    Originally posted 30 May 2022 on Medium.

  • Recognize your wall

    Recognize your wall

    I’m not saying it’s time to go stare at the wall. Well, maybe I am.

    Maybe you’ve been firefighting most of the day, one urgent situation after another popping up like ads on top of a recipe blog. Perhaps it’s been an endless stream of meetings. Or maybe you’ve been working heads-down for hours (lucky you!), writing code for some huge project. Whatever the situation, it’s now late in the day, you’re dragging… but you’re trying to get “just one more thing” done before you dash out the door.

    Photo by Tim Gouw on Unsplash

    First of all, is it just me, or is there always “just one more thing” immediately after that “one more thing” you’re working on? An endless stream of what seem at the time like final tasks, each one inspiring the need for the next…

    Secondly, let’s take a good look at how well you’re accomplishing that “one more thing.” Mmm hmm.

    I can hear some of you now, saying, “Oh come on, I can totally code for 13 hours straight! My code at 8pm is just as good as my code at 8am.” I hear it because I’ve said similar things in the past. And I’m not here to suggest that you’re wrong. I mean, you’re probably wrong. But who knows, maybe your ability to code for long hours is truly exceptional. 🏅

    I am here to suggest that you start to learn the signals that tell you when you are simply Done Coding For The Day, regardless of what the clock says or how long you’ve been at it. In other words, learn how to recognize when you’ve hit a wall. Here are some warning signs to watch for.

    You’re forgetting stuff

    You spend an hour debugging your code, only to find out that you’d assigned a variable the value "INSERT_REAL_VALUE HERE" instead of the correct value. You meant to go look up said real value and add it before committing that code. You forgot. Looking up the value takes you 20 seconds. Well, there’s an hour you won’t get back.

    Or you send your boss an email about a spreadsheet, but you forget to attach the spreadsheet. You send a second email with the attachment, forgetting there are actually TWO spreadsheets you need to send. You send the second attachment. Two minutes later, you remember that you never added this morning’s data to the first spreadsheet…

    You’re making familiar mistakes

    Even though I’ve been using mostly JavaScript for several years now, other languages I’ve used sometimes still make an unwanted guest appearance.

    For example: when I, yet again, use contains() on an array in JavaScript. JavaScript, yet again, reminds me that it doesn’t know what I’m talking about. It’s includes() that I want, not contains().

    I have to look that up, every time. I had to look it up for this article. For me, the warning sign is not forgetting the function name. The warning sign is forgetting to go look up the function name.

    You’re making newbie mistakes

    If you’re a newbie, making newbie mistakes is normal! Nothing to see here. You can move on to the next section.

    If you’ve been in this field a while, though, and you’re catching yourself using = (assignment) when you mean === (strict equals), for example… it might be time to step away from the keyboard.

    You’ve gone way off course

    Your code worked fine at around 4pm. You were just trying to fix one little piece of one little unit test. Now it’s several hours later, and not only have you not fixed your unit test, you have broken your previously working code in a way you don’t understand. And in the course of trying to fix that, you accidentally changed something else, and now your application won’t even start on your branch. And in your flailing attempt to get the code on your branch to work, you inadvertently committed a bunch of code to an unrelated branch…

    When you are so far down in the pit of despair, my friend: stop digging.

    You literally can’t see 😫

    A comma where a semicolon ought to be. Missing quotation marks. A variable called employeeFirstName in one place and employeeFirstname 20 lines later. These things happen to us all now and then. But if “now and then” has turned into “three times in the past hour,” it’s time to give your eyes a rest.

    Someone at a laptop clutching their head, phone and glasses to one side
    Why do I get an error that customer-file-052122.json doesn’t exist?? I can see that customer-fle-052122.json is right there! (Photo by Elisa Ventur on Unsplash)

    Better late than never

    If you don’t catch yourself faltering in the moment, you might start to notice the results the next day. You can’t change the past, but this is still useful information for the future!

    Pay attention when, in the light of day, you see that all of your code from last night stinks. Or worse, your peers reviews your late-night pull request, and point out at length exactly what stinks about your code. Even worse, most or all of it involves basic mistakes you know you wouldn’t normally make.

    Water under the bridge, but start to connect a certain fuzzy-brained feeling on day 1 with the unpleasant results on day 2. You’ll begin to recognize what might have been signs for you last time, and thereby learn what might be signs for you next time.

    Regardless of whether you can make it through 13 hours straight of coding, or if you run out of steam much earlier than that, pay attention to what the warning signs are for you that things are going awry. You’ll save yourself a lot of stress by learning when it’s time for you to step back from the keyboard and go do something else — or go stare at the wall.

    Originally posted 23 May 2022 on Medium.

  • Something’s gotta give

    Something’s gotta give

    You’ve already got a full schedule when the boss asks you to take on a special project. Or maybe an urgent issue just jumped up above everything else you were planning to do this week. Or you’ve got multiple stakeholders, and all of them insist on being your “top priority”.

    Photo by JESHOOTS.COM on Unsplash

    Before you start canceling evening and weekend plans so you can spend even more time than you already do at work: stop.

    You only have so many hours in the week when you will be able to work effectively. And anyway, sacrificing your personal time might be necessary in a pinch, but it should be a rare occurrence. That time is yours!

    When you start to see that you’ve got more on your plate than you can handle and still deliver the high quality of work you’d like to be known for, here are some strategies to find balance.

    Something else is de-prioritized

    If you’ve got room for five projects in your week, and your manager just approached you with a sixth, inquire about which of the other five you should set aside to focus on the new project. It may be that when your manager realizes you have five important things already planned, that sixth one doesn’t seem so urgent after all. Or maybe they agree that #1 and #2 are still your top priorities, but #3 could wait for later, and this new project should take its place in your workload for the week.

    Someone else to the rescue

    If none of your current projects can be dropped, perhaps there’s someone else who can assist with the new assignment. Or perhaps you can shift one of your items to someone else’s to do list in order to allow you to pick up the newcomer.

    Be warned however that simply adding people is often not helpful. If a colleague is assigned to help you with one of your projects, but you are going to spend more time explaining the project to your colleague than you would spend just working on it yourself, this might not be the time-saver you expect. There are great reasons for working collaboratively, but short term time savings is not always one of them.

    Scale it back a bit

    Let’s say you learn that all six of these projects must get done, and they must all get done by you. Can the scope of any of these projects be scaled back to allow you to handle all of them? Perhaps the columns on the table you’re coding don’t need a sort option, after all. Or maybe you can just handle the “happy path” case for the new screen, the error handling pieces can be taken care of next week.

    Step up now, step back later

    In some situations, you might legitimately have a time crunch that can’t be avoided. There’s a hard deadline next week, and there’s nobody else available to pitch in. If that’s the case, you might choose to negotiate putting in some extra time now in exchange for a little extra time off after the deadline has passed — if you can trust that your management will keep that promise. A few late nights this week might be rough, but next week when you’re cutting out early on a sunny day or taking a morning off to relax, it might all be worth it.

    Estimating your work is part of your job

    It isn’t easy to say “no” (or even “not this week”) to management or other stakeholders. However, accurately estimating how much time a project needs is part of your role. Your boss might not be aware that the “simple” item you are coding will take several days, or that you need several hours of preparation time for that workshop you are leading on Thursday.

    For larger tasks, you might need to break it down into sub-estimates. Then, when your supervisor says “what do you mean that will take six weeks??” you can calmly explain how you arrived at that number to help them understand everything involved with the project. And again, if they say “but I need it done in three weeks,” you have options: drop other work, get some help, scale the project back, and so on.

    Think of it as your manager relying on you, as a professional, to let them know how much time you will need to complete your work. This can help make it a little less intimidating to speak up when the boss arrives to add more to your already packed to do list. And finally, more good news: this gets easier with practice!

    Originally posted 16 May 2022 on Medium.

  • Boredom is an interesting thing

    Boredom is an interesting thing

    Okay, you’ve put off that dreaded task long enough. Finally, you get to work, but the time just drags on. You’d like to get it over with, but it’s just so… boring.

    Ho hum. Photo by Priscilla Du Preez 🇨🇦 on Unsplash

    Yes, it’s true that we all have work now and then that we’re just plain stuck doing. Tedious chores that, whether we like it or not, need to get done, and need to get done by us.

    Just the same, take a closer look at what you’re working on. Maybe your boredom is trying to tell you something. Here are some questions to consider.

    Is it necessary?

    Are you bored because, on some level, you recognize that this just isn’t that important? Could you — or your stakeholder — do without?

    Take a moment to review why the task is important, and if you truly can’t identify a reason, maybe you can skip it. On the other hand, if you do see a valid reason for it, focusing on the purpose of the task might help relieve your boredom!

    Is it the right way?

    Perhaps you’re having a hard time getting rolling on this item because it’s not the right approach. For example, maybe you need to gather some data and analyze it, and you’re combing through a spreadsheet trying to pull out the information you want. Could you (or a colleague) instead write a script to pull the data you want out, rather than sifting through it by hand? Or is there a better way to get the data you’re looking for? Does someone else already have this data extracted?

    Is it yours?

    Maybe you’re not the right person to be doing this task. Can you delegate this to someone else who might not mind doing this? Or have you been asked to take on something that you feel is really someone else’s responsibility, and therefore this seems like a waste of your time?

    Is now the time?

    Are there other priorities right now that should be taking precedence? Could be that your boredom is trying to tell you that, as important as this task is, it isn’t your top priority right now. If you’re handling something at someone else’s request, perhaps you ought to check with them to confirm what their timeline is. It may be that they never intended for you to drop everything and do this now!

    Check in

    Checking in with yourself, a trusted colleague, your manager, or your stakeholder when you’re finding something especially boring might guide you to the root cause of your boredom, and from there you might spot another solution. Or it might give you new perspective on the task, or ideas to help you get through it.

    Has boredom been a “red flag” for you in the past? Are there other emotions or thoughts that act as a signal that it’s time for you to re-evaluate something?

    Originally posted 10 May 2022 on medium.