JShell🐚

TLDR: like other REPLs, JShell provides an easy way to test Java one-liners, and, like the Rails console, a handy ad hoc CLI.

I appreciate a REPL for quickly checking the validity of small snippets. For example, I can improve the quality of my code reviews by verifying an idea works in a REPL before recommending it in a review.

My first exposure to a Java-esque REPL was the Scala REPL, which could also interpret Java. This was handy, but only easily available when Scala is installed.

When Scala wasn’t installed, I used Repl.it for Java, but this is a public site , so I need to be mindful not to use it for anything confidential, and it can take some time to load.

Recently, I learned about JShell, which is included in the JDK as of version 9.

Aside, in case you’re on a Chromebook, Google’s Cloud shell is great ad hoc terminal.

Per the JShell docs, I can start/stop the shell:

$ jshell
|  Welcome to JShell -- Version 11.0.6
|  For an introduction type: /help intro

jshell> /exit
|  Goodbye

Hello world:

jshell> System.out.println("hi")
hi

Note implicit semicolons for simple code. Return statements appear to need explicit semicolons, though, eg:

jshell> String get(){
   ...> return "s"
   ...> }
|  Error:
|  ';' expected
|  return "s"
|            ^

From the docs, I see there are “scratch variables”, which reminds me of the Scala REPL’s res variables:

jshell> 2+2
$3 ==> 4

jshell> $3
$3 ==> 4

jshell> $3 + 2
$5 ==> 6

The feedback is comparable to javac, eg:

$ cat MyMap.java
import java.util.HashMap;
import java.util.Map;

class MyMap {
        static Map<String, String> m = new HashMap<>();
        public void put(String k, String v){
                m.put(k,v);
        }
        public void get(String k){
                return m.get(k);
        }
}

$ javac MyMap.java
MyMap.java:10: error: incompatible types: unexpected return value
                return m.get(k);
                            ^
1 error
$ jshell
|  Welcome to JShell -- Version 11.0.6
|  For an introduction type: /help intro

jshell> /open MyMap.java
|  Error:
|  incompatible types: unexpected return value
|                  return m.get(k);
|                         ^------^

We can use tab completion:

jshell> List
List                 ListIterator         ListResourceBundle

Signatures:
java.util.List<E>

<press tab again to see documentation>

