This article is for developers already using LLM coding assistants who want to sharpen their workflow. I won't be explaining what an LLM is or how to set up your first AI coding tool. Instead, I'll walk through the tooling, habits, and hard-won lessons I've picked up over two years of daily LLM-assisted development.

The single biggest shift in that time: I stopped treating LLMs as code generators and started treating them as collaborators that need a plan.

The Tooling Stack

I've been using Roo Code for the longest time. Its appeal is flexibility — it works with anything, supports multiple modes, and is deeply customizable. Recently, I switched to Kilo Code, which adds one critical feature Roo Code lacked: autocomplete. Kilo Code uses the Codestral model running locally via Ollama for this, which means fast completions with zero cloud cost.

On the context side, I use the Context Portal MCP server to persist long-term context across sessions — architectural decisions, patterns, conventions, and to-do items. This acts as a project's living memory that any mode can reference.

I also use custom Roo Flow prompts, which I've tuned to reduce token usage. One recent change worth noting: I had to modify the default Roo Flow prompts to remove XML-based tool usage directions and switch to native tool calling. If you're still on the XML-based prompts, it's worth making that switch.

The Architect Workflow

Early on, my process looked like this: write a prompt, get code back, iterate on the code, get frustrated, iterate more. The generated code was often close but structurally wrong in ways that took multiple rounds to fix. I was spending most of my time reacting to output instead of shaping it.

Now, I spend almost all of my time in Flow Architect mode. I generate a plan, iterate on that plan until I'm satisfied with every detail, and only then move to code generation. The result is that code generated in Flow Code mode — or the walkthrough generated in Flow Ask mode — is nearly flawless on the first pass.

This was the single biggest improvement in my entire workflow. Everything else I'll describe builds on top of it.

When a task is fully documented and follows the single responsibility principle, I feed the design document from Architect mode as initial context into a new Flow Code conversation. If there are multiple clearly defined tasks, I switch to Flow Orchestrator mode and let it manage parallel conversations. The key is that no code gets written until the plan is solid.

Model Selection

Not every task needs the most powerful model. Setting the exact default model per mode has been one of the simplest ways to control cost without sacrificing quality.

My current breakdown: Opus for architecture work, where reasoning depth matters most. Sonnet for complex technical tasks that require nuance. Haiku for straightforward, well-known tasks — even high-volume code generation — which, honestly, is the majority of the work. Most coding tasks are not novel; they're well-established patterns that a lighter model handles perfectly.

Prompt Discipline

A few things I've learned about how to talk to these models effectively.

Be specific in your instructions, and tell the LLM what it should not do. This is just as important as telling it what you want. Without negative constraints, models will infer scope and often infer too broadly.

Front-load context. I load as much relevant context as I can think of in the initial prompt — files, architecture docs, prior decisions. The more the model knows upfront, the less it guesses.

Add rules incrementally, per project. I don't rely solely on what I've stored in Conport. Small, targeted rules in the .kilocode/rules directory accumulate over the life of a project and catch the specific behaviors I want to enforce or prevent. For example, every project gets a rule enforcing no emojis and requiring succinct, direct output. Recent models have defaulted to being irritatingly verbose and chatty, and this keeps them in check.

Be explicit about file scope. I tell the model exactly which files to work on. I then watch the output as it's generated. If I see it touching other files with good justification, I let it continue. If it's drifting, I stop the work immediately and re-prompt with more context.

Reviewing Generated Code

I check every single line of generated code, then evaluate it as a whole. This is non-negotiable, even for simple tasks.

What I consistently find: the code is often more verbose than necessary. It uses odd techniques that it was trained on but that don't fit the project's conventions. It's not always DRY. It can lean on overly simplified patterns that technically work but aren't how I envision the strategy.

That said, reviewing code has also been one of the best ways to learn. The models have shown me techniques and approaches I hadn't considered before. It's a two-way street — you're checking their work, but you're also absorbing new ideas.

Debugging

For stack traces, I copy the output and paste it inside triple backticks. For UI issues involving layout, sizing, or placement, I send a screenshot — these models are vision-capable now, and a picture communicates a layout problem far more efficiently than a text description.

The screenshot workflow extends to wireframes. Even a rough hand-drawn wireframe, photographed and sent to the model, gives it enough to work with. This is one of the most underused capabilities I've seen — most people don't think to send visual input to a coding assistant.

Testing

Test strategy gets decided in Architect mode, alongside everything else. Ninety-five percent of the time, I let the LLM generate the tests. If it's something I'm uncertain about — an unfamiliar testing pattern or an edge case I want to understand deeply — I switch to Flow Ask mode and build the tests out myself, step by step.

Learning New Things

When I'm working with a new concept, tool, or language, I never let the model generate code for me. I switch to Flow Ask mode and have it walk me through implementation step by step. I write every line myself. This is slower, but it means I actually understand what I've built, and I can maintain it without the model's help later.

The Rules I Wish I'd Known Earlier

It's not Google. Don't treat it as a search engine. It's a reasoning tool that generates output based on patterns, and it needs to be directed, not queried.

Always review the code, even for simple tasks. You will always catch something. But you'll also learn something — those two things happen in roughly equal measure.

If you find yourself writing more than two prompts about the same block of code, stop and write it yourself. The model isn't going to get there, and you're burning tokens and time. Step in, write the code, and move on.

The shift from iterating on code to iterating on plans was the turning point. Once I internalized that the quality of the output is determined by the quality of the plan, everything got faster, cheaper, and more reliable.

Building Agents

Beyond using LLMs as tools, I've started building with them. As a personal project, I'm using Pydantic AI to build a D&D Dungeon Master agent that runs locally. It's been an education in a completely different set of concerns.

Model selection matters far more when you're running small local models. A model that excels at narrative generation might be terrible at structured output or tool calling. You can't just pick the "best" model — you have to pick the best model for the specific task your agent performs, and that often means testing several.

The parameters you'd normally ignore start to matter. Temperature, max tokens, and retrieval_k all have a direct, noticeable impact on output quality and consistency. Small changes in these values can be the difference between a coherent game session and nonsense.

History processing is deceptively tricky. Conversation history grows fast in a D&D session, and you have to make deliberate choices about when to summarize history versus when to truncate it outright. Summarization preserves context but costs tokens and can lose important details. Cutting history is cheaper but risks the agent forgetting something the player said three turns ago. There's no universal answer — it depends on what your agent needs to remember and what it can afford to forget.

Writing System Prompts

One skill that's grown significantly over the past two years is writing system prompts — not just for coding, but for any task where I need consistent, specialized behavior from a model.

The best example is outside of software entirely. I'm writing a book, and I've written a system prompt that instructs an LLM to act as my editor. I generate one to three chapters of content, then provide them as context in a custom Book Editor mode with that system prompt. It gives me structured feedback on weak verbs, passive voice, character inconsistencies, overly complex language that makes passages hard to read, world-building inconsistencies, and missed opportunities to build tension or develop characters.

This works because the system prompt is specific about what to look for and how to deliver the feedback. The same principles that make coding prompts effective — be explicit, define scope, state what not to do — apply directly to any domain. Once you've internalized how to write a good system prompt for code, you've learned a transferable skill.

Where I Am Now

Three years in, my relationship with LLM tooling has fundamentally changed. I spend the majority of my time thinking and planning, not prompting and fixing. The code generation step, which used to be where all the friction lived, is now the easiest part. The hard work — and the valuable work — happens before a single line of code is written.

The models will keep getting better. The tooling will keep evolving. But the meta-skill — knowing when to architect, when to generate, when to learn manually, and when to just write the code yourself — that's the part that compounds.

I've had to console grown men and women who were crying in frustration, and I want to tell you about one of them.

Miguel was twenty-six years old with a college degree and good grades his whole life. He'd just failed his third self-assessment project — couldn't get it to work per the requirements — and he was breaking down.

"I don't understand," he said, voice cracking. "I've never failed at anything. Why can't I do this?"

I knew the answer. I've seen it hundreds of times over eleven years running a software development bootcamp. The problem wasn't that Miguel couldn't learn to code. The problem was that he'd never learned to think.

Your child is heading down the same path right now, and I want to tell you about it before it's too late.

Oh, and Miguel? About a year after he graduated, he made a LinkedIn post explaining that he'd finally realized what I had been doing for six months, and all the pieces clicked for him. But I'm getting ahead of myself.

What I Actually Do (And What Your Child Needs)

For eleven years, I led a team of software development coaches in a bootcamp. Whenever I hired instructors, I always told them the same thing:

"Your job is not to teach people how to code. Your job is to coach people through the process of learning how to become an analytical and algorithmic thinker."

If someone learns to think analytically and algorithmically, coding follows naturally. Without those thinking skills, they fail the moment they hit a problem we didn't explicitly teach them how to solve.

This is what Miguel didn't understand for six months. This is what schools stopped prioritizing twenty-three years ago. And this is what your child needs far more than good grades.

I'm not just an educator — I'm also a parent of two teenagers. I've spent their entire childhood deliberately building the thinking skills that school won't teach. It worked, and it can work for you too.

The Crisis I See Every Day

My students arrive with impressive credentials. They were the "smart kid." Teachers loved them. Honor roll, AP classes, never below a B.

Then they encounter something genuinely difficult, and they completely fall apart.

Not because the material is impossibly hard — because their identity shatters. They've spent eighteen years learning that success means "getting it done" and that smart people "get it" immediately. Now they're discovering that what they had wasn't intelligence; it was just an easy curriculum.

The behaviors I see are heartbreakingly predictable. Twenty-four-year-olds begging me to just tell them the answer. Complete shutdowns when frustration sets in. Declarations like "I'm just not a technical person" after a single failed attempt. And plagiarism — which is exactly what they learned to do when the goal was always "right answer by Friday, don't care how."

Teachers, you see this too. The gifted student who melts down when challenged. The honor student who'd rather cheat than risk being wrong. The kid asking "Will this be on the test?" about everything.

Here's what we actually had to teach people to do: how to break problems into pieces (they couldn't), how to learn efficiently (they didn't know how), how to handle ambiguity without panicking (they'd never done it), and how to learn from mistakes (they saw mistakes as failure). All of this should be automatic by age sixteen, but we were teaching it from the ground up at twenty-five.

And some didn't make it through. Not because they weren't smart — because they couldn't let go of their ego and adopt a growth mindset. Their minds had been shaped by a lifetime of the wrong incentives.

These are your kids in ten years.

How We Got Here: The Testing Era

If your child is in school right now, their education has been shaped by a 2001 law called No Child Left Behind.

