Good talks/podcasts (Jan 2024 II)

 

These are the best podcasts/talks I've seen/listened to recently:

• Rockstar Developers Are THE WORST Developers (Dave Farley) [Engineering Career, Engineering Culture] [Duration: 00:17] Dave explains clearly why what the industry often calls a RockStar developer is by no means a good developer, and why we should change that definition to focus on teams and disciplined developers who work in teams rather than individually. My notes on the topic: https://www.eferro.net/2024/01/be-humble-no-rockstars-allowed.html
• Polly Want a Message (Sandi Metz) [OOP] [Duration: 00:41] A good talk by Sandi about how to create and evolve applications with good OO design. Like all of Sandi's talks, it is very worthwhile.
• DDD Europe 2023. A Daily Practice of Empirical Software Design (Kent Beck) [Small Safe Steps (3s), Software Design, XP] [Duration: 00:59] Interesting reflection on the economics of software design and the principles that affect it. This talk describes some of the ideas that Kent elaborates on in detail in his new book 'Tidy first?'
• GeePaw Hill on Incremental Software Delivery (GeePaw Hill) [Small Safe Steps (3s), Software Design, XP] [Duration: 01:18] (⭐⭐⭐⭐⭐) Pure wisdom on why working in small, safe steps is the most efficient way to work in software product development when we have environments of high uncertainty (which is almost always).
• “Industry Changing Book” | Jez Humble & Dave Reflect On Continuous Delivery (Jez Humble, Dave Farley) [Continuous Delivery] [Duration: 01:06] This is an interesting talk by the two authors of the book 'Continuous Delivery' about the impact the book has had on the industry.

Reminder: All of these talks are interesting, even just listening to them.

Related:

• Recommended Talk/Podcast Database
• Recommended resources tag

Best talks that I recommended in 2023

 As some of you know, I maintain a database of the talks and podcasts that I watch or listen to. I usually save a description, the topics discussed, and a rating. I often use this database to make recommendations or to search for ideas and content.

This is the list of all the talks or podcasts that I recommended during this past year (2023) and to which I assigned a rating of 5/5:

• "Simple Made Easy" (12-minute redux) by Rich Hickey (2011) (Rich Hickey) [Architecture, Inspirational, Scalability, Software Design] [Duration: 0:12] This is a 12-minute redux of the 1-hour talk by Rich Hickey, for really impatient people. Original: https://www.youtube.com/watch?v=SxdOUGdseq4
• Architecture for Flow with Wardley Mapping, DDD, and Team Topologies (Susanne Kaiser) [DDD, Engineering Culture, Technology Strategy, Wardley maps, team topologies] [Duration: 0:43] This talk illustrates the concepts, connects the dots between DDD, Wardley mapping and team topologies, and demonstrates how these techniques help to evolve a fictitious legacy system for a fast flow of change.
• Master Class with Marty Cagan (Marty Cagan) [Inspirational, Product, Product Discovery, Product Leadership, Product Team, leadership] [Duration: 1:21] A great presentation on skilled product teams and leading product organizations. The questions at the end are also very interesting.
• Artificial Intelligence seen from the software development lifecycle perspective (Nerea Luis) [AI, MLOps] [Duration: 0:54] Great introduction to the differences between traditional software development and the development cycle with AI models. Nerea introduces concepts such as Continuous training, model deployment, MLOps, and collaboration between data scientists and software engineers. Highly recommended for software engineers looking to delve into these topics and collaborate more closely on AI-based feature development.
• CONSTANT Changes To User Requirements Drive Me CRAZY (Dave Farley) [Agile, Continuous Delivery, Inspirational, Lean Product Management, Lean Software Development] [Duration: 0:13] This presentation by Dave Farley shows that software development is not just about translating perfect requirements into code, but rather a process of discovery and exploration. It acknowledges that the nature of the problems being solved has changed and that it is impossible to have all the answers. It emphasizes that successful software products must be able to adapt and evolve over time, and that the key to success is embracing change and making it easy, safe, and low-cost.
• Systems Thinking for Developers (Jessica Kerr) [Inspirational, Mental models] [Duration: 0:55] Great explanation of how system thinking arises and its basic concepts. System thinking is a fundamental tool to work with/in complex systems such as software systems.
• Simon Sinek Performance vs Trust (Simon Sinek) [Company Culture, Culture, Inspirational] [Duration: 0:02] Great description of the impact of trust on team members and leaders.
• Improving Software Flow (Randy Shoup) [Devops, Flow, Inspirational, Lean, Lean Software Development, Technical leadership, leadership] [Duration: 0:50] In this session, Randy explains how they improve the overall flow and the engineering capacity following the ideas in the Unicorn Project (Locality and Simplicity, Focus, Flow, and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus). It is an excellent talk about generating/improving an engineering culture following lean principles.
• Many More Much Smaller Steps with GeePaw Hill (GeePaw Hill, Chris Lucian, Austin Chadwick) [Evolutionary Design, Lean Software Development, Software Design, Technical Practices, XP] [Duration: 0:39] Good conversation about GeePaw Hill's software development approach based on taking continuous small safe steps (Many More Much Smaller Steps).
• Tips For Technical Startup Founders | Startup School (Diana Hu) [Inspirational, Lean Software Development, Lean Startup, startup] [Duration: 0:28] Diana Hu shares her advice for being a technical founder at the earliest stages - including topics like how to ship an MVP fast, how to deal with technology choices and technical debt, and how and when to hire an engineering team.
• Oredev 2011: Sleeping with the enemy (Gojko Adzic) [Engineering Culture, testing] [Duration: 0:52] Gojko Adzic describes why independent testing should be a thing of the past. He explains how testers engaging with developers and business users create opportunities to accomplish things they cannot do otherwise.

