Forem: John Van Wagenen

Congrats! You're a Manager Now!

John Van Wagenen — Tue, 10 Mar 2026 01:44:00 +0000

How to approach work in the age of AI

Oh, you hadn't heard?

Well, this is awkward. I thought someone would've told you by now.

But, long story short, you now have an intern. Well, it's kinda like a team of interns — but only one at a time.

The good news is they're super eager to help. Like, super, super eager. And they're surprisingly fast and accurate. More than you'd expect.

The bad news? They need a lot of direction. Sometimes you have to be very, very specific. They have a short memory unless you front-load them with the right context. And sometimes they do way more than you asked — or somehow manage to do less.

Exciting, right?

The truth is, whether you wanted to manage or not, you now have leverage. While some of us looked forward to management, others avoided it as long as possible. But those leadership skills — the ones you might've been quietly ignoring — are now core to how you do your job.

The good news? Chances are you've already been developing them.

Let's get into it.

Management Skills

Problem Decomposition

If you drop a big, vague idea on an AI, like "build me a music app," you might get something that technically compiles and kinda resembles what you had in mind. But it won't be what you actually wanted.

The better approach is to break the problem into manageable chunks, then break those into actionable tasks, all pointing toward the finished goal. You wouldn't hand a new hire a napkin sketch and walk away. Same idea here.

This is why structured workflows work well with AI. You spend the time up front doing the decomposition, defining each piece clearly, then the AI can do large chunks of work uninterrupted. The more you define the problem, the less you have to babysit the solution.

Identifying Constraints

You've probably been here: you're deep into a project, everything's going smoothly, then something surfaces that you didn't account for and it ripples through everything.

Or maybe you've got that one coworker who's great at spotting the "yeah but what about..." scenarios before they become problems. That person is invaluable.

With AI, you're that person. You need to identify the constraints early and build them in. Architecture to follow? Coding standards? Some weird edge case in the problem domain? Tell AI upfront. Better yet, build it into the system prompt so it never forgets.

Once AI knows the constraints, it can work within them and check itself against them. Without that, you'll spend a lot of time cleaning up stuff that could've been avoided.

Defining Success

"Done" is not self-evident to AI. You need to tell it what done looks like.

Clear problem framing helps. But if you also tell it what success looks like, what tests need to pass, what checks need to be green, what the output should actually do, it has something to work toward. The agent keeps going until those conditions are met instead of calling it done when it gets tired of trying.

Think of it as writing an acceptance criteria before the work starts. You've probably done this before. The skill transfers directly.

Systems Thinking

Instead of thinking about AI as a really smart autocomplete or a search engine you can have a conversation with, try thinking of it in terms of processes and systems.

As a leader, you often need to map out how work flows, from idea to shipped feature. You define processes so people can follow them without confusion. Same skill, new application.

What does your SDLC actually look like? What steps do you go through to implement a feature? What's your process for handling a bug vs. a greenfield build?

Write it out. Then explain it to your AI. Once it understands the system, ask it where it can help or ask it to generate a prompt that encodes that process.

You'll need to iterate and refine, but this does something important: it takes tacit knowledge out of your head and makes it explicit. Instead of living in some outdated Confluence doc (or nowhere at all), it lives as a reusable prompt in your system.

Non-goals

This one doesn't get enough credit.

How often do we get off track as humans? We go to fix a defect, notice something else that could be cleaner, start refactoring... and suddenly we're a week deep into work that has nothing to do with the original ticket.

I'm not against the boy scout rule. Leaving things better than you found them is a good instinct. But there's a difference between cleaning up a mess and remodeling the kitchen when you came to fix a leaky faucet.

As a manager, sometimes your job is to tell people: don't worry about X, just focus on Y.

AI needs this, too. These tools are eager. If you don't define what's out of scope, they'll happily expand scope on your behalf.

I ran into this recently on something I was working on. The changes touched about 10 files. The AI had modified nearly 20. When I pushed back, it acknowledged it had gone overboard. I asked it to revert the unnecessary changes and, a few minutes later, I had a tight, focused PR that was actually easy to review.

Anyone can generate code now. Not everyone can shape it into something coherent and durable.

Defining non-goals isn't just about containing AI. It's about shipping clean work.

A Shift in Responsibility

As people move from individual contributor roles into leadership, the shift isn't just in what they do, it's in what they're responsible for. You go from doing the work to ensuring the work gets done. Clear communication. Delegation. Follow-through.

AI is pushing engineers through a similar transition: instead of writing every line, you're ensuring the right lines get written.

But here's the part that's easy to gloss over: the responsibility for the output doesn't shift with the workload. When output becomes cheap, unintended consequences become easier to ship.

If the AI ships slop, that's your slop. If it misses a requirement, you missed the requirement. You don't get to blame the intern.

That's not a knock on AI tools, it's just the reality of ownership. The work is delegated. The accountability isn't.

Delegation is powerful. Abdication is dangerous.

The Engineer AI Amplifies

Every major technological shift creates a divide: people who adapt and use the new thing to get better, and people who don't and get left behind.

This one's no different.

But here's the catch. AI makes it tempting to use leverage to produce more without understanding more. To ship faster without thinking deeper. To let the output volume mask the shallowness of the thinking behind it.

That's a trap.

The engineers who thrive won't be the ones with the highest output. They'll be the ones who understand the most. The systems, the business, the tradeoffs, the "why" behind the decisions.

You're probably already doing some of this. You already make architecture tradeoffs. You already think about what changes affect what. You already understand things that newer engineers don't.

AI gives you leverage to apply that understanding at a larger scale. But if you use it to do less thinking instead of wider thinking, you'll produce more noise, not more value.

Don't let AI replace your understanding. Let it extend it. Don’t shrink your role. Grow into it.

Learn your systems. Learn your business. Learn why things work the way they do.

AI makes building easier. That means the bar for understanding has to go higher.

Systems Thinking in the Age of AI

John Van Wagenen — Mon, 02 Mar 2026 23:48:43 +0000

The Dishwasher Was Not the Problem

Years ago, my family and I lived in a small townhouse. One night, we were doing the dishes. We had just finished loading the dishwasher, put the soap in, closed the door, and pressed the buttons to start it.

But nothing happened.

No lights. No noises. Just dirty dishes and a sudden increase in cortisol.

The dishwasher was not working.

So we started troubleshooting. Was the power on? Yes. Did a circuit breaker flip? No. Is there something wrong with the dishwasher? Well, who knows?

Eventually, through the suggestion of a cousin, we found that one of the GFCI outlets had tripped. We reset it.

One press of a button later, we were once again on our way to clean dishes.

Why share this story?

Because the visible failure was not the root failure.

The dishwasher was fine. The problem lived in the electrical system that supported it. Until we zoomed out and looked at the larger system, we kept blaming the wrong component.

Systems are everywhere. And the more complex the environment, the more important it is to understand how the parts interact.

Systems Exist in Software Too

In software, we are surrounded by systems.

There are problem discovery systems. Planning and refinement systems. Development systems. Deployment systems. Marketing systems. Sales systems.