In the simplest terms, here's how it worked: schools get money based on test scores, teachers get evaluated on test scores, and principals keep their jobs based on test scores. The result is that everyone optimizes for test scores.

The problem is that test scores and thinking skills are not the same thing — in many ways, they're mutually exclusive. Teaching kids to think takes time, exploration, and mistakes. Tests reward speed, pattern-matching, and one "correct" answer.

The Incentive Trap

Your child's school operates like a hedge fund manager of mediocrity, optimizing for students hovering around "proficient."

If your kid is already proficient, then mission accomplished — nobody's paying attention to them anymore. If your kid is advanced and bored and needs further development, forget about it. The system has no incentive to provide resources or time for them. And if your kid is below proficiency? That's where every resource goes.

"But Didn't They Fix This in 2015?"

Sort of. Not really.

The Every Student Succeeds Act replaced NCLB in 2015, giving states more control over how to manage education. But notice what didn't change: the annual testing requirements, the funding tied to performance, and the teaching-to-the-test culture that had been deeply embedded for over a decade.

You can't reverse thirteen years of institutional momentum with a new law. The first NCLB kids were already adults by 2015. They're the ones who ended up in my bootcamp.

The law changed. The culture didn't.

What Got Cut

Everything that develops thinking was gradually pushed aside: gifted programs (those students are already proficient, so there's no funding incentive), art, music, and recess (not quantifiable on a standardized test), science experiments (too messy — facts are easier to test), essay writing (multiple choice is faster to grade), class discussions (you can't attach a defensible number to discussion quality), student questions (off-script and wastes test-prep time), and deep exploration of any kind (coverage matters more than understanding).

Your child is being trained to be really good at something that doesn't matter.

Why Every Child Is Being Failed

Gifted Kids: Quietly Neglected

Imagine your child is naturally fast at running — so fast that the gym teacher never makes them practice and just tells them to sit on the bench while slower kids train.

Then there's an actual race. Your kid discovers that being fast and knowing how to race are very different things. They've never learned pacing, strategy, or fatigue management. They lose, they're devastated, and they conclude they're not actually good at running.

That's what's happening academically. Your gifted child never learns to struggle, never develops persistence, never picks up study strategies. Their entire identity gets built on effortless success. Then they hit college or the working world and fall apart.

This could have been my daughters. I saw it coming and intervened.

Struggling Kids: Trained, Not Educated

Kids who are behind get intense focus on test-taking strategies — bubbling techniques, keyword recognition, process of elimination. These help with tests, but they are not thinking skills. When these students leave school and face real problems that aren't multiple choice, they're lost.

Average Kids: Hitting Benchmarks, Not Learning

The average student gets the most resources and the most test prep. And what they're actually learning is that right answers matter more than understanding why, that speed matters more than depth, and that compliance matters more than curiosity.

They'll probably graduate. They'll probably go to college. And then they'll be in my bootcamp at twenty-five, unable to solve problems nobody handed them a formula for.

The Five Missing Skills

1. Metacognition: The Dashboard

This is your child's ability to monitor their own understanding — the internal voice that says, "Wait, I don't actually get this."

When it's present, a student can say, "I thought I understood, but now I'm not sure." When it's missing, they can't even identify what they're confused about and are blindsided by bad grades.

Quick check: Ask your child, "How do you know you're right?" If they can't explain their reasoning, that's a red flag.

2. Productive Struggle: Embracing Difficulty

This is the ability to stay engaged with hard problems without panicking or giving up.

When it's present, a child tries multiple approaches and says things like, "This is frustrating, but I can figure it out." When it's missing, they immediately say "I can't," shut down emotionally, or demand that you solve it for them.

Quick check: Give them a slightly-too-hard puzzle and watch what happens. Do they engage or give up?

My daughters still have emotional reactions to difficulty — they're teenagers. But they work through it.

3. Problem Decomposition: One Bite at a Time

This is the skill of breaking complex problems into manageable chunks.

Ask someone to "eat an elephant" and they freeze. Ask them to "take one bite" and they can do it. Our schools are handing kids elephants and timing them.

When it's present, a child can say, "First I need to do this, then I can do that." When it's missing, they say, "This is too much," and can't even identify where to start.

Quick check: Give them a multi-step task and see if they can sequence the steps on their own.

4. Assumption Validation: Debugging Your Thinking

This is the habit of testing whether your reasoning is actually correct before moving on.

When it's present, a child says, "Let me check if this works," and tests edge cases. When it's missing, they assume their first answer is correct and never check their work.

Quick check: After homework, ask, "How did you verify that your answers are right?"

5. Growth Mindset: Intelligence Is Developable

This is the belief that abilities develop through effort rather than being fixed traits you're born with.

When it's present, a child thinks, "I keep getting these problems wrong, so I need to review the material again." When it's missing, they think, "I'm just not a math person." That fixed mindset — trying once, not getting it, and concluding you're not good at it — is like going to the gym once and deciding you're "not a fitness person."

Quick check: Listen to how your child talks about challenges.

The bottom line: Without these five skills, your child can memorize facts and pass tests but can't actually think. With them, they can learn anything.

The good news is that all of these can be taught at home, but you have to start early — ideally as soon as your child starts school. If you don't catch these before your child is thirteen, it's going to be a much bumpier ride.

Why Waiting Makes It Harder

Your child's brain is at its most flexible during childhood and adolescence. The prefrontal cortex — the region responsible for executive function, planning, and problem-solving — develops between roughly ages ten and twenty-five.

This is the window. Miss it, and you're trying to build these skills after the easy period has closed. Teaching adults the thinking skills they should have started learning at ten is like teaching someone to use a computer when they're seventy. It's possible, but so much harder than it needed to be.

In the bootcamp, I watched this play out constantly. Adults needed about three months just to believe that thinking is a learnable skill. Some plateaued after six months despite intensive coaching. We were trying to build in six months what should have developed over fifteen years.

And then there's the identity problem. By adulthood, a person's identity is built around their academic experience. If you start early, analytical thinking is just how your child learns. If you start late, it becomes identity warfare — they have to unlearn who they believe they are before they can grow.

What Actually Works: Five Strategies for Tonight

Strategy 1: Socratic Questioning

Instead of giving answers, ask questions that guide your child toward answers.

Here's what it looks like in practice. Your kid says, "I don't get this math problem." Instead of explaining it, you ask: "What is the problem asking for?" Then, "What information do you have?" Then, "What's your first step?" And finally, "How can you check if that's right?"

Each question moves them one step closer to solving it themselves — and more importantly, teaches them how to approach the next problem you won't be there for.

Strategy 2: Process Praise Over Outcome Praise

When your child succeeds, praise the effort, not the trait. Instead of "You're so smart! A+ on your test!" try something like, "You worked hard for three days to understand dividing decimals — look at how that paid off." Instead of "You're a natural at science," try, "I'm proud that you didn't give up when you were struggling with organic chemistry."

I get it — you're proud when your child succeeds, and it took me years of practice to make sure I always praised my daughters for their effort rather than their ability. Telling your child she's smart feels good and may make her feel good momentarily, but over time it builds an identity that crumbles the moment something is actually hard.

Strategy 3: Model Thinking Out Loud

Thinking is usually invisible. Make it visible by narrating your problem-solving so your child can hear what thinking actually sounds like.

Here's a real example from my house. Our internet kept dropping one evening while both daughters were home. Instead of quietly troubleshooting, I talked through it out loud:

"Okay, internet's out. Let me figure this out. Is it just my device, or is everything down? Let me check my phone. Phone's out too. So it's either the router or the service. Let me restart the router first — that's the easiest thing to test..."

My older daughter chimed in: "Or call them?"

"Good thinking," I said. "What info would I need before calling?"

"Account number?"

What happened in that moment was that she heard me break down a problem, test hypotheses in a logical order, and involve her in the process. She learned something about how to approach ambiguous problems — and I never sat her down for a "lesson." I just made thinking visible during normal life.

Strategy 4: Normalize Struggle and Mistakes

Make it clear that difficulty is normal and that mistakes are information, not failure.

When your child is struggling, you might say, "This is hard, isn't it? Hard things are where real learning happens." Or, "Mistakes are how we debug our thinking." When they're frustrated, try, "Frustration means you're at your learning edge — that's exactly where you want to be."

Here's a real example — and one where teenagers really test you. My younger daughter was learning algebra one evening and started crying: "I'm so stupid! I can't do this!"

I didn't say, "Don't say that, you're not stupid!" That doesn't help. I didn't say, "This is easy once you get it." That makes her feel worse.

What I said was, "Yeah, algebra is genuinely hard. Your brain is doing something new — dealing with unknowns. That's uncomfortable. But uncomfortable is where learning happens. Let's take a break, then break this down together."

I let her cry for a minute. The emotion was information — she was at her learning edge. That's actually a good thing, even though it doesn't feel like one in the moment.

Strategy 5: Let Them Fail (The Hardest One)

This is the strategy that separates parents who build thinking skills from parents who just talk about building them.

A few years ago, my daughter had a big project due that was worth thirty percent of her total grade. She left it to the last minute — the night before, if I recall.

"I need help! I can't finish this!" she said.

Every instinct in my body screamed: Rescue her. Stay up all night. Prevent the failure.

Instead, I said, "That's tough. What do you think you should do?"

"I don't know! Can you help me?"

"I can answer questions and point you in the right direction, but I can't do it for you. What are your options?"

She was crying and angry. "I don't have options! I'm going to fail!"

She made a plan and executed it poorly because she was exhausted. She failed that project, and I did not rescue her.

Three weeks later, a new project was assigned. She started immediately, planned it out, and finished two days early.

"I noticed you started this one right away," I said.

"Yeah," she said. "I didn't want to do that panic thing again. That sucked."

What she learned from that experience was worth more than any grade: consequences are real, she can survive failure, she can learn from her mistakes, she can plan ahead, and Mom won't rescue her — so she needs to rescue herself. In a word, she learned agency.

A year later, she manages her time well, plans ahead, and asks for help strategically rather than desperately.

The short-term rescue would have felt better for both of us. The long-term lesson was immeasurably better.

Real Transformations: What Changes

Here's what my graduates tell me, and the pattern is remarkably consistent:

"I came to learn to code. But what I actually learned was how to think. Now I approach my entire life differently."

They tell me they feel more in control — of their careers, their decisions, their lives. They tell me they can actually solve problems now, and not just coding problems but life problems. They tell me they don't panic anymore when things get hard because they have strategies. And more than a few have told me they feel like a different person — calmer, more confident, more capable.

One student put it perfectly: "I thought you were teaching me JavaScript. You were actually teaching me how to be an effective learner."

Sarah: From Panic to Agency

