ทำไม Bitkub ทำให้ผมเป็น Dev ที่ “เหนือกว่าค่าเฉลี่ย”

ผมเชื่อว่า Junior Dev หลายคนคงเคยทำแบบเดียวกับผมทำในอดีต

ซื้อ Course บน Udemy, ทำ Side Project, ฝึก LeetCode ทุกคืน แล้วก็นั่งถามตัวเองว่า “ทำไมถึงยังไม่รู้สึกเก่งขึ้นสักที?”

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

หลายปีที่ผ่านมา Junior Dev หลายคนถามผมว่าทำยังไงถึงจะเติบโตได้เร็ว คำตอบที่ได้ยินบ่อยที่สุดจากคนอื่นคือ “ซื้อ Course เพิ่ม” “ทำ Side Project” “ฝึก LeetCode” ซึ่งผมไม่ได้บอกว่ามันผิด แต่มันไม่ใช่คำตอบทั้งหมด

บทความนี้ไม่ได้เขียนเพื่อบอกว่า Bitkub คือที่ที่ดีที่สุดสำหรับทุกคน แต่เขียนเพื่อเล่าว่าที่นี่สอนอะไรผม และมันทำให้ผมรู้ว่าควรร่วมงานกับบริษัทแบบไหนในอนาคต

ทำไม Bitkub ถึงไม่เหมือนบริษัทเทคทั่วไปในประเทศไทย

ก่อนจะเข้าเรื่อง ขอเล่าให้เห็นภาพก่อนว่า Bitkub ต่างจาก Company ทั่วไปยังไง

บริษัทส่วนใหญ่มักเป็นอย่างใดอย่างหนึ่ง — Startup ที่เน้น Speed และการเติบโตให้เร็วที่สุด หรือ Financial Institution ที่เน้น Stability และความระมัดระวังสูงสุด ทั้งสองแบบมีอยู่มากมาย แต่บริษัทที่เป็นทั้งสองอย่างพร้อมกันนั้นหายากมาก

แล้วก็ต่างจากธุรกิจอื่นตรงที่ตลาด Crypto ไม่เคยหยุด ร้านอาหารปิดตอนดึก ตลาดหุ้น SET ปิดตอน 17:00 โรงแรมยังมีช่วง Low season ที่ทีม IT หายใจได้บ้าง แต่ Crypto trading วิ่งอยู่ตลอด 24 ชั่วโมง 7 วัน 365 วัน ไม่มี Maintenance window ที่ปลอดภัย ไม่มีเวลาที่บอกได้ว่า “ตอนนี้ไม่มีใครใช้งาน” ทุก Deploy ที่คุณทำ เกิดขึ้นในขณะที่มีลูกค้ากำลังเทรดอยู่เสมอ

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

สามอย่างนี้รวมกัน — Startup ที่ต้องการความเร็ว, ตลาดที่ไม่มีวันปิด, และสินทรัพย์จริงที่อยู่ในระบบตลอดเวลา — สร้าง Environment ที่ผมไม่เคยเจอที่ไหนมาก่อน และในบทความนี้ผมจะเล่าให้ฟังว่ามันเปลี่ยนวิธีคิดของผมไปยังไง

1 — ที่ Bitkub มูลค่าความเสียหายของหนึ่งความผิดพลาด “ไม่มีลิมิต”

ลองเปรียบเทียบให้เห็นภาพ

ถ้าคุณทำงานที่บริษัท Food Delivery หรือแอพจองโรงแรม แล้วเกิด Bug ทำให้ลูกค้ากด Cancel order ไม่ได้ ผลกระทบสูงสุดที่เกิดขึ้นคืออะไร? User experience แย่ลง บริษัท Compensate Voucher หรือเงินคืนสัก 200–1,000 บาท แล้วก็จบ เพราะยอด Order ของ Food Delivery มักไม่ได้สูงมากนัก

แต่ที่ Bitkub ลูกค้าสามารถวาง Order ซื้อขาย Crypto ด้วยยอดหลักล้านบาทในครั้งเดียว

ลองนึกภาพว่ามี Bug ทำให้ลูกค้าที่วาง Order ยอด 1,000,000 บาทกด Cancel ไม่ได้ หรือกดได้แต่ล่าช้าไปแค่ 1–2 ชั่วโมง ในช่วงเวลานั้น ตลาด Crypto ที่ไม่เคยหยุดพัก 24 ชั่วโมง 7 วัน อาจวิ่งขึ้นหรือลงไปหลายสิบเปอร์เซ็นต์แล้ว และไม่มีสูตรสำเร็จว่าจะ Compensate ลูกค้ายังไง เพราะมูลค่าความเสียหายแทบไม่มีเพดาน

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

