This is the 'last' episode. Don't be sad, it's still the best time to be a developer. In this double episode, we first discuss why we started the podcast, and then how we currently see software development in general.

In his new book, Eric takes a different approach to teaching principles of functional programming. We discuss what it means to not use a functional programming language.

Paul switched job after 14 years in the same company working for the same client. He changed environments, programming language and even his developer machine OS including keyboard layout. How did it go?

We discuss with David whether it is important to train on Agile development or more on development practices.

If you can’t reach your audience with classic marketing, Philipp Krenn explains the different aspects of working with their community at Elastic.

BDD has been around for a while now, but in many cases it is only utilized as a technical aid. In this episode we try to unpack the power BDD could give us, together with Gáspár Nagy, the creator of SpecFlow.

We talked with J. B. Rainsberger about his idea of a Universal Architecture and how it helps people to get architectural decisions right. In addition, we talked about the continuing importance of clean code, even in times of distributed systems and microservice architectures.

Maaret Pyhäjärvi changed jobs recently and compares her experience as 'time travel 10 years to the past'. This leads to Continuous Delivery and crafting your job for impact.

Lisi Hocke talks about her personal learning tour, focusing on testing. Driven by personal challenges, this way to learn brought her a lot of new experiences and expanded her network.

We talk about guides and rules for programmers in the scope of their code style and object style. With the help of book author Matthias Noback we realize that there is more possible with static analysis than one might think. And there is definitely a use for a catalogue of stereotypes of classes.

In this episode, we discussed with Nik Graf about GraphQL and why he thinks it is a future-proof way to create APIs for client applications. We tried to distill the main advantages over classical REST, and figured out scenarios when it shines, but also took a look at possible drawbacks. TL/DR: Everything you need to know if you are interested to get started with GraphQL.

Patrick shared with us his contribution on creating the ReasonML association, as well as the idea of starting such a movement, and we also dived into the usage of ReasonML in safety critical software.

This time our very own David gives us an introduction to one of his favourite topics. Microfrontends may not be new, yet they are a recurring theme in various teams and companies. What they are about and where this idea is moving to, David will give us an overview.

We start by rejecting Kubernetes and go on a whirlwind tour through all the different tools which might be useful for automation of your development and operating needs.

Sandra gives us a crash course in what DevOps originally meant and means, when you are a DevOp person and what you would need.

We talk about the joy and benefits of sharing what we learn. Be it in blog posts, talks, just Twitter messages, or other ways.

The venture into the often-overlooked topic of making user interfaces accessible to everyone. To quote Trenton Moss we want to make it clear that Web accessibility isn't brain-science. And it's also not just about disabled users being able to access your website - it's about everyone being able to access your website.

Together with Fabian Schmied we discuss how bad implementations of Scrum can look like, and what options people have to improve or avoid it. (This episode is just a decoy to get everyone into Extreme Programming)

Fabian Schmied helps us understand CQRS and Event Sourcing by giving us a crash course on its motivation and context. Listen to learn about the inner workings of implementing such a system with some examples from the product he is working on.

We follow Gerald Bauer for a roller coaster ride of data formats, usages in open data, and how and where to find good beer - all for an open society.

To figure out why blockchain programming is just programming, we talk with Gerald Bauer about his views on No-Coiners and Bitcoin Maximalists, differences between Bitcoin and Ethereum, and finally how to solve the halting problem.

The way how software architecture works has changed tremendously, especially with iterative approaches that foster fast changes and delivery like scrum or kanban. Evolutionary architecture is a set of concepts and patterns to design system in a way to expect change. Patrick gave us a deep, but very practical insight into the ideas and techniques behind this new architectural approach.

We talked with Patrick about his understanding of what makes a good lead. He gave us a deep inside into the skills you probably need to learn, to bring yourself into this position and a hand of very useful tips to start this journey. All this, mixed with couple of very interesting insights about the inner-workings of N26.

We ask Peter about his experiences from his pair programming tour several years ago. Curious about the learning, we also discuss for whom such a tour might be worth doing and getting started in a corporate environment.

Paul asks at which point the question about differentiating between automated tests is irrelevant. As part of answering this, we discuss test automation pyramids and testing quadrants.

