I've been telling everyone to avoid Node.js for more than 3 years because I have suffered hard-to-impossible issues when using it in large-scale real-world systems. Issues are included

1. Head-of-line (HOL) blocking — it is a performance issue where one bad request or task in a queue blocks all others behind it. This is because the nature of Node.js is that JS code execution is single-threaded. Cluster mode helps a bit but it still blocks if one bad request hits a single process in a cluster.
2. Losing error stack trace context in async task — when an error happens in async context deep down in the library, it's very hard to trace back to the application layer where it starts.

I recommend using Node.js if you really need to, for example, you have to develop a web application using React, Vue, Next.js, NuxtJS, etc.

However, I've found a way to mitigate the Head-of-line blocking issue which solves the biggest pain of mine.

Head of line blocking causes unpredictable performance

Imagine there's a single Nodejs process running to serve API requests. The API endpoint queries data from the database, loops it, processes it, and returns the response. One of the users has 100,000 rows returned from the database. JS code takes around 10s to process this single request, blocking other users who have only a few rows. If we observe each API response time, all requests blocked by the bad one will have at least 10s of latency — equal to the time it takes to process that bad request.

We have many ways to mitigate this issue, for instance, doing jobs in the background, limit amount of rows returned, etc. However, if you really need to process a request that has unpredictable data size, and wants to keep the application flow the same, you could use my technique.

Cooperative scheduling

Create yieldJs function as below.

async function yieldJs() {
    return new Promise((resolve) => setImmediate(resolve))
}

Then in the tight loop, you can put this function in the middle to yield JS execution back to Node.js event loop.

async function handleRequest(req, res) {
    const rows = ... query database ...
    for (const r of rows) {
        ... process the row ...
        await yieldJs()
    }
    ... return response ...
}

What happens here is when await yieldJs() is executed, Node.js will pause the execution of this function, process something else, and then for the next event loop cycle, it will resume the execution.

I've experimented with 2 other functions: setTimeout and process.nextTick.

For setTimeout, this function has a higher overhead because of the timer. This makes JS code to be able to utilize only 15-20% of CPU.

For process.nextTick, this function is a microtask and it keeps executing the callback before everything else which still suffers from head-of-line blocking issues.

Lastly, setImmediate can utilize 80-85% of CPU in a tight loop scenario which I think is acceptable.

Final words

Even though we have a technique to mitigate head-of-line blocking, however, I still feel that Node.js has many issues preventing us from developing a maintainable and predictable performance of production web applications. Also please avoid thread-per-request language/framework for IO intensive. I recommend using Golang instead or Rust or Zig if you have experience.

เริ่มต้นจากการเป็น start-up พวกเค้าเขียน code เร็วมาก แทบไม่มี process อะไรเลย เขียนเสร็จสามารถ push code และ deploy production ได้ทันที เค้ามีลูกค้าจำนวนหนึ่ง ลูกค้าสามารถ request feature กับทีมได้โดยตรง ภายใน 3-4 วันลูกค้าก็ได้ใช้งาน feature ที่ต้องการ

เวลาผ่านไป พวกเค้าเริ่มมีลูกค้ามากขึ้นเนื่องจากมี feature ที่หลากหลาย ตอบโจทย์ แต่ระบบเริ่มซับซ้อน มันเริ่มแสดงปัญหามากขึ้น ระบบทำงานช้า มี bug และเมื่อ release ของใหม่หรือ bug fix ก็มักจะ break feature เดิม นอกจากนั้น feature request ก็ใช้เวลาหลายสัปดาห์หรือหลายเดือนกว่าจะทำสำเร็จ นั่นยิ่งทำให้ลูกค้าเก่าเริ่มไม่พอใจ แต่ก็ยังมีลูกค้าใหม่เข้ามาเรื่อยๆ

ทีมทำงานใต้ความกดดันที่สูงมาก พวกเค้านึกเสียใจว่าควรจะออกแบบระบบให้ดีตั้งแต่แรกเพื่อป้องกันไม่ให้เกิดปัญหานี้อีก พวกเค้าหาคนเก่งที่มีประสบการณ์เข้ามาเพิ่ม หา Architect ที่จะช่วยบอกพวกเค้าได้ว่าจะต้องทำอย่างไรถึงจะไม่มีปัญหาซ้ำแบบเดิม พวกเค้าเพิ่ม process มา control ในหลายจุดเพื่อป้องกันไม่ให้เกิดปัญหากับ feature ของลูกค้า การทำงานต้องมี document มีการ review และ approve แต่นั่นยิ่งทำให้ทีมงานต้องใช้เวลามากยิ่งขึ้นกว่าจะ release feature ให้ลูกค้าได้

...สุดท้ายก็สายเกินไป พวกเค้าโดนบริษัทรุ่นใหม่ที่ทำงานเร็วกว่าแซงไปอย่างง่ายดาย ลูกค้าเริ่มย้ายออกไปทีละน้อย แม้ว่าจะมีทีมงานช่วยขาย แต่ก็ถูกเปรียบเทียบและพ่ายแพ้โดยง่าย

บริษัท B...

พวกเค้าเป็นกลุ่มคนที่มีประสบการณ์ พวกเค้าทำ product แบบเดียวกับบริษัท A แต่พวกเค้าเลือกที่จะเริ่มออกแบบให้ระบบมีความยืดหยุ่นสูงตั้งแต่ต้น พวกเค้าเชื่อมั่นในประสบการณ์ที่มีในอุตสาหกรรมนี้ พวกเค้าใช้เวลาไปเกือบ 1 ปีในการ design และพัฒนาระบบที่พวกเค้าคิดว่าดีที่สุด ยืดหยุ่นที่สุดและสามารถตอบโจทย์ลูกค้าได้ แต่ในระหว่าง 1 ปีนั้น บริษัท A ปล่อย feature ต่างๆ มากมายที่ดูเหมือนไม่ผ่านการออกแบบมาเลย

หลังจากที่เปิดตัวอย่างยิ่งใหญ่ พวกเค้าพบว่าระบบที่ออกมาแบบไม่ตรงกับสิ่งที่ลูกค้าต้องการซะทีเดียว อย่างไรก็ตามพวกเค้าเริ่มมีลูกค้าบ้าง ลูกค้าเริ่ม request feature เข้ามาให้แก้ไข แต่ระบบของเค้าก็ยังมีความยืดหยุ่น ปรับแก้ได้รวดเร็วในเวลาไม่กี่วัน

แต่แล้วเมื่อโลกธุรกิจเริ่มเปลี่ยน มีโรคระบาด มีเทคโนโลยีใหม่เกิดขึ้นก็เริ่มมีลูกค้าขอ feature ที่ทำยากมากๆ และต้องแก้ไขอย่างยากลำบาก พวกเค้าต้องเลือกระหว่างปฏิเสธลูกค้าหรือเลือกที่จะปรับโครงสร้างระบบครั้งใหญ่อีกครั้ง เพราะถ้าหากพวกเค้าไม่แก้ไขโครงสร้างระบบ พวกเค้ามองเห็นแล้วว่าบริษัทน่าจะลงเอยเช่นเดียวกับบริษัท A

...แต่ในระหว่างที่พวกเค้ากำลังวางแผน ประเมินความเสี่ยง ออกแบบและถกเถียงกันมาหลายเดือน ก็มีบริษัทรุ่นใหม่ที่ทำ product ออกมาสู้กับพวกเค้าและตรงกับสถานการณ์ของโลกที่เปลี่ยนไป ลูกค้าก็เริ่มย้ายออกจนสุดท้ายพวกเค้าก็อยู่ไม่ได้

บริษัท C...

พวกเค้าเป็นกลุ่มคนที่มีประสบการณ์และทำ product คล้ายกับ 2 บริษัทก่อนหน้า พวกเค้ารู้ว่าลูกค้ามีความต้องการที่หลากหลายและเปลี่ยนแปลงตลอดเวลา พวกเค้ารู้ว่าความเร็วเป็นของปีศาจ แต่พวกเค้าก็ฉลาดและระวังไม่ให้ตัวเองมีจุดจบเหมือนบริษัท A

พวกเค้าเลือกที่จะเขียน code ในระดับที่ “พอรับได้” มี process น้อยที่สุด แทบไม่มีเอกสารอะไรเลยถ้าไม่จำเป็นจริงๆ พวกเค้า design ผ่านการคุยกันสั้นๆ แล้วไปลองทำ พวกเค้าสามารถ push code และ deploy production ได้ทันทีเพื่อให้ลูกค้าได้ทดลองใช้และเก็บ feedback มาปรับปรุงเพิ่ม รอบการ release feature ของพวกเค้าคือหลักวัน ไม่ใช่หลักสัปดาห์, เดือน, หรือไตรมาส

พวกเค้าสามารถออก feature สู้กับบริษัท A ได้อย่างทันเวลา ลูกค้าให้ความสนใจกับ product ของพวกเค้าเป็นอย่างมาก พวกเค้าสามารถรักษาความเร็วแบบนี้ได้อย่างดี ถึงแม้เมื่อเวลาผ่านไป ระบบมีความซับซ้อนมากขึ้น มีลูกค้ามากขึ้น พวกเค้าปล่อย feature ช้ากว่าเล็กน้อยเมื่อเทียบกับบริษัทขนาดเล็ก แต่ในภาพรวมก็ยังเร็วกว่าคู่แข่งที่เป็นบริษัทขนาดใหญ่

...สุดท้ายพวกเค้าก็เป็นผู้นำอันดับ 1 ในตลาด ทุกคนต่างสงสัยว่าพวกเค้าทำได้อย่างไร

Wartime mindset

ผมอ่านหนังสือเล่มหนึ่งที่พูดถึงเรื่องนี้ เค้าเปรียบเทียบการสร้างสะพานสำหรับประชาชน vs สะพานสำหรับสงครามให้เข้าใจว่า การสร้างสะพานสำหรับประชาชนมักจะใช้เวลาหลายปีในการสร้างเนื่องจากเป้าหมายคือสะพานที่มีอายุใช้งานยาวนานที่สุด แต่เมื่อเทียบกับสะพานสำหรับสงคราม ถึงแม้ว่าจะต้องให้รถถังขับผ่านซึ่งมีน้ำหนักบรรทุกมากกว่าสะพานสำหรับประชาชน แต่เป้าหมายการออกแบบของมันไม่ใช่อายุยาวนาน แต่เป็นความเร็วในการสร้างโดยยังต้องรองรับน้ำหนักของรถถังได้ มันอาจจะสามารถสร้างเสร็จได้ในเวลา 5-10 วันและถูกใช้งานแค่ 1-3 ปีแล้วเลิกใช้ไป ไม่ใช่ 50-100 ปี ดังนั้น ทั้งแนวคิด วัสดุ รูปทรง การออกแบบ กระบวนการทำงาน ทั้ง 2 แบบมีความแตกต่างกันโดยสิ้นเชิง

การออกแบบและพัฒนา software ก็จะต้องเลือก technology ที่ทำให้เราสามารถ release software ได้ง่ายและเร็วด้วยเช่นกัน ลองนึกถึงการ update feature บน web application ผ่าน cloud server vs การส่ง CD/DVD ให้ลูกค้าเอาโปรแกรมไป install ในเครื่อง laptop เอง ทั้ง 2 วิธีใช้เวลาในการ release ต่างกันหลายเท่าตัว

อย่างไรก็ตามในขณะสงคราม เวลาเป็นเรื่องสำคัญมาก แต่คุณภาพก็จำเป็นเพราะหากสะพานไม่สามารถทำหน้าที่ของมันได้ เราก็แพ้สงครามได้เช่นเดียวกัน

Post hoc design

การที่เราจะทำได้อย่างบริษัท C นั้นไม่ใช่การไม่ออกแบบอะไรเลย แต่มันคือการออกแบบภายหลัง (Post hoc design)

เรามักเสียเวลาประชุมว่าจะใช้ technology อะไร จะทำบน architecture อะไร จะใช้ pattern ไหนในการเขียน code และยังรวมถึงการ discuss ว่า UI/UX จะเป็นอย่างไร จะมีกี่ปุ่ม จะใช้สีอะไร จะเลือก wording ไหน สิ่งเหล่านี้เป็นสิ่งจำเป็นแต่ยังไม่สำคัญจนกว่าเราจะปล่อย product/feature ให้ลูกค้าใช้งานและคอย observe ว่ามันตอบโจทย์หรือไม่

เราจะไม่เสียเวลาถกเถียงกันเป็นสัปดาห์หรือเป็นเดือนเพื่อหาว่าอะไรจะตรงใจลูกค้า หรือเพื่อวางแผนเผื่อสำหรับ feature ที่อาจจะทำในอีกครึ่งปีถัดไป แต่เราจะทำงานใกล้ชิดกับลูกค้าทุกวัน ทำตามที่ลูกค้าขอเท่านั้น และให้ลูกค้าเป็นคนบอกว่าพวกเค้าต้องการอะไรหลังจากที่พวกเค้าได้ทดลองใช้งาน feature ในแต่ละ release ของเรา

ดังนั้นในช่วงแรกของ new product หรือ new feature ทุกๆ วันมีความสำคัญ ดังนั้นทีมจะต้องเลือก “ความเร็ว” ในการปล่อย feature ไม่ใช่ “ความยั่งยืน” เพื่อให้เราค้นหา “feature-market fit” ได้เร็วที่สุด อย่างไรก็ตามทีมยังต้องคงความสามารถทั้งหมดของ software ไว้ให้ได้ ระบบห้ามพัง ห้ามทำให้ feature เดิมมีปัญหา

