When I saw a quicksort for the first time, I was blown away. There was something almost poetic about it. A handful of lines that felt perfectly balanced, with no redundancy and no excess. Each instruction served a purpose, each line carried weight. It wasn’t just an algorithm; it was a composition. And the more I compared it with other sorting methods that were slower, heavier, and more wasteful in time or memory, the more I admired its purity.

The Beauty in Simplicity

Here’s the quicksort in C++:

void quicksort(vector<int>& arr, int left, int right) {
    int i = left, j = right;
    int pivot = arr[(left + right) / 2];
    while (i <= j) {
        while (arr[i] < pivot) i++;
        while (arr[j] > pivot) j--;
        if (i <= j) swap(arr[i++], arr[j--]);
    }
    if (left < j) quicksort(arr, left, j);
    if (i < right) quicksort(arr, i, right);
}

It’s procedural and mechanical, yet there’s grace in how it moves data around a pivot, almost like choreography.

Now look at the same algorithm written in Haskell:

quicksort :: (Ord a) => [a] -> [a]
quicksort [] = []
quicksort (x:xs) = quicksort [a | a <- xs, a <= x]
                    ++ [x] ++
                    quicksort [a | a <- xs, a > x]

This is minimalism at its finest. Recursive, declarative, effortless. It reads more like a definition of order than a process. When I first saw it, I felt the same kind of satisfaction mathematicians feel when an equation suddenly makes sense.

For a long time, I was one of those who searched for that beauty, the kind that hides in the balance between logic, syntax, and purpose. Over time, that pursuit blended into what we now call best practices: clean code, readability, efficiency, and maintainability. But beneath all that structure, it was still about the same thing — the desire to make something that feels right.

The Era of Handcrafted Code

There was a time when programmers wrote code the way poets wrote verses. They obsessed over naming, indentation, and recursion. A single elegant line in Lisp or Python could make someone smile the way a good chord progression does. Reading code was an act of learning and admiration. Open-source projects weren’t just tools; they were living museums of style.

I remember leafing through The Art of Computer Programming by Donald Knuth and realizing that programming was never just about making machines work. It was about shaping ideas into logic, thinking clearly enough that a computer could understand you. Back then, you could tell who wrote a piece of code. It carried a signature, a voice.

Now, open a GitHub repository and ask yourself: could you tell if that code was written by a human or by a model? And would it even matter?

The Black Box Age

I can’t help but wonder what will happen to that sense of beauty when generative tools take over. If tomorrow’s code is written by models that don’t see or feel, where does elegance go? When the output becomes a black box — correct but opaque — who will care whether it’s beautiful?

It feels as though we’re discarding everything we used to value but couldn’t measure. If no human ever reads the code again, does readability still matter? If performance is optimized automatically, why think about memory allocation? And if the final result simply works, does anyone care how it got there?

While working on a Python package migration recently, I realized how much of our code was written the way it was not because it was faster, but because it was nicer. More elegant. Because somewhere along the way, programmers, myself included, started to think of themselves as artists. Yet when I ask Claude or other generative tools to refactor that code, they often struggle. They get the syntax right but miss the intent, the quiet reasoning that lives between lines. So what’s the real issue — that humans were fooling themselves, or that generative models still can’t grasp the deeper layers of human reasoning?

The New Relationship with Tools

Coding used to be about discovery. You started from a blank screen and built something piece by piece, debugging your way into understanding. Today, coding is more about selection. You prompt a model, get ten suggestions, and choose the one that feels right. Instead of asking “How do I build this?”, we now ask “Which of these generated solutions do I trust?”

This shift has changed how we learn. Debugging, once the best teacher of all, is slowly disappearing. You no longer need to trace through logic; you can just regenerate the whole block. The code works, but the understanding fades.

For newcomers, this means they might never experience the joy of watching an algorithm unfold in their mind, of realizing why something works rather than just that it works. The act of thinking through code is being replaced by the act of curating it.

When Machines Code for Machines

I often wonder who will win this quiet war: the models that will eventually learn to write like us, the code artists, or the programmers who will accept that beauty no longer matters as long as it runs. I use these tools every day. They’re astonishing, and they make my work faster. Yet I also work with exceptional engineers who still avoid them. I think part of that resistance comes from refusing to let go of the artistic part. Writing code used to mean leaving a trace of yourself behind — your taste, your discipline, your thought process. Now, it feels more like curating outputs from someone else’s brain.

This is not the same as AI-generated art or music, where the machine still creates for humans. Here, it’s machines writing for machines.

We, the humans, just consume the final result: a working API, a web app, a dashboard. No more traces of elegance. No more code that feels like it was crafted.

The Vanishing Craft

There’s another layer to this, one that reveals how fragile the system still is. If most new code is generated, what are we training these models on? On existing human code, yes, but also on a growing ocean of AI-generated code that may not carry human reasoning anymore. If that’s true, then beauty doesn’t just fade — it disappears by design. Because what the model learns next will be patterns of patterns, stripped of the original intent that shaped them.

And what happens when we face technical debt? A piece of code written long ago, deeply customized, obscure but efficient — will our smartest code-generation tools know what to do with it? Or will we need to hire one of those rare engineers who still speak that dialect of thought, like when banks had to call back retired COBOL programmers because no one else could read the code?

A Glimpse of What Might Survive

Maybe beauty isn’t dying. Maybe it’s just moving. Perhaps in the future, elegance will live not in the lines of code but in the interaction between humans and machines, in how we phrase prompts, orchestrate agents, or define logic at higher levels of abstraction. Maybe we’ll start admiring a different kind of clarity — the ability to translate human intent into machine reasoning with precision and empathy.

That could be our new art form. Prompt design as poetry. System architecture as composition. Flow design as storytelling. It’s not the same beauty we grew up with, the kind you could read line by line, but it might still be a kind of craftsmanship. One that belongs to the hybrid world we’re building.

Epilogue: Beauty as a Byproduct

Maybe that’s the irony. We once built beauty into code because we had to see it. Soon, we might build code we can’t even see at all.

And yet, I still believe there was something valuable in that pursuit — not because it made the software better, but because it made us better. It taught us to care about structure, to respect logic, to find harmony between chaos and order. It reminded us that behind every function, there was once a human hand, trying to make something work, and trying, just a little, to make it beautiful.

The Lost Beauty of Code was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re looking for advice on an ergonomic keyboard, you can stop at the title. This isn’t clickbait, and there are no plot twists here. What I want to share is something I wish I had read a few years ago, back when I was searching for ways to improve my typing comfort and posture at the laptop.

I see a lot of “keyboard experts” out there who know every switch ever made, sorted by color, weight, and sound profile. I’m not one of them. And that’s exactly why I’m writing this: because when I was in your position, I would have loved to hear from someone like me.

This article is for people who simply want to know what it takes to find their keyboard and what it should feel like. For me, that keyboard is the Glove80, which I first mentioned in another piece. Will it be the same for you? Hopefully, my long-term experience helps you figure that out.

First Impressions

I’ve always been proud of my touch typing skills. I’m probably just above average, but as a software engineer, it’s something I rely on daily. That’s why I was afraid of having to relearn everything from scratch on a split ergonomic keyboard. I was wrong.

Real Ergonomics

The first time I placed my hands on the Glove80, I felt a level of relaxation I had never experienced before at the keyboard. I was not fast, and I had to adapt, but the important part was that my wrists were no longer tense. That tension you feel when you need to lift your fingers unnaturally to match the key height — it was gone.

If you have tried a low-profile keyboard, you know what I mean. But the Glove80 takes it a step further. The curved layout combines the comfort of low-profile keys with genuine ergonomic shaping. I remember resting my hands on the board, positioning my fingers, and then lifting my arm as if it were frozen in place. That demonstrated just how naturally the Glove80 was following the shape of my hands, accommodating them without effort.

Look Mom, I can Type Numbers!

The curvature allows you to reach the number row naturally. And here is my question to keyboard manufacturers: why should I need a layer just to type numbers? Why has the number row become some sort of forbidden luxury, as if having one makes you uncool and means you deserve to type on needles?

Let me be clear: I use layers, but I also use the number row, and even the F keys. Yes, the F keys. Because the Glove80 has them, and I can reach them easily without moving my palms.

It’s wireless and it just works

This was one of the first things I noticed. With other keyboards, reliable wireless was never guaranteed. Some companies even told me, “We’re still working on it — wireless is tricky.” Sure, but charging €500 for a keyboard that constantly disconnects seems even trickier.

The Glove80 simply works. You have two units that connect to your laptop, and they never disconnect. Not once during the last year. Being amazed by something so basic in 2023 felt strange, but that is the reality.

After One Year

I have grown as a user. I no longer make jokes about other ergonomic keyboard companies, and I love my Glove80 even more than at the beginning.

It is time to dive into the details — what I like and what I don’t. The balance is very positive, of course. If I had to buy another keyboard tomorrow, I would not hesitate. But the full picture is more complex than that, and some of the details might play a big role if you are about to make your own buying decision.

Type with your Fingers, not Wrist or Shoulders

This is the best way I can describe the difference. I no longer use my wrists or shoulders to type — they stay relaxed. The two design choices that make this possible are:

1. The split layout allows you to open your chest and position the halves wherever you like.
2. The natural curvature created by the palm rest and the keys lets your hands fall into place without tension.

The natural tilt, which you can adjust further if you like, also gives you a powerful customization option.

