Klemens Morbe

Blog

  • The Vibe-Coding Backlash: Why most criticism misses the point

    Across LinkedIn and X, vibe coding is mocked as sloppy, insecure, or a threat to “real” software engineering, but much of that pushback reflects defensive posturing more than grounded analysis. Vibe coding, popularized in early 2025, is simply an AI‑assisted development workflow where you express intent in natural language and let an LLM generate, iterate, and debug code with you in the loop.​

    What vibe coding actually is

    Vibe coding describes a conversational, intent‑first way to build software: you describe goals, accept AI‑generated diffs, run and test, then iterate through natural‑language feedback loops until it works. The idea was popularized by Andrej Karpathy, who framed it as “giving in to the vibes” and letting AI handle the boilerplate while you steer outcomes, especially for low‑stakes prototypes and weekend projects.​

    The irony on social media

    Since the term took off, social feeds flipped from routinely critiquing junior code quality to suddenly romanticizing it, often to argue that AI tools are uniquely bad while juniors are uniquely careful, which doesn’t match most real‑world code reviews. The online debates are loud, but many of the strongest critiques come from folks who haven’t used these tools beyond cursory trials, which skews perceptions of their practical value.​

    AI tools vs. junior baselines

    Modern AI coding tools frequently outperform typical junior baselines on speed, structure, and consistency for common tasks, especially when guided by a developer who can review and test outputs effectively. Reviews of platforms like Bolt.new show mature scaffolding, sensible defaults, and strong project hygiene that reduce boilerplate while keeping codebases navigable and extensible.​

    Bolt.new as a case study

    Bolt.new’s V2 added an agentic mode that autonomously chains tasks like debugging and refactoring, while giving you control to approve or adjust steps, minimizing the “spray and pray” pattern critics worry about. Its guidance emphasizes safer handling of environment variables and secrets via dedicated stores or configuration patterns, reducing accidental leakage in shared repos or logs during rapid iteration.​

    Prompting is requirements engineering

    “Garbage in, garbage out” isn’t unique to AI, unclear requirements have always produced poor software; vibe coding just makes this more visible and faster to iterate. Treat prompts like lightweight requirements: specify constraints, acceptance criteria, context, and interfaces, then tighten the loop with tests and feedback for reliable outcomes.​

    Use cases that shine

    Vibe coding is most effective when speed and iteration matter more than heavy upfront design. It’s a natural fit for scripts and internal tools, where you can generate working code quickly, test it against real logs and data, and refine in tight loops. The same strengths carry over to prototypes and proof‑of‑concepts: you can validate feasibility without over‑engineering the early layers. As those ideas harden into MVPs, the workflow helps you ship core value fast, collect feedback, and progressively strengthen the codebase with tests and reviews. For high‑assurance systems with strict compliance or reliability requirements, pair AI assistance with rigorous code review, security scanning, and formal testing gates to uphold standards.

    Security is a practice, not a promise

    AI‑generated code can introduce known vulnerability classes if left unchecked, the same way hurried human code does; the remedy is standard security hygiene: dependency vetting, secret management, code review, and automated scanning. Organizations that operationalize AI coding alongside SAST/DAST and secret scanning cut the risk while keeping the productivity gains.​

    The real takeaway

    Vibe coding isn’t a gimmick or a replacement for engineering fundamentals, it’s an acceleration layer that rewards clear intent, tight feedback loops, and disciplined review. Teams that embrace it pragmatically ship faster prototypes, cleaner scaffolds, and safer defaults, while reserving deep review for the parts that truly matter.

    Affiliate Disclosure

    Some of the links on this blog are affiliate links, which means I may earn a small commission if you make a purchase through these links. This comes at no additional cost to you and helps support the content provided on this blog. Thank you for your support!

  • The GenAI Productivity Paradox: Faster and Slower at the Same Time

    Over a decade in the Java and Spring ecosystem taught a clear lesson: generative AI only helps when the task is simple, well-bounded, and style-agnostic, otherwise, it slows things down.

    The friction starts with code suggestions that are technically correct but stylistically off, forcing constant edits to re-align with hard‑won idioms, architecture, and conventions that define readable, robust systems. Over time, the verification overhead outweighs any typing saved, especially in mature codebases where nuance and domain constraints matter. This led to switching off AI in the IDE for most work, using it only where the task is mechanical or trivially verifiable.​

    There was also a period of heavy AI use, which revealed a different cost: delegating integration with external libraries eroded the hands‑on familiarity needed to reason about APIs, edge cases, and failure modes later. That trade‑off wasn’t worth it. Static code analysis remains superior for reliability and signal‑to‑noise, and architectural decisions stay human because they hinge on context, trade‑offs, and long‑term maintainability that generalized models can’t capture. Today the balanced approach is narrow and intentional: AI for Dto to Entity converters, simple utilities, and unit tests seeded by an exemplar to lock in test style, with quick scan‑and‑run verification.​

    What studies say about experts and slowdown

    A 2025 randomized controlled trial by METR with 16 experienced open‑source developers found that allowing early‑2025 AI tools increased task time by 19%, despite participants predicting a 24% speedup; even post‑hoc, they still believed AI had sped them up, underscoring a perception gap. The full paper and PDF are openly available.​

    At a broader labor‑market level, the St. Louis Fed reports modest but measurable gains across workers using GenAI, estimating around a 1.1% aggregate productivity increase in late 2024, which coexists with the expert‑level slowdown evidence, context and task mix matter. Public summaries and methodology notes are accessible.​

    There is also RCT evidence of positive effects in enterprise settings and with coding assistants like Copilot, where trials reported productivity increases, with stronger benefits for less experienced developers, again highlighting that task type and seniority shape outcomes.​

    Why juniors often benefit (and where)

    Juniors typically work more on standardized, bounded tasks and less on complex, cross‑cutting architecture, so AI’s strengths line up with their task mix. Coding assistants accelerate boilerplate, pattern lookup, and implementation scaffolding, while seniors incur a verification tax correcting “average” solutions that clash with established design intent. Field and lab studies on Copilot show higher gains for less experienced developers, consistent with these dynamics.​

    Practical sweet spots for AI include:

    • Boilerplate and mechanical transforms like Dto to Entity mappers where correctness is easy to spot and style is minimal.​
    • Unit test generation using a seed example to enforce personal conventions, followed by quick human review and execution.​
    • Documentation stubs and simple utilities where the implementation is straightforward and verifiable.​

    Conversely, high‑context work such as static analysis, architectural design, and large legacy refactors is ill‑suited to LLMs due to missing whole‑codebase semantics, reliability requirements, and nuanced trade‑offs that exceed pattern matching. Experienced engineers report that AI suggestions often introduce review overhead or subtle misfits in these areas.​

    It’s about the mix, not maximal usage

    The pragmatic stance is selective adoption: use AI when tasks are mechanical, verification is cheap, and no meaningful learning is lost; avoid AI when correctness hinges on deep context, when style and architecture matter, or when over‑delegation would erode skill. Evidence from both an expert RCT and enterprise trials supports a dual reality, experts can slow down while less experienced developers speed up, so the optimal strategy is to align AI usage with task structure and seniority. Organizations and individuals should target the narrow bands where AI is a true accelerant and resist using it merely because it is available.​

  • How I Use AI: A Personal Take on Creativity, Code, and Everyday Magic

    Artificial Intelligence (AI) has been a hot topic for a while now. People talk about its wonders, its risks, its breakthroughs, but rarely do they show what they actually do with it. So I thought: instead of joining the chorus, why not offer something more tangible? Here’s how I personally use AI, what it creates for me, how it helps me, and where it’s become part of my everyday life.

    From Theory to Practice

    Like many of you, I didn’t have much exposure to AI early on. At university, it was discussed in theoretical terms, basic concepts, academic models, far removed from real-world use. Most people I heard talking about AI were either researchers or developers. But everything changed when the fire nation .. ehhh ChatGPT 3.5 was released in late November 2022. Suddenly, the entire world was talking about AI and actually using it.

    🎵 Music: A New Voice for Old Emotions

    Since early 2024, I’ve been using Suno, which is a platform that lets you generate original songs with vocals. You can write your own lyrics, use AI to help with that, or just let ChatGPT draft something for you. After picking a genre and structuring your lyrics with markers for verses and choruses, you simply hit “generate”, and within seconds, two tracks appear.

    At first, I just wanted some 8-bit music for a private game project. But soon, I found myself making over 20 personalized songs for my wife and child, all playable on their beloved Toniebox. Listening to music you “wrote,” even if it’s not your voice or piano playing, hits differently. It feels real, personal, meaningful. While those family songs are too personal to share, I’m currently working on a playlist for work, calm, focus-friendly background music that helps me concentrate. You can listen to it directly on Suno or YouTube.

    🖼️ Images: From Plush Toys to Action Figure Stickers

    I’ve never been great at drawing or design. Early on, I used ChatGPT (back when it had DALL·E 3) to generate wallpapers for my phone and desktop. That novelty wore off quickly, especially since the model really struggled with rendering text in images.

    But things improved. When the native image model was introduced in ChatGPT, I gave it another shot, and I was amazed. It could finally handle text well, preserve composition across prompts, and adapt to feedback. Now I use it to generate preview images for my blog posts and more.

    One of my favorite side projects: turning my child’s beloved stuffed animal (a birth gift) into custom chat stickers. Inspired by a viral trend of turning people into shrink-wrapped action figures, I thought: “Why not try that with objects?” I took a photo, uploaded it to ChatGPT, and asked it to stylize the face with various emotions. After downloading the results, I used my phone’s photo app to isolate and convert them into stickers. Voilà! Custom, personal stickers my friends now also use.

    💻 Coding: The Developer’s Secret Weapon

    Even as a full-time software developer, I rely on AI all the time. Knowing my strengths and weaknesses, I use AI as a sparring partner, a documentation assistant, a test writer, and even a web app generator. I’m primarily a Java developer, but recently had to work on a C# project. Thanks to the similar syntax, I managed well, but lacked familiarity with C# features.

    I used AI to discuss code samples, build conceptual bridges between Java’s Streams and C#’s LINQ, and get clarity on best practices. It wasn’t just helpful, it made me better. One example still feels strange to admit: I had AI build a job application tracker app for me and my wife. I didn’t have the time or energy to code it from scratch, so I used Bolt.new to generate the entire app in under 15 minutes. Fully hosted, ready to go. That’s not the only thing I’ve built so far: a simple QR code generator that doesn’t track users, an RSS feed reader with no algorithm (just plain, sorted by date), and many other small tools I personally benefit from.

    Now It’s Your Turn!

    So, that’s my journey, from simple prompts to deeply personal tools that enrich my family, my work, and my creativity. AI isn’t replacing me. It’s amplifying me.

    Now I’m curious: How do you use AI? Not just in theory, but in practice? Got something cool to show? I’d love to see it.

  • Bait in Social Media: Why We Take It That Easy

    Have you experienced this? You scroll through social media and stumble upon a post that makes you smile—a clever joke, an absurd observation, maybe a technical gag that hits your sense of humor. Recently, this happened to me with a post on X (formerly Twitter). Someone jokingly claimed to have found the same UUID twice—an astronomically unlikely event. The genius part: the comments played along! Lots of witty replies, everyone got the joke and kept it going. I sat grinning at my screen, thinking, “Great, this is exactly my kind of humor!”

    But then, just a day later—and of all days, on April 1st—a reaction to this topic popped up in my LinkedIn feed. But here, the tone was completely different. A post about UUIDs and potential risks seemed, at first glance, dead serious. Because of the date, I was immediately skeptical. Was this a masterful bait, designed to spark a debate? Or did the author simply misunderstand the original joke?

    The real surprise, though, was in the comments under this LinkedIn post. No trace of humor or doubt. Instead: a flood of serious replies, technical debates, detailed analyses, and worried warnings. I was stunned. How could the same topic, which sparked laughter on X, trigger such a serious avalanche on LinkedIn? Why does humor sometimes fail at the digital office door? Let’s try to get to the bottom of this phenomenon together.

    Why UUIDs (Sometimes) Aren’t a Joke

    First, an important clarification: Even though the probability of a collision with modern UUIDs (like v4) is practically zero, the topic itself isn’t entirely out of place in software. There are aspects that justify a serious discussion:

    1. Risks of older versions: UUIDv1, for example, is based on timestamps and MAC addresses, making them theoretically more predictable and, under certain circumstances, vulnerable.
    2. The fallacy of “security by obscurity”: A common mistake is treating UUIDs as secret keys that protect a resource by their complexity alone. That’s dangerous! If the URL with the UUID leaks (via logs, leaks, etc.), the door is wide open if there’s no real authorization check behind it. Security experts warn about this all the time.

    So, a post—even on April 1st—that touches on these real, if sometimes exaggerated, concerns can easily spark serious debate, even if it started as a joke or bait. That makes it harder for professionals to instantly dismiss as nonsense.

    Context Matters: X vs. LinkedIn

    The crucial difference is the environment—the context of each platform:

    • X (Twitter): The Playground: Here, the culture is fast, brief, and informal. Memes, sarcasm, irony, and technical jokes are daily fare. Users are primed to read between the lines and not take everything seriously. The “X” context almost whispers: “Relax, could be a joke.”
    • LinkedIn: The Digital Office: This platform is a professional showcase. It’s about expertise, networking, and (supposedly) serious technical exchange. The tone is more formal and earnest. A post about databases, security, or UUIDs is seen as a prompt for technical discussion. People want to show competence, share knowledge, maybe even correct others. Jokes often bounce off the professional facade.

    On LinkedIn, people might not “get” the joke because they’re in “business mode.” They’re looking for useful information and chances to demonstrate expertise. Even the date (April 1st) often isn’t enough to break the platform’s deeply ingrained expectations.

    Why We’re So Easily Fooled: A Look Inside Our Heads

    But it’s not just about the platform. Our own psychology often tricks us, making us prone to misunderstandings or manipulation:

    • Halo effect: We tend to trust people we see as authorities or experts (e.g., impressive titles on LinkedIn, lots of followers, eloquent language). Their statements are questioned less—even if they’re just repeating a joke.
    • Confirmation bias: Maybe you’ve had vague concerns about UUID security? A post that (seemingly) confirms that worry hits home. We unconsciously seek info that supports our existing beliefs.
    • The pull of the crowd (conformity): The first serious comments set the tone. Others read them and join in—to fit in, seem competent, or just because they assume the majority must be right. Especially in professional contexts, no one wants to be the one who dismisses a potential security warning as a joke. This creates a cascade of seriousness.
    • The art of bluffing: Some people are masters at appearing competent and convincing, even if there’s little substance. They juggle jargon, seem confident, and can easily draw others in—or wrap an April Fools’ “bait” so well that it seems real.

    Joke, Bait, or Real Confusion on April 1st?

    So what was the LinkedIn post? A misunderstood joke? A deliberate bait for engagement? A genuine post by someone who missed the X humor? Or an exaggerated but real warning that just happened to be posted on the wrong day?

    We can’t say for sure. But the reaction—the wave of serious comments—is the real lesson. It shows how strongly platform expectations and psychological effects shape our perception and can make us ignore obvious context clues (like the date or the topic’s origin).

    Sharpening Your Critical Eye

    Skepticism is always important! It’s your best ally when dealing with information online. Here are some tips to sharpen your inner “bluff detector”:

    • Context is everything: Who’s writing? On what platform? When was it posted (date!)? What’s the usual tone?
    • Pause before reacting: Especially with posts that trigger strong emotions (agreement, anger, surprise), take a moment. Don’t jump on the bandwagon.
    • Check plausibility: Does the claim sound logical and realistic? For technical topics: Is the problem really as serious as described, or maybe exaggerated? A quick web search (e.g., “UUID collision probability”) could reveal the original joke.
    • Question motivation: Why is someone sharing this? Is it about knowledge, entertainment, provocation, pure engagement, or self-promotion?
    • Trust your gut: If something feels off, no matter the topic, take that feeling seriously. It’s often a good reason to look closer and be more critical.

    Ultimately, this example perfectly shows how the digital world works—or sometimes doesn’t work. Platform culture shapes our expectations, and our psychology makes us prone to certain patterns. The best defense? A healthy dose of skepticism, a willingness to check context, and the courage to think against the current of the comments. Stay critical!

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.

  • Legacy Software: Burden or Valuable Heritage?

    Legacy software is often dismissed as outdated, but what’s really behind it? What does it actually mean for software to be “legacy”? Is it automatically a bad thing? What challenges do these systems bring—and should you act immediately? This article explores the definition, challenges, and opportunities of legacy systems and outlines strategic approaches for dealing with them.

    What is Legacy Software?

    Legacy software refers to systems still in use but made difficult to adapt due to outdated technologies, architectures, or lack of maintenance. Age alone doesn’t make software “legacy.” Three factors are crucial:

    • Business-critical function: The system is essential for operations.
    • Technical rigidity: Old technologies or monolithic architectures make changes hard.
    • Pressure to change: New requirements (like compliance or security) demand updates the system can’t efficiently support.

    A practical example: A Java application running version 8 (end of life: 2030) with 500,000 lines of code, unchanged since 2012, is considered legacy—even if it works flawlessly.

    Is Legacy Always Bad?

    Not necessarily! Legacy systems often offer:

    • Stability: Many run for decades without major issues. For example, IBM’s COBOL-based CICS platform has processed 30 billion transactions daily since 1968 without outages.
    • Embedded business knowledge: These systems are tailored to a company’s needs and support critical processes, often containing valuable domain expertise.
    • Familiarity and integration: Employees are efficient with these systems, and they are deeply woven into the IT landscape.

    The Problems

    • Security risks: Legacy systems are vulnerable to cyberattacks due to missing updates and outdated tech. The 2017 WannaCry attack hit many companies using old Windows versions.
    • High maintenance costs: Specialized skills and old hardware are expensive to maintain. Companies spend millions annually on support and parts, tying up resources that could go to innovation.
    • Limited flexibility: Monolithic legacy systems are hard to integrate with modern IT (cloud, APIs), leading to data silos and slow adaptation to change.

    Why Do You Need Specialists?

    • Obsolete frameworks: Many legacy systems use outdated frameworks (like Struts or old Spring versions) with poor documentation, requiring deep expertise.
    • Lack of documentation: Changes were often made directly in code, making onboarding and modifications time-consuming and error-prone.
    • Custom solutions: Proprietary code tailored to specific business needs is rarely standardized and hard to modernize.

    Maintenance and Modernization

    Legacy maintenance involves more than just code:

    • Security updates: Often missing, requiring expensive support or custom patches.
    • Integration with new tech: Cloud and database migrations are complex and resource-intensive.
    • Compatibility fixes: Old systems may not work with new hardware or software, causing unexpected errors.

    Updating to newer versions (e.g., Java 21) can reduce risks and improve performance but doesn’t solve fundamental architectural issues—monoliths remain monoliths.

    How Common Are Legacy Systems?

    On average, about 31% of all systems are considered legacy, with Java-based systems above average due to their historical use in many domains.

    LanguageLegacy SystemsTypical legacy indicators
    Java40-60%Java 11 (72%), Spring 4.X
    Python12-15%Python 3.7 (18%)
    JavaScript18-22%AngularJS (54%), Node.js 17 LTS
    PHP30-50%PHP < 7.4 (30%)
    .NET30-40%.NET < 4.8

    How Long Does Software Live?

    Software lifespan depends on language and use case. For Java, distributions offer long-term support from 5 to 8 years.

    LanguageLTS Support
    Java5 to 8 years
    Python5 years
    .NET3 years
    PHP2 years

    Modernization Strategies

    Modernizing legacy systems is a balancing act between cost, stability, and innovation. Common strategies include:

    1. Code migration: Gradually replace parts of the system (Strangler Fig pattern), start from scratch (Greenfield), or migrate data/settings (Brownfield).
    2. Containerization: Move monoliths to Docker/Kubernetes or the cloud (“lift-and-shift”).
    3. API wrapping: Expose old logic via modern APIs (REST/GraphQL) to make it accessible without full migration.

    Legacy: Challenge or Opportunity?

    Legacy systems aren’t necessarily a problem—they’re a challenge and often an opportunity. They form the backbone of many companies and contain valuable knowledge. With the right strategy—stepwise modernization, containerization, modular monoliths, and stable LTS versions—legacy can become a resource, not just a burden.

    Legacy code isn’t automatically bad code. Often, systems are labeled “legacy” just because they’re not on the latest version, even if they work reliably. Ultimately, the value of code is its ability to adapt to new requirements. With the right approach, legacy systems can become valuable assets—sometimes, there’s more potential in the old than you think!

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.

  • Boring technology: Why less hype can lead to more productivity

    Do you know the feeling? You’re constantly bombarded by new frameworks and unsure whether you should switch. Sometimes the sheer variety feels paralyzing. Another cool new framework or library is released, and many are eager to use it in production right away—but should you really? This article questions the hype and shows why “boring,” proven technology is often more productive.

    The Hype Around New Technologies

    The tech industry loves innovation. New tools and frameworks are often praised as the ultimate solution for scalability, productivity, or developer happiness. But this drive for innovation comes at a cost:

    Exploding Complexity: Every new tool adds dependencies, configurations, and maintenance. Instead of solving problems, we often create new ones. As a satirical comment puts it:

    “Once it took 30 Minutes to compile your code. Nowadays, it takes 30 Minutes to download dependencies.”

    Short Lifespan of Tools: Many technologies last only a few years—or even months. What’s “state of the art” today can be outdated tomorrow. For example, AngularJS was once the darling of frontend development. Today, it’s considered legacy, and many teams had to migrate painfully.

    Fear of the Wrong Choice: The sheer number of options can paralyze us. Should you invest in Vue? Or Svelte? This uncertainty often leads developers to switch tools before they’ve even built real expertise.

    Innovation Tokens: Your Limited Resources

    Dan McKinley coined the concept of innovation tokens: every company (and developer) only has a limited amount of energy and resources for innovation. If you spend these on exotic databases, frameworks, or languages, you’ll lack capacity for real product improvements.

    This concept applies outside software too. Celebrities like Steve Jobs, Mark Zuckerberg, or Elon Musk deliberately make “boring” choices in daily life—like always wearing the same clothes—to save mental energy for what matters. This principle fits perfectly with McKinley’s idea.

    A story from Etsy illustrates this: instead of introducing a new database like Redis, the team decided to extend their existing infrastructure with Memcached. This “boring” decision paid off in the long run—it was stable and scalable without adding complexity.

    The core of this philosophy: use your innovation energy where it adds the most value—not just on tools that seem “cool.”

    What Does “Boring Technology” Actually Mean?

    At first, “boring technology” sounds negative—like stagnation or a lack of creativity. But it actually stands for:

    • Using Proven Tools: Boring technologies are those that have stood the test of time. They’re stable, well-documented, and widely used—like MySQL or Java.
    • Focus on Simplicity: Instead of constantly introducing new tools, boring technology consolidates and reuses existing systems. This reduces complexity and makes maintenance and onboarding easier.
    • Sustainability Over Hype: It’s about building systems that work long-term—not those that need rewriting after a year.

    The Cost of Hype

    Modern software development suffers from a paradox: even as our tools become more powerful, productivity doesn’t always rise. Studies show developers spend a significant part of their time on non-functional tasks—like configuring CI/CD pipelines, managing dependencies, and automating infrastructure. For example, Stripe estimates that developers worldwide spend 42% of their work time on maintenance, debugging, and other non-productive tasks.

    Often, before you write a single line of functional code, you have to set up linters, maintain YAML files, and perform other “industrial rituals.” These processes may be necessary—but they add little direct value.

    Polyglot Persistence: A Warning Sign

    Another example of excessive complexity is polyglot persistence—using different specialized databases for different tasks (e.g., MongoDB for documents, Redis for caching). While this can make sense at first, it often leads to:

    • Higher operational costs (each database requires specialized knowledge and maintenance)
    • Fragmented knowledge (teams lose track of the whole system)
    • Scaling issues (what works locally can become a bottleneck globally)

    How to Apply Boring Technology

    Here are some concrete tips:

    • Use mature technologies: pick tools that have been on the market for at least five years and have well-known failure modes.
    • Reduce your stack: less is more—consolidate your tech stack and avoid unnecessary dependencies.
    • Document decisions: record why certain technologies were chosen—not just how they work.
    • Focus on what matters: use your innovation energy where it brings real value, like solving customer problems.

    Less Hype, More Focus

    The philosophy of boring technology isn’t a step backward—it’s an argument for sustainability and efficiency in a field often driven by its own love of innovation.

    That doesn’t mean standing still or staying in your comfort zone! Openness to change remains important—but not every new framework or tool justifies an immediate switch.

    So, next time you wonder if you really need to try the latest framework, remember: the best technology is often the one that just works and has your back. Or, in McKinley’s words:

    “This is what you should do, most of the time. Prefer technology that’s well understood, with failure modes that are known.”

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.

  • Why the “best” programming language (usually) doesn’t matter

    Do you know this feeling? You scroll through LinkedIn, Medium, dev.to, Reddit, or even Instagram and—bam—another post tells you why this one language or framework is the absolute best. Everything else? Outdated, slow, insecure, or just plain trash. It reminds me of endless debates about the best music genre, the best car, or the best anime. Tastes and, more importantly, requirements differ—and nowhere does this lead to more heated discussions than in our tech bubble.

    Lately, I feel like I’m landing more and more in this “bashing bubble,” where it’s all about defending your favorite language and putting others down. It’s annoying. That’s why I want to share my observations and a few thoughts with you today. Because I think we waste way too much energy on these fake battles.

    Why all the noise on social media?

    In the past, these discussions might have happened at the pub, at conferences, or in university seminars. Today, we have global platforms where everyone can share their opinion—and algorithms love controversy. A post titled “Why Java is dead” or “JavaScript is the only future” simply gets more clicks and engagement than a nuanced article about the pros and cons of different technologies in specific contexts.

    This leads to an echo chamber effect: you follow people who confirm your own opinion, and the platforms show you more of the same. It creates a distorted picture, a kind of “us vs. them” mentality that has more to do with fan culture than with professional discourse.

    Were things better in the past? A quick look back

    But have these “language wars” always existed? Yes, in some way, they have. Even in the early days of computer science, there were rivalries. Think of the 1950s and 60s: Fortran for science, COBOL for business, Lisp for AI research. Each language had its domain and its fans. Later, there were heated debates between C and Pascal, or the US Department of Defense’s efforts to bring order to the chaos of hundreds of languages with Ada.

    The main difference today is the volume and reach enabled by social media. The arguments are often the same, but now they’re fought out globally and in real time.

    Diversity isn’t a bug, it’s a feature!

    Why are there so many programming languages? Because there are countless different problems to solve! Think of your toolbox: you have a hammer for nails, a screwdriver for screws, pliers for gripping. You wouldn’t try to hammer a nail with pliers, right?

    It’s the same with programming languages. Each has its strengths and weaknesses, its “sweet spots”:

    • JavaScript: Essential for interactive web frontends, strong on the backend with Node.js.
    • Python: Super readable, huge community, strong in data science, machine learning, and scripting.
    • Java: Robust, platform-independent (JVM), huge ecosystem, widely used in large companies for backend systems. (Yes, I like Java 😅)
    • C#: Microsoft’s answer to Java, strong in the Windows world, now cross-platform thanks to .NET Core, popular for game development (Unity).
    • C/C++: Close to the hardware, unbeatable performance, foundation for operating systems, game engines, embedded systems.
    • Swift/Kotlin: Modern languages for native iOS and Android development.
    • PHP: Still powers a huge part of the web (WordPress!), has evolved a lot (thanks to Laravel).
    • Go/Rust: More modern languages; Go is great for concurrent systems, Rust focuses on safety and performance without a garbage collector.

    The list goes on (Ruby, Scala, TypeScript…). Look at the TIOBE or PYPL index: the top 20 are all relevant and used successfully. This shows: there’s no single best language, just many good tools for different jobs.

    When the choice (maybe) matters

    Okay, the choice isn’t always totally irrelevant. There are scenarios where some languages are simply a better fit or others are less suitable:

    • Performance-critical system programming: C or C++ are often the first choice.
    • Client-side web development: Not much works in the browser without JavaScript (or languages that compile to it, like TypeScript).
    • Massively parallel computing: Languages with good concurrency models like Go or Erlang shine here. Python can hit its limits here (though there are workarounds).
    • Data Science / ML: Python is the de facto standard thanks to libraries like NumPy, Pandas, Scikit-learn, TensorFlow, and PyTorch.

    But even here, it’s more about “unsuitable” vs. “suitable,” not the subtle difference between two generally appropriate languages. No one would seriously use Java for a browser extension or try to write an operating system in PHP.

    What really matters: Beyond syntax

    If the language itself often isn’t the deciding factor, what is more important? In my experience, these points matter more:

    1. You and your team: How well do you know the language and its ecosystem? A team that knows Java and Spring Boot inside out will likely deliver faster and better than with the “hottest” new framework that everyone still has to learn. Productivity and know-how are gold.
    2. The ecosystem: How good are the available libraries, frameworks, and tools? Is there an active community? Is it easy to get help? A strong ecosystem can massively speed up development.
    3. The specific task: What exactly should the software do? What are the non-functional requirements (performance, scalability, security)? The language needs to be able to solve the problem.
    4. Maintainability & Clean Code: Can you write clean, well-structured, maintainable code with the language and chosen tools? This often depends more on the developers and established practices than the language itself. (A topic close to my heart as a Clean Code fan!)
    5. Company context: Are there existing systems? What technologies are already in use? Sometimes consistency within the IT landscape is more important than optimizing for the “perfect” language for a single project.
    6. Long-term support: Will the language or framework likely be maintained and developed in the future?

    You see: language choice is just one factor among many—and often not even the most important.

    My tip: Stay curious, but pragmatic!

    Instead of getting stuck in trench wars over which language is “better,” maybe we should focus on other things:

    • Master your tool: Whether it’s Java, Python, C#, or JavaScript—get really good at it. Understand the concepts, strengths, and weaknesses.
    • Learn the principles: Concepts like Clean Code, SOLID, design patterns, and test automation are language-independent and make you a better developer, no matter what tool you use.
    • Be curious: Look beyond your own stack! Try another language or a new framework. It broadens your horizons and may help you discover patterns and solutions you wouldn’t see in your “home language.” (I struggle with frontend myself, but maybe I should give TypeScript a real chance?)
    • Focus on the problem: Ultimately, it’s about solving a problem for the user or the business. Technology is a means to an end, not an end in itself.
    • Respect other choices: Just because another team uses a different technology doesn’t mean they’re wrong. Maybe they had different requirements, prior knowledge, or constraints.

    So don’t let the noise on social media drive you crazy. Most common programming languages are great tools for building amazing things. Choose wisely, based on your requirements and context, but don’t waste energy defending your choice as the only right one. Let’s focus on writing good software and learning from each other.

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.

  • Types of Software Developers – A Humorous Look at Our Diversity

    In my ten years as a software developer, I’ve seen many different types of developers. Some are very young and excited to write lots of code, no matter the quality. Others are experienced veterans who plan everything in detail before writing a single line of code. Some developers stand out with unique traits, and sometimes the same person can act differently on different days. We developers are versatile, and I’ve listed the most typical characteristics for you. Please take it with a sense of humor.

    The Coding Cowboy

    The Coding Cowboy is the hero in a crisis—at least in his own eyes. When a deadline is tight, he rides in and delivers quick results, often ignoring rules or standards. His motto: “If it works, it’s good enough!” Unfortunately, he often leaves behind a code wild west that others have to clean up later.

    Traits:

    • Works quickly and improvises
    • Ignores best practices
    • Convinced that “small PRs are just theory”

    The Coding Dinosaur

    This developer is a veteran with 25+ years of experience and knows every detail of their favorite programming language—probably was there when it was born. Modern frameworks and tools often seem like unnecessary “bells and whistles” to them.

    Traits:

    • Deep knowledge of legacy systems
    • Skeptical of new technologies
    • Loves telling stories from the “good old days”

    The Coding Ninja

    The Ninja is efficient, precise, and works in the shadows. They complete tasks with minimal effort and surprise the team with unexpected solutions—often outside the official backlog.

    Traits:

    • Works alone and with focus
    • Checks in perfect code at 4 a.m.
    • Master of secret operations

    The Coding Evangelist

    The Evangelist is a champion of clean code, design patterns, and architectural principles. They passionately fight for their “coding religion” and turn every pull request into an epic battle for perfection.

    Traits:

    • Endless discussions about standards
    • Demands flawless code
    • The final boss of every code review

    The Coding Wizard

    The Wizard is a true guru. Their magical skills make them a legend in the team. They code effortlessly and without external help—their head is the documentation.

    Traits:

    • Needs no tutorials or Stack Overflow
    • Creates solutions that seem like magic
    • Reverently called the “jack of all trades” by colleagues

    The Coding Hobo

    The Hobo lives off copy-paste—from Stack Overflow or AI-generated snippets. They only adjust parameters and names, sometimes not even changing the comments.

    Traits:

    • Uses code snippets without deep understanding
    • Often leaves chaotic traces in the project
    • Master of pragmatic minimalism

    The Coding Greenfielder

    The Greenfielder loves starting new projects—a green field with no legacy code is their dream. Existing code is often labeled as “legacy” and best thrown away. They thrive when creating something new, but often lack patience for existing systems.

    Traits:

    • Prefers projects without legacy code
    • Little interest in existing code
    • Has at least 13 side projects (none finished)

    The Coding Planner

    The Planner needs to sketch everything out and visualize connections between functions. Even for the smallest solutions, this process must be strictly followed. Sometimes, they forget to actually implement the code while doing all the planning.

    Traits:

    • Always has three pens and paper at their desk
    • Drawing tools have shortcuts and keybindings
    • Beginners avoid them in a wide arc

    A Humorous Look at Our Diversity

    Software teams thrive on diversity—everyone brings their own strengths (and weaknesses). These archetypes are, of course, meant with humor and show the variety of personalities in developer teams. Maybe you recognize yourself or your colleagues in these descriptions? Which type are you? Or have you discovered other characters? Where would you a vibe coder align?

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.

  • Password Security: History, Myths, and Modern Approaches

    Passwords are a central part of our digital lives. Even in the Star Wars universe, codes and passwords play a crucial role: In Return of the Jedi, Han Solo and his team approach the second Death Star in a stolen Imperial shuttle. When Imperial officers check their credentials, one says: “It’s an older code, sir, but it checks out.” This moment highlights a timeless security risk-relying on outdated or weak codes can have serious consequences, whether you’re defending a galaxy or your own data. Yet despite their importance, there are countless misunderstandings and poor practices around passwords. In this article, we’ll look at the history of passwords, highlight important initiatives like “World Password Day,” and analyze modern approaches to improving password security.

    Ancient Origins

    Passwords aren’t a digital invention. Even in ancient times, they were used to control access to military or secret areas. A famous example is the biblical “Shibboleth,” used to identify friend or foe. The Romans also used “watchwords” to secure their troops.

    The First Digital Password

    The first digital password was created in 1961 by Fernando Corbató at MIT. He introduced the concept in the Compatible Time-Sharing System (CTSS) to allow multiple users secure access to a shared computer. Interestingly, just two years later, the system was hacked when a user printed out the password files and accessed other accounts.

    Key Initiatives: Change Your Password Day & World Password Day

    Change Your Password Day

    Started in 2012 by Matt Buchanan after he was hacked, this day is observed every February 1st to encourage users to update passwords regularly and use stronger measures like two-factor authentication (2FA).

    World Password Day

    Held on the first Thursday in May each year, this initiative was inspired by security expert Mark Burnett, who suggested a day to raise password security awareness in his book “Perfect Passwords” (2005). Intel officially established World Password Day in 2013.

    Password Security: Myths and Facts

    Myth: Complexity is Key

    Many believe that passwords with special characters like “Tr0ub4dor&3” are especially secure. But the famous XKCD comic shows these often only have about 28 bits of entropy and are easy to crack-plus, they’re hard to remember. A longer passphrase like “correct horse battery staple” offers 44 bits of entropy, is more secure, and easier to remember.

    Fact: Length Beats Complexity

    The length of a password is more important than its complexity. A long password or passphrase increases the number of possible combinations exponentially, making it harder for attackers to crack.

    Myth: Frequent Changes Increase Security

    It used to be recommended to change passwords regularly. Today, we know this is often counterproductive: users fall back on predictable patterns, like “123456#2024” → “123456#2025.” Passwords should only be changed if there’s suspicion of compromise-or if a password manager can generate a new one.

    Fact: Password Policies Are Outdated

    Many websites still require short, complex passwords instead of long, memorable ones. For example:

    • Meta: 6 characters, 1 special, 1 letter, 1 number
    • Sparkasse: 8 characters, 1 special, 1 letter, 1 number
    • Google: 8 characters, 1 special, 1 letter, 1 number
    • LinkedIn: 8 characters, 1 special, 1 letter, 1 number
    • Amazon: 8 characters (even “11111111” is accepted)

    Fact: Many Passwords Are Still Stored in Plaintext

    Just last year, a misconfigured cloud database exposed nearly 20 million passwords in plaintext. The “rockyou2024.txt” leak is another recent example. Many companies use default configurations that allow plaintext storage, and sometimes memory dumps can be read, as shown by the CCC in late 2024. There’s even a “plaintextoffenders” list of companies that have stored passwords in plaintext at some point.

    Real-World Challenges

    Many people use the same password for multiple accounts or slight variations like “123456#fb” for Facebook and “123456#gm” for Gmail. This increases the risk of credential stuffing, where stolen credentials from one site are used on others, fun fact: “starwars” is the 110th most used password in 2024.

    The sheer number of accounts leads to “password fatigue.” To avoid remembering endless combinations, users turn to insecure practices like reusing simple passwords.

    We developers share some blame. Many of us, under time pressure, rely on default security settings in frameworks, which are often inadequate and lack modern cryptography. There’s also a lack of knowledge about secure coding and current standards, which leads to vulnerabilities. Legacy software makes things worse, using outdated tech that doesn’t support modern encryption or multi-factor authentication. Better training in secure software development is essential to minimize these risks.

    Modern Approaches to Security

    Password Managers

    A password manager can create and store secure, unique passwords for every account. This removes the need to remember complex combinations. Before moving your passwords to a manager, check their security-many offer this feature. Lists of the most-used passwords in different countries show that people often use hobbies, politics, or their own name. Data breaches can expose these details. Sites like “Have I Been Pwned” let you check if your data has been leaked-or if someone else uses your password.

    Multi-Factor Authentication (2FA)

    2FA adds another layer-like an SMS code or biometric data. Microsoft says 99.9% of attacks can be prevented with 2FA.

    Passkeys: The Passwordless Future

    Passkeys use cryptographic key pairs and eliminate the need for traditional passwords. They protect against phishing and data leaks, since no shared secrets are stored.

    Lessons from the Past – Solutions for the Future

    The history of passwords shows their evolutionary weaknesses-from simple watchwords to complex digital combos. Modern tech like 2FA and passkeys offer promising alternatives.

    Recommendations for Users:

    • Use a password manager.
    • Choose long passphrases over complex combos.
    • Enable multi-factor authentication.
    • Change passwords only if needed or if compromised.

    With these measures, we can boost personal security and contribute to global cybersecurity-a challenge that’s only growing in our digital world. May the fourth be with you!

    ℹ️ This post was created in collaboration with pep.digital GmbH. The content was produced as part of my professional work and is shared here with permission.