หลังจาก feature เริ่มนิ่ง เริ่มอยู่ตัว เราจำเป็นจะต้อง “แบ่งเวลาทันที” เพื่อกลับมาทำให้มันมี “ความยั่งยืน” แต่ห้าม “ทำเผื่อ” โดยเด็ดขาด ในช่วงเวลานี้มีโอกาสน้อยมากๆ ที่จะมี requirement เปลี่ยนไปโดยสิ้นเชิง มันจึงเหมาะมากที่จะมาตามเก็บเช็ดล้าง เพื่อให้ทีมงานใช้แรง maintain น้อยที่สุด ...ถ้าหากไม่แบ่งเวลามาสุดท้ายก็อาจจะลงเอยแบบเดียวกับบริษัท A

การทำ post hoc design & development ให้ยั่งยืนไม่ใช่การเปลี่ยนภาษา programming เปลี่ยน database หรือเปลี่ยน architecture ใหม่ทั้งหมดใหม่ แต่เป็นเพียงการ clean up ความเละเทะที่เราได้ทำไปในช่วงแรกและ enhance ระบบเพื่อให้เราทำ feature ถัดไปของลูกค้าได้ด้วยความเร็วเท่าเดิม (ถ้าไม่มี feature ถัดไปก็ยังไม่ต้อง enhance)

Reversible vs Irreversible decision

การเน้นความเร็วไม่ใช่การไม่ออกแบบอะไรเลยในตอนต้น ควรระวังการตัดสินใจที่ย้อนไปแก้ไขไม่ได้หรือแก้ไขยากมากๆ

ยกตัวอย่างเช่น เราทำ mobile application ให้ลูกค้าใช้งานโดยให้ mobile application เชื่อมต่อกับฐานข้อมูลบน server โดยตรง ถึงแม้ว่าเราสามารถใช้ mobile developer 1 คนทำ feature เชื่อมฐานข้อมูลและปล่อย feature ได้เร็วในครั้งแรก แต่การแก้ไข feature ในครั้งถัดมานั้นยากมากๆ ทำให้ feature เดิมพัง เพราะไม่สามารถเพิ่ม/แก้ไข database column ได้ ไม่สามารถทำให้ mobile version เก่ากับใหม่ทำงานร่วมกันได้ ซึ่งไม่ใช่ “ความเร็ว” ในแบบที่ Wartime ต้องการ

อีกตัวอย่างคือการทำ native mobile app vs cross platform ในช่วงแรกเราอาจเลือกทำ cross platform ไปก่อนเพื่อรีบหา feature-market fit แต่เมื่อพบแล้ว เราจะเริ่มรู้ว่าจุดไหนมีปัญหาหรือไม่ตอบโจทย์ พัฒนา feature ยาก maintain ยากก็มา enhance เฉพาะหน้านั้นๆ

หรือการเขียน code ที่มีช่องโหว่ร้ายแรง ทำให้เกิด data leak หรือกระทบกับ financial ของบริษัทอย่างใหญ่หลวงก็เป็นสิ่งที่ต้องระวัง

การถกเถียงในเรื่อง code style หรือ variable naming หรือ monolith vs microservice หรือ SQL vs NoSQL เป็นเรื่องที่ยังไม่สำคัญ เราทำอะไรก็ได้ที่ทำได้เร็วเพื่อ release feature ให้ไว จากนั้นค่อยมา enhance เพิ่มในช่วงที่ feature เริ่มนิ่งได้

บางคนอาจสงสัยว่าการตัดสินใจเรื่องเหล่านี้ถ้าไม่เลือกตั้งแต่แรก มันจะแก้ไขยากและสร้างปัญหาในอนาคตหรือเปล่า แน่นอนว่ามีโอกาสที่จะสร้างปัญหาเมื่อมี feature-market fit เมื่อมีลูกค้าเยอะขึ้นและระบบเริ่มซับซ้อน แต่ทีมที่มี Wartime mindset จะต้องกลับมาปรับปรุงระบบให้ยั่งยืนในทันทีตลอดเวลา พวกเค้ารู้ว่า design ที่ดีคือ design ที่มีลูกค้าใช้งานจริง ทำงานได้ตามที่คาดหวังไว้ พวกเค้าเปลี่ยน technology ก็ต่อเมื่อพบว่ามันเป็นตัวถ่วงในด้านความเร็วในการปล่อย feature

Wartime Software Development ไม่ใช่ script kiddy ที่เขียน code เร็วแต่ขาดประสบการณ์ แต่เป็นเทคนิค กระบวนการและประสบการณ์มากมายที่ทำทุกอย่างเพื่อเน้นไปที่​ “ความเร็ว” บนพื้นฐานของ Software ที่ต้องทำงานได้ตามความคาดหวังของลูกค้าตลอดเวลา

พวกเขาทำสิ่งเหล่านี้เท่าที่จำเป็นในทันทีที่ได้ส่งมอบ feature ที่ตอบโจทย์ลูกค้าสำเร็จ – เขียน automate test เท่าที่จำเป็นทันทีที่ feature ตอบโจทย์ลูกค้า – clean up ทุกอย่างและ refactor code เท่าที่จำเป็นทันทีที่ feature ตอบโจทย์ลูกค้า – เขียน document เท่าที่จำเป็นทันทีที่ feature ตอบโจทย์ลูกค้า – automate business process เท่าที่จำเป็นทันทีที่ feature ตอบโจทย์ลูกค้า – สรุปบทเรียนในทุกด้านทันทีที่ feature ตอบโจทย์ลูกค้า พวกเขาใช้เวลาไม่มากในการทำสิ่งเหล่านี้เพื่อความ “ยั่งยืน” แล้วจึงเริ่มทำ feature ถัดไปที่ตอบโจทย์ลูกค้า

คำเตือน: blog นี้ยาวมาก พยายามจะเล่ารายละเอียดให้ได้มากที่สุด เผื่อเป็นประโยชน์ให้คนกำลังวางแผนจัดงาน ผมจะเน้นในมุมมองของผู้ชาย ที่จะต้องขอผู้หญิงแต่งงานเป็นหลักนะครับ ผมจะเล่าเป็นเรื่องราว ไม่ได้เล่าเป็นโครงสร้างแบบเข้าใจง่าย

อยากจะแต่งงาน เริ่มยังไง

หลายคนไม่รู้ว่าจะต้องเริ่มยังไง ต้องขอผู้หญิงแต่งงานก่อนหรือเปล่า ผู้ใหญ่จะโอเคมั้ย ต้องทำอะไรก่อน ในตอนแรกก็งงเหมือนกันครับ แต่ก็ได้คุยกับหลายๆ คนที่แต่งงานไปก่อนหน้า ถามเค้าว่าเค้าทำอะไรบ้าง แต่ว่าเริ่มต้นแรกสุด คือผมถามตัวเองก่อนว่า คนนี้คือคนที่เราอยากจะอยู่ไปตลอดใช่ไหม ในตอนนั้นเราคบกันมาสัก 2 ปีนิดๆ ผมโอเคมากๆ เลย เพราะแพรรับฟังผม แพรเปิดใจให้คน geek นิดๆ อย่างผมได้มีมุมของตัวเอง ผมเคยสอนแพรเขียนโปรแกรม แพรก็พยายามเรียนแบบน้ำตาซึมๆ ไป สุดท้ายผมก็เลิกสอนเค้าเพราะไม่มีประโยชน์ที่จะไปบังคับในสิ่งที่เค้าไม่ถนัด แต่นั่นแหละ แพรพยายามจะเข้าใจเรา เรียนรู้เรา ไม่พยายามจะยัดเยียดตัวเค้าเข้ามามากเกินไป เราก็มีความตึงๆ ใส่กันบ้างบางครั้ง แต่เราก็คุยกันด้วยดี แก้ปัญหาได้ทุกครั้ง ไม่เคยมีทิ้งปมเอาไว้รอระเบิดภายหลัง แพรเป็น supporter ที่ดีมากๆ สุดท้ายผมก็คิดว่า แต่งกับคนนี้แหละ เราน่าจะไปกันรอดจนแก่เฒ่าด้วยกัน

จากนั้นผมก็ไปเม้ากับแก๊ง engineering manager ที่ทำงานด้วยกัน ถามเค้าง่ายๆ ว่า

เราขอผู้หญิงแต่งงานเลยได้ไหม หรือต้องทำอะไรก่อน

มี Arm แชร์ให้ฟังว่า ของเค้าคือต้องให้ผู้ใหญ่ไปเจอกันก่อน ไปพูดคุยกัน เพราะถ้าเราขอกันเองเรียบร้อย แล้วค่อยไปบอกผู้ใหญ่ ถ้าผู้ใหญ่เค้าไม่ OK กันและกัน มันจะเป็นเรื่องเอา

และก็มีคนอื่นๆ พูดทำนองเดียวกัน บางคนก็บอกว่าขอกันเองเลยก็ได้ ถ้ามั่นใจว่าจะไม่แป๊ก ทั้งคู่เราและผู้ใหญ่

แล้วมันจะแปลกมั้ย ที่ผู้ใหญ่ไปคุยกัน คุยกันไว้ว่าลูกๆ เราจะแต่งงาน อย่างนี้ผู้หญิงเค้าก็รู้หมดน่ะสิ เดี๋ยวจะไม่ surprise นะ

ผมก็ถามทุกคนไปและก็เช็คเพิ่มเติมกับคนอื่นๆ ที่ผมรู้จัก ซึ่งทุกคนบอกว่า “จริงๆ ผู้หญิงเค้าก็ต้องรู้อยู่แล้วรึป่าวว่าเดี๋ยวเราจะแต่งงานกัน เพียงแต่เค้าไม่รู้ว่าวันไหน” ดังนั้นเวลาที่ผู้ใหญ่ไปคุย ก็อย่าเพิ่งกำหนดวัน ปล่อยให้เค้าลุ้นไปก่อน

สุดท้ายผมก็ตัดสินใจว่าเดี๋ยวจะให้ผู้ใหญ่ไปเจอกันก่อน

แต่ก่อนที่ผู้ใหญ่จะไปเจอกัน มันก็มีเรื่องให้ต้องคิด ต้องเตรียมตัวเยอะพอสมควรเลยนะ

ก่อนผู้ใหญ่เจอกันครั้งแรก

เรื่องราวก่อนที่ผู้ใหญ่จะเจอกัน มันจะไม่ได้เป็นเส้นเรื่องแบบเส้นตรงๆ เพราะในความเป็นจริงมันโคตรจะพันกันยุ่งเหยิงมากๆ

เริ่มจากว่า เราพยายาม sense ให้ได้ก่อนว่าแพรเค้าอยากจะแต่งกับเราใช่ไหม ผมก็คอยถามไปเรื่อยๆ วันละนิด วันละหน่อย เช่น

1. แพรดูชอบเด็กเนอะ อยากได้ลูกชายหรือลูกสาว
2. แพรอยากจะไปอยู่ที่ไหน?
3. ถ้าวันนึงชีวิตพี่เป็นขาลง เกิดลำบากขึ้นมา แพรโอเคหรือเปล่า
4. คบกันมาแล้วเป็นไง มีตรงไหนที่ชอบและไม่ชอบบ้าง

คำถามพวกนี้มันก็ช่วยเพิ่มความมั่นใจทั้งคู่แหละ แพรเองก็น่าจะรู้สึกว่าเราจริงจังกับเค้านะ ไม่ใช่คบเล่นๆ

พอเรามั่นใจประมาณนึงแล้วว่าแพรไม่น่าจะปฏิเสธ ก็เริ่มคุยเรื่องผู้ใหญ่กับแพรบ้าง หลักๆ คือ ผู้ใหญ่บ้านแพรชอบเราไหม, ผู้ใหญ่บ้านเราชอบแพรหรือเปล่า และก็เรื่องที่ยากที่สุดคือเรื่องสินสอดและเรือนหอ

สำหรับผู้ใหญ่ทางบ้านแพร เนื่องจากผมไปที่บ้านแพรอยู่บ่อยๆ คอยช่วยงานผู้ใหญ่ ก็ดูจะไม่ค่อยเป็นปัญหาเท่าไร แต่สำหรับแพรเองที่แทบจะไม่เคยได้เจอแม่ของฝั่งผู้ชายเลยก็ค่อนข้างจะยาก เพราะว่าแม่ของผมอยู่ต่างประเทศตลอด ผมเองก็แทบไม่ได้เจอเลย และยิ่งช่วง covid ก็คือไม่ได้กลับไทยเลยเกือบ 2 ปีเต็มๆ ซึ่งผมกับแพรก็คบกันมาตลอดช่วง covid นี่แหละ แพรและแม่ก็เลยแทบจะไม่เคยได้คุยอะไรกันเลยสักนิด

ผมเองก็ไม่รู้นะว่าแม่ผมโอคเกับแพรหรือเปล่า แต่ผมโอเค ดังนั้นผมมีหน้าที่ทำให้แม่โอเคด้วย 555

มีช่วงเดือน May 2022 ได้บินไปเจอแม่และไปเที่ยว ก็เลยได้คุยกับแม่จริงจังเรื่องแต่งงาน คือบทสนทนากับแม่มันจะข้ามขั้นไปเลย เพราะ relationship ในบ้านแต่ละบ้านก็คงไม่เหมือนกัน ผมสามารถคุยตรงๆ กับแม่ได้ แม่ก็รับฟังและแม่ก็ให้ความเห็นในเรื่องต่างๆ เราก็ฟังและต่อรองกันไป หลักๆ ก็คือคุยกับแม่ว่าจะแต่งงานนะ แม่กังวลอะไรไหม เราพอรู้อะไรบ้างเราก็บอกความคิดของเราให้แม่ฟังไป เช่น แต่งงานแล้วไปอยู่บ้านไหน แพรจะย้ายเข้ามาหรือว่าชาร์ปจะต้องย้ายไปอยู่กับแพร (เราตกลงกันว่าจะอยู่ทั้ง 2 บ้านสลับกันไป ไม่ซื้อบ้านหรือปลูกเรือนหอใหม่ แต่จะอยู่บ้านผมเยอะกว่านิดหน่อยเพราะเป็นส่วนตัวกว่า) เรื่องจิปาถะอื่นๆ รวมถึงเรื่องสินสอดด้วย

