Software engineering notes

Archive for the ‘notes’ Category

Dave Chang interviews Preet Bharara

leave a comment »

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.

Written by Erik

October 13, 2019 at 11:48 am

Posted in notes

Mobile Growth meetup 9/21/17

leave a comment »

Meta

Branch runs a nice mobile growth meetup I’ve attended a couple times. The one last night was in the Microsoft office (formerly Yammer) in the Twitter building.

Credit to Prakhar for asking questions about these notes that led to more clarifying detail.

Notes

Intro

What’s worked?

  • Using a wait-list to alleviate cold start; complete profile to advance in list
  • Providing VIPs with promo urls that point at their profile. This drives downloads and enables warm signup
  • Targeting individuals for trip-appropriate travel ads based on their check-out dates
  • Providing teen demographic with feedback features, eg "likes", increased retention by 5%

How to get users?

  • Maximize free, organic stuff first, as opposed to buying keywords, then layer "marketing mix" (paid marketing channels) on top (to get "halo effect"), ie pr > ads
  • All news is good news in early days. Being exclusive is ok. People complaining is ok
  • Facebook ads accounted for 20% traffic
  • Have 2-3 marketing channels to account for fluctuating performance. Continuously try new channels

What didn’t work?

  • Test performance of pics on app store listing
  • Celebrities are well known, so using their pics is tempting, but usage without permission implies endorsement and they may take action

Reengagement & overlooked metric?

  • App quality [1]
  • Minimize registration requirements. How much info can you capture later? Reducing one field can have a big impact. Prioritize input hints and assistance before paid marketing
  • Try requesting push earlier; not first, but not last, eg so you can push "We didn’t mean $3.99. We meant $2.99"
  • Ask for easy things first, which will help people feel invested and more likely to grant hard things later

Metrics to obsess over?

  • Product quality
  • Predictive churn
  • Make it hard to cancel, eg at least ask why

Thoughts on iOS 11?

  • In-app purchases process is better
  • Live photos, which are easier to produce than video and more compelling than still
  • Getting featured in app store is no longer make/break for business

Cause of FB acquisition performance change?

  • This was regarding "How to get users?" answer above mentioning performance fluctuation
  • Unclear, but timing corresponded with new FB interstitial when exiting app, eg to app store

Snapchat ads?

  • To early to tell

Google’s UAC campaign?

  • One panelist didn’t use Google ads because FB CPI is lower

How to reengage users who don’t create account?

  • Low involvement indicates low intent and will be expensive to reengage
  • Request push earlier in registration
  • Collect retargeting info on app install and then use ads to drive registration completion

How to AB test frequently?

  • This was regarding Laughly’s two-week experiment cycle
  • Only test one thing at a time. Literally, only one variation in the app every two weeks (to reduce noise) [2]

Top recommendation?

  • Experiment & fail fast
  • Prioritize feature requests from users
  • Test new marketing channels
  • Acquisition & retention are the same

Footnotes

[1]: There wasn’t a specific metric mentioned. The general idea was: invest in app quality before driving traffic to app, ie if an app’s unusable, no amount of growth tuning will retain users.

[2] This was my top takeaway. Presumably this also reduces engineering complexity and improves UX consistency. The pitch was purely about logical correctness in experiment construction, but the person who asked the question mentioned their experiments take months to run, which would seem to indicate a significance (or quality) concern. I also appreciated the conceptual simplicity. I suppose a follow-on requirement is to have a smaller eng org, so folks don’t feel blocked by limited release opportunities. In my experience, we tried to scale eng by running multiple experiments simultaneously, but the tech required to support this was complex, to the point where I’m now looking back and wondering if we should have just done less 🙂

Written by Erik

September 22, 2017 at 4:22 pm

Notes from Bill McNabb’s talk at Twitter 2017-07-27

leave a comment »

Bill McNabb is CEO of Vanguard, which promotes gender diversity internally and at companies they own shares in. I thought the rationale he described was eloquent and applicable in general. Three points stood out.

First, the goal is corporate performance. Diversity provides material value.

Second, the probability of having all effective leaders in a group partitioned by gender is lower than in an unpartitioned group.

Third, research findings (example) support the hypothesis that a diverse board yields higher performance.

Written by Erik

July 27, 2017 at 12:19 pm

Posted in notes

Tagged with ,

Notes from Kyle Neath’s presentation at Twitter on 5/31