ใน Crypto Exchange ทุก Millisecond มีความหมาย การที่ Order ถูก Process ช้าลงแม้แค่ไม่กี่วินาที หมายความว่าลูกค้าอาจ Match Order ในราคาที่ต่างจากที่ตั้งใจ หรือพลาด Opportunity ที่เกิดขึ้นและหายไปในชั่วพริบตา ความเสียหายไม่ได้เกิดจากระบบล้มเหลว แต่เกิดจากระบบที่ทำงาน “ไม่เร็วพอ” เท่านั้น

Environment แบบนี้บังคับให้คุณคิดก่อนทุกครั้ง ไม่ใช่เพราะมีใครมาบังคับ แต่เพราะคุณรู้ดีว่าถ้าพลาด มันไม่ใช่แค่ Ticket ที่ต้องแก้วันพรุ่งนี้ แต่คือเงินจริงๆ ของลูกค้าจริงๆ

ผมบอกได้เลยว่าความรู้สึกนั้นเองที่ทำให้ Dev ที่ผ่านสิ่งแวดล้อมแบบนี้มา “มีวิธีคิดที่แตกต่างออกไปอย่างสิ้นเชิง”

2 — ที่ Bitkub การคำนวณต้องแม่นยำในระดับ “0.00000001”

มีช่วงหนึ่งที่ระบบแจ้งเตือนขึ้นมาว่า ยอดเงินในกระเป๋าของลูกค้าไม่ตรงกับยอดที่ Reconcile จาก Transaction log

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

หลังจาก Debug อยู่นาน คำตอบที่ได้กลับมาเรียบง่ายจนน่าตกใจ มันคือ Float 🔥

// ดูเหมือนถูก แต่ผิดจริง
price := 0.1 + 0.2
// price = 0.30000000000000004  ← ไม่ใช่ 0.3

// แบบที่ถูกต้องในระบบการเงิน
price := decimal.NewFromFloat(0.1).Add(decimal.NewFromFloat(0.2))
// price = 0.3  ← ถูกต้องเสมอ

ในคอมพิวเตอร์ Float ไม่สามารถแทนทศนิยมบางตัวได้อย่างแม่นยำ ในงานทั่วไปความคลาดเคลื่อนเล็กน้อยแทบไม่มีผล แต่ใน Matching Engine ที่คำนวณ Transaction หลายแสนครั้งต่อวัน ความคลาดเคลื่อนเล็กๆ สะสมกันจนกลายเป็น Diff ที่ Reconciliation System ตรวจจับได้ นั่นเป็นเหตุผลที่ Matching Engine รุ่นใหม่ของ Bitkub ถูกเขียนขึ้นมาใหม่โดยใช้ Decimal แทน Float ในทุกการคำนวณที่เกี่ยวข้องกับเงิน

ระบบ Trading ยังซับซ้อนกว่านั้นอีก

แต่ละ Cryptocurrency มี Precision ที่แตกต่างกันโดยสิ้นเชิง BTC ใช้ทศนิยม 8 ตำแหน่ง ส่วน THB ใช้แค่ 2 ตำแหน่ง และราคาต่อเหรียญก็ต่างกันมหาศาล BTC อยู่ที่ประมาณ 70,000 USD ต่อเหรียญ ในขณะที่ Meme coin บางตัวราคาแค่ $0.00050646

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

3 — Bitkub เป็น Startup ที่ต้องการความรวดเร็ว แต่ก็ดัน “ยอมรับความผิดพลาดไม่ได้”

Bitkub เคยเป็น Startup company ซึ่งแน่นอนว่าต้องการ Speed อย่างมาก เพราะต้องการการเติบโตอย่างรวดเร็วเพื่อเอาชนะคู่แข่งในตลาด แต่ในขณะเดียวกันก็เป็น Financial Platform ที่ยอมให้เกิดความผิดพลาดไม่ได้เช่นกัน ซึ่งสองอย่างนี้ “ขัดกันโดยธรรมชาติ”

• ถ้าเราอยากได้ความรวดเร็ว เราต้องยอมให้เกิดความผิดพลาดได้บ้าง
• ถ้าเราไม่อยากให้เกิดความผิดพลาด เราต้องยอมให้การพัฒนาและ Deploy ช้าลง

แต่ Bitkub ต้องการทั้งสองอย่างพร้อมกัน — “เร็วและถูกต้อง”

Startup ทั่วไปบอกว่า “Move fast, break things” แต่ที่ Bitkub ถ้า break things หมายถึงเงินของลูกค้าหาย คุณจะไม่มีโอกาสได้ทำอีกครั้ง

ความเป็นจริงที่ผมเจอบ่อยมากคือ ฝั่งผู้บริหารต้องการให้ Ship ของให้เร็วที่สุด ซึ่งก็เข้าใจได้ เพราะตลาด Crypto เคลื่อนที่เร็ว คู่แข่งก็วิ่งอยู่ตลอดเวลา แต่ทีม Dev ก็รู้ดีว่ามีบาง Feature ที่ต้องได้รับ Review อย่างรอบคอบก่อน เราจึงต้องหาเหตุผลมาอธิบาย ไม่ใช่ต่อรองทุกครั้ง แต่รู้ว่าครั้งไหนที่ประนีประนอมไม่ได้

