So much knowledge not being applied Most organisations have a lot of documents and data floating around that hardly ever gets revisited or used. They all have research, reading, and relevant information collecting dust. Stuff that should be informing the decisions and strategies of the company. Some of it sits unread in a knowledge base or a wiki. Some of it lies in the drives of individual employees who don’t have a way to share it productively. So much knowledge not being applied! Except that’s not how we work as human beings. If you haven’t read it, experienced it, and contextualised it, then it isn’t knowledge to you. Knowledge is a quality that people possess, not documents, and the only way to transfer it from one place to another is for people at both ends to apply themselves and make it their own. Baldur Bjarnason, On online collaboration and our obligations as makers of software knowledgedocumentationwork
Dependence is more profitable than education A customer who pays—in advance—for service contracts is a more stable income source than a customer who has fully mastered a product's use. Customer dependence is more profitable than customer education. What I find truly baffling are manuals—hundreds of pages long—that accompany software applications, programming languages, and operating systems. Unmistakably, they signal both a contorted design that lacks clear concepts and an intent to hook customers. Niklaus Wirth, A Plea for Lean Software The design concept documentation
Figma's Engineering Values: Craftsmanship An Article www.figma.com Craftsmanship is about thoughtfulness and care in the work we do. It means being deliberate about what we build and how possible it will be to maintain and extend in the future. A solution that will require revisiting in a month — because it’s not scaling, because it has a ton of bugs, because it doesn’t support all the use cases it needs to — is not useful to us and ultimately will generate pain for our users. What we trade off by living this value is (sometimes) day-to-day speed. It’s easy to imagine an engineering team that emphasizes moving fast over keeping things stable and bug-free -- like a team building a product that isn’t responsible for important user data and doesn’t support anyone’s livelihood. But given the role the Figma product plays in the lives of our users, we feel it’s worth it to ensure we hold a high quality bar for them. And in the long run, being thoughtful about how we build often reduces the complexity of ongoing development and new features regardless. craftsoftwarequality