Forem: ludovic dillieux

The Language Choice Dilemma: Between Pragmatism and Development Joy

ludovic dillieux — Mon, 08 Sep 2025 19:15:14 +0000

After several years juggling between PHP, Python, and Java in my career, I find myself facing a reality that many developers know well: the gap between what I use at the office and what I choose for my personal projects. This experience has led me to think deeply about technology choices and what really matters when developing.

My Journey: From Professional Java to Personal Laravel

Currently, I work primarily with Java in a professional context. It's a solid language, well-established, with a mature ecosystem and recognized performance. Yet, when it comes time to create my own tools and personal projects, I systematically turn to Laravel and PHP.

Why this difference? Simply because it's with Laravel that I truly enjoy developing. The elegance of the syntax, the fluidity of the workflow, the richness of the ecosystem... everything contributes to giving me that flow sensation every developer seeks.

This experience made me realize something important: pure technique isn't everything.

Comfort Before Pure Performance

There's a tendency in our field to always want to choose the "best" language for each task. The most performant, the most modern, the most trendy. But this approach forgets a crucial factor: our own comfort and expertise.

I'm convinced that it's better to choose a language you're comfortable with, even if it's not theoretically optimal for the task, rather than struggling with a technology you don't master well. Of course, there are limits to this rule — nobody's going to develop a critical embedded system in JavaScript — but in most cases, our ease with the tool matters more than its raw performance.

A fulfilled and productive developer with their preferred language will often deliver better results than a frustrated developer using the "best" technology.

Avoiding Unnecessary Complexity

This philosophy applies particularly when developing alone or in a small team. I've seen too many personal projects or startups get bogged down in over-complex architecture, chosen for its theoretical technical qualities rather than its practicality.

When you're alone at the helm of a project, simplicity becomes a cardinal virtue. Better a well-structured Laravel monolith than a microservices architecture in Kubernetes if you don't have the time or team to maintain it properly.

Technical complexity should respond to a real need, not to a desire to write beautiful code or follow the latest trends.

The Importance of Joy in Development

The joy of developing isn't a luxury, it's a success factor. When you love what you do, several things happen naturally:

You're more creative: solutions emerge more easily
You're more productive: code flows naturally
You learn better: you spontaneously dig into aspects that intrigue you
You persevere: when facing difficulties, motivation remains intact

That's why I recommend choosing your language first by personal affinity, then adapting to specific technical constraints when they really present themselves.

Staying Curious Without Following Every Trend

This doesn't mean you should lock yourself in your comfort zone. Curiosity remains essential in our profession. But there's a difference between discovering new tools out of genuine interest and adopting every novelty out of fear of missing out.

Take GitHub Actions, which I plan to integrate into my next project. I'm not adopting it because it's trendy, but because it addresses concrete needs: automating deployments, running tests on every commit, managing releases properly...

The key is to stay open to tools that bring concrete value to our workflow, not to those that just make noise on Twitter.

Some Practical Advice

🎯 For Choosing Your Main Language

Test several languages on small projects
Observe which one makes you naturally most productive
Consider the ecosystem and community, not just the syntax
Don't underestimate the importance of documentation and learning resources

🔍 For Evaluating New Tools

First identify a concrete problem in your workflow
Test the tool on a non-critical project
Evaluate the learning cost vs. the benefit provided
Ask yourself if you'll really use this tool in 6 months

🚀 For Avoiding Over-complexity

Start simple, complexify only when necessary
Favor solutions you know how to maintain
Document your technical choices to remember why you made them
Don't be ashamed to use "simple" solutions if they work

Conclusion: Own Your Choices

In the end, there's no perfect choice when it comes to programming languages. There are choices adapted to a context, a team, a project, and especially to a person.

I completely own my choice of Laravel for my personal projects, even if it's not the most performant or trendy language. It allows me to create quickly and with pleasure, and that's exactly what I need.

The most important thing is to choose consciously, weighing the real criteria that matter for your situation: your expertise, your constraints, your objectives, and yes, your joy of developing.

