It’s common sense that in order to build large systems, a good strategy is to start with a simple base model and iterate until the whole system satisfies the desired criteria.

This was one of the core ideas behind the Agile Manifesto.

But there are other, more mature, human-built systems around: in law, math, physics, biology, etc.

Yes, we must start from a simple idea and iterate, but at some point, we have to take a step back and figure out hidden patterns and principles.

I’m not an expert, but look at memory safety mechanisms: garbage collection at runtime and the borrow checker at compile time. These concepts didn’t just happen by going “agile all the way” to the solution.

At some point, families of problems are categorized and defined from first principles, always looking to solve both the original specific case and the more general problem patterns that we find.

This isn’t the common path in most software agile projects.

Iteration is a good thing, but taking a step back to think can solve problems that wouldn’t be solvable any other way.

I would love to hear your thoughts on this topic.

Thank you for reading this post.

It has long been know that the period of a simple pendulum,​​

where L is the length of the pendulum and g is the gravitational constant.

One of the main reasons for the mechanical efficiency and low energy demand, since its governed by gravity, are the small corrections that it requires to maintain its swing.

Applied at resonance, this perturbation energy is maximized, requiring minimal input to maintain the pendulum’s amplitude:

I’ve been in the software industry for some time and I’ve worked with teams with different dynamics. If I had to chose a word to express the feeling I have when working with such teams it would be resonance.

Like in the pendulum example, communication, coordination, requests for help were effortful. Small corrections were sufficient to get things back in track.

That doesn’t mean problems did not exist or that work was not hard but the momentum created within the team was unstoppable. Usually quiet people went the extra mile to help the team. Nobody was afraid to communicate problems and everyone worked together to try to workaround them.

It was not about the company - there were other teams in which this kind of resonance just did not happen. And its not about the person - the same person in another company did not have other option than go through the motions like everybody else.

All I know is that I’ve seen it and felt this phenomenon - the results were there despite the corporate culture that surrounded us.

Here are some things that I noticed in those teams:

• People were actually happy to be in the meetings

• Everyone was allowed to speak their mind - there’s no mandatory “only work talk here”

• People often cracked some jokes when under pressure

• Everyone jumped in to help solve a problem - there’s was no blame culture

• Mission and client needs oriented, no selfish agendas playing behind the scenes

• Some people were more productive than others but everyone was respected, no playing favorites

• Everyone was important - no one was excluded

I’m sure it’s possible to be productive in other types of teams - but most people spend a large part of their lives at work, and working in a boring or stressful team is not what most people think of living a fulfilling life.

Maybe the classic pendulum model is not the best example since this is a resonance phenomenon in a classic linear system.

Maybe resonant teams follow more a chaotic resonant model with order emerging from chaos, but not a destructive chaos, more like a dynamic and creative chaos, where energy flows unpredictably but constructively, allowing for spontaneous innovation and adaptive problem-solving.

I've been writing on my blog about following a ketogenic diet to manage my mental health. One of the major wins I've been able to achieve so far is losing over 20 kg in the last couple of months.

I have been tracking my weight every week for about 8 weeks now and thought it would be interesting to implement a simple DNN machine learning model to fit that data and try to extrapolate my weight loss into the near future. After several iterations and adjustments, I worked with ChatGPT to generate this Python script to:

• Fit a function to my weight loss data and visualize it on a graph.

• Create a graph showing my calorie loss rate.

I chose to use a simple feedforward DNN model to capture the non-linear nature of the weight loss time series. I assumed a basic DNN model would be easy to implement, train, and fast in inference mode.

Additionally, I used the Harris-Benedict Equation to create a graph of the daily calorie needs required to maintain my weight at each point in the weight loss series. This graph can be compared to the real weight loss rate to understand how many calories I was below the maintenance level at each point:

The Harris-Benedict Equation, often referred to as the Harris weight loss function, is a well-established mathematical model used to estimate an individual's Basal Metabolic Rate (BMR) and Total Daily Energy Expenditure (TDEE). BMR refers to the number of calories your body needs to perform basic physiological functions like breathing, circulation, and cell production when at rest. The equation also helps calculate how many calories you need to maintain your current weight and can be adjusted to estimate calorie needs for weight loss or gain.

Here’s a diagram of the simple feedforward DNN model:

And here’s the final graph showing the non-linear function fit to my weight loss series, along with two graphs tracking calorie metrics to better understand the metabolic dynamics behind the process:

There’s an initial large drop, followed by a gradual decrease and stabilization in my weekly calorie deficit after starting the ketogenic diet. Interestingly, the weight loss function shows a near-constant decrease rate throughout the process, even as my calorie restriction (relative to the calculated Harris-Benedict BMR and TDEE) seems to have stabilized at a level that keeps me feeling satisfied without much effort.

Below is the source code I used to generate the graphs (it can run on a regular CPU in about 30 seconds):

import os
import numpy as np
import pandas as pd
import tensorflow as tf
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import MinMaxScaler
import matplotlib.pyplot as plt
from datetime import datetime, timedelta

# Disable GPU and force TensorFlow to use only the CPU
tf.config.set_visible_devices([], 'GPU')  # Disable GPU usage

# Harris-Benedict Equation for BMR (Male)
def harris_benedict_bmr(weight, height_cm, age, gender='male'):
    if gender is 'male':
        return 88.362 + (13.397 * weight) + (4.799 * height_cm) - (5.677 * age)
    else:
        return 447.593 + (9.247 * weight) + (3.098 * height_cm) - (4.330 * age)

# Activity factor (e.g., sedentary)
activity_factor = 1.2

# Input your data
data = {
    'Date': [
        '2024-08-25', '2024-09-01', '2024-09-08', '2024-09-15', 
        '2024-09-22', '2024-09-29', '2024-10-06', '2024-10-13', '2024-10-19'
    ],
    'Weight': [146.9, 143.5, 141.9, 139.8, 137.5, 135.8, 133.9, 133.0, 131.7],
    'Age': 50,
    'Gender': 'Male',
    'Height': '1.78m'
}

# Create a pandas DataFrame
df = pd.DataFrame(data)

# Convert the Date column to datetime
df['Date'] = pd.to_datetime(df['Date'])

# Calculate days since the start date
start_date = df['Date'].min()
df['Days'] = (df['Date'] - start_date).dt.days

# Prepare features (days) and target (weight)
X = df['Days'].values.reshape(-1, 1)
y = df['Weight'].values.reshape(-1, 1)

# Normalize the data (helps with training stability)
scaler_X = MinMaxScaler()
scaler_y = MinMaxScaler()

X_scaled = scaler_X.fit_transform(X)
y_scaled = scaler_y.fit_transform(y)

# Split the data into training and testing sets (80/20 split)
X_train, X_test, y_train, y_test = train_test_split(X_scaled, y_scaled, test_size=0.2, random_state=42)

# Build a simple DNN model using TensorFlow/Keras
model = tf.keras.models.Sequential([
    tf.keras.layers.InputLayer(input_shape=(1,)),  # Define the input layer correctly
    tf.keras.layers.Dense(64, activation='relu'),  # Hidden layer with 64 units
    tf.keras.layers.Dense(64, activation='relu'),  # Hidden layer with 64 units
    tf.keras.layers.Dense(1, activation='linear')  # Output layer (predicts the weight)
])

# Compile the model
model.compile(optimizer='adam', loss='mean_squared_error')

# Train the model
history = model.fit(X_train, y_train, epochs=200, validation_data=(X_test, y_test), verbose=0)

# Make predictions starting from the initial days
days_range = np.linspace(df['Days'].min(), 300, 300).reshape(-1, 1)
days_range_scaled = scaler_X.transform(days_range)
predicted_weights_scaled = model.predict(days_range_scaled)
predicted_weights = scaler_y.inverse_transform(predicted_weights_scaled)

# Ensure weights start from 146.9 kg and end at 130 kg
mask = (predicted_weights <= 146.9) & (predicted_weights >= 130)
filtered_days_range = days_range[mask.flatten()]
filtered_predicted_weights = predicted_weights[mask.flatten()]

# Calculate BMR and daily calorie needs for each predicted weight
height_cm = 178  # height in cm (1.78m)
age = 50  # age
gender = 'male'

predicted_calories = np.array([harris_benedict_bmr(w[0], height_cm, age, gender) * activity_factor for w in filtered_predicted_weights])

# Calculate real calorie loss rate (daily) based on weight differences
real_calorie_loss_rate = np.diff(filtered_predicted_weights.flatten()) * 7700 / np.diff(filtered_days_range.flatten())

# Plot all three graphs on the same figure
fig, ax1 = plt.subplots()

# First axis (left): Predicted weight
ax1.set_xlabel('Days Since Start')
ax1.set_ylabel('Weight (kg)', color='tab:blue')
weight_line, = ax1.plot(df['Days'], df['Weight'], 'o-', label="Recorded Weights", color='tab:blue')
prediction_line, = ax1.plot(filtered_days_range, filtered_predicted_weights, '-', label="DNN Predictions", color='tab:blue')
ax1.tick_params(axis='y', labelcolor='tab:blue')
ax1.set_ylim([130, 146.9])  # Limit the weight axis to 130 to 146.9 kg

# Add labels to the data points in the weight graph
for i, txt in enumerate(df['Weight']):
    if 130 <= df['Weight'][i] <= 146.9:
        ax1.annotate(f'{txt:.1f}', (df['Days'][i], df['Weight'][i]), textcoords="offset points", xytext=(0,5), ha='center')

# Second axis (right): Daily calorie needs
ax2 = ax1.twinx()
ax2.set_ylabel('Daily Calorie Needs (kcal)', color='tab:red')
calories_line, = ax2.plot(filtered_days_range, predicted_calories, '--', label="Predicted Calories", color='tab:red')
ax2.tick_params(axis='y', labelcolor='tab:red')
ax2.set_ylim([2000, 3200])  # Increased the upper limit for calorie needs axis to show the full graph

# Add labels to the calorie points more sparsely (every 20th point)
for i in range(0, len(predicted_calories), 20):
    ax2.annotate(f'{predicted_calories[i]:.0f}', (filtered_days_range[i], predicted_calories[i]), textcoords="offset points", xytext=(0,5), ha='center')

