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

AI Won’t Take Over Programming; It’ll Morph Programming

Despite ChatGPT raising the spectre of AI replacing programmers, an experiment I did implies a shift of the role of programmers rather than replacement. Programmers will not be irrelevant in the AI-powered future. They will just “program” in a very different way.

The Screen for the ChatGPT-generated todo app.

Society will always need people to translate raw ideas into something that makes sense to a computer. The form that communication takes may change over time, as it has in the past. Today, no one programs directly in machine code. Everyone works in a higher-level language. Even compilers themselves are now written in a higher-level language, usually C (Rust may take over that privilege, but that’s another blog post). 

In the same way, in the future, no programmers will write imperative code. At some point, languages like C, Rust, and Java won’t be used by humans. I used to think that we would develop declarative languages to program in, but now that I’ve been playing with ChatGPT, I wonder if programmers in the future will use natural language to describe what they want the computer to do.

This line of thought led to me doing an experiment to see what it was like to write a real program with ChatGPT. I started simple. I asked ChatGPT to write a To-Do App in React Redux. I typed the code in and asked follow-up questions to solve the errors I got. After a great deal of back and forth with ChatGPT, I finally got a complete, working project that implements a To-Do App in React Redux. You can look at the code at https://github.com/ziroby/todo-chatgpt in the v1-react-redux directory.

So what was it like working with ChatGPT to produce real code? It felt like I was talking to an errant child with more confidence than ability. ChatGPT always responded to my questions, but the code wasn’t a coherent whole. The first bit of code it gave me had an error in it that caused a blank page to display and an error in the console. I had to ask it to solve each error, and it didn’t always respond with the corrected original code. Instead, it would answer how to fix it in general, rather than for the specific code it generated.

Whenever a person originally learns programming, one of the things they learn is how to use the error messages received to learn how to program better. Deciphering error messages is very much a core skill for programmers. I feel like ChatGPT was lacking that ability.

I wonder what would happen if you gave ChatGPT access to a complete development environment and had it try to work out how to generate a complete project under different constraints. It seems like there’s a possibility of unsupervised learning. Or maybe it needs partially supervised learning, where a human gives it a task and it learns how to create a complete program to solve that task.

Back to the original question, will AI take over programming? My experiment showed that ChatGPT and similar programs will not take over programming. However, they will morph programming into something different. I see a future where “programmers” will talk to humans to find out what they want to be built, then talk to AIs to describe the program in terms the AI can understand. This will be a process, as the human asks the AI to refine each iteration of the program to add more to it. 

I allude to this today when people ask me to describe my job. I respond that my job is to write a task in terms that are so simple, even a computer can understand it. The future will just have the computer able to understand a task in more complex terms, but it will still need a human in the loop.

Thanks Prometheus

Prometheus is the name of an open source tool used for gathering metrics. I’m amazed at how appropriate the name is. 

Prometheus is the Greek god who gave fire to humankind. But there’s a lot more to that story. “Prometheus” literally means forethought, as in thinking about something and planning before you act. His brother is Epimethius, which literally means afterthought, as in doing things before you think about it and then thinking about it afterwards and going, “oops!”  Epimethius gave humankind Pandora and her box. Oops.

To the ancient Greeks, pretty much every abstract noun was a god. But they also retained their aspect as that abstract noun. That’s why when Discord wasn’t invited to a party, she sent an apple that she knew would start a fight, and when it did, there was discord, and so Discord really did attend the party.

So when we say that Prometheus gave fire to humankind, we’re also saying that the way you make a fire is through forethought. Forethought is crucial to making a fire. You need dry wood, kindling, a safe place for the fire, and the all illusive spark to start the fire, whether that spark is a flint and steel, two sticks, or a lighter that hasn’t run out of lighter fluid. To assemble these ingredients, you need to think about it before you act. You need to exercise forethought. 

That’s why it makes sense to call a metric gathering system Prometheus. To collect metrics on your system, you have to instrument the different parts. You have to instrument it before the failure that you want to analyse. 

Many applications, like your database or messaging system, have instrumentation built in. (Thank you, app developers, for your forethought). But you still have to wire it in and get it collected and sent to Prometheus. Your application code needs instrumentation added. You have to add something to expose system metrics, and for application specific metrics, you have to add the code to count and log what you’re interested in capturing. And then you need to make sure it gets to Prometheus.

