Forem: Adam Schmideg

The Grasshopper's Rebellion

Adam Schmideg — Sun, 26 May 2024 11:09:57 +0000

The grasshopper and the ants

It was time for the weekly team meeting. Michael handed out printed copies of his presentation slides. There were many pages. Samantha felt how thick the stack was - 27 pages. She sighed quietly to herself.

Michael began speaking about his presentation. Samantha nodded, pretending to listen carefully. But soon, her pen started moving by itself to draw on her notepad. Lines and shapes appeared.

Samantha drew a bright green grasshopper playing a tiny violin. Around the grasshopper, she drew twelve ants marching in a line. The ants wore business suits and carried briefcases. It looked silly and funny. Samantha fit her drawings inside the boxes on a printed Excel spreadsheet page.

Samantha's coworkers saw her doodling from the corners of their eyes. They smiled a little. Everyone knew Samantha's habit of doodling during meetings. They thought it was amusing, as long as Michael didn't notice.

"Any other questions before we continue?" Michael's voice droned on.

Suddenly, Michael's phone rang and made a buzzing sound. "Excuse me, I need to take this call." He left the meeting room. The coworkers looked at each other.

Samantha kept doodling. She added a family of turtles to her scene. She did not see Michael come back into the room.

"Sorry about that interruption, it was -" Michael stopped speaking. He looked at Samantha's notepad. Her colorful doodles were out in the open for anyone to see.

No one said anything for an awkward, uncomfortable moment. Michael stared at the grasshopper playing violin and the ants dressed in suits. Samantha's coworkers waited silently to see how Michael would react.

But Michael just cleared his throat. "Well then, where were we..." He acted like nothing unusual happened.

The meeting continued. But Michael had clearly seen Samantha's doodles. Samantha did not know if he was okay with it or not.

Breaking the silence

The meeting was finally over. People started gathering their things and leaving the room. Samantha collected her notepad and pen. She hadn't touched her pen since Michael caught her doodling.

Samantha was about to leave too, but Michael made a small gesture with his hand, asking her to stay behind. Some of her teammates noticed and glanced at her curiously as they filed out.

Soon, it was just Samantha and Michael alone in the room. An awkward silence hung in the air.

"So...why were you drawing during the presentation?" Michael asked, breaking the tension.

Samantha didn't respond at first, unsure of how to explain herself.

"Do you not find value in these status meetings?" Michael pressed. "The presentation covers important priorities and plans."

"No, I understand the value," Samantha replied carefully. But her eyes shifted slightly, hinting there was more she wasn't saying.

Michael could sense she wasn't being fully transparent. He pressed on, "Was there something about my presentation specifically that made you...distracted?"

Samantha weighed how much to reveal. A certain phrase Michael used seemed to unlock her honesty. "I...can't always pay attention," she admitted.

"Because it's boring?" Michael stated bluntly.

Samantha knew she was caught. After the doodling incident, she figured it couldn't get any worse. "Yes," she confessed. "The presentations can be...quite boring."

Samantha couldn't hold back any longer. The words came tumbling out. "Don't you find it ironic? You're always asking us for innovative, creative solutions. But then you plan it all out in spreadsheets using the same old, stale techniques that get called 'innovation best practices.'"

She gestured to her doodled notepad. "This...this is how I tap into my real creativity. My doodles help me think differently, make unexpected connections. But I have to do it in secret, like it's something to be ashamed of."

Michael furrowed his brow, considering her outburst. After a moment, he nodded slowly. "Okay, let's explore your approach then. If everyone just pursued what they found personally interesting, how would we ensure we actually deliver on what matters to our customers and stakeholders?"

Samantha opened her mouth to respond, but Michael kept going. "If you want to draw little creatures, that's fine. But that's what hobbies are for - creative outlets separate from work."

He leaned back in his chair. "I rebuild vintage motorcycles in my free time, for instance. It's my passion. But I don't mix that hobby with my professional responsibilities here. There's a line between interests and important work."

Samantha felt her cheeks flush with a mix of embarrassment and defiance. Michael's dismissive attitude toward her doodling ignited something within her. This wasn't just a hobby to be compartmentalized.

"My doodles ARE my work," she stated firmly. "They're how my mind explores problems and imagines new possibilities. Treating it as a separate 'hobby' is what stifles true innovation."

The CEO of the brain

Michael could sense Samantha's defiance over treating her doodles as mere hobbies. He decided to take a different tack, tapping his knuckle on the polished conference table.

"You know, this table is made of solid oak. Took years of patient growth for that oak tree to develop its hard, sturdy interior." He ran his hand along the smooth wood.

Michael then pointed to his own forehead. "What do you think is behind this?" He raised an inquisitive eyebrow at Samantha.

Before she could respond, he continued, "The frontal cortex - the mastermind behind our most advanced brain functions. It's the control center that allows us to plan, reason, and make conscious choices rather than just going with our first impulsive urges."

He swiveled his chair to better engage Samantha. "Imagine it as the CEO of your brain - integrating information from all other regions to decide the best course of action. Without it, you'd just drift aimlessly based on whatever thought or stimuli captured your attention at the moment. The frontal cortex is what lets you concentrate on work instead of browsing YouTube."

Michael swiveled his chair toward the glass windows overlooking a playground outside. A group of children shrieked with laughter, chasing each other across the jungle gym.

"To a child, every moment is about following their interests. Playing, running around, doing whatever feels fun and stimulating in that instant." Michael mimed drawing in the air with an imaginary crayon.

"They live totally in the present, their frontal cortexes all soft and malleable. That's why kids love to doodle and draw - it's an impulsive creative outlet with no deeper purpose."

He turned to Samantha. "When was the last time you visited the dentist?"

Samantha was caught off-guard. "Uh...six months ago, I think?"

Michael nodded. "Exactly. We become adults. Our frontal cortexes mature, and we have to make hard decisions against our childish impulses."

"A child would never willingly go to the dentist, because it's not fun. But we adults understand the important responsibilities - like basic hygiene and preventative care. We delay the gratification of eating sweets, because we know the consequences if we don't."

Samantha couldn't help but smirk at the dentist analogy, though Michael's metaphor rang true.

"That's the crux of this dilemma. Your doodles may feel like creative indulgences. But I need my team to embrace the bigger picture - our professional obligations to this company and its customers. Even if that means... delaying gratification."

Balancing acts

"But there are whole communities out there not based on these 'important' responsibilities you speak of," Samantha countered. "People who choose to live for their interests and passions, without being forced into pursuits they find dull or constricting."

She leaned forward, a hint of wistfulness in her voice. "Don't you think the world would be a happier place if we gave the 'interesting' things a bigger share of our lives? Instead of always having to delay gratification for what society deems important?"

Michael considered her point, nodding slowly. "You're not entirely wrong. With primitive hunter-gatherer tribes, that divide between interesting and important pursuits wasn't so starkly defined."

"But their lives were a constant struggle for survival," he added pragmatically. "The agricultural revolution, when humans transitioned to settled societies, was in many ways the maturation of our species."

Michael tented his fingers, gathering his thoughts. "It allowed us to delay gratification, plan long-term, and ultimately build civilization's greatest achievements. As glorious as a nomadic existence following your every whim may sound, it lacks the stability and focus to reach our full potential."

He fixed Samantha with a measured look. "The frontal cortex's ability to override impulsive urges in favor of responsibilities - as tedious as they can feel at times - is what separates us from plucky grasshoppers endlessly playing their violins while the industrious ants do the hard work of preparing for the future."

