Skip to content

2024

  • in zh
  • 1 min read

在建築領域的職業生涯發展中 - 應對複雜性並擁抱持續學習

作為技術領域中的建築師開始職業生涯是一條需要不斷努力和學習的旅程。科技的風景瞬息萬變。一名曾經的Clipper專家可能會發現他在這個領域的大量知識已經過時了。

持續學習與足智多謀的必要性

一個建築師的旅程並不是在獲得職位後就結束；這是一條由不斷學習標記的道路。保持對技術和商業進步的了解至關重要。然而，資源會波動，使得主動尋找最新的工具、新聞源和團體變得至關重要。這種對資源收集的主動態度對於保持與時俱進和在領域中保持相關性至關重要。

20分鐘法則：平衡職業生涯和個人生活

平衡這兩者的一種有效方法是"20分鐘法則"。這種技巧涉及到每天至少花20分鐘在你的職業發展上，無論是探索新概念還是深入瞭解熟悉的概念。這種做法，儘管看似簡短，卻可以大大提升建築師的技術廣度和整體職業發展。

然而，在工作、家庭和個人興趣的需求中實施這種規則可能會充滿挑戰。人們常常建議在午餐時間或下班後的時間利用這20分鐘，但這些時間經常被其他優先事項佔據。因此，建議早上起來，喝咖啡和查看郵件之後，第一件事就是實施這個規則，以確保它成為你每天日常生活的一部分。

發展個人科技雷達

忽視科技進步的危險和生活在科技泡沫中的危險。這一認識凸顯了擁有一個個人科技雷達的重要性，這是一個源自ThoughtWorks的概念。

ThoughtWorks科技雷達：個人適應的指南

由技術諮詢委員會開發的ThoughtWorks科技雷達，為評估技術提供了結構化的方法。這個每半年出一次的雷達包括工具、語言和框架、技術和平台的四個象限，並將技術分為四個環：保留、評估、試驗和採用。

對於個人使用，這些象限和環的調整可以提供在什麼上面集中，進一步研究，積極實驗，或完全擁抱的指導。這種方法有助於平衡新的、令人興奮的技術的吸引力和實際的職業考慮。

利用開放源碼的視覺化工具和社交媒體

在2016年，ThoughtWorks發布了一個幫助創建個人雷達可視化的工具。此外，像Twitter這樣的社交媒體平台可以在了解新興技術和行業趨勢方面提供無可估量的價值。

結論：熟能生巧

成為一個優秀的建築師的道路在於不斷的實踐。建築，就像任何一種技能一樣，隨著定期的練習和應用而提高。請記住，建築中沒有定性的答案——只有權衡。關鍵是持續的學習和實踐。所以，采取行動，開始今天就構建你的建築技能！

  • 3 min read

The Art of Negotiation and Leadership in Software Architecture

Harnessing Negotiation and Leadership as a Software Architect

In the complex world of software architecture, possessing strong negotiation and leadership skills is crucial. These are not innate traits but are cultivated through years of learning and real-world experiences. This blog post delves into these vital skills, offering foundational techniques for aspiring architects to embark on their journey towards mastery.

Understanding Negotiation and Facilitation in Architecture

A software architect's role involves navigating the political landscape of an enterprise, a task that requires keen negotiation skills. Every decision is subject to challenge, be it from developers, fellow architects, or stakeholders. Effective negotiation helps in balancing varied viewpoints and arriving at decisions that align with the organization's goals.

Real-World Negotiation: Balancing Cost and Availability

Take, for instance, the decision to use database clustering and federation for enhancing system availability. While technically sound, it's a costly choice. Here, the architect's negotiation skills come into play, striking a balance between availability and cost with business stakeholders.

Negotiating with Business Stakeholders

Scenario 1: Balancing Technical Realities and Stakeholder Expectations

Consider a scenario where a lead architect must negotiate with a senior vice president insisting on unrealistic system availability. The challenge lies in respectfully aligning the sponsor's expectations with technical feasibility, without coming off as condescending or dismissive.