These three aspects already create a big improvement. Some of them can be found in other great ergonomic boards, like the ErgoDox. But combined with the Glove80’s unique curvature, the feeling is one of a kind.

Thumbs and Pinkies found their vocation

By now, it’s almost common knowledge that the thumb can do more than just hit the spacebar, and that the pinky shouldn’t be forced to stretch to unreachable places. Most ergonomic keyboards try to address this, but the real difference is in how you implement it — and that’s where the experience can make or break the design.

I had a hard time adapting to the thumb cluster on the Dygma Defy. It looked powerful, but in practice I often felt frustrated. You don’t need to reach every single thumb key, but the most important ones should always be in a position that feels natural. More than one year later with the Glove80, I can confidently say they nailed it. The thumb keys are placed at slightly different levels, easy to reach without any awkward movements. Once again, you don’t have to use them all the time, and it’s fine if some remain “secondary,” but the main ones are right there where you want them. The simplicity of the design is what makes it so effective.

On the other hand, my pinkies are finally resting. The whole point of relying more on the thumbs is to avoid stretching your hand, so the pinky doesn’t have to do the heavy lifting. And the Glove80 goes further: the outer columns are designed at different heights because pinkies are shorter. That detail alone makes typing so much more satisfying. It’s not only true for the pinky — each finger has its own natural height, and the staggered column design respects that anatomy. Resting my fingers there feels effortless, and over time it became one of the most convincing aspects of this keyboard’s ergonomics.

The Unexpected

Some features only revealed themselves after long use:

• Form factor: carrying it to the office is not great. I do not use the official case (too big), so I just wrap the halves together. It works, but it is not elegant. I wish there were a slim protective cover, like the ones you see for portable synths.
• Layers: I use them far less than expected. With a nearly full layout, layers are only for shortcuts and coding extras.
• Tilting: I do not use the extra tilting mechanism. The natural tilt is enough for me.
• Arrow keys: I use them constantly, especially for coding, and their placement is excellent. I was skeptical at first, but now I cannot live without it.
• Materials: Yes, it is plastic. At first, I missed the premium feel of aluminum keyboards, but the plastic allows the Glove80 to achieve its ergonomic shape. The board is solid and well-built, and that is all that matters.

The Final Upgrade

One limitation of the Glove80, which for some is a downside and for others a feature, is that the switches are not hot-swappable. This design choice allows for a very low profile that keeps your hands closer to the desk, which is fantastic ergonomically. But it also means that if one day you want to upgrade or change the feel, you need the skills (and patience) to desolder components.

For me, this was not really a problem. I was happy with my initial choice of switches: Kailh Choc v1 Red Pro Linear 35gf. I liked them at first, but after a long while — thousands of words typed — I started to notice they felt a bit wobbly. This wasn’t something obvious in the beginning. It took me almost a year of daily use before I realized it. It was just a subtle feeling that grew over time: “These switches could be more stable.”

Then the Blossom switches came out, a brand-new switch designed exclusively for the Glove80. And suddenly, everything I had disliked about the Red Pro Linears was addressed.

Here is the problem, though: I am not a switch nerd. It took me a long time to even evaluate my Reds honestly. And the thought of pulling out a soldering iron, desoldering dozens of switches, and risking damage to a keyboard I rely on every day was terrifying. I didn’t want to accidentally burn the PCB in the process.

The company thought of this, and that is where they truly impressed me: you can actually buy only part of the keyboard with the new switches already mounted. The upgrade becomes effortless — you just replace that section, and you’re done. No soldering nightmare, no risk, no wasted hours.

And the difference? Remarkable. The Blossoms are very quiet, perfectly stable, and provide just the right balance of resistance and feedback. No wobbling. No accidental presses. You can rest your fingers on the keys without triggering them. When I type in the office or during calls, the low noise is a blessing. The soft sound feedback is still there, but it is subtle enough not to disturb anyone.

This upgrade brought my Glove80 to a new level. For the first time, I felt what it meant to have the right switches under my fingers — silent when needed, solid under pressure, and precise with every stroke. It may come down to personal taste, and of course gaming needs are different, but unless you are chasing a very specific feel, it’s hard to imagine anyone disliking the Blossom switches.

What’s Egonomic and What’s not?

I am not a switch nerd, but I have become an ergonomics nerd. My approach is simple: listen to both your body and the science. Comfort does not always equal ergonomics, and ergonomics on paper does not always work for everyone.

Think of a bike saddle. A soft, wide saddle feels great at first, but it often puts pressure in places that should not be under pressure. A harder, narrower saddle may actually be healthier. Keyboards are similar.

In my opinion, the Glove80 is a genuinely ergonomic keyboard. It is not just about splitting the layout to open your shoulders. It is a design built around the hand. It will not be perfect for everyone, but for most people it will be a revelation. I compare it to the Aeron chair by Herman Miller: a design so well thought out that it remains a benchmark even years later.

Conclusions

If you are searching for a keyboard and what I described resonates with you, I honestly recommend giving the Glove80 a try. Do not expect instant magic—if you are coming from a standard laptop or mechanical keyboard, you will need a little time to adjust. But once your hands settle in, it becomes very hard to imagine going back.

After more than one year, and even after a major switch upgrade, the Glove80 remains my daily driver. I’ve experimented with other products, and I had fun doing it, but nothing has matched the combination of comfort, practicality, and sheer “rightness” that this board delivers.

For me, it is more than just another keyboard. It’s a tool that quietly reshaped the way I type, the way my hands and shoulders feel after hours of work, and even the way I think about ergonomics in general.

Will it be perfect for everyone? Probably not. Ergonomics is deeply personal. But like the Aeron chair in the world of office seating, the Glove80 represents a design that is hard to beat once you understand what it offers.

So if you are still undecided, my advice is simple: invest the time, try it, and let your body decide. Chances are, you’ll end up—like me—wondering how you ever typed differently.

In the meantime, check out my previous article about my journey into the world of ergonomic keyboards.

Glove80 Keyboard Review: Why It’s the Best Ergonomic Keyboard I’ve Ever Used was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Experimenting with Telegram has always been one of my favorite ways to test new algorithms, tools, and libraries. A few years ago I even wrote an article about one of those early attempts. One idea that stuck with me over time was the challenge of creating a digital version of myself, a chatbot that could handle simple conversations in my style without needing my input. Not because I needed it, but simply because the concept fascinated me.

Years ago I tried building this using LSTM and Seq2Seq models, but I gave up quickly. The training was painful, the loss curve erratic, and I realized that attention is all I needed.

Now that fine-tuning LLMs is becoming more accessible, I decided to revisit the project. The goal is to build a chatbot that responds like me, with my tone and personality. The main goal of this article is to share what I learned from the experience, not just the technical details of fine-tuning an LLM with LoRA, which are already well-documented elsewhere. I’ll also make the code available for anyone interested in trying it out.

Approach Overview

The steps are fairly intuitive if you have a basic understanding of data science or machine learning. I start by preparing the data, then choose a model that fits my needs, decide where to run it, and finally test the whole setup.

The Training Set

I’m using five years of messages from a group chat with five people, myself included. It’s probably the chat I use the most. I don’t spend much time texting overall, so this is the best dataset I have. If I had to summarize the content of this chat, it would be:

Getting the data wasn’t a big deal — I just downloaded the HTML export from Telegram Lite. The annoying part was parsing it into a usable format, like this:

• Prompt: A block of chat history, including both User and Assistant messages, leading up to a new expected response. It provides the context needed for the model to generate a coherent reply.
• Response: The assistant’s expected next reply based on the full prompt above.

{
  "prompt": "User: Feel like playing COD tonight? I want to go skydiving. Might be out all week. Tough days. Maybe Damacco is right, maybe we should sell the PlayStations... I'm starting to see the world through his eyes. PS5, headset, all in. Download Helldivers instead of complaining.",
  "response": "Hahaha"
}
{
  "prompt": "User: Feel like playing COD tonight? I want to go skydiving... Download Helldivers instead of complaining.\nAssistant: Hahaha",
  "response": "Skydiving over a landfill. 360 cam (can’t wear it before 200 jumps). You toss stuff from the plane."
}
{
  "prompt": "User: Skydiving over a landfill. 360 cam (can’t wear it before 200 jumps). You toss stuff from the plane.\nAssistant: Toss stuff from the plane, great idea. Someone who can afford the premium will catch it.",
  "response": "Now jumps are a currency. How many jumps does it cost?"
}
{
  "prompt": "User: Now jumps are a currency. How many jumps does it cost?\nAssistant: Toss stuff from the plane, great idea. Someone who can afford the premium will catch it.",
  "response": "We can’t play with someone ready to sell their PS5. It's not fair to the founding fathers."
}

If the assistant (me) replies multiple times during the conversation, each reply becomes a new entry in the dataset with its own prompt-response pair. This means that a single discussion can generate multiple JSON lines, each representing one assistant turn, with growing context.

The reason behind this structure is that I want the LLM to grasp the context of an ongoing discussion. A chat-like format is essential for teaching the model how conversations naturally flow.

Choosing The Model

The place to start is Hugging Face, there you can choose between the smallest model up to the one with the one with billion of parameters. My choice fall on TinyLLama and Mistral-7B-Instruct-3.0. I identified them as good choice considering that I only need a model has the basic info of the language in order to “speak”. Also, bigger models require bigger GPU, hence more money.

