Forem: dev koan

The Meeting Skill No Coding Bootcamp Teaches You

dev koan — Sat, 11 Apr 2026 12:59:34 +0000

For the first three years of my career, I was invisible in meetings.

I'd sit there, listen, nod, and leave. Sometimes I had an idea but didn't say it — I figured someone more experienced would say it better. Sometimes I had a question but stayed quiet because I assumed I was the only one who didn't understand.

I was wrong on both counts. And I was accidentally killing my own career progression without realizing it.

Meetings are where careers happen

This sounds dramatic. It's not.

Your manager's perception of your ability is built primarily in two places: the code you produce (which they might not read closely) and how you show up in meetings (which they see directly, every time).

A developer who writes great code but says nothing in meetings is, from a manager's perspective, hard to evaluate. They might be brilliant. They might be struggling silently. The manager doesn't know, because they have no signal.

A developer who writes decent code but communicates clearly in meetings — asks good questions, flags risks early, gives updates without being asked — that person looks competent. Not because they're performing. Because they're giving their manager the information needed to trust them with bigger things.

This isn't politics. It's communication. And nobody teaches it in a bootcamp.

The three things to do in every meeting

I'm not talking about becoming a "meeting person." I'm not saying you should talk more for the sake of talking. There are three small things that, done consistently, change how people perceive your ability.

Ask one question. Any question. "What's the timeline for this?" or "Who's handling the API side?" or "Are we blocked on anything?" It doesn't have to be brilliant. It just has to show you're engaged and thinking. One question per meeting. That's it.

Flag one risk. If you see something that might go wrong, say it. "I think this might take longer than estimated because the API documentation is incomplete." Flagging risks early is one of the most valued behaviors in any engineering team. It shows judgment, not just execution.

Give one update without being asked. "Quick update on the login flow — I'm about 70% done, should have a PR up by Thursday." Proactive updates reduce your manager's anxiety. And a manager who isn't anxious about your work gives you more autonomy.

Three things. That's the whole framework.

Why developers resist this

I know the objection because I had it myself: "I want my code to speak for itself."

It doesn't. Code speaks to other developers who read it. Your manager might read it occasionally. Your manager's manager never will. Promotion decisions, project assignments, opportunities — they all happen in rooms where nobody is looking at your git history.

The developers who get promoted fastest are rarely the best coders. They're the ones whose value is visible.

How to start today

Add a brief note to your team Slack or Discord when you ship something meaningful. Keep a running list of wins — a simple notes file works fine. In your next one-on-one, share one thing you shipped and why it mattered.

Technical skills get you in the door. Communication skills move you through the building.

This is part of devkoan — one tool, one lesson, one step forward every week.

Why Copying Code from Stack Overflow Is a Skill (Not a Shame)

dev koan — Thu, 09 Apr 2026 11:29:22 +0000

I copied code from Stack Overflow yesterday. I'll probably do it again tomorrow.

After 10 years of professional development and 20+ shipped apps, I still copy code from the internet. And I'm not embarrassed about it. But I used to be.

When I was starting out, I had this idea that "real developers" write everything from scratch. That if you needed to look something up, you were somehow cheating. I remember minimizing my browser window when a colleague walked by because I had three Stack Overflow tabs open. Like I was hiding something.

That was stupid.

The actual problem isn't copying

The problem is copying without thinking. There's a massive difference between these two developers:

Developer A finds a solution on Stack Overflow, pastes it in, sees that the tests pass, commits it, and moves on.

Developer B finds the same solution, reads through it line by line, looks up the one function they don't recognize, adjusts the variable names to match the project's conventions, and then commits it.

Both of them "copied code from Stack Overflow." But Developer B actually learned something. Developer A just postponed their confusion to a later date — usually at the worst possible moment, like during a production outage at 11 PM.

What nobody tells you about senior developers

Senior developers copy code too. They just do it differently.

They know which parts to trust and which parts to question. They recognize when a Stack Overflow answer is from 2014 and uses a deprecated API. They can tell when someone's answer is technically correct but architecturally terrible for their specific use case.

That judgment didn't come from avoiding Stack Overflow. It came from using it thousands of times and slowly developing a sense for what's good and what's not.

The habit that actually fixed this for me

I started doing something embarrassingly simple. Before pasting any code, I'd read it out loud and try to explain what each line does. Not to anyone. Just to myself, in my head.

And whenever I hit a line I couldn't explain, I'd stop and look it up. Not the whole answer — just that one line. That one function. That one parameter I didn't understand.

It added maybe 5 minutes per copy-paste. But after a few months of doing this, I noticed something: I was copying less. Not because I'd sworn some oath against it. I was just recognizing patterns I'd already learned by actually reading the code I'd previously pasted.