Samantha: But there are exceptions in our current society to this rigid separation of interests from responsibilities. What about people with ADHD or other neurological conditions? For them, it can be extremely difficult, maybe even impossible, to always prioritize what's deemed important over their personal interests and creative pursuits.

Michael: That's a fair point. I can see how brain chemistry differences would make delaying gratification and overriding impulsive urges towards interests more challenging.

Samantha: Exactly. And what about artists, journalists, entertainers? Their work is literally following and expressing their creative interests and passions. Yet they're often considered less serious or trustworthy for that.

Michael: Well, I would argue that for truly successful creatives at the highest levels, their interests have effectively become important professional and financial responsibilities.

Samantha: Sure, but that's only after they've "made it" and their interests become work obligations. Before that, while they're still struggling, society tends to dismiss their passions as frivolous indulgences distracting from more important practical concerns.

Michael: I can't deny there's a double standard there. We celebrate creative success after the fact, but are quick to criticize those same pursuits as impractical whimsies beforehand.

Samantha: It's an unfair, privileged way of looking at it. The financially stable can more easily embrace their interests over responsibilities without facing the same potential consequences as others.

Michael was silent for a moment, taking in Samantha's perspective. He nodded slowly, his expression softening. "You're right, I haven't fully considered the nuances." Michael leaned forward. "If we're going to truly question this dichotomy between responsibilities and creative interests, what would your suggestion be? How could we create more space for 'interesting' work and innovative pursuits, while still meeting our professional obligations?"

He spread his hands in a gesture of openness. "I may have been too dismissive earlier. But I'm listening now - what's your vision for finding a better balance?"

Drawing attention

Samantha sat at her desk, watching at the meeting agenda. She had drawn a small grasshopper surrounded by dozens of ants in business suits, each holding a tiny briefcase. The office was noisy with the sound of keyboards, ringing phones, and people talking.

Michael’s door opened with a quiet creak. He stepped out, his eyes scanning the room until they landed on Samantha. He gave a brief nod, then went back into his office. Samantha felt a rush of nervous energy. She gathered her sketches and sketchbook, slipping them into a folder.

As she walked towards Michael’s office, the sounds of the office faded. Her footsteps seemed louder in her ears. She passed her colleagues, who were busy at their desks, not noticing her. The air felt heavier, filled with anticipation.

She stopped at Michael’s door, took a deep breath, and knocked lightly before pushing it open. Inside, the office was plain and practical, the fluorescent lights casting a harsh glare. Michael sat behind his desk, a fortress of paper and files, his expression serious.

Samantha stepped inside, the door clicking shut behind her. The room felt smaller, the walls closer. She approached the desk and placed her folder on it. Michael watched her with a calm, unreadable gaze, his hands folded neatly in front of him.

She opened the folder and spread out her sketches. The grasshopper, surrounded by ants in business suits, was a tiny act of rebellion against the boring meetings. Samantha straightened, meeting Michael’s eyes. The room was silent except for the distant hum of the office outside.

Michael picked up one of the sketches, examining it closely. His face remained impassive, but there was a flicker of something in his eyes—curiosity, perhaps, or a slight hint of amusement. Samantha stood still, her heart pounding, waiting for his reaction.

Michael set the sketch down and looked at her. For a moment, the distance between manager and employee, the line between duty and creativity, seemed to blur. Samantha felt the weight of the moment, the fragile possibility of change hanging in the air.

He leaned back in his chair, tapping a finger on the desk. Samantha held her breath, ready for whatever came next. Samantha snapped her fingers. Somewhere, a projector clicked on, and the image of the grasshopper and the ants appeared on the wall behind Michael, magnified ten times. One of the ants' briefcases landed right over Michael's face, who turned in his swivel chair and watched the presentation on the wall.

Beyond boredom: a presentation

1. Introduction

Purpose: Integrate interestingness of tasks into the Agile process to enhance engagement and motivation.
Key Roles:
- Product Manager: Defines the importance and business value of tasks.
- Interestingness Owner: Explains why tasks are interesting and ensures tasks are engaging.
- Team Members: Vote on the interestingness of tasks.

2. Roles and Responsibilities

Product Manager (PM):
- Prioritize tasks based on business needs and deadlines.
- Communicate the importance and customer/business value of each task.
Interestingness Owner (IO):
- Assess tasks for their interestingness and potential for creative problem-solving.
- Present tasks in a way that highlights their interesting aspects.
- Modify tasks to increase their interestingness if they are initially deemed dull.
Team Members:
- Vote on the interestingness of tasks during planning sessions.
- Provide feedback on what aspects make a task interesting or dull.

3. Task Evaluation Process

Task Identification:
- Tasks are initially identified and listed by the Product Manager.
- Each task includes a description, priority, estimated effort, and deadline.
Interestingness Assessment:
- The Interestingness Owner reviews each task to identify and highlight interesting aspects.
- Tasks are presented to the team with both business value (by PM) and interestingness (by IO).

4. Voting on Interestingness

Voting Mechanism:
- During sprint planning or task review sessions, team members vote on the interestingness of each task.
- Voting scale: Interesting (Yes) or Dull (No).
Marking Tasks:
- A task is marked as interesting if at least one team member votes 'Yes'.
- Tasks with unanimous 'No' votes are flagged for further review.

5. Managing Dull Tasks

Review by Interestingness Owner:
- Tasks marked as dull by all team members are reviewed by the Interestingness Owner.
- The IO attempts to identify ways to make these tasks more engaging.
Modification or Removal:
- If the IO can enhance the interestingness, the task is modified and re-presented to the team.
- If the task remains dull but is still important, it may be revisited in subsequent sessions.
- Tasks that cannot be made interesting and are not crucial may be removed from the list.

Maybe

When Samantha finished her presentation, the room became very quiet. The light from the projector made strange shapes on the walls, and everyone looked serious. Michael was at the front, looking like he was thinking very hard.

Samantha felt both excited and scared. She really wanted Michael to like her idea, but she wasn't sure if he did. She looked around the room, and all her colleagues were there, even though she had started talking just to Michael. It made her feel nervous, like all eyes were on her.

After Samantha concluded her presentation, the room fell silent. The projector's light danced across the walls, adding to the tension in the air. Michael sat at the head of the table with an unreadable expression.

Samantha's heart was beating fast as she waited for Michael's response. She had put a lot of effort into this proposal, hoping to change their approach to work. But now, she was uncertain if her ideas would be accepted or rejected.

Michael leaned forward and looked at the gathered team. "Thank you, Samantha, for sharing your ideas," he began, speaking in a calm tone. "Your perspective is certainly thought-provoking."

Everyone in the room waited with anticipation for Michael's decision. Samantha held her breath, hoping for a positive outcome.

"But," Michael continued cautiously, "as with any new idea, there are risks and uncertainties to consider."

Samantha felt a little disappointed, but she did not want to give up on her vision. She knew from the start that change would not be easy, but she was ready to fight for her ideas.

"As a team," Michael went on, "we need to carefully weigh the potential benefits against the potential drawbacks of integrating new ideas into our work process."

Samantha nodded slowly, thinking about questions and doubts. Had she failed to explain her case clearly enough? Were her ideas too different from their current practices?

But despite the uncertainty, Samantha felt determined. She may not have convinced them today, but she refused to give up on her vision. She would continue to promote creativity and innovation, even if others doubted or were skeptical.

As the meeting ended and her colleagues left, Samantha stayed for a moment and exchanged a meaningful look with Michael. In that brief moment, she saw a hint of curiosity in his eyes, a silent acknowledgment that her ideas might have some value.