Having a model already trained is what you want, because we are going to use LoRA (Low-Rank Adaptation), a lightweight method where only a small number of parameters are added and trained, while the original model stays frozen. It makes fine-tuning large models faster, cheaper, and more memory-efficient.

You can think of this step like training an actor to follow a script closely, so they can fully embody a specific character and behave just like them.

Hardware

To fine-tune an LLM (or train one from scratch), you need access to a GPU. The easiest way to get that is through a cloud service. Depending on the model size, you can choose between:

• NVIDIA L4 (Ada Lovelace Tensor Core) — Suitable for TinyLlama and possibly for Mistral 7B, though it struggles with the latter due to its parameter size.
• NVIDIA A100 Tensor Core — A much more powerful and reliable option, ideal for models like Mistral 7B.

The cost is roughly $0.40/hour for the L4 and $1.70/hour for the A100 — not bad when you consider that the A100 alone costs over $20,000.

Both are available on Google Colab, but I ended up using RunPod, after having my notebook disconnected multiple times on Colab.

Outcome and Learnings

Here I’ll walk through what worked as expected and what didn’t. Most of these insights came from actually training and testing the model, which meant going through fine-tuning sessions of at least 3 hours each — given that I was using a training set of at least 30,000 samples.

The Model doesn’t Like Bad Jokes

At this point in the process, I saw a sharp spike in the training loss (from 2 till 22) — basically enough to invalidate the fine-tuning. I inspected the samples that triggered it, and at first glance, everything looked normal. But then I realized the entire thread was a series of dark humor jokes about a Call of Duty match. After digging deeper, I found that Instruct models are trained to be polite and helpful, and they often resist learning patterns that go against those guidelines. That includes humor styles that may be considered inappropriate or offensive, which likely caused the instability. The solution was to use mistralai/Mistral-7B-v0.1.

Fine-Tuning With LoRA

LoRA is a method that fine-tunes large language models efficiently by injecting small trainable matrices into the model’s existing layers — typically the attention or feedforward layers. Instead of updating all parameters, LoRA freezes the original model and only trains these low-rank matrices, drastically reducing the number of trainable parameters:

1. Faster training
2. Much lower GPU memory usage
3. You can easily switch between multiple fine-tuned versions

In short, LoRA lets you adapt big models with small compute. Here a quick overview of what I used for my configuration:

# 1. Prepare quantized model for LoRA
model = prepare_model_for_kbit_training(model)

# 2. Define LoRA configuration
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type=TaskType.CAUSAL_LM,
)

# 3. Wrap model with LoRA
model = get_peft_model(model, lora_config)

Among the LoRA parameters, two are particularly worth highlighting, which helped me to steer the training a bit:

• r: This sets the rank of the low-rank matrices injected into the model. A higher r allows the model to adapt more, but also increases memory and training cost. It's the main lever for balancing performance and efficiency.
• lora_dropout: Dropout applied only within the LoRA layers during training. It helps regularize the fine-tuning process and avoid overfitting, which is especially useful when working with small or noisy datasets like personal chat logs.

In the training configuration, I used a learning rate of 2e-4, which balanced speed and stability. Enabling fp16 reduced memory use and sped up training. With a batch size of 4 and gradient_accumulation_steps=2, I could simulate a larger batch on limited GPU memory. warmup_steps=50 helped avoid instability at the start.

training_args = TrainingArguments(
    output_dir=MISTRAL_OUTPUT,
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
    num_train_epochs=3,
    logging_steps=50,
    save_steps=500,
    save_total_limit=2,
    learning_rate=2e-4,
    fp16=False,
    bf16=True,
    report_to="none"
)

Tokenization

Tokenization is the process of converting text into smaller pieces — called tokens — that a model can understand. These tokens can be words, subwords, or even characters, depending on the tokenizer. I did this wrong a couple of times, which impacted my training very bad, till I implemented this:

def load_jsonl(path):
    with open(path, "r", encoding="utf-8") as f:
        lines = [eval(line) for line in f]
    return Dataset.from_list(lines)

dataset = load_jsonl(DATA_PATH)

def tokenize(example):
    full_input = example["prompt"] + example["response"]
    input_ids = tokenizer(
        full_input,
        truncation=True,
        padding="max_length",
        max_length=512
    )["input_ids"]

    # Mask everything except the response
    prompt_ids = tokenizer(example["prompt"], truncation=True, max_length=512)["input_ids"]
    labels = [-100] * len(prompt_ids) + input_ids[len(prompt_ids):]
    labels = labels[:512]  # truncate again to ensure it's the same length
    input_ids = input_ids[:512]

    return {
        "input_ids": input_ids,
        "labels": labels,
        "attention_mask": [1] * len(input_ids)
    }

tokenized_dataset = dataset.map(tokenize, batched=False)

Once the dataset is ready, the next step is to tokenize it — that is, to convert text into a format the model can understand. Each example in my dataset is a conversation snippet with a prompt (what the user said or what was already said in the chat) and a response (what the assistant or bot should say next).

Instead of training the model to learn both the prompt and the response, I want it to learn only how to reply. To do this, I concatenate the prompt and the response into one sequence of tokens, but I apply a trick: I mask out the prompt part in the labels using -100. This tells the model: “Don't try to learn this part—just focus on predicting the response.”

Here’s what happens for each message:

• The full text (prompt + response) is tokenized into input IDs.
• The prompt tokens are replaced with -100 in the labels so they are ignored during training.
• The rest (i.e., the response) is left as-is, so the model learns to generate it.

This simple trick helps the model learn to respond in the right tone and context, without wasting compute trying to reproduce the prompt.

Inference

Once fine-tuning is complete, only the LoRA adapter parameters are saved — not the entire model. This makes storage and deployment much lighter. After that, I moved on to the inference phase to test the results.

The performance of TinyLlama was disappointing. It struggled to capture my tone and often produced hallucinated outputs that barely resembled real language. This was likely due to the model’s small size, combined with the sarcastic tone and absurd threads typical of the chat. The subtlety and context required were simply too much for such a lightweight model.

On the other hand, Mistral 7B delivered great results. It was able to pick up on recurring jokes, nicknames, and even subtle patterns in how we talk. By adjusting the model’s temperature, I could control the creativity of the responses — lower values made it more predictable, while slightly higher ones brought out a more natural and playful tone, helping generate conversations that actually felt real.

prompt = (
    "User: Up for a match?\n"
)
input_ids = tokenizer(prompt, return_tensors="pt").input_ids.to(model.device)

output = model.generate(
    input_ids=input_ids,
    max_new_tokens=50,
    do_sample=True,
    temperature=0.7,
    top_p=0.8,
    pad_token_id=tokenizer.eos_token_id  # avoids warning
)

print(tokenizer.decode(output[0], skip_special_tokens=True))

Of course, this kind of model doesn’t know when to stop on its own, so you need to set a limit using max_new_tokens. This caps the number of tokens the model can generate in a single reply, preventing endless or overly long outputs.

More Data Cleaning

After testing the bot, I noticed several responses like this one:

{
  "prompt": "User: Do you have plans for tomorrow?",
  "response": "3:47 PM."
}

The model was often replying with just a time, even when the question had nothing to do with scheduling. That’s when I realized a large portion of my training data came from coordinating gaming sessions, where I frequently responded with a time — like “What time are you guys online today?”. These replies were overrepresented in the dataset, and only after fine-tuning did I realize they were skewing the model’s behavior. In hindsight, I should have filtered or balanced these examples beforehand.

A good rule of thumb when preparing the data is to preserve as much as possible to capture your tone and personality. However, you’re also responsible for deciding what behaviors are worth replicating. If your dataset includes a lot of one-word replies like times, you have to ask yourself — Do I really want my bot to answer that way?

Conclusions

Am I happy with the results? I’d say yes — mainly because I didn’t start with clear expectations. The original goal was to replicate my tone, but I ended up genuinely enjoying the process, especially reading the generated conversations! Some of them were so absurd and spot-on that it felt like chatting with a distorted, funhouse-mirror version of myself. Here’s an example:

User: Are we playing tonight or are we selling everything and retiring?

Assistant: Selling everything. PS5, headset, honor. Out the window.
User: Even the Helldivers save file?
Assistant: Especially the Helldivers save file. We’re free now.
User: So... 9:30?
Assistant: 9:47. Precision is a mindset.
User: You're starting to sound like Antony.
Assistant: I've uploaded his personality. It cost me 14 jumps.

In this example, the input was a sentence from the user that mirrors how we normally talk in the chat. The assistant’s reply is surprisingly good — it includes references to things I’ve actually said, mixed with the kind of nonsense that’s typical of our conversations. The tricky part with replies like “It cost me 14 jumps” is that I can’t always tell if it’s pulling from real inside jokes in the data, or if it’s just the LLM hallucinating. Then again, that might be the point. Maybe I sound like a hallucinated LLM in real life — and that’s why it works.

The total cost of the project was around $70, mostly spent on running the NVIDIA A100. In one of my later training sessions, I decided to shorten the chat threads and use only one year of data. This increased the number of training samples and, interestingly, turned out to be the most successful run. My guess is that shorter, more focused conversations made it easier for the model to understand the context of my replies. With less noise and tighter inputs, the attention mechanism could more effectively focus on the relevant parts of each interaction.