# Third axis (right, offset): Real Calorie Loss Rate
ax3 = ax1.twinx()
ax3.spines['right'].set_position(('outward', 60))  # Offset the third axis to avoid overlap
ax3.set_ylabel('Real Calorie Loss Rate (kcal/day)', color='tab:green')
calorie_loss_rate_line, = ax3.plot(filtered_days_range[:-1], real_calorie_loss_rate, ':', label="Real Calorie Loss Rate", color='tab:green')
ax3.tick_params(axis='y', labelcolor='tab:green')

# Add labels to the real calorie loss rate points more sparsely (every 10th point)
for i in range(0, len(real_calorie_loss_rate), 10):
    ax3.annotate(f'{real_calorie_loss_rate[i]:.0f}', (filtered_days_range[i], real_calorie_loss_rate[i]), textcoords="offset points", xytext=(0,5), ha='center')

# Finalize the plot
fig.tight_layout()
plt.grid(True)
plt.show()

I had fun doing this exercise and I’m looking forward to writing about more machine learning projects, especially computer vision applications, in future blog posts.

I hope this was helpful for someone, and I wish you the best in your own endeavors!

As I was struggling with my mental health, one of the most frustrating things for me was my inability to focus at work. I was familiar with the concept of "monkey mind" through my meditation practice and tried everything I could to improve my focus—especially on my software engineering tasks.

I practiced meditation, took walks to clear my mind, used a note-taking app to plan my tasks in excruciating detail—but no matter what I did, I could never match my teammates' ability to sit down and completely focus on their work.

Over time, I learned to deliver results mostly through sheer grit and determination. By the end of each week, I was utterly exhausted, and no matter how much time I took off, I never seemed to fully replenish my energy.

I assumed this was my normal state until I read about Dr. Palmer's use of the ketogenic diet to treat metabolic and mental illness (you can learn more at Brain Energy). I followed him on YouTube and X, and decided to try the diet myself. After all, I had nothing to lose and could always return to my previous, though less-than-optimal, lifestyle.

A few weeks in, I started experiencing something new—consistent energy throughout the day. I lost 22kg, and most importantly, the "monkey mind" that had always plagued me began to quiet down. I was able to focus for long hours without much effort, and my energy felt fully restored after a good night's sleep.

I never expected such a dramatic change at this point in my life, but it feels like I've been given a second chance to contribute to the community, free from the mental fog that always held me back from reaching my full potential.

I hope that by sharing my story, others might find hope and consider trying this approach for themselves. You can find more information at metabolicmind.org, where many doctors and researchers are working hard to bring new therapies for people struggling with metabolic and mental health issues.

I hope this post was helpful, and I wish you the best of luck in your own journey!

One of the most impactful insights I had during my career as a software developer is the discovery of thinking out loud (TOL) and how it can help overcome that initial resistance between when we start working on a task until we feel the momentum letting us enter a state of flow.

It is my conviction that TOL is a hard skill and that this is a skill not commonly discussed within software teams. In the absence of having someone more experienced to discuss a work problem with, TOL definitely comes second place as a trainable skill with a considerable impact on our productivity.

Examples:

1. Debugging a complex issue:

Imagine you're trying to fix a bug in a large codebase. Instead of silently staring at the screen, you start thinking out loud:

"Okay, the error occurs when the user submits the form. Let's trace the data flow. The form submission triggers the handleSubmit function. What happens inside that function? It calls the API... Wait, are we properly handling errors from the API? Let me check the catch block..."

By verbalizing your thought process, you're more likely to spot inconsistencies or overlooked areas in your reasoning.

2. Preparing for a code review:

Before presenting your code to your team, you might think out loud to organize your explanation:

"I've implemented the new feature using a factory pattern. Why did I choose this? Well, it allows for easy extension of new product types without modifying existing code. What potential drawbacks might my colleagues point out? Hmm, perhaps the increased complexity for simple scenarios. How can I justify this trade-off?"

This process helps you anticipate questions and clarify your design decisions, leading to a more productive code review session.

As I see it, TOL, is not the same as externalising our thoughts. I learned as a meditation practitioner a few years ago that our brain has at least two modes of operation: automatic and deliberate. Simply regurgitating out loud the chaotic thoughts in our minds can even be counterproductive and make us lose motivation.

In my experience, forcing ourselves to think precisely and in an organised manner (which is something we can have the feel for and correct) is a more effective form of TOL when we want to attack and breakdown a complex problem in life or at work.

TOL is especially useful in the following cases:

• Overcoming procrastination and having more productive time within the 8 hours of work without having to resort to working evenings and weekends

• We don't yet know how to start to deconstruct a complex problem

• Our colleagues are all busy and we have no one to discuss our problem with

• Preparing meetings to extract more value from them in a shorter time frame

• By trying to speak out loud in a precise and deliberate way, we also are able to improve more effective communication skills

There is also some literature on the so-called "Thinking-out Loud Protocol," a technique that has been used to discover how software engineers approach debugging and comprehension tasks. This means that we, developers, can use this technique as a form of introspective feedback to identify problems and discover more productive thought patterns and ways of thinking.

We can even record our TOL and do a post-analysis to find potential improvements. In theory, we could even present this self-conversation to more experienced engineers and let them find bugs in our thought process and optimize problem-solving patterns with the expertise they have developed during their extended careers.

With this superpower comes the responsibility of managing our time in moderation. This strategy has a price - the mental wear resulting from the effort expended is substantial, and it's advisable not to abuse this trick for many hours in a row, risking burnout.

But since we've already achieved the holy grail of increasing our focus in the available work time, it's also likely that we can generate the same output but with higher quality in a shorter amount of time than before.

Thank your for reading this article - enjoy the rest of your day!

In light of the recent post, A Developer's Descent: When the Job Search Became a Mental Health Crisis, we conducted a survey to delve deeper into the mental well-being of tech professionals. The tech industry is known for its fast-paced and demanding nature, which can take a toll on the mental well-being of its workers. To better understand the state of mental health in tech, we conducted a survey of 26 tech professionals. The survey asked about various aspects of mental well-being, including stress levels, coping mechanisms, and the role of creativity in tech work.

Key Findings

1. Mental Well-being Concerns:

   

   • The most relevant mental well-being aspects for tech workers are burnout prevention (84.6%), stress management (65.4%), and resilience building (13%). A significant number of respondents (50%) also highlighted addressing mental health challenges as a key concern.

2. Stress Levels:

   

   • The majority of respondents (38.5%) reported feeling stressed due to work-related issues daily, with others experiencing stress several times a week (19.2%) or a few times a month (19.2%). Only a small percentage (1.5%) rarely feel stressed, and even fewer (0.0%) never experience work-related stress.

3. Coping Strategies:

   

   • The most effective strategies for managing stress and preventing burnout include regular breaks (61.5%), physical exercise (61.5%), and time management (46.2%). Mindfulness and meditation (26.9%) and seeking professional help (7.7%) were also mentioned.

4. Creativity in Tech:

   

   • The vast majority of respondents (46.2%) consider creativity to be very important in their coding or development work, with another 42.3% finding it somewhat important. Only a small percentage (7.7%) feel neutral or that it's not very important (2.3%).

5. Flow State:

   

   • Most respondents (57.7%) experience a flow state while working occasionally, while 19.2% experience it very often. A smaller percentage (19.2%) rarely or never (2.3%) experience flow.

6. Healthy Tech Teams:

   

   • The most important factors contributing to a healthy and productive tech team are effective communication (96.2%), psychological safety (69.2%), and diversity and inclusion (34.5%). Conflict resolution mechanisms are also important (50%).

7. Challenges in Building Healthy Teams:

   • The biggest challenges in building a healthy tech team environment, as identified by respondents, are diverse and include issues like communication, lack of support, unrealistic expectations, and toxic personalities. The most common responses were:

     • Slowing down the release schedule and convincing stakeholders that steady, slow development is better than rushed work (18.5%).

     • Capitalism and the company's focus on profit over employee well-being (15.4%).

     • Achieving meaningful constructive communication and dealing with toxic personalities (12.3% each).

8. Work Environment Support:

   

   • The majority of respondents rated their work environment's support for mental health as poor (30.8%) or fair (26.9%). A smaller percentage rated it as very poor (15.4%), good (19.2%), or excellent (7.7%).

9. Company Recommendation:

   • On average, respondents rated their likelihood of recommending their company to a friend or colleague as a 4.76 out of 10, with a standard deviation of 2.45. This suggests a wide range of experiences and opinions about the workplace.

10. Desired Workplace Changes:

    • The most common workplace changes desired to improve mental well-being and productivity include better work-life balance (31%), improved communication and transparency (20.6%), and increased support for mental health (17.9%). Other suggestions include hiring more developers, addressing management issues, and providing more time off.

Conclusion

The survey results highlight the importance of mental well-being in the tech industry. Tech professionals face high levels of stress and often struggle with burnout. However, there are effective strategies for managing stress and building healthy tech teams. By prioritizing mental health and fostering a supportive work environment, tech companies can improve the well-being and productivity of their employees. These findings underscore the issues raised in A Developer's Descent, emphasizing the need for systemic changes in the tech industry to prioritize mental health and create a more sustainable and supportive work environment.

Based on our findings, we recommend the following actionable steps for tech companies:

1. Prioritize Mental Health: Invest in mental health resources and create a culture that destigmatizes seeking help.

2. Foster a Supportive Work Environment: Promote open communication, collaboration, and address toxic behaviors and unrealistic expectations.

3. Promote Work-Life Balance: Encourage regular breaks, time off, and boundaries between work and personal life.

Refer a friend

In The Essence of Software: Why Concepts Matter for Great Design, the author argues that programmers have a robust language and established criteria to distinguish good design from bad. However, no such language or set of criteria exist in the user-facing sense, specifically design that dictates how software is experienced as a form embedded in a context.

The concept of internal code design is crucial primarily for what engineers call "maintainability," performance, and reliability. But the key decisions determining whether an application is useful and fulfills client needs reside elsewhere—in the type of software design where functionality and user interaction patterns are shaped.