เรื่องสินสอดผมจะไม่ขอพูดตัวเลขนะครับ แต่จะใช้ตัวแปรแทน เช่น A, B แบบนี้

ประเด็นเรื่องสินสอดก็ค่อนข้างซับซ้อน ก่อนหน้าที่ผมจะคุยกับแม่ตอนที่บินไปต่างประเทศ ผมก็ลองถามแพรไปก่อนว่าเคยถามพ่อแม่แพรหรือเปล่าว่าจะเรียกสินสอดเท่าไร แต่กว่าที่ผมจะได้ตัวเลขมาก็ถามหลายรอบเหมือนกัน เพราะทางพ่อแม่แพรบอกว่า “แล้วแต่เราสะดวก” ซึ่งมันไม่ช่วยอะไรเลย เราก็ไม่รู้ว่าจะให้เท่าไร โชคดีที่พี่ชายแพรแต่งงานก่อนหน้านี้ ก็เลยเอาเลขนั้นมาเป็นเลขอ้างอิงก่อน รวมถึงแพรก็ลองถามพ่อแม่แบบติดตลกไปด้วย พ่อแม่ก็บอกเลขมาใกล้เคียงกับของพี่ชายแพร

แต่ว่าเลขที่ได้มาอันนี้ คือทางผู้ใหญ่เค้ายังไม่เคยไปตกลงกันเลยนะครับ ผมและแพรแค่พยายามไปสืบว่าผู้ใหญ่แต่ละท่านมองตัวเลขไว้ที่เท่าไร ผมไม่ปล่อยให้ผู้ใหญ่ไปเจอกันแล้วไปคุยเรื่องตัวเลขกันหน้างานแน่ๆ ห่วงว่าจะเหมือน pantip ที่มาเล่ากันว่าผู้ใหญ่ทะเลาะกันจนลูกๆ เครียดมาก ไม่ได้แต่งงาน

พอผมได้ตัวเลขสินสอดเป็นเงิน A บาท ทองคำ B บาท ผมก็คุยให้แม่ผมฟังในวันที่บินไปหา จริงๆ เงินและทองจำนวนนั้น ผมก็มีเตรียมไว้เรียบร้อยแล้ว แต่เงินผมอาจจะยังไม่พอสำหรับจัดงานแต่งซึ่งต้องใช้เวลาเก็บเงินเพิ่มอีก แม่ก็ค่อนข้างเป็นห่วงเพราะครอบครัวเราฐานะลำบากมาโดยตลอด ไม่อยากให้ต้องใช้เงินเยอะขนาดนี้ เลยจะขอลดจำนวนลงหน่อย (ทุกคนอย่าลืมว่าในช่วงที่คุยกันเรื่องสินสอด ฝ่ายแพรไม่รู้เรื่องนี้ เพราะฝ่ายแพรได้แต่ให้ข้อมูลผมมาอย่างเดียว)

พอกลับจากไปเที่ยว ผมก็คิดหนักมากถึงจำนวนที่แม่ขอต่อรองลงมา แล้วก็ต้องค่อยๆ ไปไล่คุยกับแพร พอแพรเข้าใจ ก็เลยบอกแพรว่า จะขอไปคุยกับพ่อแม่แพรเรื่องแต่งงานและเรื่องสินสอดหน่อย แล้วแพรก็นัดพ่อแม่ให้

ผมไม่รู้ว่าบ้านอื่นจะทำแบบนี้ได้ไหม แต่สำหรับผมกับผู้ใหญ่ทางบ้านแพร ผมรู้สึกว่าเค้ารับฟัง ไม่ได้มองเราว่าเป็นเด็ก ไม่ได้มองว่าเรื่องนี้ต้องให้ผู้ใหญ่มาคุยกันเท่านั้น คือผมสามารถไปคุยกับท่านได้ตรงๆ และประกอบกับแม่ผมก็ไม่อยู่ไทย การที่ผมไปคุยกับผู้ใหญ่ทางบ้านแพรได้เองมันทำให้ผมเตรียมเรื่องต่างๆ ได้สะดวกขึ้นมาก

พอวันที่ไปคุยจริงๆ กับพ่อแม่แพร เราก็เริ่มเปิดไปก่อนว่า ผมจริงจังกับแพร อยากจะแต่งงานกับแพร พ่อแม่ติดอะไรไหม จากนั้นก็มาคุยเรื่องจิปาถะ เช่น อยู่ที่ไหน วางแผนชีวิตยังไง ฯลฯ ซึ่งทั้งหมดก็คือผมและแพรก็ได้คุยกันมาก่อนหมดแล้ว ท่านก็ถามเรื่องงานแต่งว่ามีรายละเอียดยังไงบ้าง ผมก็แจ้งไปว่ารายละเอียดยังไม่มี เดี๋ยวจะมาคุยแยกอีกรอบ สุดท้ายก็จบเรื่องสินสอด ผมก็เล่าไปว่า แพรเคยบอกมาว่าพ่อและแม่จะเรียกสินสอดเท่านี้ใช่ไหม แต่ผมอาจจะไม่สามารถให้ได้เท่าที่พ่อและแม่ขอมา อาจจะขอลดลงหน่อย พ่อแม่แพรก็เข้าใจ ก็จบลงด้วยดี

แต่จบตรงนี้ก็ยังไม่ถือว่าตกลงสินสอดกันนะครับ อันนี้แค่ลองสอบถามเพื่อดูปฏิกริยาก่อนว่าจะมีปัญหาไหม เพราะตัวเลขจริงๆ ต้องให้ผู้ใหญ่มาแจ้งกันอีกทีนึง

ผู้ใหญ่มาเจอกันวันแรก

แม่บินกลับมาไทยอยู่ช่วงนึงไม่นานมาก ก็เลยจองคิวแม่เอาไว้ว่าจะให้ไปคุยกับผู้ใหญ่ฝ่ายแพรเรื่องแต่งงาน ก็ตกลงวันเวลากับทั้ง 2 ฝ่ายไว้เรียบร้อย แต่ก่อนจะถึงวันนั้น ฝ่ายผู้ชายก็ต้องทำการบ้านไว้ก่อน

ผมนั่งคุยกับแม่ เราจดหัวข้อต่างๆ ที่แม่จะต้องไปคุยให้เรียบร้อย เราเตรียมบทกันว่าจะคุยกันยังไง เช่น วันนั้นเราจะไปที่บ้านแพร ทางบ้านแพรจะเตรียมอาหารไว้ต้อนรับเรา เราก็จะคุยกันเรื่องแต่งงาน ฯลฯ

ในหัวข้อที่คุย ผมเตรียมกับแม่ไว้ประมาณนี้

• แต่งเข้าบ้านไหน: แพรกับผมตกลงว่าจะเข้าบ้านผม แต่ผมก็จะต้องไปอยู่บ้านแพรบ้างบางครั้ง เพราะทั้ง 2 บ้านก็มีผู้ใหญ่ที่คอยดูแล
• พิธีการในงานแต่ง: เราจะจัดแบบไทย ในพิธีจะมีอะไรบ้าง เราเอาแค่พิธีสงฆ์ ขันหมากไทย หมั้น รับไหว้ งานฉลอง แล้วก็ตกลงกันว่าจะไม่เอาอะไร เช่น ไม่เอารดน้ำสังฆ์
• เรื่องจิปาถะในงานแต่ง: แขกประมาณกี่คน ตอนแรกอยากจะจัดเล็กๆ แบบไม่เกิน 100 คนเพราะไม่อยากใช้เงินเยอะ แต่พอผู้ใหญ่คุยกันก็จบลงที่ต้องจัดงานใหญ่ขึ้น รวมไปถึงเรื่องอาหารขอเป็นโต๊ะจีน และก็เรื่องอื่นๆ ที่ทางผู้ใหญ่อยากจะขอ lock ไว้ ส่วนอะไรที่ยังไม่มั่นใจผมขอเอามาทำการบ้านแล้วจะไปอัพเดทให้ทีหลัง
• เรื่องเงินๆ ทองๆ: สินสอดตกลงกันที่เท่าไร เรื่องซองในงานแต่งใครดูแล ค่าใช้จ่ายงานแต่งทั้งหมดจะออกยังไง (ผมกับแพรตกลงกันว่าจะหารครึ่งเท่ากัน) สินสอดพ่อแม่แพรบอกว่ามอบคืนให้เราไปใช้ตั้งตัว
• แต่งวันไหน: ผมบอกแม่ว่ายังไม่ให้บอกวัน เดี๋ยวผมจะไปหาแล้วบอกเองทีหลัง ตรงนี้เราเก็บเรื่องวันเอาไว้ surprise ขอแต่งงานแพร

พอดีวันที่ไปคุย ผมไม่สบายพอดี เป็นไข้สูง (ไข้ 39.4) ก็เลยรีบคุยรีบกลับ แล้ววันถัดมาผมก็ไป admit โรงพยาบาลยาวๆ แต่วันนั้นก็ถือว่าผ่านมาได้อย่างราบรื่น พ่อแม่แพรบอกว่าวันนั้นก็เลยไม่ได้เลี้ยงอาหารแม่ผมเลยเพราะผมไม่สบาย

หาฤกษ์งานแต่ง

การหาฤกษ์เป็นเรื่องใหญ่มากเหมือนกัน ผมเป็นคนที่ไม่ถือฤกษ์ ไม่ดูฮวงจุ้ยใดๆ ดังนั้นผมไม่เคยสนใจอยู่แล้ว แต่ว่าผู้ใหญ่ก็อยากจะให้ดูมาหน่อยเป็นมงคล แพรเองก็อยากให้ดู

ในตอนแรกสุดคุยกันว่าผมจะไปดูฤกษ์กับพระอาจารย์ที่จันทบุรี เพราะเป็นที่ๆ แม่ผมนับถือ แต่ความยากมันคือ ปกติแล้วเวลาดูฤกษ์ คู่บ่าวสาวก็จะต้องไปพร้อมกัน พอพระอาจารย์ท่านบอกวันมา ก็จะกลายเป็นแพรรู้วันทันที ก็จะอด surprise อีกส่วนคือการไปจันทบุรีมันก็ต้องใช้เวลา ลางาน ขับรถไกล และต้องติดต่อพระอาจารย์ นัดวันเวลา ค่อนข้างจะยุ่งยาก ผมเลยคุยกับแม่ว่าคงจะไม่ได้ไปหาพระอาจารย์

ถัดมาผมพยายามดูฤกษ์ตามที่ตัวเองสะดวกก่อน หลักเกณฑ์ที่ผมดูคือ

1. มีเวลามากพอในการเตรียมงานแต่งทั้งหมด ผมคิดว่าอยากจะได้เวลาเผื่ออย่างน้อย 6 เดือน
2. ไม่เอาหน้าร้อน เพราะเคยคุยกับแพรว่าเผื่ออยากจะจัดงานแบบ outdoor
3. มีเวลาให้ผมได้เก็บเงินเพิ่มอีกหน่อย สำรองเอาไว้
4. ขอวันหยุด วันเสาร์ อาทิตย์ หรือดีหน่อยถ้าตรงกับหยุดยาว

จากนั้นก็ไปพยายามหาฤกษ์มงคลทาง internet ผมชอบเว็บนึงมากๆ อยากแนะนำ

79hora.com – ฤกษ์แต่งงาน

เราก็ไปดูวันที่มันเป็นสีชมพูๆ หรือมีคะแนนสูงๆ ไว้ก่อน ว่าจะเป็นช่วงประมาณไหน ในเว็บนี้ผมได้วันที่ชอบอยู่ประมาณเดือนสิงหาคม หรือ กันยายน ซึ่งห่างจากวันที่ผู้ใหญ่ไปคุยกันประมาณ 11-12 เดือน ผมมองว่ามันนานเกินไป

อีกเว็บนึงที่ไปดูก็คือ อาจารย์ณภัทร ศรีจักรนารท (Astro Neemo) อันนี้เราต้องเสียเงินดู โดยเราส่งวันเดือนปี เวลาเกิดของคู่บ่าวสาวไปให้ แล้วเค้าก็จะส่งวันเวลากลับมาให้เรา สุดท้ายก็ได้วันที่ 7 พ.ค. กลับมา พร้อมรายละเอียดยาว 3 หน้ากระดาษ A4 มีตั้งแต่รายละเอียดการทำพิธีการต่างๆ เวลาสวมแหวน เวลารดน้ำสังฆ์ เวลาส่งตัว ซึ่งกว่าจะถึงวันที่ 7 พ.ค. ก็จะได้ระยะเวลาประมาณเกือบ 8 เดือน ซึ่งก็ใกล้เคียงกับที่เราอยากได้พอดี

พอได้วันแล้ว เราก็เก็บไว้เป็นความลับ ผมบอกให้แม่รู้ไว้แล้ว แต่ผมไม่บอกแพรและผู้ใหญ่ของแพร

Surprise ขอแต่งงาน

