Index out of bounds | Entwickler/Developer Podcast

Wetter-App, Taschenrechner, Habit-Tracker – langweiliger geht's kaum. Genau daraus baut Andy Allen mit seinem Zwei-Personen-Studio !Boring Software Apps, für die Menschen freiwillig Geld bezahlen. Nicht wegen der Features, sondern wegen des Designs. Inspiriert von einer Launched-Podcast-Folge mit Andy Allen fragen wir uns: Warum ist unsere Software eigentlich so boring?
Wir diskutieren, ob Design allein ein Geschäftsmodell tragen kann, warum Games uns mit Optik, Sound und eigenen Welten begeistern, während Business-Software sich anfühlt wie Arbeit – und ob Fun und Usability sich eigentlich im Weg stehen. Thomas hat die !Boring Apps ausprobiert und ist zwiegespalten, Thomas bringt Dieter Rams' Design-Thesen ins Spiel. Und am Ende steht die Frage: Vielleicht geht's gar nicht um Boring vs. !Boring, sondern um Mühe vs. keine Mühe?
Links:
Launched Podcast mit Andy Allen: https://launchedfm.com/episode/95-boring-software-andy-allen
!Boring Software: https://notbor.ing/
Dieter Rams – 10 Thesen zum guten Design: https://rams-foundation.org/die-stiftung/designverstandnis/thesen/
Community:
💜 Werde Teil der IOOB Discord Community: https://discord.gg/bbC5c4vvQY
Kontakt:
👉 ioob.de
📬 input@ioob.de
𝕏 x.com/IoobPodcast
📺 youtube.com/@ioobpodcast

Fünf Agents parallel, drei Projekte offen – und am Ende ist nichts davon fertig. Thomas ist deshalb wieder zurück beim Single-Agent-Workflow: ein Agent, kleine Schritte, Pair-Programming-Gefühl, Review mittendrin statt am Ende. Christian sieht das anders: Ohne zweiten Agent fehlt ihm der Flow, weil ihn die Wartezeiten permanent rausreißen.
Daraus wird ein Gespräch über Aufmerksamkeit als neue knappe Ressource, über AI Brain Fry und die Frage, warum sich Multi-Agent-Arbeit so produktiv anfühlt, aber verdächtig nach klassischem Multitasking riecht. Dazu: das Terminal-Revival mit cmux, herdr und dem guten alten tmux, HTML statt Markdown für Agent-Pläne, Claude Code direkt im Browser – und warum Unternehmen langsam eine Strategie brauchen, statt allen Entwickler*innen einfach einen Coding-Agent in die Hand zu drücken.
Community:
💜 Werde Teil der IOOB Discord Community: https://discord.gg/bbC5c4vvQY
Links:
herdr: https://herdr.dev/
cmux: https://cmux.com/
tmux: https://github.com/tmux/tmux
Ghostty: https://ghostty.org/
iTerm2: https://iterm2.com/
Oh My Zsh: https://ohmyz.sh/
Polyscope: https://getpolyscope.com/
Paperclip: https://paperclip.ing/
Claude Code mit Chrome: https://code.claude.com/docs/en/chrome
Kontakt:
👉 ioob.de
📬 input@ioob.de
𝕏 x.com/IoobPodcast
📺 youtube.com/@ioobpodcast

Warum produzieren ausgerechnet die größten Tech-Firmen – mit den bestbezahlten Entwickler:innen und scheinbar aller Zeit der Welt – immer wieder überraschend schlechten Code? In dieser Folge nehmen wir Sean Goedeckes vieldiskutierten Essay „How good engineers write bad code at big companies" auseinander. Seine These: Es liegt nicht an inkompetenten Leuten, sondern am System. Die meisten Entwickler:innen arbeiten ständig in fremden, alten Codebasen, unter Deadline-Druck – schlechter Code ist da fast unvermeidlich.
Wir sprechen über die Realität des „median engineer", warum auch erfahrene „Old Hands" das Problem nicht auffangen können, und über den provokanten Gedanken, dass große Firmen diesen Trade-off ganz bewusst eingehen: Austauschbarkeit schlägt Expertise. Zum Schluss steigen wir in die Debatte ein, die der Artikel ausgelöst hat – ist das eine nüchterne Analyse oder purer Zynismus?
💜 Werde Teil der IOOB Discord Community:
https://discord.gg/bbC5c4vvQY
Links:
Sean Goedecke – „How good engineers write bad code at big companies": https://www.seangoedecke.com/bad-code-at-big-companies/
Sean Goedecke – „Software engineers should be a little bit cynical": https://www.seangoedecke.com/a-little-bit-cynical
Alex Wennerberg – „Software engineers are not politicians": https://alexwennerberg.com/blog/2025-11-28-engineering.html
Nate Meyvis – „Why is there so much bad code at big companies?": https://www.natemeyvis.com/why-is-there-so-much-bad-code-at-big-companies/
Sean Goedecke – „Seeing like a software company": https://www.seangoedecke.com/seeing-like-a-software-company
Sean Goedecke – „Pure and impure software engineering": https://www.seangoedecke.com/pure-and-impure-engineering
Kontakt:
👉 ioob.de
📬 input@ioob.de
𝕏 x.com/IoobPodcast
📺 youtube.com/@ioobpodcast