The real shame is pretending you don't do it

Every developer I respect uses references. Documentation, blog posts, other people's code, GitHub repos, official guides. The idea that professional means writing everything from memory is a fantasy. Nobody works that way.

What matters is that you're building understanding as you go. Not that you already have it.

If you're a junior developer and you feel guilty every time you open Stack Overflow — stop. You're doing fine. Just read the code before you paste it.

That's the whole skill.

I've been documenting patterns like this for years — mistakes I've seen in my own career and in the junior developers I've mentored. I put 100 of them into a free guide: devkoan.gumroad.com

More essays like this on devkoan.substack.com — one tool, one lesson, one step forward every week.

The #1 Reason Junior Devs Burn Out — And It's Not the Workload

dev koan — Tue, 07 Apr 2026 10:59:25 +0000

I burned out in my second year as a developer. Not from the hours. Not from the deadlines. Not from the on-call rotations or the weekend deploys.

I burned out because I was performing.

Every day, I walked into the office and pretended I understood more than I did. I nodded along in architecture discussions I couldn't follow. I said "yeah, makes sense" in code reviews when I had no idea what the reviewer meant. I stayed late not because I had more work, but because leaving on time felt like it would expose that I wasn't keeping up.

That act is exhausting. Way more exhausting than the actual work.

The performance tax

Here's what I mean by performing: it's the mental overhead of constantly monitoring how you appear to others instead of focusing on the work in front of you.

You're in a meeting, and instead of listening to what's being discussed, you're calculating whether you should ask a question or if it'll make you look dumb. You get a code review comment and instead of reading it for what it says, you're trying to figure out if the reviewer thinks you're bad at your job. You get assigned a task you've never done before and instead of saying "I'll need to research this," you say "sure, no problem" and then quietly panic.

All of that takes energy. A lot of it. And it's invisible — there's no ticket for it, no sprint point, no standup update. You just slowly drain.

Why this hits juniors harder

When you're new, everything is uncertain. You don't know the codebase. You don't know the team norms. You don't know what "good" looks like at this company. So you fill in the gaps with anxiety. You assume the worst interpretation of everything.

That ambiguity is normal. But juniors don't know it's normal. They think everyone else has it figured out and they're the only one faking it.

I've mentored enough developers now to know: almost everyone feels this way in their first year or two. The ones who burn out aren't the ones with the hardest assignments. They're the ones who never say "I don't know" out loud.

What actually helped

Two things.

First, I started admitting when I didn't understand something. In meetings. In code reviews. In Slack threads. Just plain "I'm not following this — can you explain?" I expected people to judge me. Nobody did. Most of the time, someone else in the room was confused too and was relieved that I asked.

Second, I stopped comparing my insides to other people's outsides. The senior developer who seems effortlessly competent? They spent years being exactly as confused as you are right now. You're seeing their highlight reel. You're experiencing your own behind-the-scenes footage.

That's not a fair comparison. Stop making it.

The work itself is rarely the problem

If you're a junior developer and you're feeling burnt out, take an honest look at where your energy is actually going. Is it the code? The deadlines? Or is it the constant low-grade anxiety of feeling like you're about to be found out?

Because if it's the second one, the fix isn't working less. The fix is performing less.

Say "I don't know" more. Ask the question you think is dumb. Leave on time without apologizing for it.

The work gets easier when you stop pretending it's already easy.

This is one of the patterns I see most often in junior developers. I've collected 100 of these into a free guide — real mistakes, not abstract advice. Get it here.

Why Your First Project Should Be Embarrassingly Bad

dev koan — Mon, 06 Apr 2026 14:21:35 +0000

My first project had a hardcoded API key in the source code. The navigation crashed if you rotated your phone. The icon was something I made in PowerPoint.

I shipped it anyway. It got maybe 12 downloads, most of them from my family. I'm pretty sure my mom downloaded it twice because she thought the first one didn't work.

That project was terrible. It was also the most important thing I ever built.

The perfectionism trap

I talk to a lot of junior developers who have been "working on" their first project for six months, a year, sometimes longer. They're still tweaking it. Still refactoring. Still reading about the "correct" architecture before writing more code.

They're not building. They're hiding.

I get it. Putting something out there with your name on it is scary. What if people judge it? What if other developers look at the code and think you're bad at this? What if it gets a one-star review — or worse, no reaction at all?

Here's what actually happens: nobody cares. Not in a mean way. In a freeing way. Whether it's an app on the store, a tool on GitHub, or a side project on your portfolio — your first one will be invisible. Nobody is going to find it and judge you.