Getting an application instrumented is an intricate process. And above all, it requires forethought. Thank you, Prometheus.

Declarative programming for business rules, imperative for the rest

I’ve been thinking and reading about declarative programming lately. I have a new theory: it would be possible to write all business specific programming declaratively, and make the imperative code completely business neutral. And I see it opening up all sorts of possibilities.

Ok, so now to explain what I just said.

Programming today is generally imperative. The programmer tells the computer, “do this. Then do this. Then do this.” A list of commands. In imperative programming, we tell the computer how to find the answer.

In declarative programming, on the other hand, the programmer tells the computer what the answer is. That is, we declare what we’re looking for. The computer can find the answer any valid way it wishes. Like in a spreadsheet, we declare the formula for every cell, but the computer can evaluate it in any order.

The problem is that computers can’t run declarative programs. Some programmer has to write some imperative code to interpret the declarative code. They must tell the computer how to achieve the what. In the spreadsheet example, these are the programmers who wrote the spreadsheet.

In practice, a programmer creates a special purpose language and the software to interpret and run that language imperatively. Sometimes this is called a Domain Specific Language, or DSL. Examples of declarative languages are SQL or regular expressions.

So why do I think we could write all business logic declaratively?

The names of the business objects, the language of the domain, changes in every program, or at least in every company or industry. But the fundamental concepts are all the same. Most business programming is about moving around and mutating data. A lot of the rest can be modeled as a workflow engine or even just a finite state machine.

And why do I think this would be a good thing?

It’s mainly about a separation of concerns. The two concepts are fundamentally different. We try to treat business rules and implementation specifics as the same thing, and it muddies the water.

And they need different things. Business rules need to be verified that what they’re modeling is what was intended to be modeled. Imperative code needs to be tested for correctly handling all cases, and for non functional requirements, like performance.

It’s also a code sharing thing. What if we shared all the imperative code? Most free software is business neutral. And with there being no business specific logic, we’re not divulging the secrets of how the company is run.

Declarative code would generally not be shared. That defines how the business does its business. Businesses tend to not want to let that information out, and someone not in their industry probably couldn’t do much with it anyway.

Once we have an ecosystem with some shared declarative languages and multiple interpreters, we can finally have some sort of interoperability. “How would this app work with a different database?” Let’s swap it out and see how it works. “Someone just made a better communication method.” Great, let’s deploy it into our entire software. As long as the new code uses the same declarative language, it can be swapped in.

What do you think? Would the declarative / imperative split solve your problems? Do you think this would (or would not) be a good idea? Tell me in the comments.

Programming on your phone

I have figured out how to program on an Android phone or tablet. Using Google Cloud Platform and a couple of Android apps, I have a cloud development box, and I can pull up a command line and edit files locally in my Android device.

I’m going to describe the method I use. You can, of course, use different apps that do the same thing. This is just my method of implementation.

Setup up Google cloud platform. See https://cloud.google.com/compute/docs/quickstart

Create an instance named dev-instance. I use a small preemptable insurance to save on money. You can use a larger instance (but not a smaller one). You can choose to make it preemptable or not. Preemptable is nice because if you accidently leave it running, it won’t stay up more than 24 hours.

Install the Android Google Cloud Console app. Also install JuiceSSH and the paid version of DroidEdit.

In JuiceSSH, go to Connections, slide to Identities, and click the plus to create a new identity. In the Nickname fields, enter ‘dev-instance identity’. Under username, type your Google user ID. Press Set next to Private Key. Go to Generate. Change Key Format to RSA. Hit OK to generate the key (this may take a while). Then press the checkmark in the upper right hand corner to save the identity.

When the identity is created, long press it and select Export Public Key. Select Copy to Clipboard.

Go into Google Cloud Console. Go to Resources then to VM Instances. You should see your instance, dev-instance. Click it and select Ssh from the the dots menu in the upper right hand corner. Select Connect via SSH. This will open a console window to your instance. Type

 cat >> ~/.ssh/authorized_keys

Be sure there are TWO greater than symbols. Then long press the screen and select Paste. This should paste your private key from JuiceSSH into the window. Press the console window to turn on the extra keyboard. Press Ctrl then ‘d’. Type ‘logout’. We’ll be connecting to the console from JuiceSSH from now on. Press OK to close your session.

