Programming Without Fear: Embracing Risk and Innovation

As a child, I was introduced to programming on a Commodore 64, a machine that had a reputation for being nearly indestructible. The Programmers Reference Guide even noted that software alone couldn’t break the machine–it might freeze up or require a reboot, but it would always bounce back. This knowledge had a significant impact on my approach to programming, instilling in me a sense of bravery and a willingness to experiment. Although modern computers are far more vulnerable to software-based damage, I find that the lessons I learned as a young programmer continue to inform my coding habits. Programming on the Commodore 64 helped shape my fearless approach to coding.

In the early to mid-eighties, when I began my programming journey, the fear of breaking a computer with software was not a common concern. I learned to program on the Commodore 64, a computer that was nearly impossible to break with software. This allowed me to approach programming with a sense of curiosity and bravery. I was not afraid to experiment and push the boundaries of what I could do with code.

However, it’s important to note that computers today are much more fragile and prone to breaking with software than the Commodore 64 was. It is very possible to brick a computer, making it worthless, just through software and commands. Additionally, as a programmer or user of a modern computer, it is possible to break the law, intentionally or unintentionally, through actions such as hacking, data theft, or the spread of malware. Therefore, it is important to approach programming and computer use today with caution and to take steps to protect yourself and your computer from harm.

The introduction of test-driven development (TDD) further reinforced my confidence in programming. By writing tests first and then developing code to meet those tests, I knew that I had a safety net to catch any mistakes or errors. This allowed me to continue experimenting and trying new things with the knowledge that I could always revert to a working version of my code.

While I have broken my operating system and caused software bugs in my career, I have found that my childhood experience has helped me to approach these challenges with a sense of calm and confidence. I know that mistakes will happen, but I also know that they can be fixed. Additionally, I have learned that it is important to take responsibility for any mistakes and work to prevent them from happening again in the future.

Learning to program on a Commodore 64 without fear of breaking the computer with software had a profound impact on my approach to programming. Today, I continue to experiment and push the boundaries of what I can do with code, confident in my abilities and my safety nets. While computers today are more fragile and prone to breaking with software, I believe that my childhood experience has helped me to be a more courageous and responsible programmer. By taking precautions and approaching programming with care and responsibility, we can all strive to be confident and brave programmers in the modern age.

---

By Ron Ziroby Romero with assistance from ChatGPT

Image: https://www.c64-wiki.com/wiki/File:C64PRG_cover.jpg

Austin Style Code Dojo

Here in Austin, Texas, we’ve just started weekly dojos. Our dojo style is similar to Randoori, but without pairing (instead of pairs, we’re all one set).  In Randoori terms, we use something similar to Ping Pong.

The flow goes like this: One of the coders writes a failing test.  Lately we’ve discussed the proper API in detail during this step.  I think we’re trying to learn the wisdom of proper test structure.

Once the test fails, that person sits down, and someone else goes to the keyboard.  That person solves the test, does any refactoring, and writes a failing test.  Then they pass the keyboard.

It continues like that, with each person doing “Fix it.  Refactor. Break it.  Pass Keyboard”.

We’ve been working in very small groups of about 3-5.  In that size, everyone sees what’s going on and gets a chance to drive.  We don’t have a projector, which isn’t too bad since the groups are small. (But if someone wants to lend us one, it could be useful.)

We allow discussions and suggestions and comments at any time (not just on a green bar), but the rule is “the person at the keyboard is supreme dictator”.  They can choose to ignore everyone else, or go with whatever suggestion they choose.

We’re still working out the bumps, but we seem to have a good system going.  If you’re in Austin and have a Monday evening free, come join us at Genuine Joe’s Coffeehouse from 8 – 10 pm.

What comes next after TDD katas?

What comes next after TDD katas?  UI Testing?  Mocks?  Design Patterns?