จากวันที่ผู้ใหญ่ไปคุยกัน แพรก็พยายามถามตลอดว่าจะแต่งเมื่อไร ไปหาฤกษ์มาหรือยัง ผมก็บอกว่ายัง ทำตัวเป็นไม่รู้ ไม่ได้ดู ระหว่างนี้ก็ดูรายละเอียดการจัดงานไปพลางๆ เช่น จะจัดงานประมาณไหน จะจัด style ยังไง แบบห้อง ballroom หรือแบบริมทะเล จัดในกรุงเทพหรือต่างจังหวัด แพรอยากได้ rooftop ผมอยากได้ outdoor เราอยากได้ long table มีให้เลือกหลากหลายมากจนไม่รู้จะเลือกอะไร พยายาม survey สถานที่ต่างๆ ถามราคา แต่ก็ติดปัญหาว่าเราบอกวันที่จะจัดไม่ได้ ทางสถานที่ก็ได้แต่แนะนำรายละเอียดคร่าวๆ ถ้าเราไม่มีวันไปแจ้งเค้า ทางสถานที่ก็เช็คไม่ได้ว่าวันนั้นว่างไหม เพราะบางสถานที่ถูกจองเต็มล่วงหน้า 8-12 เดือน โดยเฉพาะวันที่ฤกษ์ดีมากๆ แต่วันที่เราได้มาไม่ได้เป็นวันมหาฤกษ์แบบนั้นก็โชคดีไป

ช่วงนี้เราก็แอบไปเตรียมแหวนสำหรับขอแต่งงาน หาทางวัด size แหวนแพร ไปสั่งทำแหวน เรื่องแหวนก็เป็นเรื่องที่ปวดหัวเหมือนกัน

ผู้หญิงจะได้แหวนจากผู้ชายทั้งหมดกี่วง? วงที่เราเอาไปขอแต่งงานจะเป็นวงเดียวกับในงานแต่งหรือเปล่า? ผมหาข้อมูลมาเยอะมาก สรุปให้ง่ายๆ ตามนี้

1. แหวนที่ขอแต่งงาน ให้แล้วให้เลย ถ้าขอแต่งงานไปแต่เกิดเหตุไม่คาดฝัน งานแต่งล่ม ผู้ชายห้ามไปทวงของคืนเด็ดขาด ยกเว้นตกลงกันไว้ดิบดีว่าจะขอคืน
2. แหวนที่ขอแต่งงาน ไม่จำเป็นต้องมูลค่าสูง ด้วยเหตุผลตามข้อ 1
3. แหวนขอแต่งงาน อยากจะเลือก style ไหนก็เลือกไปตามความชอบ จะเอาแบบ infinity ring หรือแบบเพชรชู ก็แล้วแต่ตามงบประมาณที่มี
4. แหวนที่ใช้ในพิธีสวมแหวน ควรจะเป็นแบบเพชรชู และควรจะดูอลังการหน่อย และผู้หญิงควรจะไปเลือกด้วยตัวเอง

ดังนั้นนผู้หญิงจะได้แหวนที่ถูกขอแต่งงาน 1 วง ถ้าจะเอาแหวนนั้นไปใช้ในพิธีด้วยก็ได้ หรือจะซื้อใหม่เพิ่มอีก 1 วงสำหรับใช้ในพิธีก็ได้ และผู้ชายก็จะมีแหวนของตัวเองอีก 1 วง

สำหรับในเคสของผมคือมีทั้งหมด 3 วง โดยแหวนขอแต่งงาน ผมเลือกแบบ infinity ring มีเพชรเล็กๆ ล้อมรอบทั้งวง ก็จะใส่ง่ายในชีวิตประจำวัน ใส่ติดมือได้ ไม่จำเป็นต้องซื้อแหวนเกลี้ยง และแพรเองก็ชอบใส่เพชรกับ white gold อยู่แล้ว

พอได้แหวนสำหรับขอแต่งงาน ก็เหลือแค่ไป surprise ผมก็หาสถานการณ์ที่เหมาะสมอยู่นานมาก ไม่รู้เหมือนกันว่าจะขอตอนไหน โชคดีมีวันที่ไปเที่ยวน่านพอดี ก็เลยเล็งว่าจะไปขอตอนนั้น บรรยากาศน่าจะดี วิวน่าจะสวยและก็สงบหน่อย

เอาจริงๆ เวลาจะขอแต่งงานมันตื่นเต้นมากๆ นะ ใจเต้นรัวๆ บางทีเราก็เขินผู้คนเหมือนกัน แต่อยากจะบอกผู้ชายทุกคนที่จะขอแต่งงานว่า อย่าไปเขิน ทุกคนที่เห็นเหตการณ์เค้าส่งกำลังใจ เค้ายินดีให้กับเรา เราไม่ได้ทำเรื่องน่าอายใดๆ เพราะฉะนั้นอย่ากลัวที่จะขอแต่งงานต่อหน้าผู้คน ผมคิดว่ามันน่ารักมากๆ

จังหวะที่จะขอแต่งงาน สิ่งที่ต้องทำคือ ตั้งสติให้ดี อย่าลืมใจความสำคัญที่จะพูดกับเจ้าสาวของเรา The show must go on. พลาดอะไรไปก็ช่างมัน ไม่มีใครรู้หรอกว่าเราพูดครบหรือไม่ครบ

หลังจากที่ขอแต่งงานเสร็จ เราก็บอกวันแต่งให้แพรและพ่อแม่แพรรู้ พอกลับจากไปเที่ยว ก็เริ่มลุยเตรียมงานแต่งเต็มกำลัง

งานแต่งด่านแรก: งบประมาณและสถานที่

เรื่องสถานที่ จำนวนแขก เป็นสิ่งสำคัญที่สุดที่จะกระทบกับงบประมาณ สิ่งแรกที่เราควรทำคือ ตั้งวงเงินสูงสุดที่เราจะจ่ายสำหรับจัดงานแต่งเสียก่อน สำหรับผมกับแพรสิ่งที่เราทำคือ เราดูว่าเราพอรับค่าใช้จ่ายได้ที่เท่าไร ตอนแรกเรามองว่าอยากจะจัดให้อยู่ในราคาประมาณ 500,000 – 600,00 บาท จากนั้นเราก็ไปเริ่ม survey ราคา

อยากบอกทุกคนว่า ค่าใช้จ่ายจริง มักจะเป็น 2 เท่าของงบที่เราตั้งไว้ตอนแรก ดังนั้นเตรียมเงินเผื่อๆ กันไว้ด้วยครับ

เราเริ่มติดต่อสถานที่ นัดวันเข้าไปดูสถานที่จริง เก็บข้อมูลราคา ค่าอาหารต่อหัวของแขก รวมถึง package ของแถมต่างๆ เอาไว้ เราหาสถานที่มากกว่า 20 ที่ ติดต่อไปจริงๆ ประมาณ 10 กว่าที่ ได้ข้อมูลมาเปรียบเทียบกัน

หลักๆ ค่าใช้จ่ายมันแบ่งสัดส่วนกันประมาณนี้ 1. ค่าอาหารของแขก ~50-60% ของงบประมาณ 2. ค่าสถานที่ ค่าตกแต่ง ~30% ของงบประมาณ 3. จิปาถะ เช่น ค่าชุดแต่งงาน ค่ารองเท้า ช่างแต่งหน้า รันคิว ขันหมาก พิธีกร ฯลฯ ~10-20% ของงบประมาณ

ดังนั้นถ้าต้องการคุมงบประมาณให้อยู่หมัด สิ่งที่ต้องใส่ใจมากๆ คือ อาหารและสถานที่

ปกติแล้วสถานที่แต่งละแห่งจะ bundle อาหารเข้าไปด้วย บางแห่งสถานที่สวยมาก ค่าสถานที่ไม่แพงแต่ค่าอาหารต่อหัวแพงลิบลับ ราคาอาหารต่อหัวที่ survey ในกรุงเทพและปริมลฑลมีตั้งแต่ หัวละ 800 บาท ไปจนถึง 2,500 บาท แต่โดยทั่วไปของในกรุงเทพ ค่าอาหารต่อหัวจะอยู่ที่ประมาณ 1,400 บาท

จำนวนแขกในงานของผมรวมทั้งผู้ใหญ่และเพื่อนๆ ผมกับแพร อยู่ที่ ~350 คน คิดเป็นเงินค่าอาหารทั้งหมด 490,000 บาทเป็นอย่างน้อย ซึ่งยังไม่รวมค่าอื่นๆ อีกมากมาย ดังนั้นงบประมาณ 500,000 – 600,000 ที่วางไว้นั้นไม่สามารถทำได้จริง

สุดท้ายเราก็เลือกที่จะปรับงบประมาณเพิ่ม เพราะเราต้องจัดงานในกทม เพื่อให้แขกเดินทางมาสะดวก เราตั้งงบประมาณใหม่ไว้ที่ประมาณ 800,000 – 900,000 บาท

ถัดมา สิ่งที่ต้องดูในการเลือกสถานที่ก็คือจำนวนแขก บางสถานที่รับได้แค่ 180 คน บางแห่งรับได้แค่ 250 คน มีแค่ไม่กี่สถานที่ ที่สามารถจุได้ 350 คนในครั้งเดียว และสถานที่ที่จุคนได้มากๆ ก็จะไม่สวยถูกใจแพร หรือไม่ก็คืออยู่ไกลมาก เช่น นนทบุรี เดินทางลำบาก ไม่ติดรถไฟฟ้า เป็นต้น

โดยเฉลี่ยแล้ว ถ้าจะให้เลือกสถานที่ได้ง่ายหน่อย มีตัวเลือกมากๆ จำนวนแขกควรจะอยู่ที่ประมาณ 150-180 คน แต่ถ้าเกินกว่านี้ ตัวเลือกที่เหลือมักจะเป็นห้อง ballroom ของโรงแรม

บางสถานที่ก็มี decoration ให้เลยในตัว บางสถานที่ไม่มี decoration ให้ก็ต้องไปจ้าง organizer เข้ามา ซึ่งส่วนใหญ่สถานที่จะมี organizer ที่เป็น partner อยู่แล้ว เราสามารถสอบถามกับทางสถานที่ได้เลย แต่การตกแต่งโดย organizer ก็จะมีค่าตกแต่งเพิ่มเติม ขึ้นอยู่กับความอลังการที่เราอยากได้ เริ่มต้นที่ผมรู้ก็จะประมาณ 50,000 บาท ซึ่งก็มักจะได้ backdrop ทางเข้างานและตกแต่งสถานที่ประปรายเพียงนิดหน่อยเท่านั้น ถ้า option จัดเต็มหน่อยก็จะประมาณ 100,000 – 150,000 บาท

บางสถานที่ก็จะมีขันหมากและของแถมต่างๆ เพิ่มให้ด้วย ผมแนะนำว่าเรื่องขันหมากและของแถมพวกนี้ไม่จำเป็นต้องสนใจมาก เพราะเดี๋ยวเราจะต้องจ้างทีมงานรันคิวเข้ามา แล้วทีมงานมักจะมีสิ่งเหล่านี้พ่วงเป็น package มาให้เลย ดังนั้นเลือกสถานที่โดยเน้นปัจจัยด้าน อาหาร จำนวนแขก การตกแต่ง การเดินทาง เป็นหลักก็เพียงพอ

สุดท้ายเราก็ไปจบที่โรงแรม Pullman Bangkok Hotel G ที่เลือกที่นี่เพราะว่าได้ห้อง ballroom ชั้นบนสุดของโรงแรม และได้ภาพ pre-wedding เป็นชั้นดาดฟ้าของโรงแรมตามที่แพรอยากได้ ส่วนเรื่องราคาก็อยู่ในเกณฑ์รับได้

ปัญหาเดียวของโรงแรมนี้คือห้อง ballroom รับคนได้แค่ ~230 คน ดังนั้นเราต้องแบ่งคนออกเป็น 2 กลุ่ม แล้วจัดงาน 2 รอบ ซึ่งก็เพิ่มค่าใช้จ่ายไปอีกพอสมควร แต่อีกเหตุผลคือ ผมอยากจัดงานเด็กแยกจากงานผู้ใหญ่ เพื่อจะได้คุม mood & tone ของงานเด็กได้เต็มที่ แถมมี after party แบบสุดเหวี่ยงด้วย

งานแต่งด่านที่ 2: ทีมงานต่างๆ

นอกจากสถานที่ อาหารแล้ว ก็มีจะมีเรื่องทีมงานที่เราจะต้องจัดการเยอะมากๆ

1. ร้านชุดบ่าวสาว
2. ทีมงาน pre-wedding
3. ทีมงานช่างแต่งหน้า ทำผมบ่าวสาว
4. ทีมงาน organizer ที่จัดการเรื่องการตกแต่งสถานที่
5. ทีมงานของฝ่ายสถานที่ เราต้องคอยประสานเจ้าของสถานที่ตลอด รวมถึงเรื่องอาหารด้วย
6. ทีมงาน รันคิว ที่คอยดูแลเรื่องคิวพิธีการต่างๆ
7. ทีมงานช่างภาพ คอยเก็บภาพบรรยากาศ
8. ทีมงานนักดนตรี เครื่องเสียง สำหรับปาร์ตี้
9. เพื่อนบ่าวสาว
10. พ่อแม่ของบ่าวสาว และญาติคนสำคัญต่างๆ
11. แขก VIP เช่น ผู้อาวุโสฝ่ายเจ้าบ่าว เจ้าสาว และประธานในพิธี
12. พิธีกรในงานฉลอง และนายพิธีในงานพิธีการไทย
13. พระสงฆ์
14. เจ้าหน้าที่จดทะเบียนในงานแต่ง
15. supplier ต่างๆ ที่เราอาจจะติดต่อ เช่น สั่งเครื่องดื่ม alcohol, ทำการ์ด, ของชำร่วย, ของรับไหว้, ฯลฯ