As Samantha gathered her notes and sketches, she couldn't shake the feeling that this was only the beginning of something truly remarkable.

Love at First Compile

Adam Schmideg — Mon, 08 Jan 2024 15:51:44 +0000

Not only with women have I fallen in love,
but with programming languages too.
Embarrassing to look back now
and admit I was in love with Java.
It started with a flirt in the office.

We were a Microsoft shop,
dedicated to everything Windows and Visual Basic,
everything click and drag-and-drop.
Maybe this is why I got excited
when I heard a lecture about Java at the university.
White code written in chalk on the blackboard.
Almost like typing in a terminal.
Background color should not play a role
when choosing between programming languages.
The logos of the companies behind them should be irrelevant.
But Sun, the creator of Java, designed a magical logo
that read Sun from all four directions.
A sexy logo in the finest shade of purple.
Besides personality, we fall in love
with brown eyes, with blue eyes.

It was half past five, the office
was empty, except for me and my friend.
I entered sun.com/java in the browser,
an easy to remember URL.
The link to the installer sat on the top of the page,
no need to scroll down, just click and wait.
Modern technology always takes long to download.
The proverbial fifteen minutes of
"make a coffee, smoke a cigarette, and it will be ready."
Downloading was not enough, you had to install it.
Answer questions that should not be asked.
I did not know yet how many times
I would answer these same questions
and accept the default in every case.

We used an integrated environment to write BASIC code,
the keywords were displayed
in bold and in a darker shade of carmine.
Here is how you count to ten without using your fingers:
FOR I = 1 TO 10
And imagine the colors.
You click on the yellow arrow icon to run the program.
We had no editor for Java.
It probably didn't even exist yet, the language was so new.
We used what we had.
Our BASIC editor automatically checked our Java code
and highlighted all the errors.
Imagine writing in German
and running it through an English spell checker.
I knew the code was correct,
I just copied it from the notes I had taken at the class.

Clicking the yellow arrow wouldn't make sense either.
I had to leave our integrated environment behind
and open a terminal.
Type javac Counter.java.
The whole world was black and white now,
the whole screen.
The command I typed and the error message
I received a few seconds later.
A semicolon is missing on line 8.
Go back to the editor and fix it.

It took us more than half an hour to make our first Java program work
and do some very basic stuff.
Count to ten and print the numbers.
This doesn't sound like the beginning of a love story.
But what is love if not sweat and tears?
I may tell you later about the tears.

Espresso Yourself: Explain Object-Oriented Programming to Your Barista

Adam Schmideg — Thu, 14 Dec 2023 19:13:56 +0000

"How many times do you have to draw a heart with milk foam before you get it right?" I ask.

The barista at my local cafe gazes upwards, pondering. "Took me about thirty, maybe fifty tries," she finally says. "The thing you really need to focus on is..." She then dives into a brief yet insightful explanation about this particular skill in the art of coffee making.

Sharing your enthusiasm with others can double the joy. But when you can't, it often leads to a sense of loneliness.

Alright, now it's my turn to share something. It's time for me to explain object-oriented programming to her.

Not all dates are the same

Big ideas like Darwin's evolution and Einstein's relativity theory often remind us of what we feel we should know. But honestly, I haven't delved into these topics deeply. Books on such subjects gathered dust on my shelf, unopened.

Then came Object-Oriented Programming (OOP). Intrigued, I bought a book about it, only to be baffled by jargon like classes, objects, and inheritance. The more I read, the less I understood, feeling lost in a loop of concepts. Frustrated, I shelved the book next to an unread tome on quantum theory.

It was a standard application – the kind with windows, text fields, dropdown menus. There was an OK button that set things in motion and a Cancel button that, predictably, did not. To a user, it was as ordinary as any software they'd encounter in their daily digital life. But for me, this was new ground, my first functional software from the initial line of code to the last.

The palette in the editor was like a toolbox filled with all the gadgets I needed. If I ever needed something new, I could theoretically create it, but figuring out how to add a new component to that palette was a skill way beyond my level – that was advanced stuff, meant for the pros.

Then, a colleague pointed out something: the system I was working with was built on object-oriented programming principles. The text fields, the buttons, the windows – they were all "objects."

I revisited the OOP book, and while some parts still baffled me, others began to click. Yet, it mostly echoed what I had already figured out using the program's components.

As I worked on the application, I initially convinced myself that the pre-installed components were sufficient. But deep down, I knew this wasn't entirely true, and I had to face that reality. A key feature of the application allowed users to select a date range – something you'd typically do when booking a hotel room or a flight, choosing both a start and an end date. The challenge was, there wasn't a single component designed for this specific task.

What I had at my disposal was a basic date selector. To create a makeshift solution, I placed two of these side by side – one labeled as the 'start date' and the other as the 'end date'. It was a quick fix, but far from ideal. It was clunky and not user-friendly.

This approach was also a headache for development. Every time I needed a date range selector elsewhere in the application, I found myself copying and pasting this pair of date selectors. This process involved not just the components themselves but also tweaking the associated code to fit the new context. It was tedious and error-prone. More than once, I caught myself in a situation where, if I missed updating a reference in the code, it led to confusing outcomes. Imagine booking a flight and then a hotel room, and then when you decide to change the end date for your hotel stay, you accidentally end up modifying your flight schedule instead. It was clear that this makeshift solution was not just inelegant; it was fundamentally flawed.

Meeting Nemo

In the deepest point of my journey, the kind where you might expect to meet a wise man, I met Nemo. But he was far from the archetypal sage in appearance. He was no captain from a Jules Verne novel, nor a fish, nor did he fit the typical image of a hero. Nemo was a bulky man in his mid-thirties, with a bald spot that he seemed to casually, almost unintentionally, try to cover with strands of his uncombed hair. At first glance, he didn't strike you as the kind of person who'd make a profound impact, but as I would soon learn, appearances can be deceiving, especially in the world of programming.

From self-appointed gurus like Steve Jobs, you often hear that the key to success is focus. The mantra is simple: concentrate on one thing and one thing only. Everything else, no matter how tempting or appealing, should be disregarded if it doesn't align with that singular focus. This philosophy advocates for a laser-like concentration, cutting away distractions and peripheral interests to hone in on what truly matters.

Nemo was different, maybe even the opposite of what you'd expect from the Steve Jobs type. Back then, Jobs wasn't the big name he is now, and I doubt Nemo paid much attention to his ideas about focusing on just one thing. Nemo was all over the place, in a good way. One week, he'd be all about script languages, telling everyone how great they were. Then, a month later, you'd find him talking up the serious, type-safe languages. He was always trying something new at work. He'd put together a rough prototype of an idea, get everyone excited about it, and then, just like that, he'd be onto something else. He was like a kid in a candy store, always looking for the next sweet thing to try.

The first time I met Nemo, he was really into object-oriented programming. It was unusual for him to stick with one thing for so long, but he was really excited about it. He was so into it that he put together a whole day workshop, just to talk about it and show everyone what he could do with it.

Making coffee the object-oriented way

Nemo kicked off the workshop with something unexpected. He pointed to the coffee maker in the room, a pretty ordinary-looking machine that you wouldn't give a second glance normally. But there was something about the way he looked at it, full of excitement, that made us all take notice. It wasn't anything fancy – just your regular coffee maker, a bit worn from use. Yet, I still remember exactly how it looked, because that day, Nemo turned it into our first lesson in Object-Oriented Programming (OOP), showing us how even the most everyday things can open up a world of complex ideas.