It's also worth comparing with domain-driven design, which stems from a set of core concepts in the application domain, with the author’s approach to software design more supported on the user interface where key concepts are defined above the business layer.

These concepts were once central in computer science, but over time they became less fashionable and faded away. Defect elimination—whether through testing or program verification—became synonymous with software quality.

However, if the software has the wrong design, no amount of defect elimination will fix it, short of returning to the start and rectifying the design itself.

Clarity & Simplicity in Design

In his 30 years of teaching experience, the author has become increasingly convinced that the determinant of success in software development is not whether the latest languages and tools are used, the management process followed (agile or otherwise), or even how you structure your code. It's simply whether you know what you're trying to do. If your goals and design are clear—and it's evident how your design meets your goals—your code will also tend to be clear. And if something isn't working, it will be clear how to fix it.

Personal Story

A while back, while trying to implement a feature on the frontend of a codebase, I found myself running in circles. After a few weeks and with the help of a colleague with much more experience in that part of the codebase (thank you, Weslley!), I realized that the reason I was struggling so much to implement the feature was simply that I didn't have a profound understanding of how the user interaction worked in the codebase variants I was working on. It wasn't a language or framework problem but purely ignorance of how the application functioned. My mental model as a user didn't align with the application's conceptual model.

About the Author

The author is a professor at MIT and has a public personal website where one can find more about his research in this topic: https://www.csail.mit.edu/person/daniel-jackson

As he describes in one of the chapters, this book is the result of his explorations to date. As he puts it, the problem of software design is not solved, but "a book should aim to start a conversation, not end one".

I encourage you to read the book and join the software design discussion.

Thank you for reading this post!

If you're finding value in Turing Respawns, I'd be grateful if you'd share it with a friend or colleague. It's a simple way to help our community grow and explore the human side of tech together. Plus, as a thank you, you'll both enjoy free access to all articles.

Refer a friend

In the book "The Moves that Matter: A Chess Grandmaster on the Game of Life," Jonathan Rowson attempts to describe his own concentration process in a game of chess and presents the following puzzle:

This challenge is revealed by a logic puzzle that I love, which I learned from the philosopher of mind John Hawthorne. The puzzle concerns three men on an island who all have blue faces. It is wonderfully convoluted, so please suspend disbelief, forget common sense, and search for the Sherlock Holmes inside.

The situation on the island is a little delicate. The three blue-faced men see each other every day, but none of them can see his own face. They all know that their face is either red or blue, but if any of them discovers the colour of their own face they have to shoot themselves at the next stroke of midnight exactly. Those are the rules. A little twisted, I know, but clear enough to live by.

Careless talk costs lives, so they don’t speak to each other, and never dare to see their own reflection. Yet despite the pressure and ambient tension, they live together in blissful ignorance for several years. Then one day a Scottish tourist called Jim arrives on the island, all the way from Glasgow. Jim chose this island because he was trying to shake off an incipient midlife crisis and couldn’t face the tedium of another beach holiday in Spain.

However, Jim is an accountant, not an anthropologist. After a few perplexing days with the natives he could not handle the tension and felt an uncontrollable urge to make a West of Scotland wisecrack. To his credit, Jim was careful to tell them something he assumed they must already know, and after getting on his boat he said ‘At least one of you has a blue face, eh!’ And off he went from the island, back to Glasgow.

Not that night, not the following night, but on the third midnight, all three men shot themselves. The first question is: Why? The second question is: What was the new information that Jim told them that they didn’t already know? Many intuit the answer to the first question long before being able to articulate the answer to the second.

Here lies the challenge to solve the puzzle - if you are curious to know the answer, please buy the book. Jonathan Rowson explains the solution in detail. Beyond this, it's truly interesting how the author exposes his thought process and dissects it in detail for us all to appreciate.

Thank you for your time. Leave your thoughts in the comments. Enjoy the day!

In "Black Hole Blues and Other Songs from Outer Space" by Janna Levin, the engineering story of LIGO is depicted:

They’re constructing a recording device, not a telescope. The instrument—scientific and musical—will, if it succeeds, record Lilliputian modulations in the shape of space. Only the most aggressive motion of great astrophysical masses can ring spacetime enough to register at the detectors. Colliding black holes slosh waves in spacetime, as can colliding neutron stars, pulsars, exploding stars, and as yet unimagined astrophysical spacetime cataracts.

In a less than perfect analogy, astrophysical calamities are the finger pickers, spacetime is the set of strings, and the experimental apparatus is like the body of the guitar. Or, moving up a few dimensions, astrophysical calamities are the mallets, spacetime is the skin of a three-dimensional drum, and the apparatus records the modulations in the shape of the drum to play the silent score back to us as sound.

A key figure in the development of this "musical instrument" recording the universe's symphony was Rainer Weiss. A prominent physicist, Weiss was one of the chief architects behind the Laser Interferometer Gravitational-Wave Observatory (LIGO). Born in 1932 in Berlin, he and his family fled to the United States during World War II. From an early age, he had a fiery passion for science. Weiss pursued Physics at MIT, later joining its faculty, where his groundbreaking work in gravitational physics and astrophysics began. He was essential in developing the concept and design for LIGO, marking a huge leap forward in the effort to detect gravitational waves. His phenomenal contributions were recognized in 2017 when he shared the Nobel Prize in Physics with Kip S. Thorne and Barry C. Barish for their decisive work on the LIGO detector and the observation of gravitational waves.

The idea came to him during a course he taught on the obscure subject of general relativity, Einstein’s theory of curved spacetime, as a junior professor. Rai says, “[MIT] figured that, hell, I had been to Princeton, so I must know something about relativity, right? . . . Well, what I knew about relativity you could stick in this finger. I mean general relativity. I’m not talking about special relativity.

“And I couldn’t admit I didn’t know general relativity. I mean, here I had started this whole research program to study gravity and I tell them that I don’t know anything about general relativity. I didn’t . . . so okay, I had a major problem on my hands. And I had to be sort of a day ahead of the students. Now all of us have been caught out that way, but I had just been caught out. I couldn’t say no.

“So I teach this relativity course. Now, the reason why that figures in the LIGO story is because that’s where LIGO got invented, in that course. This was about 1968 or 1969, and I was, as I say, one day ahead of the students. I had a terrible time with the mathematics. And I tried to do everything by making a Gedankenexperiment out of it. You see, I was trying to learn it myself. I mean, in the process of learning it, the mathematics was beyond what I really understood. But I kept trying to understand.

“I gave as a problem, as a Gedanken problem, the idea, ‘Well, let’s measure gravitational waves by sending light beams between things,’ because that was something you could solve. The idea was that here was an object. You’d put another object here and make a right triangle of objects, floating freely in a vacuum. And we’d send light beams between them and then be able to figure out, ‘What does the gravitational wave do to the time it takes light to go between those things?’ It was a very stylized problem, like a haiku, you know? You’d never think that it was of any value.”

The idea: Suspend mirrors so they’re free to rock parallel to the earth and watch them toss on the passing gravitational wave. Keep track of the distance between them, and their motions will record the changing shape of spacetime. Since light’s speed is a constant, the time it takes for light to race the track measures the length of the course. If the light travel time is a little longer, the distance between the mirrors has stretched. If the light travel time is a little shorter, the distance between the mirrors has squeezed.

Precision clocks are not good enough to distinguish minuscule variations in travel time. Rai’s idea was to use the floating mirrors to build a far more precise instrument, an interferometer (the roots of the word are “interfere” and “measure”). Instead of bouncing light along one arm, an interferometer sends light down two arms arranged in an L. Laser light is split into two beams, so that one beam travels along one arm of the L and the other travels along the orthogonal arm of the L. Each beam bounces off a mirror at the far end and returns down the respective arm to interfere back at the original apex. The recombined light is then split into two outputs. If the light travels the same distance in each direction, then the light in one output will recombine perfectly so that the output is bright. Light in the other output will combine in perfect cancellation so that the output is dark. If the arms are not the same length the light will come together but imperfectly, out of sync in a sense. The light will interfere with itself.

This beautiful idea underscores the birth of a transformative concept that would ultimately take shape as the Laser Interferometer Gravitational-Wave Observatory (LIGO). This story serves as a powerful testament to the might of inventive thinking, and emphasises how a singular idea, nurtured by a relentless pursuit of knowledge and comprehension, can dramatically reshape our understanding of the cosmos.

Thank you for reading this article. Please leave your thoughts in the comments. Enjoy your day.

Richard Hamming in his book The Art of Doing Science and Engineering talks about the problem of the speed of obsolescence of old knowledge:

It is claimed by many the half-life of the technical knowledge you just learned in school is about 15 years—in 15 years half of it will be obsolete (either we will have gone in other directions or will have replaced it with new material). For example, having taught myself a bit about vacuum tubes (because at Bell Telephone Laboratories they were at that time obviously important) I soon found myself helping, in the form of computing, the development of transistors—which obsoleted my just-learned knowledge!

He poses that one answer for this dilemma is that:

you must concentrate on fundamentals, at least what you think at the time are fundamentals, and also develop the ability to learn new fields of knowledge when they arise so you will not be left behind, as so many good engineers are in the long run.

Hamming then proceeds to attempt to provide answers to two questions:

1. What is it that we talk about when we talk about fundamentals

2. How do you make the choice of which path to invest our effort

Hamming continues by addressing the first question:

How are you to recognise “fundamentals”? One test is they have lasted a long time. Another test is from the fundamentals all the rest of the field can be derived by using the standard methods in the field.

To answer the second question, he employs a standard narrative:

It is well known the drunken sailor who staggers to the left or right with n independent random steps will, on the average, end up about steps from the origin. But if there is a pretty girl in one direction, then his steps will tend to go in that direction and he will go a distance proportional to n. In a lifetime of many, many independent choices, small and large, a career with a vision will get you a distance proportional to n, while no vision will get you only the distance . In a sense, the main difference between those who go far and those who do not is some people have a vision and the others do not and therefore can only react to the current events as they happen.