with 3 comments

  • Slides http://warpspire.com/talks/responsive/
  • hashbang urls
    • are a kludgy workaround for lack of history api. Since history api is coming, they have no future. Since urls are forever, especially w/ tweets being stored in the lib of congress, use of hashbangs results in permanent support for a temporary condition.
    • break pre-existing url fragment behavior
    • result in confusing routing logic
  • “responsive web design” is adapting to client and seeming responsive to user input
    • page load isn’t just a benchmark; a page is only “loaded” when the user can scroll, read text, and click links
  • well-designed urls provide a command-line-like interface for web apps
  • all web assets should have a url, i.e., navigation should not allow access to a resource that cannot then be accessed directly via a url
  • native elements should behave as the user expects
    • do not modify common key combos, e.g., shift + click
    • take advantage of the back button, tabs, links, etc
  • responsiveness is as much about performance as perception
    • wait ~500ms before showing loader image; showing loaders immediately can actually make the page seem slower
  • ssl
    • is required now that there are common, easy ways to sniff credentials
    • a new ssl handshake is very slow, and required for each domain
    • use http keep-alive to reuse ssl connections
    • multiple parallel requests to a new domain will each have to perform a handshake; instead, complete one fast request, and then reuse the connection for subsequent parallel requests
    • github optimized its backend to 40ms latency before realizing that the ssl handshake takes 500ms
      • a case of perception > performance
      • favor science over theory, i.e., test time-to-usable in multiple regions instead of just running perf tests on components
    • templates
    • use something simple, e.g., mustache
    • avoid rendering on client and server; pick one
    • kneath prefers server-side
    • for server-side rendering, passing html back as one value in a json object allows for passing data back in other keys
  • html 5 history api
  • allows for much richer state management. See github’s new issues dashboard

Written by Erik

May 31, 2011 at 8:19 pm

Posted in notes

Tagged with , , , ,

Notes from Neil Gershenfeld’s 5/24 talk at Twitter

leave a comment »

My mind was just blown by a talk from Neil Gershenfeld, director of the Bits and Atoms lab at MIT. His team created the fab lab. Here are  some notes

Written by Erik

May 24, 2011 at 12:45 pm

Posted in notes

Tagged with , ,

Notes from Rob Pike’s 5/12 talk on Go at Twitter

leave a comment »

  • See golang.org for language documentation
  • W/in a factor of 2 slower than C/C++. Generally w/in 20% speed of c/c++ programs
  • Intrinsically safe
  • This talk has been presented before, so the slides may be online. see google io 2010 archive
  • check out article in Register about Go that quotes Odersky: “I like a lot of the design decisions they made in the language … Basically, I like all of them.”
  • built on 4 self-reinforcing principles: simple, ortho, succinct, safe
  • see axiom of choice in type theory
  • public/private hint in variable name is one of the best things about the language
  • see CSP tradition
  • uses a deterministic model, channels, for concurrency
  • the “go” keyword launches a go routine
  • “for { … ” declares an infinite loop
  • expressiveness comes from orthogonal composition of constructs
  • Go conceived while waiting for 45 min gcc compilation
  • Go app engine sdk is a complete installation vs building from source

Questions

How is the language intrinsically safe?

  • no stack overflows

Interoperability?

  • native swig support for C/C++ progs
  • no java interop

Exceptions?

  • no try/catch
  • uses panic/recover
  • function-level, not statement-level

Channel implementation?

  • not like erlang channels
  • passing channel over netchan is coming

Generics?

  • Core team has members that believe generics must and must-not be included

Upgrading?

  • gofix rewrites code
  • gofont pretty-prints/formats code

Inspirations?

  • Oberon
  • New Squeek
  • Didn’t cherry-pick features to build an ideal language, but they did include elements that helped them be productive

Written by Erik

May 12, 2011 at 11:24 am

Posted in notes

Tagged with , ,

Getting started with unit testing for Node.js

with 3 comments

I’m diving into unit testing with Node.js, and my first stop is nodeunit. Luckily, Caolan McMahon wrote an excellent introduction to nodeunit on his blog. Thanks, Caolan.

I installed nodeunit via npm no problem: npm install nodeunit

All the examples in the Installing nodeunit section worked fine, but I needed to add
var events = require('events');
to the first code sample in the Testing asynchronous code section to get those tests to pass. So, the top of my test-doubled.js file looks like:

var doubled = require('../lib/doubled');
var events = require('events');
...

Farther down in the blog post, in the Shared state and sequential testing section, there’s a code sample with the events include in it, so I think I’m on the right track.

In the Test cases, setUp and tearDown section, I had trouble getting the tests to run. After referencing the project’s README file, I tried adding a callback arg to setUp() and tearDown(), and calling the callback, which worked. So, my code looks like:

...

var testCase = require('nodeunit').testCase;

exports.read = testCase({
setUp: function (callback) {
this._openStdin = process.openStdin;
this._log = console.log;
this._calculate = doubled.calculate;
this._exit = process.exit;

var ev = this.ev = new events.EventEmitter();
process.openStdin = function () { return ev; };

callback();
},
tearDown: function (callback) {
// reset all the overidden functions:
process.openStdin = this._openStdin;
process.exit = this._exit;
doubled.calculate = this._calculate;
console.log = this._log;

callback();
},
...

With the minor tweaks above, I was able to get all tests to pass:
Screenshot of all tests passing

🙂

Written by Erik

December 6, 2010 at 11:11 pm

Posted in notes

Tagged with , ,