Jonathan Lalou's Blog

Posts Tagged ‘SoftwareCraftsmanship’

Lecturer

Hadi Hariri stands at the intersection of technical depth and human insight as a developer, speaker, podcaster, and Technical Evangelist at JetBrains. For over a decade, he has traversed the global conference circuit, challenging audiences to confront uncomfortable truths about their profession. A published author and frequent contributor to developer publications, Hadi brings a rare blend of architectural expertise and communication clarity. Based in Spain with his wife and three sons, he leads the .NET Malaga User Group and holds prestigious titles including ASP.NET MVP and Insider. Yet beneath the credentials lies a relentless advocate for software as a human endeavor — not a technological one.

Abstract

This is not a technical talk. There will be no code, no frameworks, no live demos. Instead, Hadi Hariri delivers a searing, unfiltered indictment of the modern developer psyche. We proclaim ourselves misunderstood geniuses, central to business success yet perpetually underappreciated. We demand the latest tools, resent managerial oversight, and cloak personal ambition in the language of craftsmanship. But what if the real problem is not “them” — it’s us?

Through sharp wit, brutal honesty, and relentless logic, Hadi dismantembles the myths we tell ourselves: that communication is someone else’s job, that innovation resides in syntax, that our discomfort with business priorities justifies disengagement. This session is a mirror — polished, unforgiving, and essential. Leave your ego at the door, or stay seated and miss the point.

The Myth of the Misunderstood Genius

We gather in echo chambers — conferences, forums, internal chat channels — to commiserate about how management fails to grasp our brilliance. We lament that stakeholders cannot appreciate the elegance of our dependency injection, the foresight of our microservices, the purity of our functional paradigm. We position ourselves as the unsung heroes of the digital age, laboring in obscurity while others reap the rewards.

Yet when pressed, we retreat behind JIRA tickets, estimation buffers, and technical debt backlogs. We argue passionately about tabs versus spaces, spend days evaluating build tools, and rewrite perfectly functional systems because the new framework promises salvation. We have mistaken activity for impact, novelty for value, and personal preference for professional necessity.

Communication: The Silent Killer of Influence

The single greatest failure of the developer community is not technical — it is communicative. We speak in acronyms and abstractions: DI, IoC, CQRS, DDD. We present architecture diagrams as if they were self-evident. We say “it can’t be done” when we mean “I haven’t considered the trade-offs.” We fail to ask “why” because we assume the answer is beneath us.

Consider a simple feature request: “The user should be able to reset their password.” A typical response might be: “We’ll need a new microservice, a message queue, and a Redis cache for rate limiting.” The business hears cost, delay, and complexity. What they needed was: “We can implement this securely in two days using the existing authentication flow, with an optional enhancement for audit logging if compliance requires it.”

The difference is not technical sophistication — it is empathy, clarity, and alignment. Until we learn to speak the language of outcomes rather than implementations, we will remain marginalized.

The Silver Bullet Delusion

Every year brings a new savior: a framework that will eliminate boilerplate, a methodology that will banish chaos, a cloud service that will scale infinitely. We chase these mirages with religious fervor, abandoning yesterday’s solution before it has proven its worth. We rewrite backend systems in Node.js, then Go, then Rust — not because the business demanded it, but because we read a blog post.

This is not innovation. It is distraction. It is the technical equivalent of rearranging deck chairs on the Titanic. The problems that truly matter — unclear requirements, legacy constraints, human error, organizational inertia — are immune to syntax. No process can compensate for poor judgment, and no tool can replace clear thinking.

Value Over Vanity: Redefining Success

We measure ourselves by metrics that feel good but deliver nothing: lines of code written, test coverage percentages, build times in milliseconds. We celebrate the deployment of a new caching layer while users wait longer for search results. We optimize the developer experience at the expense of the user experience.

True value resides in outcomes: a feature that increases revenue, a bug fix that prevents customer churn, a performance improvement that saves server costs. These are not glamorous. They do not trend on Hacker News. But they are the reason our profession exists.

Ask yourself with every commit: Does this make someone’s life easier? Does it solve a real problem? If400 If the answer is no, you are not innovating — you are indulging.

The Privilege We Refuse to Acknowledge