Key Techniques in Stakeholder Negotiation
  1. Leverage Grammar and Buzzwords: Understand underlying concerns behind phrases like “zero downtime”. It reveals stakeholders' priorities.
  2. Gather Information: Before negotiating, research to understand the implications of terms like “five nines” of availability.
  3. State Things in Terms of Cost and Time: Use this as a last resort, presenting the financial and temporal implications of decisions.

Negotiating with Other Architects

In disagreements, like the choice between asynchronous messaging and REST, the key lies in demonstration over argumentation. Showcasing the effectiveness of a solution in the specific environment often resolves conflicts more efficiently than theoretical debates.

Collaborating with Developers

A successful architect collaborates with the development team, justifying decisions rather than dictating them. This approach fosters mutual respect and a collaborative spirit, essential for effective team dynamics.

The Software Architect as a Leader

Leadership in software architecture is about 50% people skills. It's not just about technical prowess but also about guiding teams with clarity, communication, and collaborative spirit.

The 4 C’s of Architecture
  1. Communication: Clear and concise communication is fundamental.
  2. Collaboration: Work alongside teams and stakeholders for joint solution crafting.
  3. Clarity and Conciseness: Avoid accidental complexity; simplicity is key.

Being Pragmatic and Visionary

Balancing pragmatic solutions with visionary thinking is vital. It's about making realistic decisions while considering future implications and technological advancements.

Leading by Example

Good architects lead not by title, but by example. They earn respect through their actions, demonstrating their commitment and expertise in real-world scenarios.

Integrating with Development Teams

An effective architect integrates with their team, balancing meeting obligations with hands-on team interaction. This involvement is crucial for mentoring, guiding, and resolving issues as they arise.

Conclusion: The Path to Effective Software Architecture Leadership

As Theodore Roosevelt aptly put it, the key to success is knowing how to get along with people. For software architects, this translates to a blend of negotiation prowess, leadership skills, and the ability to foster collaborative environments. These are the cornerstones of not just surviving but thriving in the complex landscape of software architecture.

  • in podcast
  • 2 min read

The Art of Negotiation and Leadership in Software Architecture

Hello and welcome to another episode of Continuous Improvement. I’m Victor Leung, your guide on this journey to mastering the art and science of software architecture. Today, we're diving deep into the realms of negotiation and leadership—two crucial skills for any software architect. Whether you’re just starting out or looking to hone your existing skills, this episode is packed with insights to help you navigate the complex landscape of modern software development.

As software architects, we often find ourselves at the intersection of technology and business, where every decision can impact multiple stakeholders. Effective negotiation isn't just about getting what you want; it’s about finding a balance that aligns with the organization's goals and satisfies the varied interests of all parties involved.

Let’s consider a real-world scenario. Imagine you’re deciding whether to implement database clustering and federation to boost system availability. Technically, it’s a sound choice, but it comes with high costs. Here, your negotiation skills are crucial to balance the technical benefits against the financial constraints, crafting a solution that stakeholders can agree on.

When negotiating with senior stakeholders, like a vice president demanding unrealistic system availability, the key is to align their expectations with what’s technically feasible. Use their language, understand the concerns behind terms like “zero downtime,” and prepare to discuss the implications of these requirements.

And it’s not just about talking to business executives. Negotiating with fellow architects or developers often requires a different approach. For example, when there’s a disagreement over using asynchronous messaging versus REST, demonstrating the benefits of your preferred solution can be more effective than just theoretical debate.

Now, transitioning from negotiation to leadership, remember that being a leader in the architecture space is about 50% people skills. It’s about guiding your teams not just with authority but with empathy, clarity, and a collaborative spirit.

Embrace the 4 C’s of effective architectural leadership: Communication, Collaboration, Clarity, and Conciseness. Speak clearly, work closely with your teams and stakeholders, simplify complex ideas, and always aim to remove unnecessary complexities.

A visionary yet pragmatic approach is essential. Strive to make decisions that are realistic and consider the long-term implications of your architectural choices. Lead by example—show your commitment and expertise, and integrate closely with your team to mentor, guide, and resolve issues collaboratively.

As Theodore Roosevelt said, “The key to success is knowing how to get along with people.” For software architects, this means mastering negotiation to harmonize technical and business needs, and leading in a way that inspires and uplifts your team.