You should be on the screen for dev-instance. Scroll to the bottom and expand Compute Engine Details. Long press the entry for External IP and select Copy. Also, write this address down, because we’ll need it later.

Go to JuiceSSH. Slide to Connections and press the plus sign to add a new connection. Under Nickname, type ‘dev instance’. Long press the space for Address and press Paste. This should paste the external IP. Make sure Identity shows ‘dev instance identity’. Hit the check mark in the upper right hand corner to create the connection.

Press the connection to test it. When it asks you to trust the connection, hit OK. You should get a command prompt. Type ‘logout”.

Swipe back to Identities. Long press ‘dev instance identity’. Select Export Private Key, then Copy to Clipboard.

Open DroidEdit (this must be the paid version). Press the drive looking icon to get a file menu. Press New. Long press the empty document and select Paste to paste the private key. Now select Save As from the file menu. Press local, then navigate to /storage/emulated/0. Press the folder plus icon and create a folder named ‘.ssh’ (make sure the folder name starts with a dot). Name the file ‘id_rsa’ and press create.

Go to Settings, then Remote Files. Scroll to the bottom and press Global Private Key Path. Enter ‘/storage/emulated/0/.ssh/id_rsa’. Hit OK. Press Add Remote Server. Server Name should be ‘dev instance’. For Server Address, enter the IP address you wrote down earlier (or go look it up again). For username, enter your Google ID. Check Use Global Private Key. Press Test to check it. If it asks for a passphrase then you’ve done something wrong. Press Save and exit the settings.

And you’re done! You can now program on your phone or tablet. To open files, use DroidEdit. To get a command line, use JuiceSSH. You have to set up the box with your development environment, but once you do, you can program wherever you are, if you just have a phone or tablet and an internet connection.

Austin Code Dojo

Anouncing
The All-New, Re-Imagined
Austin Code Dojo

This Dojo is a place for various forms of programming practice, just as a martial arts dojo is a place for various forms of martial arts practices.  We will have a beginners kata for new coders, students, and managers who used to code; and a more advanced kata, if there’s interest.  We also welcome all other forms of cooperative programming practice.  Solve a programming challenge, hack on an open source project, share some code you’re working on, or just talk about programming stuff in a friendly, unstructured atmosphere.  The point is group practice of all sorts.

Pablo’s Fiesta 2011 Notes

I went to Pablo’s Fiesta this past weekend.  It was an amazing conference with lots of energy and lots of things to learn.  Here aare some of my notes.  I maay go back and clean them up, or expand something, or just leave them s is.  For now, tho, here they are in raw form:

How do you tell a master craftsman?

I asked my 12-year old son today what it means to be a craftsman and a master craftsman (of any profession). Then we went on to discuss how you can tell that someone is a master craftsman. I find his answer illuminating:

1. They should be able to talk their craft and, if you’re not a master yourself, they will lose you and go over your head and talk about things you don’t understand. This was from a child’s view, but I interpret it as “They must be able to talk up their craft”.
2. They should be able to create a sample on demand. He was thinking about small crafts when he mentioned it, but when we talked about bigger things (like skyscrapers), we decided a small test problem would suffice.
3. (and this I think is the most important one) They should show you their previous work. They should be able to say, “Look, I created these high quality things in the past, so I can create high quality things for you in the future.”

The book Software Craftsmanship book mentions that to be a master, you must have a masterpiece. To claim that you’re a master, you must be able to show some really good work. So in our discussion of how do you tell a master craftsman, the answer is simple: look at their work.

When you hire an artist (painter, photographer, sculptor, etc.), you look at their portfolio. All artists have one, and it’s how they get work. So, if we’re craftsman, we should have portfolios. Résumés are similar to portfolios, but a) they don’t emphasize actual completed works enough, and b) they’re dry and boring. So maybe we need to start making multimedia portfolios to highlight our abilities as a craftsman. I picture web sites with screen shots, customer testimonials, sample code, links to your blog and other sites, and links to free software or other non-work projects you’ve created.

The key here is, if you want to convince someone that you’re a master craftsman, show them your work and your masterpieces.

Ron “Ziroby” Romero
http://www.ziroby.com (which has some portfolio elements, but needs to talk about my actual for-pay work)

[cross-posted to the Software Craftmanship list at http://groups.google.com/group/software_craftsmanship/browse_thread/thread/a9a03d96ff298a26 ]

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?