Most professions are defined by repetition. The accountant reconciles ledgers. The lawyer drafts contracts. The mechanic replaces brakes. Day after day, the same patterns, the same outcomes, the same constraints.

We, by contrast, are paid to solve novel problems. We are challenged to learn continuously, to adapt to shifting requirements, to create systems that impact millions. We work in air-conditioned offices, collaborate with brilliant minds, and enjoy flexibility that others can only dream of. We are not underpaid or underappreciated — we are extraordinarily privileged.

And yet we complain. We demand ping-pong tables and unlimited vacation while nurses work double shifts, teachers buy school supplies out of pocket, and delivery drivers navigate traffic in the rain. Our discomfort is not oppression — it is entitlement.

Innovation as Human Impact

Innovation is not a technology. It is not a framework, a language, or a cloud provider. Innovation is the act of making someone’s life better. It is the medical system that detects cancer earlier. It is the banking app that prevents fraud. It is the e-commerce platform that helps a small business reach new customers.

Even in enterprise software — often derided as mundane — we have the power to reduce frustration, automate drudgery, and free human attention for higher purposes. Every line of code is an opportunity to serve.

A Call to Maturity

The prima donnas of the 21st century are not the executives demanding impossible deadlines. They are not the product managers changing requirements. They are us — the developers who believe our discomfort entitles us to disengagement, who confuse technical preference with professional obligation, who prioritize our learning over the user’s needs.

It is time to grow up. To communicate clearly. To focus on outcomes. To recognize our privilege and wield it responsibly. The world does not owe us appreciation — it owes us the opportunity to make a difference. Let us stop wasting it.

Links

• Video of the lecture
• Hadi Hariri on Twitter
• JetBrains Developer Advocacy

Lecturer

Pierre Pezziardi has built a career as an entrepreneur and innovator in technology and finance, co-founding OCTO Technology and the Université du SI, as well as launching Octopus Microfinance and NotreBanque. His work promotes “convivial informatics”—systems that break down organizational silos, empower individuals, and support self-organizing teams. In 2005, Pierre initiated Octopus, an open-source platform for microfinance that fosters global collaboration on lean and agile methods to improve financial access for the underprivileged. He contributed to BabyLoan, France’s first peer-to-peer microcredit operator. From 2010, as CIO at Bred Banque Populaire, he applied lean techniques to banking. Since 2011, Pierre has led NotreBanque, developing affordable, transparent community financial tools.

Abstract

Pierre Pezziardi probes the role of developers in contemporary enterprises, questioning whether the profession garners the respect it deserves amid perceptions of high costs and limited value. He traces the historical evolution from artisanal coding to industrialized processes, critiquing how this shift has diminished developer autonomy and innovation. Through analogies to manufacturing and personal anecdotes, Pezziardi advocates for lean principles, self-organization, and cultural shifts to restore pride in development. The presentation analyzes systemic issues like productivity stagnation and organizational silos, proposing methodologies that empower developers as key innovators in business success.

The Developer’s Image: Perceptions and Realities in Enterprise

Pierre Pezziardi opens by addressing the awkwardness developers often feel when describing their profession, noting the common reaction of polite disinterest or skepticism from non-technical interlocutors. He posits that this stems from informatics’ reputation as expensive, delayed, and often unhelpful in real business contexts. Pezziardi argues this image is not unfounded, rooted in double exhaustion: declining productivity in large systems and outdated organizational models ill-suited to modern technology.

He explains productivity stagnation: marginal costs for new features rise due to legacy complexity, while organizational exhaustion manifests in siloed structures that hinder collaboration. Pezziardi draws historical parallels to the industrial revolution, where artisanal crafts gave way to assembly lines, similarly in software where developers became cogs in bureaucratic machines.

Pezziardi’s methodology involves reflective questioning: why do developers hesitate to claim their role? He suggests it’s because enterprises view informatics as a cost center rather than a value creator, leading to undervaluation.

Historical Evolution: From Artisanal to Industrialized Development

Pezziardi traces software’s trajectory from the 1960s, when programmers crafted bespoke solutions on punch cards, to today’s industrialized processes. He critiques the “software factory” model, where specialization fragments work—analysts specify, coders implement, testers verify—mirroring Taylorist principles.

