Quần Cam Blog

Vô chiêu thắng hữu chiêu

Độc Cô Cửu Kiếm trong truyện Kim Dung lừng danh với chín chiêu thức dùng kiếm vô địch thiên hạ. Nhưng cô đọng lại chỉ có một nguyên tắc: “Vô chiêu thắng hữu chiêu”, hàm ý chiêu thức là chết, người là sống. Người luyện kiếm cần tinh thông kiếm pháp. Nhưng lúc đánh nhau thì quên đi những chiêu đã học mà đánh theo bản năng. Tới mình còn chưa biết bản thân xuất chiêu gì tiếp theo, thế éo nào đối phương đỡ được.

Developer thiệt ra cũng không khác nhiều lắm. Bạn điêu luyện nhiều môn code nghệ. Bạn nắm vững mọi design pattern. Bạn hiểu tận tường ngóc ngách của Computer Science. Hơn thế nữa bạn còn thấm nhuần triết học Mác Lê. Nhưng khi làm việc bạn trở thành thợ đụng. Đụng trúng cái nào làm cái đó. Tùy cơ ứng biến, không lần nào giống lần nào.

doc-co-cuu-kiem

Có thể bạn đã nghe ở đâu đó nhưng cho tui lặp lại. Bạn được thuê vào để tạo ra giá trị thặng dư cho doanh nghiệp. Tư bản mà, lợi nhuận với nhuận lợi thôi. Hèn chi mãi mãi trong cơn giãy chết .

Ví dụ như đầu bếp. Nhà hàng thuê đầu bếp để nấu ăn nhưng mục đích là phục vụ thực khách kiếm tiền. Nấu ngon nấu dở không quan trọng bằng có lời. Mấy chỗ bán phở bên Tây nấu dở ẹc mà vẫn đông khách đó thôi. Chủ yếu là đầu bếp họ biết giải quyết vấn đề bằng cách nấu theo khẩu vị Tây. Tây không ăn mắm thì họ không bỏ mắm. Tây thích ăn khoai tây thì họ bỏ khoai tây. Tây cũng không đặt nặng vấn đề bún với phở khác thế nào.

Developer cũng thế thôi. Doanh nghiệp thuê thân xác bạn ngày 8 tiếng để giúp họ kiếm tiền. Họ có các vấn đề kinh doanh cần bạn giúp họ giải quyết. Giải quyết bằng cách nào thì tùy bạn. Bạn có thể viết code. Bạn có thể xóa code. Thậm chí dùng chiêu “Càn khôn đại na di” để đùn việc sang người khác, nhưng nhớ đọc kĩ hướng dẫn sử dụng trước khi dùng. Tóm lại, cách bạn giải quyết vấn đề không quan trọng bằng bạn giải quyết được vấn đề.

bi-kip

Gần đây gã hàng xóm The Full Snack có viết bài về problem solving, tui thấy có khá nhiều đồng cảm.

Bài viết không ngắn cũng không dài. Nhưng hắn ta nói công việc hằng ngày của một developer bao gồm các bước sau:

  1. Tiếp nhận và hiểu vấn đề.
  2. Phân tích vấn đề.
  3. Lên phương án hành động.
  4. Thực hiện.
  5. Rút kinh nghiệm.

Nhiều khi tui còn thấy công việc chính của developer chỉ gói gọn trong … bước 1 và 2. Viết code đương nhiên là vui. Nhưng nó chỉ là một cách bạn giải quyết vấn đề. Mà để giải được vấn đề, bạn phải hiểu vấn đề trước đã.

Hơn nữa, nếu làm bước 1 và 2 đủ tốt, nhiều vấn đề có thể được giải mà không cần phải viết code. Có thể bạn nghĩ Quần Cam chém gió. Ừ thì tui đang chém gió mà. Mà thôi để tui cho bạn ví dụ.

Gần đây team tui nhận được một yêu cầu từ phòng A. Họ muốn build một cái web tool tự động set up đơn hàng. Viết tool mới, nghe là thấy thú vị rồi. Nhưng lùi lại một bước, cái họ muốn giải quyết với cái tool đó là gì.

Phòng A không có developer vì công việc của họ không đủ nhiều cho một developer toàn thời gian. Mỗi lần có đơn hàng, họ sang phòng B “nhờ” anh C giúp. Mang tiếng là “nhờ” nhưng thiệt ra là “biểu”. Việc setup khá đơn giản chỉ tốn khoảng 5 phút nhưng anh C không vui lắm và phàn nàn, vì lần nào họ cũng nhờ đúng ảnh. Vì vậy phòng A muốn build tool để khỏi mang tiếng nhờ vả nữa.

Dự kiến build tool sẽ tốn khoảng 2 tuần, vị chi là 80 tiếng. Lịch sử phòng A cho thấy mỗi tháng họ có khoảng 5-6 đơn hàng, tính ra tốn 30 phút cho việc setup. Để bù lại được số giờ bỏ ra build tool, họ phải dùng nó trong hơn 10 năm. Vì vậy build tool thoạt nhìn có vẻ hợp lý, nhưng thực tế là công ty lỗ vốn.

A là cần câu cơm của công ty, bằng mọi giá đơn hàng phải được thực hiện. Cuối cùng cách ổn thỏa nhất là toàn bộ team tui “xoay tua” giúp họ. Như vậy, đơn hàng vẫn được thực hiện, anh C không còn là người duy nhất, công ty vẫn có lời. Bạn thấy đó! Vấn đề đã được giải quyết mà không phải code thêm cái quái gì hết!!

Bài viết sẽ giúp tôi tăng lương thế nào?

Bài viết mặc dù nói vòng vo tam quất, nhưng như thường lệ, nó không giúp bạn tăng lương.

Cái chính tui muốn nói là không nên tiếp cận vấn đề bằng code. Developer phải code là đúng rồi. Nhưng code đúng nơi đúng chỗ. Cái nào cần mới code. Đôi khi không cần code mà giải quyết được vấn đề cũng vui.

Cũng không nên “ép” vấn đề vào code. Khi bạn rành về một tool nào đó, rất dễ để bạn rơi vào cái bẫy dùng tool đó để giải quyết mọi vấn đề. Giả dụ bạn rành về Ruby on Rails và muốn viết blog. Việc đầu tiên nên làm không phải là code một cái blog bằng Rails, mà tập trung cho nội dung blog. Còn tool tạo blog thì bạn có Wordpress, Nabo, Ghost. Đủ thứ trên đời.

Vô chiêu thắng hữu chiêu! Như cao nhân Lý Tiểu Long từng phán:

ly tieu long

“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.” - Bruce Lee


NGUY HIỂM! KHU VỰC NHIỀU GIÓ!
Khuyến cáo giữ chặt bàn phím và lướt thật nhanh khi đi qua khu vực này.
Chức năng này hỗ trợ markdown và các thứ liên quan.

Bài viết cùng chủ đề

Giả định và Suy nghĩ khoa học

Trong cuộc sống hằng ngày, ta hay đưa ra những giả định và cho rằng nó mặc định đúng mà không kiểm chứng, nhưng chúng sẽ khiến bạn trông không thông minh lắm. Bài viết giới thiệu về cách suy nghĩ khoa học để tránh đưa ra các giả định.

[Web nhà nghèo] Tui đã viết tính năng “chém gió” như thế nào?

Trình bày cách tui xây dựng chức năng comment cho blog thay cho Disqus mà không tốn một đồng nào cả.

Chuyện uống trà

Có lẽ bạn chưa biết: Uống trà thay cho cà phê đã trở thành một thói quen hằng ngày của tui trong suốt một năm qua.