Sarah was twenty-three with a college degree and plenty of intelligence. Her first genuinely hard coding problem led to a full panic attack. During her first month, she cried twice a week and almost quit. I wouldn't let her.

Six months later, she was talking my ear off about how she no longer made decisions emotionally. She could think through difficult situations and feel confident she was making smart choices.

Her whole life was different from that point on.

From One Parent to Another: The Hard Truth

I won't pretend this is easy, because it isn't.

It's slower. Letting your child think takes far longer than just telling them the answer. It's frustrating, because you know the answer — you can see what they need to do — and you have to sit there and watch them struggle. They get mad at you. "Just TELL me!" is something I hear weekly, sometimes through tears, sometimes through yelling.

You'll doubt yourself constantly. Am I being too hard? Should I just help? And teenagers are especially challenging — emotional intensity plus cognitive development is a lot to navigate.

Other parents will judge you for it, too. I've gotten comments like, "You let her turn in that project? You could have helped more." Yes. I could have. I chose not to.

But It Works

Are my daughters perfect? No. Do they still have meltdowns? Yes — they're teenagers. Do they make bad decisions? Absolutely.

But they have tools. And I watch them reach for those tools more and more as they grow.

If it works for me — juggling a demanding job, parenting chaos, and two very different kids — it can work for you. You don't have to be perfect. You just have to be intentional.

Start where you are. Your kids will thank you. Maybe not this year. Maybe not until they're twenty-five.

But they will.

Miguel's Epiphany

Remember Miguel from the beginning? The one who was frustrated with me for six months straight?

About a year after graduation, I saw his LinkedIn post. His company was training him to mentor junior developers, and he'd taken an introductory coaching class. Here's what he wrote:

Something clicked today. I recently started taking a few courses in professional coaching, and I realize that this is what my instructor was doing for six months.

He never gave me the answers. He just asked me questions and made me come up with the answers myself. I thought he was being difficult. Or didn't want to help. Or liked watching us struggle.

Turns out he was coaching me on how to think.

I sat at my desk and smiled.

Quick Start: Five Things for Tonight

If this all feels like a lot, just start here. Tonight, do one of each:

1. Ask one Socratic question instead of giving one answer.
2. Praise one process instead of one outcome.
3. Think out loud once so your child can hear what reasoning sounds like.
4. Normalize one struggle instead of rushing to fix it.
5. Let them work through one problem on their own.

That's it. Start small, be consistent, and trust the process. Your child's future self will thank you.

In the rapidly evolving landscape of technology, AI code generation has emerged as a transformative—and contentious—force in software development. Yet, amidst the buzz, uninformed opinions, and typical mass-media hyperbole that dominate professional platforms, it's critical to establish a grounded perspective on what AI really means for developers and the future of our profession.

AI Code Generation: Evolution, Not Revolution

AI code generation isn't a sudden disruption—it's simply the natural evolution of what developers have been doing for decades. Our core responsibility has never been about typing code; it's about solving problems and defining resilient, scalable, and efficient solutions.

Think back to our progression over the decades:

• We started with manual coding of everything
• Then adopted libraries to avoid reinventing the wheel
• Then embraced frameworks that provided structural patterns
• Then built our own social platforms where code could be shared
• Then utilized code generators and snippets to accelerate common tasks
• Now we're employing AI to handle the "busy work" of implementation

This progression has consistently moved us away from the mechanical aspects of coding toward focusing on the more valuable aspects of development: architecture, design patterns, and business requirements. With AI handling implementation details, we aren't becoming obsolete—we're evolving into highly trained prompt designers and solution architects.

Job Security in the AI Era

No, AI will not take our jobs. Rather, it will vastly accelerate our work if we adapt our skills to provide comprehensive context and clearly defined plans to our AI tools. The developers who thrive will be those who:

• Understand systems holistically
• Can translate business requirements into technical specifications
• Know how to guide AI tools with contextually rich prompts
• Can validate, refine, and integrate AI-generated outputs
• Maintain a critical eye for edge cases and potential issues

The value proposition of developers is shifting from

"I can write this code"

to

"I can envision this solution and orchestrate its implementation."

This is a higher-order skill that AI enhances rather than replaces—which is a good thing because we aren't paid by a business to write code, but rather in return for the value we provide in building their products that generate revenue.

It is our professional integrity that ensures that the code is structurally and systemically sound, and is highly efficient and maintainable.

The Rise of Internal AI Systems

As the limitations and security concerns of public LLMs become more apparent, forward-thinking companies are increasingly investing in building internal AI systems. These proprietary solutions offer significant advantages:

• Protection of intellectual property and trade secrets
• Domain-specific training that understands company architecture and coding standards
• Integration with internal systems and codebases
• Compliance with industry-specific regulations

This trend creates new opportunities for developers with expertise in AI infrastructure, model fine-tuning, and system integration. Far from eliminating jobs, it's creating entirely new specialized roles within the development ecosystem.

The Emerging TPO/BPO Tandem

The future of product development likely involves a restructuring of traditional roles into a tandem team approach:

• Business Product Owners (BPOs) will focus on client relationships, gathering requirements, and defining features from a business perspective.
• Technical Product Owners (TPOs) will translate those requirements into technical specifications and work with agentic AI tools to produce the code and systems for implementation.

This partnership model leverages AI while maintaining the crucial human elements of client understanding and technical oversight. The TPO role becomes less about direct coding and more about system design, prompt engineering, mentorship, and quality assurance.

The Critical Role of Mentorship

The most important of those skills for the long-term health of any organization is the constant development of strong mentorship skills. As AI handles more routine coding tasks, the transmission of deeper architectural knowledge and system thinking becomes essential. TPOs might typically be responsible for training 1-3 apprentices in the skillset needed to thrive in this new paradigm.

This mentorship component addresses one of the most legitimate concerns about AI in development: how will the next generation learn if they don't begin with the fundamentals? The answer lies in intentional apprenticeship structures where experienced TPOs guide newcomers through understanding not just what code does, but why certain approaches are chosen and how systems work together.

The Future

The integration of AI into software development isn't about replacement—it's about augmentation and evolution. By embracing AI as a partner rather than fearing it as a competitor, developers can focus on the higher-value aspects of their profession while accelerating delivery and innovation.

Those who adapt their skills to include prompt engineering, system architecture, and mentorship will not only survive but thrive in this new era of development. The future belongs not to those who can code faster, but to those who can envision solutions more clearly and guide both humans and AI tools toward their successful implementation.

You can either fight this trend because you feel threatened by it, or you can develop your growth mindset and embrace this new tool and help guide its integration into our profession. If you choose the former, you are largely guaranteeing your obsolescence.

When building Lore, a service that provides AI-generated programming concept explanations to beginners, I faced an interesting challenge: How could I ensure reliable delivery of streamed responses while maintaining real-time performance?

The solution drew inspiration from one of networking's most battle-tested protocols - TCP's sliding window mechanism.

If you are new to TCP, I highly recommend reading "What is TCP (Transmission Control Protocol)?"

The Challenge

Streaming AI-generated text presents several reliability concerns:

• Network interruptions could cause lost chunks of text
• Client-side processing delays might miss chunks
• Server-side buffer overflows could drop content
• Out-of-order delivery would create nonsensical responses

Traditional request/response patterns wouldn't work well here. I needed a way to stream content as it was generated while ensuring every piece reached the client in the correct order.

The TCP Inspiration

TCP's sliding window protocol has managed reliable data transfer across unreliable networks for decades. Its core concepts seemed perfect for this use case:

• Sequence numbers for tracking chunks
• Window-based flow control
• Acknowledgment system
• Retransmission of lost data

Video Demo

I recorded the initial service demo immediately after I had a reliable, working version. There are mny things that need to be done to make it robust and scalable to more than one user, but I'm excited that I got the basics to work.

Implementation

I designed a buffering system that mirrors these TCP concepts:

class ChunkBuffer:
    def __init__(self, request_id: int, window_size: int = 5):
        self.request_id: int = request_id
        self.window_size: int = window_size
        self.buffer: dict[int, TextChunk] = {}
        self.next_sequence: int = 0
        self.last_acked: int = -1
        self.unacked_chunks: dict[int, TextChunk] = {}
        self.last_transmit: dict[int, float] = {}
        self.condition = threading.Condition()

The buffer maintains a window of unacknowledged chunks. Chunks are built up as my model generates new text from a streamer.

# Initialize a streamer so I don't have to wait for entire response
streamer = TextIteratorStreamer(
    self.tokenizer,
    timeout=None,
    skip_prompt=True,
    skip_special_tokens=True
)

Then a new thread is started in which the generate() method on the model is called.

thread = threading.Thread(
    target=self.model.generate,
    kwargs={
        "input_ids": inputs["input_ids"],
        "streamer": streamer,
        "max_new_tokens": self.settings.MODEL_MAX_LENGTH,
        "do_sample": True,
        "temperature": self.settings.MODEL_TEMPERATURE,
        "top_p": 0.9,
        "top_k": 50,
        "repetition_penalty": 1.2,
        "no_repeat_ngram_size": 3
    }
)
thread.start()

The cool thing about this is that I can now just wait for new bits text to be generated by the model, and build up chunks to be sent to the client.

# Process generated chunks
current_chunk = ""
for new_text in streamer:
    current_chunk += new_text

    # Buffer chunks when they reach defined size
    if len(current_chunk) >= self.settings.BUFFER_CHUNK_SIZE:
        chunk_obj = buffer.add_chunk(current_chunk)
        current_chunk = ""

        # Publish new chunk to the message bus
        self.valkey.publish(
            f'{self.settings.RESPONSE_CHANNEL_PREFIX}{question.request_id}',
            chunk_obj.model_dump_json()
        )

The Flow Control Dance

Just like TCP, the system uses back pressure to prevent overwhelming any component:

1. The model generates text chunks
2. Chunks enter the buffer until it reaches window_size
3. Generation pauses until acknowledgments arrive
4. Each acknowledgment frees buffer space
5. Generation resumes when space is available

This creates a natural flow control system where the client's processing speed influences the generation pace.

Multi-Threaded Architecture

The service runs multiple concurrent threads to handle different responsibilities:

1. Question Thread: Listens for incoming questions and initiates response generation
2. AI Thread: Handles the model inference and chunk generation
3. Acknowledgment Thread: Processes chunk acknowledgments
4. Retransmission Thread: Monitors for and handles lost chunks

Here's how the service initializes the initial threads. The text generation thread was shown above.