This fragmentation, Pezziardi analyzes, breeds inefficiency: specifications become outdated, leading to rework and delays. He contrasts this with lean manufacturing’s origins in Toyota, where empowered workers halt lines to fix issues, fostering continuous improvement.

Pezziardi’s personal anecdote from banking illustrates: implementing lean reduced delivery times from months to weeks by involving developers in business decisions, eliminating wasteful handoffs.

Implications: traditional models stifle innovation; lean empowers developers as problem-solvers, aligning with agile’s emphasis on cross-functional teams.

Lean Principles: Empowering Developers Through Autonomy and Collaboration

Pezziardi advocates lean as a remedy, rooted in eliminating waste (muda) and respecting people. He details principles like just-in-time production and jidoka (automation with human intelligence), translating to software as iterative development and automated testing.

He analyzes waste types: overproduction (unused features), waiting (delays in reviews), defects (bugs). Pezziardi proposes solutions: small batches, continuous integration, pair programming.

Pezziardi stresses cultural shifts: from hierarchical control to self-organization, where teams pull work and collaborate. He cites Octopus Microfinance as an example, where open-source contributions cultivate global knowledge sharing.

Methodologically, Pezziardi encourages daily practices: developers engaging marketers or accountants to understand needs, fostering empathy and efficiency.

Cultural and Organizational Shifts: Fostering Pride in Development

Pezziardi examines why developers feel undervalued: siloed roles limit impact, bureaucratic processes disconnect from users. He proposes redefining the developer as a cultivator of value, integrating business acumen with technical skill.

He analyzes geek culture’s potential: collaborative, innovative, yet often isolated. Pezziardi urges exemplifying values like humility, continuous learning, and cross-disciplinary dialogue.

Pezziardi’s narrative methodology—using humor, analogies (e.g., assembly lines)—engages to inspire change. Implications: enterprises adopting lean unlock productivity; developers gain fulfillment, transforming informatics from cost to asset.

Conclusion: Reclaiming Pride Through Convivial Informatics

Pezziardi concludes that technology outpaces culture; developers must lead by promoting convivial systems—tools empowering users, breaking silos. By embodying lean values, developers can reclaim pride, positioning themselves as pivotal to organizational success.

Links:

• Video URL
• OCTO Technology Website
• NotreBanque Initiative

Lecturers

Cyrille Martraire stands as one of the most influential figures in the French software craftsmanship movement, having co-founded Arolla, a boutique consultancy that has redefined how enterprise teams approach code quality, domain-driven design, and technical excellence. With nearly two decades of experience building mission-critical financial systems at investment banks and fintech startups, Cyrille has cultivated a philosophy that places expressiveness, readability, and long-term maintainability at the heart of software development. He is the founder of the Software Craftsmanship Paris community, a regular speaker at international conferences, and a passionate advocate for learning across technological boundaries. His ability to draw meaningful insights from seemingly disparate ecosystems—such as .NET—stems from a deep curiosity about how different platforms solve similar problems, and how those solutions can inform better practices in Java.

Rui Carvalho, a veteran .NET architect and ASP.NET MVC specialist, brings a complementary perspective rooted in over fifteen years of web development across startups, agencies, and large-scale enterprise platforms. A fixture in the ALT.NET Paris community and a recurring speaker at Microsoft TechDays, Rui has witnessed the entire arc of .NET’s evolution—from the monolithic WebForms era to the open-source, cross-platform renaissance of .NET Core and beyond. His expertise lies not merely in mastering Microsoft’s tooling, but in understanding how framework design influences developer productivity, application architecture, and long-term system evolution. Together, Martraire and Carvalho form a dynamic duo capable of transcending platform tribalism to deliver a nuanced, humorous, and technically rigorous comparison that resonates deeply with developers on both sides of the Java–.NET divide.

Abstract

This article represents a comprehensive, elaborately expanded re-interpretation of Cyrille Martraire and Rui Carvalho’s landmark 2012 DevoxxFR presentation, “.NET pour le développeur Java : une source d’inspiration ?”, transformed into a definitive treatise on the parallel evolution of Java and C# and their mutual influence over nearly three decades of enterprise software development. Delivered with wit, mutual respect, and a spirit of ecumenical dialogue, the original talk challenged the audience to look beyond platform loyalty and recognize that Java and C# have been engaged in a continuous, productive exchange of ideas since their inception. From the introduction of lambda expressions in C# 3.0 (2007) to Java 8 (2014), from LINQ’s revolutionary query comprehension to Java’s Streams API, from async/await to Project Loom’s virtual threads, the presenters traced a lineage of innovation where each platform borrowed, refined, and occasionally surpassed the other.