สิ่งที่ทีมพัฒนาขึ้นมาคือหลักการที่ใช้ตัดสินใจว่าอะไร Move fast ได้ และอะไรต้อง Slow down

Touch money = Slow down เสมอ

Feature ไหนก็ตามที่แตะยอดเงินของลูกค้า ไม่ว่าจะเป็น Wallet, Order หรือ Fee Calculation ต้องผ่าน Review รอบพิเศษเสมอ ส่วน Feature ที่ไม่เกี่ยวกับเงิน เช่น UI หรือ Notification ทำได้เร็วกว่า หลักการนี้ฟังดูง่าย แต่การที่ทีมยึดถือมันได้จริงในทุกสถานการณ์โดยไม่ยกเว้น “นั่นแหละที่ยาก”

Staging ไม่ใช่ Option แต่คือ Requirement

ก่อน Deploy อะไรก็ตามที่กระทบ Matching Engine หรือ Balance ต้องผ่าน Staging Environment ที่มี Real-world load ก่อนเสมอ ไม่มี Shortcut ไม่ว่า Deadline จะกดดันแค่ไหน คืนที่เราแก้บัค Reconcile กันถึงเที่ยง ส่วนหนึ่งก็เพราะบทเรียนแบบนี้นั่นเอง

มี List ของสิ่งที่ Trade-off ไม่ได้เด็ดขาด

Idempotency, Balance correctness, Order matching logic — อันนี้ห้ามรีบ ห้าม Cut corner ไม่ว่ากรณีใด ส่วนอย่างอื่น Negotiate ได้ การมี List แบบนี้ที่ทั้งทีมเห็นตรงกัน ทำให้การ Push back ผู้บริหารไม่ใช่เรื่องของความเห็นส่วนตัว แต่เป็นหลักการที่ทีมยึดถือร่วมกัน

หลักการ 3 ข้อนี้เรียบง่าย แต่ผมพบว่า Dev ที่ไม่เคยอยู่ใน High-stakes Environment มักไม่มี Framework แบบนี้ในหัว เพราะไม่เคยมีสถานการณ์ที่บังคับให้ต้องสร้างมันขึ้นมา

4 — Bitkub ทำในสิ่งที่ไม่มีบริษัทเทรดเจ้าไหนในประเทศไทยทำ “สร้าง Matching engine ของตัวเอง”

ลองถามตัวเองดูครับ คุณรู้จัก Slippage ไหม? รู้จัก Partial Fill? รู้จัก Wash Trade? รู้จัก Price-time Priority?

ถ้ายังไม่รู้ ไม่ใช่เรื่องแปลก แต่เพราะ Environment ที่คุณอยู่ไม่เคยบังคับให้คุณต้องรู้ต่างหาก

ขออธิบายให้เห็นภาพแบบคร่าวๆ

• Slippage คือความต่างระหว่างราคาที่คุณ “ตั้งใจ” จะซื้อ กับราคาที่ได้จริง มักเกิดเมื่อตลาดขาด Liquidity หรือ Order ใหญ่เกินกว่า Buyer/Seller ในตลาดรองรับได้ในทันที
• Partial Fill คือเมื่อ Order ของคุณถูก Match แค่บางส่วน เช่น คุณอยากซื้อ BTC 10 เหรียญ แต่ตลาดมี Seller ที่ราคานั้นแค่ 3 เหรียญ ระบบจะ Match ให้ 3 เหรียญก่อน แล้วรอ Match ส่วนที่เหลือในภายหลัง
• Price-time Priority คือกฎที่ตัดสินว่า Order ไหนได้ Match ก่อน ถ้าราคาเท่ากัน Order ที่เข้ามาก่อนได้สิทธิ์ก่อน เรียบง่ายแต่ Implementation ต้องแม่นยำอย่างยิ่ง
• Wash Trade คือการซื้อขายปลอมเพื่อสร้าง Volume ให้ดูสูง ระบบต้องมีกลไกตรวจจับและป้องกัน

ทีนี้ลองนึกภาพบริษัท Crypto ที่เป็นแค่ Broker — ส่ง Order ไปที่ตลาดอื่น แล้วรับ Response กลับมา Dev ในทีมนั้นเขียนโค้ดส่ง Request ไป แล้วก็รอผล โดยไม่ต้องรู้เลยว่าข้างในทำงานยังไง ไม่ต้องรู้ว่า Slippage เกิดที่จุดไหน ไม่ต้องรู้ว่า Partial Fill ถูกจัดการยังไง เพราะระบบข้างนอกซ่อนความซับซ้อนทั้งหมดไว้ให้