def start(self) -> None:
    """Start all service threads"""
    try:
        # Initialize and start service threads
        self.question_thread = threading.Thread(
            target=self._process_questions,
            name="question_thread"
        )
        self.ack_thread = threading.Thread(
            target=self._process_acks,
            name="ack_thread"
        )
        self.retransmit_thread = threading.Thread(
            target=self._process_retransmits,
            name="retransmit_thread"
        )
        
        # Start threads
        self.question_thread.start()
        self.ack_thread.start()
        self.retransmit_thread.start()
        

Monitoring with Prometheus and Grafana

To ensure reliability and performance, the service includes comprehensive monitoring using Prometheus and Grafana running in Docker containers. The Lore service publishes metrics data in key places, which is available from a Prometheus HTTP server. Grafana, running as a separate service, periodically scrapes that raw data to display it in a more visuall appealing way.

Prometheus Metrics Collection

The service exposes key metrics through a Prometheus endpoint:

• Buffer utilization rates
• Chunk transmission latency
• Acknowledgment processing times
• Retransmission counts
• Model generation speed

Real-Time Delivery with Server-Sent Events

Lore implements real-time response streaming using Server-Sent Events (SSE), enabling chunk-by-chunk delivery of AI responses to clients. The streaming process involves three main components working in concert.

Message Flow

First, Lore generates response chunks and publishes them to Valkey. Each chunk is a complete package of information.

• Sequence number
• Text generated by model
• Request ID
• Completion status

The Django API acts as the intermediary, subscribing to these chunks from Valkey as they arrive. It creates a streaming response using StreamingHttpResponse and formats each chunk as an SSE event. Throughout this process, the API maintains an open connection, staying ready to receive and forward chunks until the final one arrives.

On the frontend, the client establishes an SSE connection to receive these chunks in real-time. As each chunk arrives, the client processes it and sends back an acknowledgment to confirm receipt. This acknowledgment system is crucial for reliability—if any chunks go missing in transit, they'll be automatically retransmitted. The entire process is designed for smooth, efficient operation from start to finish, with clean connection handling throughout.

This architecture ensures:

• Real-time delivery of responses
• Reliable message delivery with acknowledgments
• Automatic retransmission of lost chunks
• Clean connection handling

Results

The TCP-inspired design of this system has exceeded expectations in production. By implementing sequence numbers, acknowledgments, and retransmission, I've achieved perfect reliability — not a single chunk has been lost.

The sequencing system ensures responses always arrive in the correct order, while the windowing mechanism provides natural flow control. When the client application process chunks slowly, the system adapts automatically rather than overwhelming them with data.

Even network interruptions are handled gracefully, with the system picking up right where it left off when the connection is restored.

Conclusion

By borrowing concepts from TCP and implementing a multi-threaded architecture with robust monitoring, I turned a potentially fragile streaming system into a reliable, observable, production-ready service. It's a reminder that often the best solutions come from adapting proven patterns to new contexts while ensuring proper observability.

If you ask most people what the most important skill a software developer needs is, the answer would likely be "good code." If you stop thinking about it at that point, then the apparent plan to train beginners in software development would be to simply teach them how to code. There are many tales fraught with the errors of this misguided approach.

My assertion is that the ability to efficiently solve problems with technology is what brings value. The medium by which a software developer solves problems is, most often, code.

The ability to produce accurate, reliable code is an emergent behavior of four fundamental skills, or principles. If you can coach someone to strengthen these essential skills, then their ability to provide value to an organization through their code is a natural outcome of the expression of those skills.

Much like a painting maestro would never hand beginners brushes and paint and tell them to start painting, beginner software developers should not be told that their primary goal is to write code.

To continue the analogy, before a person can focus on creating art, the following foundational pillars of the craft must be developed:

1. Composition
2. Color theory
3. Anatomy and figure drawing
4. Perspective
5. Art history

First Pillar: Communication

To solve a problem, one must first understand the problem.

The only way to understand the problem is to be able to communicate with the people around you. This skill must be strengthened to produce a valuable software developer since she must communicate effectively with technical and non-technical people.

Modern software development is a team sport.

1. Master complex communication during group-based work.
2. Use correct vocabulary when describing technical concepts.
3. Know how and when to ask for help from a senior technical resource.
4. Know how and when to ask for clarification from customers, product managers, and product designers.
5. Document solutions and challenges with clear, easily understood language.

Second Pillar: Analytical Thinking

Once a problem is understood, one must analyze it and break it down into technical tasks.

Imagine that your product managers have discovered a need by your customers. They need to see the daily report of yearly sales trends. Each night, a day's sales need to be processed and added to a database. By the next day, business owners should see the total sales, by product category, across the entire year, including the previous day's sales.

When a software developer looks at a business problem like this, analytical thinking is required to identify all the technical tasks necessary to accomplish this goal.

1. Ensure that the graph data includes the previous day's sales.
2. Be alerted when daily sales fail to be loaded into the database.
3. Execute a process to get daily sales loaded to load into the database.
4. Transform the raw data into a format that is needed for the graph.

This is a small sample of smaller tasks that, when completed, will work together to solve the problem. Possible tools are identified, and then each one is evaluated to determine which one would be the most effective for each task.

Third Pillar: Algorithmic Thinking

Once a problem is understood, analyzed, and deconstructed into functional units, algorithmic thinking develops a logical, efficient series of steps to solve each unit. Each functional unit is broken down into basic operations (BO) or elementary operations (EO).

A software developer must identify and understand the dependencies in the task list and document an order of operations that must be followed.An efficient developer would rearrange the tasks into the following order in the example series of tasks identified in the previous section.

1. Execute a process to get daily sales loaded into the database.
2. Be alerted when daily sales fail to be loaded into the database.
3. Transform the raw data into a format that is needed for the graph.
4. Ensure that the graph data includes the previous day's sales.

Then each task would be broken down further into small, discrete operations. For example, the operations for the first task could be defined with the following list.

1. Update the sales database table to include a timestamp.
2. Define a code module that would accept data from retail locations, and include validation that it is in the expected format.
3. Update the database access module to allow the daily sales to be inserted into the database.
4. Create a new endpoint in the API that all retail locations would send their daily sales.
5. Document the endpoint, parameters, and validations so they can be sent to the retail locations to be implemented.

Algorithmic thinking is critical to ensure an effective workflow for the entire team so that the solution can be delivered to the customer in a reasonable amount of time and for a reasonable cost.

Doing things in the wrong order ensures wasted efforts, failing tests, and increased costs.

Fourth Pillar: Efficient Learning

Talk to any software developer about the state of the profession, and the topic of the rapid pace of new technologies and tools being produced will come up. As a community, software developers continually devise new tools, and new languages, with the intent of making the job easier and the code more efficient.

This happens quite often, so a software developer must be efficient at learning these new tools to keep their skills sharp and provide maximum value.

Efficient learners take the time to use every resource available to learn a new skill or implement a non-mastered skill in a new context. Some specific tools and skills must be used for beginners to learn the basics.

1. Referencing previous solutions
2. Expert debugging skills
3. Context-complete generative AI prompting
4. Browser developer tools
5. Searching the Web for resources, and evaluating results

Efficient learners also take a critical approach to what must be learned next. Learning the latest and greatest tool is often not the best approach to ensure you are increasing your value. I believe a balanced approach of learning fundamental concepts and skills along with modern tools serves technologists, and the businesses they support, best.

An Analysis of its Impact on Web Development

Introduction

Since the inception of the World Wide Web in the early 1990s, JavaScript has been the primary language for creating interactive and sophisticated user interfaces in web browsers. As an interpreted language, JavaScript lacks static typing in its core specification, offering flexibility and ease of use that have contributed to its widespread adoption. However, in recent years, Microsoft's TypeScript has gained significant popularity among developers, sparking debates about its value and impact on web development.

This article aims to provide a balanced, evidence-based analysis of the impact of TypeScript on web development, comparing it to traditional JavaScript. We will explore the claimed benefits of TypeScript, examine criticisms and challenges, review available empirical evidence, and consider the broader context of the evolving JavaScript ecosystem.

The Rise of TypeScript

Background

TypeScript, first released by Microsoft in 2012, is a strict syntactical superset of JavaScript that adds optional static typing to the language. It compiles to plain JavaScript, allowing it to run in any environment that supports JavaScript, including browsers, Node.js, and Deno.

The key features that distinguish TypeScript from JavaScript include:

1. Static typing
2. Class-based object-oriented programming
3. Improved tooling support
4. ECMAScript features from future JavaScript versions

TypeScript was designed to address perceived shortcomings in JavaScript, particularly for large-scale applications. Its development was led by Anders Hejlsberg, the lead architect of C# at Microsoft, which partly explains its appeal to developers from statically-typed language backgrounds.

Reasons for Adoption

The adoption of TypeScript has been driven by several factors:

1. Enhanced Developer Experience: TypeScript's static typing enables better IDE support, including improved autocompletion, navigation, and refactoring tools. This can lead to a more efficient development process, especially in larger codebases.

2. Error Detection: The type system allows many errors to be caught at compile-time rather than runtime, potentially reducing the number of bugs that make it to production.

3. Code Documentation: Types can serve as a form of self-documentation, making it easier for developers to understand and work with existing code.

4. Scalability: For large projects with multiple developers, TypeScript's features can help enforce more consistent coding patterns and make it easier to maintain and refactor code over time.

5. Familiarity for Java/C# Developers: The static typing and object-oriented features of TypeScript can make JavaScript development more approachable for developers coming from languages like Java or C#.

6. Corporate Backing: Microsoft's support and continued development of TypeScript have given it credibility in enterprise environments.

Reasons Not to Adopt

Despite its growing popularity, there are several reasons why some developers and organizations choose not to adopt TypeScript:

1. Added Complexity: TypeScript introduces additional concepts and syntax that developers need to learn, which can increase the learning curve for those already proficient in JavaScript.

2. Compilation Overhead: TypeScript requires a compilation step, which can add complexity to the build process and potentially slow down development cycles.

3. Type Definition Maintenance: For projects using third-party libraries, maintaining and updating type definitions can be an ongoing challenge.

4. Overengineering Risk: In some cases, developers often overuse TypeScript's features, leading to unnecessarily complex code that's harder to maintain.

5. Limited Runtime Benefits: TypeScript's benefits are primarily during development; it doesn't offer performance improvements at runtime compared to equivalent JavaScript code.

6. Ecosystem Maturity: While improving, not all JavaScript libraries and frameworks have robust TypeScript support, which can lead to integration challenges.

7. Project Size Considerations: For smaller projects or rapid prototyping, the benefits of TypeScript most likely do not outweigh the initial setup and ongoing maintenance costs.

In the following sections, we will delve deeper into both the claimed benefits and criticisms of TypeScript, examining the available evidence to provide a balanced view of its impact on web development.