ถ้าไม่อยากปวดหัวในสิ่งเหล่านี้ แนะนำให้จ่ายเงินจ้าง organize หรือ wedding planner ดูแลให้ทั้งหมดแทนนะครับ (ใช้เงินแก้ปัญหา) แต่ผมไม่จ้างครับ จะทำเองทั้งหมด 555

ทุกคนก็ค่อยๆ ไล่ติดต่อไปตามลำดับนะครับ แล้วผมจะค่อยๆ อธิบายในแต่ละเรื่องไป

เรื่องที่ 1: ชุดบ่าวสาว

ปกติแล้วรูปแบบของชุดมีตั้งแต่ ชุดเช่า (เป็นชุดที่ร้านเคยตัดไว้แล้ว เราแค่เช่าใส่ แก้ size ได้แค่นิดหน่อย) ชุดเช่าตัด (ตัดให้ใหม่ แต่จบงานแล้วไม่ได้ชุดกลับไป ร้านจะเอาไปให้คนอื่นเช่าต่อ) ชุดตัดซื้อ (ตัดใหม่ ได้ชุดกลับไปด้วย) ผมแนะนำให้คุมงบประมาณดีๆ เพราะชุดเจ้าสาวนั้นมีตั้งแต่ราคาถูกเฉียดๆ หมื่น ไปจนถึงหลายแสน แต่สำหรับชุดเจ้าบ่าวที่ปกติจะเป็นสูทก็จะไม่แพงมากอยู่แล้ว

ปกติแล้วร้านจะขายเป็น package ชุดเจ้าสาว 1 ชุด ได้ชุดเจ้าบ่าวมาด้วยคู่กัน ราคาโดยเฉลี่ยอยู่ที่ ~20,000 บาท ต่อ 1 set (แบบที่ร้านได้กำไรแล้วด้วย) ดังนั้นถ้าเราได้ราคาแพงกว่านี้ ก็ควรจะดูว่ามันคุ้มค่าจริงไหม

เรื่องเทคนิคหมกเม็ดของร้านชุดเจ้าสาวคงไม่พูดถึงนะครับ ขอให้ทุกคนไปตามหาเอาใน internet

สิ่งที่แนะนำให้ทุกคนทำคือ พยายามไปลองชุดบ่อยๆ หา style ชุดที่ตัวเองชอบ ถ้าเป็นการเช่าชุด ปกติแล้วชุดจะถูกวนไปใช้งานอยู่เรื่อยๆ มีคิวต่อยาวๆ ทำให้เรามีโอกาสได้ลองชุดที่เราอยากลองน้อยลง เพราะร้านเค้าจะต้อง lock เอาไว้ให้คนที่จะใช้งานจริง ถ้าเจอชุดที่สวยถูกใจแล้ว ให้ lock ชุดไว้เลย ไม่ต้องเสียดายว่าจะมีชุด collection ออกใหม่มา

เรื่องที่ 2: ช่างแต่งหน้า ทำผม

แนะนำให้รีบหา ดูผลงาน ติดต่อเอาไว้แต่เนิ่นๆ เพราะช่างแต่งหน้าเด็ดๆ มักจะคิวเต็มเร็วมาก โดยเฉพาะวันที่ฤกษ์ดี ผมจองล่วงหน้าประมาณ 4-5 เดือน โดยเฉลี่ยค่าแต่งหน้าเจ้าสาวและเจ้าบ่าวจะอยู่ที่ประมาณ 12,000 – 15,000 บาท เป็นราคาเริ่มต้น ซึ่งจะแต่งแค่รอบเดียว เช่น เช้า หรือ เย็น แต่ถ้าเรามี 2 งานแบบ เช้า-เที่ยง ก็จะคิดเป็น 1.5 รอบ ก็จะเพิ่มเงินเล็กน้อย เช่น จาก 15,000 บาท เป็น 20,000 บาท

เรื่องที่ 3: organizer ตกแต่งสถานที่

ควรจะคุยกับ organizer เรื่องการตกแต่งสถานที่แบบละเอียดประมาณ 2-3 เดือน ก่อนถึงวันจริง ถ้า organizer เป็น partner กับทางสถานที่อยู่แล้วก็จะไม่ค่อยมีปัญหา เพราะทางสถานที่จะห่วงเรื่องคุณภาพและทีมงาน organizer ว่าอาจจะทำให้สถานที่เค้าเสียหาย ทำงานไม่ได้มาตรฐาน ซึ่งเราอาจจะโดนค่าปรับจากเจ้าของสถานที่ได้ ต้องคอยเช็คกับทางสถานที่อยู่เรื่อยๆ ว่าจะมีปัญหาอะไรไหมในรูปแบบการตกแต่งที่เราอยากได้

เราต้องคุยเรื่อง theme สีของงาน, mood & tone เพื่อที่ organizer จะได้ตกแต่งได้ถูกต้อง รวมถึงเอา theme งานไปทำการ์ด และสิ่งต่างๆ เพื่อให้สวยงามไปในทางเดียวกัน

เรื่องที่ 4: พิธีการ รันคิว พิธีกร

บ่าวสาวควรติดต่อทีมงานรันคิว พิธีกรเอาไว้เนิ่นๆ ขอ template ต่างๆ เอาไว้ เช่น เราจะจัดงานแบบไหน มีลำดับพิธีการยังไง ปกติทีมรันคิวจะมีลำดับงานแบบมาตรฐานเอาไว้อยู่แล้ว เราสามารถใช้ตรงนี้เป็นต้นแบบได้เลย

ถัดมาคือบ่าวสาวต้องคุยกันเองให้มาก ว่าจะให้ลำดับพิธีในงานเป็นยังไง มีเกมเล่นในงานไหม เป็นเกมอะไร จะมี surprise อะไรกันหรือเปล่า ทั้งหมดเพื่อที่จะได้ดูเรื่องเวลาว่าแน่นเกินไปไหม เป็นไปได้หรือเปล่า

ปกติแล้วกว่าจะสรุปลงตัวและนิ่งก็จะอยู่ราวๆ 2-4 สัปดาห์ก่อนวันจริง

เรื่องที่ 5: เพื่อนบ่าวสาว

เพื่อนบ่าวสาวของเราดีมากๆ เพื่อนเจ้าสาว แพรขอให้เพื่อนสนิทมาทำหน้าที่ตรงนี้ ส่วนเพื่อนเจ้าบ่าว ผมขอให้เพื่อนที่ทำงานใน office มาช่วยทำหน้าที่ โดยสาเหตุหลักๆ ของผมคือ ผมทำงานกับเพื่อนใน office มานาน และเรารู้ฝีมือกันดีว่าทุกคนทำงานได้ดี เราคุยงานกันเร็ว จัดการงานกันได้ราบรื่น

ปกติเพื่อนบ่าวสาวจะมีหน้าที่คือ

1. ช่วยในพิธีแห่ขันหมาก กั้นประตูเงินประตูทอง
2. ช่วยรับแขกที่โต๊ะต้อนรับ
3. ช่วยโปรยดอกไม้ตอนเปิดตัวบ่าวสาว
4. ช่วยในพิธีต่างๆ นิดหน่อย หรือแล้วแต่บ่าวสาวจะขอให้ช่วย

เพื่อนบ่าวสาวของเรา เรากะใช้งานเต็มที่มากๆ 555 ตั้งแต่ช่วยตัดสินใจเรื่องต่างๆ ช่วยบริหารแขกในงาน อำนวยความสะดวกให้แขก ประสานกับทีมงานต่างๆ แทนเรา เช็คความเรียบร้อยของสถานที่แทนเรา ดูแลของ ดูแลทรัพย์สิน และอีกเยอะมากๆ

เราพาเพื่อนบ่าวสาวมาเจอหน้าพร้อมกันก่อนวันงาน ทานข้าวกัน ทำความรู้จักกัน และผมก็เตรียม file brief งานเพื่อนบ่าวสาวอย่างละเอียด ว่าแต่ละคนรับผิดชอบหน้าที่อะไร ใครต้องประจำตรงไหน หากมีปัญหาเกิดขึ้นต้องแก้ปัญหาอย่างไร พร้อม contact ของ key person ต่างๆ ทั้งหมดเพื่อให้งานราบรื่น ไม่ต้องวิ่งวุ่นขวักไขว่หาตัวกันไม่เจอ แล้วเพื่อนบ่าวสาวเราก็ทำออกมาได้ดีมากๆ ต้องปรบมือให้ทุกคนครับ

ตัวไฟล์ brief งาน กดดูที่นี่

เรื่องที่ 6: wedding presentation & website

อันนี้คือสุดมากๆ เราสำรวจราคาค่าจ้างแล้วนะครับ ปกติทำ video presentation ก็จะอยู่ที่ประมาณ 15,000 – 50,000 บาท แล้วแต่ว่าจะจ้าง studio professional ระดับไหน

แต่ว่าผมตัดสินใจทำเองทุกอย่าง เพราะเรารู้สึกว่า การไปจ้างมักจะมีข้อจำกัด เช่น เราจะขอสั่งแก้งานได้กี่ครั้ง จะได้ storyline และ cutting ตามที่อยากได้ไหม จำนวนเวลาที่ออกกองก็มีจำกัด ฯลฯ ทำเองสบายใจกว่า

ผมก็ลงทุนซื้ออุปกรณ์ไว้แล้ว เช่น GoPro แต่พอลองใช้จริงๆ ปรากฎมันไม่ค่อย work ผมมีกล้อง mirrorless อยู่ตัวนึง และก็มี lens อยู่นิดหน่อย เลยไปซื้อ Ronin DJI RS3 mini มาเพิ่ม แล้วก็ไปลากน้องสาวมาช่วยถ่ายให้ คือทุกคนก็ใหม่หมด ใช้งานไม่เป็น การแสดง การเขียนบทก็ไม่เคยเรียน ก็นั่นแหละ นั่งเรียนด้วยตัวเองตั้งแต่ 0 เรื่องตัดต่อก็ไปเรียนวิธีการใช้ DaVinci Resolve 18 ใหม่ทั้งหมด

เราก็ไปถ่ายทำที่หัวหิน หาสถานที่ที่เหมาะสมอยู่สักพัก เขียนบทประมาณ 1 เดือน ถ่ายทำ 3 วัน ตัดต่ออีก 2-3 เดือน แก้ไขเล็กน้อย ทั้งหมดก็เรียบร้อย ตัว file final กับ shotlist ที่เขียนก็อาจจะไม่ได้ตรงกันทั้งหมดเพราะความสามารถคนถ่ายและนักแสดงมีจำกัด เรื่องไฟ แสดง อุปกรณ์ หลายๆ อย่างก็ต้องปรับกันไปตามหน้างาน

website ลงทะเบียนผมก็ทำเอง ออกแบบเองทั้งหมด บ้าพลังขนาดไหน 555

• link screenshot website วันที่ 4 พ.ค.
• link screenshot website วันที่ 7 พ.ค.
• link file shotlist ของ presentation
• link video presentation

เรื่องที่ 7: วงดนตรี after party

การเอาวงดนตรีเข้ามาก็มีรายละเอียดปลีกย่อย สำหรับผมผู้ที่ไม่รู้เรื่องวงดนตรีใดๆ ทั้งสิ้นก็จะค่อนข้างยากหน่อย

ปกติแล้วสิ่งที่จะต้องดูคือ นักร้องนักดนตรี, เครื่องดนตรี, เครื่องเสียง, ระบบแสงสี ทั้งหมดนี้เราจะจ้างแยกกันเป็นส่วนๆ ก็ได้ บางทีมงานก็จะมี bundle กันมา

ตอนแรกมีวงที่ผมชอบมากๆ วงนึง ก็คือวงโนบาร์หน้าช่อ ทางวงมีนักดนตรี สามารถให้ทางวงจัดการเรื่องเครื่องเสียงได้ ผมไม่ได้ถามเรื่องระบบแสงสี

อีกวงก็คือพอดีไปงานแต่งเพื่อนที่ office แล้ววงนี้ก็เล่นสนุกดี นั่นก็คือวง Catzilla เราเลยหา contact ทักไปคุยกับทางวง แล้วทางวงเค้ามีบริการแบบ full option คือตั้งแต่ระบบแสงสีไปจนถึงนักดนตรีครบหมดในทีเดียว ราคาที่ได้มาก็ถือว่ารับได้ เราเลยเลือกวงนี้

จบงานออกมาก็คือไม่ผิดหวังเลย จัดเต็มทุกอย่าง พี่บุ๋นก็ให้คำแนะนำผมดีมากๆ ในรายละเอียดต่างๆ

ส่วนเรื่องอื่นๆ ที่เหลือก็จิปาถะแล้วครับ เช่น เจ้าหน้าที่จดทะเบียนในงาน ต้องไปติดต่อ ต้องนิมนต์พระสงฆ์ไหม ไปรับไปส่งท่านยังไง อุปกรณ์ต่างๆ ที่ต้องเตรียม อันไหนสถานที่เตรียมให้ อันไหนทีมงานเตรียมให้ อันไหนที่บ่าวสาวต้องเตรียมเอง

งานแต่งด่านที่ 3: เรียนเชิญแขก

เนื่องจากเรามีจำนวนที่นั่งจำกัด เราก็จะเชิญแขกมากเกินไม่ได้ เราแบ่งงานผู้ใหญ่ไว้ที่ 200 คน และงานเด็ก 150 คน

