10 Hard Decisions: A Model for Programmer Productivity
How do you ensure that programmers are using time effectively? What can you do to help them be productive? Managers think a lot about these questions. But too often they get the answers wrong despite being very earnest and smart. This is because they have an unexamined mental model of how programming work is actually done. With an inaccurate model, managers optimize the wrong things and make bad decisions which would otherwise be good decisions in other work environments.
justinmeiners.github.io/10-hard-dec…
Driving engineers to an arbitrary date is a value destroying mistake
In this article we'll be concentrating on high value software projects and why driving engineers to create detailed estimates for these projects, and then pressuring them to complete the software according to those estimates, is a value destroying mistake. Most of us in the software industry have been asked over and over to participate in predictive planning for software projects. Predictive planning is the flawed idea that software projects lend themselves to being planned out like a construction project, using a tool like a Gantt chart. While it is true that a narrow set of low value software projects are tamable with a Gantt chart, high value software projects that fill previously unmet needs do not lend themselves to being tamable by predictive scheduling techniques.
From Despair to Delight: Lessons From Our Biggest Product Launch
Imagine this. You’re prepping for a board meeting or working on a problem definition doc to support your next product release and you find yourself stumped on a company you’d like to reference. Normally, your first instinct would be to fire up Google and search for answers. But what if you couldn’t? What if there were a huge learning curve that you’d have to overcome to use the search engine? This most likely never happens, but what if it were the case: what if only 5% of your company knew how to use Google? This is the analogy we reference when we talk about how and why we built Visual SQL. Our customers consistently rated Chartio as the most usable product, yet the data showed that only 1 in 10 of users were able to make their own charts without any roadblocks.
What a typical 100% Serverless Architecture looks like in AWS!
Two of the reasons why Lambdas are so attractive are their auto-scale (in & out) capability and their pay-per-use pricing model. In order to leverage these capabilities and reach the full benefits of a serverless architecture, we need our other infrastructure components to have the same flexibility. What would such an architecture look like on a web project? At Theodo, we’re loving serverless and using the technology on more and more projects. Some services and patterns start to be used extensively. So we decided to share our architecture best-practices for a web application. If you are new to serverless and looking for a high level guide answering those questions, you’ve come to the right place!
Second-guessing the modern web
I don’t think that everyone’s using the SPA pattern for no reason. For large corporations, it allows teams to work independently: the “frontend engineers” can “consume” “APIs” from teams that probably work in a different language and can only communicate through the hierarchy. For heavily interactive applications, it has real benefits in modularity, performance, and structure. And it’s beneficial for companies to shift computing requirements from their servers to their customers browsers: a real win for reducing their spend on infrastructure. But I think there are a lot of problems that are better solved some other way. There’s no category winner like React as an alternative.
另附：In defense of the modern web
Rebuilding our tech stack for the new Facebook.com
When we thought about how we would build a new web app — one designed for today’s browsers, with the features people expect from Facebook — we realized that our existing tech stack wasn’t able to support the app-like feel and performance we needed. A complete rewrite is extremely rare, but in this case, since so much has changed on the web over the course of the past decade, we knew it was the only way we’d be able to achieve our goals for performance and sustainable future growth. Today, we’re sharing the lessons we’ve learned while rearchitecting Facebook.com, using React (a declarative JavaScript library for building user interfaces) and Relay (a GraphQL client for React).
engineering.fb.com/web/faceboo…
When a rewrite isn’t: rebuilding Slack on the desktop
Today, after more than half a decade of hyper-growth, Slack is used by millions of people with larger companies working with more data than we ever could have imagined when we first started. Somewhat predictably, a few internal cracks were starting to show in the desktop client’s foundation. Additionally, the technology landscape had shifted away from the tools we chose in late 2012 (jQuery, Signals, and direct DOM manipulation) and toward a paradigm of composable interfaces and clean application abstractions. Despite our best efforts to keep things snappy, it became clear that some fundamental changes would be required to evolve the desktop app and prepare it for the next wave of product development.
slack.engineering/rebuilding-…
The process: Making Vue 3
Over the past year, the Vue team has been working on the next major version of Vue.js, which we hope to release in the first half of 2020. (This work is ongoing at the time of writing.) The idea for a new major version of Vue took shape in late 2018, when the codebase of Vue 2 was about two-and-a-half years old. That may not sound like a long time in the life span of generic software, but the frontend landscape had changed drastically during that period. Two key considerations led us to the new major version (and rewrite) of Vue: First, the general availability of new JavaScript language features in mainstream browsers. Second, design and architectural issues in the current codebase that had been exposed over time.
前端状态管理设计——优雅与妥协的艺术
我们谈状态管理，本质上无法摆脱应用层面的架构思维，而且这里仅仅是指围绕数据流的前端应用（Management System、Data Application），我们几乎很少在游戏这种视觉系统中大谈前端状态管理。既然是 Management System，那么我不禁要问，状态管理的目的，是技术的，还是应用的？很显然，状态管理的目的，是为了让应用系统良好运作，保障系统工作稳定准确。而我们要面对的实际情况是什么呢？并非如何在组件之间共享状态。我们的实际情况是，我们需要在不同子模块之间协调，甚至，我们需要在不同的客户端之间协调。这里面的核心点实际上是“业务逻辑”。如果我们同时拥有手机端和 PC 端应用，虽然它们在视图层面完全不同，然而在 business 层面，却是一定一致的，否则系统就不可靠了。如何保障业务层面的一致性呢？
前端开发的瓶颈与未来之路
前端开发的瓶颈到底在哪里，前端技术是否已经走到一个十字路口，全栈化的系统架构是否能改变目前的窘境？本文将根据我自己的开发经历谈谈当下前端开发中遇到的一些问题和想法。
zhuanlan.zhihu.com/p/139731168
Atomic Design
It was 2013, and we huddled with Brad Frost and Jennifer Brook around a sunlit kitchen table in Brooklyn. The four of us had just begun work on a new website for TechCrunch, and we were sketching wireframes in Jennifer’s apartment, wrestling with the new demands of responsive design. Brad pulled out his laptop: “I’ve been playing with a new idea.” Brad’s new idea was atomic design, and it changed the way we work in this astonishingly multi-device world. By thinking about interfaces simultaneously at both the large (page) level as well as the small (atomic) level, we streamlined our process: we introduced more rigorous thought into the role of every element; we fell into habits that improved the consistency of our UX; and crucially, we started working much faster and more collaboratively. Atomic design was our superpower. This wonderful book explains the philosophy, practice, and maintenance of atomic design systems.
atomicdesign.bradfrost.com/table-of-co…
积木 Sketch Plugin：设计同学的贴心搭档
积木（Tangram）Sketch 插件源于美团外卖 UI 的一致性项目，该项目自 2019 年 5 月份被提出，是UI设计团队与研发团队共建的项目，目的是改善用户端体验的一致性，提升多技术方案间组件的通用性和复用率，整体降低视觉改版的研发成本。我们通过积木 Sketch 插件来落地设计规范，可以保证设计元素均从既定设计标准中获取，产出符合业务设计语言的设计稿，而各平台UI组件库中也有对应实现，从而使积木插件成为 UI 一致性的抓手，最终可以减少开发成本，提升交付质量，服务好我们美团的多个业务团队。
复杂风控场景下，如何打造一款高效的规则引擎
美团 App 每天都面临着各类的欺诈、盗号、作弊、套现以及营销活动被恶意刷单、恶意抢占资源等风险。而业务安全团队采用的主要措施和手段就是在业务请求中识别出谁、在什么时间、通过什么方式、做了什么事。这个识别逻辑的制定过程叫做策略的生产。同时，还要对已经完成生产的策略进行快速的验证和落地，以防止风险变化后策略失效。从发现风险经过策略生产、验证，再到最终的落地部署，全流程的处理速度和效果将决定整个业务的成败。本文主要介绍了美团在打造自有规则引擎 Zeus（中文名“宙斯”）的过程中，信息安全团队遇到的挑战以及对应的解决方案，并分享了很多踩过的坑，同时还有一些思考和总结。希望对从事安全领域相关工作的同学能够有所启发或者帮助。
核对体系-资损防控（核对篇）
随着有赞的业务增长，单量与日俱增，业务场景变得越来越复杂，迭代的速度变得更快，出现故障的概率更大，从而产生的资损可能性也变大，这无论对于有赞本身还是对于有赞的商家来说都是很可怕的事情，我们要保证商家在有赞做生意是安全的、值得信赖的，所以及时发现问题、及时止血变得极其重要。同时，我们发现由于业务场景变得复杂，开发人员和测试人员也疲惫地奔波在各种场景的测试中，捉襟见肘，所以需要一个可以通过表中数据反推迭代的代码逻辑、和相关配置是否正确，在这种背景下，我们建立了核对体系，资损防控系统应运而生，我们也可以叫它实时核对系统，今天我们介绍核对体系中资损防控的第一部分：事前和事中处理。
Slack、Zoom 们全军出击（上）
2016年，微软启动 Teams 项目直接对标 Slack，订阅方式除了独立的免费版，另外两个高级版被整合到 Office 365 套件里，而即便免费版都比 Slack 具备更多功能供用户体验，可见其重视程度。Slack 招股书里的这句话让我突然理解了它让微软如此“厚待”的原因，因为它试图利用新技术来创造资源间沟通与协作的新方式，帮助企业找到最优解，实现敏捷：“Slack is a new layer of the business technology stack that brings together people, applications, and data（Slack 是一层全新的商业技术栈，将人、应用和数据重新整合到一起）.”。于是一开始 Slack 就要打破以往企业发起任务并展开资源组织的方式——邮件，这种从上世纪七十年代诞生的工具。
Idea Generation
The most common question prospective startup founders ask is how to get ideas for startups. The second most common question is if you have any ideas for their startup. But giving founders an idea almost always doesn’t work. Having ideas is among the most important qualities for a startup founder to have—you will need to generate lots of new ideas in the course of running a startup. YC once tried an experiment of funding seemingly good founders with no ideas. I think every company in this no-idea track failed. It turns out that good founders have lots of ideas about everything, so if you want to be a founder and can’t get an idea for a company, you should probably work on getting good at idea generation first.
blog.samaltman.com/idea-genera…
Developer's Guide to Tech Strategy
This is a very high level overview of tech strategy; that is, the business of software rather than the art and science of creating software itself. It goes without saying that your coding does not have independent value; it must be applied usefully on some economic problem to have sustainable real world impact.
Tools for better thinking
Collection of thinking tools and frameworks to help you solve problems, make decisions and understand systems.
