We're tracking this in Coda now (https://coda.io/@dpup/post-covid-reopenings) and would welcome submissions from other companies. You can submit here: https://coda.io/form/Share-your-reopening-plans_dg7q5vsZrKB
HN user
dpup
[ my public key: https://keybase.io/dpup; my proof: https://keybase.io/dpup/sigs/aB1SSDGZGYm74MHuxZPgHQPjSv5uN4QAcQlPNtpakig ]
I'm curious to hear what your company is doing and whether their decision is making you consider a move.
I've always struggled with the 9-5 and M-F. It never fit my energy levels. For coding, I'm often most productive in the evening. Mornings are often really slow for me.
And with kids at home, a long contiguous block of time is almost impossible.
I haven't been able to track down an original source for this, but while at Google in mid 2000s I was told it was a joke/hat-tip to Bell labs.
Kegan's work has been quite influential for me, both in helping me understand myself and others.
His later work, collaborating with Lisa Lehey is more actionable, in a work context, but builds on the foundations outlines here.
I can imagine some skepticism, so thought I'd share some of the theory behind why we released this free tool.
Hopefully we all know by now that high-performing teams depend on psychological safety: people need to feel safe to take risks in order to do their best work. What we talk about less is how to cultivate psychological safety.
Psychological safety depends on a foundation of trust and belonging, but unfortunately these aren't static. They need to be constantly renewed.
It has been shown that starting group activities with an activity that encourages vulnerability will renew these "belonging cues" and will change the dynamics of the meeting. People will be more likely to speak up and discussions will be less win/lose. This will allow you to get the most out of the rest of the time together.
Thanks for clarifying and yes, lots of interesting stories to be told around the edges of this post. Some are already written and linked. For example, I'd recommend Why ContentEditable is Terrible by Nick. https://medium.com/medium-eng/why-contenteditable-is-terribl...
Sorry it came across as "sour grapes", the spec for the post is describe the components of your stack, why you use them, and challenges you've faced.
In terms of "display an article" I'd encourage you to think about what that entails for a platform like ours, it's actually a pretty interesting problem space: near-WYSIWYG editing across 3 platforms, post model vs. HTML (hint we don't store HTML), operational transforms, version history, typographic treatments, copy/paste normalization, ingestion API, etc. It's not rocket science, but it's deeper than you might think at first blush.
As I said above, this was from a bio question that got elided during editing. I didn't want to be completely defined by my work, but at the same time didn't want to be overly verbose talking about myself.
Glad you took something from the post though.
This was mostly a hat tip to a scarred past. This is a post about Go's GC tuning philosophy: https://blog.golang.org/go15gc
The point is that we don't really care about the number of uniques or page views. What we actually look at internally on a day to day basis is the amount of time people spend reading and other engagement metrics.
I don't want to be completely defined by my work, but at the same time didn't want to be overly verbose talking about myself.
Also, the original interview had this section as multiple questions; it was collapsed into a single paragraph during editing.
Should be fixed on monday. Was a super weird rendering bug.
Minified, but pretty printed for easier debugging without source maps. The whitespace gzips pretty well.
We're actually having a hard time reproducing (though we've received some interesting screen shots). Our nexus 4 and Nexus 7 look ok. Rest assured we'll be acquiring more devices and will try and fix.
The fix was deployed. Happy keyboard scrolling.
We're looking into this. Trying to find our android test device :-/
This is a surprisingly accurate assessment from someone outside the company: http://www.quora.com/Medium-website/What-is-Mediums-technolo...
But it would be good if we documented this more formally. I'll see if someone wants to write a post.
Typekit understandably wants to make sure that no one else uses the font bundles, so they check the referrer. If you strip referrers it'll block the response and eventually it'll timeout, and show using the default system font.
The choice is a delay for the few people who block referrers or a flash of unstyled content for everyone else.
This was a mistake introduced by a last minute change. We'll have a fix deployed soon.
We have a fix for Chrome coming soon, something we overlooked in a last minute change.
This is likely related to typekit loading. Do you block referrers?
See "Ownership and Licensing of Intellectual Property" here: https://medium.com/policy/9db0094a1e0f
"You retain ownership of all intellectual property rights in your User Content. Medium (and/or other third parties) retains ownership of intellectual property rights in all Content other than User Content."
Thanks, this is useful. It's weird you are getting a 403 on the typekit request. It looks like the font-loader probably just times out. Do you happen to have any extensions that might strip referrer
Any chance you can dump a net tab trace using Firebug or similar.
This is related to Typekit font loading, as outlined here:
http://help.typekit.com/customer/portal/articles/6852-contro...
We digged into it when it came up before, but I'll have another look and try to get in touch with the Typekit folks.
Could I get your UA string, it works fine on Chrome on my Androids.
Really can't reproduce this. Tried it at home and at coffee shops. If you have anymore debugging info feel free to send it my way (dan at medium dot com).
It was added to block referrers on unpublished drafts. We have been meaning to take it out for published posts, but for a couple of reasons it's not as trivial as flipping a flag.
"break the web" is a little melodramatic though.
Thanks for the report, we hadn't noticed any problems. Will look into it.