Thank you for tuning in to Continuous Improvement. I hope today’s episode empowers you to step up as a leader in your field and navigate the complexities of software architecture with confidence and finesse. I’m Victor Leung, and I look forward to exploring more topics with you that help us all grow and improve. Until next time, keep negotiating, keep leading, and keep improving.

  • in zh
  • 1 min read

在軟體架構中的談判和領導藝術

利用談判和領導作為一名軟體架構師

在複雜的軟體架構世界中，擁有堅強的談判和領導技能是至關重要的。這些並非天生的特質，而是經過多年的學習和真實世界經驗所培養出來的。本博客文章深入探討這些重要技能，為有志於成為架構師的人提供基礎的技術，使他們開始掌握這些技能的旅程。

理解在架構中的談判和協調

軟體架構師的角色涉及導航企業的政治景觀，這需要敏銳的談判技巧。每一個決定都可能受到挑戰，無論是來自開發人員，其他架構師，或持分者。有效的談判有助於平衡各種觀點，並做出符合組織目標的決定。

真實世界的談判：平衡成本和可用性

例如，決定使用資料庫集群和聯邦來增強系統可用性的決定。雖然在技術上聽起來完全可行，但這是一個成本高昂的選擇。這裡，架構師的談判技巧就派上用場了，他們需要跟商業持分者達成平衡可用性和成本的協議。

與商業持分者談判

情境1：平衡技術現實與持分者期望

考慮一個場景，其中一名主架構師必須與一位堅持對系統可用性有不切實際期望的高級副總裁進行談判。挑戰在於尊重地將贊助商的期望與技術可行性對齊，而不顯得高傲或無禮。

在持分者談判中的關鍵技術
  1. 利用語法和流行詞：理解像是“零停機時間”這種語句背後的潛在關注點。這顯示了持分者的優先事項。
  2. 收集信息：在進行談判之前，蒐集研究結論以理解像是“五個九”這種包含在可用性條款中的概念的影響。
  3. 以成本和時間來說明事情：將這個方法作為最後的手段，提出決策的財務和時間影響。

與其他架構師的談判

在意見分歧中，如在異步訊息與REST之間的選擇，關鍵在於以示範優於爭論。在具體環境中展示解決方案的效果通常比理論辯論能更有效地解决衝突。

與開發人員合作

一個成功的架構師要與開發團隊合作，解釋決定，而不是強加決定。這種方法培養了相互尊重和合作的精神，對於有效的團隊動態至關重要。

軟體架構師作為一個領導者

軟體架構的領導約占人際專業技能的50%。這不僅僅是關於技術實力，也是關於以清晰，溝通和合作的精神引導團隊。

架構的4C法則
  1. 溝通：清晰和簡潔的溝通是基本的。
  2. 合作：與團隊和持分者一起工作，共同提出解決方案。
  3. 清晰和簡潔：避免意外的複雜性；簡單是關鍵。

務實和有遠見

平衡務實的解決方案與有遠見的思考是非常重要的。這關乎在考慮未來的影響和技術進步的同時，做出現實的決定。

以身作則

好的架構師不是靠頭銜領導，而是以身作則。他們透過自己的行為贏得尊重，並在實際情境中展示自己的承諾和專業知識。

與開發團隊整合

一個有效的架構師會與他的團隊整合在一起，平衡滿足會議義務與實際團隊互動之間的關係。這種參與對於指導，指導和解決問題至關重要。

結論：成為有效軟體架構領導者的道路

正如西奧多·羅斯福所說，成功的關鍵在於知道如何與人相處。對於軟體架構師來說，這意味著談判實力，領導技能，以及培養合作環境的能力的結合。這些是在軟體架構的複雜景觀中不僅生存，而且蓬勃發展的基石。

  • 3 min read

Mastering Cloud-Native Applications - A Comprehensive Guide to the 12 Factor App Manifesto

The 12 Factor App manifesto is a methodology for building software-as-a-service (SaaS) apps that are scalable, maintainable, and deployable on modern cloud platforms. Developed by engineers at Heroku, it's a set of best practices designed to enable applications to be built with portability and resiliency when deployed to the web.

Introduction to the 12 Factor App

