บริษัท A...

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

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

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

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

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

So you want to migrate legacy systems that no one knows in detail and no one wants to touch it. That system might be very brittle, cause a lot of trouble, can't scale to handle the business growth, and your team doesn't want to deal with that anymore.

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.

This part in #careers, I will write about the way to effectively acquire skills which help accelerate your career progress. I wrote about my own progression framework, which consist of 2 major key points — skills and scopes that play a vital part of prohibiting or allowing anyone to grow.

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.

Tools

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.

This is going to be a very long post series in #careers. It started from a discussion among my engineering manager team as well as my observation to individual engineers. There's a challenge for anyone who don't know exactly how to advance their career. Even a company provides a guideline, some of them still struggle to actually make progresses.

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.

I've just bought a new laptop, Lenovo ThinkBook 13s Gen 4, which I think it's lightweight, with good performance (AMD Ryzen 7 6700u), last-long battery, and it's not too expensive.

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.

Related to Opinionated guide on how to write a log

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?

ผมพบว่ามีหลายวิธีที่จะ manage source code และ manage pull request (หรือ merge request) แต่ผมยังไม่เจอว่ามีใครเขียนรวบรวมไว้

ผมจะ focus ในเรื่องที่เกี่ยวกับ การ Approve code การ Run CI และการ Merge code

การ Approve code

การ review สามารถทำได้ทั้ง offline และ online เช่น

• review offline แบบ pair programming
• review offline แบบ mob programming
• review online ผ่านระบบ เช่น GitHub, GitLab

กฎเกณฑ์ในการ approve code มีหลายแบบที่สามารถเลือกใช้ได้ ไม่ว่าจะ review แบบ offline หรือ online เท่าที่ผมรู้จักมีประมาณนี้