What shipping teaches you that building doesn't

There's a set of skills you can only learn by actually releasing something. Not by reading about releasing. Not by planning to release. By doing it.

You learn how deployment works — the real version, not the documentation version. You learn that your project breaks in environments you didn't test in. You learn that the feature you spent two weeks on doesn't get used, and the thing you threw in last-minute is the one people mention.

You learn that real users do things you never imagined. They click things you didn't expect. They enter text in fields you thought were obvious. They find bugs in features you were sure were solid.

None of this happens while it's sitting in a private repo.

"But it's not ready"

It's not. It won't be. That's fine. Ship it anyway.

Your code six months from now won't be good enough either, by the standards of you-in-two-years. This never stops. If you wait until your code is good enough, you will wait forever, because the finish line keeps moving as you improve.

The developer who shipped ten bad projects and learned from each one is in a completely different place than the developer who spent the same time perfecting one project that nobody ever used.

I still cringe when I look at my old code. That cringing is evidence that I've grown. If you look at code you wrote six months ago and you're NOT embarrassed, that's the worrying sign — it means you haven't improved.

Just ship the thing

If you have a side project sitting in a private repo right now — half-finished, messy, not quite ready — I want you to seriously consider shipping it. This week. As-is.

It doesn't need to be good. The act of shipping it will teach you things that six more months of building never will.

Your second project will be better. Your third will be better than that. But none of them happen until the first one is out the door.

Make it embarrassingly bad. Ship it. Move on. That's how this works.

I've shipped over 20 projects in the past decade. The first few were awful. I wrote down every mistake I made along the way — 100 of them, collected into a free guide for junior developers. Grab it here.

Git in 20 Minutes: The Safety Net You'll Wish You Had Sooner

dev koan — Mon, 06 Apr 2026 11:41:35 +0000

I lost two weeks of work before I learned this. You don't have to.

Last week I wrote about the map — four steps to go from "I want to build an app" to actually building one. The third step was Git. And I promised I'd explain it properly.

So here it is. No jargon tour. No history lesson about Linus Torvalds. Just what Git does, why you need it before you write anything you care about, and how to start using it today.

What Git actually is

Git is a save system for your code. That's it.

You know how in a video game you save before a boss fight? So if you die, you don't have to replay the whole level? Git does that for your project.

Every time you reach a point where things are working — or even just a point where you want to remember what you did — you create a save point. Git calls these "commits." You can have hundreds of them. And you can go back to any of them at any time.

I didn't use Git for my first six months of coding. During that time, I broke my app so badly that I couldn't undo it. I lost two weeks of work. Then I did it again three weeks later. Different project, same gut-punch feeling of watching your progress disappear.

After the second time, I spent 20 minutes learning Git. I haven't lost work since.

Why beginners skip it

Because it feels like extra work. You're already struggling to learn Swift or Python or whatever language you picked. Adding another tool on top feels like overhead.

I get that. But Git doesn't slow you down. It makes you faster. Because once you have it, you can experiment freely. You can try something wild, and if it breaks everything, you roll back to your last save point in ten seconds.

Without Git, every experiment is risky. You start second-guessing yourself. "What if I break something?" So you play it safe. You don't try things. That fear quietly slows down your learning more than any tool ever will.

The only five commands you need

There are hundreds of Git commands. You need five. Maybe six if you're feeling adventurous.

git init — Run this once, in your project folder. It tells Git to start watching this folder. You'll never run it again for that project.

git add . — This stages your changes. Think of it as putting files into a box before you seal it. The dot means "everything that changed."

git commit -m "your message" — This seals the box. The message is your note to your future self. "Added login screen" or "Fixed crash on rotate" or "I have no idea why this works but it does." Be honest. Nobody grades these.

git log — Shows you all your save points. Newest first. Each one has your message, a timestamp, and a long ugly ID you can use to go back to it.

git checkout — Go back to an earlier save point. This is the undo button. The one that saves you at 11 PM when you've broken everything and you just want to go back to the version that worked an hour ago.

That's the whole workflow. init once, then add, commit, repeat. Check log when you need to see where you've been. Use checkout when you need to go back.

The 20-minute setup

Here's exactly what to do. Right now, if you have a project.

Open Terminal on your Mac. If you've never opened it before, hit Command + Space and type "Terminal."

Go to your project folder. If your project is on your Desktop in a folder called MyApp, type:

cd ~/Desktop/Document/MyApp

Then:

git init
git add .
git commit -m "first save"

You're done. You have your first save point. Your project is now protected. If you break something tomorrow, you can come back to this exact moment.

