跟新的鴨鴨聊天： http://ducky2.heron.me/

前言

2017年冬天，我寫了第一代的諮商機器鴨Ducky發表在網路上，至今已有逾千人跟Ducky聊過天，當時海苔熊分享在Facebook上且有百人轉貼，直到不久前Ducky因為缺乏維護壞掉之後，還是有不少人持續跟他聊天著。

這幾年之間，我搜集到許多反饋，與幾位相關的專業人士討論之後，我們開發了第二代Ducky，目前發表在LINE上給大家試用：http://ducky2.heron.me/。

WHY — 為什麼要做第二代Ducky？

兩個主要原因讓我們開發第二代Ducky：

1. 心理健康不易注意：當一個人心理狀況不好且持續很久時，容易演變成更嚴重的心理疾病，然而我們平時容易忽略去追蹤自己的心理狀態。我們會定期做健康檢查，也該定期追蹤自己的心理健康（可收聽軟來如此EP9瞭解更多）。
2. 缺少能傾訴的空間：延續第一代最重要的功能，我們往往需要一個地方可以把自己的心情傾訴出來，重點不在於對方回答什麼，而是自己把這些情緒、事情、想法等等講出來的過程。

WHAT — 第二代Ducky可以做什麼？

對應上述兩個原因，第二代Ducky具有兩個功能（往後可能持續增加）：

1. 定期心理健康檢查：第二代Ducky每週會關心你這週過得好不好，你只需要在「🙂、😐、🙁」選項中點一個回覆，他就會記得，接著在往後的日子中關心你、提供對你可能有幫助的訊息。而在你回覆之後，他會分享一張梗圖或鼓勵的圖片感謝你。
2. 樹洞：如同第一代Ducky，他會回覆你對他說的話，雖然沒能給你很有高智慧的話，但他總是能一直聽你說，且有些字是特別敏感的小彩蛋，你有找到嗎？

HOW — 第二代Ducky要怎麼用呢？

在LINE上面加他，直接跟他聊天就可以囉！連結：http://ducky2.heron.me/
也請幫忙分享連結給你身邊可能需要的朋友。

第二代諮商機器鴨 — Ducky 2 was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here: https://wordle-eldrow.herokuapp.com/

While enjoying playing Wordle for a couple days, I wanted some dictionary lookup tools that could help me when I’m stuck. I thought about building a Wordle Solver but didn’t expect it actually happens until yesterday.

This blog briefly documents how I built a Wordle Solver less than 1 day. See code at https://github.com/heronyang/eldrow.

Design Goals

The solver should work (of curse) and should be built fast (otherwise I will lose interest and stop investing).

Process

As I was unsure how much time to invest into this solver, I implemented it incrementally — so I can still takeaway something if I stopped in the middle.

Step 1 — The Solver Brain

Interface
I started to code the main logic of solving a Wordle with a bad interface that only programmers can use it.

Language
I picked Dart as I can reuse it later if want to continue to build a Flutter app. Writing Dart takes much more time as I am new to Dart, but this is the additional cost I am willing to pay.

Algorithm
The main solving algorithm was straightforward — it looks up all valid words, applies the game rules to remove illegal words, and prints out the legal words. I didn’t spend time to optimize the algorithm as it’s O(N*M) where N~=100K and M=5 which is pretty easy for today’s devices.

Step 2 — The App (Flutter) Interface

As I found out the solver works fine, I want to make it accessible on my phone so I can use it when I’m out playing Wordle.

User Interface (UI)

In this step, I focus on building the UI for the solver and doesn’t care about the solver brain at all. The UI should be designed with the user in mind, not the solver — so I designed it to look similar to today’s Wordle game for people easy to fill in letters.

Users need to put the green and yellow letters in the correct column as the column means its position in the word, but grey letters can be out-of-order.

Bridging UI and Brain
Once we have the UI and solver brain (a solver with Dart interface), we can bridge them together. That is, within the callback function of clicking on the submit button, we prepare the parameters for the solver brain, calls the solver brain to solve, and parse the result back to the UI.