The Generic Idea of a Coffee Maker (Class): In OOP, we start with a 'class', which is like a blueprint. (Think of it as the Platonic idea of a coffee maker if you are philosophically inclined.) This class defines what a coffee maker is and what it can do. It doesn't represent a specific coffee maker in your kitchen but the general concept of what any coffee maker should be like.

Capabilities of the Coffee Maker (Methods): In our coffee maker class, we define 'methods', which are the actions that any coffee maker can perform. For example, we might have methods like addWater(), addCoffee(), or other actions like turnOn() and turnOff(). These methods are like instructions that tell the coffee maker what to do.

The most important method might be makeCoffee(). When this method is called on a coffee maker object, it uses the water and coffee added to brew a cup of coffee. It’s like giving a command to the coffee maker to perform its main function.

Continuing with Nemo's explanation, he delved deeper into the workings of the coffee maker as an example of Object-Oriented Programming. "If we peek inside the makeCoffee() method," he explained, "you'll find that it's calling other methods like brew(), getWater(), and getCoffee(). These are the coffee maker's internal processes, its own business."

He emphasized that in OOP, this is a key concept. Some capabilities of an object, like our coffee maker, are exposed to the user – these are the methods you can interact with directly, like addWater() or makeCoffee(). These are akin to the buttons and levers on the actual machine. However, there are other methods, like brew(), which are part of the coffee maker's internal mechanics. They're crucial to how the coffee maker works, but as a user, or in programming terms, as someone using the coffee maker object, you don't need to worry about these internal methods.

"This distinction," Nemo continued, "is about what the user (or other parts of the program) needs to see and interact with, versus what the object manages internally. It's like knowing you can press a button to start the coffee maker, but not needing to know exactly how the heating element works or how the water is pumped through the grounds. In OOP, we encapsulate these details, exposing only what's necessary and keeping the rest tucked away as part of the object's internal implementation."

Nemo then posed an intriguing question to the group, "But what happens when you press the 'make coffee' button? How much coffee does it produce? And what will it taste like?" He smiled as he saw the puzzled looks around the room. "You see, these questions can't be answered by the coffee maker itself. From its perspective, those details are somebody else's problem."

Somebody else's problem

He explained further, "When you call the makeCoffee() method on our coffee maker object, it doesn't just start a process; it actually returns another object – a coffee object. Yes, in the world of OOP, the coffee it makes is an object as well."

Nemo continued, "This coffee object has its own methods. For example, there's a getServings() method, which returns the number of servings the coffee maker has produced. And there's another method, getTaste(), which might give you an idea about the flavor of the coffee. These methods belong to the coffee object, not the coffee maker. It’s a way of organizing our program so that each object has its own responsibilities. The coffee maker makes the coffee, but the coffee object itself can tell you more about its quantity and quality."

Nemo shared a personal anecdote to further illustrate his point. "I have a coffee maker at home," he said. "It's similar to this one, but there are some key differences." He described his own machine, an expensive Italian model, explaining that unlike the one in the workshop room which used ground coffee, his at home took whole roasted beans and ground them itself. However, he pointed out, the process of adding water was identical in both machines – each had a container that needed to be filled with water.

"This brings us to a crucial decision in programming," Nemo continued, addressing the room but somehow, it felt like he was speaking directly to me. "When coding for these coffee makers, you have two options. The first is to copy the addWater() code from one coffee maker to the other. But as some of you might know," he glanced in my direction, "this approach can be tedious and prone to errors." I nodded, thinking back to my struggles with the date selection feature.

"But," he went on, "programmers have a principle they like to follow – it's called DRY, or 'Don't Repeat Yourself'. The idea is to avoid repetition wherever possible." He then introduced a concept that was new to me but made immediate sense – class inheritance. "You can have a general CoffeeMaker class that includes the addWater() method. Then, you can create subclasses like SimpleCoffeeMaker and FancyItalianCoffeeMaker. Both of these will inherit the addWater() method from the general class, and it will work the same way in both."

Nemo then explained a subtlety about the makeCoffee() method. "In the general CoffeeMaker class, makeCoffee() is just a placeholder. It doesn't actually do anything by itself. The specifics of how coffee is made differ between machines, so it's up to the subclasses to define their own makeCoffee() method." It's somebody else's problem again.

The date range selector

Nemo's explanation opened my eyes to a new way of seeing not just programming, but the world around me. He showed us that virtually anything could be modeled in terms of objects and methods within the framework of Object-Oriented Programming. It was like discovering a new language to describe and interact with the environment around us.

"There are hierarchies of classes," Nemo continued, his enthusiasm infectious. "In these hierarchies, classes inherit methods from their parent classes. This is the beauty of OOP – it mirrors the natural world. Just like in families where children inherit traits from their parents, in programming, subclasses inherit methods from parent classes."

"And remember," Nemo emphasized, "all these methods we talk about, they operate on objects. An object is an instance of a class, and it's the cornerstone of OOP. It's a self-contained entity with its own attributes and behaviors."

As Nemo elaborated on these concepts, I began to see the power of this approach. By breaking down complex systems into smaller, manageable objects, and by establishing a clear hierarchy where methods and properties could be inherited, we could model the whole world.

After that workshop, I went home with my head full of new ideas. I had always thought that adding a new component to the Delphi palette was some kind of high-level magic, something way beyond my skills. But that night, I sat down and went through the entire Delphi documentation about adding components. I read and read, and as I did, everything started to fall into place. By the time it was midnight, what had seemed like magic before now made perfect sense. I was so pumped up with excitement that I could hardly sleep.

The next morning, I got up way earlier than usual, around 7 am, buzzing with energy. I got straight to my computer and began working on creating my own date range picker component. Within just a few hours, I had it figured out and added it to the Delphi palette. It felt amazing. This task that I had once thought was too complex for me was now done, clean and efficient. No more moving code around from one place to another.

Escape Key: Remote Work Without a Laptop

Adam Schmideg — Sun, 03 Dec 2023 11:58:57 +0000

'H' 'e' 'l' 'l' 'o'

Back in the day, sending a simple "Hello" on my old cell phone was like playing an advanced version of Morse code. Each letter was a mini adventure on the numeric keypad. I'd start the journey by tapping '4' twice – a light tap-tap, pause, envisioning the 'H' popping up on the tiny screen. Next, '3' needed its share of attention, a double tap for the 'e'. Ah, but then came the 'l's, the true test of patience. Tap '5', wait, tap again, wait, and tap one more time – that's one 'l' down. Repeat the whole dance again for the second 'l'. By the time I got to '6' for the 'o', tapping it thrice felt like a little victory.

Most phones didn't have a feature for taking notes. But considering how tedious it was to type even a simple message, it's understandable no one was missing it. We stuck to what was manageable – quick texts and the occasional 'LOL' – and left the note-taking to the good old pen and paper.

So, when I packed my bags for a trek in the Himalayas, my old cell phone came along for the ride. I took it 'just in case,' though I wasn't exactly sure what emergency would justify the astronomical roaming charges. It sat buried deep in my backpack, more of a comforting thought than a practical tool. For the real business of recording my journey, I relied on something far more tangible and less tedious to use: a black hard-cover notebook.

At 3300 meters, high above the world in a Himalayan hostel, I found a quiet spot in the cafe area to settle with my morning ritual. The warmth of the fresh chai in my hands contrasted with the crisp mountain air. I opened my black hard-cover notebook, and began to jot down my thoughts.
But then, mid-sentence, I stopped. My pen hovered over the page as something caught my attention. It wasn’t the majestic view of the mountains or the usual buzz of the hostel; it was something else, something that starkly contrasted with my analog approach to capturing memories.