One of the main tasks of this course is to start you on the path of creating in some detail your vision of your future. If I fail in this I fail in the whole course. You will probably object that if you try to get a vision now it is likely to be wrong—and my reply is that from observation I have seen the accuracy of the vision matters less than you might suppose, getting anywhere is better than drifting, there are potentially many paths to greatness for you, and just which path you go on, so long as it takes you to greatness, is none of my business. You must, as in the case of forging your personal style, find your vision of your future career, and then follow it as best you can.

He concludes with a few words that would be remembered for generations:

Lastly, in a sense this is a religious course: I am preaching the message that, with apparently only one life to live on this earth, you ought to try to make significant contributions to humanity rather than just get along through life comfortably—that the life of trying to achieve excellence in some area is in itself a worthy goal for your life.

It has often been observed the true gain is in the struggle and not in the achievement—a life without a struggle on your part to make yourself excellent is hardly a life worth living. This, it must be observed, is an opinion and not a fact, but it is based on observing many people’s lives and speculating on their total happiness rather than the moment-to-moment pleasures they enjoyed.

Thanks for reading this article. Please share your thoughts in the comments. Enjoy your day!

This comprehensive text draws heavily from the insightful work of Simon Singh, specifically his valuable contribution to Chapter 1 of the book 'Colossus: The secrets of Bletchley Park's code-breaking computers' by B. Jack Copeland. I would like to express my deep respect and gratitude to Mr. Singh for his enlightening work.

THE SUBSTITUTION CIPHER

In Julius Caesar’s Gallic Wars, he describes how he sent a message to the besieged Cicero. The message was encrypted by substituting Greek letters for Roman letters, then delivered in the most dramatic way imaginable. The messenger, unable to reach the camp, hurled a spear with the letter fastened to it with a thong. Although the spear lodged itself in a tower, nobody spotted it for two days. Eventually, it was taken down and delivered to Cicero, who read out the vital news to the entire camp, bringing enormous joy to his troops.

This was the first documented use of a substitution cipher for military purposes. Substitution ciphers, as the name suggests, encrypt messages by replacing the original characters with different characters. This is in contrast to a transposition cipher, in which the characters remain the same, but they are transposed or rearranged to create an anagram.

One of the most famous substitution ciphers is the so-called Caesar cipher, which simply replaces each letter in the message with the letter that is, say, three places further down the alphabet. Cryptographers often think in terms of the plain alphabet, the alphabet used to write the original message, and the cipher alphabet, the letters that are substituted in place of the plain letters, both of which are shown below.

The plaintext is the technical name for the original message, while the ciphertext is the encrypted message. In this chapter, the plaintext is written in lower case and the ciphertext in upper case. Although this example involves a shift of 3, lesser or greater shifts are of course possible.

The Caesar cipher can be generally stated as substituting each plain letter with the letter that is x places later in the alphabet, where x is between 1 and 25. This illustrates one of the basic principles of cryptography, namely the relationship between the algorithm and the key. In the Caesar cipher, the algorithm is the general idea of replacing the original letters with those that lie a fixed number of places further along the alphabet.

The key, x, specifies the distance of the shift. In other words, the key is a flexible component within the algorithm, which needs to be specified in order to determine the exact method of encryption. The key is usually selected by the sender and has to be communicated to the receiver so that the message can be deciphered.

A codebreaker can crack the cipher by identifying the correct key. In this case, the codebreaker can check every key, known as a brute force attack, because there are only 25 keys. A stronger version of the substitution cipher is the general substitution cipher, which allows the cipher alphabet to be any rearrangement of the alphabet.

In this case, there are roughly 400,000,000,000,000,000,000,000,000 possible keys, because this is the number of ways to rearrange the alphabet. Although a large number of keys is not the sole requirement for a secure cipher, it certainly makes the codebreaker’s job harder, because checking every single possible key would be impractical.

Typically, a communications network will use a single algorithm for several months or years, but will employ a variety of keys. For example, a different key can be used each day. This means that if a key is captured by the enemy, then only one day’s communications are immediately jeopardised.

It is assumed that the enemy already knows the algorithm, because it is inevitable that details of the system will have been leaked or stolen. The significance of the key, as opposed to the algorithm, is an enduring principle of cryptography, and it was definitively stated in 1883 by the Dutch linguist Auguste Kerckhoffs von Nieuwenhof in his famous article ‘La Cryptographie Militaire’: the security of a cryptosystem must not depend on keeping secret the crypto algorithm; the security depends only on keeping secret the key. This is Kerckhoffs’ Principle.

CRACKING THE SUBSTITUTION CIPHER

One method for cracking a ciphertext is to guess the true meaning of part of the encrypted message, which is known as a crib. For example, the codebreaker might know that a ciphertext that begins ‘XBKJ . . .’ is a letter, so XBKJ might stand for ‘dear . . .’, which means that the true values for four letters have been established, which in turn might be helpful in deciphering the rest of the message.

Without a crib, and with so many keys, the general substitution cipher seemed impregnable for centuries, but eventually a flaw was revealed. One of the first scholars to exploit the weakness of the substitution cipher was the ninth-century Arab philosopher al-Kindi, who recorded his codebreaking technique, now known as frequency analysis, in ‘A Manuscript on Deciphering Cryptographic Messages’.

Frequency analysis focuses on the fact that the letters in the Arabic, Roman, or any other alphabet have a distinct variation in frequency. In English, for example, e is the most common letter, accounting on average for roughly 13 per cent of all letters in a piece of text. The next most common letters are t, a, and n, whereas letters such as x, q, and z are very rare, as any scrabble player will testify.

Al-Kindi realised that if a letter was substituted for another letter (or symbol), then the new letter would take on the frequency of the original letter. Therefore, by studying the frequency of the letters in the ciphertext, it should be possible to establish their true value. For example, if L is the most common letter in the ciphertext, then L probably represents e.

Each letter has a personality and its overall frequency is just one part of that personality. Other traits include its relationship to other letters (q is always followed by u) or how often it appears at the start of a word. No matter how a letter is disguised during substitution, it will continue to carry its personality and should still be recognisable.

Once news of frequency analysis spread, it was clear that a better form of encryption was required. An ideal cipher would generate a ciphertext that bore no relation to the plaintext, unlike simple substitution which carries the frequencies across to the ciphertext as a hint to help identify the true value of each letter. The perfect ciphertext should appear to be random, because the codebreaker is impotent unless there is the slightest pattern that can be recognised.

THE VIGENÈRE CIPHER

emerged as a solution. There were numerous attempts to improve the simple substitution cipher. The homophonic cipher usually has a cipher alphabet that consists of numbers, with several possible number substitutions for the most common letters and one number for each of the rare letters. This results in a much flatter frequency distribution for the elements of the cipher alphabet, which makes the cipher much more secure. However, the ciphertext still retains recognisable qualities that allow it to be cracked.

For example, if a number is always followed by a small set of other numbers, then the former is probably q and the latter is probably u. An alternative to a cipher is a code. Although the word is used loosely to cover a whole range of encryption techniques, a code is technically a system with only one key. A code book might be a dictionary that lists thousands of words and alongside each one a five-digit number.

A message would be encrypted by looking up each word of the plaintext and replacing it with the corresponding number. This system is relatively strong, because the number of elements in the ciphertext will be smaller and there will be fewer repeated elements, but the lack of keys is a drawback. The same code book will be used for months or years, because creating and distributing a new code book is a major undertaking.

During this lengthy period, it is highly likely that the code book will be deduced or stolen. While some continued to use the old-fashioned, weak ciphers, others used inflexible codes or a combination of the two known as a nomenclator. But a better solution was the Vigenère cipher, named after Blaise de Vigenère, a French diplomat born in 1523, one of the cryptographers who contributed to its development.

The strength of the Vigenère cipher relies on using not one, but 26 distinct cipher alphabets to encrypt a message. The first step in encipherment involves drawing up a so-called Vigenère square, shown below, a plaintext alphabet followed by 26 cipher alphabets, each one shifted by one more letter with respect to the previous one. Hence, row 1 represents a cipher alphabet with a Caesar shift of 1, row 2 represents a cipher alphabet with a Caesar shift of 2, and so on.

The top row of the square, in lower case, represents the plaintext letters, and you could encipher each plaintext letter according to any one of the 26 cipher alphabets. For example, if cipher alphabet number 2 is used, then the letter a is enciphered as C, but if cipher alphabet number 12 is used, then a is enciphered as M. If the sender were to use just one of the cipher alphabets to encipher a message, then this would be a simple Caesar cipher, which would be easy for an enemy interceptor to crack.

However, the Vigenère cipher involves using several rows of the Vigenère square (i.e. different cipher alphabets) to encrypt the letters of the message. In other words, the sender might encrypt the first letter according to row 7, the second according to row 24, the third letter according to row 21, and so on.

In order to communicate, the sender and receiver must agree on a system for switching between rows. This agreement is achieved via a keyword. To demonstrate the Vigenère cipher, let us use the keyword ‘WHITE’ to encrypt the message ‘Divert troops to east’. Before encrypting, the keyword is spelt out above the message, and repeated over and over again so that each letter in the message is associated with a letter from the keyword.

Then, to encrypt the first letter, d, begin by identifying the key letter above it, W, which in turn defines a particular row in the Vigenère square. The row beginning with W, row 22, is the cipher alphabet that will be used to find the substitute letter for the plaintext d. Hence, we identify the column headed by d and see where it intersects the row beginning with W, which turns out to be at the letter Z. Consequently, the letter d in the plaintext is represented by Z in the ciphertext.

To encipher the second letter of the message, i, the process is repeated. The key letter above i is H, so encryption involves a different row in the Vigenère square, namely the H row, the seventh row. To encrypt i, identify the column headed by i and see where it intersects the row beginning with H, which turns out to be at the letter P. Consequently, the letter i in the plaintext is represented by P in the ciphertext.

Each letter of the keyword indicates a particular cipher alphabet within the Vigenère square, and because the keyword contains five letters, the sender encrypts the message by cycling through five rows of the Vigenère square. The Vigenère cipher is strong because it is impregnable to simple frequency analysis. For example, a cryptanalyst applying frequency analysis to a piece of ciphertext would usually begin by identifying the most common letter in the ciphertext, which in this case is Z, and then assume that this represents the most common letter in English, e.