Claimed Benefits of TypeScript

Proponents of TypeScript often highlight several key advantages over traditional JavaScript. Let's explore these claimed benefits in detail, while also considering potential counterarguments to provide a balanced perspective.

Type Safety

One of the primary selling points of TypeScript is its static typing system, designed to catch type-related errors during development before the code is executed. With TypeScript, developers can annotate variables, function parameters, and return types with specific types such as string, number, boolean, or custom interfaces. The TypeScript compiler then checks these annotations against the actual usage in the code, flagging any mismatches as errors.

This type checking mechanism is said to offer several benefits. Firstly, it allows for early error detection, potentially reducing the number of bugs that make it to production. By catching type-related issues during development, programmers can address problems sooner, potentially saving time and resources in the long run.

Secondly, advocates argue that static typing leads to improved code quality. The process of thinking about and defining types can encourage developers to write more robust and self-documenting code. This added layer of information can make it easier for developers to understand the intended use of various components within a system.

Critical Considerations

The effectiveness of static typing in preventing bugs is a topic of ongoing debate in the programming community. Some argue that comprehensive unit testing can achieve similar or better results in terms of catching errors. Additionally, there's a trade-off to consider between the time spent defining types and the time potentially saved by catching type-related errors early. It's also worth noting that while TypeScript can catch many type-related errors during development, it doesn't eliminate the need for runtime type checking, especially when dealing with external data sources.

Developer Experience

TypeScript aims to enhance the developer experience, particularly when working with large codebases or in team environments. One of the most touted benefits is the improved tooling and IDE support that comes with static typing.

With TypeScript, developers often experience better autocompletion and IntelliSense in their code editors. This means more accurate and context-aware code suggestions as they type, which can speed up the coding process and reduce simple errors. Enhanced code navigation features, such as "go to definition" and "find all references," can also make it easier for developers to understand and work with large codebases.

These features can be particularly beneficial for team collaboration. Types can serve as a form of live documentation, making it easier for developers to understand and work with code written by others. This can lead to increased confidence when refactoring or modifying existing code, as the compiler will catch many potential issues.

Critical Considerations

It's important to note that the benefits of improved tooling may be less noticeable in smaller projects or for developers already proficient with JavaScript tooling. Some developers argue that the additional cognitive load of working with types can slow down the development process, especially during the initial learning phase. There's also a risk of over-reliance on tooling, which might lead to less attention being paid to writing clear, self-explanatory code. Furthermore, the need to maintain type definitions for third-party libraries can sometimes lead to version conflicts and additional maintenance overhead.

Code Maintainability

Advocates of TypeScript often claim that it leads to more maintainable code, especially in larger projects. The argument is that type annotations can make the intent of the code clearer, reducing the need for additional comments. Interfaces and type definitions can serve as contracts between different parts of the application, making it easier to understand how components interact.

For large-scale projects, TypeScript can offer several maintainability benefits. It can make onboarding new team members easier, as types provide additional context about the codebase. There's also a reduced risk when refactoring, as many potential issues will be caught by the compiler. Furthermore, TypeScript can help enforce consistency in data structures and function signatures across the project.

Critical Considerations

These maintainability benefits may be less pronounced in smaller projects or those with a short lifespan. It's also worth considering that overly complex type definitions can potentially make code harder to read and maintain. The maintainability benefits rely on consistent and judicious use of TypeScript features across the project. There's a risk of "type creep," where developers spend excessive time crafting elaborate type structures that add more complexity than clarity. Additionally, in fast-moving projects or those with changing requirements, the need to constantly update type definitions could potentially slow down development and become a maintenance burden in itself.

While TypeScript offers several potential benefits in terms of type safety, developer experience, and code maintainability, it's important to consider these advantages in the context of your specific project needs and team dynamics. The critical considerations highlighted for each benefit underscore the importance of carefully evaluating whether TypeScript is the right choice for your particular use case. In the following sections, we'll explore further criticisms and challenges associated with TypeScript adoption, providing a balanced view of its impact on web development.

Criticisms and Challenges of TypeScript

While TypeScript has gained popularity and offers several potential benefits, it's not without its critics. In this section, we'll explore some of the main criticisms and challenges associated with adopting TypeScript in web development projects.

Learning Curve and Complexity

One of the primary criticisms of TypeScript is the additional complexity it introduces to the development process. For developers who are already proficient in JavaScript, learning TypeScript requires understanding new concepts and syntax related to static typing.

The type system in TypeScript, while powerful, can be intricate. Developers need to learn about interfaces, generics, union types, and other advanced typing features. This learning curve can be steep, especially for those new to statically-typed languages.

Moreover, as projects grow in complexity, so too can the type definitions. In some cases, developers might find themselves spending significant time wrestling with the type system to express complex relationships between different parts of their codebase.

It is becoming common to hear developers complain that time spent wrangling complex types takes longer than development of the feature that was built. Certainly not good news.

Critical Considerations

The investment in learning TypeScript needs to be weighed against the potential long-term benefits. For small teams or projects with a short lifespan, the time spent learning and implementing TypeScript might not pay off. Additionally, the complexity of the type system can sometimes lead to overly verbose code, potentially reducing readability instead of enhancing it.

Development Speed

Another common criticism of TypeScript is its potential impact on development speed, particularly in the early stages of a project or when onboarding new team members.

The need to define types and interfaces before writing functional code can slow down the initial development process. This is especially true in rapid prototyping scenarios or when working on small, short-lived projects where the benefits of static typing might not be fully realized.

Furthermore, when working with third-party libraries, developers often need to install and manage type definitions separately. This can add an extra step to the development process and potentially lead to version conflicts.

Critical Considerations

While TypeScript advocates argue that the time invested in defining types pays off in the long run through fewer runtime errors and easier refactoring, there is rarely any actual data to support the assertion. The impact on development speed can vary greatly depending on the project's size, complexity, and the team's familiarity with TypeScript.

Runtime Performance

It's important to note that TypeScript's benefits are primarily realized during development. Once compiled, TypeScript code is converted to JavaScript, and all type information is erased. This means that there's no inherent performance benefit at runtime.

In some cases, the compiled JavaScript from TypeScript might even be slightly larger or more complex than hand-written JavaScript, although the difference is usually negligible with proper configuration.

Critical Considerations

The lack of runtime performance improvements can be a point of contention, especially when weighing the added complexity of TypeScript against its benefits. Some developers argue that well-written JavaScript with comprehensive testing can achieve similar levels of reliability without the overhead of TypeScript.

Tooling and Build Process Complexity

Adopting TypeScript typically means adding an extra step to the build process. The TypeScript compiler needs to transpile the code to JavaScript before it can be run in a browser or Node.js environment.

This additional compilation step can increase build times, especially for larger projects. It also adds complexity to the development toolchain, which can be a barrier for some teams or projects.

Critical Considerations

While modern build tools have made integrating TypeScript easier, the added complexity in the build process can still be a concern. This is especially true for teams that value simplicity in their toolchain or for projects that require quick iteration cycles.

False Sense of Security

One subtle but important criticism of TypeScript is that it can sometimes provide a false sense of security. While the type system catches many errors at compile-time, it doesn't eliminate the need for thorough testing and careful coding practices.

TypeScript's type system is also not sound, meaning there are cases where type checks can be bypassed, potentially leading to runtime errors that weren't caught during compilation.

Critical Considerations

Over-reliance on TypeScript's type system at the expense of other good development practices like unit testing, integration testing, and code reviews can potentially lead to issues. It's crucial for development teams to understand the limitations of TypeScript's type checking and not view it as a replacement for other quality assurance measures.

This article is part of the Follow the Science series where I share our team's journey in developing a learning experience based on modern cognitive science, learning science, and educational psychology.

Introduction

In the evolving landscape of education, particularly within the realm of software development, the shift towards self-directed learning paradigms represents a significant departure from traditional instructional methodologies. We adopt this approach in our learning experience and place the onus of learning on the students, providing them with the resources and the autonomy to navigate their educational journey within a flexible framework.

This model not only facilitates a personalized learning experience but also mirrors the demands and autonomy of professional life, preparing students for the realities of the software development industry.

Theoretical Foundations of Self-Directed Learning

Self-directed learning (SDL) is grounded in adult learning theory, particularly andragogy, which posits that adults learn differently from children. Malcolm Knowles, a pioneer in adult learning theory, suggests that adults are intrinsically motivated and self-directed (Knowles, 1975). They bring life experiences and knowledge to their learning experiences, which they want to be self-directed and relevant to their goals (Knowles, 1984).

Moreover, SDL aligns with the constructivist theories of learning, where knowledge is constructed rather than transmitted. Jean Piaget and Lev Vygotsky, both seminal figures in cognitive development theory, have outlined the importance of active engagement and social interaction in learning, which are key components of self-directed learning environments (Piaget, 1954; Vygotsky, 1978).

Benefits of Self-Directed Learning for Adults

Enhanced Learning Outcomes

Self-directed learning (SDL) tailors the educational process to the individual's learning style, pace, and interests, leading to enhanced learning outcomes. This customization makes learning more relevant and engaging for the adult learner, thereby increasing motivation and the likelihood of retaining information. When learners control their educational journey, they are more likely to delve deeper into topics of interest, leading to a profound understanding of the subject matter. This depth of understanding is crucial in fields like software development, where the application of knowledge to real-world problems is key.

Research indicates that SDL can lead to deeper understanding and retention of material. As learners tackle subjects like Vanilla JavaScript and React at their own pace, they engage more deeply with the content, applying it to practical projects that consolidate their knowledge (Garrison, 1997).

Development of Critical Thinking and Problem-Solving Skills

SDL experiences challenge learners to identify their learning needs, find resources to meet those needs, and apply the knowledge gained to solve complex problems. This process naturally develops critical thinking and problem-solving skills, as learners must evaluate the credibility of sources, synthesize information from various inputs, and apply theoretical knowledge to practical challenges.

Moreover, these skills are transferable across career paths and life situations, equipping learners with the ability to navigate uncertainty and complexity in professional and personal contexts.

The freedom to navigate challenges independently fosters critical thinking and enhances problem-solving skills, qualities that are invaluable in software development (Brookfield, 1986).

Increased Motivation and Satisfaction

The autonomy afforded by SDL enhances intrinsic motivation, as learners feel their educational journey is personally meaningful and directly aligned with their goals. This sense of ownership over one’s learning process increases satisfaction and commitment, making learners more likely to persist in their studies and pursue further education.

The achievement of learning milestones that learners have set for themselves can be particularly rewarding, reinforcing their motivation to continue learning.