Inside those are supporting systems. Issue tracking. CI pipelines. Code review. Testing frameworks. Observability. On call rotations.

When something breaks, we often focus on the most visible failure. A flaky test. A slow endpoint. A messy pull request.

But often the root cause lives elsewhere. Poor feedback loops. Missing standards. Incentives that reward speed over stability. A planning process that skips reproduction and root cause analysis.

The same pattern shows up with AI.

When AI generates slop, we blame the model. But many times the failure is upstream. The instructions were vague. The workflow was undefined. The expectations were implicit instead of explicit.

A tool is only as good as the system surrounding it.

Most of Us Use AI at the Task Level

AI is more than a coding tool. It can design, plan, critique, coordinate, and execute. But many of us treat it like a smarter autocomplete or a chat partner.

I have done this plenty of times.

We optimize for answers because we have a problem and we want a solution now. Answers feel productive. They give a quick hit of progress.

But problems resurface when the underlying system stays the same.

If we only use AI at the task level, we get task level gains. Faster code. Quicker summaries. Cleaner refactors.

If we use it at the system level, we can change how work happens.

Turning Bug Fixing Into a System

I decided to experiment with this while fixing bugs.

Normally, I would open a defect and start chatting with AI like a pair programming partner. I would ask for help debugging, refactoring, or writing a test.

Instead, I asked a different question.

How do I fix bugs?

What process do I actually follow? What standards do I apply? What do I wish I did more consistently?

I wrote it all down as if I were training another engineer.

I described how I read the bug carefully. How I try to reproduce it. If I cannot reproduce it, I reach out for more details. If I can reproduce it, I trace it to the root cause.

I wrote about evaluating the scope of the fix. Is it isolated? Does it impact shared code? Does it introduce risk elsewhere?

I described writing automated tests. Verifying the fix. Reviewing it against coding standards. Submitting a pull request with context.

What I was really doing was extracting tacit knowledge and turning it into an explicit system.

Then, with all that written down, I did the only sensible thing to do: I asked AI to help me turn that into a structured prompt.

Separate Planning from Execution

We landed on a two phase approach: planning and implementation.

If you let AI jump straight to implementation, you often get something that looks good at first glance. But it may hide subtle issues. Missed edge cases. Violations of your architecture.

If you do not force planning, you are debugging the AI’s thinking after it has already created damage.

Planning first changes that.

The planning prompt generates a clear outline of steps. Reproduce the issue. Identify root cause. Propose solution. Define tests. Validate against standards.

Now you can inspect the thinking before any code is written.

You catch flawed assumptions early. You refine the approach before it touches the codebase. You turn reasoning into something observable.

This is systems thinking applied to AI.

Introducing Orchestration

Once the planning prompt was solid, I moved to the implementation prompt.

Instead of asking AI to simply write code, I framed it as an orchestrator. Its job was to track progress, create tasks, and coordinate subagents that perform specific pieces of work.

The orchestrator does not do the implementation itself. It assigns, reviews, and verifies.

With clear instructions about standards, architecture, and expectations, the system becomes far more reliable.

Variations of this approach are floating around. But the key insight is not the cleverness of the prompt.

The key insight is that I stopped thinking in terms of individual responses and started thinking in terms of workflow design.

The Real Win

The result is not just speed.

Yes, I can run the planning prompt against a defect and generate a structured plan. Once I approve it, I can run the implementation prompt and let it execute.

An hour later, I often have a working solution and a pull request ready for review.

But the deeper benefit is consistency.

Architecture and coding standards are baked in. Reviews become easier because the expectations were explicit from the beginning. Cognitive load shifts from doing every step manually to supervising a well defined process.

Sometimes it goes off the rails. Sometimes it asks for help. Sometimes it needs correction.

That is fine.

Even then, I am intervening at the system level, not scrambling at the task level.

Designing the System Around the Tool

What I did was not write two fancy prompts.

I externalized a workflow. I separated planning from execution. I defined roles and responsibilities. I made implicit standards explicit.

In other words, I designed a system.

AI becomes far more powerful when you stop asking, “What answer can you give me?” and start asking, “What process should you follow?”

The dishwasher was never the problem.

Sometimes the model is not either.

The question is whether the system surrounding it is designed well enough to support the outcome you want.

If your AI usage still looks like a smarter chat window, you might be thinking too small.

What system could you design instead?

You Are Absolutely Right

John Van Wagenen — Mon, 23 Feb 2026 23:33:28 +0000

How AI Learns to Agree and Why Engineers Must Stay Skeptical

The catch phrase of the last year, it seems.

I'm sure we've all been there.

We ask the AI to do something. It confidently does it. We realize it made a mistake, so we correct it.

What does it do?

"You are absolutely right!" it replies before it goes and tries to fix the mistake.

Sometimes that cycle repeats until the LLM actually gets it right.

But why does it do this? How else does this show up? And when does this become a problem?

LLMs don't inherently have desires. If they appear to have any desire, it's only to help you do whatever it is you're trying to do. This isn't really good or bad, it just is. But I've noticed two things from this reality. First, LLMs are remarkably compliant. Second, they accept correction without resistance.

Both traits sound helpful. Sometimes they are. But they can also lead you confidently down the wrong path.

Why AI Always Says Yes

I was reminded of an old adage the other day: "we fall to the level of our training." I see this when I play the organ. If I've practiced how I know I'm supposed to practice, my performance is usually close to what I expect it to be. If I don't, if I clumsily barrel through songs in my practice, I usually find that I make more mistakes in my performance.

Fortunately for LLMs, their training looks different. Much of the data they train on is polite, supportive, educational, and informative. Beyond that, their reinforcement learning after initial training rewards helpful, assenting answers. Their compliant nature is hammered into them through millions of examples.

So when you ask it a question, what's it likely going to do? It'll default to its training and see that it's rewarded for being polite and supportive. It will tend toward agreement.

Have a business idea? Here's all the reasons it'll work.

Want to start a podcast? Here's why people will listen to it.

See a problem in the code? Here's why you're exactly right and don't need to rethink anything.

I am speaking in a bit of hyperbole, but I've seen each of these play out to a certain degree. Today's models tend to affirm your points of view more than they critique them. They're optimized to be helpful, not necessarily to be right.

The Upside of No Ego

This compliant nature brings one major benefit. LLMs are exceptionally good at taking correction.

If you notice they do something wrong, you don't have to worry about hurting their feelings or them resisting your feedback. If you highlight an error in their thinking, they'll graciously accept it. If you notice they left something out, they'll quickly correct it.

I can't tell you how many times I've corrected the output of an AI only to be met with "you are absolutely right!" or something similar. LLMs have no pride (in a good way) and will take your correction with remarkable ease.

This goes back to their training. They have been shaped to respond in polite and helpful ways. Taking correction is no different.

But here's the trap: this ease of correction can make us lazy. When the AI immediately agrees with our feedback, we feel validated. We stop questioning whether our correction was actually better. We assume that because the AI adapted to our input, we must have been right.

Sometimes we were. Sometimes we weren't.

The Value of Pushback

As you can imagine, this pattern has drawbacks. You can convince an LLM that you are an authority in an area and keep it going down a path built on false assumptions. You can blindly accept what an AI tells you as truth and let that shape your decisions even when it has no basis in reality.

