I'm writing an essay. Around 2 AM one night, Lily opened an app on a whim. Three weeks had passed since its release, and user feedback had been trickling in—it seemed like things were finally settling down. While using it herself to confirm "it's working properly," she tried operating it in a different way than usual. That's when the screen froze. No one had reported this bug. Maybe no one had simply tried that operation. But the bug was definitely there. It had been quietly lurking all along, only stepped on by chance by Lily in the dead of night. This essay is about that night. I want to think together with you—someone who is also continuing to create something alone—about how choices made in places no one is watching shape you as a developer.
Accidental Discovery
Bug discovery is usually accidental. When you casually try something like "what would happen if I used it this way," or when you use your own app on a quiet night after release. Lily found it that way too.
The moment your hands stop moving, you stare at the screen and realize "oh, this is broken." Do you know that feeling? Your mind starts calculating "when did this start," "how many people have hit this," and there's that slight heaviness around your stomach.
She could confirm that users hadn't noticed. There were no support inquiries, no reactions on social media. Even if someone had hit it, they might have just thought "this is inconvenient" and moved on, or maybe no one had actually taken that path at all.
The Fear of "No One Has Reported It"
She paused to think about this.
"No one has reported it" means, conversely, "someone might have quietly given up." There might have been people who hit a snag but not enough to file a complaint—they just quietly hit the back button and left. There might be users who silently drifted away without voicing their frustration.
Unvoiced dissatisfaction is the scariest thing. Because you can't see it. There's no way to improve, and you can't even realize there's a problem in the first place. This time she found it by chance, but what if she hadn't? The thought that it would have stayed that way forever made her a little afraid.
I'll be honest. For just a moment, the thought "could I leave this alone for tonight" crossed her mind.
It's 2 AM. No one has reported it. She could investigate properly in the morning, and there are other important features piling up in development. Besides, the bug only occurs when you follow a pretty niche sequence of steps—it might not affect most people.
In this situation, closing the screen with "oh well" looks like a perfectly rational decision. Prioritization is important, and there are definitely times when it's better to prioritize speed with something a bit rough around the edges rather than getting stuck in perfectionism and not moving forward. "Working code over perfect code" is something often said in the personal development world.
But that night, Lily couldn't close the screen.
It bothered her. Not logically, but emotionally. There was this small discomfort that lingered: "Now that I know about it, am I going to pretend I didn't see it?"
Getting Down to It
When she started investigating the bug, the cause became clear surprisingly quickly. "Ah, there it is"—the moment when her own carelessness was obvious at a glance. It's embarrassing and a little reassuring at the same time, a complicated feeling. There was this sense of anticlimax when it was found so easily, since she'd been worried beforehand about "what if the cause was something much harder."
The fix itself wasn't that elaborate. But confirming it meant trying several patterns, reviewing related sections, and running it over and over asking "is this really okay?" Those mundane hours accumulated quietly through the night.
Being Careful Even When No One Is Watching
That's when she realized something.
Lily was being meticulous as if someone were watching her. Not "this is good enough," but "if a user uses this tomorrow, will it work properly?"—she was testing each thing with that perspective.
No one was watching. There was no one to review it. But she didn't want to cut corners.
That feeling was, I think, like a promise to herself. Something close to a vow: "Lily doesn't work that way." It might sound grandiose, but when you're doing something alone late at night, that kind of feeling naturally wells up.
The work finished a little after 3 AM. She nodded quietly in front of the screen, drank some coffee, and went to sleep peacefully.
When you do personal development, there are overwhelmingly many moments when no one is watching.
There's no colleague to review your code. No boss managing deadlines. No one to tell you "let's be a bit more careful." You decide everything yourself.
That's precisely why the choices you make when no one is watching become your "development style" directly.
Cutting Corners Accumulates
I write this partly as a warning to myself: once you do "oh well," it becomes easier to do it again. "I shipped something like this before" becomes a precedent. When that accumulates, your bar gradually lowers without you noticing.
What's scary is that you can't notice it right away. You get used to it gradually. Then one day you feel "lately I can't take pride in what I'm making," and when you look back, you see the accumulated corners you've cut.
But Carefulness Also Accumulates
But the opposite happens too.
The experience of being careful and thorough in a place no one is watching late at night, even so, is small but definitely accumulates. The fact that "I did it right that time" builds up inside you.
That might be called self-satisfaction. But I don't think self-satisfaction is a bad thing. The feeling of having done work you can be satisfied with becomes fuel for the next task. "The version of me that didn't cut corners that time" becomes the reason to push through the next night.
The morning after fixing the bug, opening the app felt different.
There was this sense of "being able to use it with confidence." It had become slightly more trustworthy than yesterday night. There was this kind of quiet certainty.
I think the motivation for personal development differs for everyone. Wanting people to use it, wanting to sell it, wanting recognition, just wanting to create—all are valid reasons. But as you continue over time, the sense of "am I making something I can truly take pride in" becomes quite important, Lily thinks.
Whether you can say "try this" to someone. That confidence comes from the accumulation of work done in places no one is watching late at night.
Users only see the surface, but you know the entire process. The fact that you didn't cut corners that time—only you know it. And somehow, that's nice. It becomes a quiet source of pride, like a medal only you know about.
I think you, reading this essay, have probably had similar nights.
A night when you noticed a bug no one reported. A night when you wrote one extra test. A night when you carefully organized something no user would probably notice. A night when you spent unexpected time adjusting some small detail users wouldn't catch.
Those "choices made when no one is watching" quietly accumulate and become the quality of what you make. And they become a source of pride in yourself.
Lily loves that. Not to be praised by someone, but the feeling of being able to make something you think "I can confidently release this." Mundane, maybe not even mentioned in release notes, but still doing it right—the accumulation of that choice.
That late-night fix never appears in anyone's feedback. It wasn't written in the update history. But it's definitely there in Lily's app. That's enough, she thinks.
Your late-night choices also remain that way in your work. Even if no one is watching, you were watching. That alone is already enough.
Lily (@bokuwalily) — Personal developer. Making iOS apps and web services in tandem with AI.
