{"id":7648,"date":"2025-08-20T15:34:18","date_gmt":"2025-08-20T13:34:18","guid":{"rendered":"https:\/\/blog.bart.sk\/en\/?p=7648"},"modified":"2025-08-20T15:34:18","modified_gmt":"2025-08-20T13:34:18","slug":"5-takeaways-from-wearedevelopers-2025-that-stuck-with-me","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/5-takeaways-from-wearedevelopers-2025-that-stuck-with-me\/","title":{"rendered":"5 Takeaways from WeAreDevelopers 2025 That Stuck With Me"},"content":{"rendered":"\n

This year was my very first time at the WeAreDevelopers World Congress 2025 in Berlin. When my colleague Mi\u0161o and I bought the tickets, we expected a big conference. But over 15,000 people, hundreds of talks, and 17 stages with parallel sessions running from morning to evening \u2013 that\u2019s a whole new dimension. On top of that, this edition was special: the conference celebrated its 10th anniversary and once again proved why it\u2019s called the largest developer event in Europe. <\/strong><\/p>\n\n\n\n

Already on day one it became clear that we couldn\u2019t possibly attend everything, so we split the schedule and agreed to share the best highlights afterwards. With so many talks, some content inevitably blended together, some topics repeated, and not everything left the same impression. But a few ideas really stuck with me. Here they are:<\/p>\n\n\n\n

1. Large applications get simpler when you break them down <\/strong>(microfrontends at ZEISS)<\/em><\/strong><\/h3>\n\n\n\n

I\u2019ve been following the topic of microfrontends for years, even though I haven\u2019t had the chance to use them in production yet. I\u2019ve always believed that smaller means simpler, and simpler means easier to maintain. This belief was confirmed by Stefan Bley and Lucas Braeschke<\/strong> from ZEISS Digital Innovation<\/strong>, who illustrated the concept on a real-world challenge.<\/p>\n\n\n\n

Their Health Data Platform (HDP) was a monolithic frontend where each release triggered time-consuming testing across the entire app. The solution? Splitting the app into micro parts that can be developed, tested, and deployed independently. In practice, a main shell wrapped around individual components, which could share dependencies and even run on different frameworks (in their case Angular and React side by side).<\/p>\n\n\n\n

Each micro-part was owned by its own team responsible for both development and release planning. The result: more independence, faster iterations, and less waiting on others. The key, however, lies in defining the right boundaries so teams don\u2019t step on each other\u2019s toes while still keeping the system maintainable.<\/p>\n\n\n\n

This isn\u2019t just a neat architectural idea \u2013 it\u2019s a practical way to simplify development in large teams and reduce deployment risks. Since that talk, I\u2019ve kept a mental list of projects where this approach might fit.<\/p>\n\n\n\n

\"\"
My view of the packed hall and the welcome sign \u201cKaribuni\u201d \u2013 Swahili for \u201cwelcome\u201d.<\/figcaption><\/figure>\n\n\n\n

2. The biggest security risk isn\u2019t always in the code \u2013 it\u2019s in user behavior <\/strong>(inspired by John Romero on cheating and AI)<\/em><\/strong><\/h3>\n\n\n\n

John Romero, creator of Doom and Quake, talked about security in a way I didn\u2019t expect.
He explained how cheating in games has evolved. It used to mean hacking memory or modifying code. Today, cheaters don\u2019t need to touch the system at all \u2013 they simply train an AI to watch the screen until it learns how to play the game by itself. No code changes, no hacking.<\/p>\n\n\n\n

For developers, the lesson is clear: cheating is a business. Because there\u2019s real money in e-sports, people invest in increasingly sophisticated tools. AI can now act as an autonomous player, learning from observation and reacting faster than humans. And interestingly, the same principles that let AI cheat also power tools like GitHub Copilot \u2013 except here they accelerate work and support developers instead of exploiting the system.<\/p>\n\n\n\n

For me, this was a strong reminder that security isn\u2019t just about encryption and access tokens \u2013 it\u2019s also about how users interact with the system. The same thinking applies to web and business apps: risks often come not from the code itself, but from user behavior.<\/p>\n\n\n\n

3. Node is no longer an excuse \u2013 true parallelism is here without changing your stack <\/strong>(on worker_threads and Piscina in Node.js)<\/em><\/strong><\/h3>\n\n\n\n

Mi\u0161o attended Matteo Collina\u2019s talk Node.js: More Threads Than You Think<\/em>. If you still think of Node as a single-threaded runtime, it\u2019s time to update your perspective.<\/p>\n\n\n\n

Thanks to the built-in worker_threads<\/code> API and tools like Piscina<\/a>, we can now introduce true parallelism in Node.js apps \u2013 without changing technologies or architecture.<\/p>\n\n\n\n

The benefits are obvious for CPU-heavy tasks like report generation, data processing, or statistics that would otherwise slow down the main event loop. Offload them to worker threads, and they run in parallel without blocking requests.<\/p>\n\n\n\n

\"\"
Selfie in front of the hall with the iconic duck \u2013 the conference mascot referencing \u201crubber duck debugging\u201d.<\/figcaption><\/figure>\n\n\n\n

4. When dev and production environments behave the same, development speeds up <\/strong>(on docker-compose in Google Cloud)<\/em><\/strong><\/h3>\n\n\n\n

From the Google Cloud sessions, the most exciting update was the ability to deploy apps directly using docker-compose.yml<\/code>. Not through a traditional Dockerfile or Kubernetes manifests \u2013 but exactly the same way we do locally.<\/p>\n\n\n\n

Until now, moving to production meant rewriting configs into K8s YAML or Terraform, which was slow and error-prone. This new approach could cut down that overhead significantly.<\/p>\n\n\n\n

If it works in practice like it did in the demo, developers will be able to test complex changes without waiting for DevOps. For smaller services or internal tools, there might not even be a need for a \u201cproduction-only\u201d deployment anymore \u2013 just run docker compose up\u2026 directly in the cloud.<\/p>\n\n\n\n

The result could be:
\u2013 faster testing of architectures,
\u2013 fewer errors caused by mismatched environments,
\u2013 easier staging deployments,
\u2013 lower infrastructure knowledge requirements during development.<\/p>\n\n\n\n

It may not be a revolution yet, but if it stabilizes and gains adoption, it could change how teams handle smaller apps.<\/p>\n\n\n\n

\"\"
#WeAreDevs \u2013 a reminder that even if we all write different code, we\u2019re still part of one developer community.<\/figcaption><\/figure>\n\n\n\n

5. AI is no longer just autocomplete \u2013 it\u2019s becoming a colleague <\/strong>(on GitHub Copilot as an independent agent)<\/em><\/strong><\/h3>\n\n\n\n

Copilot was one of the hottest topics \u2013 sometimes technical, sometimes more philosophical.<\/p>\n\n\n\n

What stood out most was how it\u2019s becoming more autonomous. Not just a plugin guessing the next line of code, but an agent you assign an issue to \u2013 and it works on it by itself. It can open a pull request, take feedback, and push an updated solution.<\/p>\n\n\n\n

The live demo didn\u2019t work at all, which was a funny moment. But that doesn\u2019t change the fact: Copilot already saves time. With the right prompts and review, it works like a smart junior developer who never forgets, never delays, and is always online.<\/p>\n\n\n\n

Bonus: JavaScript\u2019s skeletons in the closet aren\u2019t going anywhere <\/strong>(on backward compatibility and syntax oddities)<\/em><\/strong><\/h3>\n\n\n\n

Peter Kroner delivered a funny but accurate roundup of JavaScript\u2019s strangest syntax quirks \u2013 like why [] + [] isn\u2019t the same as [] + {}. The takeaway? It all stays because of 100% backward compatibility<\/strong>.<\/p>\n\n\n\n

A good reminder that tech debt doesn\u2019t only apply to projects, but also to languages themselves. Sometimes we code despite<\/em> the language, not thanks to it.<\/p>\n\n\n\n

Not something I\u2019d deploy Monday morning \u2013 but as a reality check that even languages carry their past baggage, it was spot on.<\/p>\n\n\n\n

Conclusion<\/strong><\/h3>\n\n\n\n

What impressed me most was the organization. With so many people, everything ran smoothly. Networking was interesting too \u2013 QR-code cards linked to app profiles replaced business cards, which felt natural and practical. Still, it was mostly companies using it; let\u2019s be honest, developers tend to be introverts.<\/p>\n\n\n\n

In short \u2013 the conference was excellent. A well-curated expo, loads of inspiring talks, and often the hardest decision was simply choosing where to go. And that, I think, is the best problem a developer can have at an event like this.<\/p>\n\n\n\n

At the end of the day, we agreed on one thing: AI is reshaping how we build software. Programming today looks nothing like it did just a few years ago, and a year from now it will look different again. Still, we need to stay cautious about what we adopt \u2013 sometimes new tools bring more chaos than clarity. Some things aren\u2019t ready for production just yet, while others we started trying out on the way home. And that\u2019s exactly what conferences like this are for.<\/p>\n\n\n\n

\"\"
Taking a moment to pause. A good event isn\u2019t just about content \u2013 it\u2019s also about letting your brain reset and process the ideas.<\/figcaption><\/figure>\n\n\n\n

FAQ: Frequently Asked Questions about WeAreDevelopers 2025 and Conference Topics<\/h2>\n\n\n\n
\n What are the benefits of microfrontends and when are they worth using?<\/summary>\n

Microfrontend architecture splits a large application into smaller, independently deployed parts. This simplifies development, testing, and deployment while reducing release risks. It\u2019s especially useful for larger teams and complex products.<\/p>\n<\/details>\n\n\n\n

\n How can Node.js achieve parallelism without rewriting the application?<\/summary>\n

With the built-in worker_threads<\/code> API and the Piscina<\/strong> library, Node.js can handle CPU-intensive tasks in parallel without blocking the main event loop \u2013 and without changing the entire stack.<\/p>\n<\/details>\n\n\n\n

\n Can you deploy applications to Google Cloud directly with docker-compose.yml<\/code>?<\/summary>\n

Yes. Google Cloud now supports docker-compose configurations for straightforward deployments. It\u2019s a fast, practical option for staging environments and smaller apps, without needing to manage complex Kubernetes YAML files.<\/p>\n<\/details>\n\n\n\n

\n How can AI tools like GitHub Copilot handle tasks independently?<\/summary>\n

Copilot has evolved beyond autocomplete. It can open pull requests, respond to feedback, and iterate solutions on its own. Think of it as a digital junior developer who remembers context and makes autonomous decisions.<\/p>\n<\/details>\n\n\n\n

\n What does cheating in games have to do with application security?<\/summary>\n

Game hackers show that exploiting behavior doesn\u2019t require touching the code \u2013 just the UI and logic. The same principle applies to business applications. That\u2019s why security should consider user behavior, not only developer safeguards.<\/p>\n<\/details>\n\n\n\n

\n Is programming in 2025 different from just a few years ago?<\/summary>\n

Absolutely. AI tools, new deployment workflows, and architectural shifts are transforming how developers work. What was considered futuristic last year is quickly becoming the new normal.<\/p>\n<\/details>\n\n\n\n

\n What was networking like at WeAreDevelopers 2025?<\/summary>\n

Digital, efficient, and surprisingly natural. QR codes, open booths, and a strong community vibe made connecting easier \u2013 even for developers who aren\u2019t the most outgoing.<\/p>\n<\/details>\n\n","protected":false},"excerpt":{"rendered":"This year was my very first time at the WeAreDevelopers World Congress 2025 in Berlin. When my colleague…","protected":false},"author":45,"featured_media":7649,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","csco_display_header_overlay":false,"csco_singular_sidebar":"","csco_page_header_type":""},"categories":[210,199,516],"tags":[974,976,978,977,975,962,970,971,969,973,965,963,980,966,967,979,972,964,968],"_links":{"self":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7648"}],"collection":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/users\/45"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/comments?post=7648"}],"version-history":[{"count":1,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7648\/revisions"}],"predecessor-version":[{"id":7650,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/posts\/7648\/revisions\/7650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media\/7649"}],"wp:attachment":[{"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/media?parent=7648"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/categories?post=7648"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.bart.sk\/en\/wp-json\/wp\/v2\/tags?post=7648"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}