Is there still a reasonable area of application for the blockchain after the first hype went by? And what is the blockchain exactly? Is it a pattern, a framework, a database? We will talk with someone who's daily job is to get stuff done, with a lot of blockchain technology involved.

During this episode had a great discussion with Thomas about the programming language Rust. Why his teams uses it for all their projects, where he sees the main benefits and how it is comparable to other programming languages. As a bonus, he gave us a few tips on how to start if you want to learn this promising stuff.

How we, the developers, ended up back at the original problem of building software to support the people. We ask our guest and local expert about different aspects of domain driven design.

Martin tells about his experience in creating two successful communities in Vienna. How to get going if you don't know anything about it. Thanks Martin for giving us an insight into this!

In the second episode with Sebastian Daschner we talked about his work as developer advocate - and what does this actually mean? After getting the head around this we focus on tools and techniques that make you more productive as a developer. As usual paired with jokes an viennese coffee shop flair, as usual.

We talked with Sebastian Daschner, a Java Champion about the future of Java Enterprise, the new Eclipse Microprofile and what's behind Quarkus. As not of all us are Java-Heads this episodes also contains a few “Explain it to me like I’m 6” segments which bring light into a few core concepts of the Java ecosystem and its history. Last but not least, why is there no Java Conference in Vienna?

In a smaller than usual group we discuss with Gottfried Szing how we keep on the pulse of our craft and industry. This discussion leads us from Twitter feeds over local communities to the dislike of conferences as advertisements in disguise.

Our guest Gottfried Szing introduces us into some ideas of security by design. A fruity cocktail of how to avoid primitives obsessions and where to put the validation in your architecture - mixed with a little bit of contract first development. Finalized with a discussion about rusting software.

Our special guest Claudia Oster explains the ideas of design thinking and the similarities with human centred design. It is interesting how the original design methodologies expanded to the business world. Peter brings us out of our comfort zone with his need for dogma. Listen to find out if strict rules are reasonable!

2019 gets even stronger with a lot to discuss. First we ask how much testing do our tests need. Is it a smell if we feel we should test our tests? Then we do a run-down on common architectures. What are the benefits and drawbacks? How do they relate to each other? And can someone survive never having experienced any of them in their true form.

This episode is all about talking: Together with our very first official guest, we attempt figuring out how to get developers talk to each other, and then get managers talk to developers about technical debt.

We started this episode discussing about readability of code. What actually is readability? It seems, that next to names, there are other important things to consider, like visual structure. In the second part we talked about how to get started with Test Driven Development (TDD) in a project were nobody else is doing it. We found a few suitable ways to get things started. Finally we concluded the episode with our personal history, how we each one of us got started with TDD.

How bad is duplication on different levels? When should we prefer having some code in our codebase over taking the dependency to a library? Is all duplication equal? In the first topic of this episode we discuss several aspects of duplication in a code base and the impact on stability, maintainability and reliability. For the second topic we discuss some schools of software development, from eXtreme Programming to Programming M.F.. Do they support different personalities of team members? Or should we try to consolidate on a single school within a team? For the last topic we don't feel to have a proper conclusion. So - what are your experiences on schools of software development. Interesting discussions guaranteed!

In this episode, we were discussing the (i) additional cost of following BDD. We concluded that the core of BDD is the understanding of what needs to be done and as such, it can be compared to TDD or ATDD. Maybe there is no additional cost, rather a cost of not doing it. During the second part, we focused on the question of (ii) being a generalist or specials. What impact this decision has on career, teamwork and project success and whether there is a preference for us.

In this episode, we tackled two topics: (i) How we meet the requirements of constantly learning new technologies and what approaches we use to drive this efficiently. In addition, we try to find a common understanding, at which point in time something can be considered as known or learned. After this, we take hold of (ii) the occurrence of accidental and essential complexity in software projects described by Fred Brooks. Why it's important to understand the difference, and what we can gain from this knowledge.

The SOLID principles were proposed by Robert C. Martin to make software designs more understandable, flexible and maintainable. During our first podcast Paul, David and Christian will dig deeper into these five legendary design principles and discuss which experiences they made by using them during their daily work.