In the early days of web development, applications were often built in a monolithic style, tightly coupled to their execution environment. This approach led to numerous issues, especially when apps needed to scale or move to different environments. The 12 Factor App methodology was created to address these challenges, emphasizing a declarative format for setup automation, clean contract with the operating system, and minimizing divergence between development and production.

The Twelve Factors

  1. Codebase: One codebase tracked in version control, many deploys. This principle advocates for a single codebase for each service which can be deployed in any environment.

  2. Dependencies: Explicitly declare and isolate dependencies. Applications should explicitly declare all dependencies, not relying on the implicit existence of system-wide packages.

  3. Config: Store configuration in the environment. This factor pushes for the separation of config from code, as configurations vary substantially across deploys while code does not.

  4. Backing Services: Treat backing services as attached resources. This means that a deploy of the app should be able to swap out a local MySQL database for a third-party service without changing the app’s code.

  5. Build, Release, Run: Strictly separate build and run stages. This factor emphasizes the need for strictly separating the build stage (where the code is converted into an executable bundle), the release stage (where the executable is combined with the config), and the run stage (where the app is actually run).

  6. Processes: Execute the app as one or more stateless processes. This principle states that the app should be executed in the stateless fashion, and any data that needs to persist should be stored in a stateful backing service, like a database.

  7. Port Binding: Export services via port binding. Apps should be completely self-contained and should not rely on runtime injection of a webserver into the execution environment to create a web-facing service.

  8. Concurrency: Scale out via the process model. This factor implies that apps should be able to scale horizontally by adding more concurrent processes.

  9. Disposability: Maximize robustness with fast startup and graceful shutdown. This principle advocates for short startup times and graceful shutdowns to maximize robustness.

  10. Dev/Prod Parity: Keep development, staging, and production as similar as possible. This factor aims to reduce the gaps between development and production to ensure continuous deployment for maximum agility.

  11. Logs: Treat logs as event streams. Applications should not concern themselves with routing or storage of their output stream. Instead, each running process writes its event stream, unbuffered, to stdout.

  12. Admin Processes: Run admin/management tasks as one-off processes. This principle states that management tasks should be run in an environment identical to the regular long-running processes of the app.

Conclusion

The 12 Factor App methodology provides a framework for building software that demonstrates key characteristics necessary for modern cloud platforms. It addresses issues of scalability, reliability, and portability, making it easier for development teams to build and manage applications effectively. As the world of web development evolves, the principles of the 12 Factor App continue to be a vital reference for building robust, scalable cloud-native applications.

  • in podcast
  • 3 min read

Mastering Cloud-Native Applications - A Comprehensive Guide to the 12 Factor App Manifesto

Welcome to Continuous Improvement, the podcast where we explore cutting-edge methodologies and best practices that enhance how we build software. I’m your host, Victor Leung, and in today’s episode, we’re unpacking a crucial methodology for anyone working in the realm of Software-as-a-Service or SaaS—The 12 Factor App. Developed by the engineers at Heroku, this set of guidelines has transformed how applications are built and deployed on modern cloud platforms.

To start, let's talk about why the 12 Factor App methodology was created. In the early days, web applications were often built as monoliths—large, single units that were tightly coupled with their environments. This created a myriad of problems, especially when these applications needed to scale or be moved to different environments.

The 12 Factor App methodology was designed to overcome these challenges. It emphasizes a declarative format for automation setup, a clean contract with the operating system, and a drive to minimize the gap between development and production. These practices ensure that applications are portable, scalable, and maintainable. Let’s break down these factors.

Factor 1: Codebase. There should be exactly one codebase for a service, with the codebase being used for many deployments. This means having a single repository that can be deployed anywhere, from the developer's local environment to the final production servers.

Factor 2: Dependencies. Your application should explicitly declare and isolate dependencies. This avoids the pitfalls of implicit dependencies that can lead to conflicts between differing environments.

Factor 3: Config. Configuration settings should be stored in the environment rather than in the code. This separation of config from code helps keep the application environment agnostic, making it easy to adjust settings without changing the codebase.

Factor 4: Backing Services. Treat all backing services as attached resources which can be attached or detached to deployments without significant changes to the code.

Factor 5: Build, Release, Run. Strictly separate the build and run stages. By doing this, applications are more stable and predictable since no changes are allowed that might affect the running application during the release phase.