jshell> List.
class     copyOf(   of(

jshell> List.of("1", "2")
$3 ==> [1, 2]

jshell> $3.stream().forEach(System.out::println)
1
2

The up arrow scrolls back through history. We can also print it:

jshell> /list

   1 : List.of("1", "2")
   2 : $3.stream().forEach(n->System.out.println(n))

We can also search history, eg Ctrl + R for reverse search:

(reverse-i-search)`hi': System.out.println("hi")

Editing multi-line code is cumbersome, eg:

jshell> class Foo {
   ...> String get(){}
   ...> }
|  created class Foo

// Up arrow to edit method definition

jshell> String get(){
   ...> return "s";
   ...> }
|  created method get()

// Creates new function instead of editing Foo.get

jshell> get()
$10 ==> "s"

jshell> Foo f = new Foo();
f ==> Foo@1e88b3c

jshell> f.get();

jshell>

I’d recommend using an external editor for anything non-trivial.

JShell has an /edit command to launch an external editor, but it doesn’t appear to save the output.

jshell> /set editor vim
|  Editor set to: vim

jshell> class Foo {}
|  created class Foo

jshell> /edit Foo // add bar method to Foo
|  replaced class Foo

jshell> Foo f = new Foo()
f ==> Foo@56ac3a89

jshell> f.bar()
|  Error:
|  cannot find symbol
|    symbol:   method bar()
|  f.bar()
|  ^---^

jshell> /edit Foo // Observe bar method is undefined

I’d recommend just having an editor open in a separate terminal, and using JShell’s /open command to load the file after changes.

For folks using Google Cloud Shell, it appears to have an implicit tmux session, which makes it easy to edit in one pane and use JShell in another.

In practice, I’m guessing there’s little use for JShell when editing complex code, but it does provide a handy CLI for exploring complex code. We could have a build target, like pants repl, or a CLI for our app, like rails console.

For example, given a naive script build_to_repl.sh:

javac -d bin src/main/com/example/* \
        && jar cf bin/MyMap.jar -C bin com \
        && jshell --class-path bin/MyMap.jar

We could:

$ ./build_to_repl.sh                                                                                                                                                          
|  Welcome to JShell -- Version 11.0.6
|  For an introduction type: /help intro

jshell> import com.example.MyMap;

jshell> MyMap m = new MyMap();
m ==> com.example.MyMap@6a41eaa2

jshell> m.put("k", "v")

jshell> m.get("k")
$4 ==> "v"

Architecture for Light

The Illuminating Engineering Society has a couple interviews with Kim and Paul Mercier, authors of a book called Architecture for Light. The content is fascinating, touching on anthropology, physics, engineering, design and their professional experience, but a few things stood out to me in particular as overlapping with software engineering:

  1. The role of people
  2. Efficiency
  3. Multi-disciplinary planning

People

Perhaps the connection to people is more immediate in the field of lighting design than software engineering, but the two have a couple things in common that can negatively affect usability: creative purity and cost efficiency.

In software and architecture, we can design something that’s aesthetically pure, but difficult to incorporate or maintain.

One of the best tools I’ve found in project management is a focus on the customer. This can help us prioritize and avoid ethical pitfalls.

Related, healthy organizations recognize software is built by people, and people thrive in a nurturing environment. For example, Google’s research indicated psychological safety correlated strongly with high-performing teams.

Efficiency

The Merciers describe an approach to lighting that minimizes electrical usage and maximizes sales, but focusing light on products. (A common alternative is to uniformly light a space.)

They mentioned the most cost-effective solution is to turn the lights off. This reminds me of a balance in software engineering: we need to maintain everything we build, so not building minimizes maintenance cost. A similar balance comes up in SRE: we can maximize stability by minimizing changes. Obviously, doing nothing has other costs, but having all options on the table opens up opportunities, such as only invest light where a customer’s attention produces value.

The Merciers propose a method that maximizes efficiency and usability. This was an amazing observation: not too long ago, daylight was the most efficient light source; it’s still very efficient, but we need to rediscover the skills to use it.

Multi-disciplinary planning

The Merciers recommend including lighting designers from the “imagination” phase of a project rather than pulling them in later. Lighting designers can then advise on structural changes to maximize lighting efficiency. They describe the opposite as an anti-pattern: bringing specialists in late to fix problems.

This reminds me of a tension when organizing software development teams: a “waterfall” model where each specialty contributes in sequence, versus an “agile” model where teams are composed of cross-functional members.

They describe several examples in their interview, but one reminded me of complex workarounds that can arise in software: a building design that let in too much daylight. They observed a small overhang would be ideal, but because the design was already finalized the building had to be outfitted with a mechanical shade.

Customer feedback

Customer feedback can come through a variety of channels. Here’s a list of the ones I’ve found valuable, and practices for aggregating feedback through these channels.

Channels

Inline survey

This is an in-context prompt for feedback, eg
“Like the service? 😀 | 😐 | 😭”

Pros:

  • Relatively easy for feedback provider, resulting in broad participation
  • Confidential

Cons:

  • Limited signal
  • Hard to filter for quality participation

User research

This is when a company makes an open call for feedback.

Pros:

  • Long-form discussion
  • More control over participation than inline surveys
  • Confidential

Cons:

  • Quality of participants can vary

Partner interviews

This is when a company solicits feedback from valuable customers. I’ve found it useful to do this periodically, eg yearly.

Pros:

  • Long-form discussion
  • High-quality participants
  • Confidential

Cons:

  • Risk of focusing too closely on feedback from a small group

GitHub issues

GitHub provides a way for users of a repository to report issues.

Pros:

  • Public, so customers can pile on and follow progress
  • Intuitive for GitHub users
  • Reactions help capture sentiment
  • Easy to discover, eg via Web search
  • Enables customers to crowd-source support

Cons:

  • Specific to a repository

Slack

This is when a company maintains a public Slack channel.

Pros:

  • Good for quick Q/A
  • Enables customers to crowd-source support

Cons:

  • Can be noisy/interruptive. A support rotation can help distribute cost across team.

Stack Overflow

Stack Overflow enables people to ask questions about anything, but companies can use it’s features to support customers and collect feedback.

Pros:

  • Easy to discover, eg via Web search
  • Enables customers to crowd-source support

Aggregation

One challenge of having numerous feedback channels is distilling themes, identifying task and communicating progress. I’ve seen a few patterns to address this.

Product management

Collecting feedback from customers and using that feedback to guide planning is basic product management. Engineers may end up doing aspects of this, but they should get appropriate credit.

Dedicated support

This is when a company staffs a team to monitor all feedback channels. This team can also aggregate reports and/or work with product management to identify themes.

Support rotation

Distribute the cost of monitoring feedback sources across the team using a weekly rotation. This person will be completely distracted and may identify issues, so it pairs well with an on-call rotation.

Centralized tracking

This can be a spreadsheet or a full-featured bug tracking tool like Jira, but it’s helpful to have a single place to prioritize all issues and feature requests.

Delegated communication

If there’s a team that, say, owns a given GitHub repository, they can own the task of keeping GitHub issues for that repository synchronized with centralized tracking state.

Crowd-sourcing themes

One pattern I’ve seen work well is to split a team into groups, assign each group a subset of feedback, and ask each group to identify themes in that feedback. For example, as part of quarterly planning. This works well with large bodies of inline survey results.

Batch to SSTable

A pattern I’ve seen a couple times for immutable data:

  1. Generate the data using a batch process
  2. Store the data in an an indexed structure (like SSTable)
  3. Expose the structure through an API

The result is a key-value store with extremely high read performance.

The first time I heard about this was Twitter’s Manhattan database. Recently, I saw the pattern again at a different company. Ilya Grigorik wrote about it several years ago in the context of log-structured data, BigTable and LevelDB.

My takeaway is: this pattern is worth considering if:

  • my current store is having issues (no need to fix what’s not broken)
  • I have heavy read traffic
  • I can tolerate latency on updates

The context of log-structured makes me think that might open a door to write access too. Twitter’s post mentions a “heavy read, light write” use-case, although it also describes use of a B-tree structure rather then a simple sorted file for that case. Grigorik’s post mentions BigTable uses a “memtable” to facilitate writes.

Note Web’s IndexedDB has a similar access pattern to SSTable. If I think about remote updates as an infrequent write, then the pattern described here might be a common use-case for Web, which might bring this around full circle: Google crawls the Web in a batch process and updates an index which is read-heavy.

Easy & advanced

An API design pattern I’ve found helpful is to think about usage in two modes: easy and advanced.

This is especially helpful in debates. We may be able to accommodate a valid, but advanced, feature without cluttering the API, by housing it in an advanced subset of the API and docs.

I recently heard another phrasing of the same idea from David Poll: “Common case easy. Uncommon case possible.”

The Manager’s Path

I’m an individual contributor, but I want to better understand management’s concerns, so I’m reading Camille Fournier’s excellent The Manager’s Path. These are my notes.

Many think a neutral relationship with management is good because at least it’s not negative, but there is such a thing as a positive relationship w mgmt.

1-1 mtngs:

  • two purposes:
    • Human connection
    • Private conversation, eg feedback
  • I agree w the above two, and would add a third:
    • To ensure time w otherwise busy ppl; the junior person has the priority
  • Not for status
  • Prepare an agenda. I like a living doc, linked from the mtng invite. Items can be added and referenced any time
  • “Regular 1-1s are like oil changes; if you skip them, plan to get stranded …”
  • “Try to keep notes in a shared document” 👍 I like to link an agenda doc from the mtng invite. (Same for most recurring mtngs.)

As you become more senior, feedback decreases.

Appreciate the fact that current peers turn into future jobs.

Uncertainty
– common every 5-10 yrs
– lots of uncertainty in the world
– ultimately, we have to rely on ourselves

People aren’t good at saying what they mean in a way others can understand, so we have to listen carefully to words, and non-verbal cues indicating the person feels understood.

“Be prepared to say anything complex a few times and in diferent ways.” I’ve found such repetition frustrating in the past. It’s validating to see this advice.

Effective teams have good onboarding documents. Have new hires update the docs as their initial contribution.

“What you measure, you improve.”

Beware alpha-geek tendencies. In particular, the tendency to lecture and debate.

Mentorship skills:
– keep an open mind, since the mentee brings fresh eyes
– listen and speak their language. If you can’t hear the question being asked, you can’t provide good answers
– use the mentorship to build your network

“Tech lead is not a job for the person who wants the freedom to focus deeply on the details of her own code.”

“… the tech lead role may be held by many different stages of engineer, and may be passed from one engineer to another without either person necessarily changing his functional job level.”

“… we know from the title that it is expected to be both a technical position and a leadership role.” In other words, it’s not necessarily superlative, ie TL != best.

“The tech lead is learning to be a strong technical project manager… and [is] learning how to handle difficult management and leadership situations”

“Realistically, it is very hard to grow past senior engineer 2 without ever having acted as a tech lead, even on the individual contributor track… people skills are what we’re asking the new tech lead to stretch, more than pure technical expertise.” This stands out to me because of the tension between manager and maker modes, to use Paul Graham’s terminology.

“Being a tech lead is an exercise in influencing without authority …” Including building a psychological skill set for managing associated stresses.

“From now on … balancing is likely to be on of your core challenges.”

Currently, it feels like I’m working two jobs, manager mode during the day, and maker mode in morning and evenings. Regular, project-specific “cadence” meetings have helped reduce ad hoc discussions, fwiw.

Ah, a few lines later: “Some days you’re on maker’s schedule, and some days your on manager’s schedule…It’s very difficult to get into the groove of writing code if you’re interrupted every hour by a meeting.”

“Part of your leadership is helping the other stakeholders … respect the team’s focus and set up meeting calendars that are not overwhelming for individual contributors.” I’m very happy to see this in a book about managing thought workers.

Main roles of tech lead

  • Architect and business analyst. Design the system enough to provide estimates and ensure requirements are met
  • Project planner. The goal is to maximize parallelization
  • Developer and lead. Write code, but not too much. The goal is the project (and team development), not individual tasks

“Sometimes tech leads are tempted to go to heroics and push through obstacles themselves… [but] you should communicate the obstacle first.” I can relate with the former and appreciate the actionable latter.

“Teams often fail because they overworked themselves on a feature their product manager would have been willing to compromise on.” So, communicate.

“… most managers will expect their tech leads to continue writing as much code as before … It’s generally a pure increase in responsibility …”

The goal of a project plan is a “degree of forethought, in places where you can reasonable make predictions and plan … The plan itself … is less important than the act of planning.”

Take time to explain. No one who’s not actively working on a project should be expected to immediately know and understand project details.

Do a premortem as part of project planning. How could the system fail, and what could we do to recover?

“Having the focus to build something big yourself is a distant memory.”

The agile principles can be a healthy alternative to rigid process 👍 I think they’re great.

“… no two great teams ever look exactly alike in process, tools or work style” The best thing I’ve seen is an appreciation of experimentation and iteratively building a style that works for the current team. A basic project plan, ie list of tasks, also seems like a universal business requirement. Put another way, revisiting that plan periodically seems like a reasonable, universal starting point.

Qualities of a great tech lead:

  • Understand the architecture
  • Help build, but involve others
  • Lead decisions, but do so collaboratively
  • Communicate

“You want to encourage others on your team to learn the entire system … but you don’t always need to be self-sacrificing” There’s the need for a sense of balance again.

“Your productivity is now less important than the productivity of the whole team.” But how to improve the productivity of the team without putting on a management hat? Fournier gives an example: “Represent the team in meetings.”

Possession of communication skills differentiates successful leaders.

“Practice repeating things back to people to ensure you understand them.” I like this! I think it pairs well w advice earlier in the book to listen and observe non-verbal cues.

Communicate and listen.

I’d add that the tech lead label can also make one a focal point for questions, eg support, which can disrupt focus work. I like the pattern of having a support rotation, but depending on the company, the convention may be to simply ping the TL.

“Respect the ‘maker schedule’ for reports” 👍 As a general rule, I appreciate biasing toward contiguous meeting blocks.

Autonomy … is an important element of motivation.” I see this w external contributions too. Maximizing an integrating team’s autonomy frees them to meet their goals w minimal bottlenecks.

Site reliability

Google’s SRE handbook, summarized in The Calculus of Service Availability, and the accompanying Art of SLOs workshop materials, are great. Here are a few things that stand out to me.

SLI vs SLO vs SLA

As defined in the chapter on Service Level Objectives:

  • SLI = Service Level Indicator. In other words, a specific metric to track. For example, the success rate of an endpoint. Have as few as possible, to simplify reasoning about service health.
  • SLO = Service Level Objective. A desired SLI value. For example, a 99% success rate.
  • SLA = Service Level Agreement. A contractual agreement between a customer and service provider defining compensation if SLOs are not met. Most free products do not need SLAs.

The “Indicators in Practice” section of the SLO chapter provides some helpful guidelines about what to measure:

  • User-facing serving systems –> availability, latency, and throughput
  • Storage systems –> latency, availability, and durability
  • Big data systems –> throughput and end-to-end latency

In the context of less is more, note each domain has 2-3 SLIs.

Reasonable SLOs

Naively, I’d think a perfect SLO would be something like 100% availability, but the “Embracing Risk” chapter clarifies all changes have costs. Striving for 100% availability would constrain all development to the point where the business might fail for lack of responsiveness to customer’s feature requests, or because it spent all its money on monitoring.

Additionally, customers might not notice the difference between 99% and 100%. For example, “a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability!”

Related, a dependency’s SLOs can also provide a guideline. For example, if my service depends on a service with 99% availability, I can forget about 100% availability for my service.

I find downtime calculations (eg uptime.is) helpful for reasoning about appropriate SLOs:

  • 90% = 36d
  • 99% = 3d/yr
  • 99.9% = 8h/yr
  • 99.99% = 52m/yr
  • 99.999% = 5m/yr

The Art of SLOs participant handbook has an “outage math” section that provides similar data, broken down by year, quarter and 28 days.

So, if our strategy is to page a person and have them mitigate any issue in an hour, we might consider a 99.99% SLO. A 5 minute mitigation requirement is outside human ability, so our strategy should include something like canary automation. In this context, a small project involving a couple people on a limited budget should probably consider a goal of 90% or 99% availability.

I found it helpful to walk through an example scenario. The Art of SLOs participant handbook provides several example “user journeys”. For example, I work on a free API developers consume in their apps. This fits the general description of a “user-facing systems”, so availability, latency, and throughput are likely SLIs. Of these, most support requests concern availability and latency, so in the spirit of less is more, I’d focus on those.

I have an oncall rotation, pager automation (eg PagerDuty), and canary automation, but I’m also building on a service with a 99% availability.

We can reasonably respond to pages in 30 minutes, and fail out of problematic regions within 30 minutes after that, but we also have occasional capacity issues which can take a few hours to resolve.

So, 99% seems like a reasonable availability SLO.

A latency SLI seems more straightforward to me, perhaps because it can be directly measured in a running system. One guideline that comes to mind is the perception of immediacy for events that take less than 100ms.

A nice data mart 🏪

The data mart is a subset of the data warehouse and is usually oriented to a specific business line or team

https://en.m.wikipedia.org/wiki/Data_mart

I don’t have a lot of experience with data marts, but I recently met one that seems nice and simple.

The store benefits from a few other abstractions:

  1. a service that just ingests and persists client events
  2. a query abstraction, like Hive
  3. trustworthy authentication and list membership infra

Given these, the store in question simplifies the process of utilizing data by abstracting a few common requirements:

  1. a simple config DSL specifies which query to run, the frequency to run it, the output table, deletion conditions, etc. Specifying config via files enables use of common source control tools.
  2. three predefined processing stages (raw-to-normalized, normalized-to-problem-specific, problem-specific-to-view-specific). New event sources, aggregations and views can be independently defined by adding new config files.
  3. common styling and libraries for data visualization
  4. access is generalized to a few tiers of increasing restriction, eg team, division, company. The lowest level might be freely granted to teams for their own business intelligence, and the highest level restricted to executives for making revenue-specific decisions.

In retrospect, this seems pretty straightforward. I’m remembering a tool from another team (basically Hadoop + Rails + D3) that had the same goals, but didn’t have the query, scheduling or ACL abstractions underneath. It was replaced by an external tool that was terrible to the point of being unusable, but more secure. Eventually, we dumped normalized data in a columnar store that was also secure and easier to use for our team’s business intelligence, but would’ve been insufficient for things like periodically updating charts. I guess it’s the combination of data store features and supporting infra that makes the magic happen.

Dave Chang interviews Preet Bharara

Dave Chang, chef and restaurateur, interviewed Preet Bharara, former US attorney for the Southern District of New York on June 20th, 2019. Their discussion focused largely on professional development and management and identified commonalities in their respective professions. I too identified commonalities with my experience in software development, so I wanted to take some notes for future reference. I tried to clearly quote and paraphrase, but this isn’t intended to be a transcript. I summarize, merge, reorder and comment on the thoughts.

Bharara’s book Doing Justice was the inspiration for the interview. Chang’s recommended it to many of his managers. He found the process by which Bharara approached criminal justice was the same as for being a chef. Bharara clarifies the book was intended for anyone, at any level of an organization, and is about how to approach problems in general.

The book has a chapter on asking questions. Junior and senior members of an organization need to feel safe asking questions. Chang comments that not asking questions is how we start making mistakes.

Innovation is important, but isn’t always dramatic. Innovation can take the form of thinking about a problem differently, and come from anyone at any level of an organization. It’s important to cultivate a “culture of innovation”. It’s insufficient to have a couple innovative people. Management must respect innovation.

This ties back to asking questions; it’s important to understand and question the rationale behind the status quo. Doing things one way because that’s the way they’ve always been done is insufficient. For example, until recently no one thought to use wire-tapping for inside trading investigations, even though insider trading is an act of communication.

Bharara describes the slow pace of change in government and how we have to work around that. His was the first US attorney’s office to contract with a data analysis firm, and the first to have a twitter account. He describes people looking at him like had three heads, which I find validating; I’ve felt insecure before expressing an unorthodox view.

At one point, Bharara recognized he understood law well enough, but had no training in business management. Two things are important for institutions: continuity and change. We want continuity of values and a culture of innovation.

People don’t like change. The legal and culinary professions are especially averse to change. Chang describes chefs dismissing advanced cooking techniques: “I don’t need to learn anything. I have fire. I have chicken.”

Chang wrote down a line from the book: “There are people who fight for the status quo and reject change.” (Aside, this fits the Economist’s definition of “conservatism”, so there’s a positive side of this too.)

How do you change an organization to be more open to innovation? It may be sufficient to identify and support a minority who embrace the concept. Bharara comments: “Not everyone is going to be a leader. You want to have more leaders than the average organization, but a lot of people are going to be followers.” Chang asks: “Can you be effective at your job as a follower?” Bharara clarifies a distinction between innovation and execution. Both are valuable. Some people are better at one or the other. Few are good at both.

Different people have different skills. As we ascend higher in an organization, people become more specialized. Any one person may be better than average in any role, but the difference between the best team and the worst team is how closely people’s skills are aligned with their roles.

Chang asks Bharara if he was successful at identifying people’s skills in his first management job as US attorney. He responds: the most important part of being a leader, because one person can’t do everything, is identifying who the best people are and putting them where they belong. He consulted a lot. He also saw value in a balance of, say, aggressive and cautious, people on a team.

Promotion isn’t always a good idea. Different levels require different skills. Bharara’s unaware of any manager who doesn’t have a record of significant personnel mistakes. Chang comments this is exactly the case in the culinary industry too. Traditionally, people are promoted in a kitchen based on excellence at one level, but that is not an indicator of excellence at the next level. Bharara agrees and describes law offices as typically having poor management because there are no business people involved. Management and individual contribution are completely different skills and have a completely different reward structure. For example, no US attorney has tried a case in recent history because they’re busy managing. Bharara codified this by prohibiting leads from participating directly in cases describing that as an “indulgence” for a manager.

Self-awareness is important in this context. It’s beneficial for people to recognize whether they want to manage other people. Bharara would ask people seeking promotion “Are you sure you want that?” He continues: “Some people are so ambitious they think that there’s a natural progression to their career that must include certain kinds of promotion … I wish more people thought about their own fun and ability rather than always being on this rat race to have another item to put on their resume.”

Chang acknowledges the same is true in the kitchen. As an executive chef, he no longer cooks. Bharara talks about his difficulty describing his job, but it boils down to “meetings”. Leaders oversee and are the outward face of an organization. Bharara paraphrases Pat Fitzgerald, a former US attorney: when you have the right people, who know what they’re doing, the job of the leader is to get out of the way and let them do it, and when they’re not doing it, to steer them.

Likewise, folks in leadership should be aware of their skills, roles and the fact they are often not the best choice for direct execution. “If you want something done well, you have to do it yourself” is an anti-pattern in this context. Chang describes chefs taking direct control in times of stress, but because they’re not involved in the day-to-day production of the kitchen, this is often disastrous: “You’re going to ruin the flow of the kitchen through entirely one’s own ego.”

Bharara describes two motivations for this:

  1. leadership thinks “I could do this better”
  2. leadership is trying to demonstrate they add value

Chang describes a risk at the upper limit of ability: the person eventually creates something only they can maintain, or they run the organization in a way that only works for them. Both are bad for the organization. Part of Chang’s job is to shake them out of it.

Chang asks how do people adapt to loss of control and recognition they’re not the best at everything. Humility is helpful. People presume the head of the office is the best at everything. Bharara describes having “warring self-doubt”, which was validating for me to hear. He also describes being very nervous about starting a new stage in his career when he created his podcast. Consulting with experts is essential. The difference between good and great is consultation.

Talent is often the greatest obstacle to becoming a great chef. At some point, talent is no longer the most important factor to success. Chang’s describes telling talented people they need to grow up. I wonder if he’s talking about a threshold between individual contribution and management, and if this is in conflict with the earlier discussion about self-awareness.

The interview closes with discussion of making decisions under stress. Chang jokes that every day in a restaurant is like defusing a bomb. Bharara describes the tension between imminent danger and sufficient evidence. I suppose the general theme is problem solving under pressure.

Another general theme is how to prepare for the unknown. Judgement is as important as education and credentials. Bharara comments there are lots of intelligent people he wouldn’t put in charge of anything; some folks are much more comfortable with contemplation over a long period of time. Bharara describes the importance of core values in these moments. For SDNY, the mission is: “Do the right thing in the right way for the right reasons every day and that’s all.” He paraphrases To Kill A Mockingbird: trying to do the right thing, is the right thing.

Good behavior is important for effective management. Fear, intimidation and perfectionism doesn’t work in the real world. Bharara paraphrases Eisenhower: hitting people over the head is assault, not leadership. Empathy, respect and even temperament are much better. Chang acknowledges that’s a lot to ask of someone who just wanted be a cook.

Bharara states one of his goals is to never let people you lead see you freak out. He freaks out with his closest deputies, but the organization as a whole benefits from calm leadership.