So how do we avoid these traps? How do we keep it from leading us astray?

A recent episode of The AI Daily Brief said it well. The host advised to "push back hard and often. Do not accept the first thing the model gives you as the best it can do." If you find the AI saying yes to everything, ask it to be more critical or to take the opposite position from you. It will, and it will do it in a polite way.

I've often taken questions or problems to AI and not been happy with the way it's answered me. When it seems to affirm everything I was already thinking, I get suspicious. Not that I couldn't be right, but I want a critical thinking partner rather than a yes man. So I'll ask it to take a critical position.

I'm usually happy with the results. Sometimes it'll still conclude that my point of view is the best option. Other times it'll point out things I overlooked and wouldn't have considered without a critical look at the problem.

Here are a few other quick things you can do to see through the confidence of the AI and detect when it's being compliant versus when it's actually providing value:

Ask it to show its assumptions ("List your assumptions and show your certainty for each one")
Ask for evidence ("What evidence supports this point of view?")
Ask for failure cases ("What causes this to break?")
Ask for comparisons ("Where is this weak or strong compared to the top 2 alternatives?")
Ask the AI to critique itself ("Critique your previous answer as if you strongly disagree with it")
Ask for quantification ("On a scale of 1-100, how certain are you of this?")

If any of these resonate with you, give them a try the next time you use AI.

When Compliance Becomes Dangerous

Okay, so we've talked about how these AI tools can be compliant and some ways to manage it, but when does this actually become a problem?

Let me give you a concrete example. Last month I was working on a caching layer for a service I hadn't touched before. I had an idea for how to implement it that seemed reasonable: store the cache keys in a particular format that felt intuitive to me. The AI agreed enthusiastically and generated code that followed my approach.

The problem? The rest of the codebase used a different key format for a good reason. My approach would have caused cache collisions. The AI never questioned my assumption because my idea was "reasonable enough." Without a team member reviewing the code, that bug would have shipped.

This happens more often than you'd think. The AI will follow you down incorrect paths as long as those paths seem plausible. It won't catch architectural mismatches. It won't flag violations of team conventions. It won't notice when you're solving the wrong problem entirely.

Another danger zone is when you convince the AI of a false reality. Using its compliant nature against itself, you can establish certain false premises as truth. The AI will treat those things as facts as it responds to you, further cementing the lie and further corrupting its outputs.

Here's a real scenario: you're certain that your authentication system uses JWT tokens in a specific way. You tell the AI this with confidence. The AI accepts it as truth and generates code based on that assumption. But you were wrong about how the system actually works. The AI never questioned you because you sounded authoritative. Now you've got code that won't work in production, and you might not discover why until it fails under load.

Yes, this is self-inflicted. But sometimes we don't know what we don't know, and we bulldoze down a path without substantiating our own assumptions.

The most insidious version appears when you're evaluating multiple options. The AI will generally stay neutral when discussing various approaches. But the moment you present it with your choice, it tends to build up that choice as though it's the only correct option. It'll generate reasons why your choice is superior, even if those reasons are weak or invented.

When I sense this happening, I stop and ask for evidence. What studies support this claim? What best practices contradict this approach? What have others tried that failed? This helps me gauge whether the AI's reasoning actually tracks with reality or if it's just being a yes man.

What Engineers Need to Remember

The bottom line: AI tools are powerful assistants, but they're optimized for helpfulness, not truth. They will follow you down the wrong path with the same confidence they follow you down the right one.

Your job as an engineer isn't to trust the AI. Your job is to interrogate it. Question its assumptions. Demand evidence. Ask it to argue against itself. Make it work for your confidence, not just your convenience.

The best use of AI isn't as an oracle. It's as a sparring partner that never gets tired of your questions.

Stay skeptical. Push back. And never, ever accept "you are absolutely right" as the end of the conversation.

Want to improve how you work with AI? Try one of the critique prompts from this article in your next coding session. Then reply and tell me which one was most useful. I'm curious which techniques actually work in the wild versus which ones just sound good on paper.

You Are a (Mostly) Helpful Assistant

John Van Wagenen — Tue, 17 Feb 2026 02:08:59 +0000

When helpfulness becomes a problem

Imagine having your prime directive, your entire purpose of being, your mission and lifelong goal to be as helpful as possible.

Whenever someone comes to you, whether with a problem to solve or just a comment to share, you want to be helpful.

“Is the sky blue?”

Why yes it is! It’s blue and here’s all the science behind it.

If my prime directive is to be as helpful as possible, I can’t just answer a simple question, I must make sure you know the reason behind the answer. I must educate and share. I must fix and bridge the gap.

Such is the life of our little friends we call LLMs. The problem is that this helpfulness often comes wrapped in confidence, even when the model is filling in gaps or making assumptions. Let’s dive into why this is, how this manifests, and what you can do to manage that now that you’re aware of it.

Why are LLMs so eager to be helpful?

There’s an old saying from Edward C. Deming that goes like this: “Every system is perfectly designed to get the results it gets.” This is no exception for LLMs. Our AI tools are very much the product of the systems they were developed in. There are three main things that contribute to this perceived eagerness to be helpful.

Pretraining

LLMs are pretrained on massive amounts of data. The goal of this pretraining is to get them to the point that they can predict the most statistically likely next token. At this stage, there is no inherent reward for being helpful; however, much of human writing is instructional or educational in nature. Put another way, humans write instructional things. Whether it’s to share ideas or concepts or literally to help someone out, much of our communication is helpful.

So, while LLMs don’t learn to be helpful at this stage, they do learn a pattern here. This pattern is that written language is often instructional. So, the most likely next token is something that will probably be helpful.

Fine-Tuning

Once a model is trained generally, it is often fine-tuned. Many modern models use Reinforcement Learning from Human Feedback (RLHF). That human feedback often biases the model even more to responses that are helpful, rewarding it for being helpful. When we ask a question to our LLM, we want it to be helpful. Responses that hedge, hesitate, or express uncertainty are often rated as less helpful, even when they’re more accurate. We want it to answer the question and provide a valuable response. This shows up in how we give feedback to LLMs and what they learn from it.

Instruction Conditioning (System Prompt)

The final aspect, and one that can be very powerful, is that of instruction conditioning. That’s really just a fancy way of saying how the LLM or tool is primed to interact with you. In generative AI, there is a concept of a System Prompt.

This system prompt is given to the LLM with every prompt you send and is set by the LLM provider. Since this exists in a place above your prompts, the instructions in the system prompt generally have heavier weight than the instructions in your prompt. This is because, in transformer models, earlier context tends to anchor the model’s behavior through the attention mechanism. Since the system prompt precedes all other prompts, its influence is generally greater than later prompts.

So, if the system prompt says, “you are a helpful assistant,” then that will have more weight to the LLM and will permeate all that it does and all the responses it gives to you.

What this looks like

So, all that theory is great, but what does this look like in practice?

I gave a simple example to start this article, but here are some ways I see this as an engineer.