In fact, the letter Z represents three different letters d, r, and s, but not e. This is clearly a problem for the cryptanalyst. Equally confusing is the fact that a letter that appears several times in the plaintext can be represented by different letters in the ciphertext. For example, the oo in ‘troops’ is substituted by two different letters, namely H and S.

The Vigenère cipher is called polyalphabetic, because a single message is encrypted using a variety of cipher alphabets. This is in contrast to the substitution ciphers that have been previously discussed, which are known as monoalphabetic. The Vigenère cipher seemed so strong that it was dubbed le chiffre indéchiffrable. It remained unbroken for centuries.

In "Sketching User Experiences," author Bill Buxton shares a gripping story about Saul Greenberg, a fellow researcher and avid mountaineer:

“This story is about Saul Greenberg, a professor at the University of Calgary and a leading researcher in human-computer interaction. Saul and the storyteller share a strong bond, not only because of their professional relationship but also due to their mutual love for mountains and outdoor activities. Saul, being an experienced mountaineer, once faced a life-threatening situation while skiing with his wife, Judy, and three other friends.

They were skiing in Canmore, Alberta, a terrain they were familiar with. Despite the considerable risk of avalanches that day, they decided to ski down a slope, spreading out to minimize the risk. Unfortunately, an avalanche occurred, burying Saul under almost two meters of snow. Two other members of the party were also caught but not fully buried. Judy and another friend, Steve, who were acting as lookouts, were not caught up in the slide.

Steve, who was positioned higher, went to assist the partially buried members, while Judy set out to find Saul. She did not immediately start digging but used her avalanche transceiver to pinpoint Saul's location. Avalanche transceivers are wireless collaborative PDAs with audio/visual user interfaces that help locate victims under the snow.

Once the transceiver indicated the likely burial point, the usual procedure is to use an avalanche probe to confirm the exact location before starting to dig. However, Judy decided to skip the probing and started digging at the location indicated by her transceiver.

Saul, realizing his predicament, tried to ski out of the avalanche, but ended up trapped at the base of the slope. Avalanches can travel up to 200 km/h, making it challenging to out-ski them. Because of the conditions and Saul's technique, he was able to ski down with the slide until he got trapped in a feature trap.

As the river of snow started to slow down and cover him, Saul did the most important thing in terms of staying alive: he cupped his hand over his nose, and mouth, making sure that he kept an air space within which he could breathe. Once buried, he went very Zen, and purged every effort to struggle or rescue himself. Struggle and fight is what you do on top of the snow. Underneath, you must wait. And wait. And have faith in your partners, their training, and everyone’s gear. In Saul’s case, this trust was well placed. Judy found him. The total time from the slide to rescue was about 10 minutes. That was good—after 20 minutes, he probably would have been dead.

In reflecting on this incident, it is clear that Saul's survival was not just a matter of luck. There was a combination of on-the-spot problem-solving, performance, training, procedure, and equipment that contributed to his rescue. The story highlights that the tools, such as the avalanche transceiver, would have been useless if they did not exist within a larger ecosystem.

The story concludes with the acknowledgement that technologies do not exist in a vacuum but in a social and physical context. It emphasizes the need for any design methodology to take full account of the relevant ecosystem, as technologies are increasingly finding themselves in diverse and specialized contexts. For instance, if Saul had been the only one with a transceiver, his outcome would likely have been different, regardless of how well the transceiver worked.”

I was able during these two last weekends to read Domain Specific Languages by Martin Fowler. This time investment was very much motivated by the following problem:

Many times, in e-commerce applications, some product data and meta-data will be setup by content engineers and will drive the product categories and customisation pages that will be used by the end users to select their final product configuration.

I began wondering if the introduction of a DSL with an associated Semantic Model (see description below) would allow to extract the product customisation code from the many other concerns of the codebase. Part I of this article will be a quick summary of Martin Fowler’s excellent book - Part II will be dedicated to how such a generic solution could be potentially architected.

According to Martin Fowler, a DSL is:

“a computer language of limited expressiveness focused on a particular domain”

We can talk about an internal vs external DSL:

• Internal DSL - a particular way of using a general purpose language. Rails, Ruby most famous framework is often seen as a collection of DSLs

• External DSL - a language separate from the main language of the application it works with. SQL, CSS, SASS (a DSL that compiles to another DSL!) and HTML for example

Another way to look at a DSL is a way of manipulating a library or framework - in this book’s context the library is the Semantic Model I mentioned above. Usually the hard work is building the model - the DSL is just layers on top of it

Again, Fowler describes a few reasons of why to use a DSL:

• Improving development productivity

• Communication with domain experts (content engineers, product managers, ..)

• Alternative computation model (vs imperative model of computation) more adapted to the domain focus

1. Decision tables

2. State machines

3. Production rule systems

4. Dependency networks

The book is long and I will not try to replicate everything here - I really encourage everyone involved in developing digital products to read the book - but my summary of the seven main steps to implement an external DSL are:

1. Implement a Semantic Model

2. Design the domain language

3. Define the EBNF grammar for the language

4. Use a parser generator - e.g. antlr - to generate a parser from the EBNF grammar

5. Leverage the flexibility of the parser generator to make the parser generate an AST (abstract syntax tree) that is easy to navigate and populate the Semantic Model

6. Use the generated parser to parse the DSL and generate the AST

7. Populate the Semantic Model from the customised AST

In Part 2 I’ll try to describe a possible approach for extracting the product navigation and customisation code from the rest of an e-commerce codebase by using a DSL to configure the data and meta-data that will drive the Semantic Model embedded within the application.

That's the experience that Greg Mckeown, the author of Essentialism: The Disciplined Pursuit of Less proposes that the reader do in their professional life - the result may be more surprising than it seems at first sight - and in a very positive way..

The Way of the Essentialist

If I could synthesize the concept of essentialism into a sentence, it would be to focus all the energy on the effort where it could have the most impact. Of course, to be able to do this, it is necessary to carefully choose what you are going to invest this effort in and convince the people around you that this is the strategy that will bring the maximum return on investment, not only for yourself, but also for the team and the organization.

If you don’t prioritise your life, someone else will

Or put another way, when everything is important, nothing is important. Another result is that we get distracted from what is really important and what we should invest in to have the greatest possible impact.

Explore and Evaluate

Ask yourself “Will this activity or effort make the highest possible contribution towards my goal?” - if the answer is no then you know its a candidate for elimination.

Discerning the trivial many from the vital few

Ask yourself “What do I feel deeply inspired by?”, “What am I particularly talented at?”, “What meets a significant need in the world?”

Eliminate

It’s not enough to simply determine which activities and efforts don’t make the highest possible contribution; you still have to actively eliminate those that do not.

Cutting out the trivial many

To eliminate non-essentials means saying no to someone. Often. To do it well takes courage and compassion. It’s about the emotional discipline to say no to social pressure. Remember, when we forfeit our right to chose, someone will chose for us.

Execute

Removing obstacles and making execution effortless

The Essentialist approach, instead of forcing execution, invests the time they have saved into creating a system for removing obstacles and making execution as easy as possible.

Choose

We often think of choice as a thing. Options may be things but a choice is an action. It is not just something we have but also something we do. A crucial lesson we need to learn is that certain types of efforts yield higher rewards than others. Ask yourself “What is the most valuable result I could achieve in this job?”. Working hard is important. But more effort does not necessary yield more results.

Explore

Escape

We need space to escape in order to discern the essential few from the trivial many. Unfortunately, in our time-starved era we don’t get that space by default – only by design. While non-Essentialists automatically react to the latest idea, jump on the latest opportunity, or respond to the latest e-mail, Essentialists choose to create the space to explore and ponder. Escape to a space where you can focus and explore ideas.

Play

Play, which I would define as anything we do simply for the joy of doing rather than as a means to an end – whether it’s flying a kite or listening to music or kicking around a football – might seem like a non-essential activity. Often it is treated that way. But in fact play is essential in many ways.

First, play broadens the range of options available to us. It helps us to see possibilities we otherwise wouldn’t have seen and make connections we would otherwise not have made. It opens our minds and broadens our perspective. It helps us challenge old assumptions and makes us more receptive to untested ideas. It gives us permission to expand our own stream of consciousness and come up with new stories. Or as Albert Einstein once said: “When I examine myself and my methods of thought, I come to the conclusion that the gift of fantasy has meant more to me than my talent for absorbing positive knowledge.”

Second, play is an antidote to stress, and this is key because stress, in addition to being an enemy of productivity, can actually shut down the creative, inquisitive, exploratory parts of our brain. You know how it feels: you’re stressed about work and suddenly everything starts going wrong. You can’t find your keys, you bump into things more easily, you forget the critical report on the kitchen table. Recent findings suggest this is because stress increases the activity in the part of the brain that monitors emotions (the amyg-dala), while reducing the activity in the part responsible for cognitive function (the hippocampus)7 – the result being, simply, that we really can’t think clearly.

Third, as Edward M. Hallowell, a psychiatrist who specialises in brain science, explains, play has a positive effect on the executive function of the brain. “The brain’s executive functions,” he writes, “include planning, prioritizing, scheduling, anticipating, delegating, deciding, analyzing – in short, most of the skills any executive must master in order to excel in business.”

Sleep

The best asset we have for making a contribution to the world is ourselves. If we underinvest in ourselves, and by that I mean our minds, our bodies, and our spirits, we damage the very tool we need to make our highest contribution. One of the most common ways people – especially ambitious, successful people – damage this asset is through a lack of sleep.

If we let our type A instincts take over, we will, like Geoff, be swallowed up whole. We will burn out too early. We need to be as strategic with ourselves as we are with our careers and our businesses. We need to pace ourselves, nurture ourselves, and give ourselves fuel to explore, thrive, and perform.

In K. Anders Ericsson’s famous study of violinists, popularised by Malcolm Gladwell as “the 10,000-Hour Rule,” Anders found that the best violinists spent more time practising than the merely good students.