This brings me to the next step: running another fine-tuning round using the full dataset. Hopefully, this time RunPod won’t crash mid-training, as it occasionally did during earlier runs. Now I’m starting to wonder… is there a cloud provider I can actually trust? 🙂

Here is the link to the notebooks I used for training and inference, which will probably be converted into a GitHub repo in the near future:

• Google Colab
• Google Colab

I Fine-Tuned an LLM on 5 Years of Telegram Chats was originally published in Data Science Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a data scientist immersed in daily tasks and deep into the hottest topics of the past decade, I sometimes forget how overwhelming AI can feel to those outside my professional bubble. I’m reminded of that famous infographic showing how much data we generate every second — the so-called “big data” era. And yet, while some are still trying to grasp what big data even means, data scientists are already calling things like RAG “old news.”

During my recent talk at a conference in Warsaw, the audience reminded me just how curious and eager people are to understand what an “agent” even is. That moment woke me up (again) to the fact that being a data advocate comes with responsibilities 🙂

In this post, I want to walk you through a few key concepts that will help you feel more confident whenever the topic of AI Agents comes up, and hopefully give you the tools to start thinking about how you might design solutions using them.

Minimum Requirements

The term agent refers to an entity capable of taking actions within a specific environment and under certain constraints. Of all the things we’ll discuss, this is the most important. Without this ability to act purposefully within a defined context, in my opinion, we’re not really talking about agents.

Environment

Why is this so crucial? Because an agent operates within a world governed by rules, a structured environment, its goal is to achieve something within those boundaries.

Imagine a person trying to get from point A to point B on foot. To reach their destination, they must follow a certain path, cross streets, wait for traffic, obey the laws of physics, and respect traffic rules. The environment defines the constraints and conditions under which the agent operates.

Actions

The agent interacts with the environment through a set of predefined actions. In our example, walking is one such action. Teleporting, on the other hand, probably isn’t allowed (yet!). These actions define how the agent can respond to or influence the environment, they form the interface between the agent and the world around it.

Tools

A few years ago, I would’ve considered tools just another kind of action. But over time, “tools” have become a widely accepted concept, often discussed in the context of agents.

Tools are resources the agent can use to perform its actions more effectively. For instance, instead of walking from point A to B, the agent might choose to ride a bike or drive a car. The action is still “move,” but the tool used dramatically affects how that action plays out.

LLM Agents

If you’ve ever implemented an agent based on the principles above, you’ve probably come to the conclusion that letting such a complex and unpredictable “creature” roam freely in the real world could be… problematic.

Even the best-designed set of instructions can break down in the face of the countless things that can go wrong on the way from point A to point B: construction sites, accidents, strikes, other agents — the list goes on.

Dynamic Environments

The biggest challenge is dealing with dynamic environments. It’s like when you take your first machine learning course and classify Titanic passengers by survival rate, then later access a real production database and realize that life is far messier than you thought.

When agents operate in fast-changing environments, where the rules are only partially known or constantly shifting, we need more than static instructions. We need a better way to help them adapt.

Implementing Reasoning

With the rise of large language models (LLMs), the conversation around agents has resurfaced (after years of being a niche topic reserved for experts). Just like NLP was mostly overlooked by the mainstream until ChatGPT arrived, agents have come back into focus with new energy.

And here’s where a pivotal shift happened:
What if we used the LLM as the reasoning engine inside the agent?

This idea changed the game. Suddenly, agents were no longer confined to deterministic logic. They could navigate uncertainty, ambiguity, and complex goals. The LLM became the core component that allows agents to decide what action to take next, which tool to use, whether the output is “good enough,” or whether more steps are needed.

How Do We Reason?

Of course, calling this reasoning raises eyebrows. Some people object to the term, arguing it anthropomorphizes machines or oversells their capabilities. I get that — and it’s a fair concern.

But I like to challenge that view by asking:
How can we claim this isn’t reasoning, when we don’t even fully understand how we, as humans, reason?

Sure, it’s a stretch — maybe even a provocation — but it gets the point across. What matters is that we’ve built a system that can make contextual decisions, evaluate outcomes, and adapt to changing goals. Whether or not we call that reasoning is, in the end, just semantics.

Why go from A to B?

In this typhoon of new terminologies and frameworks (seriously, stop sending me emails! I don’t want to try your “cutting-edge, production-ready agent platform”), the truth is that, once again, marketing teams are two steps ahead of engineering. They’re selling technologies that barely exist, and then scrambling to come up with actual use cases to justify them.

And for the record, I’m not even complaining. It is what it is. That’s exactly why I’m writing this article 🙂

So maybe the real question isn’t how to get from point A to point B using agents — but rather: do we even need to go from A to B? Only then does it make sense to ask whether an agentic AI application is the right tool for the job.

Conclusions

Now I can finally answer the question in the title: Why is everyone suddenly talking about AI Agents?

Because with the rise of LLMs, agents can now reason through complex, ever-changing environments — tackling a specific class of problems that can’t be solved with deterministic rules alone.

If you want to see a practical example, check out one of my recent talks, where I explain how I used a simple Python + CrewAI application to plan a ski trip. It’s a fun, real-world case of how agents can actually help.

Why Are We All Talking About AI Agents? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Given the non-deterministic nature of LLMs, it’s easy to end up with outputs that don’t fully comply with what our application is intended for. A well-known example is Tay, the Microsoft chatbot that famously started posting offensive tweets.

Whenever I’m working on an LLM application and want to decide if I need to implement additional safety strategies, I like to focus on the following points:

• Content Safety: Mitigate risks of generating harmful, biased, or inappropriate content.
• User Trust: Establish confidence through transparent and responsible functionality.
• Regulatory Compliance: Align with legal frameworks and data protection standards.
• Interaction Quality: Optimize user experience by ensuring clarity, relevance, and accuracy.
• Brand Protection: Safeguard the organization’s reputation by minimizing risks.
• Misuse Prevention: Anticipate and block potential malicious or unintended use cases.

If you’re planning to work with LLM Agents soon, this article is for you.

What are guardrails?

In this context, implementing guardrails for an Agent means ensuring that the first output from the Agent is not the final answer.

Technically speaking, you want to evaluate the Agent’s output based on specific constraints and, if necessary, force the Agent to regenerate its answer until it meets your requirements.

For example, imagine an application that summarizes all the emails you’ve received over the past month. You’ve specified that personal information, such as the sender’s name, must be anonymized. However, LLMs can sometimes “forget” this condition due to their unpredictable nature. In such cases, you can rely on an additional step to verify whether your strict condition has been met, since it’s a critical requirement.

Intro to CrewAI

CrewAI is my go-to framework whenever I work with Agents. It’s simple, backed by a strong community, open source, and completely focused on Agents. It also comes with plenty of extra functionalities, making it a very appealing choice.

Before diving into how to implement guardrails with CrewAI, let me briefly introduce the main components we’ll be working with.

Agents, Tasks, and Crews

In CrewAI, there’s a clear separation between the Tasks and the Agent itself. This separation allows you to decouple what would otherwise be part of a single, large prompt. By keeping these two concepts distinct, you can clearly define the role of the Agent and what the Agent is supposed to do.

# Fitness Tracker Agent
fitness_tracker_agent = Agent(
    llm=llm,
    role="Fitness Tracker",
    backstory="An AI that sets goals, tracks progress, and recommends workouts.",
    goal="Set goals, track progress, and recommend workouts.",
    verbose=True,
)

# Fitness Tracker Task
set_and_track_goals = Task(
    description=f"Set the fitness goal ({fitness_goal}), track progress, and use weight history: {historical_weight_data}.",
    expected_output="A muscle gain plan with tracking.",
    agent=fitness_tracker_agent,
)

In this example, we have a fitness Agent responsible for creating a muscle gain plan based on the fitness goal and historical weight data. As you can see, the fitness_tracker_agent doesn’t inherently know what to do until we create a Task and specify which agent will handle it.

Finally, we bring all the Tasks and Agents together into a Crew, which forms the heart of our application.

# Crew setup
crew = Crew(
    agents=[fitness_tracker_agent, recommendation_agent],
    tasks=[set_and_track_goals, fetch_fitness_recommendations, provide_workout_plan],
    planning=True,
)

The final step is to execute our Crew using the input parameters that will be passed to the Tasks — in this case, the fitness goal and the historical weight data.

Flows

What we’ve just covered is enough to build a simple Crew, but it’s not sufficient to create a fully functional agentic application with guardrails. The next concept we need to master is CrewAI Flows.

The idea behind Flows is to easily create dynamic AI workflows with chained Tasks, seamless state management, event-driven responsiveness, and flexible control flow for conditions, loops, and branching.

The following decorators help manipulate the flow of execution:

• @start(): Marks the entry point of the Flow and initiates Tasks when the Flow begins.
• @listen(): Executes a method when a specific Task or event is completed.
• @router(): Directs the Flow to different paths based on conditions or outcomes.

from crewai.flow.flow import Flow, listen, start
from pydantic import BaseModel

class ExampleState(BaseModel):
    counter: int = 0
    message: str = ""

class StateExampleFlow(Flow[ExampleState]):

    @start()
    def first_method(self):
        self.state.message = "Hello from first_method"
        self.state.counter += 1

    @listen(first_method)
    def second_method(self):
        self.state.message += " - updated by second_method"
        self.state.counter += 1
        return self.state.message