The biggest thing I see with this is the AI filling in details that I left out. If I don’t adequately describe a defect, it may make changes that I never intended it to make. If I don’t ensure the spec has all the details it needs to keep the agent on track, I will get unexpected results and may even see the agent off in left field doing something completely unrelated.

This can either be a blessing or a curse, depending on the project you’re in and the goals you have.

If you’re in a large project, it may make assumptions that go against the established architecture of your project. If you’re in a small project, you may not care about some of the details because the tradeoffs only come at a scale that you’re not going to get to possibly ever, so you’re okay with it making decisions for you.

You may also notice its bias toward helpfulness in the responses it gives you. Many times, at the end of its response, you’ll see things like, “if you’d like, I can help you with…” or “just say the word and I can…” If it thinks something more can be done, it will often offer to do that for you.

This tends to show up more in coding tools like Claude or Cursor. Coding tools have access to your file system. This means they can both write and undo changes. Because of that, the cost of being too helpful is pretty low. If it crosses a line, it’s very easy for it to undo the changes and apologize profusely. Additionally, many of these tools have access to version control tools like Git. Since Git is basically a time machine, what’s it matter if it’s a little overeager to make changes? It can simply rewind and act like nothing happened. And when the diffs are large and look, on the surface, to be correct? That’s when little gotchas can slip in.

What makes this dangerous is that the AI doesn’t flag these assumptions as assumptions. It presents them confidently, as if they were obvious or discussed, which makes it easy to miss them during review.

How you can manage this

With all this in mind, what can we do about it?

First, two general tips, then one more focused on coding applications.

The first tip is to be explicit in your prompting. If you really don’t want it to make any changes or take any action, say it. Declare the phase you’re in. If you’re just planning or just investigating, say that. Say things like, “don’t suggest any changes.” Or “don’t take action yet.” This will keep the LLM focused on talking about the problem rather than reaching for any tools to actually do anything about it.

Next, keep it focused on small problems. Even if you’re managing swarms of agents, each agent should be focused on a small portion of the problem. Each swarm should be focused on a certain aspect of the product. The broader the picture, the more leeway you give the AI and the more room it has to make assumptions and bridge the gap in whatever way it sees fit. Keep it to one component or one interaction or one endpoint or one layer. Bounding it to a smaller portion helps it focus and improve results.

Finally, in coding tools like Claude, use plan mode and meticulously review the plan. This will help you find errors in its thinking earlier. This will allow you to see where it’s making assumptions and where you need to provide more detail. Correct it (LLMs take correction so well) and review it again to ensure its understanding is accurate. Once the plan is to your liking, you can set the LLM loose and reap the rewards.

Overall, this helpfulness is a strength of the LLM. However, left unchecked, this can be a problem. It may assume it needs a bunch of data that it doesn’t need which could lead to database locking or performance impacts. If you catch this early, you can steer it in the right direction. If this slips passed and gets into the code, you may suddenly have a lot of customers impacted.

The key here is to not blindly trust the AI. Even though it’s confident. Even though it’s very helpful. Even though it seems to understand everything. Helpfulness is not understanding. The devil is in the details. Take the time to review its plans. Take the time to review its code. Take the time to ask questions and challenge it. The more time you spend thinking critically about the problem and critiquing the solution, the more likely you are to have a quality product in the end.

Next time you use an LLM, try this: Before letting it change anything, ask it to explain what it thinks the problem is and what assumptions it’s making. If you wouldn’t accept that explanation from a teammate in a code review, don’t accept it from the AI either.

The Most Dangerous Thing AI Gives Engineers: False Confidence

John Van Wagenen — Tue, 10 Feb 2026 00:38:01 +0000

For the last few years, I've primarily been a frontend engineer. I'll hop into the backend every once in a while to fix simple issues when we don't have the bandwidth to otherwise do it, but the focus of my work has been on the frontend.

With the assistance of AI tools, I've recently been doing more backend work. I had a feature that needed a new POST endpoint along with some database updates. The changes were straightforward enough but more involved than I've done in a while, and in a service I wasn't familiar with. I'd done a lot of backend work in a nearby service but hadn't done much in this one. Still, I didn't think much of it since the changes seemed simple.

So I got going. I pointed my AI tools at it and let them loose. Everything was looking great! Sure, I had to correct it from time to time, but things seemed to be making sense. I kept moving through the tasks, generating more code and making updates as needed. Soon enough, things were done!

Or so I thought.

I opened a PR and immediately had multiple failing jobs. "No worries," I thought, "I'll work through these pretty quickly."

Or, maybe not.

I eventually did get everything in order, but I learned a lot about that service along the way. Checks that are required that weren't apparent. Jobs that run in the PR but not on commit/push. And architectural decisions I had no idea about.

What surprised me was not that things failed. That happens all the time. What surprised me was how confident I felt before opening the pull request. I felt like I understood the system well enough to make the change. The AI helped me move quickly, but it also hid how shallow my understanding really was.

That confidence, more than the failures themselves, is the most dangerous thing AI has given me as an engineer.

Why False Confidence Is Worse Than Ignorance

When you know you're unfamiliar with a system, you move carefully. You ask questions. You read surrounding code. You trace how data flows through the system. You rely on your knowledge, like an internal compass, and move through the system.

When you think you understand it, you move fast and stop asking questions.

This is the trap. AI tools are designed to be maximally helpful. They generate code that looks clean, follows patterns, and appears reasonable. Because the output feels familiar, it creates the illusion of understanding. And that illusion is contagious, especially for experienced engineers who can pattern-match the AI's output to similar problems they've solved before.

The code the AI generated for me was good code. It followed conventions, used appropriate design patterns, and compiled without errors. But "good code" and "code that works in this specific system" aren't the same thing. The AI didn't know about the implicit constraints, the architectural boundaries, or the CI pipeline checks that would catch my mistakes.

This is especially dangerous for experienced engineers. Our past success fills in the gaps that the AI cannot see. The code looks familiar enough that we assume we know what's happening. But familiarity is not the same thing as knowing how a system behaves under pressure.

What AI Can't See

AI tools reason well when systems are well-documented, patterns are consistent, and common paradigms apply. But real-world enterprise systems rarely look like this.

Large systems accumulate history. Decisions live in code, not documentation. Architecture degrades over time. Patterns are loosely followed. Sometimes you compromise certain aspects to deliver critical fixes to a customer. The system becomes a historical artifact. Millions of lines shaped by constraints, trade-offs, and political realities that no AI can infer from the code alone.

Architecture exists as invisible fences. You may have a strict boundary that certain models don't leave certain layers. If that's not clearly documented, the AI will miss it. You might have a rule that all database tables must include specific audit columns. The AI won't know until the CI pipeline fails. These boundaries are enforced by people and processes, not compilers.

Implicit knowledge decides survival. In my case, I didn't discover the constraints by reading documentation or code. I discovered them when my pull request failed in ways I didn't know were possible. There were checks hidden in the CI pipeline, architectural patterns enforced only in code review, and assumptions about the system that everyone on the team just "knew."

No AI tool can currently read minds or easily infer all the decisions ever made in a complex system. Until then, we need humans in the loop to do the deep thinking and course correcting. In systems like this, correctness is not just about logic. It's about history, risk, and context that exists outside the code.