Ein harmloser brew install, ein kurzer Moment der Unaufmerksamkeit – und plötzlich sind Passwörter, Keychain und Dokumente weg. Genau das ist einem Freund von Thomas passiert. In dieser Folge nehmen wir den Angriff Schicht für Schicht auseinander: vom ersten Klick bis zum Datenabfluss.
Thomas hat sich die Sache selbst per Reverse Engineering vorgenommen und zeigt, was hinter dem vermeintlichen Install-Befehl steckt: ein nachgeladenes Skript, ein versteckter Hintergrundprozess zur Verschleierung und am Ende ein AppleScript, das mit einem täuschend echten Passwort-Prompt Keychain, Browserdaten und Wallet-Extensions absaugt. Danach reden wir über die unbequemen Fragen – was tun, wenn's einen selbst erwischt hat, und warum „wär mir nie passiert" der gefährlichste Satz überhaupt ist.
💜 Werde Teil der IOOB Discord Community: https://discord.gg/bbC5c4vvQY
Links
Homebrew (offizielle Seite): https://brew.sh/
AMOS über gefälschte Homebrew-Seiten als Einfallstor: https://www.securityweek.com/homebrew-macos-users-targeted-with-information-stealer-malware/
Tiefergehende technische Analyse von AMOS (Reverse Engineering): https://www.picussecurity.com/resource/blog/atomic-stealer-amos-macos-threat-analysis
Kontakt
👉 ioob.de
📬 input@ioob.de
𝕏 x.com/IoobPodcast
📺 youtube.com/@ioobpodcast

„Agentic Engineering" klingt nach Revolution – am Ende ist es vielleicht einfach Engineering mit neuem Werkzeug. Die Versprechung: Agenten nehmen uns die Arbeit ab. Die Realität: Der Flaschenhals verschwindet nicht, er verschiebt sich nur. Weg vom Implementieren, hin zum Reviewen. Und plötzlich sitzt man auf 100 offenen Reviews und kommt trotzdem nicht voran.
Christian und Thomas machen einen ehrlichen AI Reality Check – und sind sich dabei nicht in allem einig. Sie diskutieren, ob der Hype um Agent Orchestration wirklich trägt, warum Reviews schon immer fehleranfälliger waren als das Schreiben von Code, und was passiert, wenn man den Review gleich von der nächsten KI erledigen lässt: Token Burn, Output Bias, fragwürdige Qualität. Dazu die unbequeme Frage hinter allem – macht uns das Ganze eigentlich gründlicher oder nur fauler? Zwischen Review-Blindheit, „einfach alles abnicken" landen die beiden beim vielleicht größten Risiko von allen: es uns bequem zu machen.
💜 Werde Teil der IOOB Discord Community: https://discord.gg/bbC5c4vvQY
Links:
Dexter Horthy über Agentic-Coding-Workflows: https://www.youtube.com/watch?v=YwZR6tc7qYg
Ralph Caspers – Maximierer vs. Satisficer: https://www.youtube.com/watch?v=r4kAwbUSYoU
Paperclip (Agent Orchestration): https://github.com/paperclipai/paperclip
Optio (Agent Orchestration): https://optio.host
Kontakt:
👉 ioob.de
📬 input@ioob.de
𝕏 x.com/IoobPodcast
📺 youtube.com/@ioobpodcast