This is Part 2 in my 12-part series documenting what I learned in a business school course called “Technovate Thinking.”
In Part 1, I wrote about why someone with an IT infrastructure background would take this course, and how I reflected on the impact of ICT evolution on my work. This time, I’m covering the other major pre-work assignment for Session 1: building a program in Scratch and representing its algorithm as a flowchart.
The short version — I packed in way too much and completely overdid it. But thanks to that, the line between “skills I already have” and “skills I still need” became crystal clear. Here’s the record of what happened.
- 1 The Assignment: Build an Interactive Program in Scratch
- 2 What Happens When You Complete the Entire Textbook Before Starting the Assignment
- 3 I Built Far Beyond the Requirements
- 4 Overbuilt, Yes — But My Foundational Skills Showed Up
- 5 But I Realized My Logic-Building Skills Need Serious Work
- 6 Key Takeaway: “Structuring” and “Logic-Building” Are Different Skills
- 7 Next Up: Session 2 — Algorithm Fundamentals and Transition Diagrams
- 8 Books Referenced in This Article
The Assignment: Build an Interactive Program in Scratch
The Session 1 pre-work required us to build a program in Scratch and draw its flowchart. In broad strokes, it was an interactive program that responds to user input with relevant information.
A straightforward reading of the requirements would mean: take a string input, run it through conditional branches, and display the corresponding result. That would satisfy the brief. Done simply, it would probably be under 30 lines.
I did not choose “simple.”
What Happens When You Complete the Entire Textbook Before Starting the Assignment
Before touching the assignment, I worked through the entire textbook — Learning Programming and Algorithm Basics with Scratch (Revised 2nd Edition) — cover to cover, exercises included.
I knew I had no development experience, so I wanted a solid foundation first. The syllabus warned that beginners should expect significant prep time including the textbook, and I took that as a sign to be thorough.
In hindsight, that was the right call. I ended up comfortable with all of Scratch’s core building blocks: variables, lists, conditionals, loops, messaging, and custom block definitions.
But there was a side effect. “Being able to use every tool” inevitably leads to “wanting to use every tool.” And that’s exactly how the overengineering began.
This urge to “use everything because I can” may have been a uniquely beginner impulse. An experienced developer would draw the line at “is this sufficient for the requirements?” But for someone stepping into programming for the first time, having all these newly acquired building blocks right in front of me was irresistible. It was like being a kid with a full set of LEGO, determined to use every single piece.
I Built Far Beyond the Requirements
The program I ended up building far exceeded the assignment’s scope. Input variation handling, visual flourishes, user feedback collection and aggregation — I reached a point where I had to remind myself, “This is just pre-work.”
Naturally, the flowchart ballooned proportionally. What was probably expected to be a simple, compact diagram turned into a multi-section opus that sprawled across multiple pages.
…This was pre-work. For the first session.
Looking back, the reason for the overengineering is clear. I never asked myself, “What’s the minimum viable solution to meet the requirements?” Instead, I was driven by “I want to use everything I learned from the textbook.” In business terms, this is a textbook case of scope creep. It’s something I preach constantly in project management, yet the moment I became the one building, I forgot all about it. That realization stung.
Overbuilt, Yes — But My Foundational Skills Showed Up
That said, the overengineering came with some unexpected discoveries. In fact, these turned out to be the bigger takeaway.
The “thinking habits” I’d built over years of infrastructure design and operations translated naturally into Scratch — a completely different world. Specifically, three patterns emerged.
Habit 1: Modularize Everything (Reusability)
I defined every process as an independent custom block. The instinct to never write the same logic twice comes straight from infrastructure configuration management and scripting — my hands moved on their own.
The result was a clean main flow consisting of nothing but block calls, where any modification only required changing a single block.
This wasn’t because “I knew programming.” It was because the “don’t repeat yourself” instinct cultivated through years of system operations transferred directly. Even when the technical domain changes, design principles at the conceptual level still apply. Discovering this was genuinely confidence-building.
Habit 2: Track State with Variables and Initialize Rigorously (Structured Design)
I explicitly defined all state as variables and ran a single initialization routine at program start.
This came from the operational design habit of always thinking about idempotency and re-runnability. The principle that “running the same process under the same conditions should always produce the same result” holds whether you’re working in Scratch or in infrastructure.
Idempotency might not be a concept most people encounter when they first learn to code. But in infrastructure operations, it’s second nature. Seeing my own background prove useful in a completely different context — that was a profoundly meaningful moment. It reinforced why it matters for IT professionals to learn programming.
Habit 3: Keep Extension Points in the Data Layer
When I needed to add more data, I designed the program so that I could simply add entries to a list without modifying the program logic itself. Data separated from code.
This mirrors the infrastructure practice of externalizing configuration rather than hardcoding it. The instinct to build change-resilient structures just came out naturally.
What these three habits share is a mental model of “designing for future change and extension.” What’s second nature in infrastructure turns out to be equally valid in programming. When IT professionals learn to code for the first time, they’re not starting from zero. They already have something. Recognizing that was a welcome byproduct of going overboard.
But I Realized My Logic-Building Skills Need Serious Work
On the flip side, something hit me hard: “the ability to structure” and “the ability to build logic” are two very different things.
For example, when writing loops, I kept stumbling over the basics: “Should the index start at 0 or 1?” “Does the increment come before or after the comparison?” I could see the flow in my head, but when I tried to assemble it as Scratch blocks, it wouldn’t behave as expected.
Nested conditionals were the same story. Building them without gaps or overlaps took longer than I anticipated. Business school had drilled MECE thinking into me, but there was still a translation gap between MECE on paper and MECE in executable logic.
This “translation gap” deserves a closer look. MECE means “Mutually Exclusive, Collectively Exhaustive” — a framework for organizing without gaps or overlaps. But organizing ideas on paper in a MECE way and implementing MECE conditional branches in a program demand completely different levels of precision. On paper, “roughly MECE” passes. In code, anything less than “perfectly MECE” simply doesn’t work. This is something you can only truly grasp by getting your hands dirty.
And when it came time to draw the flowchart, I caught myself building the implementation first and reverse-engineering the diagram afterward. The proper order is obviously the opposite — design the logic in a flowchart, then implement it. But building was more fun, so I finished the program first and worked backward to create the flowchart.
This may be a common trap for “learn by doing” types. Infrastructure people, in particular, are culturally inclined to spin up a test environment before writing the design document. The habit of “build first, document later” is deeply ingrained. But what Technovate Thinking demands is the reverse — “design the logic first, then implement.” This might be the single most important skill for me to develop in this course.
Key Takeaway: “Structuring” and “Logic-Building” Are Different Skills
The biggest insight from the Session 1 assignment boils down to this:
- Structuring ability: The skill of breaking things into components, modularizing them, and organizing them for reuse
- Logic-building ability: The skill of precisely assembling sequence, conditions, and loops into something that actually runs
Years of IT work had honed the former. But the latter — actually building working logic from scratch — hadn’t been trained as much as I’d assumed through design and operations work. “Reading and understanding someone else’s code” and “building your own from zero” are fundamentally different. I’d done plenty of the former throughout my career, but had almost no experience with the latter. This assignment forced me to confront that.
Let me put these two skills in more everyday terms. Structuring ability is like “organizing a bookshelf” — sorting by genre, by size, putting frequently read books within reach. Logic-building ability is like “writing a recipe” — “high heat for 3 minutes,” “flip when browned.” It’s about specifying steps and decision criteria at a level of precision where anyone following them would get the same result. Being good at organizing doesn’t necessarily mean you can write a recipe. But someone who can do both? They’re incredibly powerful.
The premise of Technovate Thinking is that “humans handle the logical design.” Within that “logical design,” the structuring side looks solid; the logic-building side needs practice. Just getting a clear read on where I stand made the first assignment well worth the effort.
Next Up: Session 2 — Algorithm Fundamentals and Transition Diagrams
Session 2 digs deeper into algorithm fundamentals and introduces a new concept: Transition Diagrams. It’s a familiar idea from business system design, but revisiting it in this context brought fresh perspective. More on that next time.
Books Referenced in This Article
This is the book I read cover to cover before tackling the assignment. Even with zero development experience, I was able to work through it without getting stuck.
For a more systematic study of algorithms, this was suggested as supplementary reading.
And this is the companion text I’ve been reading throughout the course — useful for building a repertoire of management-level IT perspectives.
