DEV Community: Tim Lorent

"One more course" is not a learning strategy

Tim Lorent — Mon, 23 Mar 2026 17:53:51 +0000

You've been working through a course for three weeks. You're almost done. But there's already another one open in another tab (the one you'll do after this) because once you finish both, you'll finally feel ready to apply. Or to take on bigger work. Or to stop feeling like you're pretending.

That feeling doesn't go away when you finish the course. You already know that.

I used tutorials as a way to avoid the thing I was afraid of

When I was trying to land my first dev job, I did this obsessively. One more project. One more certification. One more month of practice. I told myself I was building a foundation, but I was really managing anxiety by feeling productive.

The courses felt safe. They had right answers. They gave you a green checkmark when you got it right. Real work doesn't do that.

At some point I applied anyway: underprepared, convinced someone in HR had made a mistake. Within a month on the job I'd learned more about version control, debugging, and reading unfamiliar code than six months of tutorials had given me.

Why tutorials can't simulate the real thing

Tutorials are designed to reduce friction. They give you a working environment, cleaned-up problems, and a path that someone else already validated. That's useful, but it's also exactly what's missing from actual development work.

Real codebases are messy. Real specs are incomplete. Real feedback comes from people who are also under pressure and don't always have time to be gentle. The skills that matter most on the job, like reading unfamiliar code, asking the right question at the right time, sitting with ambiguity without panicking, aren't things you can learn in a tutorial, because tutorials are specifically designed to remove those conditions.

This isn't an argument against learning resources. It's an argument against using them as a substitute for the discomfort they can't replicate.

What to look for in your first role (or next one)

Not all environments accelerate learning at the same rate. These are the conditions that actually move the needle:

Structured onboarding that explains the why, not just the what.
Pair programming or regular code review from someone patient enough to explain their reasoning.
A team where asking questions is normal!
Real tickets with some ambiguity, not just "go build this thing exactly as described."

What slows things down: being left alone to figure everything out with no guidance, a culture where mistakes are punished rather than examined, and senior devs who are too busy or too defensive to share context.

The quality of that environment matters more than how prepared you felt when you walked in.

How to break the tutorial loop

Set a hard constraint. Pick a date (four weeks out, eight weeks out) and commit to applying or taking on something real by then, regardless of how ready you feel.

Build, build, build. A real project with a real README, a deployment you maintain, a problem you actually ran into. The messiness of making real decisions is the education.

Track what you don't know. When you hit something unfamiliar in a tutorial, note it. Then go apply anyway, and come back to those gaps when the job surfaces them as real problems. You'll retain it better because the context is real.

Use courses to close gaps, not to gate your next move. A course is useful after you've hit something at work that you need to understand better. It's much less useful as a prerequisite for starting.

The fastest way to become a better developer is to be one, somewhere that supports the learning.

The "not ready yet" feeling is real, but it's not a signal to wait. It's the feeling of standing at the edge of the thing that will actually grow you. I've mentored developers who spent a year overlearning before their first application. I've mentored developers who applied early, struggled loudly, and grew twice as fast. The difference wasn't talent. It was which discomfort they chose.

What's one thing you've been waiting to feel ready for? And how long have you been waiting?

The tutorial loop, the readiness myth, and what actually moves your career forward: I cover all of it in From Hello World to Team Lead, my practical guide for developers at every stage of growth.

I vibe-coded a productivity app for two days as a senior engineer. Here's what happened.

Tim Lorent — Tue, 17 Mar 2026 16:55:13 +0000

I've been using AI as a coding assistant for a while now. My usual approach: treat it like a senior developer who occasionally hallucinates after a rough night. Capable, fast, but usually not a great idea to merge their PR without reading it first.

That means I review every line. If something gets generated that I don't fully understand, I stop and ask for an explanation before I let it into the codebase. If it violates how I'd normally structure something, I say so and we refactor. The AI proposes, I dispose or approve, or redirect. It's collaborative, but I'm in the driver's seat (although I don't actually have a drivers license).

I also always work in plan mode, or at minimum ask it to outline what it's about to do before touching a file. That habit alone has saved me from a lot of "wait, why did it rewrite three components to fix one bug" moments.

So when I decided to try vibe-coding, genuinely handing over the wheel, auto-edit on, no review gate... I kind of expected it would go wrong. That was the point.

The Problem I Was Actually Solving

I'm running several workstreams in parallel at any given time: freelance projects, a consultancy, a few side projects, and I teach frontend at HackYourFuture. My task and project management needs don't fit neatly into any single tool.

Bear is great for notes but not for tasks. Notion is powerful but requires too much upkeep to stay useful. Things is clean and opinionated, which I like, but it doesn't bend to the way I think about projects that span different contexts and timelines.

None of them work for me: the way I actually move between things during a day.

So instead of trying to bend another tool to my brain, I decided to build my own. The experiment was the perfect excuse!

I named it Dunzo. If you've watched Parks and Recreation, you know exactly the scene. Tom Haverford: "We are dunzo." It felt right for a task app.

It's live at donezo.vercel.app. My girlfriend and I are currently the only two users. The landing page exists entirely because I needed something convincing enough to get her to actually use it.

How I Normally Use AI When Coding

Before getting into the experiment, it's worth being specific about what I'm comparing against: because "I use AI to code" covers a lot of ground.

My standard workflow looks like this:

Plan before touching files. I describe the feature or problem and ask for a plan first. What files will be affected? What's the approach? Are there tradeoffs worth discussing? Only once I'm aligned with that plan do I let it start generating.

Read everything it writes. Not skim, but read. I want to understand every function, every type, every structural decision. If I don't, I ask. This sounds slow, but it's actually what keeps the codebase coherent over time.

Challenge decisions actively. If it reaches for a pattern I wouldn't have used, I ask why. Sometimes the answer is good and I learn something. Sometimes it was just the path of least resistance, and we do it a different way.

Refactor to my standards before moving on. AI-generated code tends to be correct before it's clean. I don't let technical debt accumulate: each piece gets shaped to how I'd actually write it before the next feature starts.

This workflow is way slower than vibe-coding. It's also the reason the codebases I care about stay navigable six months later.

The Experiment: Auto-Edit On, No Safety Net

The rules I set for myself:

Auto-edit mode, always on. No plan mode, no "confirm before changes," no second-guessing the approach before it started writing. Just go!
Act as a technical product owner, not a developer. My job was to describe what I wanted, with precision, using my experience to frame things well. But not to steer implementation decisions.
No copy-pasting UI from existing apps. If it was going to design something, it would design it from my descriptions, not from screenshots.

The shift that required the most discipline was staying out of implementation. My natural instinct when something gets generated is to read it, react to it, redirect it. For this experiment, I had to consciously resist that: describe the outcome I wanted, let it build, move to the next thing.

Day One: Faster Than Expected

The first day moved quickly. I started with a rough description of what Dunzo needed to be: a personal task management system with tagging, a daily overview, and the ability to group tasks by project or context. I didn't wireframe anything. I just described it in plain language with enough technical specificity to keep the output useful.

Within a few hours I had a working dashboard. Tags worked. The day view worked. Drag-and-drop task reordering worked, powered by dnd-kit. The auth flow was wired up through StackAuth. It wasn't beautiful, but it was functional in a way that would have taken me significantly longer to build with my normal workflow. Not because I'm slow, but because I would have made careful decisions at each step.

What I was doing wasn't passive. My prompts were doing real work. Instead of writing code, I was writing context:

What the component needed to do
What edge cases mattered
What the data shape should look like
How it connected to what was already built

Eight years of building products gave me a vocabulary for that. I suspect vibe-coding with less experience would produce a much messier first day.

The Redesign: Describing Aesthetics Instead of Code

Midway through day two, I decided the app needed to look better. Not a small tweak, but a full visual redesign. This was the part of the experiment I was most curious about, because design direction is something I'd normally drive very deliberately.

Before

After

I didn't give it screenshots of apps I liked. I described the feel I was going for: sleek, minimal, focused. I talked about the kind of typographic weight I wanted, the density of the layout, how I wanted whitespace to work. We went back and forth: it would propose, I'd react, it would adjust. It felt closer to a design conversation than a code session.