SDL allows learners to pursue topics that interest them within the curriculum, which can increase intrinsic motivation and satisfaction with the learning process (Deci & Ryan, 1985).

Preparation for Lifelong Learning

In today's rapidly changing world, the ability to learn continuously is a critical skill. SDL encourages the development of metacognitive skills, such as self-awareness and self-assessment, which are foundational for lifelong learning. Adults engaged in SDL are better prepared to adapt to new information, technologies, and career paths because they have learned how to learn. They can independently seek out new knowledge and skills, making them resilient in the face of change.

By engaging in SDL, adults cultivate a proactive approach to education, where learning is seen not as a task to be completed but as an ongoing process. This mindset is essential for personal and professional development in a world where the only constant is change. Lifelong learners are more adaptable, more likely to embrace new opportunities, and better equipped to navigate the complexities of modern life and work environments.

The skills developed through SDL, such as time management, identifying learning needs, and seeking resources, are crucial for lifelong learning, enabling individuals to adapt to new technologies and methodologies over the course of their careers (Candy, 1991).

Application in Our Program

Our innovative software development bootcamp is meticulously designed to champion the principles of self-directed learning (SDL), a strategy that not only respects the autonomy of adult learners but also prepares them for the dynamic demands of the tech industry. The SDL approach is deeply embedded in every facet of our learning model, from the organization of course materials on GitHub to the structuring of the curriculum and the learner-instructor dynamics.

Content Delivery and Structure

We present the course content through GitHub, breaking it down into "books" and "chapters" that progressively build upon one another. This structure enables learners to navigate through the material at a pace that suits them best, fostering a sense of independence right from the outset. The only fixed time guidance within the first three months is the expectation to complete the Vanilla JavaScript material within eight weeks, ensuring all participants are ready to embark on at least two weeks of focused React learning before moving onto their first capstone project.

This phased approach allows learners to gradually enhance their skills, with each book designed to incrementally increase their competency in a way that mirrors real-world software development progression. By not imposing strict deadlines other than the three-month capstone project and the six-month graduation mark, we empower our learners to take full ownership of their educational journey.

Learner Responsibilities and Engagement

In our learning experience, the learners are entrusted with significant responsibility. They are expected to effectively manage their time, proactively request help, engage in daily vocabulary practice with their peers, and participate in instructor-led behavior modeling sessions. This framework encourages learners to develop essential soft skills, including time management, communication, and collaboration, which are as critical as technical proficiency in the software development field.

Unlike traditional educational models, our program eschews assigned homework and rigid project deadlines for regular work, placing the emphasis on learning through doing. This method not only enhances engagement and retention but also respects the individual learning processes of adult learners, who may have varying commitments and learning speeds.

Instructor Role and Learner Support

Instructors in our program act more as mentors than traditional instructors. Their primary role is to oversee the learners' progress, offering support and guidance rather than direct instruction. This mentorship model is crucial for SDL, as it provides learners with a safety net when they encounter challenges, ensuring that while the learning journey is self-directed, it is not solitary.

Regular meetings at the end of each book of material are the touchpoints where instructors ensure that learners have adequately grasped the concepts and vocabulary necessary for technical proficiency and success in technical interviews. These interactions are among the few structured elements of our program, designed to validate the learner’s progress and readiness to move forward.

Optional Interactions and Peer Collaboration

Crucially, aside from these scheduled check-ins, all other interactions with instructors are optional, requiring learners to be proactive in seeking out the assistance and guidance they need. This structure mimics the professional environment where initiative and self-motivation are prized, preparing learners not just technically but also mentally for their future careers.

The learner experience also leverages the power of peer learning, encouraging learners to collaborate and support each other's growth. This collaborative aspect of SDL not only enriches the learning experience but also builds a community of practice that can extend beyond the bootcamp into professional networks.

References

• Knowles, M. S. (1975). Self-Directed Learning. Chicago: Follett.
• Knowles, M. S. (1984). Andragogy in Action. San Francisco: Jossey-Bass.
• Piaget, J. (1954). The Construction of Reality in the Child. New York: Basic Books.
• Vygotsky, L. (1978). Mind in Society: The Development of Higher Psychological Processes. Cambridge, MA: Harvard University Press.
• Garrison, D. R. (1997). Self-Directed Learning: Toward a Comprehensive Model. Adult Education Quarterly, 48(1), 18-33.
• Brookfield, S. D. (1986). Understanding and Facilitating Adult Learning. San Francisco: Jossey-Bass.
• Deci, E. L., & Ryan, R. M. (1985). Intrinsic Motivation and Self-Determination in Human Behavior. New York: Plenum.
• Candy, P. C. (1991). Self-Direction for Lifelong Learning. San Francisco: Jossey-Bass.

I maintain a bespoke learning management platform application that I built for my team to track all kinds of student data. This week, I finally decided I wanted to tackle the slowest request in the entire application - students by cohort. I knew it would be a challenge to take all of the individual ORM statements I have written over the past 2 years and consolidate them into a speedier process. I was planning on spending about a week to analyze, tinker, refine and deploy a solution.

GenAI beat me to it.

It stole all that time and allowed me to do the entire process in about 10 minutes. Here's the tale about how it was able to steal my work from me.

Data Context

First, I learned that this infernal tool can ingest the DBML for my entire database as context and understand how the structure and relationships work. Here's a screenshot of my database. It's certainly not a large database, but 38 tables can challenge the most structured mind when trying to get data that spans 10 of them, and also requires conditions, grouping, and aggregate functions.

Since I know that it can parse DBML and generate high quality SQL statement from it, I decided to give this bugaboo the opportunity to fail. There was no chance that it could work at this level of complexity. I was sure of it.

I am providing the DBML for my API project below. I need you to take on the role of a business analyst and an expert SQL developer to help me generate SQL statements for new features for the project, and optimizing existing queries.

```dmbl
{ all my DBML here }
```

It was over-confident right from the get go. I couldn't wait to rub its smug face in how much I could do as a human that it couldn't.

Based on your DBML for the API project, I will help generate SQL statements for new features you might be considering and making existing queries more efficient.

Yeah, we'll see.

Slow Django Serialization

Again, my most egregious crime in this app is the slow build-up of more and more data being added to the information to be sent as JSON about the students in a cohort.

At first, it was just what project was being worked on. Then it was if an assessment was being worked on. Then weighted learning scores, assessment status, capstone submission, capstone submission statues, on and on and on. Finally, after all those additions, the HTTP request was taking over 2 full seconds to complete - unacceptable.

Now it was time to show GenAI how much it sucks and it will never replace humans. It's only for losers who don't know how to code in the first place. I copy-pastad my entire Django model, which has 6 methods on it used by the Serializer for producing a response. I asked it to produce a single SQL statment that would replace all of the separate ORM statements.

Below is an abbreviated version of the model. An experienced developer will immediately notice how much of a performance hit these will incur when run separately when used by a serializer build the JSON.

Time to break GenAI. Below is my prompt for ChatGPT, and I knew that I would get complete garbage as a response, and with further prompting, I might get something that could save me a little bit of time.

The Big Prompt

Here is a Django model based on the DBML above. Currently there are 6 methods - book, assessment_status, proposals, score, assessment_overview, and current_cohort - that are all used by a serializer to produce a JSON response with all of this information about a student. Because all of these execute separately, the operation can take over 2 seconds to complete. I want all of these combined into either a single Django ORM statement, or the full SQL in order to create a database function.

class NssUser(models.Model):
    """Model for NSS-specific user information beyond Django user"""

    @property
    def book(self):
        student_project = StudentProject.objects.filter(student=self).last()
        assigned_cohort = self.assigned_cohorts.order_by("-id").last()

        if student_project is None:
            cohort_course = CohortCourse.objects.get(cohort=assigned_cohort.cohort, index=0)
            project = Project.objects.get(
                book__course=cohort_course.course, book__index=0, index=0)

        ...
        
    @property
    def assessment_status(self):
        try:
            student_assessment = self.assessments.last()
            if student_assessment.assessment.book.id != self.book["id"]:
                return 0

            status = student_assessment.status.status
        ...
        
    @property
    def proposals(self):
        try:
            lastest_status = CapstoneTimeline.objects.filter(capstone=OuterRef("pk")).order_by("-pk")

            proposals = self.capstones.annotate(
                course_name=F("course__name"),
                current_status_id=Subquery(
                    lastest_status.values('status__id')[:1]
                ),
                current_status=Subquery(
                    lastest_status.values('status__status')[:1])
                )
                .values(
                    'id', 'current_status', 
                    'course_name', 'proposal_url', 
                    'current_status_id'
                )
        ...
        
    @property
    def score(self):
        scores = self.learning_records.filter(achieved=True) \
            .annotate(total_score=Sum("weight__weight")) \
            .values_list('total_score', flat=True)
        total = sum(list(scores))

        core_skill_records = list(
            self.core_skills.values_list('level', flat=True))
        ...

    @property
    def assessment_overview(self):
        for assessment in self.assessments.all().order_by("-assessment__book__index"):
            assessment_list.append({
                "id": assessment.id,
                "name": assessment.assessment.name,
                "status": assessment.status.status,
                "book": assessment.assessment.assigned_book,
                "reviewed_by": assessment.instructor.user.first_name
            })
        ...

    @property
    def current_cohort(self):
        assignment = self.assigned_cohorts.order_by("-id").last()

        return {
            "name": assignment.cohort.name,
            "id": assignment.cohort.id,
            "start": assignment.cohort.start_date,
            "end": assignment.cohort.end_date,
            "courses": assignment.cohort.courses
                .order_by('index')
                .values('course__name', 'course__id', 'active'),
            }

ChatGPT's Disgusting, Useless Response

Combining the operations of the six methods (book, assessment_status, proposals, score, assessment_overview, and current_cohort) into a single Django ORM statement or SQL query to fetch all required information in one go is quite complex and challenging. This is mainly due to the diverse nature of the data these methods retrieve, which spans across different tables with various relationships.

Aha!! Gotcha!!

As soon as I read that, I knew I'd won and proven my superiority. This tool is already admitting that it can't do it. One point for humans.

Wait.... what? Are there yet more foes that need to be vanquished?

However, I can outline an approach to create a more efficient SQL query or a set of queries that could potentially reduce the total execution time. The goal here would be to minimize the number of database hits by fetching related data in bulk and then processing it in Python.

Recommendation: Database Function or Stored Procedure:

Given the complexity, consider implementing a database function or stored procedure that encapsulates this logic within the database. This allows you to maintain complex logic in one place and potentially improve performance by utilizing database-specific optimizations.