It should be noted that I recommended them last year, but that does not imply that the talk or podcast is from 2023, in fact I think most of them are much older.

I hope you find these recommendations helpful.

Good talks/podcasts (Jan 2024 I)

 

These are the best podcasts/talks I've seen/listened to recently:

• Big Transitions in Small Steps (Kent Beck) [Agile, Software Design, Technical Practices] [Duration: 0:59:00] (⭐⭐⭐⭐⭐) Very deep ideas about how to make any kind of huge technical change using small and incremental changes. This part of the core of agile... Vertical slicing to make changes in small (low risk) steps.
• Laloux Culture Model and Agile (AgileForAll) [Agile, Company Culture, Culture, Inspirational, Lean] [Duration: 0:09:00] (⭐⭐⭐⭐⭐) An overview of Frederic Laloux's Reinventing Organizations and how it relates to Lean and Agile Adoption.
• Compliance standards should be modern development practices (Charity Majors) [Compliance, Engineering Culture, Security] [Duration: 0:37:00] Great talk in which Charity explains how to maintain good engineering practices in regulated environments while meeting the corresponding compliance requirements. The talk doesn't have a high level of detail, but provides ideas for a general approach.
• Paul Akers - How to apply lean thinking to your business for success (Paul Akers) [Lean, Lean Manufacturing] [Duration: 0:57:00] (⭐⭐⭐⭐⭐) Very interesting conversation with Paul Akers who speaks from experience on how to apply lean thinking and continuous improvement.
• A Young Lady's Illustrated Primer to Technical Decision-Making (Charity Majors) [Engineering Culture, Technical leadership] [Duration: 0:41:00] (⭐⭐⭐⭐⭐) Fun and interesting talk about the context and process for making technical decisions. Very good ideas. The talk is a few years old, but the ideas are still very valid. Charity talks about how to decide to introduce new technologies, the cost of maintaining them, the importance of migrations, failure modes, etc.
• Solomon Hykes Discusses Dagger, DevOps, and Docker (Solomon Hykes) [Continuous Delivery, Developer Productivity, Devex, Operations] [Duration: 0:43:00] Interesting podcast about the current problems of CI/CD pipelines and how they aim to solve them from Dagger. There are also interesting opinions from the perspective of creating technical products geared towards developers and about the development experience.

Reminder: All of these talks are interesting, even just listening to them.

Related:

• Recommended Talk/Podcast Database
• Recommended resources tag

Be humble, no Rockstars allowed

Continuous delivery is based on the idea that when dealing with uncertainty and complex problems (as described in the Cynefin framework), the best approach is to assume we don’t already know the solution. Instead, we must commit to continuously learning about both the problem and the optimal solution. Moreover, continuous delivery encourages us to implement systems that effectively manage errors—because we are bound to make mistakes—while minimizing their impact.