My gaze drifted to a man by the window, comfortably seated at what was undoubtedly the best spot in the cafe, offering a commanding view of the mountains. He reached into the deep pockets of his utility vest, first pulling out a Palm Pilot, then a foldable keyboard. With a practiced ease, he unfolded the keyboard on the table, revealing a slot into which he expertly slid the Palm Pilot.

What is a Palm Pilot? It was the Lamborghini of handheld devices, resembling what we might now see as a bulky prototype of a future smartphone (keep in mind, this was 6-7 years before the first iPhone made its debut). Though it couldn't make phone calls, the Palm Pilot boasted a range of features that were revolutionary at the time. It had a modest-sized screen, a calendar to manage appointments, a variety of games, and yes, even a note-taking app.

Using the Palm Pilot's note-taking app was an experience in itself. You had to use a stylus, carefully writing out each letter one at a time on its touchscreen. Despite this seeming limitation, using the device felt like operating a high-end luxury car. It wasn't just about the functionality; it was the speed, the elegance of its design, and, not to forget, its price tag. Witnessing someone use a Palm Pilot with a portable keyboard in the remote Himalayas was like watching magic squared.

I didn't long for the money to afford such a device. Instead, what I truly envied was the freedom it represented – the ability to break free from being tied to a specific location. It was the notion of boundless mobility that captivated me, not the gadget itself. The real dream was being able to write "Hello world" from anywhere.

The clock strikes five

She stood up suddenly, breaking the usual stillness of our office. As she headed for the door, her chair spun a little in her wake. Her regular, precise exit was like clockwork – always at 5 PM, never a minute later. We, a small band of programmers, watched this daily ritual from our corner, a nest of screens and scattered coffee cups.

There was something amusing about it, almost like watching a scene from an old movie where everyone's life is timed to the second. We glanced at our own screens, confirming the time: 5:00 PM on the dot. It was like she was programmed to leave with the precision of the systems we coded daily. In that moment, she seemed less like a colleague and more like a symbol of the very thing we had escaped - a slave to the job and the clock, bound by a routine that dictated her every move.

As the door shut behind our punctual colleague, we shared a knowing look. It was our daily signal to shift gears. I reached for the old stereo we had salvaged from a throw-away pile, and I pressed play. The quirky, electronic beats of Orbital’s “Halcyon On and On” filled the room, a 90s anthem that somehow became our unofficial soundtrack. It was niche, a little weird, but so were we.

We were your typical nerds - a bunch of programmers who got excited about coding and solving tough puzzles. We kicked off our shoes, embracing that nerdy stereotype. There’s something fun about being the kind of people who work better barefoot, and we totally embraced it.

Our corner of the office was less a workspace and more a haven for free thought and creativity - cluttered, chaotic, and undeniably ours. Amidst the tangle of wires and stacks of books on programming, an extra-sized family pizza box sat on a side table from a few days back. It wasn’t just about being different for the sake of it. We had earned our stripes, or rather, our freedom. We were trusted to take on the task of developing a government portal - a job that came with its fair share of headaches and all-nighters. We could work in our own way because they trusted us to get things done.

You know the feeling of getting up just before ten, leisurely making a cup of coffee, and taking it out to the balcony – admittedly, it's a really small balcony, but it does the job. Standing there, sipping your coffee, you watch the people in the floors above going about their morning routines. There's a sense of peace in this moment, a feeling of having all the time in the world. For a moment, I pondered skipping work for the day, but the thought of finishing the header of our portal with a new, exciting technology pulled me back to reality.

You may be familiar with this feeling now, but back then, it was a rare luxury. While I was enjoying my coffee on the balcony, most people were already seated at their desks in their offices. My friend used to call them "the ants.". The ants are going to work. They moved in a steady stream, each person a tiny part of a larger, busier world, while I observed from above.

Reflecting on it now, it might come off as a bit arrogant. I never actually called those office workers 'ants' out loud. It was more of an amusing thought I kept to myself during my walks to the office. This idea was my little secret, bringing a subtle smile to my face as I moved through the busy morning crowds. I wasn't aware of just how lucky I was. To me, it felt like the natural way of things, the way life was supposed to be.

By the time I arrived at the office, the woman was already there, settled at her desk. Throughout the six weeks of the project, I never actually learned her name. We didn't exchange even a single word with each other. Our worlds, it seemed, were parallel but never intersecting.

Ruby's Roast

At the breakfast table, there is quite a diverse gathering: an Italian cappuccino, a French croissant, an American notebook, and an ordinary sheet of A4 paper, probably made in China. Yet, upon closer inspection, this paper is anything but ordinary. It's printed full of letters and stranger characters, resembling a sample page from a printer. To the uninitiated eye, these markings might look like hieroglyphs, a mysterious array of symbols without meaning. However, to the person at the table, they are far from cryptic. In fact, they are the source code of a program. And that person, deciphering these characters with a knowing eye, is none other than me.

Printing a program's code on paper is typically a bad idea. Some books used to do this, perhaps to give them a thicker and more serious appearance. But it's a fundamentally flawed concept. Source code is full of empty spaces; many lines consist of nothing more than a solitary curly brace. Navigating through source code on paper is impractical – you have to continuously turn pages, unable to jump to specific sections or scroll through lines, as you would on a computer.

However, the programming language K is an exception to this rule due to its remarkable conciseness. A single sheet of paper with a K program printed on it can accomplish what would take 20 pages in another language.

So here I am, sitting in the cafe Ruby's Roast, looking out over Lake Garda, and actually getting some work done. I study the sheet of paper in front of me, full of K code. As I go through it, I spot a misplaced percent sign. I quickly circle it with my pen. Then, an idea for a better way to do something comes to me. I open my notebook and write down a new, simpler line of code. If you knew how much I'm getting paid for this focused, yet seemingly effortless task, you'd be green with envy.

This story, as vivid and sexy as it is, never actually happened. It was more of a dream, a vision I had for the kind of work I wanted to do. Then came the era of portable laptops, followed by ones you could actually carry around. And now, here I am, coding on a laptop in a cafe, a reality not too far off from my dream. It's true I'm working with different programming languages, ones that require a bit more scrolling.

The bare essentials of thinking

I step into the bathhouse. At the cloakroom, they hand me a white apron made of simple canvas, like it’s cut from an old bedsheet. It's plain and straightforward. I like that I don't need to bring a swimsuit. I can come here on a whim, without any preparation.

I change into the apron, leaving my clothes in the locker. The apron covers just the front and leaves my bottom bare. It feels a bit unusual, but here, it’s part of the ritual. As I immerse myself in the steaming water, I'm surrounded by other men, each in their own contemplative state. The bathhouse operates on separate days for men and women, and today, it's a male-only sanctuary.

The thought does cross my mind, briefly, that being approached by a gay man might feel strange with my exposed state. But that worry fades quickly; I know that the gay community frequents a different bath. Here, it's just a gathering of men, each lost in their own thoughts.

There's a relief, too, in the absence of women. Not because of any discomfort, but rather it spares me the unconscious act of watching them, something almost automatic. In their absence, the space becomes free of any sexual undertones, a neutral ground where the mind can wander without distraction.

This bathhouse, with its simple canvas aprons and gender-specific days, becomes a place devoid of sexuality for me. It's a rare environment where the usual dynamics of attraction and distraction are absent.

I slide into the hot water, feeling the canvas apron lift and float around me. My eyes are drawn to the familiar sign by the pool's edge, noting the water's temperature and the warning not to stay in longer than 10 minutes. It's a gentle rule, one that everyone here seems to ignore.