ตลาดหุ้นไทยอย่าง SET เองก็ซื้อ Matching Engine สำเร็จรูปจากบริษัทชั้นนำในสหรัฐ เช่นเดียวกับ Crypto Broker ไทยหลายเจ้าที่ไม่ได้สร้างตลาดของตัวเอง แต่เป็นเพียงตัวกลางที่ส่งคำสั่งต่อไปยังตลาดอื่น

Bitkub สร้าง Matching Engine ของตัวเอง

และผมได้ทำงานอยู่ในระบบนี้ ได้เห็นว่า History Consumer ทำงานยังไง ได้เข้าใจ Place-order และ Cancel-order Mechanism จากข้างใน เมื่อระบบมีปัญหา ไม่มีใครช่วยได้นอกจากทีมเอง เพราะเราเป็นเจ้าของทุกบรรทัดของมัน

ความรู้เหล่านี้ไม่มีใน Course ไหน และไม่มี Tutorial สอน มันได้มาจากการแก้ Production bug และการทำงานอยู่ใน Environment ที่บังคับให้คุณต้องรู้จริงเท่านั้น 💡

5 — Bitkub ทำให้ผมมี Security Awareness แม้ไม่ได้อยู่ในทีม Security

ผมไม่ได้ทำงานในทีม Security โดยตรง แต่การที่ Bitkub เก็บสินทรัพย์ Digital ของลูกค้าจำนวนมาก มันทำให้ทุกคนในทีมมี Security awareness ที่แตกต่างออกไปโดยอัตโนมัติ

เมื่อระบบของคุณเป็นเป้าหมายที่ Hacker ทั่วโลกจ้องอยู่ตลอดเวลา คุณจะเริ่มตั้งคำถามกับโค้ดตัวเองต่างออกไป ทุก Input ที่รับมาจาก User ถูกสงสัยก่อนเสมอ ทุก API Endpoint ถูกคิดว่า “ถ้ามีคนพยายาม Abuse อันนี้จะเกิดอะไรขึ้น?” โดยอัตโนมัติ โดยที่ไม่มีใครต้องมาบอก

Security mindset แบบนี้ไม่ได้เกิดจากการอ่าน OWASP Top 10 แต่เกิดจากการทำงานใน Environment ที่ต้นทุนของการมองข้ามมันสูงเกินไป

Bitkub สอนผมอะไร และคุณควรมองหา Environment แบบไหน

ทั้งหมดที่เล่ามาไม่ได้บอกว่า Bitkub คือที่ที่ดีที่สุดสำหรับทุกคน

แต่มันทำให้ผมรู้ว่า สิ่งที่ทำให้ Dev เติบโตเร็วที่สุดคือ Environment ที่มี Cost of Mistake สูง เพราะมันบังคับให้คุณคิดรอบคอบ ตั้งคำถาม และเรียนรู้จากของจริง ในแบบที่ Course หรือ Tutorial ไม่มีวันทำได้

ยิ่ง Cost of Mistake สูง ยิ่ง Environment บังคับ “คุณยิ่งเติบโตได้เร็ว”

ก่อนรับ Offer ครั้งต่อไป ลองถาม Interviewer 3 คำถามนี้

1. “ถ้าเกิด Bug ใน Production ขั้นตอนที่ทีมทำคืออะไร?” — คำตอบบอกได้ว่าทีมมี Engineering culture จริงหรือเปล่า
2. “Production Incident ที่เจ็บปวดที่สุดที่ทีมเคยเจอคืออะไร?” — ถ้าตอบไม่ได้ แสดงว่า Incident ไม่ได้ถูก treat อย่างจริงจัง หรือระบบเล็กเกินไปจนไม่มี Incident ที่น่าจดจำ
3. “ทีม Build ระบบหลักเอง หรือต่อ External Service?” — คำตอบบอกได้ว่าคุณจะได้เรียนรู้ข้างในระบบหรือแค่เรียนรู้ API

และลองถามตัวเองด้วย

ที่ทำงานตอนนี้ ถ้าคุณพลาด — มันเจ็บแค่ไหน?

ถ้าคำตอบคือ “ไม่เจ็บเท่าไหร่” นั่นอาจหมายความว่า Environment ของคุณกำลัง Protect คุณจากการเติบโต

ตัวคุณในอีก 3 ปีข้างหน้าจะขอบคุณที่คุณเลือก Environment ที่บังคับให้ดีขึ้น ไม่ใช่ Environment ที่แค่ทำให้สบายใจ ❤️

มาร่วมแลกเปลี่ยนประสบการณ์กันได้เลยนะครับ อยากรู้ว่า Environment ที่ทำให้คุณ Grow มากที่สุดในชีวิตการทำงานคือที่ไหน