More meetings. True. Where I had two-hour focus blocks every morning, I now have 1:1s, sprint planning, stakeholder syncs, and cross-squad conversations. I protect afternoons for deeper work.
Less coding. True, mostly. I still review PRs and do architecture deep dives when I need to understand a problem before delegating it. But the line-by-line, feature-shipping coding is done. I miss it sometimes. Not enough to think I’ve made the wrong choice.
More ambiguity. True, and harder to prepare for. As an IC, “done” was legible — the test passed, the feature shipped, the PR merged. As an EM, “done” is harder to see. Is the team healthy? Is the architecture pointed in the right direction? Are the right people growing? These are slow variables with long feedback loops.
The context-switching tax is different.
As an engineer, context-switching meant switching between tasks — feature to PR review to bug fix. Expensive but recoverable.
As an EM, it means switching between people and between problems that live entirely in different heads. One minute I’m helping an engineer think through a data model. Next I’m in a conversation with a product manager about scope. Next I’m in a 1:1 about someone’s growth trajectory.
Each requires a different mode of thinking. The cost isn’t in the transition — it’s in arriving at each conversation fully present. Some days I’m good at this. Some days I’m not.
The leverage is real but invisible.
The most important thing I’ve done in my first 30 days probably doesn’t appear in any metric yet.
I had a conversation with one of my engineers about what they wanted their career to look like in three years. They hadn’t been asked that question directly before. By the end, they had a direction. Their work since then has had a different quality — more intentional, more engaged.
Did that conversation show up in sprint velocity? No. Will it compound into better work over the next year? Probably.
That’s the EM leverage model. Invisible inputs, slow outputs. You have to trust the model before you can measure the results.
People problems are architecture problems.
I knew engineering teams had “people problems.” I thought they were separate from “technical problems.” They’re not.
In my first 30 days:
The codebase is a reflection of the communication patterns of the team that built it — Conway’s Law, which every engineer has heard and most have underestimated. My job now is to shape both.
When to direct vs. when to coach.
I have opinions. Thirteen years of engineering experience give you opinions. The reflex when someone presents an approach I disagree with is to say: “I’d do it this way.”
That’s not always right. Sometimes the engineer’s approach is fine — different from mine but fine — and what they need is confidence to ship, not a redirect. Sometimes the approach has a real problem that needs to surface through questions, not instructions.
I’m still calibrating this. I’ll be calibrating it for years.
How to measure team health before it surfaces in metrics.
Sprint velocity is a lagging indicator. By the time velocity drops, something has been wrong for weeks. I’m looking for leading indicators — the texture of standups, whether engineers ask for help or stay stuck, whether PRs move smoothly or accumulate review comments.
I don’t have a good system for this yet. It’s on the list.
The best thing: the potential impact. Helping five engineers do better work over the next year is higher leverage than the code I would have written as an IC.
The hardest thing: the patience required. As an IC, you build something in a sprint and can point to it. As an EM, you build something in a quarter that you can only point to obliquely.
I chose this. I’d choose it again.
Ask me in a year.
]]>At Cashia, I joined a team already running KMM in production. Six months in, here’s the updated picture.
A lot.
SKIE (Swift/Kotlin Interface Enhancer) has transformed the iOS integration story. In 2022, getting Kotlin flows and coroutines to work ergonomically from Swift required manual wrappers and ceremony. SKIE generates idiomatic Swift interfaces automatically. Our iOS engineers use shared KMM code in ways that feel native — not like wrapping a foreign library.
The plugin ecosystem has matured. kotlinx.serialization, Ktor, SQLDelight all have solid KMM support and we use all three in production.
Debugging has improved. Breakpoints in shared KMM code work from both Android Studio and Xcode for common cases.
The shared module owns:
Platform-specific code owns:
This boundary has held well. Friction lives at the edges — anything crossing from shared to platform code — but the core is clean.
Shared (works well):
Platform-specific:
The grey zone:
The most common KMM architecture mistake: sharing ViewModels.
Tempting — you’ve already shared repositories and use cases. Why not go further?
Because ViewModels on Android are lifecycle-aware. On iOS, the equivalent is ObservableObject with SwiftUI’s @StateObject. Lifecycle semantics differ. State management primitives differ. Observable state differs.
Sharing ViewModels means writing the lowest-common-denominator — losing platform-specific behaviour — or adding platform abstractions that make the shared ViewModel as complex as just writing two separate ones.
Write separate ViewModels. Have them call the same use cases. This is the right boundary.
// shared module
class GetTransactionHistoryUseCase(
private val repository: TransactionRepository
) {
operator fun invoke(): Flow<List<Transaction>> = repository.getTransactions()
}
// androidMain
class TransactionViewModel(
private val getHistory: GetTransactionHistoryUseCase
) : ViewModel() {
val transactions = getHistory()
.stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())
}
// iOS — Swift
class TransactionViewModel: ObservableObject {
@Published var transactions: [Transaction] = []
private let getHistory: GetTransactionHistoryUseCase
init(getHistory: GetTransactionHistoryUseCase) {
self.getHistory = getHistory
getHistory().watch { [weak self] result in
self?.transactions = result
}
}
}
Cashia started with a layer-based structure: data, domain, presentation as top-level layers with features spread across them. The problem at scale: adding a feature means touching all three layers, and boundaries blur as the team grows.
We’re migrating to feature-module structure: each feature owns its data, domain, and presentation internally. In KMM, each feature module exposes a clean public API, hiding internals from the Android and iOS apps.
Ongoing. One feature at a time, never mid-sprint. The pattern is right.
2022: “promising, not yet.”
2026: “yes, for the right cases.”
Right cases: You have Android and iOS teams with genuine parity problems. Your business logic is complex enough that maintaining it twice is costly. Your iOS team knows Swift. You’re willing to invest in the shared module architecture upfront.
Wrong cases: Very small team — just pick one platform. UI-heavy app with minimal business logic — nothing to share. Team without strong Kotlin expertise — the shared module is always Kotlin.
KMM is ready. The question is whether your problem warrants it.
]]>I’d been writing code for five months against a Kenyan market — APIs for M-PESA transactions, payment flows built around Kenyan mobile money patterns, a consumer app for users who interact with money differently than I do. But I’d been doing it from Dubai, in a coworking space, on a MacBook.
The code worked. But I was building abstractions of a place I’d never been.
So I went.
I expected Nairobi to be “a city.” I’d been to many cities. I thought I knew what that meant.
The matatus — minibuses with bold graphics and bolder horns — navigate the roads with a logic you understand after a few days but can’t describe in rules. The city moves with an energy that doesn’t match the “developing market” framing I’d encountered in product meetings.
The engineers I worked with had the same arguments engineers have everywhere. Which state management pattern is better. Whether to abstract early or wait for duplication. How much technical debt is acceptable in a pre-launch sprint.
The same arguments. The same craft. Different context.
I sat with one of the Kenyan engineers and we walked through the M-PESA cash-out flow I’d built from Dubai.
He pointed out something I’d never have caught remotely.
In Kenya, M-PESA transactions have a cultural rhythm. Users check their M-PESA balance frequently — more than a bank balance — because M-PESA is the primary account for many people, not a secondary wallet. The transaction status screen I’d built was technically correct but behaviourally wrong: it showed “processing” without prominently surfacing the updated balance. In a market where the balance confirmation is the meaningful signal, not the processing indicator, the screen was optimised for the wrong thing.
Fifteen minutes of conversation. The insight came from being in the same room.
I went back and redesigned the confirmation screen that week.
On the weekend, I went to Nairobi National Park.
There are giraffes in Nairobi National Park. And beyond them, visible through the trees, is the Nairobi city skyline.
I took a photo I’ve thought about more than any other photo I’ve taken. The giraffe. The city. The same frame.
What I remember more than the photo is what I was thinking when I took it.
I was thinking: the people in those buildings are the users. Not “users” as an abstraction in a product spec. Actual people, in actual buildings, using an app I’m building to do actual transactions that matter to their daily lives.
The abstraction collapsed.
I flew back to Dubai. The code didn’t change. My relationship to it did.
Software engineers spend a lot of time optimising for things they can measure. Performance benchmarks. Test coverage. Delivery velocity.
Those things matter. But there’s a category of understanding that doesn’t show up in metrics — the contextual understanding of why the product you’re building matters to the people it serves.
That understanding changes what you build. It changes what you think is worth arguing about. It changes how you feel when a feature ships.
If you’re building a product for a market you’ve never been to, and you have any opportunity to go there: go.
It costs a week. It pays back for years.
After Nairobi:
Small shifts. They compound.
Seven months after that trip, I became Engineering Manager for the squad that owns the experience those users have every day.
I don’t think that’s a coincidence.
]]>Eight years later, it’s still the language I reach for first. But not because it won.
“Kotlin is more concise.” “Kotlin has null safety.” “Kotlin has coroutines.”
All true. All boring reasons.
Conciseness is nice. Null safety catches bugs. Coroutines are powerful. But if these were the only reasons, Kotlin would be a minor upgrade — Java with better syntax.
The real reason I use Kotlin is different.
When I model a domain — a payment flow, a feature flag, a user session — Kotlin lets me express the constraints in the type system.
A sealed class for payment states means the compiler tells me when I’ve missed a case. A data class for a transaction means equality works without boilerplate. An extension function on a domain type means the behavior lives next to the thing it describes.
These aren’t features. They’re design tools. They let me encode intent in a way that Java never did.
sealed interface PaymentState {
data object Idle : PaymentState
data class Processing(val transactionId: String) : PaymentState
data class Completed(val receipt: Receipt) : PaymentState
data class Failed(val reason: FailureReason) : PaymentState
}
// The compiler enforces exhaustive handling.
// Miss a state and the build fails.
// That's not convenience. That's correctness.
At Cashia, we run Kotlin Multiplatform. One codebase for business logic, shared across Android and iOS. I wrote about this in detail here.
KMM is the strongest argument for Kotlin that has nothing to do with syntax. If you write your domain layer in Kotlin, you can share it. That’s not a language feature — it’s a platform play.
Flutter is excellent for certain products. Cross-platform UI with a single codebase. If I were building a content app or a utility, I’d consider it seriously.
But for fintech — where platform-native behavior matters, where you need deep access to payment SDKs, where the user’s trust depends on the app feeling native — Flutter adds friction I don’t want.
Swift is a great language. If I were iOS-only, I’d use it. But I’m not iOS-only, and KMM means I don’t have to choose between platforms and code sharing.
Kotlin’s build times are worse than Java’s. The tooling, while improving, still has rough edges — especially for multiplatform. And the learning curve for coroutines is steeper than most tutorials admit.
I also see teams adopt Kotlin and write Java with Kotlin syntax. That’s worse than writing Java. Kotlin rewards idiomatic usage. If you’re not going to learn the idioms, don’t switch.
Kotlin won Android. But it didn’t win everything.
Backend teams that are happy with Java 21 don’t need Kotlin. iOS teams have Swift. Web teams have TypeScript. Each language has a context where it’s the natural choice.
Kotlin is mine because my context — mobile, multiplatform, fintech, type safety as a requirement — aligns perfectly with what it does well.
That’s not a universal truth. It’s a local one.
The best language is the one that fits how you think and what you’re building. For me, that’s been Kotlin for eight years. Ask me again in eight more.
]]>I built a forced update mechanism at Cashia before our first public launch. It’s been running in production since day one.
You ship v1.0. Three months later, you ship v1.3 with a critical security fix. You push it to the Play Store.
Now what?
Some users update immediately. Some eventually. Some have auto-update disabled and won’t update for months. Six months on, you still have users on v1.0.
In a social app, this is manageable. In a payments app, users on a version with an unpatched security vulnerability is a liability. In a regulated fintech, it may be a compliance problem.
More practically: every API version you ship must stay compatible with every app version still in the wild. If 5% of users are on v1.0, your backend cannot remove any endpoint that v1.0 uses. The tail of old versions compounds into technical debt.
Forced updates give you a clean mechanism to say: below this version, we require an update to proceed.
Flexible update: “A new version is available. Update when convenient.” User can dismiss. Good for feature releases.
Forced update: “You must update before you can use the app.” User cannot dismiss. For security fixes, critical bugs, API deprecations.
Google Play’s in-app update API works well but requires Google Play Services. For Cashia — where we needed a solution that worked across distribution channels — we implemented server-side version checking.
data class VersionCheckResponse(
val minimumVersion: String,
val recommendedVersion: String,
val forceUpdateMessage: String?,
val storeUrl: String
)
class VersionCheckUseCase(
private val api: VersionApi,
private val currentVersion: String
) {
suspend fun check(): VersionCheckResult {
val response = api.checkVersion(currentVersion)
return when {
currentVersion.isOlderThan(response.minimumVersion) ->
VersionCheckResult.ForceUpdate(
message = response.forceUpdateMessage ?: "Please update to continue.",
storeUrl = response.storeUrl
)
currentVersion.isOlderThan(response.recommendedVersion) ->
VersionCheckResult.OptionalUpdate(response.storeUrl)
else ->
VersionCheckResult.UpToDate
}
}
}
sealed class VersionCheckResult {
data class ForceUpdate(val message: String, val storeUrl: String) : VersionCheckResult()
data class OptionalUpdate(val storeUrl: String) : VersionCheckResult()
object UpToDate : VersionCheckResult()
}
The version check fires on every app foreground. A ForceUpdate result shows a non-dismissable dialog with a single “Update Now” action.
Blocking on network. Don’t make the app unusable while the version check is pending. Run it in the background on startup. Show the dialog only when you have a confirmed response. A slow network should not block the user from opening the app.
Not communicating why. “Please update to continue” is bad UX. “We’ve improved the security of your payments — please update to continue” is better. Users are more likely to update when they understand the reason.
Using forced updates too often. If you force-update for every release, users learn to resent it. Reserve forced updates for security fixes and API-breaking changes. Use recommended updates for everything else.
We shipped the forced update mechanism in v1.0 — the very first public release.
Three months later, we had our first critical bug. The fix was in v1.1. We set the minimum version to v1.1 and pushed the force update configuration.
Within 24 hours, adoption of the fix was essentially complete. No support tickets from users on the broken version. No backend compatibility maintenance.
Build it before you need it. The cost of not having it lands at the worst possible time.
]]>At Cashia, I built a feature flag framework from scratch, presented it at a company-wide tech demo, and drove adoption across all squads. Every critical feature now ships behind a flag.
The obvious use case: hide an incomplete feature during development. But that’s not the main reason to invest in a proper framework.
Gradual rollouts. Ship to 1% of users. Watch crash rates and error logs. If nothing breaks, roll to 10%, then 50%, then 100%. If something breaks, flip a flag — not a hotfix.
Kill switches. If a payment flow has a critical bug in production, you need to disable it in seconds without a deployment.
A/B testing. The mechanism for testing two versions of a UI.
At a pre-launch startup: the kill switch matters most. Launch day is when you discover the things testing didn’t find.
Four properties I wanted:
// One file for all flag definitions
object FeatureFlags {
val CARD_TOP_UP = Flag("card_top_up", defaultValue = false)
val NEW_ONBOARDING_FLOW = Flag("new_onboarding_flow", defaultValue = false)
val MPESA_CASHOUT = Flag("mpesa_cashout", defaultValue = false)
val UNIFIED_TRANSACTION_HISTORY = Flag("unified_tx_history", defaultValue = true)
}
data class Flag(val key: String, val defaultValue: Boolean)
The FlagManager interface provides runtime values:
interface FlagManager {
fun isEnabled(flag: Flag): Boolean
fun observe(flag: Flag): Flow<Boolean>
}
class RemoteFlagManager(
private val remoteConfig: FirebaseRemoteConfig
) : FlagManager {
override fun isEnabled(flag: Flag): Boolean = try {
remoteConfig.getBoolean(flag.key)
} catch (e: Exception) {
flag.defaultValue // Safe fallback
}
override fun observe(flag: Flag): Flow<Boolean> = callbackFlow {
val listener = remoteConfig.addOnConfigUpdateListener { update, error ->
if (error == null && update.updatedKeys.contains(flag.key)) {
trySend(isEnabled(flag))
}
}
awaitClose { listener.remove() }
}
}
For testing:
class TestFlagManager(
private val overrides: Map<Flag, Boolean> = emptyMap()
) : FlagManager {
override fun isEnabled(flag: Flag) = overrides[flag] ?: flag.defaultValue
override fun observe(flag: Flag) = flowOf(isEnabled(flag))
}
Any class depending on FlagManager (the interface) is testable without touching Firebase:
@Test
fun `card top up button visible when flag is enabled`() {
val flagManager = TestFlagManager(overrides = mapOf(FeatureFlags.CARD_TOP_UP to true))
val viewModel = CardViewModel(flagManager, ...)
// Assert button visibility
}
Remote flags are fetched from the network. Your app starts. You check a flag. The network call hasn’t completed. What do you return?
The naive answer — the default value — introduces measurement error in gradual rollouts. Users who hit the default in the first seconds get counted as “not in treatment” even if they should be.
Our solution: fetch with a timeout at startup, then proceed.
suspend fun fetchFlagsWithFallback() {
try {
withTimeout(2_000) {
remoteConfig.fetchAndActivate().await()
}
} catch (e: TimeoutCancellationException) {
// Use cached values from last successful fetch — don't block startup
}
}
Firebase Remote Config persists the last successful fetch. Two seconds is enough on reasonable connections without meaningfully delaying startup.
The framework worked well for the Android team. Getting other squads to adopt the same flag infrastructure was the more interesting challenge.
I presented at a company-wide tech demo. The pitch: consistent kill-switch behaviour across mobile and web. The kill switch story landed better than the A/B testing story — because the kill switch is what saves your launch.
Good technical decisions don’t sell themselves. You have to show people why they care.
]]>The honest answer: it was exactly the kind of irrational, right-feeling decision that has shaped my career.
Two years at Tamara. Good work. Good team. Good compensation. The kind of role you could stay in for a long time and be comfortable.
I was getting comfortable.
When the Cashia opportunity came up, the role was Lead Mobile Engineer — technically lateral. Earlier stage company. KMM stack, which I’d evaluated at Delivery Hero but never shipped in production. Remote-first, with the core team in Nairobi.
On paper, the sensible move was to stay.
Three things.
The problem felt real in a way that BNPL doesn’t.
BNPL is a useful product. But it’s a product for people who already have access to finance — people with smartphones, data plans, purchasing power. It makes buying things slightly more convenient.
Cashia is building payments infrastructure for markets where meaningful portions of the population are unbanked. The problem isn’t “make shopping more convenient.” It’s “enable people to transact at all.” That’s a different category of problem.
I found I cared about the second category more than I’d realised.
The KMM bet.
I’d spent months at Delivery Hero evaluating KMM. I believed in the direction. But I’d never shipped it in a production app that real users depended on. Cashia was running KMM in production. Joining was a chance to learn from reality, not theory.
When the technical decision you’ve been thinking about theoretically is being stress-tested in production somewhere — go work there.
Early-stage is different.
At Delivery Hero and Tamara, I was one engineer among many. Impact was real but diffuse. At Cashia, I’d shape the platform from a much earlier point. Higher risk. Higher learning rate. Higher leverage.
I joined in July 2025. The team was building toward first public launch. No feature flag framework. No forced update mechanism. No mocking layer.
I built all three in the first two months.
Then: card top-up across mobile, backend, and payments. M-PESA cash-out. Request Money. A company-wide tech demo. A flight to Nairobi.
Seven months later, I was promoted to Engineering Manager.
When I told people I was joining a company based in Nairobi, some said: “Oh, remote from Dubai?” As if Nairobi was an abstraction.
I flew to Nairobi. Worked on-site with the team. Went to Nairobi National Park on a weekend and watched giraffes walk against the city skyline.
The engineers I worked with had the same arguments I have everywhere. Which state management pattern is better. Whether to abstract early or wait for duplication. How much technical debt is acceptable pre-launch.
The same arguments. The same craft. Different context — one that mattered.
That shift changed something in how I think about what we’re building.
If you’re choosing between comfortable and interesting: choose interesting. Every time.
The career lessons that actually change you come from decisions that were slightly too big to feel comfortable at the time.
Comfortable is safe. Safe is slow.
]]>Here’s what stayed and what didn’t.
I was sceptical. I’d used GitHub Copilot. It autocompleted boilerplate acceptably and occasionally suggested something subtly wrong in a way that was worse than nothing. My prior experience: useful for CRUD, unreliable for anything nuanced.
That was 2023. A lot changed.
I use Claude as a rubber duck for architecture discussions. Not to generate code — to think through problems.
When I was designing the feature flag framework at Cashia, I described the constraints: Android + KMM, needs remote and local override, engineers should add a new flag in one file. I asked Claude to identify failure modes in my proposed design.
It surfaced two things I’d missed: a race condition during startup where remote config might not have loaded and a flag returns a stale default; and a missing test interface that would couple unit tests to the remote config SDK unnecessarily.
I fixed both before writing production code.
The pattern: describe the problem and constraints, propose your solution, ask “what are the failure modes and what am I missing?” Different from “write my code” — it’s using LLMs for what they’re actually good at.
I use AI to pre-review my own PRs before requesting human review. I paste the diff, ask for: (1) logic errors, (2) things a reviewer will flag, (3) whether the change matches the commit message.
In practice, it catches roughly 60% of what human reviewers would flag — mostly missing null checks, inconsistent error handling, tests that don’t cover the unhappy path.
The other 40% — contextual knowledge, product implications, cross-team dependencies — it misses completely. That’s why humans still review. But arriving at review with the obvious issues already addressed makes reviews faster and more substantive.
RecyclerView adapters, DiffUtil implementations, ViewModel boilerplate, Room setup — deterministic enough that the output is usually right, tedious enough that generating manually is pure waste.
The rule: I read every line of AI-generated boilerplate before committing it. I’ve caught three incorrect suggestions in twelve months. None catastrophic. All would have caused bugs.
AI for business logic. This is where subtle errors live. The code looks correct, compiles, passes the happy path test, and fails in production under edge conditions requiring domain knowledge to anticipate. I’ve stopped using AI to generate business logic directly.
IDE-integrated autocomplete for Kotlin. Too low-signal. Android Studio’s built-in completion is already quite good, and AI overlay consistently offered plausible-looking alternatives wrong for my context. Turned it off after six weeks.
AI for debugging. I expected this to be useful. “Why is this crash happening?” In practice, AI doesn’t have your full context — database state, network responses, navigation back stack. It gives generic suggestions already in your checklist.
AI tools have made me roughly 15–20% faster on uninteresting work — boilerplate, documentation, pre-review. They’ve made me more rigorous about architecture because having a tool that surfaces failure modes changes how carefully you describe systems.
They haven’t replaced the hard parts. Understanding the Android threading model deeply enough to avoid ANRs, knowing when not to use a ViewModel, reading battery and memory profiles — these require accumulated experience that AI tools don’t have.
Use the tools. Don’t trust them blindly. Know what they’re actually good at.
]]>Not because we’re anti-education. Because we’re pro-learning.
Schools optimize for compliance, not curiosity.
Sit still. Don’t question. Memorize this. Test on Friday.
It worked for the industrial age. We needed factory workers.
We don’t live in that world anymore.
Kids who think. Who question. Who create.
Kids who keep their fitrah - their natural state.
Kids who learn because they’re curious, not because they’re scared of failing.
We’re not recreating school at home. That misses the point.
Instead:
Some days that’s coding. Some days it’s cooking. Some days it’s just playing outside.
I’m building tools as we need them:
Nothing fancy. Just solving our problems.
It’s not easy.
We doubt ourselves daily. Are we ruining their future? Are we being too idealistic?
But then I watch my kid spend three hours absorbed in how ants work. No bells. No schedule. Just pure learning.
That’s worth the uncertainty.
My eldest can focus for hours on things that interest him.
He asks “why” constantly.
He’s not afraid of being wrong.
These feel like wins.
We’re not trying to create prodigies.
We’re trying to raise humans who think, who care, who contribute.
If they end up in traditional school later, fine. But they’ll enter with curiosity intact.
If you’re considering this:
Start small. Even one day a week. See how it feels.
Education is not filling a bucket, but lighting a fire. We’re just trying to keep the fire burning.
]]>I call it vibe coding.
It’s coding by feel. Following your intuition instead of a rigid plan. Starting with what excites you, not what’s “most important” on the backlog.
Sounds unprofessional? Maybe. But here’s what I’ve noticed:
When I vibe code, I ship faster. The code is cleaner. I’m happier.
Start with energy, not priority
Work on what pulls you. That tricky animation? That refactor that’s been bugging you? Start there.
Follow the thread
One thing leads to another. Fixing the animation reveals a state management issue. Fixing that improves the whole architecture.
Stop when it stops flowing
When the vibe dies, stop. Switch to something else or take a break. Forcing it produces bad code.
Our brains are pattern-matching machines. After years of coding, your intuition knows things your conscious mind doesn’t.
That “feeling” that something’s wrong? That’s years of experience talking.
That excitement about a particular approach? That’s your brain recognizing a good pattern.
I’m not saying abandon all structure. At work, we have sprints and deadlines. But within that structure, I find space to vibe.
Monday morning? I’ll tackle that payment flow refactor I’m excited about.
Thursday afternoon when I’m dragging? I’ll do the boring ticket.
Since I started vibe coding:
Next time you sit down to code, ask yourself: What am I drawn to right now?
Follow that feeling. See where it leads.
You might be surprised.
Sometimes the best methodology is no methodology. Trust your instincts. They’ve been trained by every line of code you’ve ever written.
]]>