After creating the stored procedure, you can call it from Django using a raw SQL query:

from django.db import connection

def get_student_details(user_id):
    with connection.cursor() as cursor:
        cursor.execute("CALL get_student_details(%s);", [user_id])
        result = cursor.fetchone()  # or fetchall() based on your needs
    return result

PostgreSQL Function for Student Details

This PostgreSQL function aims to provide a comprehensive overview of a student's details, including their latest book project, current cohort, assessment status, and a simplified score calculation. Given the varied nature of the data, some simplifications and assumptions are made for the sake of brevity and clarity.

-- I have removed much of the SQL, also for the 
-- sake of brevity of this blog post

CREATE OR REPLACE FUNCTION get_student_details(student_user_id INT)
RETURNS TABLE (
    full_name TEXT,
    latest_project_name TEXT,
    latest_book_name TEXT,
    ...
) AS $$
BEGIN
    RETURN QUERY
    WITH student_info AS (
        SELECT
            au.id,
            au.first_name || ' ' || au.last_name AS full_name
        FROM auth_user au
        WHERE au.id = student_user_id
    ),
    latest_project AS (
        SELECT
            sp.student_id,
            p.name AS project_name,
            p.id as project_id,
            ...
        FROM "LearningAPI_studentproject" sp
        ...
    ),
    current_cohort AS (
        SELECT
            nuc.nss_user_id,
            c.name AS cohort_name,
        ...
    ),
    assessment_status_agg AS (
        SELECT
            sa.student_id,
            sa.status_id,
            ...
        FROM "LearningAPI_studentassessment" sa
        ...
    ),
    score_calc AS (
        SELECT
            lr.student_id,
            SUM(lw.weight) AS total_score
        FROM "LearningAPI_learningrecord" lr
        JOIN ...
    )
    SELECT
        si.full_name,
        ...
        lp.book_id AS latest_book_id,
        coalesce(asa.status, 'Not Started') AS assessment_status,
        coalesce(sc.total_score, 0) AS total_score
    FROM student_info si
    LEFT JOIN latest_project lp ON si.id = lp.student_id
    ...;
END; $$
LANGUAGE plpgsql;

🤔

Stunned Silence

Ok, so I copy that into my SQL file and execute it. Dubious 🤨, but hopeful because my initial scan of the query had me feeling that it looked... kinda right.

I ran it for one student. It was right.

I ran it for another student in a different project. It was right.

I ran it for a student that wasn't working on an assessment. It was right.

I ran it for a student that was working on an assessment. It was right.

I ran it for a student that hadn't submitted a proposal. It was right.

I ran it for a student that had a capstone proposal and it was currently being reviewed. It was right.

I'm not going to lie. I absolutely could have completed all of this work myself using Google and my own knowledge. It also would have taken me a week, multiple dozens of Google searches, myriad mistakes, and multiple versions until I got a working version.

One thing that it missed is that I wanted to get this information for every student in a cohort, so the next step is to modify it for that data. I prompted it to update the query, but it didn't do that great of a job, and I needed to take over and finish it up myself.

I'd Like A Second Opinion

Ok, so ChatGPT did give it a valiant shot and saved me a considerable amount of time, but now my curiosity was piqued. I decided to shop my problem around to other interested parties. I'd heard good things of Claude so I headed down the highway to that shop.

I fed it the exact same prompts with no modifications and I was pleasantly surprised to see that it took a completely different approach. First, it produced an ORM statement that it believed met the requirements. ChatGPT didn't even try.

The ORM Edition

from django.db.models import OuterRef, Subquery, F, Sum

class NssUser(models.Model):

    @property
    def combined_data(self):
        subquery = StudentProject.objects.filter(student=OuterRef('pk')).order_by('-date_created')
        
        return self.prefetch_related('assessments', 'assessments__status', 'capstones', 'learning_records', 'core_skills', 'assigned_cohorts').annotate(
            latest_student_project = Subquery(subquery.values('project__book__id')[:1]),
            latest_student_project_name = Subquery(subquery.values('project__book__name')[:1]),
            latest_student_project_index = Subquery(subquery.values('project__book__index')[:1]),
            latest_student_project_date = Subquery(subquery.values('date_created')[:1]),
            latest_assessment = Subquery(self.assessments.filter(assessment__book=OuterRef('latest_student_project')).order_by('-date_created').values('status__status')[:1]),
            learning_record_score = Subquery(self.learning_records.filter(achieved=True).annotate(total=Sum('weight__weight')).values('total')[:1], output_field=models.IntegerField()),
            current_cohort = Subquery(self.assigned_cohorts.order_by('-id').values('cohort__name')[:1])
        ).values(
            'latest_student_project', 
            'latest_student_project_name',
            'latest_assessment',
            'learning_record_score',
            'current_cohort',
            # add other needed fields here
        )

The LEFT JOIN Edition

Now that was a great start, but it didn't stop there. It also generated SQL, but instead of using CTEs it just LEFT JOINed the heck out it.

SELECT 
    nu.user_id,
    nu.first_name || ' ' || nu.last_name AS user_name,
    sp.project_id AS latest_project_id,
    p.name AS latest_project_name,        
    sa.status AS latest_assessment_status,
    lr.total_score AS learning_record_score,
    c.name AS current_cohort
FROM LearningAPI_nssuser nu
JOIN LearningAPI_nssusercohort nc 
    ON nc.nss_user_id = nu.id
JOIN LearningAPI_cohort c 
    ON c.id = nc.cohort_id
LEFT JOIN LearningAPI_studentproject sp 
    ON sp.student_id = nu.id AND sp.date_created = (
        SELECT MAX(date_created) 
        FROM LearningAPI_studentproject 
        WHERE student_id = nu.id
    )
LEFT JOIN LearningAPI_project p 
    ON p.id = sp.project_id
LEFT JOIN LearningAPI_studentassessment sa 
    ON sa.student_id = nu.id AND sa.date_created = (
        SELECT MAX(date_created) 
        FROM LearningAPI_studentassessment 
        WHERE student_id = nu.id
    )
LEFT JOIN (
    SELECT lre.student_id, SUM(lw.weight) AS total_score
    FROM LearningAPI_learningrecord lr
    JOIN LearningAPI_learningrecordentry lre ON lre.record_id = lr.id
    JOIN LearningAPI_learningweight lw ON lw.id = lr.weight_id
    WHERE lr.achieved = true
    GROUP BY lre.student_id
) lr ON lr.student_id = nu.id
WHERE nc.cohort_id = cohort_id;

Again, that gets me about 90% of where I want to be and saved a lot of mistakes and me stupidly typing in syntax errors and yelling at myself. After tinkering with it for about 10 minutes, I got this version working the way I wanted.

So after all of this, I have two versions of a Postgres function that I can use in my app. Now I can take on the task of actually evaluating their performance in my actual application and make a judgement call on which one to use.

Time to Ask My Copilot

Until I originally published this article, I had never used Github Copilot.

Update on March 1, 2024

I made the assumption that since Copilot is an extension for VS Code that it had the capability of navigating my database structure via the Django models that are right there in the project. Based on that assumption, I provide the more concise prompt below.

Generate a read-only property that uses a direct connection to the database and a SQL statement to get the following information related to NSSUser. The current book the user is assigned to, the status of the current StudentAssessment being worked on (if any), a list of related Capstone rows, the SUM() of the weight field on the LearningRecord rows assigned to the user, all of the information from Cohort and CohortInfo for the most recent cohort the user is assigned to, all of the StudentNote records assigned to the user, and all of the Tag records assigned to the user via the StudentTag model. This is to replace all of the existing methods in this model. The generated code should not utilize any existing method or property.

The prompt was specific and provided guidance on exactly what I needed. Unfortunately, it did not produce a very accurate SQL statement. I include it below, but also removed chunks of it for brevity's sake. Because I didn't provide the DBML, it also misspelled some of the table names.

Once again the strategy for the SQL statement is very different from either ChatGPT or Claude. This produced more nested subqueries than the other two, and used some different functions.

SELECT
        COALESCE(p.book_id, 0) AS book_id,
        COALESCE(p.name, '') AS book_name,
        COALESCE(a.status, '') AS assessment_status,
        c.id AS cohort_id,
        c.name AS cohort_name,
        ci.client_course_url,
        ci.server_course_url,
        ci.zoom_url,
        c.start_date,
        c.end_date,
        ci.student_organization_url,
        SUM(lr.weight) AS learning_record_weight_sum,
        ARRAY_AGG(DISTINCT sn.id) AS student_note_ids,
        ARRAY_AGG(DISTINCT t.id) AS tag_ids
FROM
        "LearningAPI_nssuser" AS u
        LEFT JOIN (
            -- Subquery
            WHERE sp.date_created = (
                -- Sub subquery
            )
        ) AS p ON u.id = p.student_id
        LEFT JOIN (
            SELECT *
            FROM "LearningAPI_studentassessment" AS sa
            INNER JOIN ...
            WHERE sa.date_created = (
                -- Another sub subquery
            )
        ) AS a ON u.id = a.student_id
        LEFT JOIN (
            -- More sub queries and sub subqueries
        ) AS c ON u.id = c.id
        LEFT JOIN "LearningAPI_learningrecord" AS lr ON u.id = lr.student_id
        LEFT JOIN "LearningAPI_studentnote" AS sn ON u.id = sn.student_id
        LEFT JOIN "LearningAPI_studenttag" AS st ON u.id = st.student_id
        LEFT JOIN "LearningAPI_tag" AS t ON st.tag_id = t.id
WHERE
        u.id = 414
GROUP BY
        u.id, p.book_id, etc...
        ;

The True Power of GenAI

The point of this article was to demonstrate how ridiculously sophisticated these GenAI tools are, and how much time can be saved by software developers... if they learn how to generate powerful prompts and provide the context the tool needs.

As of right now, I find 100x time more value when I ask it to help me improve my code instead of asking it to generate new code from scratch.This saved me a tremendous amount of very complex, and cognitively challenging work, but it didn't do it for me.

It's not like I was working at my desk and it came up behind me like, "Hey dude, it's Gene. I saw you working on this ticket, but it looked cool so I did it for you. Here's the code."