Factor 6: Processes. Execute the app as one or more stateless processes. This is crucial for scalability and distribution since no user session or context is stored locally.

Factor 7: Port Binding. The application should be self-contained and not rely on runtime injection of a web server.

Factor 8: Concurrency. Scale out via the process model. Essentially, this involves starting more copies of the application to handle more load.

Factor 9: Disposability. Maximize robustness with fast startup and graceful shutdown. This improves the application’s reliability in the face of hardware/software failures.

Factor 10: Dev/Prod Parity. Keep development, staging, and production as similar as possible to avoid bugs that arise from environmental differences.

Factor 11: Logs. Treat logs as event streams. This allows for more scalable and manageable logging.

Factor 12: Admin Processes. Run administrative/management tasks as one-off processes. This ensures that these tasks are performed without affecting the running application’s environment.

The 12 Factor App is more than just a methodology; it’s a philosophy for software development and deployment. It’s about building software that is robust, manageable, and above all, adaptable to the changes and scales as needed without a complete overhaul.

Thanks for joining me on Continuous Improvement. Whether you’re building your next big SaaS or scaling an existing one, keeping these 12 factors in mind can be the difference between success and failure. I'm Victor Leung, and I’ll be back soon with more insights and strategies to help you refine your craft and improve your projects. Until next time, keep coding, keep improving, and stay cloud-savvy.

  • in zh
  • 1 min read

掌握雲原生應用程式 - 12因子應用程式宣言的全面指南

12因子應用程式宣言是一種構建軟件即服務（SaaS）應用程式的方法，這些應用程式具有可擴展性，可維護性，並且可在現代雲平台上部署。這套方法是由Heroku的工程師開發的，旨在使應用程式具有部署到web時的可攜性和彈性。

介紹12因子應用程式

在網頁開發的早期，應用程式經常以單體風格構建，與其執行環境緊密結合。這種方式導致了許多問題，尤其是當應用程式需要擴展或遷移到不同環境時。12因子應用程式的方法論就是為了解決這些挑戰，強調以聲明的方式進行設置自動化，與操作系統保持良好的合同，並使開發與生產之間的差異最小化。

十二因子

  1. 程式碼庫：一個在版本控制中追蹤的程式碼庫，許多部署。這條原則主張每個服務都應有一個程式碼庫，該程式碼庫可以在任何環境中部署。

  2. 依賴性：明確宣告並隔離依賴性。應用程式應明確宣告所有依賴性，不依賴於系統範疇內包的隱含存在。

  3. 配置：在環境中儲存配置。這個因子推動將配置與程式碼分離，因為配置在部署間變化很大，而程式碼則不是。

  4. 支援服務：將支援服務視為附加資源。這意味著應用程式的部署應能夠換出本地 MySQL 資料庫為第三方服務，而不用修改應用程式的程式碼。

  5. 建立，發佈，運行：嚴格分離建立和運行階段。這個因子強調需要嚴格分離建立階段（將程式碼轉換成可執行包的階段），發佈階段（將可執行文件與配置結合的階段）和運行階段（實際運行應用程式的階段）。

  6. 進程：作為一個或多個無狀態進程來執行應用程式。這個原則認為，應用程式應該以無狀態的方式執行，並且任何需要保留的資料都應該儲存在有狀態的支援服務，如資料庫。

  7. 端口綁定：通過端口綁定導出服務。應用程式應完全自包含，不應依賴於服務器在運行環境中的注入來創建面向web的服務。

  8. 併發：通過進程模型進行擴展。該因子意味著應用程式應能通過增加更多並發進程來實現水平擴展。

  9. 廢棄：通過快速啟動和優雅關閉來最大化魯棒性。這個原則主張縮短啟動時間並優雅地關機，以最大程度地提高魯棒性。

  10. 開發/生產同態：保持開發，暫存和生產盡可能相似。這個因子的目標是減少開發與生產之間的差距，確保連續部署以達到最大的敏捷性。

  11. 日誌：將日誌視為事件流。應用程式不應對其輸出流的路由或儲存感到憂慮。相反，每個正在運行的進程都將其事件流無緩存地寫入stdout。

  12. 管理流程：作為一次性流程運行管理/管理任務。這個原則認為，應該在與應用程式的常規長期運行進程相同的環境中運行管理任務。