Here’s an example of how ELDROW solves a real Wordle Game:

Deploy
Finally, I built the code into a web app and deploy it onto Heroku. The commands are:

See the deployed app at https://wordle-eldrow.herokuapp.com.

Step 3 — Continuous Update

Okay, I actually haven’t done this step yet — this is a future step I will continue if its benefit outweighs the cost.

This step includes:

• Sort the answer words with their popularity. (Show common words on top.)
• Maintain an issue list which contains user feedbacks, bugs, wanted features, etc.
• Consider fancy add-on features — e.g. the solver reads a screenshot instead of you typing in the letters.
• etc.

Summary

The MVC concept affects the flow of how I built ELDROW (although this term didn’t actually appear in my mind). I started with the model (M) so I can still have a solver with poor interface to use if I gave up in the middle. Then, I focus on the view (V) where I only think about the user. Lastly, I added the controller (C) to connect the model and the view.

Building an app quickly is fun and fulfilling :)

Follow me on Facebook.

ELDROW — The Wordle Solver was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I summarized Radical Candor into the following mind map for future me:

The Get-Stuff-Done Wheel is as below:

And, the long version of my reading note is as below.

Follow me on Facebook.

Radical Candor — Book Reading Note was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summary

Wanting a wrong thing — miswanting — such as job, money, awesome stuff, etc, is the reason of not being happy. Annoying features of our brain caused miswanting include bad intuitions, can’t think in absolutes, and being used to stuff.

Two ways of bringing happiness are:

• Intentionally strategy: thwart the adaption and reset the reference point of comparison.
• Better wanting: we should want these things instead: kindness, social connection, time affluence, mind control (e.g. meditation), and healthy practice (e.g. sleep and exercise).

To act, we intentionally practice: signature strength (apply your strengths), savoring, gratitude, kindness, social connection, exercise, sleep, and meditation. Last, investing in experience other than stuffs brings happiness.

Takeaway

After taking the course, I finally understand there’s a misconnection between “what I expect to make me happy” and “what actually makes me happy”. This is a question I’ve been measuring and rethinking over the past few months and the course (and this post) answers it nicely.

Follow me on Facebook.

The Science of Well-Being (Happiness) was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

小記：我喜歡的寫實攝影似乎也是一種正念練習，因為它專注於觀察眼前事物、保持客觀態度。

認知行為治療 (CBT) was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

不論你自己是一個寫程式的人，或者是平時跟程序員合作的人，以上的故事是不是聽起來很熟悉？「程序員都是樂觀主義（All programmers are optimists）」這句話源自於近半個世紀前出版的軟體書：人月神話（The Mythical Man-Month），而至今，每日開發軟體的我總是會想起，也深深影響我評估開發時程的方式。

什麼意思？

程序員在評估完成某一軟體功能時，容易給出一個最樂觀的理想時程，而實際上卻往往花出數倍多的時間。由於程序員給予的時間比最終實際的情況短太多了，於是我們說程序員都是樂觀主義者，仿佛是一種刻意的偏見。

為什麼？

程序員習慣用「順順地會需要花多久時間把程式打出來」來評斷所需的開發時間，於是忽略掉兩件事實：寫程式只是軟體開發的一小部分、程式開發充滿不確定性。

寫程式只是一小部分

健康的程式開發流程包含：設計、寫程式、單元測試與整合測試。人月神話作者認為的比例如下：

• 1/3 設計 (Design)
• 1/6 寫程式 (Coding)
• 1/4 單元測試 (Component Testing)
• 1/3 系統整合測試 (System Testing)

也就是，設計清楚之後，寫程式的時間其實相對很少的，只有六分之一，且超過一半的時間在測試新加入的功能。

程式開發充滿不確定性

