One Bad Day Means Nothing
A few weeks ago, I had a bad day at work. I was dealing with a bug that appeared completely intractable, and a deadline was looming. The longer I stared at my screen, the more opaque the bug seemed, and the more stressed I felt as the clock ticked onward. I stayed up past midnight, changing code, running and re-running tests, probably re-implementing the same faulty logic multiple times before finally giving up and closing my laptop, defeated. I felt incompetent and convinced that this was a sign that I wasn’t cut out for the field; I couldn’t even fix a simple bug! The next morning, I got up, looked at the code, fixed the bug, ran a successful test, and then sat down to berate myself for not having caught it in the literal hours I had wasted on it the day before. What happened yesterday?
This issue actually brought to mind advice that I was given in the context of another part of my life. I have been horseback riding for many years and spent a long time competing in show-jumping. One time I was having a lot of trouble during a training session with my coach. I kept “missing the distance”, show-jumping lingo for choosing a take-off point either too far from or too close to a fence, causing the horse to either take down a rail or refuse to jump.
After another failed attempt to clear the fence in question, I pulled up my horse in front of my coach, frustrated almost to the point of tears. I started off on a diatribe about my riding; how I’d never be ready for the next competition, I wasn’t improving, despite lots of training I was stumbling on the same problems I’d had years ago, et cetera, et cetera. My coach listened impassively and let me run out of steam before saying, “One bad day means nothing.”
What?
“One bad day in training means nothing. Two bad days means nothing. Three bad days? Three bad days means look for a pattern.”
While data engineering may not generally have a lot of overlap with show jumping, I think that the sentiment behind those words still resonates. It’s very easy to let a bad day at work creep into your mind and stoke the fire of self-doubt. Do you actually know what you are doing? Are you even capable of this job? Surely your coworkers must be perplexed as to why or how you were hired, and must be at this very moment gaping in disbelief at your most recent diff, calling all your other coworkers to gather around the monitor for a team-bonding laugh at your expense.
Except, well, not likely. The more reasonable explanation is that you’ve had a bad day. You’re tired, you’re distracted, you’re a little burned out from too much on your plate of late and for whatever reason, the “flow” that you need to solve that problem just… isn’t flowing today. An experienced athlete isn’t going to re-design their training regime because they had a bad day, and nor should you. If you can: file yourself a task for the next day, close the laptop, head outside for a walk and try again tomorrow. (To keep aligned with my show jumping analogue, this is the moment when you scale it back to a simple crossrail and then pat your horse and call it a day). If you can’t do that because of time sensitivity, then reach out to your team. Say, This needs to be addressed by this evening and I’m not coming to a solution. Can anyone provide a second set of eyes and help me to review? There’s a reason that companies hire teams rather than singular superstars: because even singular superstars have bad days, and then the pipeline fails in prod.
Now what if the problem persists? What if you’ve had a whole week of bad days — feeling overwhelmed, underwater, unhappy with the quality of your code? This is when you need to look for a pattern. What makes the last few days different from your (presumably better) day to day? Do you have a major project coming to a head, a massive migration ongoing that’s causing a lot of churn, a few coworkers out on vacation and everyone stretched thin to cover? Have you, personally, gotten less sleep, less exercise, have something external weighing on your mind? Is a new role or new project intimidating or overwhelming you? If you can identify an issue that’s common to all of the days you’ve struggled, you’ve taken the first step to fixing it.
Some of these things are unavoidable, and occasional weeks filled to the brim with last-minute product changes, hot fixes, and mysterious bugs are going to happen. When the scale tips more towards prioritizing speed over quality, I find it best whenever possible to set aside or delay tasks that demand quality, in favor of the tasks that need to be done ASAP to unblock. If a thoughtful pipeline refactoring was planned to start the same week as a massive feature launch is wrapping up, temper expectations by pushing out that start date and leave yourself free to focus on the hairy ad-hocs.
If, however, these kinds of issues are a repeating pattern — if every launch is a panicked scramble and every week has overlapping urgent priorities — then a more momentous shift will need to be made, and that involves talking to your manager to identify the root of the issue (understaffing, conflicting priorities, too-tight deadlines and the like) and making a plan to address it.
And what if the pattern you’ve identified shows a consistent personal weakness in a certain area? Are you delving into a new codebase and struggling? Are you having trouble collaborating with your coworkers or determining the logistics of a new project? I definitely don’t have all of the answers here, but I can share a personal anecdote (which everyone knows is just as good as the results of a rigorous scientific study):
Two years ago, I was working on a large project and was asked to design a feature for a new release of our project. Even during the initial meeting, I felt a sense of unease growing in me as the team discussed the functionality of said feature. It was going to use a technology stack I was unfamiliar with, it would have to integrate with a few of our existing features, and I’d be the sole engineer working on it. I had no idea how to start implementing. And so I… didn’t.
I distracted myself with smaller, more familiar tasks and continued working on my day-to-day. Occasionally, I would read through email threads discussing the new release and see reference to the feature — then nervously close out. I would get to it, uh, soon. By the next week, my lack of “getting to it” had blocked an engineer on another team, and he was pinging me frequently for status. My manager asked me how it was progressing and I had very little to report. I tried to read through documentation and felt directionless and frazzled: how and where was I supposed to apply this? By the time I’d officially had three bad days, there was an evident pattern emerging: I was so overwhelmed by the scope of the whole project, I couldn’t see where to begin.
Once I had admitted this, the solution began to reveal itself. Could I break the problem down into more manageable tasks? And I mean hella manageable: things like describing in words what the feature would do. Okay, great, now enumerate steps that describe what it will do. What do you need for each step? What already exists, and what will need to be written from scratch? What can I do on my own, and what will I need to consult a senior engineer for? Starting with this scaffolding turned what had seemed insurmountable into something wholly, uh, mountable. (And yes, the feature made it into the next release and it was beloved by users around the (semiconductor) world (maybe)).
In the past I have thought of my career as something that, on a daily level, should be steady state; I should be equally competent and productive from one day to the next. But I’ve come to realize that is not realistic in athletics, academics, or our careers. Some days you will crush everything and feel ready to take on the world. Other days you will struggle, and some weeks will feel like you are slogging through mud. My coach in horseback riding taught me not to over-index on any one day or any one mistake, but to try to identify underlying patterns that were causing consistent weaknesses or frustrations. Then, by tweaking my training program, I could start to replace those patterns and achieve better results. Applying this same methodology has helped me in my career so far. And whenever I finish a day feeling frustrated, drained, and convinced I don’t know what I’m doing, I try to remind myself: one bad day means nothing.