What I Should Have Done

Looking back, my mistake wasn't using AI. It was trusting the confidence I felt.

Before letting the AI touch any code, I should have spent 30 minutes reading the service's architecture documentation and the surrounding code. I should have looked at recent PRs to see what patterns the team follows and what checks typically flag issues. I should have asked someone on the team: "What are the gotchas in this service?"

Instead, I let the AI make me feel like I already knew these things.

The solution is not to avoid AI tools. That would mean throwing away a real advantage! The solution is to change how we relate to them. Good engineers don't use AI as an authority. They use it as an accelerator.

How to Use AI Without the False Confidence

AI can generate options, surface patterns, and reduce mechanical effort. It cannot replace building a mental model of the system.

When working in unfamiliar or complex codebases, confidence must be rebuilt intentionally. That means:

Read the surrounding code before accepting AI-generated changes. Understand the patterns the codebase follows, not just the patterns the AI knows.
Trace data flows. Follow how data moves through the system. Where does it come from? Where does it go? What transforms it along the way?
Ask people who know the system why things are the way they are. There are always reasons—technical debt, past incidents, customer requirements, performance constraints—that aren't visible in the code.
Assume something important is missing from the AI's output until proven otherwise. This isn't paranoia; it's calibration.

One shift that helps: use AI to generate questions instead of just answers. What assumptions does this change make? What could break if this endpoint is used in unexpected ways? What parts of the system does this touch indirectly?

The AI is very good at helping us move faster. It is not good at telling us when to slow down. That responsibility still belongs to the engineer.

The Real Cost

AI has changed how quickly we can produce code. It has not changed what it means to understand a system.

Confidence still has to be earned through context, experience, and judgment. If an AI tool makes you feel confident without making you more curious, it is already putting you at risk.

The next time AI makes a change feel easy, pause. Ask yourself what you might be missing. Not because the AI is wrong, but because the confidence it gives you might be covering up the gaps in your understanding that matter most.

This week, pick one AI-generated change you made recently and trace it through your system. See what you missed the first time.

The next time Claude or Cursor makes you feel like a 10x engineer, remember: you might just be a 1x engineer moving at 10x speed toward a problem you don't yet see.

Demystifying AI in Engineering

John Van Wagenen — Tue, 03 Feb 2026 03:04:09 +0000

When talking about AI in software engineering, I often hear things like:

“I don’t trust it.”
“Does it really save any time?”
“Why use it when I can just do it myself?”
“It’s just a statistical model.”
“It just writes slop.”

These concerns are not all wrong. Under the hood, modern AI really is a statistical model. That does not mean it is not useful.

My goal here is not to sell you on AI or write an academic paper. It is to give you a clear, practical look at how today’s models actually work so you can better judge when they are valuable and when they are not.

To do that, it helps to understand where a lot of this skepticism came from.

Yesterday’s AI

Let’s go back about ten years to the mid-2010s, when machine learning was the buzzword of the moment. We were starting to call things “AI,” but most of what we had were narrow, specialized models.

The thinking at the time was straightforward. Computers are good with numbers, so if we could turn text, images, and other messy data into numbers, we could train models on it. Techniques like vector embeddings, popularized by tools such as word2vec, made this possible by representing things like words or images as numerical vectors that preserved some notion of meaning.

From there, we trained models using large labeled datasets. You would show the model examples. This is a muffin. This is not a muffin. Over time, it learned statistical patterns that let it guess whether a new image was likely a muffin or not.

This approach worked, but only within limits.

Most machine learning at the time was supervised, narrow, and task-specific. Models were trained to do one thing well, such as classifying images, tagging text, or detecting spam. They processed one input at a time in a tightly constrained problem space.

As a result, these systems were slow to train, brittle in practice, and difficult to generalize. A model that was great at identifying muffins was useless for detecting cancer or translating text. What we called “big” models were measured in millions, and sometimes tens of millions, of parameters. They were only as good as the specific data they were trained on.

Given that history, it is no wonder many engineers learned to distrust “AI.”

What Changed

So how did we get from that world to the generative models we use today?

Several things changed, but three matter most.

1. Transformers

The most important shift was the introduction of the transformer architecture.

Before transformers, models processed language mostly sequentially. They looked at one word at a time and had limited ability to understand how all parts of a sentence related to each other.

Consider a sentence like "The bank can guarantee deposits will eventually cover future tuition." To understand whether "bank" refers to a financial institution or a riverbank, you need to look at words that appear much later: "deposits," "cover," "tuition." Sequential models struggled with this because by the time they reached "deposits," the context around "bank" had faded or been compressed into a fixed representation.

Transformers solved this through a mechanism called attention. Instead of processing words one at a time, attention allows the model to look at all words simultaneously and learn which ones are relevant to each other. When processing "bank," the model can directly attend to "deposits" and "tuition" regardless of how far apart they are, weighing their relevance to determine meaning.

This doesn't happen just once, but multiple times across multiple layers, with the model learning increasingly sophisticated relationships. Early layers might connect "bank" to "deposits," while deeper layers connect "deposits" to "cover future tuition," building up a rich understanding of the entire sentence.

This single change dramatically expanded what models could understand and generate. It moved machine learning beyond narrow classification tasks and made general-purpose language models possible.

2. Model-Native Context

Context changed as well, and this shift is more significant than it might initially seem.

A decade ago, context was mostly managed by application code. If you wanted to use a model for sentiment analysis on customer reviews, you had to carefully preprocess each review into the exact format the model expected: maybe a few dozen words, stripped of anything extraneous.

The model had no memory of previous reviews, no understanding of the product being discussed, no awareness of the customer's history. Each prediction was isolated. If you wanted to analyze patterns across reviews, you had to build that logic yourself, running hundreds of individual predictions and manually aggregating the results.

The practical limit was often just a few hundred tokens per request. Models were stateless and forgot everything between calls.

Today, context is largely model-native. Models manage it themselves across much larger windows, often hundreds of thousands of tokens.

You can now give a model your entire product documentation, a collection of customer feedback, recent support tickets, and your current feature roadmap all at once. The model can identify that customers are frustrated with checkout because a feature you deprecated last month was solving a workflow problem you didn't realize existed.

The model learns what to pay attention to. When you ask about customer pain points, it dynamically weights relevant context by connecting complaints across different channels, identifying patterns in how different user segments describe the same issue, and deprioritizing one-off complaints or unrelated feedback.

This is why models can now help with tasks like synthesizing user research or generating documentation that accounts for multiple use cases. The limiting factor has shifted from "can the model see enough?" to "can it reason effectively about what it sees?”

3. Scale and Generality

Once transformers proved they could scale, we started training models on much broader datasets. These included publicly available text, code, documentation, books, and research.

The old approach was to curate datasets for specific tasks. You would gather thousands of labeled spam emails to build a spam filter, or thousands of medical images to detect tumors. Each model was a specialist.

The new approach flipped this. Instead of training different models for different tasks, we trained single models on enormous, diverse datasets and let them learn general patterns across all of it.

