The Case for Starting with Text: Why Blocks Aren’t the Only On-Ramp to Computer Science

There is a deeply held belief in computer science education that students must start with block-based programming before they can learn to write real code. Blocks first, then text. Crawl before you walk. It sounds intuitive, and for years it went largely unchallenged.

I want to challenge that belief-not because blocks are bad, but because the assumption that they are required deserves scrutiny, especially now. The tools have changed. The landscape has changed. And if we’re not careful, a well-intentioned pedagogical convention could become a barrier to the very thing we’re trying to teach.

I want to say clearly at the outset: this is not an attack on educators who use blocks effectively. Many of them are doing extraordinary work, and I have deep respect for the creativity and care they bring to their classrooms. What I’m questioning is the assumption-the default-that blocks are the necessary starting point for every student, at every level. That assumption deserves a closer look.

The Syntax Barrier Isn’t What It Used to Be

The original argument for blocks was compelling. Languages like Java and C++ had steep learning curves, full of semicolons, curly braces, type declarations, and boilerplate that buried the actual logic students were trying to learn. Blocks removed all of that friction and let students focus on thinking instead of typing. That was a genuine breakthrough.

But the programming world didn’t stand still. Python was designed from the ground up to be readable and beginner friendly. As Guido van Rossum, Python’s creator, has explained, the language was built to prioritize readability and minimize unnecessary syntax-using clean indentation instead of braces and friendly error messages to flatten the learning curve [1]. A student can write print("hello world") on their very first day. The syntax reads almost like English.

Python’s design philosophy-captured in PEP 8’s guiding insight that “code is read much more often than it is written” [2]-aligns directly with the goals that originally motivated blocks. The gap between what blocks offer and what Python demands has narrowed considerably. This raises a question worth sitting with: is the friction blocks remove still significant enough to justify an entirely separate programming environment, or are we solving a problem that has already been largely solved?

The Cost of the Detour

If blocks are a steppingstone, we need to be honest about what the step costs.

A 2025 systematic review published in the Journal of Computer Languages examined the full body of research on how students transition from block-based to text-based programming. What it found was not a single, manageable challenge. It identified eight distinct categories of difficulty that students face when making this shift [3]. Eight. Not a speed bump. A systematic breakdown in the learning pathway that the entire CS education research community is actively trying to solve. The fact that so much research energy is being spent on how to get students across this gap should itself tell us something: the gap is significant, and it is not going away on its own.

Think about what that means in a real classroom. A student spends weeks-sometimes an entire semester-building confidence in a block-based environment. They feel capable. They’re engaged. They’re starting to see themselves as someone who can build things with code. Then the curriculum shifts to text, and suddenly the environment they’ve grown comfortable in is gone. The interface is different. The feedback is different. The way they express ideas is different. Everything they’ve learned to rely on has been pulled out from under them.

Some students push through that transition. But some don’t. Some lose confidence. Some disengage. Some decide that programming isn’t for them-not because they lack ability, but because the shift felt like starting over. Those students don’t show up in the long-term outcome data. They’re simply gone. And every one of them represents a failure of the pathway, not a failure of the student.

There is also an opportunity cost that rarely gets discussed. Every week spent in a block-based environment is a week not spent building fluency in the language students will actually use going forward. Fluency in text-based code is cumulative-it compounds over time as students encounter more complex problems and develop deeper pattern recognition. That compounding starts the moment a student begins working in text. When students spend their first months in blocks instead, they aren’t just delaying the start of that process. They’re spending time building skills and habits in an environment they will ultimately have to leave behind.

And here is perhaps the most sobering finding: even for the students who do successfully make the transition, the early advantage blocks provide does not last. A quasi-experimental study by Weintrop and Wilensky (2019) followed students who started in either block-based or text-based environments and then transitioned to Java. After five weeks, the blocks group appeared to be ahead. But after fifteen weeks-once both groups had been working in text-there were no significant differences between them. Not in conceptual understanding. Not in attitudes. Not in programming practices [4]. The blocks group paid the cost of the transition and did not end up ahead.

