![Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
[...]
There should be one-- and preferably only one --obvious way to do it.
[...]
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!](https://image.slidesharecdn.com/fromtheboardroomtotheterminaladaptingtothefuture-devopsbcn-apr2025-250411053301-43b2a257/85/From-the-Boardroom-to-the-Terminal_-Adapting-to-the-Future-DevOpsBCN-Apr-2025-14-320.jpg)
![Source: PEP20, The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
[...]
There should be one-- and preferably only one --obvious way to do it.
[...]
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!](https://image.slidesharecdn.com/fromtheboardroomtotheterminaladaptingtothefuture-devopsbcn-apr2025-250411053301-43b2a257/85/From-the-Boardroom-to-the-Terminal_-Adapting-to-the-Future-DevOpsBCN-Apr-2025-15-320.jpg)
From the Boardroom to the Terminal_ Adapting to the Future - DevOpsBCN - Apr 2025
- 1. From the Boardroom to the Terminal: Adapting to the Future David Poblador Garcia. April 2025 david@poblador.com
- 2. Raise your hand if you can relate “My CEO is definitely the next Linus Torvalds who just happens to run our company, while my sad team merely keeps everything running without jumping on every HackerNews fad.” — Any 2025 engineer with a “vibe coderˮ boss
- 3. About Me ● 25+ years in Tech ● Hands-On to Strategy and Back ● Built Spotify's SRE Department. Migrated 15K+ servers to ⛈ ● Founder of All Tuner Labs. Building Castuner and Devtuner. ● Involved in Due Diligence processes. Advisor to Tech Startups ● Last Time I Was Hands-On... Stack Overflow was a thing and Google Search actually worked
- 4. Today's Topics 1. The transformed development landscape 2. Technical debt in the age of code generation 3. The new API revolution 4. The future of tech interviews 5. The bright future ahead for technologists
- 5. The New Development Landscape
- 6. What’s changed 01 Search Engines 02 Documentation 03 Trial and Error 04 Stack Overflow 01 Conversational Tools 02 Generated Code 03 Evaluation 04 Refinement 2015 2025
- 7. Tools Comparison What automated tools do well ● Generating boilerplate code ● Solving well-defined problems ● Suggesting optimizations ● Documenting existing code ● … making you “feel good” and hypocritically boosting your self-esteem What humans do well ● Defining the actual problem ● Systems thinking and architecture ● Quality assessment ● Innovation and creativity ● … imagination!
- 8. The “New” Workflow Problem Definition Initial Code Generation 🤖 Review and Refinement Testing and Validation 🤖 Deployment and Monitoring 🤖 🔮
- 9. Technical Debt in the Modern Era
- 10. Legacy is the name of the game ● Remember how old banking systems created decades of legacy maintenance? ● Auto-generated code is tomorrow’s technical debt (tell your vibe coder CEO) ● Heck… all code we write is debt And that’s good: we will continue having a job, and we will be able to rant about it. And it gives us the opportunity to work on conventions! (Don’t we all like creating new frameworks?)
- 11. Sources: Github Octoverse 2024 and Trends 2018 Not convinced yet? Just imagine how much technical debt all these projects are accumulating
- 12. Context is King
- 13. LLMs are wasting precious cycles reinventing the wheel
- 14. Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. [...] There should be one-- and preferably only one --obvious way to do it. [...] If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
- 15. Source: PEP20, The Zen of Python Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. [...] There should be one-- and preferably only one --obvious way to do it. [...] If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
- 16. Stronger Conventions to the Rescue ● If we minimize the amount of guesswork, we help LLMs, and we help ourselves. ● If you’ve been around for a while you know it’s happened before: ○ Linux Distributions are conventions ○ Packaging methods are conventions ○ APIs are conventions ○ Containers are conventions ○ Frameworks are conventions ○ Docker primitives are conventions ● Currently, LLMs (and us) rebuild the square wheel many times! ● We need to minimize choices, without hurting innovation ● If standards are strong, we will have less temptations to go off-road
- 17. But I like off-road biking!
- 18. The Balancing Act: Don’t Damage Innovation Standardization Innovation Exciting but unstable Sustainable progress Chaos Stagnation
- 19. The Balancing Act: Don’t Damage Innovation Standardization Innovation Exciting but unstable Sustainable progress Chaos Stagnation GOOD IDEAS!
- 20. The New APIs
- 21. 2000s SOAP, XML based Mostly constrained to internal communication and RPCs 2010s REST Tools open to the world, modern services “must” have endpoints 2020s GraphQL Interoperability, and conventions are poor, someone tried to solve that API Evolution Timeline
- 22. Context is King
- 23. 2000s SOAP, XML based Mostly constrained to internal communication and RPCs 2010s REST Tools open to the world, modern services “must” have endpoints 2020s GraphQL Interoperability, and conventions are poor, someone tried to solve that API Evolution Timeline
- 24. 🔮 2000s SOAP, XML based Mostly constrained to internal communication and RPCs 2010s REST Tools open to the world, modern services “must” have endpoints 2020s GraphQL 2025+ MCP We need to fight against short context windows of LLMs and make them appear smarter Interoperability, and conventions are poor, someone tried to solve that API Evolution Timeline
- 25. MCP ● Rich context sharing ● Function calling ● Standardized formats ● Natural both for humans and machines
- 26. MCP ● Rich context sharing ● Function calling ● Standardized formats ● Natural both for humans and machines Security!
- 27. The “Future” of Tech Interviews
- 28. Is it really a “new” discussion? ● Syntax recall ● Algorithm memorization ● Whiteboard pressure VS ● Problem definition ● Solution evaluation ● Architectural Thinking
- 30. When anyone can generate code on demand, what are we really testing?
- 31. A saner interview process 01 Problem solving sessions Collaborative problem solving sessions: work with us, how do we tackle X? 02 System Design System design with real world constraints: Dependency management, security… 03 Assessing existing codebases 04 Tool use Show us your toolbelt: what do you do when you get stuck? How is this piece of software going to bite us in the future? What would you do to isolate the problem?
- 33. It’s a tough time to be a junior engineer
- 34. But also a great opportunity
- 36. Some Advice for Newcomers to the Field and 🦖like Myself ● Software engineering will be more about “engineering” than ever before: ○ Less metawork ○ More about problem solving ● People who know how to “make things” will have more opportunities ○ Someone said modern teenagers only want to be “content creators”: good, because that’s what software will be about. ○ You better cultivate unique skills and superpowers. ○ And you better be ready to experience an ever changing landscape. ● Don’t fear the change, we have survived the advent of personal computing, the Internet, the Cloud, the Mobile devices… ● Bonus point: good “product people” will have more opportunities in software development.
- 37. Sources: Github Octoverse 2024 and Trends 2018
- 38. Sources: Github Octoverse 2024 and Trends 2018 Our job is safe Just imagine how much technical debt all these people are creating
- 39. Lots of Work to do on Conventions. Real Time to Batch ● A lot of the software that powers big systems is making (again) batch computing regrow ● We’ve spent 10+ years creating “good” primitives for real time computing ● We need to move past the point where lots of good AI is being developed and “deployed” on Jupyter notebooks. ● Cloud providers are not adapting to this transition (they are more interested in selling their high margin products) ● There are a bunch of new players in the field: modal.com, replicate.com and CloudFlare (among others) seem to understand where this is going.
- 40. Discussion
- 41. Some thought provoking statements Will junior developer roles as we know them exist in 5 years? Most custom-built infrastructure will be obsolete In the future, complex cloud architectures will be considered technical debt.
- 42. Thank You David Poblador i Garcia david@poblador.com // davidpoblador.com