Functional programming forms pits of success where you naturally fall into the same ‘best practices’ that you have to deliberately work for in object-oriented programming.

Every programming paradigm is opinionated. Different paradigm have different best practices. Take the example from the talk, ports and Adapters pattern might be a perfect fit in a language (F#), but it may have a hard time in another language (C#).

So the analogy of "bell" vs. "bowl" is really powerful. Think before you make a technical choice: Is this technology a "bowl" that can keep me in the stable state I want? Or is it a "bell" that I need to fight to stay in the stable state?

• Using railway track as a metaphor, we have created a number of useful building blocks that will work with any data-flow style application.

  “constructors”

  are used to create new track.

  “adapters”

  convert one kind of track into another.

  “combiners”

  link sections of track together to make a bigger piece of track.

Another great thinking from F# community. (Maybe I should look into F# someday.) At its core, it's the power of composable functions.

In Elixir, we use with statement to write railway oriented programs:

with {:ok, result1} <- step1(),
     {:ok, result2} <- step2(result1) do
  # ...
else
  {:error, error1} ->
    # ...
  {:error, error2} ->
    # ...
end

One-on-one meeting is one of the most important management tool.¹ It's mentioned and recommended in tons of management books. But most of these books are about management in general, not one-on-one in specific. So I was really happy when this book went public. Because this book focuses on this single topic, and does a great job to explain what one-on-one meeting is, why one-on-one meeting is important, and how to host one-on-one meeting.

I would recommend this book to anyone who want to learn more about one-on-one meetings.

• What's "Yes, if"?

  Yes, if you can show that each iteration was a useable milestone.
  

• Benefits of "Yes, if"?
  • This sort of “yes, if” approval means that the design author isn’t blocked and doesn’t need to wait for the approver to read again later.
  • It’s also more encouraging than a flat “no.” The approver is working with the author to get the best possible design; they’re not gate-keeping.

When projects get bigger and bigger, when more and more people get involved, we can't just hack some code together and ship it randomly. We need some change management process, to plan what to change and how to change it. RFC is a battle-tested process to do that. (See Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs)

You may not follow the RFC way strictly. But at the end of the day, change management is all about communicating and discussing

1. Why do we need this change? (Goals and non-Goals, Background and Motivation)
2. What are we gonna change? (Current state, Desired state)
3. How are we gonna implement the change? (Steps, Timeline, Dependencies, Alternatives)
4. Who are gonna implement the change? (Leader, Members, Collaborators)

for any system there is a certain amount of complexity which cannot be reduced.

Every feature, every product, every system comes with its own complexity. Even 1+1=2 is extremely complex if we dig deeper into Group theory or Abstract Algebra. We take it for granted because we've learned it early on. If 1+1=2 is complex, what about our fancy new features? That's why we should be extremely careful and conservative when adding new features.

Here are some great posts explaining Tesler's Law.

• Simplicity is Overrated - Marvel Blog
• Explaining the Law of Conservation of Complexity - Humanist
• Simple is Complex – avdi.codes (which does not mention Tesler's Law directly, but it's the same thinking)

• Resource efficiency is about optimizing at the level of the individual.
• Flow efficiency is about optimizing for the feature (for the team).
  • Your customers buy features. They don't buy your busy-ness.

A great series about why we should optimize for the team efficiency (rather than individual efficiency), and how to do that.

Optimizing for team efficiency is also a value-driven thinking. "Your customers buy features" reminds me of a similar quote from Million Dollar Consulting:

No one is paid to take action, people are paid to achieve results.