The Product Thinking That Built Slack & Twitter, with April Underwood
Twitter and Slack are two of technology’s most talked-about companies. They are both category-defining products marked by hypergrowth, each amassing a large base of deeply loyal users and a valuation of more than $20B. But Founders rarely get access to the product decisions being made behind the scenes, or the strategy and frameworks that guided them. April Underwood was instrumental at both companies, first as Director of Product at Twitter and then as Chief Product Officer at Slack. She is a powerhouse product leader with an unusual depth of experience in growing both B2C and B2B products from 0 to 1 to ubiquity and building world-class product teams along the way.
The Future Vision of Microsoft 365
As product makers, we go where human need takes us and strive to navigate the nexus of timeless needs and current realities. Three years ago, we launched Microsoft 365 and began holistically rethinking how our products could work together as an intelligent and connected suite of services. We implemented flexible designs and over time evolved our ecosystem to facilitate not just modern work, but modern life. That ecosystem increasingly decouples app capabilities from the apps themselves, leaving you free to use functionality whenever, however, and wherever you need it. New generations’ embrace of mobile devices for their ease, simplicity, and joy has inspired us to create cross-platform Microsoft 365 experiences that scale gracefully and feel natural to whatever device you choose.
The Importance of Deep Work & The 30-Hour Method for Learning a New Skill
The Law of Productivity: High-Quality Work Produced = (Time Spent) x (Intensity of Focus). The best moments usually occur when a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile. To create a state of flow, one must follow certain rules and embrace deliberate practice through a concept called deep work.
Computers can be understood
This post attempts to describe a mindset I’ve come to realize I bring to essentially all of my work with software. I attempt to articulate this mindset, some of its implications and strengths, and some of the ways in which it’s lead me astray.
Advice to Myself When Starting Out as a Software Developer
Take the time to read two books per year on software engineering; Learn the language you use at work in-depth, to the very bottom; Pair with other developers more often; Write unit tests and run them against a CI; Make refactoring a habit and master refactoring tools; Know that good software engineering is experience, Get lots of it; Teach what you learn.
blog.pragmaticengineer.com/advice-to-m…
Building Twitter’s ad platform architecture for the future
A great advantage of software systems is that they are extremely adaptable. There comes a point in the evolution of complex software systems, however, where that malleability hinders growth instead of facilitating it. At some point, software will approach a stage where it’s no longer serving its purpose — helping people. This was the case for the Twitter AdServer in early 2019. After 10 years of iterative development, the system was too inefficient to further evolve with the organization. When it started, we were an extremely small team of engineers, serving a single type of ad format (Promoted Tweets), generating around 3B of revenue, supporting multiple ad formats - Brand, Video, Cards. Low velocity for launching new products and tightly coupled cross team dependencies with high overhead costs added to the growing complexity of the organization. This demanded a fundamental change in order for us to scale any further.
All Hands on Deck
Slack is a critical tool for millions of people, so it’s natural when Slack going down can feel as stressful as when our power goes out, when the internet stops working, or when our smartphone runs out of battery. What does Slack do when Slack goes down? On those rare times we suffer a total service disruption, the response is, essentially, All Hands on Deck. This happened on the afternoon of May 12th, 2020 at 4:45pm Pacific, which started as a normal day like any other at Slack. This is the story of that day, who was involved in the effort to restore Slack service, and, chiefly, what that process looks like. We hope it gives insights into the machinery, both human and computational, that runs Slack for our millions of customers.
slack.engineering/all-hands-o…
Ready for changes with Hexagonal Architecture
We needed to support the ability to swap data sources without impacting business logic, so we knew we needed to keep them decoupled. We decided to build our app based on principles behind Hexagonal Architecture. The idea of Hexagonal Architecture is to put inputs and outputs at the edges of our design. Business logic should not depend on whether we expose a REST or a GraphQL API, and it should not depend on where we get data from — a database, a microservice API exposed via gRPC or REST, or just a simple CSV file. The pattern allows us to isolate the core logic of our application from outside concerns. Having our core logic isolated means we can easily change data source details without a significant impact or major code rewrites to the codebase.
netflixtechblog.com/ready-for-c…
对低代码、零代码产品的一些看法
业务的复杂度只会转移，是不会消失的。用代码表达，或者搭建系统表达，本质上只是改变了其组织形态，得到的管控方式有所差别，其业务实质是一样的。所以，我们想要通过搭建系统来表达一个业务，其底层就要有对等于主流开发框架的架构，确保拥有完整表达业务需求的能力，然后才去做产品形态上的权衡。
可逆计算的技术实现
最近和一些朋友交流 Low Code 平台的开发经验，发现大多数工作都是由前端架构师主导的，主要精力集中在可视化界面设计器方面，这与可逆计算的理论有着很大的区别。维特根斯坦有一句名言：语言的边界就是我们世界的边界。语言之外的世界是一片黑暗，难以感知且不可言说。当我们专注于通过类型（Type），函数（Function），类（Class），属性（Property）等等这样的术语去描绘我们以为的世界的时候，一些必然的事实就会被自然的遮蔽起来，成为我们视野之外的偶然。我的学术背景是理论物理学，所以可逆计算的思想来源不是传统的计算机科学，而是数学和物理学，所以我在软件构造中所想要强调的不是类型系统，不是函数式，不是对象化，而是结构（Structure）、复杂性（Complexity）和源起于物理世界的规律（Law）。
zhuanlan.zhihu.com/p/163852896
Array Functions and the Rule of Least Power
There is an important tradeoff between the computational power of a language and the ability to determine what a program in that language is doing. Expressing constraints, relationships and processing instructions in less powerful languages increases the flexibility with which information can be reused: the less powerful the language, the more you can do with the data stored in that language. Though the Rule of Least Power targeted programming languages themselves, rather than language features, I think the same ideas still apply. The less powerful your code is, the easier it is to reason about.
jesseduffield.com/array-funct…
我做编辑器这些年：钉钉文档编辑器的前世今生
大家好，我是展新，来自钉钉文档团队。2011 年加入支付宝，一路成长于支付宝的前端团队，孵化了语雀，2018 年到钉钉，开启钉钉文档的旅程。今天主要和大家从另外一个角度来分享，一起来认识编辑器，讲解钉钉文档编辑器的前世今生，让更多对编辑器感兴趣的人能更好地了解这一个领域。
语雀在线表格自研之路
在语雀团队以及体验技术部，不管做什么，我们都会多问自己几个为什么，想透为什么做往往比去思考怎么做更重要。Why：介绍我们在做表格前期的思考。How：讲的是怎么做，以及研发过程中的一些方法和技术选型。What: 谈一谈关于自研的一些心得。
如何选择 WebGL 框架和引擎？
Sugar 是我们从零开始开发的 BI 产品，可以不用写 SQL 制作报表及大屏页面，上半年我们发布了三维场景功能，为了实现这个功能，我们调研了大量 WebGL 相关框架和库，整理了这篇文章，或许以后对你有帮助。
zhuanlan.zhihu.com/p/162878354
Design Docs at Google
One of the key elements of Google's software engineering culture is the use of defining software designs through design docs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions. As software engineers our job is not to produce code per se, but rather to solve problems. Unstructured text, like in the form of a design doc, may be the better tool for solving problems early in a project lifecycle, as it may be more concise and easier to comprehend, and communicates the problems and solutions at a higher level than code.
www.industrialempathy.com/posts/desig…
Data Structures & Algorithms I Actually Used Working at Tech Companies
This article is a set of real-world examples where data structures like trees, graphs, and various algorithms were used in production. I hope to illustrate that a generic data structures and algorithms knowledge is not "just for the interview" - but something that you'd likely find yourself reaching for when working at fast-growing, innovative tech companies.
blog.pragmaticengineer.com/data-struct…
我们看好怎样的 SaaS 公司 | GGV 投资笔记
每一次风口和创业热潮的出现，资本往往都在第一现场“推波助澜”，SaaS 行业也不例外。与大多数在消费互联网下兴起的风口不同的是，SaaS 作为 To B 行业，可以称作是最“慢热”的行业之一。一方面，B 端潜在用户数量和 To B 市场容量充满了想象空间，另一方面，SaaS 产品的成熟度以及用户的 SaaS 使用习惯与付费习惯仍有待培养。尽管是一个周期长、回报慢的行业，资本还是对 SaaS 抱有极大的信心与期待。在 SaaS 行业深耕多年的 GGV 纪源资本的六位管理合伙人，聊了聊他们对 SaaS 行业的看法以及对中国 SaaS 市场的判断。
远望资本程浩：做 To B，一定要避免 9 类错误！
最近几年 To C 创业红利消失，很多人开始关注 To B，特别很多从业者是从互联网的C端业务转去做 To B。在这里我总结出，做 To B 业务最易犯的9类致命错误，希望能让大家在创业的路上少走弯路。
