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.
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.
In this episode we discussed with
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.
In this episode we discussed with
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.