Let that sit for a moment. The research tells us that the block-to-text transition is difficult enough to warrant eight categories of documented challenges, costly enough to lose students along the way, and after all of that-the students who survive it arrive at the same place as those who started with text from the beginning. That is not an argument for blocks as a starting point. That is an argument for reconsidering the entire detour.

Friction Can Be a Feature

One of the most counterintuitive arguments for text-based programming draws on a well-established concept in learning science: desirable difficulty. Psychologist Robert Bjork at UCLA introduced this framework in 1994, demonstrating that conditions which seem to slow learning in the short term often produce superior long-term retention and transfer [5]. Subsequent work by Bjork and Bjork (2011, 2020) has reinforced the finding that challenges requiring deeper cognitive processing-rather than smooth, frictionless experiences-lead to more durable learning [6].

When a student encounters a syntax error in Python, they have to slow down, read carefully, and figure out what the computer expected versus what they wrote. That process, frustrating as it can be, is a form of reasoning. It builds close-reading skills, attention to detail, and the habit of precise communication. These capacities are foundational not just in programming but in every technical discipline. Blocks protect students from that friction, but in doing so, they can also protect students from developing these capacities early.

The key insight from Bjork’s research is the distinction between performance and learning. Conditions that produce rapid performance gains-the kind that look impressive in the short term-often fail to support long-term retention, while conditions that feel harder in the moment promote deeper, more transferable understanding [6]. For many learners from middle school on, Python’s syntax sits in exactly this sweet spot: challenging enough to promote real learning, accessible enough that students aren’t overwhelmed.

Text Scales. Blocks Don’t.

Perhaps the most practical argument is about trajectory. A student who starts with Python can go from printing “hello world” to building web applications, analyzing data sets, training machine learning models, and automating real-world tasks-all in the same language, in the same environment, with continuous momentum.

Text-based code connects to everything. Every library, every API, every framework, every professional tool-GitHub, VS Code, CI/CD pipelines, code review systems, Stack Overflow, AI coding assistants-is built for text. The entire infrastructure of modern software development assumes text as the medium. A student who learns Python can install any package, contribute to any open-source project, and navigate any professional development environment. Block-based programming exists in walled gardens. A student working in Scratch or a similar environment cannot access any of that. That is not a pedagogical preference. It is an infrastructure reality.

The limitations become even more apparent as complexity grows. When a text-based project gets large, developers have an entire mature toolchain for managing it: search, diff, version control, automated testing, linters. When a blocks-based project gets complex, debugging means scrolling through visual stacks with no way to search, compare versions, or isolate changes. And the complexity ceiling is not abstract-it is concrete. Try building a program in Scratch that reads a CSV file, filters rows based on a condition, and writes the results to a new file. You cannot. In Python, that is six lines of code. That is not a difference in difficulty. It is a difference in capability.

When high school students were asked to compare block-based and text-based programming, they themselves identified blocks as being less powerful and more verbose than text-based alternatives [7]. These are students speaking from their own experience, not researchers imposing a judgment. A student who gets excited about a project in a block environment will eventually hit that ceiling, abandon that environment entirely, and start over in something new. That break in momentum matters, especially for students who are just beginning to see themselves as capable builders.

And here is why this matters beyond the classroom: every one of these capabilities-accessing libraries, reading error output, working with file formats, navigating real development tools-is exactly what is required to use AI effectively, whether you are analyzing data, automating a workflow, or vibe coding an application from a natural language prompt. When a student asks an AI assistant to build something and the AI generates Python that imports a library, reads a file, and throws an error on line twelve, that student needs text-based literacy to evaluate what happened and decide what to do next. Blocks do not prepare anyone for that moment. Text does.

With text-based code, there is no cliff. The path from beginner to advanced is continuous, the skills compound rather than reset, and the tools a student learns on day one are the same tools they will use for the rest of their career-or for every interaction they ever have with an AI coding assistant.

What AI Changes and What It Doesn’t

The rise of AI-powered coding tools has added a new dimension to this conversation. Some argue that because AI is changing how code gets written, syntax matters less than ever, and therefore the focus should shift entirely to computational thinking-with blocks as the ideal medium for teaching it.