The result was entirely AI-generated based on that input. It's cleaner than what I'd have built if I were coding it myself under time pressure, because I could give feedback on the visual output without getting distracted by the implementation details producing it. There's something genuinely useful about that separation.

The Stack

"dependencies": {
  "@dnd-kit/core": "^6.3.1",
  "@dnd-kit/sortable": "^10.0.0",
  "@dnd-kit/utilities": "^3.2.2",
  "@hookform/resolvers": "^5.2.2",
  "@stackframe/react": "^2.8.72",
  "@tailwindcss/vite": "^4.2.1",
  "react": "^19.0.0",
  "react-dom": "^19.0.0",
  "react-hook-form": "^7.71.2",
  "react-router-dom": "^7.13.1",
  "tailwindcss": "^4.2.1",
  "typescript": "^5.9.3",
  "zod": "^4.3.6",
  "zustand": "^5.0.11"
},
"devDependencies": {
  "@biomejs/biome": "2.4.6",
  "@types/react": "^19.0.0",
  "@types/react-dom": "^19.0.0",
  "@vitejs/plugin-react": "^4.7.0",
  "vite": "^7.3.1"
}

Nothing here is surprising, which is itself worth noting. The AI reached for the obvious choices: Zustand for state, Zod for validation, React Hook Form for forms, dnd-kit for drag-and-drop. These are all reasonable tools. They're also the tools that show up most often in training data, which probably isn't a coincidence.

A few observations on specific choices:

Zustand was the right call for a project this size, but the store it generated grew without any deliberate architecture. More on that in a moment.

Tailwind v4 + Vite v7 — both bleeding edge at time of writing. The AI used them without hesitation, which I appreciated. It wasn't defaulting to stable-minus-one out of caution.

Biome over ESLint + Prettier is a choice I'd have made myself. Fast, opinionated, one dependency instead of three.

What Actually Worked

The speed is real. Two days from nothing to a deployed, functional, multi-user productivity app... including a drag-and-drop interface, auth, and a full visual redesign. That's not something I'd wave away.

Prompting well matters enormously. The quality of what got generated was directly tied to the precision of what I described. Vague prompts produced vague code. When I described a feature with specificity (the data flow, the edge cases, the component boundary) the output was meaningfully better. This is not a workflow where you can turn your brain off.

Describing design direction rather than implementing it was a genuinely productive way to work. The redesign felt faster and less precious than it would have if I were writing the CSS myself. I could react to output aesthetically without getting attached to the code producing it.

The app works. That's not a minor thing to say. It does what I need it to do. My girlfriend uses it daily. It's live, it's deployed, it handles two users without issues. For a personal tool, that's the bar, and it cleared it easily.

What Didn't Work

The codebase is a mess. Not broken, but pretty messy.

The Zustand store is bloated. Because state was added incrementally, feature by feature, without anyone stopping to design the store as a whole, it grew into something I'd need to spend real time deciphering before I could safely refactor it. It works, but it's not something I'd want to hand to another developer.

No DRY, no KISS. The AI optimizes for making the current feature work. It doesn't optimize for the codebase as a coherent system (I know that can be prompted too, but I intentionally didn't). Similar logic got duplicated across components because each feature was generated in relative isolation. Abstractions that would have been obvious when writing by hand never materialized.

Tailwind without structure. Utility classes scattered without naming conventions, without component logic, without any discernible system. In a small codebase this is navigable. Scale it up and it becomes painful.

Hardcoded values in places they shouldn't be. Small things, but they accumulate. Magic strings, inline values that should be constants, configuration that ended up in component files. None of it is catastrophic; all of it is the kind of thing that slows you down later.

The pattern across all of these is the same: the AI builds for now, not for later. It has no stake in the maintainability of what it generates. That's a fundamental property of the workflow, not a bug to be fixed with better prompting.

What I Actually Learned

Vibe-coding is a speed tool, not a quality tool. If you want something live fast and the long-term state of the codebase is a secondary concern, it delivers. If you care about the code as much as the product, you'll spend time cleaning up what it built.

Your existing experience sets the ceiling. The precision I could describe features with, the ability to spot when something generated was subtly wrong, the judgment about when to push back: that all came from eight years of building things. Vibe-coding doesn't remove the need for engineering judgment. It just moves where you apply it.

The prompting approach matters more than I expected. There's a meaningful difference between describing what you want like a product owner who understands the technical constraints, and describing it like someone who just wants a feature to exist. The former produces significantly better output. That gap probably narrows as AI models improve, but right now it's real.

State management without architecture is a trap. Zustand is fine. Zustand grown organically across two days of feature additions, with no one designing the store shape, is a liability. If I did this again, I'd stop early and have a conversation specifically about state architecture before letting it grow.

The comparison to my normal workflow is sharper than I expected. When I work with AI carefully (reviewing, redirecting, refactoring as I go) the output reflects my standards. When I vibe-coded, it reflected the AI's defaults. Those are not the same thing, and the codebase shows it clearly.

Would I Do It Again?

For Dunzo: yes! I'll keep vibe-coding it as my needs change. It's a personal tool with two users, and architectural rigor doesn't pay off at that scale. The speed-to-value ratio is right for what it is.

For anything I care about maintaining, collaborating on, or scaling? No. My default workflow exists for good reasons, and two days of vibe-coding reminded me exactly what they are.

The experiment was worth running. The app works. The codebase is something I'll quietly avoid looking at too closely.

That feels like an honest summary of what vibe-coding gets you.

Dunzo is live at donezo.vercel.app. Parks and Recreation fans will get the name immediately. Everyone else will figure it out eventually.

The toxic workplace nearly made me quit development

Tim Lorent — Mon, 16 Mar 2026 13:47:22 +0000

You're not sleeping well. You're second-guessing every PR you open. You've started rehearsing what to say before every Slack message, just in case it gets used against you later. You tell yourself it'll get better: you just need to work harder, get faster, prove yourself.

It doesn't get better.

I almost left the industry because of one job

I was a few years into my career when I landed at a company that looked great on paper. The stack was interesting, the product was ambitious, and the team seemed senior.

What I didn't see until I was inside it: micromanagement at every level, constant peer comparison, and a culture where asking questions felt dangerous. My confidence eroded fast. I started overstudying at night to compensate — trying to out-skill the anxiety. I isolated. I second-guessed things I'd done confidently six months earlier.

I nearly walked away from development entirely. Not because I wasn't good enough, but because the environment was making me into someone I didn't recognize.

What changed wasn't my effort level: it was leaving.

The thing nobody tells you about toxic workplaces

We talk a lot about hard work, resilience, and "just pushing through." Like it's a badge of honor within the development world. What we talk about less: a bad environment doesn't just slow your growth: it actively reverses it.

Psychological safety isn't a buzzword. It's the condition under which learning actually happens. When you're afraid to ask questions, you stop asking them. When you're afraid to make mistakes, you stop taking the kind of risks that lead to real skill. When you're constantly compared to peers, you optimize for looking capable instead of actually becoming capable.

The reframe that changed how I think about this: the environment you work in is a variable, not a fixed condition. You can leave. Sure, perhaps not immediately because a family depends on you and you need to pay rent, but ultimately.

I've mentored developers who spent two or three years grinding harder in a bad workplace, convinced that their discomfort meant they needed to grow more. Some of them did grow: in spite of the environment, not because of it. All of them would have grown faster somewhere else.

Green flags worth protecting

After leaving that job, I became deliberate about what a good environment actually looks like in practice. Here's what I watch for:

Senior devs who answer questions without making you feel small. This sounds like a low bar, but it isn't. When you work somewhere this is normal, your learning rate doubles.

Code reviews focused on architecture and readability, not on who wrote it. Feedback that's attached to the code, not to you as a person.

Mistakes handled with curiosity, not punishment. The first time something breaks in production and your lead says "okay, what happened and what do we fix" — that's data. Stay.

People who admit they don't know things. On high-functioning teams, "I'm not sure, let me check" is standard. It signals that ego isn't running the technical decision-making.