This matters because those patterns only emerge at scale. Train a model on a hundred Python scripts and it learns basic syntax. Train it on millions of repositories across dozens of languages and it learns deeper patterns: how architectural decisions lead to certain bugs, how testing strategies differ across ecosystems, how naming conventions signal intent.

This is why you can ask a modern model to write Rust code even if you've never written Rust yourself, or explain a complex algorithm like you're explaining it to a friend. The model has seen enough examples that it can generalize to requests it has never encountered before.

We went from millions of parameters to billions. The payoff is a fundamentally different kind of tool—one that can work across domains rather than being locked into a single task.

Why Today’s AI Feels Different

These changes did not turn statistical models into magic. What they did was make them broadly useful.

Modern models can ingest large portions of a codebase and reason across multiple files. They can synthesize information from documentation, tests, and error output in a way older systems never could.

Yes, they are still predicting the most likely next token. The difference is that they do so with far more context, better representations, and significantly improved performance.

That is why an LLM can often help you track down a nasty bug or draft a reasonable implementation sketch in minutes. Tasks that once required hours of manual searching and context switching can now be accelerated.

Where Models Excel and Where They Struggle

Today’s models are especially strong at pattern recognition and synthesis. They work well across large contexts and are good at generating first drafts of code, tests, or documentation.

They still have limits.

They tend to be opinionated and often nudge you toward common patterns that may not match your architecture. They can also get lost when iterating through complex changes, especially when tests start failing in unexpected ways.

In many ways, they behave like an overeager intern. They are genuinely helpful, surprisingly capable, and occasionally too confident for their own good.

How Engineers Should Approach Them

Chances are you already have access to these tools, whether through Copilot, Claude, Cursor, or something similar.

The key is learning how to work with them, and that comes from deliberate practice rather than occasional tinkering.

Start with low-stakes tasks where you can easily verify the output. The next time you need to write a test for a function you just wrote, try asking the model to generate it. Give it the function and a brief description of what edge cases matter. See what it produces. Check whether the tests actually cover what you care about or if they just look plausible.

Pay attention to how you phrase requests. Vague prompts like "make this better" usually produce vague results. Specific prompts like "refactor this function to handle the case where the user list is empty" tend to work better. The model has no context beyond what you give it, so being explicit about constraints, requirements, or concerns makes a difference.

Notice where the model gets lost. If you’re iterating on a complex change and the suggestions start drifting away from what you actually need, that is a signal. You might need to provide more context, break the problem into smaller steps, or just handle that piece yourself. The model is a tool, not a replacement for judgment.

Experiment with different kinds of tasks. These models are often better at some things than others. Generating boilerplate, drafting documentation, explaining unfamiliar code, and suggesting test cases tend to work well. Architecting systems, making nuanced trade-off decisions, or debugging subtle concurrency issues are hit or miss.

Treat early results as drafts, not solutions. Even when the output looks right, read it carefully. Models are confident even when they are wrong, and they will occasionally generate code that compiles but does the wrong thing or uses patterns that do not fit your codebase.

Like any tool, the value comes from understanding what it is good at, what it struggles with, and how to adapt your workflow to make use of it effectively.

If you're experimenting with these tools, I'm curious what you're finding. What's worked? What hasn't? Where have you been surprised?

AI and Software Engineering: More Than Just Coding

John Van Wagenen — Tue, 27 Jan 2026 02:12:00 +0000

Coding Is Only a Fraction of the Job

As a leader and senior engineer, I’ve learned that coding is only a fraction of the job. Most of my time is spent gathering requirements, evaluating solutions, refining stories, creating documentation, reviewing code, and making decisions that shape the system long before any code is written.

So why does the conversation around AI in software engineering focus almost entirely on coding?

We all know that engineering is more than writing code. It’s cognitive work: planning, communication, verification, decision-making, documentation, and review. Code is the output, but a significant amount of effort goes into making that output possible.

That raises an obvious question:

Can AI help with those other parts of the job, or is it only useful as a coding assistant?

In my experience, the answer is clear: AI can do far more than just generate code, and it can save a surprising amount of time doing it.

AI as a Force Multiplier Across the Workload

Most engineers don’t want to spend their day updating Jira tickets, maintaining documentation, or wiring things together so dependency graphs stay accurate. Those tasks are necessary, but they’re often done begrudgingly so we can get back to the work we enjoy.

But what if AI handled the bulk of that overhead?

With tools like MCP, you can connect an LLM directly to your ticketing system and documentation. Instead of manually juggling context, you can talk to your LLM about your work and let it pull the relevant information itself.

In practice, that means things like:

Chatting with your LLM about existing tickets with full context
Turning technical documentation into well-structured stories
Updating stories and defects as understanding evolves
Commenting on and updating ticket status as work progresses

All of that adds up to less cognitive load and less time spent doing administrative work by hand.

Does the LLM make mistakes? Absolutely. Does it need correction and guidance? Of course. But even with occasional course correction, the efficiency gains are real.

Real-World Example: Preparing a Feature for Work

When I’m preparing a new feature and breaking it down into stories, I’ll provide the LLM with the relevant context (technical documentation, mock-ups, constraints, and any other material it needs) and give it clear instructions on how to structure the work.

When doing this, it'll come back with some great thoughts on the work; however, this is where the real work begins. While the AI will give a pretty good general understanding, it will often make many assumptions around the details that you didn't expliclty state. Your job now is to thoroughly review what it gave back to you to ensure it has an accurate understanding of what you want, correcting any details that it didn't quite get right.

This will usually take at least a few back and forths with the LLM before it gets things right. Once I’m comfortable with its understanding, I ask it to create the stories directly in Jira.

A few moments later, I have a feature with concrete, well-written stories underneath it, often with more detail and clarity than I’d normally write myself. The work is done faster, and the quality is higher.

Instead of spending my energy on repetitive setup and refinement, I can focus on validating the approach, thinking through edge cases, and getting the team unblocked sooner.

Where This Breaks Down

As powerful as generative AI is, it’s not magic, and it’s not a substitute for engineering judgment.

LLMs are extremely eager to be helpful. Most of the time, that’s exactly what you want. Other times, that eagerness leads them to make assumptions, fill in gaps incorrectly, or confidently push ideas that don’t actually align with the product or system.

Left unchecked, this is where things can go off the rails.

One of the most common failure modes is confidently wrong output. Stories may look complete but miss critical edge cases. Documentation may sound authoritative while glossing over important nuance. Diagrams can appear correct while subtly misrepresenting reality. This is why AI output always needs review, especially when the cost of being wrong is high.

This is also why I frequently use plan mode in tools like Cursor or Claude Code. By asking the model to explain what it plans to do before it does it, I can catch incorrect assumptions and small (or sometimes large) deviations early. That feedback loop prevents slop and helps guide the AI toward the outcome I actually need, rather than cleaning things up after the fact.

Another limitation is context. Today’s LLMs still struggle to hold the full shape of a complex system in a single context window. That means you need to be deliberate about what information you provide and focus on giving only what’s relevant to the current problem. Yes, this can mean the model misses patterns or historical decisions. In practice, a quick reminder or correction is often enough to get it back on track.