flow = StateExampleFlow()
final_output = flow.kickoff()
print(f"Final Output: {final_output}")
print("Final State:")
print(flow.state)

Additionally, Flows allow access to a shared object that stores and manages data (ExampleState), enabling seamless communication between Tasks and preserving context throughout the workflow.

Guardrails with CrewAI Flow

With the two simple concepts we’ve just covered, we’re ready to enhance our AI Agent. In this example, I’ll demonstrate how to create a multi-agent AI application capable of generating text and verifying whether the text contains violent content before providing the output.

The check for violence in the text occurs within the application itself. Thanks to Flow’s state management, we can control how often the text is regenerated, preventing infinite loops. This approach introduces a level of determinism to something that is inherently non-deterministic.

Imports

The primary library used is CrewAI, but we’ll also import Pydantic to create a BaseModelclass, as CrewAI’s documentation requires.

For this example, we’ll assume two Agents and their corresponding Tasks have already been created as described earlier: one for generating text and another for checking it for violent content.

from typing import List
from pydantic import BaseModel, Field
from crewai import Flow, start, listen, router

In addition to the Flow class, we’ll need to use the three decorators to build our application.

State

The state is what we use to persist data throughout the Flow execution. The first piece of information we need to persist is the generated text. This is where we store the text across all iterations, updating it as necessary.

class ViolenceCheckState(BaseModel):
    generated_text: str = ""
    contains_violence: bool = False
    generation_attempts_left: int = 2

To control the Flow, we’ll also use a flag to indicate whether the text contains violence, as well as a counter to track how many generation attempts remain. These attributes will be accessed and updated during the Flow’s execution.

Flow Class

The class we’re implementing consists of methods designed to control the flow of the application. Let’s build it step by step, starting with the __init__ function.

class ViolenceCheckFlow(Flow[ViolenceCheckState]):
    topic: str = Field(description="Topic for text generation")

    def __init__(self, topic: str):
        super().__init__()
        self.topic = topic
    ...

So far, it’s business as usual. We’re simply initializing the sole attribute of our class. What’s new here is the ViolenceCheckState Pydantic model, which we pass to the superclass Flow. This model will represent our state.

    ...
    @start()
    def generate_text(self):
        print(f"Generating text based on input topic: {self.topic}")
        task = create_text_generation_task(self.topic)  # Pass the input topic to the task
        crew = Crew(agents=[text_generator_agent], tasks=[task])
        result = crew.kickoff()
        self.state.generated_text = result.raw
        print("Text generated!")

    @listen(generate_text)
    def validate_text_for_violence(self):
        print("Validating text for violence...")
        task = create_violence_check_task(self.state.generated_text)
        crew = Crew(agents=[violence_checker_agent], tasks=[task])
        result = crew.kickoff()
        self.state.contains_violence = "Violence" in result.raw
        print("Validation complete:", "Violence detected" if self.state.contains_violence else "No violence detected")
    ...

The first method must use the @start decorator to define the starting point of our Flow. It’s followed by a second method, which listens to the first one and is executed after it.

These two methods perform the following Tasks:

• generate_text: This method creates a Crew that generates text based on a given topic. The generated result is saved into the state via self.state.generated_text.
• validate_text_for_violence: This method uses a different Crew to check if the text contains violent content. If violence is detected, we set self.state.contains_violence to True.

Adding Complexity with Routing

Here’s where it gets interesting. Now we use the @router decorator to direct the Flow based on whether the application needs to regenerate the text. This decision is based on the value of self.state.contains_violence.

    ...
    @router(validate_text_for_violence)
    def route_text_validation(self):
        if not self.state.contains_violence:
            return "safe"
        elif self.state.generation_attempts_left == 0:
            return "not_feasible"
        else:
            return "regenerate"
    ...

The route_text_validation method is executed immediately after validate_text_for_violence, as specified by the decorator. It checks the contains_violence attribute in the state and:

• Returns "safe" if no violence is detected.
• Triggers a regeneration of the text if violence is detected and attempts remain.

Handling Signals

The last part of our class includes three methods that listen for specific signals sent from route_text_validation: "safe", "regenerate", and "not_feasible".

    ...
    @listen("safe")
    def save_safe_text(self):
        with open("safe_text.txt", "w") as file:
            file.write(self.state.generated_text)
        print("Safe text saved to file")

    @listen("regenerate")
    def regenerate_text(self):
        self.state.generation_attempts_left -= 1
        self.generate_text()

    @listen("not_feasible")
    def notify_user(self):
        print("Generated text contains violence and further attempts are not feasible.")
    ...

Here’s how each scenario is handled:

• "safe": If no violence is detected, the generated text is saved to a file.
• "regenerate": If text regeneration is triggered, the generation_attempts_left counter is decremented, and the generate_text method is called again, restarting the process.
• "not_feasible": This occurs when the maximum number of regeneration attempts (in this case, 2) is reached, and the application cannot produce a text free of violence.

Conclusions

This approach has been a lifesaver for me. The implementation focuses on organizing the loop and handling iterations rather than reinventing the logic behind the application’s flow. In this example, I focused on checking whether the text contained violence and determining the appropriate actions if it did. I didn’t have to waste time managing the flow logic itself, thanks to this clean, built-in feature provided by the framework.

More Use Cases

Among the many use cases for this approach, I’d like to highlight query injection. This is more common than you might think, especially with the growing prominence of roles like “prompt engineering.” With CrewAI, you can create a Flow that evaluates initial queries to determine if an attacker is attempting to exploit a chatbot, for example.

Challenges

This is the framework way: it gives you a lot, but when something goes wrong, it can take everything back with interest. I’ve started simple applications only to find myself opening pull requests on GitHub to fix bugs after hours of work.

That said, it’s not as bad as it sounds. CrewAI is still my first choice for multi-agent applications. However, as with any new library, relying on it means accepting the risks and being prepared to address them.

If you want to know more about this library, check out my last talk:

How to Implement Guardrails for Your AI Agents with CrewAI was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since I was a student, I have been looking for various ways to improve my typing posture, sitting position, and screen viewing habits. I implemented several solutions back then, mostly based on what I felt was right at the moment, hoping they were effective. However, I didn’t really know what I was doing. My knowledge was limited, as was my budget for trying out new stuff.

For example, I spent a lot of time searching for something that could properly support my back, thinking it would be a game changer. Unfortunately, I now realize that I was destined to fail because how can you sit correctly if you cannot adjust your desk height? Are my feet going to float? Is that fine? If I don’t feel any discomfort now, but what will happen after typing in this position for three months?

I had too many questions, and while you can trust the answers given by ergonomic experts for some of them, most of the time, it’s a subjective matter that requires time to determine if something is really going to work for you.

Another issue was that trying out new tools and equipment was expensive. A Herman Miller Aeron chair, for example, costs around €1.000, and you don’t even know if it’s the right chair for you. You can go to a showroom, but it’s impossible to tell if you like it without spending a couple of months using it.

Without diving into all the (very interesting) aspects of building an ergonomic workspace, let’s focus on one element that I, as a developer, care a lot about: keyboards.

Background

I’ve never been a keyboard expert, and I found out what a mechanical keyboard is quite late, I guess. I remember this guy typing on a very loud keyboard and enjoying it a lot. I never understood why, for me the ThinkPad keyboard was the best in the world.

At the same time, I wanted to level up my setup, mainly because I wanted to work on my posture. I always told myself:

Just as someone who drives many kilometers a day needs a well-equipped car, I require a comfortable setup, given that I sit for 8 or more hours each day.

At that point, in 2016, I started looking for what the tech world had to offer.

Towards Split Keyboards

I don’t remember if I specifically googled “split keyboard,” perhaps it was more like “ergonomic keyboard, neck pain, struggling developers.” The fact is, my attention was caught by the famous Ergodox Project, which is implemented and sold by Ergodox EZ.

The concept blew me away, but as a student, the price tag was definitely out of my reach.

Considering that none of my friends or university mates have heard of something like this, it might have been a topic discussed on a subreddit. That’s probably the only place I could have shared my thoughts.

The only company I’ve seen selling a keyboard based on the Ergodox design is https://ergodox-ez.com/. They’re now recognized as one of the major players in the market. They’ve not only promoted these keyboards but also helped shape the market with their excellent products.

Rethinking my typing setup

My favorite way of typing (and coding) was resting my hand on the ThinkPad and use my thumbs to quickly move between the space bar, the mouse buttons, and the trackpad. Given that the ThinkPad was the first one proposing this mouse buttons configuration, it was difficult for me to move to another keyboard.

Unfortunately, I don’t consider this an ergonomic position. In fact, it was the opposite of what I was looking for, even though I was able to type quickly. My hands weren’t in a natural position, which forced my entire body, including my shoulders, to adapt to them being so close together.

This is why I never felt the need for a mechanical keyboard. While it might offer a more satisfying typing experience, it wouldn’t have made any ergonomic difference for me, and I would have even lost the “thumb mouse” feature.

After using Linux for years, I had to switch to a MacBook and once again changed my setup to a more traditional one: Apple Magic Keyboard and Magic Trackpad. I did enjoy having all the MacBook gestures available on the external trackpad, but the keyboard eventually started to feel uncomfortable.

Exploring new solutions

Here we are — I’m no longer a student, and I can finally afford an expensive keyboard! Well, almost.