This expanded analysis delves far beyond surface-level syntax comparisons to explore the philosophical underpinnings of language design decisions, the ecosystem implications of framework choices, and the cultural forces that shaped adoption. It examines how .NET’s bold experimentation with expression trees, dynamic types, extension methods, and Razor templating offered Java developers a vision of what was possible—and in many cases, what Java later adopted or still lacks.

EDIT
Updated for the 2025 landscape, this piece integrates the latest advancements: C# 13’s primary constructors and source generators, Java 21’s pattern matching and virtual threads, Spring Fu’s functional web framework, GraalVM’s native compilation, and the convergence of both platforms under cloud-native, polyglot architectures. Through rich code examples, architectural deep dives, performance analyses, and forward-looking speculation, this work offers not just a historical retrospective, but a roadmap for cross-platform inspiration in the age of cloud, AI, and real-time systems.

The Shared Heritage: A Tale of Two Languages in Constant Dialogue

To fully appreciate the depth of inspiration between Java and C#, one must first understand their shared origin story. Java was released in 1995 as Sun Microsystems’ answer to the complexity of C++, promising “write once, run anywhere” through the JVM. C#, announced by Microsoft in 2000, was explicitly positioned as a modern, type-safe, component-oriented language for the .NET Framework, but its syntax, garbage collection, exception handling, and metadata system bore an uncanny resemblance to Java. This was no coincidence. Anders Hejlsberg, the architect of C#, had previously designed Turbo Pascal and Delphi, but he openly acknowledged Java’s influence. As Cyrille humorously remarked during the talk, “C# didn’t just look like Java—it was Java’s younger brother who went to a different school, wore cooler clothes, and occasionally got better grades.”

This fraternal relationship manifested in a decade-long game of leapfrog. When Java 5 introduced generics in 2004, C# 2.0 responded with generics, nullable types, and anonymous methods in 2005. When C# 3.0 unveiled LINQ and lambda expressions in 2007, Java remained silent until Java 8 in 2014. When Java 7 introduced the invokedynamic bytecode in 2011 to support dynamic languages, C# 4.0 had already shipped the dynamic keyword in 2010. This back-and-forth was not mere imitation—it was a refinement cycle where each platform stress-tested ideas in production before the other adopted and improved them.

Lambda Expressions and Functional Programming: From Verbosity to Elegance

One of the most visible and impactful areas of cross-pollination was the introduction of lambda expressions and functional programming constructs. In the pre-lambda era, both Java and C# relied on verbose anonymous inner classes to implement single-method interfaces. A simple event handler in Java 6 looked like this:

button.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent e) {
        System.out.println("Button clicked at " + e.getWhen());
    }
});

The equivalent in C# 2.0 was only marginally better, using anonymous delegates:

button.Click += delegate(object sender, EventArgs e) {
    Console.WriteLine("Button clicked");
};

But in 2007, C# 3.0 introduced lambda expressions with a syntax so clean it felt revolutionary:

button.Click += (sender, e) => Console.WriteLine("Clicked!");

This wasn’t just syntactic sugar. It was a paradigm shift toward functional programming, enabling higher-order functions, collection processing, and deferred execution. Rui demonstrated how this simplicity extended to LINQ:

var recentOrders = orders
    .Where(o => o.Date > DateTime.Today.AddDays(-30))
    .OrderBy(o => o.Total)
    .Select(o => o.CustomerName);

Java developers watched with envy. It took seven years for Java 8 to deliver lambda expressions in 2014, but when it did, it came with a more rigorous type system based on functional interfaces and default methods:

button.addActionListener(e -> System.out.println("Clicked!"));

The Java version was arguably more type-safe and extensible, but it lacked C#’s expression-bodied members and local functions.

EDIT:
In 2021, Java 21 has closed the gap further with pattern matching and unnamed variables, but C# 13’s primary constructors in records remain unmatched:

public record Person(string Name, int Age);

LINQ: The Query Comprehension Revolution That Java Never Fully Embraced