There’s truth in the premise but a flaw in the conclusion. If AI tools can generate syntactically correct code from natural language prompts, then the syntax barrier that blocks were designed to address is dissolving on its own-without blocks. That development doesn’t make blocks more essential. If anything, it makes the unique advantage blocks once held less distinctive.

More importantly, AI coding assistants generate text-based code. Recent research in CS education has increasingly emphasized that in an AI-augmented world, the critical competencies for students include reading, evaluating, and debugging code that AI produces [8]. Students who will work alongside these tools need text literacy-the ability to look at generated code and reason about whether it’s correct, efficient, and safe. A student whose entire programming experience has been in a block-based environment has not had the opportunity to develop that skill.

The goal should not be to shield students from the complexity of generated code. The goal should be to prepare them to engage with it critically. That preparation happens in text.

A Note from the Other Side of the Keyboard

I want to add something here that isn’t from a research paper. It’s from my own desk.

I am not a software engineer. I’m a CEO. I don’t write production code and I never will. By every conventional measure, I am exactly the kind of person the blocks-first argument is designed to serve-someone who needs to think computationally but isn’t headed toward a career in programming.

Over the past year, I’ve begun using AI tools for tasks that go well beyond helping me write emails or summarize documents. I’m using them to work with data, to automate parts of my workflow, to build things I couldn’t have built on my own even six months ago. But it hasn’t been all smooth sailing. And surprisingly, my technical limitations have almost nothing to do with logic or problem-solving. They come down to dealing with text.

The bottleneck is not computational thinking. I can reason through a problem. I can break a complex task into steps. I can describe what I want clearly. What trips me up every time is the text. Understanding an error message. Recognizing when AI-generated output has a structural problem. Knowing enough about file formats, parameters, and configuration to evaluate whether what I’m looking at is right. Every one of those moments requires text-based technical literacy. Not block-based thinking. Text.

No amount of dragging and dropping blocks would have prepared me for those moments. What would have helped is earlier, even modest, exposure to reading and reasoning about text-based code-understanding its structure, its logic, its patterns. Not so I could become a developer, but so I could be a more capable partner to the AI tools I’m now working with every day.

I share this not because one person’s experience settles a pedagogical debate, but because it illustrates something the research supports: the future of working with technology-for everyone, not just engineers-runs through text. If we are preparing students for that future, we should be honest about what it actually demands.

Identity and Motivation Matter

There’s a dimension to this conversation that goes beyond cognitive outcomes: how students see themselves. Research has shown that students themselves perceive block-based programming as less authentic than text-based programming. They recognize it as a simplified version of what professionals actually do [7]. For older learners-middle schoolers, high schoolers, and certainly adults-that perception has real consequences for engagement and persistence.

Starting with Python signals to students that they are doing real, professional work from the beginning. That sense of legitimacy, of identity as someone who writes real code, can be a powerful motivator. For many students, especially those who are already uncertain about whether computer science is for them, that distinction matters enormously.

Blocks as Pre-Literacy, Not Pre-Programming

If the transition from blocks to text is as costly as the research suggests, a fair question follows: should we avoid blocks entirely, even for the youngest learners?

I don’t think so. But I think we need to be much more precise about what blocks are actually doing for young children-and what they are not.

For learners roughly aged six through ten, blocks serve a genuine developmental purpose. The motor skills required for typing aren’t fully developed at that age. Reading levels may not support text-based syntax. And the visual, tangible nature of blocks maps well to how young children learn. A recent meta-analysis found that block-based visual programming has a moderate positive effect on K-12 student learning, particularly in cognitive outcomes [9]. That’s real, and it matters.

But here is the critical distinction: what blocks teach a seven-year-old is not programming. It is computational pre-literacy-sequencing, cause and effect, basic logical reasoning, the idea that instructions have consequences. These are developmental building blocks, not programming building blocks. The difference matters because it changes what we expect the transition to look like.

We don’t worry about the “transition cost” from picture books to chapter books. We don’t fret that a child who loved illustrated stories will struggle when they encounter pages of plain text. We understand intuitively that picture books and chapter books serve different developmental purposes-one builds the love of narrative and the foundations of comprehension, and the other builds the skill of reading itself. They are not two points on the same continuum. They are different tools for different stages.

