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?
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
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.)
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:
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:
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.
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.
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:
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…
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?
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:
“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.
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.
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.
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.
When I first learned about APIs, all I ever heard for a definition was what the letters stood for: Application Programming Interface. As if that told me anything useful.
The only “what it stands for” that I’ve found less useful was learning what REST stands for, as in “REST APIs”. That expansion is so useless to me that I’m not even going to share it here.
If you didn’t know REST, did you go look it up? Am I right or what??
An interface is an agreement
So what is an Application Programming Interface? Let’s start with the “interface” part. When you hear that word, think “agreement”.
You have an agreement with your microwave. When you press ‘3’ and ‘0’ and ‘Start’, your microwave will respond in a predictable way: it will start heating your food and maybe spin a carousel, it will display a countdown timer for 30 seconds, and it will beep when the time’s up.
This agreement, and the keyboard (and display and beeping) that let it be executed, are the interface. Specifically, this is a user interface, because you are the user of the microwave.
So far, so good?
The programmer’s agreement
Now, let’s say you have an app on your mobile device that lets you control your microwave. I don’t know why you’d want to do this. This sounds like a recipe for overcooked food, or a mess splattered all over your microwave. But let’s say that’s what you have.
Just going to heat up my coffee… from the next room. (Photo by Paul Hanaoka on Unsplash)
You now press ‘3’ and ‘0’ and ‘Start’ on your phone, and your microwave responds. There’s still a user interface here — the interface between you and the phone is the user interface.
But there’s also another interface here: between the mobile app and the microwave. There’s an agreement between the developers of the mobile app and the developers of the microwave: when the app sends data in a specific format to the microwave, the microwave will do stuff, and maybe even send some data back to the mobile app when it’s done.
That’s not a user interface, between the app and the microwave. That’s a programming interface… an application programming interface. An API.
Is it “an API” or “APIs”?
One more thing to know: people play fast and loose with the term “API”. It is used to refer to the overall interface between two systems. It can also be used to refer to a specific subset of the interface, which could also be called an endpoint: maybe the microwave has a “cook” API, a “set timer” API, and a “toggle light” API for that light I always wish was brighter when I’m standing at the stove making dinner. And these APIs are part of the larger API. 🙃
In case that wasn’t enough, a server that provides the API might also be called an API. As in: “the microwave API [server] is down, so the APIs [the actual endpoints] aren’t responding, and the app won’t work.” Fortunately, you can usually figure it out from context.
Did this clarify things for you? Do you have a real world use case for the ability to microwave something while not physically present in front of the microwave? What other abbreviations do you know where just knowing what the letters stood for didn’t help much at all in understanding what it means? And shout out any good resources you know for understanding what REST APIs actually are!
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.
“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.
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!
I have been importing blog posts from my previous blog at Medium, and I keep losing track of the steps.
And often, when I want to document something for myself, it’s my habit to document it for anyone else who has the same question…
This is exactly what my blog post checklist will look like. I mean, the checklist below — not the ink-on-graph-paper. But graph paper’s cool too. Photo by Glenn Carstens-Peters on Unsplash
While writing the post
Catchy but short title? (Sometimes I go for an entertainingly long title instead.)
At least one interesting image?
Caption your image(s)? Unsplash doesn’t require an attribution, but I like to add one.
Got sub-headings?
Review: brevity, passive voice
At the end of the post
A short note to sum up
If you’re importing from Medium, did you mention that? “Originally posted [date] on Medium.”
Add the Medium link?
Is it long enough that you kinda wanna add a second photo?
Metadata
(I’m using WordPress, the metadata is all the stuff on the right hand side under “Post”.)
Set featured image?
URL slug? (This one is “blog-post-checklist” which is okay)
Discussion – open or closed?
Categories?
Tags?
Note
I wanted my posts to have a featured image that will appear on the Posts page, but not appear twice in the article. However, barring any customization, setting a featured image that is already in my post will make it appear twice: once at the top where I don’t want it, and once where I put it.
Fortunately, I was able to figure that out:
Appearance > Editor
Click anywhere on the page to make the toolbar appear
Click the black and white circle icon for Styles in the upper right
Select the vertical “…” and choose Additional CSS
Add the following, Save, and refresh your browser
.wp-block-post-featured-image {
display: none;
}
And so…
Here’s the aforementioned “short note to sum up.”
Did this checklist actually prove to be useful to anyone else other than me? Drop a note here if you used it.
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.
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.
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.
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”.
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!