(side note: I didn't like Gene)

• I had to understand the real problem.
• I had to know how to prompt a GenAI for valuable responses.
• I had to have the DBML for my database generated.
• I had to know which model, and which methods on that model were the bad actors.
• I had to design a very comprehensive, and specific, prompt that told it exactly what problem needed to be solved.
• I had to tell it how I wanted it to act and respond to my queries.
• I made sure to verify each solution and provide adjustments 3 times.

I feel pity for the low to mid-value developers on the Web that bash GenAI as a hack or a cheat that only losers use.

It's a new tool with a tremendous amount of power, for good or evil. It has some people (like me) thrilled and excited about the benefits that it brings to the world of software development. Some people are curmudgeons and say how much it sucks, or that it's a crutch for bad software developers.

I get it. Coming from a place of fear and anxiety is pretty normal for humans when confronted with something new like this.

"I learned it {insert some old way} and I turned out just fine! You kids these days want to take the easy way out."

To which I always call bullshit. If this tool was available to any of these folks when they were just starting out, it would have been like a miracle and they all would have used it.

This article is part of the Follow the Science series where I share our team's journey in developing a learning experience based on modern cognitive science, learning science, and educational psychology.

Introduction

Coding bootcamps are often thought of as intensive coding tutorial sessions where the only focus is on pounding out line after line of code. What if the ability to produce code is simply an emergent behavior of more fundamental skills that must be developed first?

This article explores how we integrate core problem-solving skills development into the experience, and how competence in code syntax is viewed as an important, but secondary, skill to learn.

The Giffygram Scenario

The 2023 team called me into their breakout room around mid-morning of the 3rd day to show me what they had pieced together. I was stunned.

In 2023, I had a team of developers that had the option to choose from 5 different projects that were designed for them to develop their communication and teamwork skills. One of those projects is called Giffygram. It is a simplified version of a social media platform where people create posts that contain only animated GIF images.

I gave the team an overview of the project and explained that their initial goal was to deconstruct an existing implementation and generate a technical specification that details how it was constructed. The code itself was compressed and uglified so they could not rely on using the source code to build the spec. They had to use their existing understanding of the strategies and concepts, and use all of the other diagnostic tools at their disposal to figure it out.

They had 5 days to deconstruct the project and then build their own implemetation from the spec.

This team took their job seriously. They spent 3 of the 5 days deconstructing the code, documenting how the HTML was structured, the CSS classes used, the payload/response signatures of each HTTP request, and the organization of the modules that had been downloaded to the client. They also built an incredibly accurate sequence diagram that fully articulated the flow of each feature in the application.

It was a testament to how to debug, investigate, and use analytical and algorithmic thinking skills. Truly one of the most impressive efforts that I've ever seen a team put into a group project.

Traditionally, I observe teams spend about 1 to 1.5 days on the deconstruction and problem-solving stage because they are focused on getting to the code writing stage as quickly as possible. They want to get it done rather than understand it.

This leads to the inevitable conclusion of having an incomplete project after 5 days that is rife with errors, and features that are half-implemented or implemented incorrectly. It's all part of being a beginner to learn those lessons the hard way.

The 2023 team called me into their breakout room around mid-morning of the 3rd day to show me what they had pieced together. I was stunned. I know many seasoned pros who could not produce the quality of documentation, depth of analytical and algorithmic thinking, and professional dedication that this team demonstrated to me.

After I made a couple minor corrections to their ERD and documentation, they forged ahead with coding the solution. At that moment, I was so proud that I didn't care at all that they would barely get any of the code written and wouldn't have much to show. After all, they had just over 1.5 days left to develop what is a complex application for beginners.

Imagine the depth of my astonishment when, at the end of the 5th day, they messaged me and said they wanted to demo their completed application.

That's right.

They built the entire thing in one and a half days. A team of beginners who didn't know what a function was just 50 days ago. It was a full stack application that made fetch calls to a JSON API service. It was a single-page application that dynamically rendered components given different states. It had a main feed with the ability to favorite posts, a new post component, a messaging component, a user profile component, with simplistic login/logout capabilities.

It was all done with Vanilla JavaScript. No advanced state-driven component library like React or Vue.

All of that was possible because they followed our advice -

Never try to solve a problem with code. Solve the problem, then code the solution.

The Science of Problem-Solving

Research in cognitive science suggests that effective problem solvers are not just knowledgeable in their field but also skilled in analytical thinking, algorithmic thinking, and efficient learning. Our strategy encompasses all these aspects to ensure a comprehensive learning experience.

Advances in technology and changes in necessary workplace skills have made the ability to think critically more important than ever before, yet there is ample evidence that many adults consistently engage in flawed thinking.

_{"Teaching Critical Thinking for Transfer Across Domains" - Diane Halpern (1998)}

Being able to think analytically and algorithmically are crucial to software developers because they provide value not through their code, but through their ability to solve problems. Code is simply the vehicle by which a solution is delivered.

The good news is that being aware of modern cognitive science about how the human brain learns means that you can craft a learning experience that methodically builds problem-solving skills.

Our Methodology

Our experience is crafted around reinforcing core problem-solving skills. It's not about the quantity of code written but the quality of the thought process behind it.

We have discovered over the years that many of our students begin day one with a diminished ability to think critically (i.e. analytically and algorithmically). The first section of the course introduces them immediately to two tools that help them strengthen the skill.

1. The Debugger - This allows them to track the data used in the application and understand the signal flow of basic software instructions.
2. Sequence Diagrams - This gives them the ability to build a visualization of an algorithm, which is immensely helpful to a beginner.

These valuable tools help learners build the foundation for how software works and enables them to design a solution for novel problems. Knowing the syntax for code is not enough. A learner needs to know exactly how the code is designed and executed.

Learners begin by seeing solutions for problems similar to what they will be asked to solve. They learn the basic tools and strategies they will be using professionally. Then they are asked to implement the strategies and tools to solve similar problems.

To help them effectively build these skills in problem solving, we use another strategy called Faded Worked Examples, which will be covered in another article.

Problem Solving Process

Here is an overview of the steps involved for a software developer to solve a business problem and deliver an effective solution.

1. Understand the problem
2. Break down the problem into atomic tasks
3. Consider solutions to each task
4. Implement solution for each task
5. Deliver solution to the problem

Because most of our learners begin the program unsure how to methodically solve problems using critical thinking skills, we model the process for them and expertly guide them through each step. We do this via three mechanisms.

1. Project based coursework
2. Collaborative sessions
3. Behavior modeling sessions

Project Based Course

Project-based learning will be explored in-depth in a separate article. At a high level, each section of the course focuses on a few core learning objectives, and students build 3 or 4 small-scale projects that are focused on developing the competencies in those objectives.

The first project provides them with a walkthrough of a solution that includes copious explanations, supporting videos they can watch to gain different perspectives, and graphics that help their brains learn through dual modalities. The last project they work on in the section simply provides the requirements and they must develop it completely from the ground up.

Collaboration Sessions

Weekly collaboration sessions are where student teams, usually comprising of 4 or 5 learner, use analytical and algorithmic thinking skills to solve a problem together with an instructor present. The instructor is not involved in building the solution, but rather serves as a coach during the process.

The learners are guided to first understand the problem that is presented for the project. Then, using only English comments, they developer their analytical thinking skills break down the project into the smallest operations possible.

Once the individual tasks have been defined, the learners then use their algorithmic thinking skills to rearrange them in the order in which they should be written. This tends to generate the most discussion, and a bit of coaching from the experienced coach to ask targeted questions about order of operations.

Finally, the students collaboratively start writing the code to implement each step in the algorithm.

Once they write all of the code and fix any remaining syntax errors, each team realizes that the code was obvious and they can get a working solution very quickly. It's the most effective way to demonstrate to beginners that code is the last part of the process. Coming into the program, their instinct is to start coding immediately and then fix it all as it becomes increasing complex and broken.

We give them the confidence to break that instinct and follow a process the valuable professionals follow.

Behavior Modeling

These sessions are where an instructor breaks down a problem, decides on a strategy for a solution, and slowly implements the solution while allowing learners to contribute if they want and answer all questions along the way.

It is a opportunity that students find highly valuable. They can listen to an experienced developer think through a problem, see how tickets are written, absorb more advanced analytical thinking and algorithmic thinking processes, and have some cognitive dots connected as the coach talks through their code implementation.

Ask most beginners and they will tell you that watching an experienced developer go through the process of solving a problem is an invaluable resource.

The Result

By taking this approach, one grounded in learning science, successfully develops professionals who are prepared to navigate the modern technological landscape. They are capable, well-rounded problem solvers equipped that can learn efficiently and provide value to their teams and customers.

I encourage educators and learners alike to embrace evidence-based practices. Think about how these insights can reshape your educational endeavors and share your thoughts or questions.

Follow the Science Series Introduction

In this first article of the "Follow the Science" series, you will learn about the goals of the series and get an overview of the concepts that will be covered.

The goal of this series is to share how we constructed a learning experience based on the results of modern cognitive science, learning science, and educational psychology. Traditional educational strategies were considered suspect unless they were backed by science and proven to be effective.

As an accelerated software development bootcamp, we were free of the constraints of the existing higher education system, and my hopes were to construct an effective, engaging, and hopefully fun learning experience based on science, not dogma.

Audience

I'm sharing this information in the hopes that it can provide some value, or generate productive conversations, for educators, students, policymakers or educational designers who are interested in learning science and coding education.

When educators follow the science, they position themselves at the vanguard of pedagogical innovation. This pursuit allows for constant evolution of teaching methods, making learning more effective and enjoyable.

Core Principles

Above the science, I have five driving goals for the learning experience.

1. Developing general problem-solving competence.
2. Student ownership of learning.
3. Personalizing the learning experience.
4. Differentiating to match individual zones of proximal development.
5. Coaching over traditional teaching.

The Science of Learning

Modern education has access to some exciting developments over the last 20 years, thanks in large part to breakthroughs in learning and cognitive science. As educators, course designers, or facilitators of learning experiences, it's crucial to stay abreast of this cutting-edge research.

Why?

Because the insights it offers allow us to create educational environments that are more effective, inclusive, and inspiring. This focus is not a luxury but a necessity for several compelling reasons.

Here are some high level concepts that will be explored in future articles that we use to guide how to nurture the experience.

• Project based learning
• Cognitive load theory
• Faded worked examples
• Reflection, interleaving, spacing, variation, elaboration, and retrieval
• Scaffolding
• Coaching/learning culture

Starting the Conversation

I will be sharing these article on various social media platform in the hopes that we can all learn from each other. I am hoping that you can engage with this content to share real experiences, failures, and successes just as I will.

I have learned more by reading and listening to others (including the students) than I have by using my own creative thinking skills.

Meeting the Needs of a Digital Age

In an era where technology is ubiquitous, cognitive research often intersects with technology and learning.

By following the science, we can ensure that our teaching methods evolve as our understanding of the learning process deepens. It's a commitment to never settling for "good enough," constantly seeking to understand our students better, and refining our craft to deliver the best possible educational outcomes.

I look forward to learning from you.