結論

12因子應用程式的方法提供了一個構建軟體的框架，該軟體顯示了現代雲平台所必需的關鍵特性。它解決了可擴展性，可靠性和可攜性的問題，使開發團隊更容易有效地構建和管理應用程式。隨著網頁開發的世界不斷演進，12因子應用程式的原則繼續是構建強大、可擴展的雲原生應用程式的重要參考。

  • 2 min read

Nudges - A Gentle Push Towards Better Choices

In the world of behavioral economics, the term "nudge" has become a powerful concept in influencing the decision-making processes of individuals. Coined by Richard Thaler and Cass Sunstein in their influential book "Nudge: Improving Decisions About Health, Wealth, and Happiness," a nudge is defined as any aspect of the choice architecture that alters people’s behavior in a predictable way without forbidding any options or significantly changing their economic incentives.

Types of Nudges

  1. Default Nudges: These are based on setting a default choice which is more likely to be chosen because of inertia. For example, automatically enrolling employees in a retirement savings plan but giving them the option to opt out.

  2. Social Norm Nudges: These nudges use the power of social influence. By showing that a particular behavior is the norm, individuals are more likely to conform. An instance of this is hotels indicating that most guests reuse their towels, encouraging others to do the same.

  3. Simplification Nudges: These are based on the principle that if a choice is easier to understand, it's more likely to be chosen. For instance, simplifying the paperwork for financial aid can increase college enrollment.

  4. Salience Nudges: These nudges make certain options more prominent or visible. An example is placing healthier foods at eye level in a cafeteria to promote better eating habits.

  5. Feedback Nudges: Providing feedback about behavior can influence future decisions. For example, a monthly report on electricity usage compared to neighbors nudges people to reduce their consumption.

Examples of Nudges in Action

  1. Organ Donation: In countries where organ donation is an 'opt-out' system (default nudge), there's a higher rate of organ donors compared to countries where you have to 'opt-in'.

  2. Healthy Eating: In school cafeterias, placing fruits and vegetables at the beginning of the serving line (salience nudge) has been shown to increase their consumption among students.

  3. Financial Decisions: Apps that round up purchases to the nearest dollar and save the difference (simplification nudge) make it easier for people to save money without feeling a significant impact on their finances.

  4. Environmental Conservation: Showing a building’s energy consumption in real-time compared to other similar buildings (feedback nudge) can motivate reductions in energy use.

  5. Public Health: During the COVID-19 pandemic, social norm nudges were used by displaying signs about mask-wearing being a common practice, thereby encouraging more people to wear masks.

Conclusion

Nudges represent a subtle yet powerful way to influence human behavior positively. By understanding how different types of nudges work, policymakers, businesses, and even individuals can create an environment where making the best choice becomes the easiest option. It's a testament to the power of gentle persuasion over forceful compulsion.

  • in podcast
  • 3 min read

Nudges - A Gentle Push Towards Better Choices

Welcome back to Continuous Improvement, where we explore ideas that enhance our lives and reshape our behavior. I'm your host, Victor Leung, and today, we're diving into a fascinating concept from behavioral economics known as the "nudge." Popularized by Richard Thaler and Cass Sunstein in their book "Nudge: Improving Decisions About Health, Wealth, and Happiness," nudging has transformed how we think about influencing decision-making in subtle yet effective ways.

A nudge is essentially a feature of the environment that alters people’s behavior in a predictable way, without forbidding any options or significantly changing their economic incentives. It's about making it easier for people to make certain decisions that can benefit them and society as a whole.

Let’s break down some types of nudges that have proven particularly effective:

First up, Default Nudges. These are choices made easy simply by what's pre-selected for us. Think about a workplace that automatically enrolls its employees into a retirement savings plan, but gives them the option to opt out. This type of nudge takes advantage of our tendency to stick with the default setting, boosting positive outcomes like increased savings for retirement.

Next, we have Social Norm Nudges. These are all about the power of the crowd. When hotels tell you that most guests reuse their towels to save water, they're nudging you to do the same by highlighting what others are already doing.