Perhaps the most profound inspiration from .NET—and the one Java has still not fully replicated—is LINQ (Language Integrated Query). Introduced in C# 3.0, LINQ was not merely a querying library; it was a language-level integration of query comprehension into the type system. Using a SQL-like syntax, developers could write:

var result = from p in people
             where p.Age >= 18
             orderby p.LastName
             select new { p.FirstName, p.LastName };

This syntax was compiled into method calls on IEnumerable<T>, but more importantly, it was extensible. Providers could translate LINQ expressions into SQL, XML, or in-memory operations. The secret sauce? Expression trees.

Expression<Func<Person, bool>> predicate = p => p.Age > 18;
var sql = SqlTranslator.Translate(predicate); // "SELECT * FROM People WHERE Age > 18"

Java’s Streams API in Java 8 was the closest analog:

List<Person> adults = people.stream()
    .filter(p -> p.getAge() >= 18)
    .sorted(Comparator.comparing(Person::getLastName))
    .map(p -> new PersonDto(p.getFirstName(), p.getLastName()))
    .toList();

But Streams are imperative in spirit, lack query syntax, and cannot be translated to SQL without external tools like jOOQ. Cyrille lamented: “Java gave us the pipeline, but not the language.”

Asynchronous Programming: async/await vs. the Java Journey

Concurrency has been another arena of inspiration. C# 5.0 introduced async/await in 2012, allowing developers to write asynchronous code that looked synchronous:

public async Task<string> FetchDataAsync()
{
    var client = new HttpClient();
    var html = await client.GetStringAsync("https://example.com");
    return Process(html);
}

The compiler transformed this into a state machine, eliminating callback hell. Java’s journey was more fragmented: Futures, CompletableFuture, Reactive Streams, and finally Project Loom’s virtual threads in Java 21:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    return executor.submit(() -> client.get(url)).get();
}

Virtual threads are a game-changer, but they don’t offer the syntactic elegance of await. As Rui quipped, “In C#, you write synchronous code that runs asynchronously. In Java, you write asynchronous code that hopes to run efficiently.”

Web Frameworks: From WebForms to Razor and the Templating Renaissance

Rui traced .NET’s web framework evolution with particular passion. The early 2000s were dominated by ASP.NET WebForms, a drag-and-drop, event-driven model that promised rapid development but delivered ViewState bloat, postback hell, and untestable code. It was, in Rui’s words, “a productivity trap disguised as a framework.”

The community rebelled, giving rise to ALT.NET and frameworks like MonoRail. Microsoft responded with ASP.NET MVC in 2009, embracing separation of concerns, testability, and clean URLs. Then came Razor in 2010—a templating engine that felt like a revelation:

@model List<Person>
<h1>Welcome, @ViewBag.User!</h1>
<ul>
@foreach(var p in Model) {
    <li>@p.Name <em>(@p.Age)</em></li>
}
</ul>

No XML. No JSP-style scriptlets. Just C# and HTML in harmony. Java’s JSP, JSF, and even Thymeleaf felt antiquated by comparison. But in 2020, Spring Boot with Thymeleaf or Micronaut Views has narrowed the gap, though Razor’s layout system and tag helpers remain superior.

The Cutting Edge in 2025: Where Java and C# Stand Today

EDIT:
C# 13 and .NET 9 continue to innovate with source generators, record structs, and minimal APIs:

var builder = WebApplication.CreateBuilder();
var app = builder.Build();
app.MapGet("/", () => "Hello World");
app.Run();

Java 21 counters with pattern matching for switch, records, and virtual threads, but lacks native metaprogramming. Projects like Spring Fu and Quarkus are pushing functional and reactive paradigms, but the expressive gap remains.

Conclusion: Inspiration Without Imitation

Martraire and Carvalho’s core message endures: Java and .NET are not rivals—they are collaborators in the advancement of managed languages. The inspiration flows both ways, and the future belongs to developers who can transcend platform boundaries to build better systems.

EDIT:
In 2025, as cloud-native, AI-augmented, and real-time applications dominate, the lessons from this 2012 dialogue are more relevant than ever.

Links

• Cyrille Martraire – Arolla
• ALT.NET Paris
• C# Language Evolution
• Java 21 Features
• Video: .NET pour le développeur Java