The second most important factor differentiating the best violinists from the good violinists was actually sleep. The best violinists slept an average of 8.6 hours in every twenty-four-hour period: about an hour longer than average. Over the period of a week they also spent an average of 2.8 hours napping in the afternoon: about two hours longer than the average. Sleep, the authors of the study concluded, allowed these top performers to regenerate so that they could practise with greater concentration. So yes, while they practised more, they also got more out of those hours of practise because they were better rested.

Sleep will enhance your ability to explore, make connections, and do less but better throughout your waking hours.

Select

You can think of this as the 90 Per Cent Rule, and it’s one you can apply to just about every decision or dilemma. As you evaluate an option, think about the single most important criterion for that decision, and then simply give the option a score between 0 and 100. If you rate it any lower than 90 per cent, then automatically change the rating to 0 and simply reject it. This way you avoid getting caught up in indecision, or worse, getting stuck with the 60s or 70s. Think about how you’d feel if you scored a 65 on some test. Why would you deliberately choose to feel that way about an important choice in your life?

If it isn’t a clear yes, it’s a clear no

Being selective when deciding what opportunities to go after is one thing, but it can get even harder when opportunities come to us. We get a job offer we didn’t expect. A side project comes along that isn’t really what we do, but it is easy cash. Someone asks us to help out with something we love doing, but it is unpaid work. An acquaintance has a time share available in a less-than-ideal location but at a discounted rate. What do we do?

By focusing on work no one else was doing, they could create the knowledge, tools, and expertise to become the premier company in the world at their expertise. But to achieve this they would have to say no to everything else. Even in bad economic times. Even when paid work was offered to them. It was the price for becoming distinct. In other words, they would have to be more selective in the work they took on, so they could channel all their energies towards excelling in the area that had become their speciality.

Eliminate

Clarify

From “Pretty Clear” to “Really Clear”

But anyone who wears glasses knows there is a big difference between pretty clear and really clear! The same seems true with individuals’ professional strategy. When I ask people, “What do you really want out of your career over the next five years?” I am still taken aback by how few people can answer the question.

For one, there is a heavy price just in terms of human dynamics. The fact is, motivation and cooperation deteriorate when there is a lack of purpose. You can train leaders in communication and teamwork and conduct 360 feedback reports until you are blue in the face, but if a team does not have clarity of goals and roles, problems will fester and multiply.

When there is a serious lack of clarity about what the team stands for and what their goals and roles are, people experience confusion, stress, and frustration. When there is a high level of clarity, on the other hand, people thrive.

Essential Intent

To understand what an essential intent is, we may be best served by first establishing what it is not.2 At the risk of using a consulting cliché, we can explore this using a two-by-two matrix.

An essential intent, on the other hand, is both inspirational and concrete, both meaningful and measurable. Done right, an essential intent is one decision that settles one thousand later decisions. It’s like deciding you’re going to become a doctor instead of a lawyer. One strategic choice eliminates a universe of other options and maps a course for the next five, ten, or even twenty years of your life. Once the big decision is made, all subsequent decisions come into better focus.

Dare

The Power of a Graceful “No”

Have you ever felt a tension between what you felt was right and what someone was pressuring you to do? Have you ever felt the conflict between your internal conviction and an external action? Have you ever said yes when you meant no simply to avoid conflict or friction? Have you ever felt too scared or timid to turn down an invitation or request from a boss, colleague, friend, neighbour, or family member for fear of disappointing them? If you have, you’re not alone. Navigating these moments with courage and grace is one of the most important skills to master in becoming an Essentialist – and one of the hardest.

Saying no is its own leadership capability. It is not just a peripheral skill. As with any ability, we start with limited experience. We are novices at “no.” Then we learn a couple of basic techniques. We make mistakes. We learn from them. We develop more skills. We keep practising. After a while we have a whole repertoire available at our disposal, and in time we have gained mastery of a type of social art form. We can handle almost any request from almost anybody with grace and dignity.

Uncommit

It’s true that “uncommitting” can be harder than simply not committing in the first place. We feel guilty saying no to something or someone we have already committed to, and let’s face it, no one likes going back on their word. Yet learning how to do so – in ways that will garner you respect for your courage, focus, and discipline – is crucial to becoming an Essentialist.

Edit

An editor is not merely someone who says no to things. A three-year-old can do that. Nor does an editor simply eliminate; in fact, in a way, an editor actually adds. What I mean is that a good editor is someone who uses deliberate subtraction to actually add life to the ideas, setting, plot, and characters.

Likewise, in life, disciplined editing can help add to your level of contribution. It increases your ability to focus on and give energy to the things that really matter. It lends the most meaningful relationships and activities more space to blossom.

Editing Life

An editor’s job is not just to cut or condense but also to make something right. It can be a change as minor as a grammar correction or as involved as fixing the flaws in an argument. To do this well, an editor must have a clear sense of the overarching purpose of the work he or she is editing. As Michael Kahn explains, he doesn’t always do what Spielberg tells him to do; instead, he does what he thinks Spielberg really wants. Understanding the overarching intent allows him to make the corrections that even Spielberg himself might not be able to verbalise.

A non-Essentialist views editing as a discrete task to be performed only when things become overwhelming. But waiting too long to edit will force us to make major cuts not always of our choosing. Editing our time and activities continuously allows us to make more minor but deliberate adjustments along the way. Becoming an Essentialist means making cutting, condensing, and correcting a natural part of our daily routine – making editing a natural cadence in our lives.

Limit

The Freedom of Setting Boundaries

With practice, enforcing your limits will become easier and easier.

Execute

Buffer

The Unfair Advantage

The reality is that we live in an unpredictable world. Even apart from extreme events such as famines, we face the unexpected constantly. We do not know whether the traffic will be clear or congested. We do not know if our flight will be delayed or cancelled. We do not know if we’ll slip on an icy pavement tomorrow and break our wrist. Similarly, in the workplace we do not know if a supplier will be late, or a colleague will drop the ball, or a client will change his or her directions at the eleventh hour, and so on. The only thing we can expect (with any great certainty) is the unexpected. Therefore, we can either wait for the moment and react to it or we can prepare. We can create a buffer.

The way of the Essentialist is different. The Essentialist looks ahead. She plans. She prepares for different contingencies. She expects the unexpected. She creates a buffer to prepare for the unforeseen, thus giving herself some wiggle room when things come up, as they inevitably do.

The importance of extreme preparedness holds true for us in business. In fact, this example is used by Jim Collins and Morten Hansen to demonstrate why some companies have thrived under extreme and difficult circumstances while others have not. In filtering out 7 companies from 20,400, the authors found that the ones that executed most successfully did not have any better ability to predict the future than their less successful counterparts. Instead, they were the ones who acknowledged they could not predict the unexpected and therefore prepared better.

When Erwann works with national governments to create their risk management strategies, he suggests they start by asking five questions: (1) What risks do we face and where? (2) What assets and populations are exposed and to what degree? (3) How vulnerable are they? (4) What financial burden do these risks place on individuals, businesses, and the government budget? and (5) How best can we invest to reduce risks and strengthen economic and social resilience?

Essentialists accept the reality that we can never fully anticipate or prepare for every scenario or eventuality; the future is simply too unpredictable. Instead, they build in buffers to reduce the friction caused by the unexpected.

Subtract

Bring Forth More by Removing Obstacles

In the business parable The Goal, Alex Rogo is a fictional character who is overwhelmed by the responsibility of turning around a failing production plant within three months.1 At first he does not see how this is possible. Then he is mentored by a professor who tells him he can make incredible progress in a short time if only he can find the plant’s “constraints.” Constraints, he is told, are the obstacles holding the whole system back. Even if he improves everything else in the plant, his mentor tells him, if he doesn’t address the constraints the plant will not materially improve.

As Alex is trying to make sense of what he is being taught, he goes on a hike with his son and some other friends. As the Scout leader, it’s his responsibility to get all of the boys to the campsite before the sun sets. But as anyone who has been on such a hike knows, getting a group of young boys to keep up a pace is more difficult than it sounds, and Alex soon runs into a problem: some of the Scouts go really fast and others go really slow. One boy in particular, Herbie, is the slowest of all. The result is that the gap between the hikers at the front of the line and Herbie, the straggler, grows to be miles long.

At first Alex tries to manage the problem by getting the group at the front to stop and wait for the others to catch up. This keeps the group together for a time, but the moment they start walking again the same gap begins to form all over again.

So Alex decides to try a different approach. He puts Herbie at the front of the pack and lines up all the other boys in order of speed: slowest to fastest. It’s counterintuitive to have the fastest person at the back of the line, but the moment he does it the pack begins to move in a single group. Every boy can keep up with the boy in front of him. The upside is that he can now keep an eye on the whole group at once, and they will all arrive at the campsite safely and at the same time. The downside is that the whole troop is now moving at Herbie’s pace so they will arrive late. So what should he do?

The answer, Alex finds, is to do anything and everything to make things easier for Herbie. With the slowest boy at the front of the line, if Herbie moves one yard an hour faster, the whole troop will get there that much faster. That is an amazing insight to Alex. Any improvement with Herbie, however small, will improve the pace of the whole team immediately. So he actually takes weight out of Herbie’s backpack (the extra food and supplies he brought with him) and distributes it throughout the rest of the group. And indeed, this instantly improves the speed of the whole group. They make it to camp in good time.

In a moment of insight, Alex sees how this approach could also be applied to turning around his production plant. Instead of trying to improve every aspect of the facility he needs to identify the “Herbie”: the part of the process that is slower relative to every other part of the plant. He does this by finding which machine has the biggest queue of materials waiting behind it and finds a way to increase its efficiency. This in turn improves the next “slowest hiker’s” efficiency, and so on, until the productivity of the whole plant begins to improve.

But this can’t be done in a haphazard way. Simply finding things that need fixing here and there might lead to marginal, short-term improvements at best; at worst, you’ll waste time and effort improving things that don’t really matter. But if you really want to improve the overall functioning of the system – whether that system is a manufacturing process, a procedure in your department, or some routine in your daily life – you need to identify the “slowest hiker.”