程式開發是充滿不確定性的，大多時候都不會走在一個「最理想的情況」上。原因是因為程式開發是一個創作過程，前無古人，沒有人做過一樣的事情來保證沒有問題，於是，意外總是在發生，例如：使用套件X之後出現Error卻查不到原因、函式庫Y中竟然不支援我想要的用法Z、等等。每一件意外都會耗掉非常非常多的時間來解決，如一天至數週。

那怎麼辦？

不論你自己是程序員，或者你必須跟程序員合作，可以試試以下方式來預估更準確的軟體開發時程。

意識實際值與預估值

有意識（Be Conscious）於實際值和預估值之間的誤差是解決問題的起點。你可以試著看過去（自己或別人）評估過的開發時間與實際所花時間，然後問：

• 實際上所花的時間與當初預估的差多少？
• 這個差別是因為時間花在什麼地方？
• 是否有出現「意外（Surprise）」所以花了異常多的時間？
• 是否在預估與實際上花足夠的「測試」時間？

累績經驗

透過有意識地練習如上述，加上單純的經驗累積，你的預估值應該會離實際值較為相近。記得持續透過新觀察的資料點（實際值與預估值的落差）來修正自己的評估能力。

經驗較少的程序員往往會讓自己死命地拼一個曾答應過的「馬上就寫好」，而經驗多的工程師則能穩穩地在差不多預估的時間上交差。

明白軟體開發流程

明白軟體開發流程包含反覆修改的設計與大量的測試，「寫了可以動了」與「寫好、測試好、可以上架」的差別如天與地。程序員自己、與程序員合作的設計師或PM等等、還有程序員的主管都應有一樣的了解，且對於「寫好」有相同的定義。如此一來，程序員不用讓自己埋頭趕交差、團隊能準時地完成目標，最重要的是：寫出來的軟體是經過妥當測試的，所以用起來是穩定且能長久地成長。

結語

「程序員都是樂觀主義者」不是偏見，而是警語，它提醒我們時程評估上常犯的錯。每一個程序員都有一個預估落差比例 D，定義為實際所花時間除以預估所花時間；我們要時時觀察身邊程序員與自己的 D、不斷地修正讓它接近1。

Follow Heron’s Blog on Facebook.

程序員都是樂觀主義者 was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Definition

Command Pattern encapsulate all information needed to perform an action into a single method. Different implements can override the method differently and the callers are unaware of the implementations.

Code

Command is an interface that exposes Execute(), implemented by AttackCommand and DefenseCommand. Game is the caller of different Command implementations and is unaware how each command is handled as all of them expose the same interface. As a result, Game can easily map different buttons to execute different commands.

command.h

attack_command.h

DefenseCommand is similar to AttackCommand so I am skipping it here.

game.h

game.cc

main.cc

Note

I noticed two properties about Command Pattern:

• “Commands are an object-oriented replacement for callbacks.” With Command Pattern, we can implement a flow that triggers a method — say Execute() - when a target event happens. Execute() then plays the same role as callbacks.
• Command Pattern enables us to ‘undo’ an action. To implement ‘undo’, (1) Other than Execute(), each command object should also implement Undo() which does the action to undo an Execute(), then (2) We push the executed Command objects into a stack. When the caller wants to ‘undo’, we pop one Command object from the stack and call its Undo().

Full Code

heronyang/design-pattern

Reference

• https://en.wikipedia.org/wiki/Command_pattern
• https://gameprogrammingpatterns.com/command.html

Follow me on Facebook.

[Design Pattern in C++] Command Pattern was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Definition

Chain of Responsibility pattern passes a request into a chain of objects — each object processes the request and decides whether to pass to the next object.

Code

Logger is an abstract class implemented by ConsoleLogger, FileLogger, and EmailLogger. Logger provides AddNext() to chain another Logger. When the caller calls Log(), the logger writes log and asks the next logger does the same if needed.

logger.h

logger.cc

console_logger.h

console_logger.cc

Note that FileLogger and EmailLogger are similar to ConsoleLogger so I skipped them in this post.

main.cc

Full Code

