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.
David Chapman quotes Kegan a lot in his "Meaningness" blog. I included one link, but you should find more of his writing linked from there. Check out the rest of the site as well.
ETA: From the (Stanford) article this thread is attached to...
> Kegan (Robert) introduced his theory of self-evolution in 1982 in his book, The Evolving Self. In his later book, In over Our Heads: The Mental Demands of Modern Life (1994), he presented a revised version of his theory and further discussion of the implications of his work for society.
Of those two books, The Evolving Self is the easier read. I would start with that one.
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.
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.
"Sour grapes" was in response to sibling comments here, not the original article!
The additional stuff you mentioned here--all of the annoying fiddly details for editing and whatnot--is exactly what should've been used to justify the stack.
The problem is that all of the extra stack baggage frankly looks really baroque, even with the trickiness of the UX you just hinted at.
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...
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.
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.
Whether someone spent a second or a year with the page open is irrelevent to how many servers you need to have running.
How many pageviews or requests per second is.
Aince this is an article about infrastructure no body cares about Engagement time.