You might think that I'm in this hot bath just to relax and let my mind wander without purpose. But that's far from the truth. In these moments, immersed in the heat, I'm actually doing some of my hardest work. The warm water has a way of loosening not just my muscles, but also the rigid structures that programming in Java imposes on my mind. Here, in this steamy, soothing environment, my thoughts are free to roam.

This isn't work in the traditional sense – I'm not laying bricks or mechanically typing out lines of code. Yet, this is where a crucial part of my work unfolds. As I soak, my mind tackles the problems I've been grappling with, contemplating different approaches and solutions. The actual coding, the typing of line after line, is the easy part. It's in this bath, with my mind softened by the warmth, that the real challenge is met – figuring out what those lines of code should be.

Just a few meters away, I overhear the conversation between two guys discussing some sort of construction project. One is talking about plans to rebuild a hotel in the countryside, while the other mentions a business opportunity linked to it. Their words blend into the background noise of the bathhouse. I'm not actively listening, their discussion floating in and out of my awareness as I focus on my own thoughts.

This moment reinforces a powerful realization: I don't rely on anything in the physical world to do my work. The beauty of my profession is that I can work anywhere, as all I need is my brain. I don't require a computer in front of me or people around to bounce ideas off. It's just me and my thoughts. I step into a world inhabited with data structures and links, where I shift pieces of information from one place to another. In this world of changing data, I don't even need an apron.

The New Special

I used to think I just wanted the freedom to work from anywhere. But I also liked that not many people could do it – it made me feel special. Now, with so many digital nomads and remote jobs, it's not that unique anymore. It's time for me to find something new to make me feel special again.

Coding in the Shadows: Hidden Gems of Lisp, Clojure, and Friends

Adam Schmideg — Tue, 28 Nov 2023 19:58:41 +0000

In the world of programming, rankings are more than just numbers; they're a source of endless debate and pride. Much like how people are fascinated by top 10 lists in music or movies, there's a similar ranking system for programming languages. But unlike box office hits or Billboard charts, the criteria for ranking programming languages aren't as clear-cut.

There's a constant back-and-forth among programmers about which language is superior. You'll often hear them boast, "My language is better than yours," followed by demonstrations of elegant one-liners or efficient algorithms. But the truth is, we haven't settled on a universally accepted measure for ranking these languages. So, when it comes to these rankings, they're based primarily on popularity.

Now, this isn't about social media popularity – it's not a matter of likes or shares. It's about how many people are actively using these languages. Measuring this is tricky, as you can't simply count heads or survey every programmer out there. However, with a combination of job market analysis, community activity, and usage statistics in various projects, a somewhat accurate picture can be formed.

This approach to ranking may not satisfy everyone, especially since it doesn't necessarily reflect the technical merits or innovativeness of a language. Yet, it does offer a snapshot of the programming landscape, showing us which languages are currently in demand and shaping the world of technology.

The top spots in the programming language rankings are often occupied by names that even those outside the IT world might recognize. Languages like Java, Python, C, and JavaScript are household names in the tech community and beyond. When you delve into the top 20, the "least popular" among these is still used by approximately 1% of programmers worldwide – a small percentage, perhaps, but still significant when you consider the sheer number of people coding across the globe.

However, the list of programming languages doesn't stop at the top 20. Venture further down to the top 50, and you'll start to encounter some truly niche languages. Among them is Logo, a language developed in 1967 with the aim of teaching programming concepts. It's famously associated with the 'turtle graphics,' where you can control a turtle's movement on-screen through coding commands. It’s intriguing to ponder what modern applications it could have, given that it’s still used, albeit by a mere 0.1% of programmers.

Also nestled in this segment of the list is COBOL – an even older language that first appeared 64 years ago. Despite its age, COBOL remains a vital cog in the machinery of large insurance companies and banks. These institutions rely on massive mainframe computers running on millions of lines of COBOL code. It’s a language that, while seemingly antiquated, underpins systems too critical and complex to risk rewriting. The mere thought of transitioning away from COBOL raises concerns about potentially catastrophic system failures.

Lisp

Venturing even further down the list, you encounter two languages that are my personal heroes. One such language is Lisp, a language that has its roots in academia and theoretical computation. Fascinatingly, Lisp was initially conceived on paper, without any practical implementation on a computer. It's a testament to the pure, almost philosophical approach to programming language design.

Lisp is built on a handful of core concepts and a mere eight operations. Yet, from this simplicity springs an immense power. Its creator, John McCarthy, mathematically demonstrated that Lisp was a fully capable programming language, earning it the classification of being "Turing-complete." This term refers to a system of computation that, given enough resources, can solve any problem that a Turing machine (a basic model of a computer) can. In this sense, Lisp is akin to geometry as formulated by Euclid – based on just a few axioms, it unfolds into a vast and intricate world of possibilities.

The elegance of Lisp lies in its minimalism and its flexibility. It's a language that encourages a different way of thinking, one that is more about the essence of computation and less about the specifics of syntax. This philosophical underpinning makes it not just a tool for writing software, but also a medium for exploring the very nature of programming itself. For those who delve into its depths, Lisp offers a unique perspective, revealing the elegant complexity that can arise from the simplest of foundations.

Lisp's role in the evolution of computer science extends beyond its elegant design. It was the first programming language widely used for research in Artificial Intelligence (AI) during the 1960s and 1970s. At that time, Lisp was at the forefront of this groundbreaking field. This deep association with AI led to the creation of specialized hardware known as Lisp machines. These were computers designed specifically to run Lisp efficiently, representing a unique convergence of software and hardware dedicated entirely to one programming language. Unlike modern computers, which are built to run a wide range of software, Lisp machines were optimized for the nuances and particularities of Lisp.

The phrase "it was Lisp all the way down" aptly captures this era. In these machines, Lisp wasn't just a programming language running on general-purpose hardware; it was an integral part of the entire system. This period in computing history highlights Lisp's significant influence and the fervent belief in its potential to unlock the secrets of artificial intelligence and advanced computation.

As the years progressed, however, Lisp's prominence in the programming world began to wane for reasons that are as complex as they are varied. This shift in the landscape saw the rise and fall of various programming languages, each vying for a spot in the rapidly evolving tech industry.

This was the time when I came across an article by Paul Graham called Beating the Averages. Graham described Lisp as a secret weapon that wasn’t for everyone - it was special, meant for a select group of programmers. Reading this, I felt a strong connection; I knew I was part of that group. Lisp just clicked with me.

This led me to dive deeper into Graham's other writings about Lisp. The more I read, the more natural it felt to use Lisp. It was as if my mind was perfectly suited for it. This idea reminded me of a quote from Eric Raymond:

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

During this time, I was playing around with Lisp, immersing myself in its unique style. That's when Clojure appeared, like a fresh wave for those of us who loved Lisp. It felt like a modern version of Lisp, mixing old Lisp ideas with new ways of programming. Clojure made it easier to use Lisp with today's technology, first with the Java Virtual Machine (JVM), then with the browser. For a while, it looked like Clojure would make Lisp popular again. It even became one of the top 20 programming languages for a bit.

Yet, despite this promising start, Clojure didn't maintain its momentum. It eventually settled into a niche, maintaining a presence in a few actively developed applications but largely receding from the mainstream programming scene. For me, personally, Clojure has been more than just a programming language. It has profoundly shaped my thinking, offering a unique perspective on problem-solving, system design, and the elegance of code.

Doesn't Clojure deserve its own chapter? It certainly does. You can read more about why it lies so close to my heart: Why My Brain Is Wired for Clojure

APL