If we assume that we do know the solution, or if the problem is straightforward (or just "complicated" within the Cynefin framework), continuous delivery and iterative learning might not be the most efficient approach. In such cases, a direct solution delivered by a team with prior experience can work better. However, in this scenario, don’t expect to gain new insights or improve the process further. And if the problem has already been solved before, reproducing the solution could simply be wasteful—something we should avoid at all costs.

As Kent Beck aptly put it:

"The only way it's all going to go according to plan is if you don't learn anything."

My experience and context

In my case:

• I assume that the solutions I come up with are rarely the best ones.
• I acknowledge that we (myself included) make frequent mistakes—even with something as simple as writing "Hello, World" correctly on the first try.
• I recognize that we still have a lot to learn—about the domain, the business, tools, needs, and everything else.
• I have never worked in a simple or purely complicated context where a ready-made solution was available. And if I ever did encounter such a case, I would avoid reinventing the wheel to minimize waste.

Within this context, the discipline of lean product development, coupled with practices like continuous delivery (focusing on continuous flow), continuous learning, and sustainable quality, remains the best strategy I know.

For Self-Sufficient Experts

If you consider yourself an expert in everything, someone who rarely makes mistakes and feels like a 'rockstar' in their field, you might believe that you don’t need continuous delivery. I suspect that humility and the recognition that EVERYONE (including yourself) makes mistakes might be lacking in this case. Perhaps I’m wrong, and you’re some mythological being who never errs and doesn’t need to learn continuously. If that’s the case, my apologies… :)

However, I won’t be able to work with you since I do make mistakes and need to be part of a team that uses techniques enabling us to develop products despite our errors, all without living in constant stress.

In summary

I believe the general trick of this profession is to work as a team in the best way we know how, using the best techniques we have, and still assuming that:

• We are going to make mistakes.
• We have to keep learning.
• We need to improve continuously.
• We need a level of quality that allows us to work sustainably.

The discipline of continuous delivery (CD, TBD, TDD, etc.) provides all of that for me.

Please...

• Be a great team player. Collaborate and get involved.
• Create a safe learning environment for your team.
• Program as well as you can but assume you will fail, so build an environment where failing is manageable and has minimal impact on customers.
• Make the best architectural decisions you can, but assume they will need to evolve and improve over time.
• Seek continuous delivery as a goal—it fosters the right discipline and creates a safe, sustainable work environment.
• Be humble and accept failure, uncertainty, and your own limitations.

I don’t want to work with Rockstars, nor with x10 developers… I want to work in x10 teams and environments where learning is constant, questioning is welcomed, errors are accepted (because they are low-cost), and improvement is continuous.

Remember:

We need professionals, not heroes.

“I’m not a great programmer; I’m just a good programmer with great habits.” — Kent Beck

Low friction cli tools using docker

Although I last wrote about technical topics here a while ago, I would like to share some ideas that are helping me reduce friction in creating tools for my colleagues at ClarityAI.
As the Platform Lead, among other things, I am involved in the development experience, which means that my team creates tooling (as part of our platform) for the rest of the engineering and data science teams in the company. This tooling includes command-line tools that help users use our platform with minimal friction and autonomously (without requiring support).
In our case, this means we want command-line tools with the following characteristics:

• Usable on Linux and Mac
• Low friction for usage (easy installation and usage)
• Easy to evolve
• Easy to distribute to all our users
• Few external dependencies so that our users don't have to install additional tools

In this context, and considering that we are already heavy users of Docker, it is a good idea to implement these types of tools as Docker images that our users can use.
This would allow us to include any external tools our users may need in the Docker images and eliminate friction by not requiring them to install those tools.

At the same time, using Docker presented its own challenges:

• Difficulty in distributing a Docker image from a private repository
• Difficulty in usage for execution requiring many parameters (volumes, environment variables, execution parameters and arguments, etc.)

Below, I will explain how we have solved (or are in the process of solving) each of the mentioned challenges.

Controlled Environment

Any modern development platform is implemented using different technologies and solutions.
This means the user must use different clients for each of these technologies (kubectl, AWS CLI, Git, Teleport, etc.).
To eliminate friction, avoid installation problems, and reduce the number of potential issues due to misuse or using incorrect versions, what has worked very well for us is to include all these tools (with controlled versions and environment) in a Docker image along with code to control their usage and configuration.
This allows the platform team to forget about problems caused by using the wrong version of kubectl or incorrect AWS client configuration.

Installation