ฝ่ายผู้ใหญ่ เราให้พ่อแม่จัดการ เพราะเป็นแขกของท่าน ให้ท่าน list รายชื่อแขกที่จะเชิญ จัดคนลงโต๊ะให้ได้ (เป็นโต๊ะจีน) จัดว่าใครจะนั่งกับใคร จากนั้นก็เอารายชื่อไปพิมพ์ซอง แขกบางท่านก็โทรไปเชิญและส่งการ์ด online

ของฝั่งเด็ก เราก็ list รายชื่อแขกออกมา พิมพ์ชื่อบนซอง ส่งการ์ดเชิญไปให้

การ์ดแต่งงานเราต้องสั่งทำ 2 ชุด มีรายละเอียดไม่เหมือนกัน ราคาการ์ดถูกสุดก็ประมาณ 12 บาทต่อใบ ถ้าปั้มฟลอยแบบเราก็จะบวกราคาเพิ่ม บางอันดีๆ หรูๆ หน่อยอาจจะถึง 50 บาทต่อใบก็ได้ ของผมจบงานแล้วการ์ดเหลือเยอะพอสมควรเพราะพิมพ์มาเท่ากับจำนวนแขก แต่ไม่ได้แจกแขกทุกคน บางคนก็ส่ง online บางคนก็ให้ใบเดียวแต่เชิญทั้งครอบครัว

เราเริ่มแจกการ์ดเชิญประมาณ 1-2 เดือนก่อนวันงาน ถ้าแจกล่วงหน้านานกว่านั้นก็อาจจะลืม ถ้าแจกกระชั้นชิดไปแขกก็อาจจะไม่สะดวก

ปัญหาคือการ confirm แขก เป็นเรื่องที่ยากมากๆ บางท่านก็แจ้งว่าเดี๋ยวจะ confirm อีกที บางท่านก็สามารถบอกได้เลยว่ามาได้หรือมาไม่ได้ รวมถึงยิ่งวันใกล้ๆ งาน ก็จะมีแขกบางท่านโทรมายกเลิกเพิ่มเติม

ผมเองก็ไม่รู้เหมือนกันว่าควรจะทำวิธีไหนดีที่สุด แต่วิธีที่ผมใช้คือ

1. list รายชื่อแขกออกมาให้เกินกว่าจำนวนที่นั่งประมาณ 20-30% (จริงๆ เราอยากเชิญทุกคนในนี้ แต่เนื่องด้วยสถานที่มันทำไม่ได้จริงๆ)
2. เชิญไปให้เกินกว่าจำนวนที่นั่ง 10%
3. ถ้ามีแขกยืนยันว่าไปไม่ได้เลยทันที ก็ไล่เชิญเพิ่มไปเรื่อยๆ พยายาม keep จำนวนให้เกิน 10% ไว้เสมอ
4. 2 สัปดาห์สุดท้ายก่อนถึงวันแต่ง เราจะไม่เชิญใครเพิ่มแล้ว

โดยปกติสถานที่จะสามารถเพิ่มโต๊ะได้ประมาณ 10% ดังนั้น best case คือคนมาเกิน 10% ก็จะได้นั่งตรงนี้ที่สำรองไว้ แต่ถ้าเป็น normal case คือหน้างานคนจะมาน้อยกว่าที่เชิญ 10% อยู่แล้ว แขกที่มาจริงก็จะไม่ดูโล่งจนเกินไป

สำหรับงานเด็กที่เป็น international buffet จะไม่ค่อยมีปัญหาหากเชิญเกิน 10% แต่สำหรับผู้ใหญ่ที่เป็นโต๊ะจีน จะมีปัญหาในการจัดโต๊ะมากๆ เพราะเราไม่สามารถจับคนที่ไม่รู้จักกัน ให้มานั่งด้วยกันได้ ดังนั้นในงานผู้ใหญ่ เราจะไม่เชิญคนเกินเด็ดขาด

งานแต่งด่านที่ 4: รับมือกับปัญหา

จัดงานแต่งมีปัญหาให้ลุ้นตลอดครับ ยิ่งใกล้วันแต่งเท่าไร ก็จะมีปัญหาจุกจิกโผล่มาเต็มไปหมด ดังนั้น พยายามเคลียตารางช่วงใกล้ๆ วันแต่งให้โล่งๆ ไว้ อย่าพยายามยัดสิ่งที่ต้องทำมาใกล้วันแต่งจนเกินไป

ผมเองก็มีปัญหาที่เจออยู่บ้างเช่นกัน

พิธีการเช้า-เที่ยงแน่นและรีบจนเกินไป

สืบเนื่องมาจากเรื่องฤกษ์ที่ดูมา พิธีสงฆ์ 6.30 ขันหมากเริ่ม 8.39 เวลาสวมแหวนตามฤกษ์คือ 9.39 แล้วรับไหว้ที่เวลา 11.09 แต่จำนวนแขกรับไหว้คือประมาณ 30 คู่ ซึ่งน่าจะจบที่ 12.10 แล้วบ่าวสาวต้องไปเปลี่ยนชุด เปลี่ยนผมอีก 1 ชั่วโมง ทำให้พิธีการในงานฉลองเที่ยงต้องไปเริ่ม 13.00 และต้องจบภายใน 14.00 เพราะใช้ห้องได้ถึงแค่เวลานี้ ทางผู้ใหญ่ก็มีบอกว่าอยากจะให้มีเวลามาถ่ายรูป ต้อนรับแขกก่อนเข้าพิธีฉลองด้วย เพราะถ้าพิธีจบเวลา 14.00 เราต้องคืนสถานที่เลย ทุกคนก็จะต้องรีบออกจากห้อง รีบกลับทันที

แพรและผมต้องคุยกัน และก็ต้องไปคุยกับพ่อแม่ รวมถึงแจ้งกับแขกทุกท่านที่เรียนเชิญไว้แล้วด้วยว่าจะมีการเปลี่ยนเวลาให้เร็วขึ้น เราตกลงกันว่า พิธีสงฆ์ 6.30 ตามเดิมไม่เปลี่ยน แต่ขยับทุกอย่างลงมาประมาณ 1 ชั่วโมง ขันหมากเริ่มที่ 8.00 ปล่อยทุกอย่าง flow ไปได้เลยไม่ยึดตามฤกษ์ที่ดูมา อย่างที่บอกไปคือผมไม่เคยถือเรื่องฤกษ์อยู่แล้ว ดังนั้นผมเองไม่มีปัญหา

ถัดมาคือต้องไปไล่คุยกับทีมงานรันคิว สถานที่ และ organizer เรื่องเวลาใหม่ทั้งหมด เพื่อที่ทุกคนจะได้ปรับตารางให้ตรงกัน จะได้ไม่ผิดพลาด

ยังโชคดีที่เรื่องนี้โผล่มาประมาณ 2 สัปดาห์ก่อนวันงาน ก็เลยไม่วุ่นวายมากนัก แล้ววันจริง พอเรารันไปตามตารางเวลาใหม่นี้ เราก็รู้สึกว่างานมันราบรื่นมากๆ ทุกคน happy เราก็ happy

ทีมงานมีการเปลี่ยนแปลงคน

เริ่มตั้งแต่ Sales ของโรงแรมมีการเปลี่ยนใหม่ เราก็ห่วงว่า sales คนใหม่จะตกหล่นรายละเอียดอะไรหรือเปล่า รวมถึงเราตกลงกับ sales คนเก่าไว้ว่าจะขอให้เค้าช่วยงานบางอย่างด้วย พอเค้าไม่อยู่ เราก็ต้องหาทีมงานมาทำตรงจุดนั้นแทน

Sales ร้านชุดเจ้าสาวลาออก ทำให้คนดูแลเรื่องชุดเปลี่ยใหม่ แล้วร้านชุดก็ดูจะตกๆ หล่นๆ อยู่แล้ว เลยยิ่งเป็นห่วง แต่คนที่มาดูแลช่วงต่อก็โอเค เรา recheck รายละเอียดต่างๆ ดูแล้วครบถ้วน ไม่มีอะไรตกหล่น ก็สบายใจ

ทีมรันคิว ยังไม่ได้ lock คนที่จะมาดูแลพิธีการให้ เรื่องนี้ไม่ได้มีปัญหามาก เราแค่ห่วงว่าทางทีมรันคิวจะส่งรายละเอียดงานกันครบถ้วนไหม จะ brief งานกันถูกไหม แต่พอหน้างานจริงก็ราบรื่นมากๆ และทีมงานก็ professional มากๆ ด้วย

เรื่องคนที่มีหน้าที่ตามจุดต่างๆ ก็มีการเปลี่ยนแปลงอยู่บ้าง แต่ก็แก้ปัญหาเฉพาะหน้า ผ่านมาได้หมด

วันที่ 4 พ.ค. กับ 7 พ.ค. มี surprise ให้ลุ้นตลอด

วันที่ 7 พ.ค. เกือบจะเป็นวันเลือกตั้งทั้งประเทศ ก็ห่วงว่าแขกจะมางานน้อยลง จะ cancel เพราะติดไปเลือกตั้ง ฯลฯ

วันที่ 4 พ.ค. เป็นวันหยุด แต่วันที่ 5 ไม่หยุด แล้วรัฐบาลประกาศให้ 5 เป็นวันหยุดพิเศษเพิ่มขึ้นมา เลยกลายเป็นหยุดยาว 4-7 พ.ค. ก็ห่วงว่าแขกจะใช้หยุดยาวนี้ในการไปเที่ยว แล้วไม่สามารถมางานแต่งเราได้

อีกเรื่องคือวันหยุดยาวแล้วห้องโรงแรมจะเต็มไหม ถ้าแขกจะมานอนพัก ตอนแรกดูราคาหน้าเว็บไว้ค่อนข้างสูงทีเดียว คืนละ ~5,000 บาท แต่พอใกล้ๆ วัน ห้องไม่ได้แน่นขนาดนั้น ราคาหน้าเว็บก็ drop ลงมาเท่ากับราคาพิเศษที่เราได้คุยกับโรงแรมไว้

วันที่ 4 พ.ค. เราจะจัดงานปาร์ตี้ ก็ห่วงว่าจะให้เสริฟเครื่องดิ่มได้หรือเปล่า เราเช็คแล้วว่าทำได้ก็รอดไป

วันที่ 7 พ.ค. เป็นวันเลือกตั้งล่วงหน้า มี beer สดเหลือจากวันที่ 4 พอสมควร แต่เอามาเสริฟไม่ได้เพราะผิดกฎหมาย ก็เสียดายกันไป

เรื่องจิปาถะต่างๆ ที่ค่อยๆ โผล่มาทีละนิด

ผมทำ todo list ไว้ว่าในแต่ละวันต้องทำอะไรให้เสร็จบ้าง ต้อง final เรื่องอะไร บางอย่างก็ตัดสินใจไม่ทำ ยกเลิก บางอย่างก็ทำเสร็จก่อน บางอย่างก็ delay และก็มีบางอย่างเพิ่มเข้ามา

อย่าง script brief งานเพื่อนบ่าวสาว ก็เป็นสิ่งที่ต้องทำเพิ่ม และไม่ได้มีจดไว้ตั้งแต่ตอนแรก

ของที่เราจะต้องขนไปโรงแรม เราก็ต้องเตรียม checklist ให้ครบ ไม่งั้นเดี๋ยววันงานจริงตกหล่นแล้วจะมีปัญหา

บ่าวสาวไม่สบายก่อนแต่งงาน

เรื่องนี้เป็นสิ่งที่กังวลที่สุดเลย เริ่มจากแพรไปขัดผิวแล้วมีผื่นแพ้แดงคันขึ้นทั้งตัว ต้องวิ่งวุ่นพาไปหาหมอ

ผมเองก็ท้องเสียไป 2 วันติด หลังจากจบ party วันที่ 4 พ.ค. แต่โชคดีหายทันวันที่ 7 พ.ค.

ส่วนแพรจบ party มาก็คือเท้าเจ็บ เลือดอาบนิ้ว ต้องคอยทำแผล ห่วงจะใส่รองเท้าคัชชูไม่ได้ ทางโรงแรมก็ดูแลดีมาก ผมกับแพรเดินไปทานอาหารเช้าที่ห้องอาหารโรงแรม ใส่ slipper ไป น้องที่หน้า front แจ้งว่าไม่อนุญาติให้ใส่ ห่วงว่าจะอันตรายเพราะพื้นลื่น เราเลยแจ้งว่าพอดีเท้าเป็นแผลต้องขอใส่อันนี้ น้องที่ front ก็แอบไปแจ้งทาง sales (คุณแนน) ว่าเจ้าสาวเท้าเจ็บ คุณแนนก็รีบโทรมาหาทันทีด้วยความเป็นห่วง และทีมงานโรงแรมทุกคนก็ช่วยดูแลแพรเป็นอย่างดี

และก็โชคดีที่ไม่มีใครไม่สบายเพิ่มอีก

จบงานแล้วเป็นไงบ้าง

สรุปค่าใช้จ่ายโดนไปทั้งหมดประมาณ 1,020,000 บาท ยังไม่รวมสินสอดที่ฝ่ายชายต้องเตรียม หักลบกลบหนี้กับซองช่วยงานก็ยังขาดทุนอยู่พอสมควร แต่ก็เป็นงานแต่งที่เราทั้งคู่ happy มากๆ เราได้งานเด็กในแบบที่เราอยากได้ คนที่มางานเด็กก็ชมว่าสนุก เมากันเละเทะไปหลายคน มีแค่เรื่องอาหารที่ดูเหมือนจะน้อยไปนิดและเราเพิ่งจะรู้ทีหลัง (ไม่รู้ว่าทำไมโรงแรมทำอาหารมาไม่พอ เพราะแขกก็มาไม่ถึง 150 คน)