Onboarding that assumes you're capable. Not hand-holding, not sink-or-swim — actual structure that respects your time.

Red flags to take seriously

No documentation and nobody has time to explain things. This means context is hoarded, not shared.

Interviews that emphasize how "fast-paced" everything is, but can't describe what good work looks like.

Senior devs who compete instead of collaborate. Seniority shouldn't come with contempt for the people coming up behind you.

Feedback that's vague and personal. "You need to be more proactive" with no specifics is a sign that psychological safety is low: no one wants to give you real information but they do expect a lot from you.

Being made to feel lucky to be there. If you're hearing that implicitly or explicitly: leave. That framing exists to prevent you from advocating for yourself.

When to actually go

Three months of trying to change your environment with no movement. That's a reasonable window. If you've raised concerns, adjusted your approach, tried to find allies (and the conditions haven't shifted) the conditions won't shift.

When the job is changing who you are off the clock. If you're more anxious, more defensive, less curious than you were a year ago.

Your first job isn't your final destination. Neither is your second or your third. The developers I've seen grow fastest weren't the ones who endured the most: they were the ones who found environments where growth was actually possible, and stayed long enough to take advantage of it.

A bad environment doesn't mean you're bad at this. It means you're in the wrong place.

Your effort matters, sure, but effort compounds when the conditions support it and stalls when they don't. The bravest thing I did early in my career wasn't staying and grinding. It was recognizing the difference.

Have you ever stayed somewhere longer than you should have? What finally made you go or what made you realize you'd found the right place?

If this resonates, a lot of what I learned navigating bad environments, and building better ones, is in my book From Hello World to Team Lead, a practical guide for developers who want to grow without losing themselves in the process. And if you're currently in a situation that feels stuck and want to talk it through, you can book a developer growth session with me.

"That's Just How It Is" Kills Innovation: Building Teams That Question Everything

Tim Lorent — Mon, 01 Dec 2025 12:08:46 +0000

Three months into a new project, our builds were taking 12 minutes. Everyone complained. Nobody investigated.

"That's just how it is with large codebases."

A new teammate joined. Day two, she asked: "Why does this take so long?"

We shrugged. She didn't. She spent an afternoon digging. Turns out we were bundling dev dependencies in production. One config change later: 3-minute builds.

Twelve months of collective frustration, solved in an afternoon—because one person refused to accept "that's just how it is."

🚫 The Phrase That Stops Progress

"That's just how it is" is the most expensive sentence in software development.

It sounds like acceptance. It's actually resignation.

I've heard it everywhere:

"Deployments always break on Fridays." (They don't have to.)
"The staging environment is always down." (There's a reason.)
"This feature is too complex to test properly." (Probably not.)
"Our standups always run long." (They shouldn't.)

Every time someone says "that's just how it is," they're drawing a line. On one side: things we can change. On the other: things we've decided to live with.

High-performing teams don't have that line.

🔍 The Nadia Makarevich Approach

Nadia Makarevich did something most React developers don't do: when everyone said "React is slow," she didn't just accept it.

She investigated. She measured. She dug into the actual bottlenecks—not the assumptions, not the conventional wisdom, but the real technical reasons behind performance issues.

And she found the truth was more nuanced than "React is slow." It was about how people were using React. About unnecessary re-renders, about component architecture, about understanding the actual mechanisms at play.

That's the difference. Most people stop at the surface answer. Great engineers keep asking "why?" until they understand the system.

I learned this the hard way. Early in my career, I accepted so many things as unchangeable:

Our code reviews always took three days. (Because we didn't have a process.)
Our API responses were slow. (Because nobody looked at the queries.)
Our bug count kept climbing. (Because we weren't tracking patterns.)

None of these were inevitable. They were all solvable. But solving them required curiosity—and permission to question the status quo.

🎯 What Curiosity Actually Looks Like

Real curiosity isn't just asking questions. It's being willing to investigate when everyone else has moved on.

Surface level: "Why is this failing?"
One layer deeper: "Why is this condition triggering?"
Actual root cause: "Why did we structure it this way?"
System insight: "What does this tell us about our architecture?"

I remember a bug that kept appearing in production. Every time, we'd patch it. Every time, it would come back in a slightly different form.

Finally, someone asked: "Why does this keep happening?"

Turns out our error handling was masking a deeper issue—a race condition we'd been dancing around for months. We'd been treating symptoms. We needed to understand the disease.

Once we saw the pattern, the fix was obvious. But we'd been too busy firefighting to step back and ask "why?"

🧠 Code Matters When It Solves Problems

Here's something that took me too long to learn: code only matters when it solves customer problems.

You can write the most elegant, performant, beautiful code in the world. If it doesn't help a user accomplish something, it's just expensive art.

I spent days once refactoring a component to be "perfect." Clean, reusable, well-tested. I was so proud.

Then in a user session, I watched someone struggle with the feature it powered. The refactor didn't matter. The core interaction was confusing.

All that beautiful code was solving the wrong problem.

Great engineers don't just ask "why is this code slow?" They ask "why does this code exist?" and "what problem is this actually solving for users?"

That shift—from "code works" to "code matters"—changes everything.

🛠️ Building a Culture of Curiosity

Here's what I've learned about fostering this mindset in teams: curiosity isn't an individual trait you hire for. It's a team behavior you cultivate.

Make it safe to question things

In toxic environments, "why do we do it this way?" sounds like criticism. In healthy teams, it's an invitation to improve.

I remember asking "why" in a meeting once and being told "that's above your level." That shuts down curiosity instantly.

Now when someone on my team asks "why," my response is: "Great question. Let's figure it out together."

Reward investigation, not just solutions

We celebrate the person who fixes the bug. We should also celebrate the person who digs into why it happened and documents the pattern so it doesn't happen again.

Create space for exploration

"Just ship it" culture kills curiosity. If everything is urgent, nobody has time to ask why.

Document the "why," not just the "what"

Our best pull request descriptions don't just say what changed. They explain why it was necessary, what we learned, and what alternatives we considered.

That context helps future developers (including future you) understand the decisions—and question them if circumstances change.

Ask "why does this matter to users?"

In refinement, before we dive into technical details, someone should ask: "What user problem does this solve?"

If nobody can answer clearly, we dig deeper. Sometimes we discover the feature request was based on an assumption, not an actual user need.

Curiosity about the problem is as important as curiosity about the solution.

🔄 The Curiosity Checklist

Here's what we ask now when something feels off:

Before accepting "that's just how it is":

Have we actually investigated why this happens?
What assumptions are we making?
What would it take to change this?
Who benefits from things staying this way?
What would a new teammate think if they saw this?

Before starting work:

Why are we building this?
What user problem does it solve?
How will we know it worked?

After shipping:

What surprised us?
What would we do differently?
What patterns are emerging?

These questions sound simple. But asking them consistently changes how teams work.

⚡ What Changes

Teams that cultivate curiosity don't just ship faster—they ship better.

They catch issues early because someone asked "why is this structured this way?"

They prevent tech debt because someone questioned "do we really need this complexity?"

They solve real problems because someone pushed back on assumptions about what users need.

And they attract great people—because curious engineers want to work with other curious engineers.

✨ Your Turn

Look around your codebase, your processes, your team rituals. What have you accepted as "just how it is"?

Pick one thing this week. Ask why. Dig one layer deeper than you normally would.

You might find nothing. Or you might find the thing that unlocks the next six months of progress.

What's one thing your team has accepted as "just how it is"—that maybe shouldn't be?

I write about building better development teams at Beyond Commit. Free 15-minute coaching calls available for developers and leads working through team challenges. 10% of everything supports tech education nonprofits.

webdev #teamculture #leadership #engineering

Want to dive deeper into building these skills?

I wrote From Hello World to Team Lead for developers navigating the messy reality between junior and leadership—the parts bootcamps don't teach you. It covers the frameworks, templates, and mindset shifts I wish I'd had earlier: how to give feedback that doesn't crush people, build systems that support growth, handle burnout, and lead without a title.

Right now it's 40% off, and 10% of every purchase goes to tech education charities (TechMeUp, SheSharp, GirlCode, HackYourFuture).
Grab your copy here and start applying these ideas tomorrow!

"Soft Skills Are Actually the Hard Skills": Why Developer Growth Is More Difficult Than Technical Mastery

Tim Lorent — Thu, 27 Nov 2025 10:33:06 +0000

I sat across from a senior developer at a meetup last month. We were talking about career growth, burnout, the usual stuff. Then he said something that was one of those 'mind-blown' moments:

"Soft skills are actually hard skills for me."

He wasn't joking. He got a degree in CS, studied for years, was developing for 20+ years...but soft skills? They were actually hard for him.

Here's what nobody tells you: the skills we call "soft" are often the hardest to master.

🎖️ The Army Got It Backwards

Rob Baker uncovered something wild: the terms "hard" and "soft" skills came from the 1950s U.S. Army. "Hard" meant weapons and machinery. "Soft" meant everything involving humans—leadership, communication, strategy.

The irony? They had it backwards.

Technical problems are complicated. Many moving parts, sure—but reproducible. You can Google "React useEffect cleanup," find a pattern, apply it. Stack Overflow has 23 million answers waiting for you.

Human problems are complex: every person is different, every team has different dynamics. You can't copy-paste trust, you can't Stack Overflow your way through conflict.

That's why giving constructive feedback to one teammate works beautifully—and the exact same approach makes another shut down completely.

📚 The "Soft Skills" We Actually Struggle With

Let me be honest about my own journey. I learned TypeScript generics faster than I learned how to say "I disagree" in a meeting without my voice shaking.

Here's what tripped me up (and still does sometimes):

Giving feedback without crushing someone's confidence. Early on, I'd either be too blunt ("This code is messy") or too vague ("Maybe we could improve this?"). Finding the middle ground—specific, kind, actionable—took years, not weeks.
Receiving feedback without spiraling. Someone would say "This could be cleaner" and I'd hear "You're a terrible developer." Learning to separate information from identity? That's ongoing work.
Explaining technical decisions to non-technical people. I could architect a solid solution. But explaining why it mattered in a way product and design could understand? That required a completely different skillset.
Speaking up when something feels off. I once stayed silent during a toxic project for months because I didn't know how to address it. Technical problems had clear solutions. Interpersonal friction? No clear playbook.

Why Technical Skills Feel Easier

When I wanted to learn Flutter, I had a path: tutorials, documentation, practice projects, Stack Overflow. The feedback loop was immediate. Code works or it doesn't.

When I needed to get better at mentoring? There was no "Mentorship.dev" with interactive exercises. No linter to catch when I was being too directive or not supportive enough.

Technical skills scale through repetition. Once you understand React hooks, you can apply that pattern across projects. Write one good API, you can write another.

Human skills require constant calibration. What worked with my last team might fail with this one. How I mentor someone confident is different from how I support someone struggling with imposter syndrome.

And here's the thing: we're rarely taught these skills explicitly.

Most developers learn communication through trial and error. Through screwing up a code review and watching someone's face fall. Through missing a chance to speak up and regretting it later.

We expect these skills to develop naturally. But they don't—at least not well, and not for everyone.

What Makes Them Actually Hard

I wish someone had told me this earlier: these skills are legitimately difficult because they require things code doesn't.

Self-awareness. You have to notice your own patterns—like realizing you interrupt people when you're excited, or that you avoid conflict until it explodes.
Emotional regulation. Staying calm when someone criticizes your work. Not letting frustration leak into your tone during a tense meeting.
Adaptability. Reading the room. Adjusting your approach mid-conversation. Knowing when to push and when to step back.
Vulnerability. Admitting you don't know. Asking for help. Saying "I was wrong" or "I need feedback."

That senior dev at the meetup? He wasn't struggling because he was bad at these things. He was struggling because these things are genuinely hard.

🎯 What Actually Helps

Here's what's helped me (and what I wish I'd known earlier):

Treat soft skills like technical skills. Don't just hope you'll "pick them up." Study them. Practice deliberately. I started using feedback templates, communication frameworks, conflict scripts—the same way I'd learn a new library.
Create systems for recurring situations. I have a code review checklist. A ticket prep template. A way to structure difficult conversations. Structure doesn't kill authenticity—it supports clarity when your brain is overwhelmed.
Learn from people who are good at this. I watched teammates who could give feedback that made people excited to improve. I asked questions: "How did you phrase that?" "What made you choose that approach?"
Reflect regularly. Weekly reviews where I ask: What went well in communication this week? Where did I struggle? What would I do differently? Reflection turns experience into learning.
Give yourself permission to be imperfect. I still mess up. I still say the wrong thing sometimes. But I'm better than I was a year ago—and that's what matters.

For Engineering Leaders

If you're leading a team, here's what I'd ask you to consider:

Stop calling them "soft" skills. Call them what they are: essential skills or human skills or even the hard skills. Language shapes how seriously we take them.
Provide actual training. Not just "be a better communicator" in a performance review. Real training. Workshops. Role-playing. Feedback practice sessions. Resources.
Model them yourself. Show your team what good feedback looks like. Demonstrate how to navigate conflict. Admit when you're wrong. Your behavior sets the standard.
Create space for people to practice. Retrospectives aren't just for process—they're for practicing speaking up. Code reviews aren't just for catching bugs—they're for learning how to communicate critique with care.
Normalize struggle. Make it okay to say "I'm not sure how to approach this conversation" or "I need help with this feedback." If your team thinks they should already know this stuff, they won't ask for help.

The Real Growth Edge

Learning the next framework will make you productive. Learning how to communicate, collaborate, and lead will make you invaluable.

That developer at the meetup? He was right. The soft skills are the hard skills. And that's exactly why they're worth investing in.

Because here's what I've learned: you can replace a developer who knows React. You can't replace a developer who makes the whole team better.

What's one "soft skill" you've struggled with? And what helped you improve—even a little?

Want to dive deeper into building these skills?

Right now it's 40% off, and 10% of every purchase goes to tech education charities (TechMeUp, SheSharp, GirlCode, HackYourFuture).

Grab your copy here and start applying these ideas tomorrow!

🚀 Junior Devs Aren't Disappearing—They're Just Getting Started

Tim Lorent — Mon, 17 Nov 2025 08:35:28 +0000

I refresh LinkedIn and see another post: "Junior roles are dead." Another thread on Reddit: "AI is replacing entry-level devs." Another think piece predicting the end of the junior developer.

Then GitHub's former CEO says something completely different.

Thomas Dohmke told "The Pragmatic Engineer" that junior engineers still bring massive value—not despite AI, but because of it.

That aligns with everything I've seen going from junior to team lead.

The Fear Is Real (And Valid)

If you're early in your career right now, I get it. The job market feels brutal. Every posting wants 3+ years of experience. AI tools are getting better. Senior devs are saying they're 10x more productive with Copilot.

So where does that leave you?

Staring at that "Apply" button, wondering if you're already obsolete before you even start.

I've been there—different context, same fear. I remember thinking I'd waited too long, learned the wrong stack, missed my window.

What Juniors Actually Bring

Dohmke's point wasn't just feel-good encouragement, rather it was strategic.

Younger developers adopt AI tools faster. They bring fresh perspectives, recent learning, and don't carry the "this is how we've always done it" mindset.

What that actually looks like in practice:

Fresh ideas and willingness to experiment

You haven't been burned by five failed rewrites. You're not attached to the old way. You see possibilities where others see risk.

AI fluency from recent education

You learned to code with AI tools. That's not a weakness—it's native fluency in the tools shaping the industry.

Open-minded approach to new tools

When someone suggests trying a new framework or approach, you don't have years of muscle memory fighting against it.

Energy that pushes teams forward

You ask "why?" when everyone else just accepts "because that's how it works." That questions systems. That creates momentum.

Diverse backgrounds shaping better solutions

You didn't all come from the same CS program or bootcamp cohort. You bring perspectives from music, teaching, healthcare, design—experiences that matter when building for real users.

🔧 Engineering vs. Coding

Here's where Dohmke's point gets sharper.

Engineering still requires craft and systems thinking. But future engineers combine prompting skills with open source to solve problems faster.

The coding skill matters. But engineering means building complex systems—whether you write every line or orchestrate AI to help.

The new generation of developers will ship faster than I ever did.

But they will need to understood the why, the architecture, the tradeoffs. The AI just helps them type faster.

That's engineering.

🎓 What I Learned Going from Junior to Lead

The fastest-growing developers on my teams weren't always the most technically gifted.

They were the ones who:

Asked questions when everyone else stayed quiet
Tried new approaches instead of copying old patterns
Shared what they learned, even when it felt basic
Elevated everyone by bringing curiosity into the room

One junior dev I mentored was terrified they weren't "technical enough" because they used AI tools heavily. But they became the person everyone went to for architecture questions—because they could explain complex systems clearly, having learned by asking better questions.

Your edge isn't knowing everything. It's learning fast and thinking clearly.

🧭 If You're Worried About the Junior Market

You're still needed.

Companies that understand growth know they need fresh perspectives alongside experience. They need people who challenge assumptions. They need energy and curiosity driving the team forward.

Yes, the market is tough. Yes, you'll face rejection. Yes, some companies are shortsighted about junior roles.

But the best teams? They're actively looking for what you bring.

✅ So What Should You Focus On?

Not just technical skills. Not just prompting. Something beyond code.

Focus on:

Systems thinking

Understand how pieces connect. Why this API structure? Why this state management pattern? Why this deployment strategy?

Communication

Explain your decisions. Write clear tickets. Ask better questions. Engineering is a team sport.

Problem-solving with tools

Use AI, Stack Overflow, documentation, senior devs—whatever gets you unstuck and moving. The skill is knowing when to use what.

Building in public

Ship projects. Write about what you learn. Show your thinking, not just your code.

Curiosity over credentials

Keep asking "why?" Keep trying new things. Keep sharing what you discover.

🎁 Permission You Don't Need (But I'll Give Anyway)

You don't need to know everything before you're "qualified."

You don't need to code without AI assistance to be a "real" developer.

You don't need years of experience before your perspective matters.

You're ready enough right now. Not because you're perfect, but because engineering teams need what you bring: fresh eyes, new energy, and willingness to challenge how things work.

The junior role isn't disappearing. It's evolving—and you're exactly the kind of developer who thrives in that evolution.

What are you focusing on right now—technical skills, prompting, or something beyond code? I'd love to hear what's working for you.

Photo by Nubelson Fernandes on Unsplash

"Technical Debt Will Bite Us in the Ass": How to Make Non-Technical Stakeholders Actually Care

Tim Lorent — Fri, 14 Nov 2025 09:39:53 +0000

"We need to refactor this code."

Blank stares.

"The architecture is getting messy."

More blank stares. (Even a hint of 'leave me alone, we have features to ship.')

"If we don't address this technical debt now, it'll slow us down later."

Polite nods. Then: "Can we just ship this feature first?"

I've had this conversation more times than I can count. And for years, I blamed the product managers.

They don't get it. They only care about features. They're ignoring the foundation while demanding we build another floor.

Then I realized: they weren't the problem. My communication was.

The Translation Gap

Here's what I was saying: "We need to refactor this code because the architecture is getting messy and technical debt is accumulating."

Here's what they heard: "I want to spend two weeks making things prettier instead of building what customers asked for."

We were speaking different languages. I was talking about code quality. They were thinking about customer value, revenue, and roadmap commitments.

Neither of us was wrong. We just weren't connecting.

The Moment Everything Changed

I was in yet another meeting trying to explain why we needed to pause feature work to address technical debt.

The product manager's eyes were glazing over. I could see her mentally calculating how to politely end this conversation.

So I stopped mid-sentence and tried something different.

"Imagine you just cut half your finger off. You could properly clean it and put on a bandage, or you could just ignore it. What happens if you keep ignoring half cut off fingers?"

She looked at me like I'd lost my mind. But then she got it.

"They get infected."

"Exactly. And eventually, you can't use that hand at all. That's what technical debt does to our codebase."

Suddenly, we weren't debating code architecture. We were discussing wounds that fester, infections that spread, and hands that stop working.

Technical debt became something she could visualize. And visualization creates urgency.

Why Technical Jargon Fails

When we say "refactoring," non-technical stakeholders hear "optional polish."
When we say "technical debt," they hear "developers want perfect code."
When we say "architecture," they hear "abstract concerns that don't affect users."

We're not wrong to use these terms with each other. But with stakeholders who measure success in features shipped, revenue generated, and customer satisfaction scores, we need a different vocabulary.

Not because they're less intelligent. Because they're optimizing for different outcomes.

A product manager isn't ignoring technical debt out of malice.

They're focused on:

Delivering promised features to customers
Meeting revenue targets
Staying ahead of competitors
Keeping stakeholders happy

And "we need to refactor" doesn't map to any of those goals. So we need to show them how it does.

Building the Bridge

The change isn't about dumbing things down, rather it's about finding shared language.

Here are the metaphors that have worked for me:

The Band-Aid on an Infected Wound

Every quick fix is a band-aid over a cut we didn't properly clean. Every shortcut is like painting over a crack in the wall instead of fixing the foundation.

At first, it looks fine: the wall looks painted, the cut is covered.

But band-aids fall off. Paint peels. And what's underneath is worse than when you started.

Why it works: Everyone understands infections get worse when ignored. Nobody argues with "this will get infected."

The Cracked Foundation
You can keep building floors on a cracked foundation. And for a while, it'll hold. But every new floor adds pressure. The cracks spread. And one day, the whole thing collapses—right when you need it most.

Why it works: It connects technical decisions to risk management, something every business leader thinks about.

Speaking Their Language

Metaphors help, but you know what really works? Translating consequences into business language.

Instead of: "This code is hard to maintain."

Try: "Every new feature in this area takes 3x longer because of how it's structured. That's 20 extra hours per sprint we could be spending on new features."

Instead of: "We have technical debt here."

Try: "This is costing us $15,000 in developer time every quarter. If we invest two weeks now, we'll save that every quarter going forward."

Instead of: "The architecture is messy."

Try: "Our bug rate in this module is 4x higher than elsewhere.

Customers are reporting issues every week. We can fix that, but it requires addressing the underlying structure."

Hours lost. Money wasted. Bugs multiplying. Velocity decreasing.

These are metrics stakeholders understand. These create urgency.

The Conversation That Actually Works

Here's the framework I use now:

Acknowledge their priorities: "I know we need to ship Feature X by end of quarter. That's important."

Don't start with opposition. Start with alignment.

Connect technical debt to their goals: "The problem is, the area where we need to build Feature X is really unstable. We're seeing bugs there every week, and each change takes twice as long as it should."

Show how the technical problem affects their goals, not yours.

Quantify the cost: "Right now, we're spending about 10 hours every sprint just working around the issues in that module. That's half a developer's time."

Make the invisible visible. Give them numbers.

Propose the investment and ROI: "If we spend one week cleaning this up, we'll cut that time in half. Plus, Feature X will be faster and more stable to build."

Frame it as an investment with clear returns, not a cost.

Give them the choice: "We can either address it now and move faster after, or keep working around it and accept that every feature in this area will take longer. What makes more sense given our priorities?"

Empower them to make the decision with full information.

🛠️ How to Apply This

Before the next technical debt conversation:

Identify the business impact. What's the cost in time, money, or risk? If you can't articulate this, you're not ready for the conversation.
Choose your metaphor. What will resonate with this specific person? Financial types respond to debt and interest. Product types respond to velocity and risk.
Quantify everything you can. Hours, dollars, bug counts, velocity changes. Numbers create urgency.
Prepare the ROI. What's the investment? What's the return? How long until it pays off?

During the conversation:

Start with their goals, not yours. "I know shipping Feature X is critical..."
Connect technical to business. Show how the technical problem blocks their goals.
Give options, not ultimatums. "We can address it now and move faster after, or keep working around it. What makes sense given our priorities?"
Be honest about trade-offs. Every choice has costs. Acknowledge them.

After you get buy-in:

Deliver what you promised. If you said it would take one week, take one week. Trust is built through follow-through.
Measure the impact. Did velocity improve? Did bugs decrease? Share these wins.
Reinforce the connection. "Remember when we cleaned up Module X? That's why we shipped Feature Y so fast."

The Deeper Skill

Here's what I wish someone had told me earlier: Cross-discipline communication is a core engineering skill.

Not a soft skill. Not a nice-to-have. A core skill.

The best engineers I know aren't just technically excellent. They can translate technical concerns into business value, design implications, or user impact.

They understand that:

Backend engineers need to talk to frontend in terms of API contracts and data flow
Frontend engineers need to talk to designers in terms of interaction patterns and constraints
Everyone needs to talk to product in terms of customer value and business outcomes

Finding the bridge between disciplines isn't about compromising your expertise. It's about making your expertise relevant to people who optimize for different outcomes.

🤔 Questions to Reflect On

When's the last time you tried to explain a technical problem and got blank stares? What language were you using?

What metaphors resonate with your specific stakeholders?

Are you quantifying the business impact of technical decisions, or just hoping people trust you?

How often do you start technical debt conversations with stakeholder goals vs. engineering concerns?

The Bottom Line

Technical debt will bite us in the ass. But saying that to stakeholders won't create urgency.

Band-aids on infected wounds will. Credit card interest will. Cracked foundations will.

Every quick fix is a band-aid over a cut we didn't properly clean.

Every shortcut is like painting over a crack in the wall instead of fixing the foundation.

At first, it looks fine. But band-aids fall off. Paint peels. And what's underneath is worse than when you started.

Your job isn't just to identify technical debt. It's to make non-technical people care about it as much as you do.

And that starts with speaking their language.

Photo by charlesdeluvio on Unsplash

Not a Single Customer Cares If You Chose Vue or React

Tim Lorent — Thu, 13 Nov 2025 11:52:04 +0000

I've sat through enough technical debates to predict exactly how they'll go.

Someone suggests a framework. Another person counters with a different one (possibly me). Twenty minutes later, we're deep into performance benchmarks, bundle sizes, and whether TypeScript generics make the codebase more maintainable.

Meanwhile, the customer is still waiting for us to solve their actual problem.

And here's the uncomfortable truth: they don't care which framework we choose. They care if we solved their problem. Fast.

The Trap of Technical Perfectionism

I used to be that developer who needed every decision to be "right."

React or Vue? Let's compare virtual DOM implementations.
Should we refactor this prop drilling into Context? Let's debate the trade-offs for an hour.
MongoDB or PostgreSQL? Better write a comparison matrix.

Every technical decision felt like it needed deep analysis, careful consideration, and team consensus.

And you know what happened? We shipped slowly. We over-engineered. We built things nobody asked for because we were so focused on how we built that we forgot why we were building.

The change came when I started working more closely with product and business colleagues. They taught me something I didn't learn in any coding tutorial:

Focus on now.

Not on the perfect scalable architecture for when we have a million users. Not on the most elegant solution that demonstrates our technical prowess. On shipping the MVP, iterating, and creating value for the customer.

What Product Teams Know That We Often Forget

Product managers live in a world of trade-offs. They understand something fundamental:

Done and iterating beats perfect and delayed. Every time.

They're not suggesting we write garbage code and ship it. They're suggesting we stop debating theoretical problems and start solving real ones.

Over eight years, I've learned their most valuable question: "What's the smallest thing we can build to test if this solves the problem?"

Not: "What's the most technically impressive solution?"
Not: "What will make our codebase look amazing in the architecture review?"
But: "What gets us to feedback fastest?"

The Two Questions That Cut Through the Noise

When I feel a technical debate heating up (or when I'm the one heating it up), I've learned to pause and ask:

What's relevant now? Not in six months when we might have scale problems. Not when we have the budget for a rewrite. Now. Are we actually experiencing performance issues, or are we debating potential future performance issues? Do we have real data showing users need this feature, or are we building what we think they need? Is this technical debt actually blocking us, or does it just feel uncomfortable?
How can we get the most value out of the most basic implementation? This one hurts because it forces us to admit: the fancy solution probably isn't needed yet.

Can we ship this with a simple state object before we build out Redux?
Can we use fetch before we implement a full caching layer?
Can we validate this idea with a prototype before we architect the perfect system?

Verify, then iterate!

Not build perfectly, then discover nobody wanted it.

A Story About Prop Drilling and Reality

Once, a developer on my team spent three days refactoring our prop drilling into an elegant Context solution.

The code was beautiful. The architecture was clean. The implementation was technically impressive.

Not a single customer noticed.

You know what they did notice? That we hadn't shipped the feature they actually requested because we were busy refactoring code that already worked.

I'm not saying that refactor was worthless. Context is often the right choice. But the timing was wrong.

We optimized for developer satisfaction instead of customer value.

And that's the trap. Technical quality feels like the responsible choice. But sometimes, it's just procrastination disguised as professionalism.

The Balance Nobody Talks About

Here's where this gets nuanced: I'm not saying ship garbage and call it an MVP.

I'm not saying ignore code quality, skip tests, or tie loose ends together and pretend it's done.

I'm saying: be mindful of how much debate you're entering before you've built anything.

There's a spectrum:

Too far left (ship garbage):

No tests, no structure, just hack it together
Technical debt that blocks future work
Code so brittle that every change breaks something

Too far right (perfect or nothing):

Debating architecture before validating the need
Building for scale you don't have
Refactoring working code because it "could be better"

The sweet spot (verify, then iterate):

Build the simplest thing that solves the problem
Ship it, get feedback, learn
Then decide if it needs to be better

Sometimes the MVP is the answer you need. Sometimes it reveals that the whole approach was wrong and you need to pivot. Either way, you learned something real instead of debating something theoretical.

🛠️ How to Apply This

When facing a technical decision:

Ask: "What problem are we actually solving?" Write it down. Make sure everyone agrees. If you can't articulate the customer problem clearly, stop debating solutions.
List the simplest possible implementations. Force yourself to consider boring, basic solutions before the fancy ones.
Estimate time to feedback. How fast can each option get you to real user validation? Weight this heavily.
Check your motivations. Are you choosing this because it solves the customer problem, or because it's more interesting to build?

When debates get heated:

Pause and ask: "What's relevant now?" Redirect from theoretical to actual.
Request data. "Do we have evidence this is actually a problem?" forces the conversation to become concrete.
Propose an experiment. "What if we tried the simple version first and measured?" Usually the answer becomes obvious fast.
Set a decision deadline. "Let's discuss for 15 more minutes, then make a call." Prevents endless debate.

When tempted to refactor:

Ask: "Is this blocking customer value?" If no, it probably can wait.
Calculate opportunity cost. What could you ship instead with that time?
Get customer feedback first. Sometimes you discover you built the wrong thing entirely, making the refactor irrelevant.

The Uncomfortable Truth

Your customers don't care about your stack.
They don't care if you chose Vue or React.
They don't care if you refactored your prop drilling spaghetti into an amazing Context solution.
They don't care about your bundle size, your performance benchmarks, or your elegant architecture.
They care if you solved their problem.

And here's the thing that took me years to accept: this doesn't mean your technical skills don't matter. They absolutely do.

But they matter in service of customer value, not as an end in themselves.

The best engineers I know aren't the ones who write the most elegant code. They're the ones who ship the right things at the right time, balance quality with speed, and know when good enough is actually good enough.

🤔 Questions to Reflect On

When's the last time you chose a simpler solution over a more impressive one?
Are you debating technical decisions to solve real problems, or to demonstrate expertise?
What would happen if you shipped your current "not quite ready" solution and iterated from there?
How much of your technical quality focus is actually serving customers vs. serving your own standards?

🎯 The Bottom Line

Sometimes the MVP is the answer you need.

Not because it's perfect. Not because you're proud of it. But because it gets you to feedback, learning, and real customer value.

Verify, then iterate.

Everything else is just debate.

How do you balance technical quality with shipping value to customers? Share your approach in the comments—I'd love to hear how other developers navigate this tension.

If you want to dive deeper into making technical decisions that actually matter, check out my book From Hello World to Team Lead.

Photo by Fotis Fotopoulos on Unsplash

"Your Plans Aren't Realistic": The Brutal Honesty That Prevents Burnout

Tim Lorent — Wed, 12 Nov 2025 13:18:06 +0000

I spent three months on the couch with zero energy.

Not tired. Not unmotivated. Zero. Like someone had unplugged my battery and thrown away the charger.

Looking back, I know exactly what I needed before I got there: someone to tell me the truth. Someone to look at my plans—the side projects, the courses, the "just one more thing" syndrome—and say:

It would've hurt. But not as much as the collapse.

The Myth of "More Is Better"

Here's what nobody tells ambitious developers: your hunger to grow can be just as dangerous as apathy.

We celebrate hustle culture. We admire people who code all day, learn all night, and somehow still ship side projects on weekends. We wear
exhaustion like a badge of honor.

And then we wonder why burnout rates in tech keep climbing.

I was that person. Junior dev by day, studying JavaScript at night, building a portfolio on weekends. Every article I read told me I wasn't doing enough. Every LinkedIn post made it seem like everyone else was learning faster, building more, advancing quicker.

So I added more. And more. And more.

Until my body said "enough" and shut down completely.

🚨 When Ambition Becomes Dangerous

The tricky thing about burnout is that it sneaks up on you. One day you're tired but functional. The next day you can't get off the couch.

But the warning signs are there if you know where to look:

Red flags:

Your to-do list grows faster than you can complete it
You feel guilty every time you relax
You're learning things you "should" know, not things you actually want to know
Rest feels like weakness
You can't remember the last time you hung out with friends without checking Slack
You keep adding "just one more thing" to your plate

What it actually means: You're running a sprint at marathon pace. And your body will force you to stop whether you want to or not.

The Conversation Nobody Wants to Have

Now when I'm coaching developers who are heading straight toward burnout, I have a conversation I wish someone had with me.

It's uncomfortable. Sometimes people don't want to hear it. But it's the kindest thing I can offer.

Step 1: Name what you're seeing

"I notice you're learning React, studying for AWS certs, building two side projects, and working full-time. That's a lot."

Not judgment. Just observation. Let them hear their own reality reflected back.

Step 2: Ask the hard question

"If you keep this pace for the next six months, where do you think you'll be?"

Most people pause here. Because deep down, they know the answer.

Step 3: Share the truth they need to hear

"Your plans aren't realistic. Not because you're not capable—you clearly are. But because you're human, and humans need rest."

This is the part that stings. But it's also the part that can save them.

Step 4: Redirect to what actually matters
There are more important things than work:

Family and friends who will be there when your code isn't
Health that compounds over decades (who looks back on their deathbed thinking "I wish I worked more"? Probably only Elon. I rest my case.)
Joy that comes from doing things just because you enjoy them

Step 5: Offer a better path

Small daily focus beats massive unsustainable plans every time.

Twenty minutes of focused learning each day will take you further than weekend marathons that leave you burned out.

You don't need to learn everything. Focus on what energizes you, not what you think you "should" know.

Rest is part of growth, not a break from it. Your brain needs downtime to process and consolidate what you've learned.

The Shift That Changed Everything

When I finally accepted that I couldn't do it all, something unexpected happened.

I got better at the things I actually cared about.

Instead of spreading myself thin across five learning goals, I picked one. Instead of grinding every night, I learned for 30 minutes and then closed my laptop. Instead of feeling guilty about rest, I recognized it as necessary.

My growth didn't slow down...it sped up!

Because sustainable beats spectacular. Every. Single. Time.

✅ How to Apply This

If you're heading toward burnout:

Write down everything you're trying to do. Just seeing it on paper might be enough to realize it's too much.

Ask yourself: "If I could only keep three things, what would they be?" Cut the rest. Not forever—just for now.

Schedule rest like you schedule meetings. If it's not on the calendar, it won't happen.

Check in weekly: "Am I energized or drained?" Adjust accordingly.

If you're coaching someone toward burnout:

Name what you see without judgment. "I notice you're..."

Ask permission to be honest. "Can I share something that might be hard to hear?"

Speak from your own experience, not from authority. "When I tried to do everything, here's what happened..."

Offer an alternative, not just a warning. "What if instead of five goals, you focused deeply on one?"

🤔 Questions to Reflect On

What are you doing out of genuine interest vs. what you think you "should" be doing?

When's the last time you felt energized after coding, rather than drained?

If you could only keep three learning goals, what would they be?
What would it look like to give yourself permission to do less?

The Bottom Line

Sometimes the kindest thing you can tell an ambitious developer is that their plans aren't feasible.

It hurts to hear. But it's way better than the collapse that comes without it.

You don't need permission to slow down, but I'll give it to you anyway: You're allowed to do less. You're allowed to focus on what energizes you. You're allowed to rest.

Your career is a marathon, not a sprint. Pace yourself accordingly.

Have you ever had to have this conversation with someone, or needed someone to have it with you? Share your story in the comments—sometimes we all need to hear we're not alone in this.

If you want to dive deeper into recognizing burnout patterns before they happen, join my upcoming masterclass on sustainable growth. I'll share the frameworks I wish I'd known before I ended up on that couch.

Photo by Nubelson Fernandes on Unsplash

The Skills That Actually Make You Senior (Hint: They're Not What You Think)

Tim Lorent — Tue, 11 Nov 2025 10:22:48 +0000

I used to think becoming a senior developer meant mastering advanced algorithms, design patterns, and maybe picking up a third framework.

Nope.

The moment I realized this was during a project refinement. We were going to build this fantastic feature that the whole team was convinced would be awesome. My product owner asked one question: "But did it solve the customer's actual problem?"

Uhm...

The Myth of "Technical Excellence = Seniority"

Some developers believe the path to senior looks like this:

Master advanced TypeScript
Learn system design
Contribute to open source
Get really good at LeetCode

And sure, technical skills do matter! But the gap between junior and senior developers is rarely just technical.

I learned this the hard way. And recently, when I interviewed Nadia Makarevich (author of Advanced React), she said something that crystallized everything: "Code by itself is mostly worthless."

Your perfectly crafted React component means nothing if it doesn't solve a real business problem. Your elegant algorithm is worthless if it's solving the wrong pain point.

What Actually Makes You Senior

Senior developers don't just slam dunk code into a repository (because of my height I will never be able to do a slam dunk...sad). They connect technical solutions to real business needs.

Here's what that looks like in practice:

Before writing any code, they ask:

What customer problem does this solve?
Why is product prioritizing this over other features?
What's the business impact if we ship this vs. delay it?

During development, they:

Identify every stakeholder (not just other engineers)
Create roadmaps that align with business goals
Break work into tasks that make sense to non-technical people
Update stakeholders throughout—not just at the end

After shipping, they:

Measure impact, not just completion
Connect their work to customer outcomes
Understand what marketing, product, and support need

The technical implementation? We've got AI for that now. The business thinking? That's what separates developers who code from developers who create impact!

Why This Is Hard (And Why Nobody Teaches It)

I spent years thinking "business stuff" wasn't my job. I'm an engineer, so surely my job is to write code.

That mindset kept me junior far longer than it should have.

The problem is that there's not a lot of talk about these skills, according to Nadia. I've seen it too: bootcamps teach React, online courses teach algorithms...but who teaches you how to:

Translate customer pain into technical requirements?
Prioritize features based on business impact?
Communicate technical trade-offs to non-engineers?
Collaborate with marketing, product, and support?

These skills are usually learned through painful trial and error.

How to Actually Develop Business Thinking

When I became a team lead, I had to learn this fast. Here's what actually worked:

Start with stakeholder mapping

Next time you get a feature request, pause. Before you open your editor, identify:

Who requested this and why?
Who will use this feature?
Who needs updates during development?
Who measures success of this feature?

This simple exercise changes a lot. Suddenly you're not just implementing a ticket—you're solving a real problem for real people.

Learn to ask "why" three times

Product says: "We need a dark mode."

Why? "Users are requesting it."
Why do users want it? "They work late and it hurts their eyes."
Why is this a priority now? "Customer surveys show it's blocking enterprise deals."

Now you understand the business context. Maybe you realize a "focus mode" with reduced brightness solves the same problem faster. Maybe you discover the real issue is font contrast, not colors.

Attend meetings outside engineering

This was uncomfortable at first. But sitting in on product planning, customer calls, and marketing syncs taught me more about business thinking than any engineering meeting.

You don't need to attend everything of course. But sitting in once a quarter, if possible, helps you understand how other departments work—and how your code impacts them.

Respect (and admire) other departments

As Nadia Makarevich mentioned in our interview: "respect and admire other departments".

Marketing isn't "just doing ads." They're understanding customer psychology, crafting messages, and driving revenue.
Product isn't "telling us what to build." They're balancing customer needs, business goals, and technical constraints.
Support isn't "handling complaints." They're the frontline understanding where your code actually breaks down.

Green Flags You're Developing Business Skills

You know you're on the right track when:

You find yourself asking "why" before "how"
You can explain your work's impact without technical jargon
You proactively update non-engineering stakeholders
You push back on features when the business case isn't clear
You see patterns between customer problems and technical solutions
You get invited to planning meetings outside engineering

Try This Tomorrow

Next time you get a feature request:

Pause before coding—Don't open your editor yet
Identify stakeholders—Who cares about this beyond your team?
Understand the business goal—What customer problem does this solve?
Plan communication—When will you update people, and what will you tell them?
Ask one "why" question—Even if you think you know the answer

The Uncomfortable Truth

You can stay a great coder forever and never become senior.

I've seen developers with 10 years of experience still writing code in isolation, wondering why they're not getting promoted. Meanwhile, developers with 3 years of experience who understand business context become team leads.

The main difference? Business thinking!

Your perfectly crafted code doesn't matter if it solves the wrong problem. Your elegant architecture is worthless if nobody understands why it exists.

Senior developers bridge the gap between technical execution and business impact.

Where to Start

If this resonates but feels overwhelming, start small:

This week: Before starting your next task, identify three stakeholders and one business goal.
This month: Ask to shadow a product manager for a customer call.
This quarter: Attend one meeting outside engineering and share one insight back with your team.

You don't need to become a business expert overnight of course, but start seeing your code as a solution to real problems, not just an implementation of technical requirements.

What business skills have helped your career growth? I'd love to hear what patterns you've noticed—drop a comment below.

If you want to read my full interview with Nadia Makarevich (and Kent C. Dodds), where we dive deeper into what actually makes developers senior, check out my book From Hello World to Team Lead. Both conversations are packed with insights that nobody talks about in tutorials.

P.S. I donate 10% of all book proceeds to tech education charities (TechMeUp, SheSharp, GirlCode, HackYourFuture). Your growth helps others grow too.

Why I Check Every Ticket Before Writing Code (And You Should Too)

Tim Lorent — Sun, 09 Nov 2025 15:39:22 +0000

A simple checklist that saved a developer from wasting hours on impossible scope

The Message That Made My Day

"Yes, I applied the ticket checklist and I immediately communicated to my PO that something was not possible and that we should resize the ticket 🎉"

This message hit my inbox yesterday.

A developer read my book, grabbed the Ticket Checklist, and applied it to their next feature. Within minutes, they spotted something: a requirement in the ticket couldn't be done the way it was scoped.

Instead of diving into code and discovering this halfway through (or worse, during code review), they caught it upfront. They messaged their Product Owner, explained the blocker, and got the ticket resized—before writing a single line of code.

This is what good systems do.

They don't slow you down. They save you from wasted work.

Why Most Developers Skip Planning

Here's what usually happens:

You get assigned a ticket. You read the description. Maybe glance at the designs. Then you open your editor and start coding.

Three hours later, you hit a wall:

The API endpoint you need? Not ready yet.
That edge case you didn't consider? Breaking everything in QA.
The scope that seemed clear? Actually vague and missing critical details.

So you backtrack. Rewrite code. Ping people in Slack. Wait for answers.

You've just wasted hours you'll never get back.

Most developers do this because planning feels like extra work. You want to build, not sit around asking questions. You feel pressure to show progress.

But let me tell you: 5 minutes of planning saves hours of rework.

The Ticket Checklist (What Actually Matters)

Before I write any code, I ask four questions:

1. What's the actual scope?

What are we building, specifically?
What's explicitly out of scope?
Are there dependencies on other teams or features?

If I can't explain the ticket in one clear sentence, it's not ready yet.

2. Are designs ready?

Are designs finalized, or will they change?
What happens on mobile? Tablet? Small screens?
Are there edge cases the designs don't show?

Designs that "look done" often have gaps. I check first.

3. Are there dependencies or API blockers?

Is the backend ready, or do I need to mock data?
Are endpoints documented?
What's the expected response structure?

Nothing kills momentum like discovering the API isn't ready halfway through development.

4. What edge cases might break this?

What happens if data is missing?
What if the user does something unexpected?
Are there permission or role considerations?

Edge cases are where bugs hide. Thinking about them early means fewer surprises later.

How to Start Using This

You don't need a fancy system. Just try this:

Pick your top 2 pain points: If you often hit API blockers, focus on dependencies. If designs change mid-development, focus on design readiness.
Apply it to your next ticket: Before opening your editor, spend 5 minutes answering those questions.
Adjust based on your context: Agency work? Focus on scope and deadlines. Product team? Focus on long-term maintainability.

The Deeper Lesson

This isn't really about checklists.

It's about thinking like a senior developer.

Juniors see a ticket and think: "How do I code this?"

Seniors see a ticket and think: "What could go wrong, and how do I prevent it?"

They don't code faster. They waste less time.

They anticipate problems, ask clarifying questions upfront, and communicate proactively. They own outcomes, not just tasks. The checklist trains that muscle!

You're Not Being Slow—You're Being Smart

A 5-minute checklist prevents:

Hours of rework
Scope surprises mid-development
Tense conversations with your PO
Code that doesn't meet expectations

And it builds trust. Your team sees you're thinking ahead, asking good questions, and taking ownership. That's what separates good developers from great ones.

What's one question you wish you'd asked before starting your last feature? Drop it in the comments—I'd love to hear what trips people up most.

If you want the full Ticket Checklist (plus 9 other practical frameworks), I explore them in From Hello World to Team Lead. The systems are built for real work, not tutorials.

You’ll Learn More in 3 Months on the Job Than 2 Years of Tutorials

Tim Lorent — Tue, 04 Nov 2025 08:58:44 +0000

Your first dev job will teach you more in three months than two years of tutorials ever could.

Most juniors don’t believe that (I certainly did not). They’re stuck in the “just one more course” loop — convinced the next certification or project will finally make them ready.

But real growth doesn’t happen before the job. It happens because of it.

The Myth of “Ready”

I applied to my first dev job feeling completely unprepared. Spent the first week thinking someone in HR had made a terrible mistake.

And yet — within a month, I’d learned more about version control, debugging, and reading other people’s code than six months of online courses ever taught me.

Because tutorials can’t simulate what it’s like to fix production bugs at 9PM or explain your logic during a code review.

Why the Job Changes Everything

Once you’re in a real environment, everything shifts.

You learn how to:

Read messy legacy code and make sense of it.
Ask better, sharper questions.
Navigate feedback without taking it personally.
Handle ambiguity when specs aren’t crystal clear.

That’s the real developer education — and it starts on day one.

What to Look For in Your First Job

Don’t just apply anywhere. Look for teams that actually invest in juniors.

Green flags:

Structured onboarding
Pair programming
Regular code reviews
Patient seniors who want to mentor

Red flags:

No documentation
Everyone’s too busy to help
They expect you to “hit the ground running” on day one

You’re Ready Enough

That feeling of not being ready? It never fully goes away. Even senior devs feel it.

So apply anyway. Because the fastest way to grow is to start — not to prepare forever.

You’ll learn by doing, failing, and improving.

That’s how every great developer started.