HN user

wting

2,942 karma

io at williamting.com

https://github.com/wting

[ my public key: https://keybase.io/wting; my proof: https://keybase.io/wting/sigs/yTnPQ0DZR5vV9WRhYq8SP7V56pyKc3Z8fMQQE9cADBQ ]

Posts14
Comments291
View on HN

Fool me once, shame on... shame on you

— George Bush, 2002

The original saying: Fool me once, shame on you. Fool me twice, shame on me.

I think an intellectually honest take is that it's advantageous and prudent to depend on allies and neighbors; leveraging each party's strengths for efficiencies over strategic autonomy. This trade-off is commonly debated with depending on US military hardware in favor of EU military hardware (e.g. France's long standing position for EU strategic autonomy), or vendor lock-in with AWS vs cloud-independent offerings.

The problem is when an ally becomes inconsistent and/or uncooperative; a high stakes version of prisoner's dilemma. At which point do you replace an ally's offerings with more expensive, and often inferior, alternatives? The general populace rarely has the appetite for the short-term economic pain required to achieve long-term strategic independence.

Rust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach.

If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.

Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.

I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.

This requires those with power to relinquish authority and/or try new, unfamiliar practices and accept possible failure.

Any company/organization can theoretically change its culture, but it's quite difficult in practice.

I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.

And yes, I don't like managers trying to shape communication patterns.

I'm a manager who shaped communication patterns (e.g. default conversations to a public channel) because we're solving different problems. By moving conversations to a public channel away from an individual, we're improving redundancy and reducing single points of failure. Our primary responsibility, which understandably garners discontent, is to prioritize the system over the needs of individuals, within reason.

There are many issues resulting from defaulting conversations in private channels or DMs that you've probably seen first-hand.

Visa, Mastercard, payment processors, banks, etc act as accountability sinks[0] for governments and political group by design. They are arbiters for moving/blocking money, not taking principled stances; there is no net neutrality equivalent for financial networks.

There's a lot of wasted discussion talking about an intentional design decision because they're arguing from consumers' perspectives, ignoring the huge benefit to political organizations (e.g. freezing Russian assets).

0: https://aworkinglibrary.com/writing/accountability-sinks

Because of goomba fallacy.

The EU is not a hegemonic state, but rather an economic supranational organization. France/Germany tend to be primary proponents of increased EU strategic autonomy, while Poland/Czech/Baltic states are less supportive.

Similar to recent discussions of self-hosting, it's a tradeoff of autonomy/control vs efficiency.

Chrome launched in an era where IE didn't stop the gazillion pop ups and crashed pretty often losing dozens of windows, before tabbed browsing and with no restore. Firefox was a resource hog due to memory fragmentation.

Google was also the company that espoused, "Do no evil" and contributed a bunch to open source. A lot has changed since then.

For clarification, "The Matrix" refers to the urgency vs importance decision matrix and not the movie: https://asana.com/resources/eisenhower-matrix

It's a framework to prioritize important tasks instead of falling into the agency trap, akin to prioritizing meaningful strategic tasks such as product development and tech debt instead of fighting fires.

Another perspective is that planning is a breadth-first traversal of the solution space, and coming up with a path to the solution. When reality hits and the path is often wrong, one can switch to other paths quickly since the graph was created ahead of time. It's writing the table of contents for a book before fleshing it out.

Without planning, a depth first traversal is a high risk endeavor in the likelihood that the that path is wrong but backtracking and creating the graph is comparatively expensive and susceptible to sunk cost fallacy. Depth-first traversal is writing the book a chapter at a time without a table of contents in mind.

After the roadmap is finalized, as the manager I ask every one on my team to stack rank at least N preferred projects from the roadmap. I map preferences to projects with some optimizations (e.g. career progression, avoiding knowledge silos), review it with everyone, and then commit for the roadmap.

If there's grunt work that no one wants to do, I distribute it fairly among the team. Fairly can be splitting it up evenly among the team (everyone refactors _n_ files) and sometimes it means we round-robin the responsibility (e.g. quarterly compliance reviews with auditors). Obviously this depends on the team size and role in the company, but I think it's only come up a few times over ~4 years.

It does, though. Your karma basically determines the visibility of any new post you try to make.

User karma has no impact on the default sort ranking[0]. The source code is available here (as of ~2018): https://github.com/reddit-archive/reddit/blob/master/r2/r2/l...

And low-karma or new accounts are de facto shadowbanned.

User karma is impacted by mods' use of AutoMod on a per subreddit basis or fraudulent[1] accounts, but otherwise there is no site-wide application of user karma.

Source: I spent some time experimenting and implementing alternative rankings at Reddit.

0: Subreddit hot score, not applicable to logged in users' default feed.

1: Shadow banning (vs direct banning) fraudulent accounts makes it more difficult to reverse engineer signals used to identify malicious accounts.

Yes, but in the end it's because people who like Go because they prioritize a certain set of features (language, community, ecosystem, etc), and those who prefer non-Go languages prioritize other features.

I don't like Go personally, but I have advocated for Go to be used in many situations depending on context. It's unproductive to start a language war here since it's generally situation-dependent.

I have two similar commands, both written as zsh functions but easily adaptable to shell scripts, other shells, etc.

# wait on a path and do something on change, e.g. `wait_do test/ run_tests.sh`

    wait_do() {
        local watch_file=${1}
        shift

        if [[ ! -e ${watch_file} ]]; then
            echo "${watch_file} does not exist!"
            return 1
        fi

        if [[ `uname` == 'Linux' ]] && ! command -v inotifywait &>/dev/null; then
            echo "inotifywait not found!"
            return 1
        elif [[ `uname` == 'Darwin' ]] && ! command -v fswatch &>/dev/null; then
            echo "fswatch not found, install via 'brew install fswatch'"
            return 1
        fi

        local exclude_list="(\.cargo-lock|\.coverage$|\.git|\.hypothesis|\.mypy_cache|\.pgconf*|\.pyc$|__pycache__|\.pytest_cache|\.log$|^tags$|./target*|\.tox|\.yaml$)"
        if [[ `uname` == 'Linux' ]]; then
            while inotifywait -re close_write --excludei ${exclude_list} ${watch_file}; do
                local start=$(\date +%s)
                echo "start:    $(date)"
                echo "exec:     ${@}"
                ${@}
                local stop=$(\date +%s)
                echo "finished: $(date) ($((${stop} - ${start})) seconds elapsed)"
            done
        elif [[ `uname` == 'Darwin' ]]; then
            fswatch --one-per-batch --recursive --exclude ${exclude_list} --extended --insensitive ${watch_file} | (
                while read -r modified_path; do
                    local start=$(\date +%s)
                    echo "changed:  ${modified_path}"
                    echo "start:    $(date)"
                    echo "exec:     ${@}"
                    ${@}
                    local stop=$(\date +%s)
                    echo "finished: $(date) ($((${stop} - ${start})) seconds elapsed)"
                done
            )
        fi
    }

# keep running a command until successful (i.e. zero return code), e.g. `nevergonnagiveyouup rsync ~/folder/ remote:~/folder/`
    nevergonnagiveyouup() {
        false
        while [ $? -ne 0 ]; do
            ${@}

            if [ $? -ne 0 ]; then
                echo "[$(\date +%Y.%m.%d_%H%M)] FAIL: trying again in 60 seconds..."
                sleep 60
                false
            fi
        done
    }

To add on to ethbr0's good response, a few other things to do:

1. Find early adopters of the thing you're building who are willing to use and give feedback (bugs, friction logs) in the early stages of the feature.

2. Build relationships with your users / VIP users and meet regularly to discuss friction points and upcoming features (feasibility, etc). To make it time efficient, make sure you're talking to staff engineers who can speak on behalf of a significant portion of your user base. Make sure your team is closing the feedback loop with these engineers (i.e. shipping things that address their concerns) in a timely fashion.

There's too much money in Rust, and many power brokers at play here from Google, Amazon, MS, et al. People are incentivized by money and career growth to lead Rust's future. I think core members should be the one leading the foundation, but there are a few reasons this hasn't happened:

1. Core members are burnt out.

2. This is not their primary skill set (administration vs engineering/community building).

Other languages have been blessed with an administrative group (GvR/Python[0], Hickey/Clojure), corporate sponsor (Pike/Go), or committee (C++, Java). The counterpart for Rust is core member/Mozilla, but there is no appetite for this responsibility.

0: I like this talk about governance models at Pycon 2019, after GvR stepped down as BFDL: https://www.youtube.com/watch?v=mAC83JVDzL8

The person who created Twitter's experimentation platform is also at Reddit, and heavily influenced Reddit's experiment design and review process.

But yes, a revolving door of product leaders and decisions is going to bias towards short term optimization.

One of the ways to measure long term impact is through the use of a golden cohort that is never opted into experiments. Unsurprisingly, I could not get this work prioritized on the roadmap.

We also worked with growth consultants (read: Bay Area B2C product leads) in scoping out some of these ideas. We accrued what I call "product debt" where we launch the MVP but never followed up to polish the feature[0] as they don't improve KPIs.

I assume this is the same with Growth teams everywhere but am happy to be corrected.

Regarding long term impact, we measured this through various dimensions in marketing, recruiting, and user research. The outcomes are largely positive.

______

0: One feature I argued for was an opt out of the mobile app interstitial. It makes sense to show it once or twice, but users aren't going to download the app just because they saw it 50x.

Features are only launched after running a successful experiment.

We try to appeal to power users when possible. For example with the current signup flow has optional emails, though intentionally non-obvious.

This means new users sign up with an email which means we can reduce churn through digests and also reset passwords / prevent account takeovers, a large burden for Reddit's anti spam teams.

I was the EM for Reddit's Growth team around this time. I am responsible for / contributed to a few features like the current signup flow, AMP pages, push notifications, email digests, app download interstitials, etc.

There was a new product lead who joined with many good ideas, but some of them were dark patterns that I heavily protested. After a few months of this, it was obvious that I was going to be reigned in or let go[0]; I immediately transferred to a different org.

Now let me explain the other side of the story. 4 years later, Reddit's DAU, MAU, and revenue have all grown at ridiculous rates[1]. Yes, power users complain—and still continue using the site—but the casual user does not. These dark patterns have been normalized on other websites.

These practices are done because it works.

_____

0: They changed it so I would report to the product lead, which is odd for an EM to report into a product chain and the only instance within the company ever.

1: Many friends are startup founders and I've been at a few startups myself—a byproduct of being in the Bay Area—and Reddit's growth numbers are impressive. As a former employee, I am quite happy about my equity growth.

Stripe | Java Services Infra | SF/Seatle/NYC/Remote (US, Canada) | Full Time

We're leading the charge to servicify Stripe, working closely with product and infra teams. Our team and the service stack is ~18 months old, and growing rapidly. As the hiring manager, I'm looking for engineers who are user focused, excel in a generalist infra role, and comfortable working across multiple teams given our broad scope.

- Senior role: https://stripe.com/jobs/listing/infrastructure-engineer-hori...

- Staff role: https://stripe.com/jobs/listing/staff-infrastructure-enginee...

Please apply through the above links, but I'm happy to answer questions or share details about the team or roadmap. You can reach me via email: wting at stripe dot com

Company policy cannot overrule laws, but it is not illegal to put it in a contract. Companies put in things they can't enforce because it has the same effect of discouraging certain behaviors.

A company's policy cannot prohibit employees from talking about the company. Obviously there is more nuance (e.g. leaking internal info) but in this case we're discussing public events.