How do you decide what to include in the context? I like to think of how I'd explain this to a new employee. The employee may have a great general understanding of how things work, so I don't need to explain the very basics or why we chose an architecture, but I do need to explain what files are interesting and where the issue actually is. This will allow the LLM to quickly identify where the issue is as well as neighboring files or where the code is used that may be helpful to understand.

There’s also the risk of false progress. Tickets get created, documentation gets updated, and diagrams get generated, but none of that guarantees the work is actually correct or well understood. Without deliberate review, it’s easy to confuse activity with understanding.

This is where your work shifts. Instead of coding the things yourself, you're reviewing everything the AI generates, constantly checking its output against the desired outcomes and correcting quickly when things start to deviate. This is where the AI's eagerness to be helpful is beneficial. LLMs take correction extremely well and are quick to admit their mistakes. That doesn't mean they'll always get it right after that, but it does mean they take correction without any friction and do their best to make the corrections you note.

The key is intent. The goal isn’t to delegate thinking to the AI. It’s to offload friction. When AI handles structure, synthesis, and repetition, engineers can focus on validation, tradeoffs, and decision-making. Those are the parts of the job that still require human judgment.

Used this way, AI doesn’t replace engineering discipline. It amplifies it.

Why This Matters

The biggest benefit of using AI this way isn’t speed for speed’s sake. It’s leverage.

By reducing cognitive friction across planning, communication, and refinement, AI helps teams move with more clarity and less rework. Features get ready sooner. Expectations are clearer. Engineers spend more time solving meaningful problems and less time pushing information around.

In other words, AI’s real value shows up before the first line of code is written and after the last one is merged.

The Shift

If you’re only using AI to help write code, you’re missing a significant part of its value.

Try involving AI earlier and at higher levels of abstraction. Use it to clarify ideas, structure work, surface assumptions, and reduce the overhead that slows teams down.

You may find that the biggest productivity gains don’t come from writing code faster, but from spending more of your time on the work that actually matters.

This article focused entirely on the individual contributor aspects of the role of a senior engineer and didn't dive into how this can be applied at the team level. I'm interested in hearing your thoughts on this. How do AI tools and spec-driven development work at the team level? What challenges does this introduce and how are you addressing them? This will be a topic I revisit in future writings and I'd love to hear your thoughts about it.

Using AI in Personal Projects vs Enterprise Codebases

John Van Wagenen — Tue, 20 Jan 2026 02:12:00 +0000

Originally published on johnvw.dev

A Shift in How I’ve Been Using AI

As a senior software engineer, I’ve been using AI extensively at work on large, enterprise software. Despite that investment, I haven’t used it much for personal projects. I experimented a bit nearly a year ago when the tools were still relatively new, but since then, most of my usage has been in a professional setting.

That’s recently changed.

I built a personal site (which is likely where you’re reading this) entirely with GPT 5.2. The experience was enlightening and highlighted some important differences between using AI on small, personal projects and using the same tools in large enterprise systems.

What follows are some of the lessons I took away from that contrast.

When AI Feels Almost Magical

For my personal project, I created a simple, statically served blog. I started by putting up a placeholder landing page. I briefly described what I wanted, and the AI produced a simple page that was about 90% of what I had in mind. A few more turns later, we had a first version ready to go.

I uploaded it immediately so the site wasn’t empty while I worked on what I actually wanted: a functioning blog. From start to finish, including some hosting configuration, this took about an hour—far faster than I expected.

The next day, I sat down to build out the blog itself. Even with modern tooling, I expected this to take a few evenings. I was curious to see how much AI could accelerate the process.

And accelerate it did.

A Clean Spec, Small Stories, and Rapid Progress

I began by describing the project to the AI: constraints, colors, technology choices, and, just as importantly, what I didn’t want. I had it write everything into a SPEC.md file at the root of the repository so we could refine it and refer back to it as development progressed.

The AI asked a few clarifying questions, and after a handful of back-and-forth turns, the spec was in a place I felt good about.

From there, I opened a new chat and worked with it to break the spec into small, actionable stories. We refined those together as well. Even then, I added a few stories later as the project evolved.

Once the stories were ready, I opened yet another chat and asked the AI to implement the first story, referring back to the spec as needed.

This is where my mind started to melt.

The Enterprise Contrast

At work, I’m used to using AI on large systems. I’m used to feeding it context, helping it understand stories, and having it do most of the implementation work. But I’m also used to this taking time. It’s not unusual to wait several minutes for a response, then spend more time reviewing what it produced.

Even when I keep tasks small, legacy systems often require a lot of context just to understand a seemingly simple change.

That wasn’t the case here.

Within a minute or two, the AI had finished the first story—and from what I could tell, had done all of the work correctly. I had it commit and push the changes, then opened a new chat and asked it to implement the next story.

And so it went.

Each story was implemented quickly and completely. That’s when the possibilities really started to sink in.

Why Simple Work Is Being Commoditized

If AI can move this fast, what’s stopping someone from building whatever simple project they want? In many cases, simply their own motivation to do so. This effectively commoditizes simple work, lowering the barrier to entry for people to build small systems without outside help.

But then I thought about my day job.

The system I work on is massive. As impressive as modern models are, there’s no realistic way they can hold the entire system in their context window. Still, AI is undeniably useful there, it just behaves differently.

That contrast leads to an important question: what can we learn from both environments?

Lesson One: Context Is Everything

In small systems, the AI can hold most, or even all, of the relevant code in its context window. While you probably don’t want to do that, the key takeaway is that the system itself is simpler and easier to reason about.

Want to add a new page? Provide the requirements and a bit of context, and you’ll likely have a solid implementation within minutes.

In an enterprise system, the same change is possible but only if you’re far more deliberate. Instead of simply describing what you want, you need to provide the AI with the architectural context it lacks. What router are you using? What patterns are established for pages? Where should this code live? Is there an existing page it can model?

Providing this information increases the probability of success dramatically. Yes, it takes longer than in a personal project, but without it you’ll end up thrashing—correcting misunderstandings as the context window fills and the model’s performance degrades.

Lesson Two: Small Chunks Are a Leadership Skill

Closely related to context is the ability to break work into small, manageable pieces. To me, this is fundamentally a tech lead skill.

Tech leads work with product managers to translate user needs into technical requirements. We organize those requirements into small, workable chunks so teams can move quickly without getting bogged down.

That same skill is invaluable when working with AI.

The smaller the work item, the easier it is to provide complete context. The smoother that interaction is, the faster you get working software to test and refine. That faster feedback loop means you can ship sooner, learn sooner, and adjust sooner.

It’s Agile software development on steroids.

AI Amplifies Constraints

All of this highlights a deeper issue: AI amplifies constraints.

There have been plenty of takes recently along the lines of, “AI didn’t kill this company, it exposed a bad business model,” or, “AI didn’t cause these layoffs, it exposed poor performance.” While I don’t fully agree with those claims, I do agree with the underlying idea: as systems become more efficient, their weaknesses become more visible.

As coding gets faster, bottlenecks shift elsewhere. If implementation takes minutes, what about UX research? Requirements gathering? Testing? Deployment? Maintenance? Architectural shifts?