Blocks for young children should be understood the same way. A six-year-old dragging and dropping sequences in Scratch is not taking the first step on a programming ladder. They are building the kind of thinking that will make programming accessible when they’re ready. The transition problem the research documents-the eight categories of difficulty, the lost students, the advantages that don’t persist-arises specifically when blocks are used as the introduction to programming for students who are cognitively ready to work in text. That is where the cost is incurred. That is where the detour doesn’t pay off.

So, the argument is not that blocks have no place. The argument is that their place is developmental, not curricular-and that by middle school, students are ready for text, they benefit from text, and routing them through blocks as a programming prerequisite creates a cost that the evidence does not justify.

Moving the Conversation Forward

The blocks-first approach emerged for good reasons, and it has served many students well. But the landscape has shifted. Python lowered the syntax barrier years ago. AI tools are lowering it further. And the skills students most need going forward-reading code, debugging text-based programs, working critically alongside AI assistants-are skills that text-based environments build more directly.

This isn’t about declaring blocks obsolete. It’s about being precise about where they belong: as a developmental tool for young children building computational pre-literacy, not as a required prerequisite for students who are ready to write real code.

The best educators are already asking these questions. The rest of us should be asking them too. Our students deserve an honest, evidence-informed conversation about the best path to computational thinking-not one constrained by convention, but one shaped by where the field is actually heading.

References

[1] Van Rossum, G. (2025). Interview with GitHub. “Why Developers Still Flock to Python.” The GitHub Blog. Available at: github.blog (opens in a new tab)

[2] Van Rossum, G., Warsaw, B., & Coghlan, A. PEP 8 – Style Guide for Python Code. Python Enhancement Proposals. Available at: peps.python.org/pep-0008 (opens in a new tab)

[3] Strong, G., Bresnihan, N., & Tangney, B. (2025). Supporting learners in the transition from block-based to text-based programming: A systematic review. Journal of Computer Languages, 84, 101342.

[4] Weintrop, D. & Wilensky, U. (2019). Transitioning from introductory block-based and text-based environments to professional programming languages in high school computer science classrooms. Computers & Education, 142, 103646.

[5] Bjork, R. A. (1994). Memory and metamemory considerations in the training of human beings. In J. Metcalfe & A. Shimamura (Eds.), Metacognition: Knowing about Knowing (pp. 185–205). MIT Press.

[6] Bjork, R. A. & Bjork, E. L. (2020). Desirable difficulties in theory and practice. Journal of Applied Research in Memory and Cognition, 9(4), 475–479. See also: Bjork, E. L. & Bjork, R. A. (2011). Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning. In M. A. Gernsbacher et al. (Eds.), Psychology and the Real World (pp. 56–64). Worth Publishers.

[7] Weintrop, D. & Wilensky, U. (2015). To block or not to block, that is the question: Students’ perceptions of blocks-based programming. In Proceedings of the 14th International Conference on Interaction Design and Children (pp. 199–208). ACM.

[8] Prather, J. et al. (2024). Beyond the hype: A comprehensive review of current trends in generative AI research, teaching practices, and tools. In Proceedings of the 2024 Working Group Reports on Innovation and Technology in Computer Science Education (ITiCSE-WGR 2024). ACM. See also: Kazemitabaar, M. et al. (2023). Studying the effect of AI code generators on supporting novice learners in introductory programming. In Proceedings of CHI 2023. ACM.

[9] Yu, Q., Yu, K., & Li, B. (2025). Effects of block-based visual programming on K-12 students’ learning outcomes: A meta-analysis. Journal of Educational Computing Research. DOI: 10.1177/07356331241293163.

[10] Weintrop, D. & Wilensky, U. (2017). Comparing block-based and text-based programming in high school computer science classrooms. ACM Transactions on Computing Education, 18(1), 1–25.

[11] Mladenović, M., Žanko, Ž., & Zaharija, G. (2024). From blocks to text: Bridging programming misconceptions. Journal of Educational Computing Research. DOI: 10.1177/07356331241240047.