↑ Back to all posts

Learning to Build Together: How My Latest Project Taught Me Git and Collaboration

Building solo is comfortable. You move fast, make decisions without debate, and never deal with merge conflicts. Then you try to build with someone else — and everything slows down.

But here's the thing — it slows down in the best possible way.

The first merge conflict

I'd used Git before, but mostly as a save button with extra steps. Push to main, done. The first time a collaborator and I touched the same file and tried to merge — I broke the branch and spent forty minutes figuring out what HEAD actually meant.

That frustration was useful. It forced me to actually understand the tool instead of just using it. I now know what a detached HEAD state is. I never wanted to know that, but here we are.

What collaboration actually teaches you

When you're solo, your code only needs to make sense to you. The moment someone else reads it, you discover how many assumptions you've been making. Naming things properly, writing clear commit messages, leaving comments — these stop being nice-to-haves and become team requirements.

"The best code review I ever got was someone asking: what does this function actually do? I didn't have a good answer."

Working with someone else also forced me to think about the product from a different angle. My collaborator caught two UX decisions I'd made that seemed obvious to me but were confusing to anyone who wasn't living inside my head 24/7.

That's the thing about building in isolation — you stop noticing your own blind spots. A second set of eyes isn't just a code quality thing. It's a product quality thing.

What I'd do differently

We didn't set up branch conventions until two weeks in, which caused a lot of unnecessary friction. Now I'd start every collaborative project with 20 minutes on: how do we name branches, what's our PR process, and when do we merge vs. rebase. Small upfront investment, massive downstream payoff.

The takeaway

Solo projects teach you to build. Collaborative projects teach you to communicate. Both are skills. Both matter. If you've only done one — go do the other. The discomfort is the point.

↑ Back to all posts

Coding as a Creative Outlet, Not Just a Skill

There's a version of coding that feels like assembling IKEA furniture — you follow the instructions, something functional comes together, done. That's the version most people learn first. It's useful. It's not exciting.

Then at some point, something shifts. You stop following tutorials and start making decisions. You pick colors, you choose how a button feels when you click it, you decide what to name a variable in a way that makes future-you smile instead of cringe. That's when coding stops being a technical skill and starts being a creative medium.

The blank canvas moment

The first time I built something with no spec — no tutorial, no instructions, just a problem I wanted to solve — was genuinely terrifying. There's no right answer to reach for. No rubric. Just: what do I want this to be?

That's the same feeling a painter has staring at a blank canvas, or a writer at an empty document. Most people hate it. I've learned to love it. That discomfort is where the interesting decisions live.

"Every design decision is an expression of values. What you choose to show first, what you hide, what you make easy — that's all communication."

Constraints make it better

The most creative work I've done has been under the tightest constraints. A specific user problem. A limited timeline. A technical limitation that forces you to find a smarter solution rather than a bigger one. Constraints are generative — they force you off the obvious path.

NoorTab was built in a weekend with a strict feature limit. BudgetBuddy had to work entirely offline. Those constraints shaped the design in ways I never would have found with unlimited time and scope.

Why it matters for PM work

Here's the thing that took me a while to connect: thinking about code as a creative medium made me a better product manager, not just a better developer. When you've made creative decisions under technical constraints yourself, you understand the trade-offs your engineers are navigating. You stop treating implementation as a black box and start engaging with it as a design space.

The best PMs I've learned from think this way. Not "can we build this?" but "what's the most elegant way to build this, and what does that elegance cost?"

The point

If you're learning to code and it feels mechanical, that's normal — it always does at first. But don't stop there. Find a problem you actually care about and build something for it without instructions. That's where it gets interesting.

↑ Back to all posts

Dark Mode vs. Light Mode in Coding: Which Really Works Best?

Ask ten developers which they prefer and nine will say dark mode — then look at you like you just asked whether water is wet. The tenth uses light mode and has fully accepted they will be judged for it.

I spent a month deliberately switching between the two every week to figure out whether the preference is rational or just habit. Here's what I found.

The case for dark mode (it's not just aesthetics)

Dark mode genuinely reduces eye strain in low-light environments. If you're coding at night — which, let's be honest, is often — a dark background is significantly easier on your eyes than a bright white screen. The contrast between light text on a dark background also makes syntax highlighting pop in a way that feels easier to scan.

There's also the focus argument. A dark interface feels more immersive. Fewer visual distractions pulling your attention away from the code. This is partially psychological, but psychological effects on productivity are real.

"Dark mode isn't about looking cool. It's about reducing the cognitive load of staring at a screen for eight hours."

The case for light mode (hear me out)

Here's what surprised me: in bright environments — a coffee shop, a well-lit office, outside — light mode is actually easier to read. Dark text on white has better contrast in high ambient light conditions. Your screen doesn't have to fight the environment.

Light mode also tends to produce fewer color rendering issues. Some syntax highlighting themes look washed out on dark backgrounds, and certain color combinations that work beautifully in dark mode become hard to distinguish. Light mode gives you a more consistent rendering baseline.

And for reviewing documents, reading documentation, or doing design work — light mode tends to match how the output will actually look, which matters.

What I actually found after a month

Switching every week forced me to notice things I'd stopped noticing. The first two days of each switch felt slightly off — just habit recalibrating. By day three, I'd fully adjusted.

My conclusion: dark mode wins for coding sessions, light mode wins for everything else. Most modern editors and operating systems handle this well — you can auto-switch based on time of day or ambient light. That's what I do now and it's the actual answer.

The deeper finding: it matters far less than the energy spent debating it. Font size, line height, and a good monospace font had a bigger impact on my readability than mode ever did. That's probably the hill worth dying on.

The actual recommendation

Use dark mode as your default. Set up auto-switching if your OS supports it. Pick a font you actually like (I use Fira Code with ligatures). Stop arguing about it on the internet and go build something.