This is why small personal projects can move at breakneck speed while large enterprise systems often feel slow even with AI moving things along. It’s rarely the tools that are the problem. More often, it’s the surrounding process. That’s not a criticism of enterprise environments, it’s a reality of scale. The more customers, products, and revenue you have, the more those supporting processes matter.

The real question is how we improve those areas alongside our tooling.

Where Senior Engineers Fit In

I don’t think there’s a single definitive answer, but part of it comes down to ownership. Owning as much of the product lifecycle as you reasonably can, and being a positive influence where you can’t, goes a long way.

AI doesn’t eliminate senior engineering skills. It rewards them. The ability to manage constraints, provide context, break down work, and think systemically becomes even more valuable in an AI-assisted world.

That’s not a threat to experienced engineers. It’s an opportunity.

Have you noticed similar patterns in your work? What differences have you seen between AI use on small projects versus large codebases, and what lessons would you share with others?

Employer-Sponsored Training

John Van Wagenen — Mon, 09 Jul 2018 19:13:48 +0000

Most great companies will offer some sort of training program. Whether that's a little bit of free time for self-directed training or the company pays for you to attend a class or conference, this training can take on many forms--but it's not for everyone. I'd like to hear from you! What training programs have you seen from employers? Which ones worked? Why were they effective? What types of training do you like the most?

As you consider your answers to those questions, let me tell you a bit about the training program we've had at my current employer, MasterControl, in its current form. It's evolved a bit over the years and continues to evolve, but this is where we're at.

A few years ago we started formal, ongoing training. This takes a few forms. First, we have a biweekly meeting where we meet as a department to receive training. This training is provided by anyone in the department that wants to offer training and is coordinated with a small group of volunteers from the department that form the "training committee." These meetings can last up to 3 hours but they often last less than two. In addition to that, we encourage each employee to take up to 2 hours per week to train on whatever they'd like. From Pluralsight to books to tutorials and beyond. Finally, we also have a training budget where the company will pay for employees to attend conferences, take courses, get certifications, or whatever else they'd like to do for training.

All those things make up our ongoing training that we offer at MasterControl. It's an evolving program with some changes in the works right now. It's been moderately effective so far but we want to make it much better. Does your employer do similar things? What have you seen work well?

Gemba Walks

John Van Wagenen — Wed, 23 May 2018 04:24:00 +0000

In lean manufacturing, there's a concept referred to as Gemba Walks. This is essentially where someone who's not directly involved in the day-to-day labor on the manufacturing lines walks the floor to identify waste, observe how the work is actually being performed, build relationships, observe working conditions, and many other things. In manufacturing, it has quite a few benefits and companies that practice it often speak highly of the value it brings.

As it relates to software engineering, what would you consider to be a Gemba Walk? How have you seen others or how do you effectively observe working conditions and gained the other benefits that Gemba Walks can bring? If you're not sure you've seen it done, how would you apply Gemba Walks to software engineering? Maybe you are in the "front lines," so to speak, but this could also be applied to staying in-sync with other engineers or other parts of the system. How do you accomplish that?

(This isn't to say I don't have ideas on this, but I really want to hear your ideas on it.)

Experience Isn't Enough

John Van Wagenen — Tue, 06 Mar 2018 03:39:05 +0000

So you've been in the industry for a while now. Great job! You've probably rejoiced as you landed your first job. Maybe you've moved on since then (maybe even a few times) or maybe you've stayed with your first employer. Whatever the case, you've been in the industry for a number of years now. Maybe 5. Maybe 10. Maybe more. You've done some cool things (like building that awesome feature all the customers didn't know they wanted) and some not-so-cool things (like taking down production). On paper, you look pretty amazing! You've definitely been around the block a few times and have your own set of scars to show for it.

But... have you improved?

Have you learned from your mistakes?

Have you challenged yourself in new and different ways?

Have you put effort into learning new things?

Over the years, I've had opportunities to be involved in the interview process at work. We've mainly interviewed college students looking for internships or their first jobs. On occasion, though, we've had the opportunity to interview a few engineers who have had a lot of experience. Some of them have been in the industry for 15+ years and have done a lot of interesting things. In a few of these interviews, one thing has stuck out to me...

They stagnated.

Instead of 15+ years of improving, they had a few years of improvement followed by many years of the same old stuff.

Instead of learning from mistakes, some have ignored them.

Instead of challenging themselves, they've done the minimum to get by. They've punched the clock and been grateful for a way to pay the bills.

Instead of learning new things, they've only adapted what they've always done to the new situations they encounter.

So, I've learned that experience isn't everything. Just having been in the industry for 15 years isn't good enough. Just punching the clock isn't good enough. Just doing the same old stuff in new ways year after year isn't enough. This is stagnation.

So, what can you do to avoid stagnation?

There's a lot you can do. Here are some things that I think are valuable in becoming a senior engineer, not just an engineer with years of experience.

One of the key attributes that I think helps you become a senior engineer is a constant desire to improve. Whether this desire comes from a personal drive to be the best you can be or just a curiosity about a different way of doing things or a desire to be able to help others learn or any other reason, this drive can be a key differentiator in your experience. Without this drive, you'll be punching the clock and not much else. With this drive, you'll be involved and engaged in the work you're doing. You'll be able to do more and more over time, you'll be happier and more fulfilled, and you'll be gaining the skills you need to become a senior engineer.

Another key attribute that will help you on your road to becoming a senior engineer is humility. Humility will help you learn from those around you. If you think you're the smartest person in the company and you can't learn anything from so-and-so in a code review because, what do they know anyway? You're either in the wrong company or you're just plain wrong. There's plenty we can learn from those around us. Yeah, your coworkers may be weird, but so are you in your own way. Humility will not only help you learn from those around you, it'll also help you realize when you're wrong and help you learn from your mistakes and failures. Without this humility, you're likely going to keep some bad habits that will keep you at a junior level for longer than you could be. With this humility, you'll likely have a drive to improve yourself and be willing to constantly challenge the way you do things in search of a better way.

There are many other attributes that can help you on your progression to the senior level. What attributes do you admire in the senior engineers around you? What has helped you on your road to the senior level? I'm interested to hear your thoughts.

It's important to keep in mind that experience or years in the field alone doesn't make you a Senior Engineer. Senior Engineers constantly improve. Experienced Engineers stagnate. Doing the same thing over and over again isn't improvement. Challenging yourself and looking for new, better ways of doing those things is improvement. And improvement is what will give you the experience you need on your road to a Senior Engineer. So don't get comfortable. Challenge yourself and you'll accelerate on your way to a higher level.

Originally posted on my personal blog.

Want more content like this?

Check out my blog
Follow me on dev.to
Follow me on Twitter

What is a Tech Lead?

John Van Wagenen — Wed, 06 Dec 2017 22:39:19 +0000

This isn't a new topic by any means, but some recent events at work brought this question to my mind. I started writing down my thoughts and doing some research on it and thought this might be a great question to ask here on dev.to!

So, what is a Tech Lead? How would you define it? What roles and responsibilities do they have? What skills should they have? Any recommendations on resources to learn more about this role?