ส่วนงานผู้ใหญ่ก็เป็นพิธีการตามธรรมเนียมที่ผู้ใหญ่อยากได้ปกติ พิธีการราบรื่น อาหารโอเค งานไม่เร่งรีบ ทุกคนมีเวลาได้พูดคุยกัน พ่อแม่แพรก็ชมมาว่าจัดงานออกมาดี เราทั้งคู่ก็ดีใจ

งานนี้เป็นงานที่ผมและแพรตัดสินใจรายละเอียดต่างๆ เอง เลือกสิ่งต่างๆ เอง เราแค่รับฟัง feedback จากผู้ใหญ่แล้วเราดูว่าเราจะปรับหรือไม่ เราไม่ตามใจผู้ใหญ่ทั้งหมด เพราะว่านี่คืองานแต่งของเราทั้ง 2 คน และเงินที่ใช้จัดงานก็เป็นเงินของเราทั้งคู่ล้วนๆ ก็มีบางครั้งที่ต้องต่อรองกับผู้ใหญ่กันไปบ้าง แต่ก็ผ่านมาได้ตลอด

อยากจะบอกว่า การจัดงานแต่งเป็น project scale ใหญ่มากๆ project นึง ถ้าใครไม่เคยทำ project management scale ใหญ่ ไม่เคยคุย vendor เอง ไม่เคยบริหารทีมงาน ไม่เคย compare ราคา หรือเตรียมเอกสาร brief งานคนต่างๆ ผมแนะนำให้จ้าง organize ทั้งหมดดีกว่า ไม่อย่างนั้นงานอาจจะไม่ราบรื่นนัก และก็จะรู้สึกเหนื่อย ทรมานมากๆ ผมเองทำ spreadsheet เพื่อดูแลงานทุกส่วนเยอะมากๆ มีเอกสารที่ต้องดูแล ต้องส่ง แก้ไขจำนวนไม่น้อย นัดวัน + follow up action จาก supplier ตลอดเพื่อไม่ให้พลาด deadline และต้องคอย update กับผู้ใหญ่ตลอดเวลาว่างานไปถึงจุดไหนแล้ว เราทั้ง 2 คนต้องช่วยกันประสานกับทีมงานและ stakeholders ร่วม 20 กว่าคนโดยที่ไม่มีประสบการณ์มาก่อน ถือว่าเป็นงานยากพอสมควร

หลังจบงานแพรก็ย้ายมาอยู่ด้วยกัน ผมเองไม่ได้มีอะไรที่เปลี่ยนแปลงมากนัก มีแค่ต้องตื่นเช้าขึ้นมากๆ เพราะแพรต้องเข้าไปทำงานแต่เช้า ส่วนแพรก็คงจะปรับตัวเยอะหน่อย เพราะเหมือนย้ายบ้านใหม่ ก็ค่อยๆ ปรับตัวกันไป

ยังไม่มีแพลนไป honeymoon ไว้วางแผนอีกที และก็ยังไม่ได้มีแพลนจะมีน้องตอนนี้ ขอไปเที่ยว กู้คืนชีวิต lockdown ช่วง covid 2-3 ปีนี้ก่อน

One day, the team was in the room to discuss fancy ideas of how we can change the system, and how we can utilize amazing modern technologies. Someone shared their own experiences about the best way to achieve the migration without causing too much pain, burden, and issues to the team.

The system was just 3-tiers monolith architecture — Mobile app, API server, and DB. The team decided to move forward with microservices with a fancy horizontal scalable database, a cache server, and a centralized message queue for event-driven applications.

Woah, that's too many changes! Should you do that? Is that possible? Or how could we possibly make that? Let's find out.

More contexts about the migration

1. The API for the mobile app was developed a long time ago. it was evolved and did not fit well with the company's needs.
2. The new set of services will be developed with completely new technology and new API schemas. You can't reuse old codebases.
3. Some features were deprecated or removed from the user perspective but the code still exists. No one actually knew what was used or not. Digging through the code to gain understanding would take a lot of effort.

Things don't work well with the migration

Before we do any migrations, please make sure you migrated away from the following:

• DB-controlled ID (Auto incremental ID, UUID generated by DB, etc)
• Distributed DB transaction (Transaction that spans multiple DB instances)
• Database Foreign key

Migration goals

The migration might take months to years, depending on how complex it is. It's not an easy boring task. It's full of traps, sweat, and tears. Unfortunately, the system has to be migrated otherwise it will drag you down until the whole company dies. I will write some other approaches (both good and bad) at the end of this blog post, so you can learn and don't have to repeat the same mistakes.

We want the migration process to be:

1. Low risk – least issues, downtime
2. Repeatable – easy to follow, able to get the same result
3. Effective – not much waste, minimum effort, get value fast

We should treat the migration process to be much like the refactoring process. To achieve the 3 goals above, we must put some constraints at first, and after we completed the migration, all constrains can be removed and it should unlock the full potential of making any changes to the new system architecture.

There are 2 key constraints to consider here: the feature set and the API specs. Basically, the set feature and API specs of the new system must not exceed the existing system. Otherwise, this would be considered as feature development, not system migration. Let's take a look for examples.

• [NOT OK] Your order processing system has 5 states and the new system has 8 states.
• [OK] Your order processing system has 5 states and the new system has 3 states.
• [NOT OK] The old user API schema doesn't have “Age” field but the new schema has it
• [OK] The old user API schema has “full name” field and the new schema has “first name” and “last name” fields that can be extracted from existing “full name” data.
• [OK] The old product API has an image URL field as a string but the new schema has an image URL as an array of strings.

You see it. Keep the feature set and API specs not exceeding the scope of the existing system. And once the system is migrated away, hopefully, the new codebase and architecture would enable your team to make changes easily.

Migration steps

There are 6 stages.

1. Initial stage
2. Translation stage
3. Dual-write stage
4. Read-compare stage
5. Cut-off stage
6. Clean-up stage

For the Initial stage, there won't be much detail, so we'll go into detail about the rest of the stages.

Translation stage

The goal of this is to test new the API schema with the client. You create a new service with the technology you want. You implement a new API spec and translate it into the existing API. Then, migrate the mobile app to use the new API, test it, and release it.

In this stage, no database or persistent was developed. You just translate ugly-existing API to the new and clean API you want. Please keep in mind that this could be possible because you don't add any features.

The value you get from this stage is that

1. You test your new API design to see if that fits well with the client
2. You may adjust some UI in mobile to match the new experiences you want. You can test the new UI design with your customer and get feedback. If anything goes wrong, you can easily change it without a lot of wasted effort.

Dual-write stage

After everything is going well, then you can start implementing more on the writing side (insert, update, delete). Start by setup a database you want, then write some code to insert, update, and delete the data on the database when the API is invoked.

You shouldn't implement every table and deploy all of it at once. You should split the work into multiple chunks, each chunk should focus on some set of tables. Keep deploying it into production continuously. This allows you to test whether the DB is well-suited to your need. Also, use feature flags for enabling and disabling the write into the new DB at the runtime (see the code sample in the section below).

Inserting records should be fine in all cases. Some old records that hadn't been inserted by the new system might be missing during the update or deletion. You can ignore those errors for a while and focus on the correctness of the newly created data.

Do not fetch the data from the new DB for returning to the client yet because it might not be complete or correct. Let it runs on production for a couple of days, monitor for any issues, fix it, and then you're good for the next step.

If anything goes wrong with your design or your data in the new system, then you can simply reset the DB and redesign it again. It's low-risk because the data hasn't been used by the client.

A common mistake is to start working on the reading side first instead of the writing side. This will hold you back because have to share the DB, keep it to be compatible with the existing system, do massive DB migration which uses a lot of time, and find out that it's very hard to shut the DB down during the clean-up stage.

Another common mistake is coupling the new system with the existing one. For example, after you insert a record into the new DB, then you use the result to update the existing system via its API. This is not the result you want because you need to remove the existing system without changing the implementation of the new one. Make sure those 2 systems don't know each other.

Read-compare stage

The prerequisite in this stage is you need to back-fill the data on the new system. From the previous stage, not all the data are available on the new system. Now, you must find somehow to migrate it. Examples of methods could be by writing DB export & import or writing a script to invoke an endpoint on the new system to set up those data.

Then, you should compare the result of all responses back to the client. Log all the records that don't match. Fixes the mismatched data and fixes the bug that causes it. Wait until the system is stable and almost has no issues.

All of the comparisons must be controlled under the same feature flag.

You could write a feature flag and flow controls like pseudo-code below:

func someApiHandler(request, response):
    stage = featureFlag.get("migration.someApi", default="translation")
    if stage in ["cut-off"]:
        result = callNewApi(request)
    if stage in ["translation", "dual-write", "read-compare"]:
        result = callOldApi(request)

    if stage in ["dual-write", "read-compare"]:
        newResult = callNewApi(request)
    if stage in ["read-compare"]:
       compareResponseAndLogIfNotMatched(result, newResult)

    return result

Cut-off stage

At this point, all bugs should be fixed. All response data should be matched. Performance, availability, and reliability should meet your expectation. You can simply switch the feature flag to stage “cut-off”. Be careful because, at this point, you can't turn it back. If anything is broken, you have to do a hotfix.

You should take a look at the existing system to see if there's any traffic going there. Does it have any load? Where is the source of the traffic?

Clean-up stage

You're free to destroy the existing system and remove the migration code on the new system. Now, you are in a better world with a shining bright future. You can add many features you want and hopefully, the new code and the new architecture could enable you to achieve and unlock your business goals faster.

As you may see, the migration code is quite generic which you can develop as a generic migration proxy that can route an API call to different versions of backends. This also helps you eliminate code clean-up effort in the last stage. I don't know if there is any open source but hope someone will develop it.

Other approaches that may work or may not

I've seen system migration attempts using these patterns. Some of it work in some context. I sorted it by the most possible approach to the lease possible approach. I still recommended the pattern above and please don't use the below if you don't know what you are doing.

1. DB synchronization with some down-time during the cut-off

You can use some tools like AWS DMS to synchronize DB changes. When the date has come, you simply shut down all the services and up with the new DB.

This could work for simple migration such as splitting the database. This pattern also only has a couple of steps to do which require a small amount of effort.

2. Modularize the codebase by refactoring, then splitting the deployment

If you can't make the code to be very modular with very low coupling, it might be impossible to split it into services. The idea is simply to only allow those modules to communicate with each other using only basic data types such as DTO and primitives. Do not allow them to share the same ORM model or use shared memory.

After the code has been refactored, you can make a copy of its deployment and split the traffic. You may need an API gateway for routing and aggregation responses from different services.

The downside of this approach is that it requires you to refactor all the code (both used and unused) which takes a huge amount of effort to understand all corner cases of the existing system.

3. DB synchronization with reading endpoints first

It's similar to #1 except the new API service will be implemented with reading endpoints first. This may sound OK to you but it turns out to cause problems later.

• Tools like DMS will make a conflict write when you want to start implementing writing endpoints
• DMS might cause issues from time to time such as synchronization lag, lost write, etc.
• Dependency between systems is cyclic which makes it very hard to fully migrate the system.

4. Rewrite from the ground up and migrate later

This approach starts by developing the new system with your desired architecture, data modeling, APIs, etc. Then, try to find a way to migrate both DB data and API calls later.

It creates an illusion of making progress because you can say that the new system is developing and features are implementing. We're approaching the target. But, actually, you don't deliver any value to users at all.

It is also very hard to create a plan to migrate the data from a messy database to the new one while the new database also requires more newly data input from users.

TL;DR: Acquiring skills by doing the real job. Always keep looking for more challenging tasks, projects, and expand scopes. Asking someone more expert to be your mentor and learn from them.

What's wrong with the way of learning

I have done some experiment about knowledge sharing. I shares knowledge, interesting topic, trends to the team regularly (e.g. weekly or bi-weekly). Here's what I did and observed.

• The knowledge that has been shared is not being use soon.
• The team understand the idea at the sharing moment.
• The team still told me that they understand even if the piece of knowledge is a bit of abstract. For example I shared about a strategy to write test that heavily inspired from functional programming.
• 3-4 weeks later, there's a task that suits to use the idea shared previously. The team just forget it so I have to share again.
• I collect feedback which told me to give more concrete example. I did it but the result is the same, they cannot actually use it.
• I know more about the subject that was shared because I need to prepare it but I believed the team won't because they just listen to it.
• What I shared mostly based on my own experience. I use it to do the real job, see the result, sometimes if it doesn't work then I just throw it out.

From the observation, knowledge sharing by just listening from expert won't work. The listeners are able to learn the concept but they are not acquiring skills into the level of being able to really use it.

In order to finish a piece of work, the person has to have an ability to demonstrate the skill, adapt, and solve an any unexpected problem. You can't swim by reading from books.

Your career cannot be advanced if you are only able to talk about skills. You have to done something and it is required the skill.

What to do instead?

Instead of learning like a school where a teacher gives a lecture, we can learn a new subject just-in-time or on-the-job. This is the best time for a person to concentrate on the subject and put thoughts and creativities in order to finish the job.

Everyday, you and your manager have to maximize the learning by assigning a task which have to balancing between practicing a person's skills to become an expert vs expanding knowledge in a new area.

For example, if you want to become a solution architect, you and your manage can work together with backlogs and let you explore different solutions, do proof of concept with a clear goal of the task. You can also get mentor by another solution architect in your company or work with manager on what he/she is expecting to see. Another example is if you are a web developer and want to learn more about mobile development, you can start working on mobile bug fix and take more challenges as you progress. You can also pairing with a mobile engineer in your team or asking for learning materials support from your company.