Because at the end of the day, a good developer with their favorite tools will always be worth more than a frustrated developer with the "best" tools.

What about you? How do you choose your languages and tools? Do you prioritize technical performance or your development comfort?

Drop a comment below and let's discuss! 👇

5 Laravel Migration Mistakes That Cost Me 3 Days (And How You Can Avoid Them)

ludovic dillieux — Thu, 14 Aug 2025 10:52:32 +0000

Learning Laravel while building a real beekeeping app taught me these lessons the hard way.

Last week, I spent 3 frustrating days debugging migration issues while building BeeNote, my beekeeping management app. What should have been a simple database setup turned into a PostgreSQL nightmare.

Here are the 5 mistakes that cost me the most time – and the solutions that finally worked.

1. The Duplicate Index Trap 🪤

The Mistake:

Schema::create('photos', function (Blueprint $table) {
    $table->morphs('photoable'); 
    $table->index(['photoable_type', 'photoable_id']); // DUPLICATE!
});

The Error:

SQLSTATE[42P07]: Duplicate table: relation "photos_photoable_type_photoable_id_index" already exists

The Fix:
Laravel’s morphs() method automatically creates the index. Don’t add it manually.

Schema::create('photos', function (Blueprint $table) {
    $table->morphs('photoable'); // Index created automatically
    $table->index('ordre'); // Only additional indexes
});

Time saved: 4 hours of PostgreSQL debugging.

2. Wrong Data Types for GPS Coordinates 🗺️

The Mistake:

$table->float('latitude');  // Precision loss!
$table->float('longitude'); // Your beehives will "move" 10 meters

The Fix:

$table->decimal('latitude', 10, 8);  // 47.12345678 - exact precision
$table->decimal('longitude', 11, 8); // -1.23456789 - no drift

When you’re tracking beehive locations, 10-meter precision errors aren’t acceptable.

3. Forgetting Business Logic in ENUMs 📝

The Mistake:

$table->string('queen_color'); // Free text = chaos
// Users input: "blue", "Blue", "BLUE", "bleu", "azul"...

The Fix:

$table->enum('couleur_marquage_reine', [
    'blanc', 'jaune', 'rouge', 'vert', 'bleu'
])->nullable(); // International beekeeping color code

Real beekeeping uses standardized queen marking colors. Research your domain!

4. Performance Killer: Missing Composite Indexes 🐌

The Problem:
50ms query time on 10k+ records because I didn’t think about real-world usage patterns.

The Solution:

// Users frequently filter by: their tasks + status
$table->index(['user_id', 'statut']); // Composite index

// Query time: 50ms → 2ms

Think about your WHERE clauses before you have performance problems.

5. Wrong Cascade Strategy = Data Loss 💥

The Mistake:

$table->foreignId('visite_id')
      ->constrained()
      ->onDelete('cascade'); // DESTROYS history!

The Fix:

$table->foreignId('visite_id')
      ->constrained()
      ->onDelete('set null'); // Keeps history, breaks link

When a visit gets deleted, I want to keep the task history – just remove the connection.

The Real Learning: Domain Knowledge Matters

Building BeeNote taught me that migrations aren’t just technical – they tell the story of your business logic.

My visits table has 47 columns because beekeeping is complex:

Weather conditions affect bee behavior
Queen marking follows international standards
Varroa mite counts determine treatment timing
etc.

The technical complexity reflects the real-world complexity.

What’s Next?

These 5 mistakes were just the beginning. I documented the complete migration journey – including the full PostgreSQL schema, performance optimizations, and why I chose VILT stack over TALL stack for this project.

→ Read the full technical deep-dive here (warning: it’s detailed, includes all the code, and explains the beekeeping business logic behind each decision)

Currently building this in public as I transition from employee to freelance Laravel developer. Following my progress? Find me on X/Twitter @Llieudi.

What migration mistakes have cost you the most time? Drop them in the comments – let’s learn from each other’s pain! 😅