I promised to mention two programming languages that hold a special place for me; Lisp is the first, and APL is the other. APL, which stands for "A Programming Language," began its life not even as a language for programming, but as a notation system used by people at IBM. It was developed as a way to clearly communicate complex programming and mathematical ideas, extending beyond traditional mathematical notation.

When you first see APL code, two things will likely catch your eye. Firstly, it looks almost like a secret code from a pirate's treasure map, filled with unique symbols like backward-crossed circles, triangles with extra lines, and an array of other special characters. At the height of APL's popularity, these symbols were so integral to the language that you could even find special keyboards made just for typing in APL.

This mysterious and almost romantic quality of APL's appearance was one of the things that drew me to it. But there's another aspect of APL that's immediately noticeable: its conciseness. APL is renowned for its ability to condense what would be ten lines of code in other languages into a single line of APL.

What exactly makes APL so concise? At first glance, it might seem like a simple trick. Other programming languages are filled with long keywords and functions like continue and length, while APL appears to just replace these with a single character. But there's much more to it than that.

Yes, it's true that APL often uses single characters, like the Greek letter rho (ρ), to perform tasks that would require more elaborate expressions in other languages. Rho, for example, is used to determine the length of a string or a vector. But the real power of APL lies in its fundamental approach to data. APL treats nearly everything as a vector, or a list of items, and it's designed to operate on these vectors efficiently.

Take a simple operation like adding 2 to a vector. In strict mathematical terms, this might not make sense, but APL interprets it as adding 2 to each element of the vector. This characteristic allows you to perform complex operations without the need for writing loops or conditions, which are common and space-consuming in other languages. By thinking in terms of operations on whole vectors or arrays at once, APL enables a level of conciseness and elegance that is hard to match in more verbose programming languages.

Recognizing the limitations imposed by the need for a specialized keyboard, the creators of APL took an innovative step forward. They developed a new language, J, which was designed to be used with the standard ASCII characters available on every keyboard. This move addressed one of APL's biggest accessibility issues, making the language more approachable for a broader audience.

J's creation marked the beginning of an interesting progression in programming language development. It inspired the creation of K, a language that further refined the ideas of APL and J, focusing on efficiency and speed. K, in turn, led to the development of Q, a language built on the foundations of K but geared more towards database and query operations.

Q might not be a widely known programming language, but it has a very important role in one specific area: handling financial transactions. This is because Q is really good at processing large amounts of data quickly, which is crucial in finance where every second counts. The demand for Q programmers may not be widespread across the tech industry, but within the finance sector, their skills are highly sought after. If you know how to program in Q, you can actually earn a lot of money.

K

This part is going to be more technical. For programmers familiar with the concepts of functional programming, K offers a powerful yet concise way to perform operations like summation. For example, the expression +/!8 in K efficiently sums up the numbers up to 8. Here, !8 generates a list of numbers from 0 to 7. Then, +/ acts as what's known in functional programming as a "reduce" operation, applying the addition function across the list. Another example is calculating factorial: */1+!8. We generate a list of the number from 0 to 7; then add 1 to add number: 1+!8 -- we already know that adding 1 to a list adds 1 to each element. Finally, we reduce the list applying multiplication.

One more example. Here is how to find the largest number in a list: |/'4 2 7 1. Let's break it down how it works. The phrase |/' is a combination of two symbols:

|: This is the 'maximum' function in K. When used on its own, it gives you the maximum of two numbers.
/': This is known as an 'over' operator. It is used to apply a function repeatedly between the elements of a list.

Together, |/' applies the 'maximum' function across the list. It repeatedly compares pairs of numbers and carries forward the larger number each time. This process continues across the entire list until the largest number is determined.

If programmers have heard of K, it's usually in connection with code golf. Code golf is a unique and playful programming challenge where the objective is to solve a specific problem or complete a task using the least amount of code possible. Unlike typical programming practices where code is often measured in lines, code golf counts every single character, making each one count. This form of programming competition emphasizes brevity and resourcefulness, encouraging programmers, often referred to as 'code golfers,' to think outside the box. They must employ ingenious methods and deep knowledge of their chosen language's syntax and features to craft a solution that is as short as possible.

K has gained a reputation as one of the most successful languages for code golf. Its concise syntax and powerful built-in functions allow programmers to express complex operations in just a few characters, making it ideal for these challenges. However, in the world of code golf, some languages have been created solely to excel in this arena. These languages, often referred to as 'esoteric' or 'golfing' languages, might include built-in functions for common code golf tasks, like a one-character function to generate prime numbers - a frequent requirement in code golf challenges.

While the one-liners showcase K's ability to succinctly express complex ideas, it has a serious consequence beyond winning at code golf. Not only K applications are compact in size, but the K interpreter itself is extremely small, especially when compared to similar programs in other languages. This minimal footprint allows K applications, along with the K interpreter, to fit entirely within the L2 cache of a CPU. The L2 cache is a smaller, faster memory compared to a computer's main RAM, and because it's closer to the CPU, data stored in the L2 cache can be accessed much more quickly. This proximity significantly enhances the execution speed of K applications.

This compactness and efficient use of the L2 cache set K apart from many other programming languages. In most languages, especially those that produce larger, more memory-intensive applications, critical parts of the program and the interpreter or runtime environment are less likely to fit entirely in this fast-access cache. As a result, K applications, despite being interpreted, can often achieve execution speeds comparable to compiled C code, which is renowned for its performance. The efficiency of K doesn’t just stem from its concise syntax but also from how it harmonizes with the underlying hardware, making the most of the CPU's capabilities to deliver high performance. The speed and efficiency of K make it perfect for working with huge amounts of data in real-time, like in stock trading.

If you want to try out K, there are some open source implementations, like John Earnest's oK which has a REPL and a calculator-like interface for mobile phones with a charting feature.

The Accidental Programmer

Adam Schmideg — Tue, 21 Nov 2023 21:42:49 +0000

Many years ago, I discovered programming in an unusual way. This is the story of how I became a programmer, first a hobbyist, then a professional.

The quiet linguist

A friend once walked into my room and saw me poring over a book. "What are you reading?" she asked, peering over my shoulder.