heronyang/design-pattern

Reference

• https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
• https://www.geeksforgeeks.org/chain-responsibility-design-pattern/

Follow me on Facebook.

[Design Pattern in C++] Chain of Responsibility was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Important Sentences

• HRT (important): — Humility: You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement. Respect: You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments. Trust: You believe others are competent and will do the right thing, and you’re okay with letting them drive when appropriate.
• Give people: “autonomy”, “mastery”, and “purpose”.
• “Track happiness” — ask “what do you need?”
• “Failure is an option.” — If you’re not failing now and then, you’re not being innovative enough or taking enough risks.
• The more you are open to influence, the more you are able to influence; the more vulnerable you are, the stronger you appear.
• Even if you’re great at writing code, there’s still an upper limit to the amount of code you can write. Seek to replace yourself.
• “Do the right thing, wait to get fired.” (Chade-Meng Tan, Googler) If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.
• At some point, you need to decide when it’s time to cut your losses and move on.

More Sentences

• Mission: more time creating and less time fighting — by improving their ability to collaborate with other people.
• ‘Hide my code’ is caused by insecurity — people are afraid of others seeing and judging their work in progress. Hiding is considered harmful — how do you even know if you’re on the right track?
• ‘Bus factor’ is the number of people that need to get hit by a bus before your project is completely doomed.
• Linus’s real achievement was to lead these people and coordinate their work.
• Working alone is inherently riskier than working with others.
• It’s not about tracking or manipulating people; it’s about creating relationships to get things done, and relationships always outlast projects.
• Nobody wants to work with someone who consistently behaves like he’s the most important person in the room.
• Rather than worrying about whether you’re personally awesome, try to build a sense of team accomplishment and group pride.
• Once you reach a local maximum on your team, you stop learning. And when you stop learning, you get bored.
• If you don’t put effort into building and maintaining your culture, your team will eventually be overtaken by strong personalities that cultivate their culture in your team. If you build a strongly defined one, it will become self-selecting.
• As your project progresses, the mission statement keeps things on track.
• Try to schedule the meeting near other interrupt points in your day.
• Traditional managers worry about how to get things done, while leaders worry about what things get done .. (and trust their team to figure out how to do it.)
• “A people hire other A people; B people hire C people.”
• Leader is always on stage.
• In many cases, knowing the right person is more valuable than knowing the right answer.
• One of the hardest things to do as a team leader is to watch a more junior-level team member spend three hours working on something you know you can knock out in 20 minutes.
• Being sensitive to personal situations that your team members are going through can give you a lot of insight into why they may be more or less productive at any given time.
• Let your team know when they’re doing well.
• Focus on the long term: Do you truly believe the project will still benefit in the long run? Do you believe the conflict will ultimately resolve itself in a useful way?
• When you fail, take responsibility, don’t seek to assign blame, and document what happened and what you can do to avoid that same failure again.
• Bad manager sees your existence solely as a means to get herself promoted, and she doesn’t care about your career, much less your team’s happiness.
• Is your manager serving you? Or are you serving your manager? It should always be the former.
• You need to try to ensure that both your manager and the people outside your team are not only aware of what you’re doing, but are aware that you’re doing it well.
• Avoid promising things that you can’t deliver, even if it means saying “no” more often than you’d like.
• After years of trial and error, we’ve found that shorter emails are even more likely to get a response.
• There’s probably nothing else you can do. Don’t be a victim. Get the heck out of there.
• You can’t ignore marketing, but you can actively cooperate with marketing.
• “Focus on the user, and all else will follow.”
• Measure usage, not users.

My Thoughts

I like the book focuses on HRT (Humility, Respect, Trust) as the key factors in collaborations. The book also points out things that are easily be missed out, e.g. always track happiness. I am afraid that I will forget important things learned from this book over time, so I put them into this post for myself and the future me.

Follow me up on Facebook: fb.com/blog.heron.me.

Debugging Teams was originally published in Heron’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.