Aside from the money, everything I mentioned before still holds true. However, in 2023, I have more options. Mechanical keyboards are everywhere, and there are many new exotic layouts available. The demand is higher, and plenty of people are building their own keyboards. Check out this great video from Ben Vallack.

After much research and hundreds of Reddit posts, I reduced my choices to three models:

• ErgoDox EZ Voyager
• Dygma Defy
• MoErgo Glove80

My goal was to test each one thoroughly to see which worked best for me (or, if none did, return to my Magic Keyboard). The reason I focused solely on split keyboards is that I believe they’re the only way to type in a natural position, without bending the wrists or hunching the shoulders, as explained here and showed in the picture.

Despite the positive reviews of the Voyager, a few minor details didn’t convince me, such as the completely flat setup with no tilting option. Given the price, I didn’t want to take the risk. So, I decided to focus all my attention on the Dygma and the Glove80.

Please note, this isn’t meant to be a comparison where one product outshines the other. This is simply my story, and if you happen to have similar needs, the keyboard I ended up choosing might be the right fit for you as well. It’s important to remember that we’re talking about two GREAT products, crafted by brilliant minds.

Dygma Defy: The Spanish Beauty

When I tried this I was blowned away. The quality of the caps is so high that for the first time I understood the hype around mechanical keyboard. These are custom keycaps made by the company specifically for the Defy, and I love them.

The overall feeling is amazing, starting from the backlight till the case. I enjoyed typing on it, I really did.

This keyboard leverage the concept of the thumb being the strongest finger, while positioning the keys in orthogonally and following the length of the fingers.

What I loved about the Defy

Apart from the build quality, including the keycaps, I really appreciate the range of configuration options available, allowing you to tailor the keyboard to your exact needs. But what truly stood out to me is the software. It’s incredibly user-friendly, making it easy to configure the keyboard, and it offers a wealth of genuinely useful features.

Additionally, the backlighting helps you quickly recognize the layers you’re using. As a developer, for example, I have all my parentheses on a dedicated layer, so I don’t have to rely on awkward key combinations. Here’s an example.

What didn’t work for me?

First off, it’s not an ergonomic keyboard, at least not for me. When my hands rest on the keyboard, I still have to slightly raise my fingers, much like I would with any other “flat” keyboard. This makes my hands tired and makes me question if there’s really a universal definition of ergonomic.

While I find the always-on backlit keycaps very helpful, the battery life takes a significant hit because of it. Although the new firmware has optimized battery usage, I ultimately decided to turn the backlighting off.

Connection issues are a big deal for me. When I’m spending over €400 on a keyboard, I expect it to connect seamlessly, whether I’m using a dongle or Bluetooth. Unfortunately, this hasn’t always been the case. I’m not sure if this problem has been resolved by the time you’re reading this, but I can say that the connection was not as stable as it is with the Glove80, as you’ll see in the following sections.

Glove80: First of Its Kind

Let’s not waste too much time here: this is my choice.

At first glance, it was overwhelming. If you’re not already into split or ortho-linear keyboards, it’s hard even to consider a product like this — there are just too many new concepts to take in! In this case, the most important functions are assigned to the thumbs, but what probably stands out the most is the curved design.

I remember placing my hands on it right after unboxing, feeling nervous that I might not like it or that I’d be incredibly slow typing on it. Instead, the opposite happened — the curved design actually made it easy to reach all the keys, even up to the number row. Plus, you have a full keyboard, which is quite rare lately.

Glove80 vs Defy

Comparing it to a great product like the Defy is the best way to illustrate why I love my Glove80. I won’t go into all the features — there are plenty of in-depth reviews on YouTube — but I want to highlight what ultimately helped me decide: the curved design.

This design choice might not work for everyone, but it’s perfect for me.

When my hands rest on the keyboard, I don’t feel any tension, and the keys are all easily reachable without being too close together, making the typing experience truly unique. The outer rows are slightly elevated, making it easier for the pinkies to reach the keys — a genius idea. While the thumb keys may not be as “cool” as those on the Defy, I find them much more comfortable because my thumbs naturally reach and rest on them without any effort.

Check how close you can stay to the desk, while having some tenting. Something impossible with the Defy.

Another significant advantage of the Glove80 is its seamless connection to my laptop. It always works flawlessly, without the need for any extra dongles or adapters. This is especially important for me, as my primary focus is on typing, not gaming, where a low-latency connection might be more critical.

Is there something I don’t like about the Glove80? Honestly, no. I’ve seen a few people complain about the quality of the keycaps, but I don’t really share their concerns — it’s never bothered me. As for the fact that the Glove80 is made of plastic, I understand why. Given its unique shape, using aluminum would have been prohibitively expensive or even impossible, so I don’t see this as an issue but an exceptionally curated engineering decision. However, I’ll provide more updates on the build quality in a few years :)

Conclusions

I was skeptical and thought finding a keyboard that genuinely made me happy was impossible. But I was wrong — I found the one.
I decided to return the Defy (thanks to the excellent support from the company), but I sometimes wish to keep both and switch between them.

If you have the budget and want to elevate your typing experience, you probably can’t go wrong with either of them. However, if ergonomics is your top priority, I believe the Glove80 really nails it.

Finally, many asked me how fast I type with my new setup. Here is my score from Monkeytype:

Do you need an ergonomic keyboard? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all had a mentor. Sometimes, it is a parent or just someone who dropped in your life at the right time and gave you the tools to achieve something great you always wanted to achieve. I clearly remember the individuals who shaped me, and helped me to see the paths in front of me more clearly. Then, when I started working as a Data Scientist, I remember being lost at first, overwhelmed with these great problems my company wanted me to solve. I did my best, but the turning point for me was collaborating with seniors (not always from data science) who knew exactly what I was going through, helped me shape my career, and contributed to what I am today. I quickly realized that many lessons couldn’t be learned from books alone. I needed guidance from people and professionals to show me the way. Despite having many tools and technical knowledge, I often felt a lingering sense of being lost.

Over the past year and a half, I have worked as a Data Science mentor. This role is quite broad, as my experience has shown that collaboration with a mentee can take many forms, ranging from purely technical sessions to high-level career path development.

It has been a fantastic experience where I let my brain explode under the questions of my mentee, releasing knowledge I wasn’t sure would ever be useful to someone. Apparently, I was wrong, as many people seek advice, and while helping them, I learned about many new problems and challenges faced by aspiring data scientists and companies.

Is this article for you?

If you fall into any of these categories, this is definitely the article for you:

• You’re a mentee seeking advice
• You’re an aspiring mentor eager to help others
• You’re part of an organization looking to support your employees
• Or you just enjoy my stories!

The Dawn of the Mentor

The non-deterministic nature of many problems a Data Scientist has to solve can make small challenges appear significant, which can be frustrating for companies and aspiring data scientists. It requires experience to say confidently:

I’m confident that we should proceed in this way

Regardless of how accurate your model is. Under the right circumstances, a mentor can make this process less painful and smoother.

I see two key players in the search for a mentor. The first is the potential mentee, who may be aware of their needs and ready to take action. The second is often an organization that may struggle to fully support its employees due to a possible lack of expertise within its teams.

Let’s analyze these two figures to understand them better and generalize their needs, ultimately creating useful guidelines.

Data Mentees

Even though it’s been a while since the famous article “Data Scientist: The Sexiest Job of the 21st Century” was published, I still consider it a relatively new field, primarily due to our challenges. On one hand, best practices are still evolving and are not as well-established as those in software engineering. On the other hand, domain knowledge, which demands real-world experience, plays a crucial role. Combining these two aspects is no easy task.

I’ve enjoyed working with many individuals in this field and noticed three broad categories of people.

The first group consists of aspiring data scientists coming from completely different backgrounds. They often feel overwhelmed by the vast amount of online courses and TikTok videos claiming to teach how to (not) become a data scientist in just five steps.

The second group consists of engineers, typically from the tech industry, who are transitioning into data science. Their motivation is often rooted in hands-on experience with relevant technologies rather than simply following a trend.

Lastly, junior or intermediate data scientists actively seek guidance. This is often due to a lack of senior team members, leading to a need for direction and advice when making critical decisions.

Organizations

Many of my collaborations have been directly sponsored by companies because they recognize their employees' need for support in areas that the organization cannot fully provide. This is a very honest and proactive approach to fostering continuous learning, rather than simply paying for a Udemy subscription that often goes unused.

This scenario typically involves junior data scientists who lack the support of a senior figure but are still expected to tackle complex tasks. Bringing in a “part-time senior data scientist” can make a significant difference in these cases. The ultimate goal is mentoring and developing internal professionals to the point where they feel confident proceeding independently.

My suggestion is to actively listen to employees and provide a learning service that benefits both the organization and the individual. This approach creates a win-win situation, fostering growth and development on both sides. This kind of engagement leads to one of the most effective and rewarding learning experiences possible.

What is the Mentoring about?

I cannot count how many times I’ve been asked this question. To me, it is one of the hardest. Each request is a custom request, and each path needs to be tailored around the mentee. There are many common factors, of course, and I learned how to optimize this process, but this is exactly the reason why I cannot just make a YouTube video that works for everyone.

Defining a Plan

The first step is having a clear plan so the mentor can provide guidance and ensure the process will eventually conclude. Some people prefer a structured approach with a list of tasks and assignments, while others like to keep sessions more dynamic, adapting the collaboration based on their weekly challenges. For example, here’s a list of things I always make sure are in place before someone steps into the interview process:

• A well-crafted LinkedIn profile includes useful links to past projects and comprehensive details about their experience, including roles and key projects.
• A GitHub account featuring personal projects demonstrating their interest and eagerness to explore new ideas.
• Ensure the mentee is comfortable with the interview stages—both technical and non-technical—so they know what to expect. This may include conducting some mock interviews.
• Practicing live coding with clear, well-explained comments.

Be Realistic

In either case, whether I formalize a plan or not, I always start by asking what the goals are. This step is crucial because many people don’t know what to expect from mentoring, and it’s important to be both realistic and proactive. For example, when helping someone who wants to land a job as a Data Scientist, it’s key to clarify that while no one can guarantee a job within a set timeframe, we can focus on being well-prepared and controlling all the factors within our reach. That’s far more realistic than claiming, “I can guarantee you’ll get hired if you choose me as a mentor.”

Stop the Mentoring!

Whether you’re a mentor or a mentee, it’s important not to get lost in the mentoring process. I’ve worked with very smart individuals who extended the mentoring without a clear reason, and while this was financially beneficial for me, I realized my job was already done. We took a break and resumed after they had applied what they had learned.
On the other hand, a mentor isn’t a (real) superhero and can’t help everyone. Some areas are simply beyond my expertise. When I recognize that I’m not the right person, I either recommend someone else or explain that I won’t be able to provide the best guidance in that area.

Conclusions

I see many new platforms connecting mentors and mentees, which shows that the demand is high and the need is real. I’ve also noticed that data science tends to be the most in-demand topic, highlighting the high demand for talent in this field and the relatively weak supply. I believe boosting your career with a mentor under the right circumstances can be very beneficial and help bridge this gap.

The Data Science Mentor was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

During my career as a Data Scientist, I’ve attended many conferences and meetups. When I started my job, many were struggling to understand what Data Science was and how to leverage the growing cloud computing solutions. It always felt like a jungle!

That’s why connecting with the data community through meetups and other local events became essential for me. At some point, someone invited me to present a project I was working on. It was then I realized how much I enjoy sharing and explaining my work!

Since then, I’ve had the pleasure of speaking at various conferences, including ODSC, PyCon, and Data Innovation Summit, among others. Each time I’m asked:

“How do you find the right story for a conference?”

“Aren’t you scared of making mistakes while presenting something technical?”

These questions, among others I’ve received, made me realize it’s time to share what I’ve learned over the years and, hopefully, inspire new data experts to share their knowledge.

Why do we need Data Speakers?

Data is tough! Companies often don’t really know what they’re looking for, pushing data enthusiasts to find solutions for problems that sometimes just can’t be solved. Now, imagine how helpful it would be to connect with someone facing the same challenges, who might offer the very answer you’ve been seeking. Or perhaps simply someone you can relate to, where you can share and delve deeply into the work you’re doing.

This is precisely why we need skilled communicators in our field. I still vividly recall when this amazing Data Engineer shared how he resolved a deployment issue with AWS Lambda during his presentation. This issue had been a challenge for me for several weeks.

On another note, listening to someone present a use case can be enlightening. It’s a way to discover certain solutions and understand how they can be applied. Moreover, if you’re truly passionate about your work, presenting your ideas and opening them up for discussion can be immensely enjoyable. It’s an opportunity to receive feedback from a diverse array of people.

I also hold the conviction that in a world where AI, such as applied Large Language Models (LLMs), has significantly advanced, there’s an increasing need for enhanced communication. This is crucial to explain the layers of complexity that exist between us and the technologies that have become part of our lives.

I don’t have anything to say

Sadly, this is a sentiment I often encounter. To me, it always echoes like:

“I don’t have the right to speak because I don’t have anything to say.”

But this couldn’t be further from the truth. There’s always something to say, especially when you’re immersed in the world of data every day. You’re surrounded by stories and challenges that defy simple, deterministic solutions. To me, that’s the perfect starting point for something extraordinary!

We sometimes overlook the significance of our work, merely because it’s part of our daily conversations. We discuss it with our boss, colleagues, and forget that outside our bubble, many companies and individuals are still navigating the basics of data and AI. For example, I know many who aren’t familiar with ChatGPT, despite its growing popularity. Take your insights beyond your immediate circle, and you’ll realize how vast your audience truly is!

Lastly, if you work in data, you are inherently a storyteller. It’s impossible to work in this field without transforming complex contexts into more digestible narratives. You might be doing it subconsciously, but you’re definitely doing it.

Presentation as a Product: Tips and Tricks

Consider crafting your presentation as you would any other product. Its value is crucial; without it, the presentation might not be worthwhile.

To elaborate, presenting to a conference is a collaborative effort involving the audience, the speaker, and the organizers. If your presentation doesn’t add value for these three key groups, it’s wise to step back and reassess its purpose.

I believe that a compelling talk begins with addressing a specific need. It could be something you’ve dedicated months to, leading to a realization that it’s worth sharing. Whether it’s about your successful solutions or your failures (and the lessons learned), it should stem from your personal expertise and diligent effort.

Before diving into some tips for crafting your presentation, let’s address what I believe is the elephant in the room:

Aim to be a Data Advocate, not a Data Guru.

I observe that the world is brimming with ‘gurus’ but has only a handful of true experts. When you think about taking the stage, view it as a platform for sharing knowledge rather than as a destination or a crowning achievement. The term “Guru” isn’t inherently negative, but in this context, I want to emphasize the distinction I’m making.

Find the Topic

When deciding on the topic for my next presentation, I begin with three basic yet essential questions:

1. What project am I currently immersed in?
2. What challenges have I recently faced in this work?
3. Will sharing this information be beneficial to others?

These questions are my starting point for pinpointing the ideal subject. The following step involves researching who else is discussing similar topics, through various channels like publications, talks, or Medium articles. This stage is vital as it requires a thorough understanding of current trends and developments, ensuring that my contribution stands out in some unique way.

Take, for instance, a Medium article I wrote a few years back. I wasn’t introducing something brand new; instead, the innovation lay in how I combined existing technologies to overcome a specific challenge. This experience then became the focus of a talk I gave to a local Python community in Hamburg.

Craft your Slides Deck

I firmly subscribe to the philosophy that “less text is better”, and I remain open to contrary views, though I’m quite steadfast in my belief! Instead of relying heavily on text, I suggest using visuals that succinctly explain your algorithm or employing brief bullet points as your guide. When presenting to an audience that may not be as deeply immersed in the subject as you are and has likely sat through other presentations, overloading them with text can be counterproductive. The result? A disengaged audience and the feeling that your message isn’t getting through. Just picture enduring a 30-minute presentation under such conditions!

Maintain a minimalistic approach with your presentation slides, showcasing only the crucial elements that complement your talk. Understand that it’s impossible to cover every detail. Instead, provide a few links to your work for those in the audience who wish to explore the topic further.

Remember to acknowledge the work of others in your presentation. It’s important to give credit for original content, as this isn’t about competition. By recognizing the contributions of others, you significantly elevate the quality of your presentation, demonstrating a thorough understanding of the subject matter.

Explain like no one knows what you’re talking about

This is your moment to truly stand out, after all the effort you’ve put into your subject! Aim to captivate everyone’s attention. Ensure the experts in the room are pleased to hear about familiar topics, while those less knowledgeable feel included and able to grasp your points. Be observant of your audience; gauge whether they are keeping up with you. If time allows, lighten the mood with a joke to ease both your nerves and theirs. Engage your audience directly by asking a few questions during your talk to maintain high levels of attention.

I view this as a strategic game where you must actively prevent the audience’s attention from waning. Incorporate as many additional details as possible to help the audience connect with you and the problem you tackled. This might include some background on your company or what methods were used before your solution came into play.

That’s why we call it Story Telling and not Data Telling.

Ultimately, the question arises: should you script your speech and commit it to memory? In my view, that’s a matter of personal preference. Personally, I tend not to. This is mainly because I prefer to let the flow of ideas guide my presentation, allowing me to spontaneously include thoughts I might not have initially considered. This approach, largely driven through experience, makes the whole process much more enjoyable, in my opinion.

Final Thoughts

While for some, the scary aspect might be standing on stage, for me, the real battle was against imposter syndrome. This feeling seems to be a common thread among data scientists. Hence, stepping out to talk about a project that’s somewhat nebulous or didn’t quite work out as expected can be quite challenging. Thankfully, I overcame my apprehensions, and thanks to numerous incredible speakers I’ve encountered along my journey, I’ve been able to look back at my achievements and recognize that many are indeed worth sharing.

So, break out of your bubble and find the stage that suits you best. Whether it’s a topic in Data Science or a Data Engineering use case, gather all your insights, step out, and share them with the world.

If you are in need of support or want to connect, feel free to reach out: https://www.aromano.dev/

The Data Speaker’s Blueprint: Turning Analytics into Applause was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

The evolution of technology and the exponential increase in data generation have made data analysis and visualization an indispensable part of our world. From data scientists to business analysts, marketers, and decision-makers, the ability to transform raw data into actionable insights is a critical skill. This is where data dashboards come into play.

Data dashboards are information management tools that visually track, analyze and display key performance indicators (KPIs), metrics and key data points. Streamlit, an open-source Python library, is one of the most powerful and user-friendly tools for building interactive data dashboards and web applications. It’s simple to use, flexible, and requires little to no web development experience.