"It's a French grammar book," I replied, turning a page filled with explanations of verb tenses (le passé composé and l'imparfait in case you want to know).

She raised an eyebrow in surprise. "So, you're learning French?" she asked.

"No," I answered with a small smile, "I'm not really learning to speak it. I just like understanding how it's structured, how it works.

My friend looked puzzled as I explained further. "Actually, I've read quite a few grammar books - Italian, German, even Latin." I gestured towards a stack of books on my desk, each one a testament to my unusual hobby.

"But how's your French then?" she inquired, still trying to piece it together.

"It's pretty basic," I admitted. "And my Italian isn't much better. As for Latin, I don't speak it at all. I'm not really focused on speaking these languages. I'm more fascinated by how they're put together, the rules and patterns behind them."

After the French grammar book, my curiosity led me to something entirely different yet strangely similar. I picked up an introduction to programming in Basic. Then a reference manual for the Pascal language. It was an odd choice, given that I didn't own a computer and wasn't planning on getting one anytime soon. Just like with the languages, my interest wasn't in actually writing any code. I was fascinated by the underlying structure, the logic and rules that made these programming languages tick.

Bets and bytes

At this time in my life, betting on football games was a big deal for me and my friend. We used to spend lots of time looking at papers, talking about which teams might win. We looked at how the teams were doing, their past games, and how their best players were playing. We thought about all of this carefully and wrote down what we decided.

Every next morning, we would meet up with our notes ready. We had lots of betting papers in front of us. I would take a pen and put an 'X' in the boxes that matched our choices. The process was tedious, repetitive, and required precision. Doing this over and over was boring. But we did it because we really wanted to win our bets.

My tolerance of monotony was so low that I involved my brother, who was pretty good at writing computer programs. So, I figured, why not make this whole betting deal easier? I caught up with him one day and laid it out. "Hey, can you help me turn this betting stuff into a program?" I asked. I gave him the lowdown, like, "We need a loop that runs from 1 to 14, adds up the odds for each game, stuff like that." He got it. It was pretty simple for him – all he had to do was translate my ideas, which I just sort of rambled off, into Pascal, the programming language he used. He seemed cool with it, just taking what I said and turning it into code.

Finally, after tapping away at his keyboard for a while, my brother hit some command and the whole thing was done. He wrote the program onto a floppy disk - this small, square piece of plastic that suddenly felt like treasure. He handed it over to me, and I remember feeling like I was holding something really valuable. This was my first computer program, even though I hadn't written a single line of the code myself.

This one last thing

My birthday brought me an awesome gift: my own desktop computer. This wasn't just a cool present; it opened up a whole new world for me. I started to write my own programs. At first, it was like learning a new language which I literally did. But soon I really got the hang of it.

Every night, I'd be there at my computer, the screen lighting up my face in the dark room. Around me, everyone else was asleep. That's how it is, right? Late at night is when artists, programmers, and murderers come alive. I was definitely not an artist or a murderer, but I sure felt like a real programmer.

With a cigarette in one hand, I'd keep telling myself, "Just fix this one last thing, then go to bed." But in programming, there's always another "last thing" that pops up. Hours would pass like minutes. Before I knew it, it would be really late, but I'd still be there, typing away.

The far-reaching Yahtzee

I created something pretty neat. It was a program where you could play Yahtzee. Sure, anyone could play Yahtzee the regular way with five dice and a piece of paper, but my program was different. I often wondered what made it special. Maybe not everyone had five dice lying around at home, or perhaps people didn't want to bother adding up their scores on paper.

Whatever the reason, my friends got pretty excited about it. They started coming over with their floppy disks. "Can you put your Yahtzee game on this for me?" they'd ask. And I was happy to make a copy for them.

The Yahtzee game I created started to become more popular than I ever expected. My friends didn't just keep it to themselves; they began sharing it with their own friends. Like a message in a bottle tossed into the sea, my little program began a journey far beyond my circle.

It was fascinating to see how far it reached. One day, I heard from a friend about someone they knew, a friend of a friend – someone I'd never met. This person worked in a theater, all the way at the other end of the country. My little Yahtzee game had traveled that far!

The theater staff, between their rehearsals and performances, would take a break, pop the floppy into their computer, and dive into a game of Yahtzee. It was a strange and wonderful thought – that something I made in the quiet of my room was bringing a bit of fun to people so far away, people I'd never met.

One morning, my trusty computer began to behave oddly. It started with a few unusual beeps – sounds I hadn't heard it make before. At first, I thought maybe I had accidentally changed a setting or triggered an unknown command. But as the beeping became more frequent, a sinking realization dawned on me: my computer had caught a virus.

This wasn't just any hiccup in the system; it was like an unwelcome intruder had slipped into the digital world I had built. I remember feeling a mix of annoyance and worry. Viruses back then were a bit of a mystery, not like the ones we know about today. They could do anything from messing up your files to completely crashing your system.

I wondered where it came from. Could it have been one of the many floppy disks that came in and out of my computer, carrying my Yahtzee game? It was a risk we rarely thought about in those days of sharing and swapping games.

I realized the extent of the issue was much larger than I first thought. The virus hadn't just infected my system; it had been copied onto the floppies of my friends along with my Yahtzee game. Each time I shared the game, the virus tagged along, silently spreading to each new computer.

Later I learned that the virus, piggybacking on my Yahtzee game, had traveled all the way to the theater at the far end of the country. More than just reaching their computer, it had infected their entire system. At the theater, their computer wasn't just for leisure; it was an essential part of their operations. They stored everything on it - from the performance schedules and rehearsal plans to important vouchers. When the virus hit, it wreaked havoc, resulting in the loss of all this crucial information.

A single program, something I created as a bit of fun and a challenge to myself, had the power to reach and affect so many people, in ways I had never anticipated.

Coding on a shoestring

As a student I had lots of options for making money. You might picture a buffet of choices laid out before me, each more appealing than the last. But the reality was more like a compulsory all-you-can-work marathon. Private lessons? Check. Translation gigs? Double check. And sometimes, the less glamorous option of skipping meals.

In those days, I noticed an odd but common trend: people who didn't have enough cash for food often still found a way to afford a drink or a pack of cigarettes. I was no exception. Despite my tight budget, there I was in a bar, nursing a single beer that had to last the night, yet somehow, it often turned into more. It was in this setting, one evening, that one of our group spotted a familiar face at another table. Seamlessly, our two groups began to blend together. It was as if introductions weren't needed; everyone just started talking and getting along as if we were all old friends.

That night at the bar, I met someone new, a guy named Zed. The exact start of our conversation is lost in the haze of memory, but I'll never forget how it ended. We shook hands on a deal – I was going to write a computer program for the research lab he worked at, and they were actually going to pay me for it. Sure, there were details to be figured out, like talking to his boss, and it wasn't a legally binding contract or anything. But it felt like something stronger, a gentleman's agreement, or rather a friend's friend agreement.

So, I got to work on the program and after some time, I was ready to show what I had done. I found myself in a room with a small group of researchers from the lab, ready to present my progress. The presentation was a bit of a rollercoaster. I navigated through the program, and when I hit a snag, I'd chuckle and say, "Okay, this bit's still under construction, but just imagine it springing to life and zipping around any moment now."

After that presentation, something amazing happened – I received my first payment for the project, a whole third of what the entire job was worth.

That night, riding high on the wave of my first big paycheck, I decided to throw a party. It was my way of celebrating this milestone and sharing the joy. I invited all my friends, especially those who had covered those extra beers for me during my leaner times. Zed, the guy who had set this whole opportunity in motion, was of course on the guest list too.

This would have been the perfect spot to end my tale, a high note of triumph and celebration. But the story of my programming adventure didn't stop there. I still had to earn the other two-thirds of my payment. So, I got back to work, full of confidence. But soon, I hit a wall, the kind that makes you feel like you're stuck in a loop of problems.

You know that feeling, right? It's like when you finally manage to close your suitcase, only to realize you left out your pants. You manage to stuff them in, but now your t-shirt is playing peek-a-boo with the zipper. No matter how you rearrange everything, something just won't fit. That was me with my program. I'd finish one part, all neat and tidy, then I'd add something new, and boom – it was like I'd pulled the wrong thread, and other parts started unraveling. I'd fix one thing, and another would break. It was this never-ending cycle of fixing and breaking, a programmer's version of the suitcase dilemma.

So what happened to the other two-thirds of my payment? Well, the simple truth is, I never got it because I never finished the program. Despite my best efforts and countless hours spent trying to piece everything together, I couldn't get it to work as it was supposed to.

Interestingly, I didn’t even have to pay back the first payment. The partially completed, 'under construction' program I left them with was probably not very useful. But in those days, programmers were such a rare breed that there seemed to be a different set of rules for us. People hiring programmers seemed to operate on a 'hope for the best' mindset. You paid a programmer, and if you were lucky, you got your program. If not, well, it was just part of the risk of investing in tech. And so began the golden era of programming, at least from my perspective.