If the installation process of a tool is complicated, you can be sure that a significant percentage of users will encounter problems and require support.
It is often assumed that good documentation is sufficient, but no matter how good the documentation is, if there are many steps to follow and many tools to install, there will be problems.
A better solution is to create a specific installer without configuration and with the fewest possible dependencies.
In our case, the tool to be distributed was built with Docker and stored in a private repository (AWS ECR).
As a lean team, we have iteratively improved the solution, reducing friction at each step:

1. Installation instructions are documented in the engineering handbook. It depends on Docker, properly configured AWS CLI, and knowledge of ECR.
2. Installer script in the code repository. It improved the experience and generated a helper script for future usage. It depends on Docker and properly configured AWS CLI but does not require knowledge of ECR.
3. Cross-platform installer implemented with Golang. This is the version currently in development. It only requires Docker, and the user has an AWS Key. (Example: ECR Docker image puller / installer)

Execution

When we create an open-source solution or a product that will be used in different environments, the ability to configure and adapt it to different environments is crucial.
But when we develop a tool for our colleagues and our goal is to minimize friction and reduce cognitive load, we need to provide the minimum necessary flexibility.
We can even avoid the need for any parameters. 
This becomes a challenge when you have a tool built with Docker that requires multiple credentials and the ability to modify files on the user's machine, as it requires running Docker with many parameters and environment variables.
Once again, iteration has allowed us to improve the solution. The steps we have taken are:

1. Document all the parameters and environment variables for tool execution in the README. This serves us well for development, but we never intended for our users to use the tool following this documentation.
2. Using an execution script that hides all the parameters and variables. In our case, this execution script was generated by the installer.
3. Cross-platform wrapper implemented in Golang. This allows us to distribute a binary that only depends on having Docker and hides the tool's complexity. This is the version we will distribute soon. (Example: Simple wrapper to execute (interactive/non interactive) docker image)

Continuous Updating

In addition to facilitating installation, it is essential that the platform team can quickly push new versions. In this case, having Docker already facilitates this because simply uploading new versions to the Docker repository makes them available to our users.
On the other hand, to streamline the update process, what has worked well for us is to include an option in the execution script/wrapper to check and download new versions.
Initially, we made it so that each execution would check for new versions, but we found that it caused too much delay during startup, so now we prefer to let the user decide when to update.

Conclusions:

• Docker allows packaging applications with specific versions in a controlled environment.
• Creating a cross-platform wrapper in Go is an excellent solution to eliminate friction in the distribution and execution of tools implemented using Docker.
• Investing in making installation and updating simple allows tools to evolve rapidly without generating much friction.

Updated My Personal Mission. Same Essence, Different Words

 

Eduardo Ferro's Personal Mission

Cultivate Happiness: Foster personal joy and spread happiness to those around me, starting with family and friends, while continuously expanding my circle of influence.

Methods of Achievement

• Responsibility and Respect: Uphold personal accountability and respect for others in all interactions.
• Balance Seeking: Strive for a harmonious balance in personal life and contribute towards global equilibrium.
• Authenticity: Remain true to myself in every aspect of life, including professional pursuits.
• Value Generation: Utilize my abilities to create both intrinsic and economic value, mindful of social and ethical considerations.
• Win-Win Scenarios: Continually seek outcomes that are mutually beneficial.
• Continuous Learning: Embrace lifelong learning, both personally and professionally.
• Conscious Decision-Making: Choose my reactions and actions thoughtfully.

Ethical Stance

Selective Engagement: Refrain from involvement with businesses that conflict with my values, including:

• Financial enterprises that prioritize profit over social and environmental responsibility.
• Weapon manufacturers and the military industry.
• Casinos and gambling enterprises.
• Entities involved in the abuse or exploitation of humans, animals, or the environment.
• Businesses that negatively impact the lives of stakeholders.

Vision for the Future

I believe we are at a pivotal moment where our actions can significantly impact the planet, both positively and negatively. It's crucial to remember this responsibility at all times. We are amidst a revolution that blends collaboration, knowledge, and a federation of power. Networks are becoming the structures of the future, and their growth should be both sustained and sustainable.

Professional Alignment

My focus is on engaging with green and teal organizations, where people are valued as the primary asset. I am drawn to environments that prioritize sustainable and ethical practices, recognizing the importance of human capital in driving positive change.

Personal Commitment

I engage with the world passionately and responsibly, yet always at a measured pace, ensuring a balanced approach in all my endeavors.