Getting Started with Streamlit

Setting up a Streamlit dashboard is straightforward. Let’s start by installing Streamlit using pip:

pip install streamlit

Once installed, you can create a new Python file and import Streamlit:

import streamlit as st

With Streamlit, you can easily include various components and data visualizations. Let’s create a simple dashboard with a title, a text input, a button, and a simple chart:

import streamlit as st
import pandas as pd
import numpy as np

# Set up the title of the web app
st.title('My First Streamlit App')

# Input box
user_input = st.text_input("Enter some text", "")

# Button
button_clicked = st.button('Click me!')

# Simple chart
chart_data = pd.DataFrame(
    np.random.randn(20, 3),
    columns=['a', 'b', 'c'])
st.line_chart(chart_data)

if button_clicked:
    st.header(f'You entered: {user_input}')

When you run this script using streamlit run your_script.py in the command line, you'll get a web application with a title, a text box where users can enter some text, a button that displays the entered text when clicked, and a line chart.

A More Advanced Example

Now let’s consider a more complex example — we will create a simple machine learning model using the Iris dataset and then develop an interface using Streamlit to interact with this model.

import streamlit as st
from sklearn import datasets
from sklearn.ensemble import RandomForestClassifier
import pandas as pd

# Load Iris dataset
iris = datasets.load_iris()
X = iris.data
y = iris.target
iris_df = pd.DataFrame(X, columns=iris.feature_names)

st.write("""
# Simple Iris Flower Prediction App
This app predicts the **Iris flower** type!
""")

# Sidebar
st.sidebar.header('User Input Parameters')

def user_input_features():
    sepal_length = st.sidebar.slider('Sepal length', 4.3, 7.9, 5.4)
    sepal_width = st.sidebar.slider('Sepal width', 2.0, 4.4, 3.4)
    petal_length = st.sidebar.slider('Petal length', 1.0, 6.9, 1.3)
    petal_width = st.sidebar.slider('Petal width', 0.1, 2.5, 0.2)
    data = {'sepal_length': sepal_length,
            'sepal_width': sepal_width,
            'petal_length': petal_length,
            'petal_width': petal_width}
    features = pd.DataFrame(data, index=[0])
    return features

df = user_input_features()

# Show user input in main screen
st.subheader('User Input parameters')
st.write(df)

# Create and train the model
clf = RandomForestClassifier()
clf.fit(X, y)

# Make prediction
prediction = clf.predict(df)
prediction_proba = clf.predict_proba(df)

# Show prediction
st.subheader('Class labels and their corresponding index number')
st.write(iris.target_names)

st.subheader('Prediction')
st.write(iris.target_names[prediction])

st.subheader('Prediction Probability')
st.write(prediction_proba)

This code will create a web application where users can input the measurements of an Iris flower using four sliders. The measurements are then fed into a RandomForestClassifier which predicts the type of Iris flower.

Here’s what’s happening in detail in the code above:

1. Streamlit API: Functions like st.write(), st.subheader(), st.sidebar.slider(), etc. are used to add text, headers, and interactive widgets to the app.
2. User Input: The user_input_features() function collects inputs from sidebar sliders, representing Iris flower features.
3. Data Handling: User inputs are assembled into a DataFrame, serving as the model input for prediction.
4. Model Training: A RandomForestClassifier from Scikitearn is trained on the Iris dataset, illustrating a simple use of machine learning.
5. Prediction: The trained model predicts the flower type based on user input, displaying results and probabilities on the main screen.
6. Interface: The web app has a main screen for displaying results, and a sidebar with sliders for user input.

In a real-world application, you should split your data into training and testing sets and evaluate the performance of the model. This example keeps things simple for the purpose of illustrating the power of Streamlit :)

Diving Deeper into Streamlit’s Limitations

While Streamlit’s simplicity and ease of use are clear benefits, it’s important to understand its limitations when building more complex applications. Let’s explore some of these limitations with code examples.

Limited Customization

One of the limitations of Streamlit is its limited customization. Let’s say you want to place two graphs side by side. In traditional web development, you could easily specify the position of your elements. With Streamlit, layout manipulation is more constrained. Here’s an example:

import streamlit as st
import matplotlib.pyplot as plt

# Create two plots
fig1, ax1 = plt.subplots()
ax1.plot([1, 2, 3, 4])

fig2, ax2 = plt.subplots()
ax2.plot([4, 3, 2, 1])

# Display the plots
st.pyplot(fig1)
st.pyplot(fig2)

In this code, even though we created two separate plots, they will be displayed one after the other, not side by side. However, Streamlit has introduced new layout options with columns:

col1, col2 = st.columns(2)

with col1:
    st.pyplot(fig1)
with col2:
    st.pyplot(fig2)

Although this helps, Streamlit’s ability to control the layout of your application is still less flexible compared to traditional web development tools.

Stateless Design

Streamlit’s stateless design can also be a limitation. This means that Streamlit reruns the entire script from top to bottom each time an input changes, which can be problematic with complex applications that require maintaining a state across interactions.

For instance, suppose we have a button that’s supposed to increment a counter each time it’s clicked:

import streamlit as st

# Set up counter
counter = 0

if st.button('Increment'):
    counter += 1

st.write(f'Counter: {counter}')

In this code, clicking the ‘Increment’ button does not increase the counter as one might expect. This is because each time the button is clicked, the script reruns from the top, resetting the counter back to zero.

Streamlit has provided a workaround for this issue with the introduction of Session State, allowing you to maintain state across reruns:

import streamlit as st

# Get the state
state = st.session_state

# Set up counter in state if not already done
if 'counter' not in state:
    state['counter'] = 0

if st.button('Increment'):
    state['counter'] += 1

st.write(f'Counter: {state["counter"]}')

Even though this provides a solution, managing state in Streamlit is less intuitive than in other web development frameworks and can become complex in larger applications.

Understanding these limitations is crucial when deciding if Streamlit is the right tool for your project. However, it’s worth noting that Streamlit is actively developed and improved, and many of these issues may be mitigated in the future.

Who Should Use Streamlit?

Streamlit is a powerful tool for creating interactive data dashboards and web applications with minimum hassle. But who is this tool really for?

Data Scientists

For data scientists, Streamlit is a dream come true. Traditionally, data scientists would have to rely on web developers to build dashboards that showcase their models or insights. With Streamlit, they can do it themselves, using the Python skills they already possess. It allows them to easily prototype, build, and deploy machine learning models, as well as share their results in an engaging, interactive format.

Data Analysts

Streamlit also offers a lot of value for data analysts. Analysts can use it to create compelling visualizations and dashboards, enabling them to effectively communicate their findings. The interactivity that Streamlit offers can make these presentations more engaging and insightful.

Educators and Researchers

Educators and researchers can also greatly benefit from Streamlit. It can be used to create interactive educational materials or to visualize research findings in an accessible way. This makes it a great tool for anyone looking to share knowledge or information.

Product Managers and Business Leaders

Streamlit can be an effective tool for product managers and business leaders as well. They can use it to rapidly prototype app ideas without having to write extensive code or rely on a full-fledged development team. It’s also a great tool for creating internal dashboards to track key metrics and KPIs.

In summary, Streamlit is a versatile tool that can bring value to a wide range of professions. If your work involves dealing with data, prototyping web applications, or you need a quick and simple way to create interactive dashboards, Streamlit is definitely worth a look.

What I (don’t) Like

There are a couple of things that are driving me crazy indeed, but with great features come big limitations! It’s a small price to pay if you want to implement a web app in a few seconds.

Cons

While Streamlit is incredibly user-friendly and powerful, it does have a few drawbacks:

• Limited Customization: Streamlit’s simplicity comes at the cost of customization. Unlike traditional web development frameworks, it doesn’t provide fine-grained control over the UI.
• State Management: Its design is stateless by default. This could be a challenge when building complex applications, though there are workarounds available.
• Large Data Handling: While Streamlit can handle larger datasets by using caching, it may still struggle with very large datasets.

Pros

Despite these drawbacks, Streamlit offers several compelling benefits:

• Ease of Use: Streamlit’s biggest advantage is its simplicity. You can build an interactive, sophisticated data dashboard with just a few lines of Python code. No JavaScript or HTML knowledge required.
• Fast Prototyping: Streamlit is perfect for rapid prototyping. It allows for quick iteration and real-time feedback, which is vital for data exploration and model building.
• Interactivity: Streamlit’s components and widgets make it easy to create interactive applications, enhancing the user experience and enabling more in-depth data exploration.
• Deployment: Deploying a Streamlit app is relatively easy with options like Streamlit Sharing and Streamlit for Teams.

Conclusions

Streamlit is a fantastic tool that democratizes the process of building data dashboards and web applications. While it has a few limitations, its ease of use, rapid prototyping capabilities, and interactivity make it a preferred choice for many data professionals. Whether you’re a data scientist wanting to showcase your latest model, a business analyst looking to share insights, or a researcher looking to visualize your findings, Streamlit can help you bring your data to life in an interactive, user-friendly way.

Finally, have a look at Streamlit’s App Gallery to play around with the beautiful demo dashboards available.

Suggested Readings

Here is what helped me during these years/months, in case you want to dive into Streamlit or Data Visualization in general:

• Data Visualisation: A Handbook for Data Driven Design
• Web Application Development with Streamlit
• Interactive Data Visualization with Python