Going forward, every time you finish something — a feature, a bug fix, even just an hour of work — run:

git add .
git commit -m "describe what you did"

That's the habit. Two commands. Takes five seconds. Saves you hours of pain.

What about GitHub?

GitHub is not Git. This confuses everyone.

Git lives on your computer. It's local. GitHub is a website where you can upload your Git history so it's backed up online and other people can see it.

You don't need GitHub right now. Git alone is enough. When you're ready to share your code or back it up to the cloud, GitHub is the natural next step. But don't let that stop you from using Git locally today.

One thing at a time.

The commit message that saved me

I want to tell you a quick story about why good commit messages matter.

About three years in, I was working on an app and something broke. A feature that had been working for weeks suddenly wasn't. I opened my git log and scrolled through my commits. Most of them said things like "update" or "fix" or "changes." Useless.

Then I found one that said "added background refresh — works but needs error handling." That was the one. I'd added background refresh, and the error handling I'd skipped was now causing the crash.

I found the bug in two minutes because past-me had written a decent commit message. If that commit had just said "update," I would have spent an hour hunting.

Write messages for future-you. Future-you is tired and confused and just wants to find the problem. Help them out.

I've documented 100 mistakes from 10 years of building apps — the ones I made and the ones I watched junior developers make. Grab the free guide here.

The Map Nobody Gave Me: A 10-Year Dev's Honest Starting Guide

dev koan — Sat, 04 Apr 2026 16:35:17 +0000

The first time I wanted to build an app, I sat down, opened my MacBook, and thought: okay. Let's do this.

Then I opened Google.

Four hours later I had 47 tabs open. Three different programming languages downloaded. Two YouTube tutorials paused halfway through. And zero lines of code.

I wasn't lazy. I wasn't stupid. I just didn't have a map.

The Real Problem Isn't Information — It's Sequence

Here's the thing about googling "how to make an app" — you get answers meant for people who already know the shape of the thing.

Swift or Objective-C? Xcode or VS Code? UIKit or SwiftUI? Bootcamp or self-taught? Start with fundamentals or just build something?

Every single one of those is a real question with a real answer. But when you don't know what any of those words mean yet, the answer to each question just opens three more. You spend four hours clicking and reading and watching and at the end of it you feel less ready than when you started.

That's not a knowledge problem. That's a sequencing problem.

The information exists. There's more of it than you'll ever need. The problem is nobody tells you what order to learn it in.

What 10 Years and 20+ Apps Taught Me

I've been building iOS apps solo for 10 years. Twenty-something shipped. I've made every mistake you can make in this process and kept notes on most of them.

The thing I wish someone had told me on day one isn't a tip or a trick. It's this:

The tools matter less than the order you learn them in.

Most beginners try to learn everything at once. Or they pick the "best" tool before they understand what any of the tools do. That's like buying the best hiking boots before you know whether you're going to the mountains or the beach.

Figure out where you're going first. Then pick the tools.

The 4-Step Map

If I were starting over today and wanted to build iOS apps, here's the exact order I'd go:

Step 1: Get Somewhere to Write

Download Xcode. It's free. It's made by Apple. It lives on your Mac. This is where you'll spend most of your time for the next few years so you might as well meet it now. Don't try to understand it yet. Just install it and open it. That's the whole step.

Step 2: Learn One Language

Swift. Not Objective-C, not Python, not JavaScript. Swift. It's what Apple uses, it's what iOS apps are written in, and it's genuinely well-designed for beginners. The debate about which language to learn first is real and completely irrelevant to you right now.

Step 3: Learn to Save Your Work Properly

This is Git. It creates checkpoints in your code so that when you break something (you will, constantly, that's normal) you can go back. I skipped this when I started. Lost two weeks of work. Then did it again. Then I started using Git and I've never lost work since.

Set this up before you write anything you care about.

Step 4: Build Something Small and Ugly

Not impressive. Not portfolio-worthy. Just something that runs on your phone and does one thing. A timer. A list. A button that plays a sound. The goal isn't the app. The goal is going through the full process once so it stops feeling like a mystery.

That's the map. Four steps. Everything else builds on top of those four things.

What's Next

This is the first post in a series. Next up: Git — what it actually is, why it matters more than most beginners think, and how to get started with it in under 20 minutes even if you've never used a command line before.

If you know someone who's been saying "I want to build an app" for the past year and hasn't started yet — share this with them. This is exactly where they need to begin.

I'm DevKoan. 10 years of solo iOS development, 20+ shipped apps, and a collection of every mistake a junior developer can make. I write about the things I wish someone had told me earlier.

Follow me here or on Substack for weekly posts.