It’s my turn for our team’s mini tech talk this week. You know the drill someone’s gotta bring a topic that’s interesting enough to keep people from checking social media halfway through.
I wanted to talk about something deeper than just tools or frameworks. Something that actually sticks.
Coincidentally, I’m in the middle of finishing Better Than Before by Gretchen Rubin, a book about mastering habits in everyday life.
And as I was reading it, something clicked: everything Rubin writes about habits how we form them, why we break them, how tiny changes compound applies frighteningly well to how we grow as engineers.
Think about it.
The way we review pull requests, plan features, pick up new frameworks, or avoid touching that legacy module it’s all habit.
We often mistake skill for experience, but the truth is, what really defines a great engineer is how they build repeatable patterns of improvement.
“What we do every day matters more than what we do once in a while.” — Gretchen Rubin
So, instead of another deep dive into architecture patterns or the latest AI framework, I thought why not talk about the habits that actually make us better engineers in this harsh, demanding tech world?
This article isn’t about “hustling harder.” The industry already worships at that altar.
It’s about designing better engineering habits using Rubin’s five strategies:
Scheduling, First Steps, The Lightning Bolt, Monitoring, and The One Coin Loophole.
These are ideas from psychology and behavior science, reframed for the engineer who wants to build long-term mastery not burnout.
The Engineering Grind Loop
Most engineers don’t burn out because they’re lazy.
They burn out because they’re always on.
Every sprint bleeds into the next.
Meetings stretch into “just one more task.”
Even after shipping, our brains won’t stop benchmarking themselves against someone else’s Git activity.
We live inside the machine and the machine never sleeps.
The modern engineering world quietly worships hustle culture.
It’s the unspoken rule that your value equals your output.
We glorify the developer who fixes bugs at midnight, the architect who “lives and breathes code,” the founder who hasn’t taken a weekend in years.
It sounds noble until it becomes noise.
Every podcast, every tweet, every LinkedIn post tells us to optimize ourselves more.
Ship faster. Learn Rust. Write threads. Publish side projects.
It’s an infinite feedback loop of performance disguised as growth.
But like any overloaded system, it eventually collapses.
We try to fix it the way we fix everything else: with optimization.
We buy new apps, reorganize Notion boards, experiment with productivity frameworks like they’re new libraries to import.
For a while, it works. Then entropy takes over.
“Habits are the invisible architecture of daily life.” — Gretchen Rubin
That line hit me hard.
Because in engineering, architecture is everything and most of us are building our days on fragile, undocumented systems.
We keep pushing hotfixes into our routines instead of designing them properly.
We don’t test. We don’t monitor. And eventually, the system crashes.
Hustle culture tells us the fix is to run faster.
But the real fix is to redesign the system itself.
The world won’t slow down frameworks will keep updating, expectations will keep rising.
So the question isn’t how do I keep up?
It’s how do I build habits that keep me stable while everything else moves fast?
That’s where Rubin’s strategies come in not as motivational fluff, but as genuine design patterns for the self.
Because if you can design reliable systems for distributed microservices, you can design one for your own well-being too.
Strategy 1: The Power of Scheduling, Build Rituals Like Cron Jobs
The first strategy Rubin talks about is scheduling, the simple act of deciding when you’ll do something, instead of endlessly debating whether to do it.
Sounds basic, right?
But that tiny shift changes everything.
In code, once you automate a process say a nightly build or a deployment you stop thinking about it. It just happens.
Scheduling habits works the same way.
Once something is on the calendar, your brain stops negotiating with itself.
No more internal debates like “Should I learn that new framework tonight?” or “Maybe I’ll refactor later.”
You’ve already made the decision once the system will execute it
“We can build habits by deciding not to decide.” — Gretchen Rubin
That’s why the best engineers I know don’t rely on bursts of motivation.
They rely on rituals.
A fixed morning slot for learning.
A Friday hour blocked for cleaning up tech debt.
A recurring calendar reminder for journaling ideas or documenting architecture.
At first, these feel rigid. But in reality, they create freedom the same kind you get when automation removes repetitive tasks.
Because if every decision costs energy, scheduling is how you write a scheduler for your life.
⚡ Practical Takeaway for Engineers
Start small. Don’t build a new system overnight.
Just pick one recurring thing that matters and automate it.
Maybe it’s a 15-minute slot to review your pull requests, or to read docs before daily stand-up.
Make it non-negotiable.
Make it boring.
That’s the point.
Once it runs smoothly, it becomes part of your mental infrastructure reliable, predictable, and beautifully unremarkable.
That’s what a real habit looks like.
Section 2: The First Step Start Small, Ship Something
One of Gretchen Rubin’s most deceptively simple ideas is The Strategy of the First Step.
To begin a habit, you just need to begin. Not plan, not research tools for three days, not color-code a Notion board just start.
As engineers, we’re world-class at avoiding first steps.
We tell ourselves we’re “setting up the architecture” or “exploring options,” but half the time, we’re just over-preparing. Our brains crave the illusion of progress instead of the discomfort of actually building.
“The first step is small but once taken, it creates its own energy.” — Better Than Before
That’s exactly what pushed me to create my own build logic repository:
👉🏻 [sjy-build-logic](https://github.com/Sanjaya-Inc/sjy-build-logic).
For years, I noticed how much friction existed every time I started a new Android project. Reconfiguring Gradle files. Re-adding dependencies I always use. Re-tweaking project structures. Each time, the real first step actually writing code got delayed behind repetitive setup.
So I built my own starting point.
The repo now contains everything I usually need: dependency catalogs, Android Studio templates, project configurations from compile SDK to test frameworks all the boring parts automated.
Now, spinning up a new project isn’t a mental mountain. It’s one command, and I’m straight into momentum mode.
But here’s the best part: it updates itself.
Whenever the frameworks evolve or new stable versions drop, the setup refreshes automatically using dependabot. That means I don’t waste energy keeping up I just start coding, always on the latest stack.
That’s what Rubin means by mastering the first step: make it so easy, you can’t not start.
It’s not about removing effort it’s about removing resistance.
In an industry that glorifies “10x speed” and “hustle harder,” it’s easy to overlook the quiet power of small beginnings.
But the truth is, mastery rarely starts with a grand launch. It starts with a repo, a file, a function and the courage to make it exist.
Section 3: The Lightning Bolt When Change Hits You Hard
Every once in a while, something hits you so clearly that it changes how you work forever. Gretchen Rubin calls this The Strategy of the Lightning Bolt a sudden moment of insight that makes a new habit not just appealing, but inevitable.
We’ve all felt it as engineers.
That late-night realization that the architecture you’ve been defending is actually holding the team back.
That one tech talk that makes you rethink how you’ve been testing.
Or that single line in a pull request comment that rewires your entire approach to clean code.
For me, one of those lightning-bolt moments was realizing how much friction was silently draining my creativity. I’d spend more time fighting boilerplate and build errors than building ideas.
That’s what led me to systemize my own tooling, automate setup, and ultimately create sjy-build-logic.
But this time, the motivation didn’t come from planning it came from frustration. And frustration, when channeled right, can be lightning in a bottle.
“Some changes are gradual, but others happen in a flash when we’re struck by a powerful insight that alters everything.” — Better Than Before
The Lightning Bolt is rare, but when it strikes, it rewrites the rules of your game. It’s the spark behind every great open-source project, every bold refactor, every side project that suddenly consumes your weekend in the best way.
In a culture that romanticizes grind, we sometimes forget how valuable these moments of emotional clarity are.
You can’t schedule them. You can’t automate them. But you can recognize them and when they come, act fast before the feeling fades.
Because the truth is, change doesn’t always require discipline. Sometimes it just requires electricity and the courage to follow it.
Section 4: Monitoring Debug Yourself Like Production Code
After a Lightning Bolt moment, motivation surges but it never lasts forever. That’s where Gretchen Rubin’s Strategy of Monitoring steps in. She writes that “we manage what we monitor.”
And honestly, no group understands that better than engineers.
When something’s in production, we don’t just hope it behaves well we instrument it, observe it, and set up alerts. We track uptime, latency, user engagement, crash rates.
But when it comes to ourselves our learning pace, our focus, our burnout risk we often fly blind.
We forget that we are the system.
“Self-knowledge is the foundation of habit change.” — Better Than Before
That realization hit me when I noticed I was constantly jumping between projects, convinced I was being “productive.” In truth, I was context-switching myself into exhaustion.
So, I started debugging my own patterns. I tracked when I wrote my best code (mornings), when I got distracted (afternoons), and how often I overcommitted (always).
Eventually, I began treating my workflow like an observability problem.
Just like I’d analyze logs or performance metrics, I’d note down how long tasks actually took compared to how long I thought they would.
Turns out, my mental estimates were off by a consistent 30–40%. Once I saw the data, it stopped being personal it became debuggable.
The beautiful thing about monitoring is that it removes judgment.
You don’t need to guilt-trip yourself for being tired or slow you just read the logs and optimize.
That mindset shift alone changed everything. My calendar became a dashboard, not a to-do list. My progress stopped being about emotion and started being about evidence.
In engineering, we love to say “if you can’t measure it, you can’t improve it.”
That’s true for code and even truer for ourselves.
Section 5: The One Coin Loophole When “Just Once” Becomes a Bug
Gretchen Rubin tells a story about a man who kept adding coins to a jar every day.
One coin alone meant nothing but over time, it made him rich.
The flip side is just as true: skipping “just one coin” doesn’t seem like a big deal… until it becomes a habit of exceptions.
She calls this The One Coin Loophole our tendency to tell ourselves that one small deviation doesn’t matter.
Engineers know how that story ends.
Because “just once” is how production bugs are born.
“What we do ‘just this once,’ we often do again and again.” — Better Than Before
We see it all the time:
- “I’ll skip writing this test, just this once.”
- “I’ll push directly to main, just this once.”
- “I’ll skip the code review it’s urgent.”
It’s innocent, even logical in the moment. But the cost compounds quietly, like technical debt disguised as efficiency.
The danger isn’t the exception it’s the normalization of it.
I’ve seen this play out not just in code, but in habits too.
Skip one personal retrospective. Miss one refactor sprint. Delay one cleanup task. Suddenly, the system you built to keep yourself sharp starts drifting out of sync.
And like any complex system, once entropy sets in, recovery takes far more effort than maintenance ever did.
That’s why I treat my own process like a living codebase.
When I catch myself saying “just this once,” I pause and ask:
Would I accept this logic in production?
Most of the time, the answer’s obvious.
The One Coin Loophole isn’t about guilt it’s about awareness. It’s the reminder that consistency, not intensity, defines growth.
Habits, like systems, thrive on small correctnesses tiny acts of integrity repeated long enough to become invisible.
And that’s how good engineers become great ones.
Not by doing everything perfectly, but by refusing to let “just once” become “every time.”
Closing: Building Momentum, Not Just Code
At the end of the day, growth isn’t about doing more things it’s about removing the friction between you and momentum. For me, that’s exactly why I built [**sjy-build-logic**](https://github.com/Sanjaya-Inc/sjy-build-logic).
It’s not just another Gradle setup. It’s a living foundation a repository that evolves automatically, preloaded with every dependency, Android Studio template, and project configuration I rely on daily. It means when an idea strikes, I don’t waste energy wiring things up I just create, run, and iterate.
Every engineer needs their own version of this: a launchpad that eliminates hesitation and keeps you focused on building things that matter. Because once you remove the friction, consistency follows naturally and that’s where mastery begins.
References:
Better Than Before: Mastering the Habits of Our Everyday Lives — Gretchen Rubin
📚 Originally published on Medium.
💬 I also share free mentoring sessions on ADPList.
🚀 Let’s connect and talk about Android, Kotlin, and building great systems together!
Top comments (1)
This is such a sharp observation. The real danger isn’t breaking a rule, it’s teaching yourself that it’s okay. “Just once” feels harmless, but it quietly rewrites our standards🤩