I’ve been doing TDD katas and dojos for a while now, and I think I’ve learned the first lesson.  I know the cadence of “break it, fix it, refactor”.  I understand Baby Steps and The Simplest Thing That Could Possible Work.  I get the importance of test choice in guiding the evolution of design.

So what’s my next lesson?  What’s the next thing the katas and dojos can teach me?  Maybe I need to figure out how to test UIs, and how to make testable UIs. The Humble Dialog Box may provide insight and direction there.  A coworker suggested that I need to learn mocks, maybe JMock or RhinoMocks.  I think there’s a kata in there somewhere.  I’ve tried the Publish/Subscribe example from JMock, but that feels too simple, a Hello World of JMock.  What’s a more complex kata that needs mocks to solve?  Or maybe I need to find a way to incorporate Design Patterns into my solutions.  So far I’ve evolved very simple designs, so they haven’t needed Design Patterns.

So what’s the next lesson to learn from code katas?  I know there’s a lesson in there somewhere, and I feel like I’m on the verge of learning it.  What is that lesson?

What Matters in a Dojo?

We in the Austin Code Dojo have been doing weekly dojos for four weeks now, in Genuine Joe Coffeehouse in North Austin, Texas. We’ve been learning a lot in these sessions.  Here are some of my notes.  These mostly talk about what matters in a dojo.  What are the important things we’re doing and why are we doing things this way?

Moon Phase Sprints

In Wicca there is a concept of the magical power of the moon. Each moon phase has different power, and different magickal workings should be done during each phase.  We can apply this to Agile sprints to make Moon Phase Sprints.  The sprints would be one moon cycle long (29 – 30 days).  The waxing half would be used for the generative, or creative, tasks, and the waning moon would be an opportunity for polishing, testing/fixing, and retrospective.  This gives an internal structure to each sprint, and lets the work follow a natural rhythm.

First Weekly Community Dojo on Monday

We’re going to hold a Dojo this Monday at Genuine Joe Coffeehouse in Austin.

A dojo is a coding practice session, an instance of deliberate practice.  We work through a simple coding problem TDD style.  After talking through the problem description, someone writes one failing test.  Then another person gets the keyboard, solves the test, refactors, and writes the next failing test.  Then they pass the keyboard and repeat.

Austin Code Dojo

Monday, June 21, 2010
8pm to 10pm

Genuine Joe Coffeehouse
2001 W. Anderson Lane
Austin, TX 78757

Cost: free, but please buy some drinks and/or food from the Coffeehouse

We don’t have a projector yet, so if someone can borrow one from their work, or if someone owns one, that’d be great.

Quick Code Kata Restrospective

I’ve been doing Coding Katas three to five days a week for the last several weeks. I mentioned this to a friend, and he asked to join me. We did the reversi Kara, and learned some good stuff.  We learned to start with empty test cases and progress slowly from there.  We discovered we had to trust ourselves to pick which test cases to write, rather than doing complete comprehensive tests.  Finally, we wrote down lessons learned, which let us contemplate the process later.

TDD FizzBuzz on the Android

I’m starting Android development, but I want to work in a Test Driven development (TDD) way. I’ve looked at the Notepad Tutorial, but each step is too big, and it’s not at all TDD. This blog post describes the first step I took.

Dojo in a Community Ed Class

I’m interested in having a regular Coding Dojo that I attend, and I think setting up a community ed “class” would be a great way to organize it.

Cyborg Chess Kata

This Kata creates a tool used for Cyborg Chess that displays the number of pieces attacking each square.

Background

Cyborg chess is a special kind of league where each “player” is actually a human-computer team. Gary Kasparov is a proponent of Cyborg chess, saying it will lead to higher quality play and “blunder free” games. Most Cyborg chess today is played by a human sitting in front of a chess engine. The human gets proposals from the engine and types in potential moves to be evaluated. But I think there’s more potential. The computer can present information to the human in interesting ways which help the human better visualize the position of the board.