Then there's Simplification Nudges. By making processes simpler, these nudges help people make better choices more easily. A great example is streamlining the paperwork for financial aid to help more students enroll in college.

Salience Nudges make the preferred choices more visible. For instance, placing healthier foods at eye level in a cafeteria can nudge people towards better eating habits without removing the less healthy options.

And Feedback Nudges involve giving people information about their behavior to encourage smarter decisions in the future. A monthly report showing your electricity usage compared to your neighbors can motivate you to cut back on energy consumption.

Let's look at nudges in action. From organ donation to healthy eating in schools, financial decisions, and even during the COVID-19 pandemic with mask-wearing—nudges have been applied in various areas to encourage beneficial behaviors subtly.

In organ donation, countries with an 'opt-out' system see higher donor rates than those requiring an explicit 'opt-in'. Simply by changing the default, these countries have significantly increased the availability of organs for lifesaving transplants.

In schools, placing fruits and vegetables at the start of the line nudges students towards making healthier choices. Financial apps that round up your purchases to the nearest dollar and save the difference are simplifying the act of saving money, making it feel less like a sacrifice and more like a seamless part of everyday spending.

Nudges show us that the best choice doesn't have to be the hard choice. By designing our environments to promote better decisions effortlessly, we can all benefit from the subtle powers of influence that nudges provide.

That's all for today's episode of Continuous Improvement. I hope you've gained insights into how simple changes in our choice architecture can lead to significant improvements in our behavior and decision-making. I'm Victor Leung, and I look forward to nudging you towards more fascinating topics in our next episode. Until then, keep thinking, keep improving, and let's all make the easy choices the good choices.

  • in zh
  • 1 min read

引導 - 朝著更好的選擇輕輕推進

在行為經濟學的世界中，"引導"一詞已成為影響個體決策過程的一種有力概念。這一詞由Richard Thaler和Cass Sunstein在他們的影響力極大的書籍"引導:Nudge: Improving Decisions About Health, Wealth, and Happiness"The book"提出，引導被定義為改變人們行為的任何選擇架構的方面，這種改變是可預見的，而不讓人們禁止任何選項或大幅改變他們的經濟激勵。

各類型的引導

  1. 預設引導: 這些基於設置一個預設選擇的引導，由於慣性，這個選擇更有可能被選擇。例如，將員工自動納入退休儲蓄計劃，但給予他們退出的選擇。

  2. 社會規範引導: 這些引導利用社會影響的力量。通過顯示某種行為是常規，個人更有可能遵從。一個例子是，酒店指出大多數客人重複使用他們的毛巾，鼓勵其他人也這樣做。

  3. 簡化引導: 這些基於一個原則，即如果一個選擇更易於理解，則更有可能被選擇。例如，簡化資助金的申請表格可以增加大學報名率。

  4. 顯著引導: 這些引導使某些選項更為突出或可見。一個例子是在飯堂將更健康的食物放在視線高度以鼓勵更好的飲食習慣。

  5. 反饋引導: 提供有關行為的反饋可以影響未來的決策。例如，與鄰居相比，每月對電力使用量的報告引導人們減少他們的消耗。

引導在行動中的範例

  1. 器官捐贈: 在將器官捐贈設定為'退出系統' (預設引導)的國家，與需要'選擇加入'的國家相比，有更高的器官捐贈者比例。

  2. 健康飲食: 在學校飯堂，將水果和蔬菜放在供應線的開頭 (顯著引導)被證實可以增加學生的消耗。

  3. 財務決策: 將消費額進位到最接近的整數並儲存差額 (簡化引導)的應用軟件，讓人們在不感到財務壓力的情況下更容易儲蓄。

  4. 環境保護: 將一個建築物的能源消耗與其他類似建築物的實時比較顯示出來 (反饋引導)可以激勵減少能源使用。

  5. 公眾衛生: 在COVID-19大流行期間，社會規範引導被用來展示佩戴口罩是一種常見的做法的標示，從而鼓勵更多的人佩戴口罩。

結論

引導代表了一種微妙而又強大的影響人類行為的方式。通過理解各種引導的工作方式，政策制定者、商業和個人可以創建一個環境，使得做出最好的選擇成為最容易的選項。這證明了溫和的說服力超越了強制的強迫性。