A non-Essentialist approaches execution in a reactive, haphazard manner. Because the non-Essentialist is always reacting to crises rather than anticipating them, he is forced to apply quick-fix solutions: the equivalent to plugging his finger into the hole of a leaking dam and hoping the whole thing doesn’t burst. Being good with a hammer, the non-Essentialist thinks everything is a nail. Thus he applies more and more pressure, but this ends up only adding more friction and frustration. Indeed, in some situations the harder you push on someone the harder he or she will push back.

Essentialists don’t default to Band-Aid solutions. Instead of looking for the most obvious or immediate obstacles, they look for the ones slowing down progress. They ask, “What is getting in the way of achieving what is essential?” While the non-Essentialist is busy applying more and more pressure and piling on more and more solutions, the Essentialist simply makes a one-time investment in removing obstacles. This approach goes beyond just solving problems; it’s a method of reducing your efforts to maximise your results.

Removing obstacles does not have to be hard or take a superhuman effort. Instead, we can start small. It’s kind of like dislodging a boulder at the top of a hill. All it takes is a small shove, then momentum will naturally build.

Progress

The Power of Small Wins

The way of the non-Essentialist is to go big on everything: to try to do it all, have it all, fit it all in. The non-Essentialist operates under the false logic that the more he strives, the more he will achieve, but the reality is, the more we reach for the stars, the harder it is to get ourselves off the ground.

The way of the Essentialist is different. Instead of trying to accomplish it all – and all at once – and flaring out, the Essentialist starts small and celebrates progress. Instead of going for the big, flashy wins that don’t really matter, the Essentialist pursues small and simple wins in areas that are essential.

Research has shown that of all forms of human motivation the most effective one is progress. Why? Because a small, concrete win creates momentum and affirms our faith in our further success. In his 1968 Harvard Business Review article entitled “One More Time: How Do You Motivate Employees?” among the most popular Harvard Business Review articles of all time, Frederick Herzberg reveals research showing that the two primary internal motivators for people are achievement and recognition for achievement.

More recently, Teresa Amabile and Steven Kramer gathered anonymous diary entries from hundreds of people and covering thousands of workdays. On the basis of these hundreds of thousands of reflections, Amabile and Kramer concluded that “everyday progress – even a small win” can make all the difference in how people feel and perform. “Of all the things that can boost emotions, motivation, and perceptions during a workday, the single most important is making progress in meaningful work,” they said.

Instead of starting big and then flaring out with nothing to show for it other than time and energy wasted, to really get essential things done we need to start small and build momentum. Then we can use that momentum to work towards the next win, and the next one and so on until we have a significant breakthrough – and when we do, our progress will have become so frictionless and effortless that the breakthrough will seem like overnight success. As former Stanford professor and educator Henry B. Eyring has written, “My experience has taught me this about how people and organizations improve: the best place to look is for small changes we could make in the things we do often. There is power in steadiness and repetition.”

Focus on Minimal Viable Progress

We can adopt a method of “minimal viable progress.” We can ask ourselves, “What is the smallest amount of progress that will be useful and valuable to the essential task we are trying to get done?

Flow

The Genius of Routine

The way of the non-Essentialist is to think the essentials only get done when they are forced. That execution is a matter of raw effort alone. You labour to make it happen. You push through.

The way of the Essentialist is different. The Essentialist designs a routine that makes achieving what you have identified as essential to the default position. Yes, in some instances an Essentialist still has to work hard, but with the right routine in place each effort yields exponentially greater results.

Making it Look Easy

Our ability to execute the essential improves with practice, just like any other ability. Think about the first time you had to perform a certain critical function at work. At first you felt like a novice. You probably felt unsure and awkward. The effort to focus drained your willpower. Decision fatigue set in. You were probably easily distracted. This is perfectly normal. But once you performed the function over and over again, you gained confidence. You were no longer sidetracked. You were able to perform the function better and faster, and with less concentration and effort. This power of a routine grows out of our brain’s ability to take over entirely until the process becomes fully unconscious.

Focus

There Is Only Now

Think about how this might apply in your own life. Have you ever become trapped reliving past mistakes … over and over like a video player, stuck on endless replay? Do you spend time and energy worrying about the future? Do you spend more time thinking about the things you can’t control rather than the things you can control about the areas where your efforts matter? Do you ever find yourself busy trying to prepare mentally for the next meeting, or the next assignment, or the next chapter in your life, rather than being fully present in the current one? It’s natural and human to obsess over past mistakes or feel stress about what may be ahead of us. Yet every second spent worrying about a past or future moment distracts us from what is important in the here and now.

Non-Essentialists tend to be so preoccupied with past successes and failures, as well as future challenges and opportunities, that they miss the present moment. They become distracted. Unfocused. They aren’t really there.

The way of the Essentialist is to tune into the present. To experience life in kairos, not just chronos. To focus on the things that are truly important – not yesterday or tomorrow, but right now.

Essentialists live their whole lives in this manner. And because they do, they can apply their full energy to the job at hand. They don’t diffuse their efforts with distractions. They know that execution is easy if you work hard at it and hard if you work easy at it.

What we can’t do is concentrate on two things at the same time. When I talk about being present, I’m not talking about doing only one thing at a time. I’m talking about being focused on one thing at a time. Multi-tasking itself is not the enemy of Essentialism; pretending we can “multi-focus” is.

How To Be In The Now

Thich Nhat Hanh, the Vietnamese Zen Buddhist monk who has been called the “world’s calmest man,” has spent a lifetime exploring how to live in kairos, albeit by a different name. He has taught it as mindfulness or maintaining “beginner’s mind.” He has written: “Mindfulness helps you go home to the present. And every time you go there and recognize a condition of happiness that you have, happiness comes.”

This focus on being in the moment affects the way he does everything. He takes a full hour to drink a cup of tea with the other monks every day. He explains: “Suppose you are drinking a cup of tea. When you hold your cup, you may like to breathe in, to bring your mind back to your body, and you become fully present. And when you are truly there, something else is also there – life, represented by the cup of tea. In that moment you are real, and the cup of tea is real. You are not lost in the past, in the future, in your projects, in your worries. You are free from all of these afflictions. And in that state of being free, you enjoy your tea. That is the moment of happiness, and of peace.”

Be

The Essentialist Life

Of course, we don’t have to try to replicate Gandhi to benefit from his example as someone who lived, fully and completely, as an Essentialist. We can all purge our lives of the non-essential and embrace the way of the Essentialist – in our own ways, and in our own time, and on our own scale. We can all live a life not just of simplicity but of high contribution and meaning.

We can see the philosophy of “less but better” reflected in the lives of other notable and diverse figures – both religious and secular – throughout history: to name a few, the Dalai Lama, Steve Jobs, Leo Tolstoy, Michael Jordan, Warren Buffett, Mother Teresa, and Henry David Thoreau (who wrote, “I do believe in simplicity. It is astonishing as well as sad, how many trivial affairs even the wisest thinks he must attend to in a day; … so simplify the problem of life, distinguish the necessary and the real”).

People with Essentialism at their core get far more from their investment than those who absorb it only at the surface level. Indeed, the benefits become cumulative. Every choice we make to pursue the essential and eliminate the non-essential builds on itself, making that choice more and more habitual until it becomes virtually second nature. With time, that inner core expands outwards until it has all but eclipsed the part of us still mired in the non-essential.

The Essential Life: Living Life That Really Matters

The life of an Essentialist is a life lived without regret. If you have correctly identified what really matters, if you invest your time and energy in it, then it is difficult to regret the choices you make. You become proud of the life you have chosen to live.

Will you choose to live a life of purpose and meaning, or will you look back on your one single life with twinges of regret? If you take one thing away from this book, I hope you will remember this: whatever decision or challenge or crossroads you face in your life, simply ask yourself, “What is essential?” Eliminate everything else.

Just finished reading "A Philosophy of Software Design", one of the best books I have ever read regarding what causes software complexity and some potential heuristics on how to continuously improve the codebase design and mitigate technical debt.

Specially liked these 3 takeaways:

1. Deeper layer APIs should in general be more generic than the layers above which will in principle be more exposed to changing requirements

2. Use documentation to drive the design and to reduce code obscurity

3. Try out at least two alternative designs and pick the best ideas from both approaches

I always felt that the GUI layer of any application was the most subject to changing requirements and that every effort should be taken to isolate the lower level layers API from the GUI changes - the Text Editor examples in this book really do an impressive job providing concrete implementations on how to achieve such isolation.

Highly recommend this book!

This weekend I enjoyed reading the book “Laying the Foundations - a book about design systems”.

This book parallels many of the core ideas of “Atomic Design” - major new concepts are the introduction of a new design system model for digital products (the original Atomic Design book examples were focused around website development).

Atomic Design (Website oriented)

* Pages
* Templates
* Organisms
* Molecules
* Atoms

Laying the Foundations (Digital Product oriented)

* User Journeys
* Screens
* Features
* Patterns
* Components
* Foundation

Foundations in this model are an extension of the style guide concept.

Components will map to the atoms and molecules described in Atomic Design.

Patterns, recurrent solutions to design problems, will be related to organisms.

Unlike the website template described in the Atomic Design model, dynamic screens mays have dozens of outcomes and resulting feature sets.

Finally, user journeys will map out how a feature is used.

The book also talks about the major problems emerging while maintaining a design system which everyone working on such a project should be careful about.

Would recommend this book a quick look after having read Atomic Design.

Hope this was helpful for someone - thanks!

I’ve recently found this comment on LinkedIn and at first, being a developer myself, I've found it a bit offensive.

At first I reacted in an impulsive way.

But after spending sometime thinking about how everyone in a team, from Product Managers, Engineers and Digital Product Designers can improve how they communicate and work together I'm suggesting two words to address this problem:

Design Systems

And here is why I think a design system will make everybody in a product team happier:

1. A shared design system between Product Managers, Engineers and Digital Product Designers, if successful, will speed up time to market

2. Imposing restrictions to the Design Space minimizes the introduction of unwanted design variations and special cases ...

2.1 ... which in turn reduces the necessary lines of code to implement the product

2.1.1 Minimising Technical Debt
2.1.2 Increasing Product Development speed
2.1.3 Making possible to explore alternative design solutions in the same time span

