Chapter 1: The Programmer's Perspective

When it comes to programming, I can only share my personal experience. I can't speak for others. Personally, I struggle with visual memory and imagination. If I were a mechanical engineer, I would likely fall short in design; as a surgeon, I would be uncertain about where and how to make incisions.

In my programming endeavors, I focus on the necessary actions to reach a specific goal, directly translating them into instructions and subroutine calls. The entire process feels quite abstract to me, lacking any visual representation.

Ideas related to larger systems often come to me unexpectedly—sometimes at 4:00 a.m. or while I'm commuting. Much of this happens subconsciously and intuitively.

Higher-level concepts, like "finite state machines," have been invaluable for certain tasks, though I needed to sketch them out and program based on those diagrams. Early in my career, I relied on flowcharts and Nassi-Shneiderman diagrams, all drafted with pen and paper.

As I gained more experience, I found that I could work from a simple textual outline of the program structure and directly code it in a higher-level programming language.

I consider myself fortunate to possess a natural aptitude for programming. While many can outline processes to achieve a target, I believe there are several key points to consider: It's crucial to not only find a solution but to ensure it is correct, straightforward, and easy to comprehend.

You also need to assess various options based on their practicality: which microcontroller to use? What programming language is best suited? Should a multi-tasking kernel be implemented? And if so, which one? Polling versus interrupts? Direct memory access?

Occasionally, you may stumble upon an ingenious idea that simplifies the task enormously. For instance, in Windows:

In test programs for assemblies, individual operations (each consisting of issuing a stimulus, waiting for a result, and evaluating that result) are often combined into multiple sequences. Each sequence is triggered with a button click. Programming this directly within Windows results in a cumbersome series of event-handling routines that are both tedious to implement and challenging to read.

The breakthrough idea is to create a class for each operation. An object of this class, called a "test atom," can be parameterized. When a sequence of operations is initiated by a button click, a series of appropriately parameterized test atoms are generated and stored in a FIFO (First In, First Out) memory. A framework is then activated that processes all FIFO content automatically.

The advantage here is that the framework and the classes for the test atoms require a one-time setup. Consequently, various test sequences can be programmed much more rapidly, and they're considerably easier to read and modify.

It's essential to grasp the overall software concept, although it often feels a bit nebulous to me. Only when I attempt to articulate it do specific elements become clearer.

This phenomenon is difficult to explain further. Not everything is immediately accessible to our conscious mind. I have encountered situations where I simply disliked a segment of code without understanding why, only to later uncover an error after days or even weeks.

As for the "brilliant idea" mentioned earlier? I struggled with the drudgery of programming (due to the Windows message pump) for quite some time. The concept of "test atoms" emerged only after about a year of grappling with the challenges.

Chapter 2: Simplifying Complex Programming Tasks

In Plain English ?

Thank you for engaging with the In Plain English community! Before you leave, remember to clap and follow the writer.

Follow us: X | LinkedIn | YouTube | Discord | Newsletter

Explore more on our other platforms: CoFeed | Differ

Discover additional content at PlainEnglish.io