I would like to give a tips on learning from materials here: reading is faster than watching a video and don't learn it all, just learn enough for you to do the work. You should also allocate more free time to learn deeper in the subject.

After you have learned a new subject, you should also give a presentation to the team. The goal here is not only about let the others learn from you but it's about communicating what you did and improve your understanding on the subject by thinking in a different perspective.

You can't do it alone

With this way of learning, you have to incorporate with you manager about your goals. The company also has to have tasks that align with your goals as well — if you want to become a mobile engineer but the company is only doing a website, you'd better looking for a new job.

Starting by have a clear picture of skills you want to acquire/learn, then you can optimize your learning. If you don't have a skills list, you should talk with experts who can paint a clear picture so you can choose you own journey.

Hope this help.

I've talk with many people — engineers in my company, candidates in interview sessions, meetups, etc. They are often excited about new technologies, frameworks, tools and eager to learn, try, and talk about it. They may listed those tools as what they have experiences in CV. This is good but I think that over the half of those people are “tools' user” — who know how to use tools but don't understand it deeply.

Complexity

There's types of task's complexity that engineer will have to solve. CRUD or defined business workflow maybe classified as “Clear” so any engineer can simply write a program in a very straight forward way and this type of task is suitable for junior level.

Next is “Complicated”, an engineer may received a customer problem and asked to solve it. It also could be a technical challenge. The solution is not identified yet. The problem itself is solvable and feasible in theory. For example, scaling the system to handle more load, or in business context which a coupon quota is overused somehow. This type of task is suitable for senior level.

I won't go into more types here but I hope you can see what will happen when task is more complex.

Dots & connect the dots

In order to solve more complex problem, engineer has to use more knowledge and has ability to mix & match many things and come up with a solution.

Dots represent knowledge. Connect the dots is a process of utilizing knowledge and creating a solution that could solve a problem.

In order to increase ability to solve problems, it's simply to increase more dots as much as possible and practicing to connect those dots together so one can generate many new possible solutions.

For tools' users, their dots are limited — even if they know a lot of tools but those knowledge are quite shallow. It's hard to use across different domain because tools are tend to be specific for some use cases. Underneath those tools, there's layers of knowledge, techniques, and principles to be acquired — which are more fundamental and more reusable across different domains.

Critical thinking

When you're asked “What's happened when you open a website?” and your answer was “The browser send a request to server, received a response back, and render it.”, you're not think critical enough. You also may be asked “Why Kafka is so fast?” and the answer was “Because everyone said so.”, it's not a critical thinking.

In order to think critically, you have to tear it apart, think finer in every piece, go deeper more into detail, asking why again and again, until you arrived at the atomic piece of knowledge that cannot be split anymore — the first principle. This is how anyone should learn about anything. In this way, you will acquire much more dots than before.

When solving a complex problem, divide & conquer is a common technique used which break down a problem into smaller problems that easier to solve. It's kind of the same way of critical thinking. If you want to apply critical thinking into problem solving, you should look closer into a problem, identify any detail out of it, tear it apart into many pieces, dig down inside what's seem to be magic or abstract, and try to arrive at the first principle.

Wrap up

Skills are required for growing up to be senior or higher. The higher level you are, the more complex problem for you to solve. The ability to solve more complex problem are coming from ability to think more critically, how many dots (knowledge) do you have, and how you can connect those dots to create solutions that solve the problem.

Again, those abilities need to be practice and take time to acquire. Don't be rush. Asking yourself if today do I acquire any more dots? do I generate new ideas? do I think critical enough? do I arrive at the first principle? How can I go deeper to hit first principle?

Talk with someone more expert will speed up the learning — because they can think more finer than you.

Hope this help.

#careers

I'm going to be a stereotype here. I'm pretty sure it won't cover all the cases, it’s just for simplicity and I hope that it should cover at least 70% of the cases.

I divided the problem into 2 sub-problems: Lack of skills and Lack of scope.

Each of these problems could be fixed independently. I'll write more about what I believed a learning process should be. The important thing that you should know is fixing these problems is not a sequential, but it is a cycle to fix a little bit of each sub-problem many times.

Lack of skills

This problem is well-known among software engineers. Everyone wants to be smart, full of wisdoms, or even a 10x engineer. There's many way to increase your skill: read books, blogs, watch video, learn on the job, side projects, leetcode, mentored by expert, etc. These materials consumed are usually focusing on technical knowledge: programming language, scaling, performance, design, tools, etc.

The missing piece here is the other side of technical knowledge which I called soft skills (It isn't the same commonly known soft skills). The sample of soft skills are: project management, effective communication, effective writing, mentoring, inter-personal skill, problem solving, critical thinking, outcome-focusing, etc.

Without the soft part, all you have is an engineer who's waiting for someone telling you “Hey, this is your ticket with full of requirements and if you can check all the boxes in the ticket then everything will work as planned”. It's like a ticket bashing — who can clear tickets so fast, alone, and doesn't account for anything.

I tend to find engineers focusing more on the hard-skill and pay a little attention to soft-skill. I believed because hard-skill is in your power to control but soft-skill need someone else to practice with.

Even if you know that you need to improve soft-skill, it still lack the way to improve it, for example, project management — you cannot practice it alone but you have to actually do it. This issue creates inequality, if you are chosen to do it then you have more opportunity than the other. The same project won't come back again for the others to practice, only a newer project that is harder. This is a vicious cycle that make the gap wider.

Lack of scope

What I mean by scope is below:

• How much you have to be responsible for?
• What's the size of your tasks/projects that you’re accountable with?
• How many engineers you have to work with and influence?
• How many people in organization you have to work with and influence?
• What's the coverage in level of people you have to work with, starting from senior management to the frontline?

All of scopes here is relatively compared among employees in the company, so it can't compare across company.

Let's be specific.

You are an engineer who responsible to complete a simple bug fix assigned by the other engineer and the ticket has full of detail, solution, everything is clear and concrete. In this case, your scope is less than the one who create a ticket for you.

You are an engineer to support ~10 of micro-services. These services are in maintenance mode. You have to keep watching its health, answer inquiries from other engineers. Compare with someone else who responsible to develop a new system which is very critical to the business. It's life or death. Your scope might be less than the other.

You are an engineer who responsible an end to end of a product life cycle. So you talked to all stakeholders, create a plan, review code, monitor its health, and be an on-call. Comparing with someone work in a team, there's product owner (PO) who try to give a concrete requirement and when that engineer have a question, the PO will find answer for him. You might have larger scope comparing to the other.

So, you can think of scope as a circle of responsibility, criticality, people connection, and influential. How large are your circle? How can I increase it? It has to be increased in all angle, otherwise it's not a circle anymore.

Fixing these problems is a cycle

You cannot learn all soft and hard skills before you increase your circle. And you can't increase your circle if you don't have enough skills, otherwise you will lose trust.

The thing is you should increase your circle bit by bit and learn it along the way. Have I done good enough? What else can I improve?

It takes time and you can't rush it.

The only problem left unsolved here is can we create equality to all employee in a company so that everyone will have the same opportunity to grow? I believed, maybe, it's the hardest or impossible to solve.

#careers

There's a problem with keyboard, which at first, I think the laptop might have a defect from manufacturer but it only happen when I'm using on Linux. I was trying to plug external USB keyboard after I installed Linux and It's fine.

I search through internet and found this thread. Turns out it was a bug in linux kernel with new AMD Ryzen platform. Somebody who use Arch linux can apply patch by themselves but for me I use fedora so I have to find a way.

A patch has been submitted to mainline here and here. Right now, I think I just need to install kernel from the mainline.

I add Fedora Kernel Vanilla Repository and follow the instructions. I put these commands:

curl -s https://repos.fedorapeople.org/repos/thl/kernel-vanilla.repo | sudo tee /etc/yum.repos.d/kernel-vanilla.repo
sudo dnf --enablerepo=kernel-vanilla-mainline update

It installed kernel 5.19.0-65 but in this version, there was no new patch yet.

I look around to see if there's a repo or a way to install from latest git of kernel but I can't find any. So I decided to compile the kernel by myself from this guide.

sudo su
mkdir -p /usr/src/kernel/linux-next
cd /usr/src/kernel/linux-next
git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git .
make oldconfig
make bzImage
make modules
make modules_install
make install
reboot

The custom kernel build takes almost 2 hours and the problem was solved. I'm happy with Fedora 36 and this laptop.

Config needs restart to be updated, static, stored in file, override by env variable, small number of config

Example: DB config, server listen port, remote host location

Feature flag

Feature flag and settings can be changed at runtime without restart or down time. Both are similar but I want to draw a bold line separate them.

Feature flag is temporary, has to be clean up or removed someday in the future. It is about roll out, release, use context to decide who, when, where, which version to enable which can be apply to users partially, or globally. It is usually controlled by engineers, or technical operation team.

Setting

Setting is permanently. It has been designed to be in the code without creating technical debt.

It likes a feature which has a real user use case for example to adjust behavior of the system.

It should be safe to be uses, changes, enables, disables in numerous times. It should be test throughout.

Any feature flags that has been rolled out and stable, can be transitioned to setting such as kill switch.

Example: Site title, User role & Permission, Look & feel, Content to be shown

Below is a comparison table:

#codestyle

I would like to write in more detail about where to put log, the benefits, disadvantages, and how to mitigate that.

I want to put a context that we're developing web services, whether public access or internal use. No matter what protocol is used, HTTP with JSON, gRPC, Thrift, etc. I think my guide may adapt to all of these kinds of technology.

So, where to put logs?

1. Incoming requests – aka. access log

Usually, there are two types of requests: read and write. You can write a middleware, interceptor, AOP, or whatever is suitable for your situation and log all necessary data such as HTTP request data, response status, process time, caller information, controller and handler name, etc.

This is very useful for many of situations:

• To monitor anomaly of 4xx or 5xx HTTP status
• Investigates on which endpoint is slow for which user
• Who perform what action and when

Someone might take it to a very extreme by constantly logging the entire request and response body. Well, it depends on context and company, but I suggest logging those only if there is a serious error such as HTTP 500 so that it won’t violate user privacy, reduce security risk, and save the cost.

2. At the end of handlers that are not read-only

You should put a log to record an event (what happened) at the end of every handler that is not read-only, such as POST, PUT, PATCH, DELETE, or depending on the RPC technology you are using.

I don’t suggest putting it on read-only handlers because most of the systems are very read-heavy, and you already have an access log from above, so it doesn’t add much value to do that on all handlers.

What should be logged on those non-read-only handlers?

• Who performs the action
• Name of the event, this should be unique across all of your systems
• Request or data of the action
• Result or data of what have been changed
• Any metrics, numerical values

In order to log so much of those information, structured log such as JSON is a must.

The benefit of doing this is building real-time business metrics to show to all stakeholders. It is pretty exciting to put data, visualize, and see the impact of what you did in real-time.

3. When handlers got an error or exception

Access log with response status is not enough for investigation when there is an error or exception on a request. Handling errors and putting a log in each handler is very helpful to know what's wrong with that request.

You should log an error message, stack trace, why the error happens, on which block of code. Don't write a generic error log or catch a generic exception because you won't get enough detail to understand the problem.

4. When the system calls to external dependencies

In a microservice architecture, it is common that your system has to invoke an API call to other services. You may remember that there are 2 types of requests: read and write. If you send a request to get the data back without any side effects, it is a read, or you may call a query request.

As your system is a client who calls to another service, I suggest you write a log for all requests being sent out from your service. Again, the information to be logged is quite the same as the access log.

There are disadvantages to logging every call, especially for the query request type. The most significant drawback is overhead. Around 80% of requests are query requests; logging all of them will cost you the storage, compute power, and increased response time. In this case, metrics are a better solution as you can count the number of requests, duration histogram.

By the way, if a query request has got an error, I still suggest logging it for investigation. You may also apply a log sampling or rate limit to mitigate the log flood problem in case of 100% of requests are errors.

5. After the system did something important

Even though you had event logging at the end of handlers, there is a missing gap here such as a cron job, watchdog, housekeeping. Those are still not logged and in many cases, it is useful to know what the system does so you can correlate the event in case of something bad happened.

I had an experience on a system where cron jobs are running in the same process as the web server. The application was deployed to many physical servers. Once it is time to run a cron, every server triggers a job simultaneously, which causes a sudden spike in system resources and database.

I'm lucky enough that once I take a look at the centralized log system around that time, it is so obvious that the cron job is a problem.

Here's a list of what should be log

• When a background job or cron job was started and finished
• Events related to database connection such as connection lost, failover
• Garbage collection event
• It's setting up something with other systems, e.g., declaring queue, registering to service discovery, configuration updates.

6. When you want to record what happened

You can log anywhere in the code, so don't limit yourself to logging only inside handlers. I usually log about security information, such as someone trying to login using the wrong password, requesting an OTP, delete a record without permission.

You can also log for audit purposes: database record with before & after, login success, email verified, etc.

This might sound a bit duplicate with No 2. but it is not. As a single request can perform many tasks, the log at the end of the handler will record an overall event. But this kind of log is more granular, so it records what happened within a single request.

Closing

I found that logging is more helpful than metrics when you need very detailed information, but it comes with writing, transit, processing, and storing costs. For a system under heavy load, you should reduce the number of logs by using metrics or sampling the logs. But for non-read-only requests, you should always write logs as you might get the benefit when investigating the problems and real-time business metrics for monitoring.

These guidelines on where to logs are what I think you should always do. By the way, feel free to put any log in any log level on the locations that it might be helpful for you.

#codestyle