3. Superior quality and consistency of the user experience

4. Developer turnover will be a thing of the past

So let’s all get along and leverage the power of a Design System to make our lives happier and less stress prone!

Many perceive software engineering as primarily a solitary act of writing code. However, modern software engineering is a multifaceted discipline that extends far beyond this simplistic view. It encompasses understanding complex systems, problem-solving, designing software architecture, testing, debugging, and much more. A significant portion of a software engineer's role involves activities like requirements gathering, project planning, and documentation.

The Critical Role of Proactive Communication

One often underestimated aspect of software engineering is the pivotal role of proactive communication. Effective communication is not merely an advantage; it is often the key to unlocking progress and overcoming obstacles. This could involve seeking assistance when facing a problem, sharing valuable insights with the team, or clearly articulating project requirements and updates.

Unfortunately, many newcomers to the field neglect this crucial skill, often learning its importance the hard way. Failing to communicate proactively can result in unnecessary setbacks and delays. Hence, cultivating strong communication skills is as vital as honing technical expertise for a software engineer.

The Power of Collaboration and Collective Knowledge

Another fundamental aspect of software engineering is collaboration. Leveraging the diverse skills and collective knowledge of a team comprising product managers, business analysts, and QA specialists can significantly enhance understanding of the codebase and expedite the learning curve. These professionals offer valuable insights into product usage, which can prove invaluable for software engineers.

Learning from Early Mistakes: Humility and the Bigger Picture

A common pitfall for many new engineers is neglecting the importance of relationship building and understanding the broader context before diving into code. This can lead to feelings of isolation and reduced productivity. Instead, taking the time to get to know the team and grasp the project's overall objectives can lay a strong foundation for success.

Transitioning from Amateur to Professional

This realization – the importance of communication, collaboration, and understanding the bigger picture – marks a significant turning point in a software engineer's career. It represents the shift from an amateur coder's mindset to that of a professional software engineer, one who understands that software development is not just about writing code, but about working effectively within a team to create valuable solutions.

The question of why some individuals thrive in the face of adversity while others falter has intrigued scholars and philosophers throughout history. While nature and nurture undoubtedly play a role, Dr. Carol S. Dweck's groundbreaking research on mindset offers a compelling new perspective. In her book, "Mindset," Dweck introduces the concept of fixed versus growth mindsets, shedding light on the underlying beliefs that can significantly impact our approach to challenges, learning, and ultimately, success.

Individuals with a fixed mindset tend to believe that their qualities, such as intelligence or talent, are fixed traits. This belief can lead to a fear of failure and rejection, as they feel the need to constantly prove their worth. They may avoid challenges or give up easily when faced with setbacks, fearing that their struggles will expose their perceived limitations. For example, a student with a fixed mindset might avoid taking a difficult math course, fearing that a low grade would confirm their belief that they're not "math people."

In contrast, individuals with a growth mindset believe that their abilities can be developed through dedication and hard work. They see challenges as opportunities for learning and growth, and they embrace setbacks as a natural part of the process. A growth mindset fosters resilience and a willingness to persevere, even when faced with obstacles. For instance, a student with a growth mindset might struggle with a particular subject but would seek out extra help, practice diligently, and ultimately master the material.

Dweck's research highlights the importance of effort, perseverance, and a willingness to learn from mistakes. It's not just about having a positive attitude but about actively engaging in the process of growth and development. John Wooden, the legendary basketball coach, echoed this sentiment when he said, "You aren't a failure until you start to blame." In other words, it's not the setbacks themselves that define us, but how we respond to them.

To cultivate a growth mindset, Dweck suggests several actionable strategies. First, embrace challenges as opportunities for learning rather than threats to your ego. Second, view failure as feedback rather than a reflection of your inherent abilities. Third, focus on effort and perseverance rather than solely on results. Fourth, be open to feedback and use it to improve your performance. Finally, learn from others and surround yourself with people who inspire and challenge you to grow.

By understanding and adopting a growth mindset, we can unlock our full potential, achieve our goals, and lead more fulfilling lives. Whether it's in academics, sports, or the workplace, the power of belief in our ability to learn and grow can make all the difference. As Dweck reminds us, "The view you adopt for yourself profoundly affects the way you lead your life."

Theoretical Framework

The book proposes as a tool for analysis (and design) of team performance the following theoretical framework:

• Psychological Safety

• Share Vulnerability

• Establish Purpose

Psychological Safety

In 'The Culture Code' the author notes that in a high-performance team all its members feel part of the team and are comfortable to report any problem without suffering consequences from their superiors.

The format of feedback received takes the form:

I’m giving you these comments because I have very high expectations and I know that you can reach them.

Actually, when you look more closely at the sentence, it contains three separate cues:

• You are part of this group.

• This group is special; we have high standards here.

• I believe you can reach those standards.

Leadership delivers two things over and over: tell you the truth, with no bullshit, and then they’ll love you to death.

One misconception about highly successful cultures is that they are happy, lighthearted places. This is mostly not the case. They are energised and engaged, but at their core their members are oriented less around achieving happiness than around solving hard problems together.

Creating safety is about dialing in to small, subtle moments and delivering targeted signals at key points.

Share Vulnerability

On July 10, 1989, United Airlines flight 232 left Denver and headed for Chicago with 285 passengers on board. Then, at 3:16, came a loud explosion from the tail. The plane shook fiercely, then started climbing and tilting hard to the right.

Through the description of the crew performance on the incident on Flight 232, the author demonstrates that a series of small, humble exchanges—Anybody have any ideas? Tell me what you want, and I’ll help you—can unlock a group’s ability to perform.

All of which underlines a strange truth. The crew of Flight 232 succeeded not because of their individual skills but because they were able to combine those skills into a greater intelligence.

The Vulnerability Loop

1. Person A sends a signal of vulnerability.

2. Person B detects this signal.

3. Person B responds by signaling their own vulnerability.

4. Person A detects this signal.

5. A norm is established; closeness and trust increase.

As the author points out, vulnerability is less about the sender than the receiver. “The second person is the key,” he says. “Do they pick it up and reveal their own weaknesses, or do they cover up and pretend they don’t have any? It makes a huge difference in the outcome.

How to Create Cooperation in Small Groups

From the three hundred Navy SEALs who make up Team Six, if you were to ask a variety of current and retired Team Six operators which leaders they admire most, you would hear the same handful of names over and over. But the name you would hear most often is Dave Cooper.

How do you develop ways to challenge each other, ask the right questions, and never defer to authority? We’re trying to create leaders among leaders. And you can’t just tell people to do that. You have to create the conditions where they start to do it.”

Dave generates a series of unmistakable signals that tipped his men away from their natural tendencies and toward interdependence and cooperation. “Human nature is constantly working against us,” he says. “You have to get around those barriers, and they never go away.”

“When we talk about courage, we think it’s going against an enemy with a machine gun,” Cooper says. “The real courage is seeing the truth and speaking the truth to each other. People never want to be the person who says, ‘Wait a second, what’s really going on here?’ But inside the squadron, that is the culture, and that’s why we’re successful.”

One of the most difficult things about creating habits of vulnerability is that it requires a group to endure two discomforts: emotional pain and a sense of inefficiency.

It combines the repetition of digging into something that already happened (shouldn’t we be moving forward?) with the burning awkwardness inherent in confronting unpleasant truths. But as with any workout, the key is to understand that the pain is not a problem but the path to building a stronger group.

Establish Purpose

Purpose isn’t about tapping into some mystical internal drive but rather about creating simple beacons that focus attention and engagement on the shared goal.

High-proficiency environments help a group deliver a well-defined, reliable performance, while high-creativity environments help a group create something new. This distinction is important because it highlights the two basic challenges facing any group: consistency and innovation.

It’s strange to think that a wave of creativity and innovation can be unleashed by something as mundane as changing systems and learning new ways of interacting. But it’s true, because building creative purpose isn’t really about creativity. It’s about building ownership, providing support, and aligning group energy toward the arduous, error-filled, ultimately fulfilling journey of making something new.

Skills of proficiency are about doing a task the same way, every single time. They are about delivering machine-like reliability, and they tend to apply in domains in which the goal behaviors are clearly defined, such as service. Building purpose to perform these skills is like building a vivid map: You want to spotlight the goal and provide crystal-clear directions to the checkpoints along the way. Ways to do that include:

• Fill the group’s windshield with clear, accessible models of excellence.

• Provide high-repetition, high-feedback training.

• Build vivid, memorable rules of thumb (if X, then Y).

• Spotlight and honor the fundamentals of the skill.

Creative skills, on the other hand, are about empowering a group to do the hard work of building something that has never existed before. Generating purpose in these areas is like supplying an expedition: You need to provide support, fuel, and tools and to serve as a protective presence that empowers the team doing the work. Some ways to do that include:

• Keenly attend to team composition and dynamics.

• Define, reinforce, and relentlessly protect the team’s creative autonomy.

• Make it safe to fail and to give feedback.

• Celebrate hugely when the group takes initiative

Thank you for reading my notes - please let me know in the comments what other books or topics you’d like me to write about or even comment just to say Hello, I’d appreciate that!

Advertising

Are you tired of sipping lukewarm coffee from a boring mug? Do you crave a daily reminder of the secrets to building a thriving, high-performance team?

Look no further than The Culture Code Mug, inspired by Daniel Coyle's bestselling book. This stylish 11oz ceramic mug isn't just a vessel for your favorite beverage, it's a conversation starter, a symbol of your commitment to creating a positive and productive workplace culture.

Each time you take a sip, you'll be reminded of the three key skills that drive successful teams:

• Build Safety: Foster trust and belonging among your team members.

• Share Vulnerability: Create a space where people can be themselves and take risks.

• Establish Purpose: Unite your team around a common goal and shared values.

This dishwasher and microwave-safe mug is perfect for your morning coffee ritual, afternoon tea break, or any time you need a boost of inspiration. It's also a thoughtful gift for colleagues, managers, and anyone who wants to cultivate a strong and positive culture.

Order your Culture Code Mug today and start your journey toward building a team that thrives!

Buy Mug Today