Nhái Cốm Blog

I love you just the way you are


Leave a comment

10 mẹo phỏng vấn xin việc cho lập trình viên

Tác giả: Jack Wallens
Bài gốc: 10 job interview tips for developers

Lược dịch

Những buổi phỏng vấn xin việc không còn là nỗi ám ảnh khi bạn chợt nhận ra rằng mình không bước trên con đường một chiều. Người phỏng vấn đúng là người quyết định liệu bạn có phù hợp với công ty hay không, nhưng bạn cũng phải tự mình quyết định một vấn đề lớn: Liệu đây có phải là nơi thích hợp cho mình không? 10 mẹo dưới đây sẽ giúp bạn nhanh chóng đưa ra quyết định đó.

1. Vấn đề không phải chỉ là công việc (mà là cả dự án nữa!)

Đây là một vấn đề lớn cho lập trình viên. Bạn phải nhớ rằng mình không chỉ phỏng vấn để tìm một công việc mà còn để tìm một dự án (rốt cuộc thì đây là phần thú vị nhất). Thậm chí nếu công ty bạn phỏng vấn không phải là công ty lớn nhất, có uy tín nhất, bạn sẽ vẫn muốn cân nhắc những khả năng mà dự án có thể mang lại. Một dự án đặc biệt có thể kéo theo nhiều dự án lớn cũng như một tương lai sáng lạn hơn là việc chỉ đơn giản đồng ý ký vào hợp đồng với một công ty lớn nhưng chỉ phát triển các dự án có quy mô nhỏ, các ứng dụng và dịch vụ nội bộ.

2. Hỏi về công cụ

Nhiều lập trình viên rất kĩ tính với công cụ phát triển sử dụng trong công việc. Bạn có phải người không ưa các công cụ dùng làm môi trường phát triển tích hợp (IDE – Integrated Development Environment) và thích dùng các công cụ như vi hay make để thực hiện công việc? Nếu đúng vậy, chắc chắn bạn sẽ muốn người thuê mình không cấm bạn sử dụng các công cụ phát triển bạn thấy tin cậy và hiệu quả. Mặc dù đó không phải là rào cản lớn với một số người, rất nhiều lập trình viên sẽ chỉ làm việc với một số môi trường nhất định. Liệu bạn có quyết định ký hợp đồng với một công ty bắt bạn phải làm việc với một môi trường phát triển không quen thuộc và thiếu hiệu quả, để rồi công việc của bạn có thể bị ảnh hưởng?

3. Ăn mặc chỉnh tề

Nghe có vẻ ngu ngốc phải không? Nhưng rất nhiều lập trình viên đã quen làm việc ở nhà hoặc làm việc trong môi trường cho phép họ thoải mái trong việc ăn mặc. Xuất hiện trong một buổi phỏng vấn với quần sóoc và dép là cách chắc chắn nhất để họ không gọi lại cho bạn. Tất cả những gì bạn cần làm là mặc quần dài, áo sơ mi và một chiếc cà vạt. Thậm chí nếu bạn phỏng vấn với tất cả khả năng, bạn không muốn mạo hiểm xúc phạm người phỏng vấn hay công ty đó. Bạn có thể không bao giờ mặc bộ quần áo đó thêm một lần nào nữa nhưng nếu chúng có thể giúp bạn vượt qua buổi phỏng vấn thì đó là một vụ đầu tư hoàn toàn đáng giá.

4. Thể hiện đam mê nhưng đừng mù quáng

Lập trình viên là những người nhiệt huyết nhưng đam mêm nào cũng nên có giới hạn. Đừng tiêu tốn toàn bộ thời gian chỉ để nói về việc bạn yêu thích lập trình thế nào, thay vào đó hãy nói về đam mê của mình thông qua việc giới thiệu những dự án bạn đã từng kinh qua. Không chỉ thể hiện cảm giác vui sướng khi được tham gia vào nhóm mà cả tầm quan trọng của việc viết ra mã lệnh trong sáng, dễ dọc đối với bạn. Hãy làm người phỏng vấn hiểu rằng bạn là một lập trình viên, người sẵn sàng thức đêm để giải quyết một vấn đề lập trình nhưng bạn phải đảm bảo họ cũng biết đó không phải đam mê duy nhất của bạn. Bạn sẽ không muốn người đối diện nghĩ rằng mình là loại “ngựa non háu đá”.

5. Chỉ mang tới những dự án đã hoàn thiện

Đừng chỉ mang tới bản sao đơn xin việc, hãy mang tới cả bản sao dự án tốt nhất bạn đã từng làm. Hãy in một ít mã lệnh cũng như tệp tin của dự án làm ví dụ. Hãy để người phỏng vấn thấy rằng dự án đó thực sự do bạn thực hiện và bạn biết rõ từng ngóc ngách của dự án đó. Đảm bảo rằng bất kì dự án nào bạn mang ra giới thiệu vẫn còn hoạt động. Nếu dự án là một trang web, nó phải có khả năng truy cập bất kì thời điểm nào trong buổi phỏng vấn. Đừng mạo hiểm giới thiệu một dự án đã thất bại. Hãy thực hành trước việc sử dụng phần mềm (hoặc trang web) và chắc chắn rằng bạn biết rõ cách giới thiệu làm sao để người đối diện biết sản phẩm đó do bạn làm ra.

6. Chia sẻ kiến thức của bạn về công việc

Đừng chỉ bước vào phòng và nói: “Tôi biết công ty anh làm gì và tôi thích công việc đó”. Hãy nắm vững công việc của công ty, những dự án họ đang thực hiện, ngôn ngữ sử dụng trong các dự án và thậm chí là cả môi trường phát triển. Bạn càng biết nhiều những thông tin này, bạn càng có cơ hội có được việc làm. Bên cạnh đó, bạn cũng sẽ gây ấn tượng với người phỏng vấn bằng việc đã tìm hiểu chi tiết những thông tin liên quan đến công ty.

7. Đừng bỏ qua các đồng nghiệp

Chê bai người khác để tự đề cao mình luôn là việc dễ làm. Đừng làm vậy! Tuyệt đối không bao giờ! Nếu bạn cần chê bai người khác chỉ để đề cao mình, đó là thời điểm thích hợp bạn nên tự nhìn lại bản thân. Nếu người phỏng vấn hỏi ý kiến của bạn về mã lệnh của những lập trình viên khác, hãy giữ lại những ý kiến tiêu cực cho riêng mình. Nói chuyện theo hướng tích cực và nếu bạn cảm thấy không đồng tình, hãy cho họ biết bạn có thể làm theo hướng khác.

8. Nhìn vào mắt người đối diện

Điều này tương tự với việc ăn mặc chỉnh tề. Mặc dù nhiều lập trình viên có thiên hướng hướng nội, ấn tượng bạn đề lại trong cuộc phỏng vấn sẽ theo suốt sự nghiệp của bạn. Đừng bỏ qua việc giao tiếp bằng ánh mắt với người phỏng vấn. Nhìn thẳng vào mắt người đối diện thể hiện bạn là người tự tin mà sự tự tin là điều mà tất cả các lập trình viên đều cần.

9. Đừng tỏ ra cái gì cũng biết

Mặc dù giao tiếp bằng ánh mắt cho thấy bạn là người rất tự tin, bạn sẽ không muốn sự tự tin đó đi quá xa. Không ai muốn thuê hay làm việc cùng một người lúc nào cũng tỏ ra biết tất cả. Bất kể bạn viết mã lệnh tốt đến thế nào đi nữa, việc kiêu căng, tỏ ra tự tin thái quá sẽ gây phản tác dụng. Nhớ nằm lòng câu thần chú sau đây sẽ giúp bạn: có người biết ít hơn bạn thì cũng sẽ có người biết nhiều hơn bạn. Luôn có một ai đó thông minh hơn, viết mã lệnh tốt hơn bạn. Đừng quên điều này khi bạn bước vào cuộc phỏng vấn. Một chút khiêm tốn sẽ tạo ra ấn tượng tuyệt vời.

10. Đặt câu hỏi

Khi người phỏng vấn hỏi liệu bạn có bất kỳ câu hỏi nào không, đừng ngại mà bỏ qua. Sự tò mò của bạn về công ty và những dự án của công ty chứng minh rằng bạn biết bạn đang tìm kiếm công việc như thế nào; từ đó mang đến cho bạn nhiều lợi thế hơn việc chỉ đơn giản nhún vai. Nhưng đừng đặt câu hỏi chỉ để hỏi (câu hỏi về việc tăng lương, thời gian nghỉ và cách ăn mặc có thể để dành đến thời điểm bạn được đề nghị một vị trí làm việc). Hãy hỏi cụ thể và chắc chắn rằng câu hỏi của bạn hướng đến các dự án, ngôn ngữ dự án yêu cầu, nhóm làm việc và những điều khác bạn nghĩ đến khi bạn ở đó.

Đã qua rồi thời kì ngồi phỏng vấn giống như ngồi trên ghế nóng. Trong khi người phỏng vấn mong bạn nhận được thông tin, họ cũng chuẩn bị cẩn thận để đặt ra câu hỏi cho bạn. Hãy tiến tới thổi bay chúng đi, cho họ thấy bạn có thể giúp họ thành công; sau cùng bạn sẽ chợt nhận ra rằng toàn bộ quá trình phỏng vấn không quá kinh khủng như bạn nghĩ.

P/S: Bạn nào có công việc gì tốt giới thiệu cho tớ cái nhỉ 😀

Advertisements


1 Comment

5 mẹo giúp bạn thuê được những nhân viên phát triển phần mềm tốt nhất

Tác giả: Jack Wallens
Bài gốc: 5 tips to help you hire the best software developers

Lược dịch

Thuê nhân viên phát triển phần mềm là một công việc không dễ dàng. Họ không đơn thuần là những kĩ sư, vì vậy bạn không thể áp đặt quá trình tuyển dụng thành một quy định cứng nhắc cho phòng IT. Trên thực tế, những người phát triển phần mềm thường rất rắc rối, đòi hỏi bạn phải có sự lưu tâm đặc biệt.

Những người phát triển phần mềm đồng thời cũng là những người thiết kế, những người có kĩ năng về kĩ thuật với tài năng bẩm sinh. Người ta thường nói rằng kĩ năng có thể học được nhưng khiếu thẩm mĩ thì không. Điều này cũng đúng đối với phát triển phần mềm. Hoặc là bạn có khả năng, hoặc là không. Chắc chắc bạn có thể học một ngôn ngữ như C hay C++ nhưng điều đó không đồng nghĩa với việc bạn có thể phát triển phần mềm.

Trước khi bạn trở nên quá căng thẳng, hãy sử dụng 5 mẹo dưới đây để có thể thuê được những nhân viên phát triển tốt nhất cho công việc của mình.

1. Phỏng vấn đa dạng

Khi bạn muốn thuê nhân viên quản lý hệ thống, tốt hơn nên sử dụng một phương pháp rõ ràng. Bạn cần biết họ có những kĩ năng gì. Liệu họ có quản lý được hệ thống máy chủ Windows không? Liệu họ có biết về Active Directory hay không? Kĩ năng bảo mật của họ tốt đến mức độ nào? Phương pháp này cũng sẽ đúng nếu bạn muốn thuê một nhân viên quản trị mạng. Cậu ta có biết gì về bảo mật không? Cậu ta thành thạo những nền tảng nào? Tuy nhiên, đối với việc phỏng vấn nhân viên phát triển phần mềm, các câu hỏi cần được nghiên cứ kĩ lưỡng chứ không chỉ đơn thuần là câu hỏi về kĩ năng.

Người đến phỏng vấn có thể có một danh sách dài những ngôn ngữ họ biết trong lý lịch, nhưng liệu họ có thể chắp nối chúng lại với nhau để tạo ra một cái gì đó không? Điều quan trọng nhất cần lưu tâm là những dự án họ đã tham gia. Những dự án nào chính nào học đã từng làm và kết quả công việc của họ có đạt yêu cầu không? Liệu họ có dự án riêng nào không và liệu học có thể giới thiệu các dự án không?

Bạn cần biết công việc thực tế của họ, tìm hiểu xem liệu họ có thể sử dụng ngôn ngữ mình biết để tạo ra những sản phẩm mang tính khả thi không. Hãy lưu tâm và tốc độ thực hiện và sự hiệu quả của họ. Mất bao lâu để họ có thể hoàn thành dự án từ những khái niệm ban đầu? Nếu bạn đang xem xét một ứng cử viên, người mất một khoảng thời gian đáng kể trong năm chỉ để phát triển một ứng dụng mobile đáp ứng mục tiêu nhỏ và trông khá tệ khi thực thi, bạn nên bỏ qua ứng cử viên đó. Tuy nhiên, nếu bạn xem xét một người phát triển phần mềm đã thực hiện nhiều website và ứng dụng chỉ trong một khoảng thời gian ấn tượng, đó có thể chính là người bạn cần.

Hãy nhớ rằng khi phỏng vấn những người phát triển phần mềm, luôn quan tâm đến kết quả và sản phẩm cuối cùng. Đừng chú tâm vào cách mà họ thực hiện chúng.

2. Không tập trung quá nhiều vào nỗ lực trong nhóm

Với phần lớn nhân viên có tiềm năng, bạn phải tập trung vào khả năng làm việc trực tiếp của họ với những người khác. Đó là một kĩ năng cực kì quan trọng. Làm thế nào những người quản trị làm việc với nhân viên, khách hàng và cấp trên của họ?

Khi nghĩ về những nhân viên phát triển phần mềm, bạn phải đặt vấn đề nhóm sang một bên, khi mà phần lớn thời gian họ phải làm việc độc lập. Thậm chí khi một dự án được thực hiện bởi cả nhóm, đa phần thành viên phát triển sẽ phải làm việc một mình, bởi vì họ phải tập trung vào một chứng năng trong tổng thể dự án. Khi công việc của họ hoàn thành, học đưa kết quả ra cho cả nhóm để tích hợp. Nếu có vấn đề, họ sẽ phải tự mình tìm ra sai sót. Công việc có thể thực sự tách biệt với mọi người.

Tất nhiên, điều đó không có nghĩa bạn hoàn toàn bỏ qua khía cạnh giao tiếp của ứng cử viên. Cuối cùng, nhân viên đó sẽ phải giao tiếp với những người khác chứ không chỉ là những người quản trị mạng hay hệ thống.

3. Xem xét những điểm đáng lưu tâm trên khía cạnh nghệ thuật hay những khía cạnh thiết kế khác

Thoạt đầu điều này có vẻ kì lạ nhưng hãy nhớ rằng, phát triển phần mềm tương đồng với công việc thiết kế hơn là công việc hỗ trợ các vấn đề về máy móc. Bạn sẽ muốn tìm một người phát triển quan tâm đến nghệ thuật, âm nhạc và những kĩ năng liên quan đến thiết kế khác. Những người này có khả năng tốt hơn trong việc nhìn nhận công việc phát triển từ một mức độ cao; khả năng khái quát dự án cũng như những thành phần cấu thành nên dự án.

Những mối quan tâm riêng này sẽ không được liệt kê trong lý lịch của họ. Để thực sự nắm được thông tin này, bạn phải vượt qua rào cản của việc phỏng vấn và nói chuyện thực sự với ứng cử viên. Hiểu nhiều hơn những thông tin cá nhân của ứng cử viên chứ không chỉ là kĩ thuật. Tìm ra những mối quan tâm, niềm đam mê cũng như quá khứ của họ. Đừng lo lắng việc này sẽ dẫn đến những câu chuyện vụn vặt. Bạn có thể tìm ra một ứng cử viên người cũng có thể viết nhạc; một khả năng có mối liên hệ thật sự với phát triển phần mềm.

4. Hỏi về kĩ năng gỡ lỗi

Khả năng tìm ra vấn đề trong phần mềm không quan trọng như khả năng hoàn chỉnh dự án từ đầu đến cuối. Nhưng khả năng nhanh chóng chỉ ra vấn đề là một năng khiếu cực kì đặc biệt. Khi một người tạo ra sản phẩm, họ không chỉ đơn giản tung ra thị trường rồi phủi tay. Họ phải giúp sức vào quá trình tìm lỗi. Nói gì đi nữa, nếu đó là mã lệnh của họ thì sẽ chẳng ai lại hiểu những dòng mã đó tốt như người tạo ra chúng.

Không phải mọi người đều có thể làm tốt việc này. Bạn sẽ thấy có những người thậm chí không thể thể tìm ra lỗi trong mã lệnh mình viết. Trên thực tế, bạn sẽ thấy có những nhân viên phát triển phủ nhận rằng có sai sót trong công việc của họ, đồng thời nhấn mạnh rằng lỗi đó thuộc về người dùng. Bạn tuyệt nhiên nên tránh xa bất kì ứng cử viên nào không thể gỡ lỗi hoặc luôn cho rằng mã lệnh của họ không bao giờ có lỗi.

5. Tìm kiếm những lập trình viên gọn gàn và ngăn nắp

Một trong những vấn đề lớn nhất với những nhà phát triển là khả năng viết mã lệnh sáng sủa, dễ hiểu. Nếu bạn thuê một người có thể hoàn thành công việc bằng những dòng mã lệnh cẩu thả (mà không ai khác có thể hiểu), bạn đã thất bại trong việc tuyển người. Điều gì xảy ra nếu anh ta nghỉ việc và không ai khác có thể làm việc với những dòng mã lệnh anh ta để lại? Liệu bạn có trả tiền cho một ai đó để họ bỏ ra nhiều giờ dọn dẹp những dòng mã lệnh cẩu thả trên?

Việc biết người bạn thuê có thể viết ra những dòng mã lệnh và nhận xét sáng sủa hay không là rất quan trọng. Những mã lệnh đó phải được hiểu và sử dụng bởi những đồng nghiệp khác. Nếu không bạn có thể đã thuê về một quả bom hẹn giờ.

Thuê nhân viên phát triển phần mềm không phải công việc khiến bạn phải quá lo lắng. Nếu bạn tiếp cận quá trình tuyển dụng bằng những lưu tâm nhỏ, bạn sẽ thành công trong việc tuyển dụng ứng viên, người sẽ giúp bạn xây dựng sản phẩm hoặc dự án phù hợp với nhu cầu của công ty bạn.


Leave a comment

Quản lý lập trình viên

Tác giả: Jon Evans (@rezendi)
Bài gốc: On Managing Developers

Lược dịch

Tôi là một kĩ sư phần mềm, tiểu thuyết gia, nhà báo, đồng thời cũng là một nhà quản lý; và quản lý các lập trình viên là công việc khó nhằn nhất mà tôi từng làm (không phải công việc nặng nhọc nhất nhưng là công việc khó nhằn nhất). Tôi không tự coi mình là chuyên gia hay một nhà quản lý xuất sắc; nhưng tôi có thể đảm bảo với bạn rằng tôi là một người cầu thị. Dưới đây là một số bài học rút ra từ sai lầm của chính bản thân tôi.

Nắm quyền phụ trách không có nghĩa bạn đang nắm quyền kiểm soát

Điều trớ trêu trong việc quản lý đó là chức vụ của bạn càng cao bao nhiêu, khả năng kiểm soát thực sự của bạn càng ít đi bấy nhiêu. Khi bạn chỉ là một người lập trình bình thường, bạn bắt máy tính thực hiện chính xác những gì bạn muốn. Khi bạn là một nhà quản lý, bạn chỉ hy vọng rằng mọi người hiểu những gì bạn muốn và sau đó tin tưởng (hoặc cầu nguyện) rằng họ sẽ thực hiện chính xác yêu cầu trong thời gian quy định.

Các nhà quản lý có xuất phát điểm là lập trình viên, đặc biệt là những lập trình viên đa năng (full-stack – hay còn gọi là “tài tử”) như tôi, thường gặp khó khăn với vấn đề này. Điều này đặc biệt chính xác khi họ từng do dự trong việc lựa chọn công việc lập trình hay quản lý (một số kết hợp cả hai). Tự mình làm hết mọi việc để đảm bảo nó được thực hiện chính xác là vô cùng khó khăn.

Vẫn đề trở nên khó khăn hơn nữa khi phải phân biệt giữa việc “đó không phải là cách tôi sẽ làm” và “đó là cách làm sai, cần phải tái cấu trúc / viết lại / bố trí lại” khi xem xét công việc của một ai đó. Nhưng bạn cũng phải tạo cơ hội cho những người mới vào để họ phát triển cũng như tạo môi trường cho những lập trình viên có kinh nghiệm để họ phát huy. Bạn phải buộc mình lui lại và chấp nhận rằng việc có ảnh hưởng lớn hơn đi kèm với việc giảm bớt khả năng kiểm soát.

Những nhà quản lý không có xuất phát điểm là kĩ sư thậm chí có ít khả năng kiểm soát cũng như thiếu hiểu biết về quá trình phát triển và khó khăn có thể mắc phải hơn. Tôi không tin kết luận này lắm nhưng không phủ nhận rằng có những người như vậy, thậm chí một số còn là những người giỏi nhất tôi từng làm việc cùng hay làm việc cho. Điều họ mang lại (hy vọng thế) là tăng khả năng suy nghĩ như một khách hàng, người vận hành hay người dùng cuối. Và có lẽ cũng nâng cao khả năng tránh xa khỏi ám ảnh rằng mọi thứ phải luôn nằm trong tầm kiểm soát. Những lập trình viên tiến thân thành nhà quản lý có xu hướng tự coi mình như vị tướng thống lĩnh một đội quân trong khi thực tế bạn là một hoa hiêu đang hy vọng hướng dẫn con tàu vượt qua cơn bão. Ở đó, điều những thủy thủ đoàn làm thực sự rất quan trọng.

Agile rất tốt. Nhưng tại sao là Agile?

Mọi người nói nhiều về phương pháp phát triển; câu trả lời là “quá nhiều” nếu bạn hỏi tôi. Ở nhiều nơi, “phát triển linh hoạt” (Agile development) đã được hệ thống hóa thành một quy trình cố định với những quy định cụ thể cho từng tiến trình như “standup”, “scrum” và “sprint”. Những quy tắc này được ám chỉ mơ hồ như là những nguyên tắc cơ bản trong tuyên ngôn của Agile bao gồm “Tính cá thể và tính tương tác quan trọng hơn qui trình và công cụ” và “Phản ứng với các thay đổi quan trọng hơn tuân thủ kế hoạch”. Vậy các công ty đã tạo ra và tuân theo những gì? Quy trình Agile, công cụ và kế hoạch. Chẹp! Nếu bạn là thạc sĩ được chứng nhận về Scrum, bạn đang làm hoàn toàn sai.

Bất kì quá trình riêng biệt nào được tạo ra có lẽ đều không thích hợp. Nhóm phát triển tốt nhất mà tôi từng làm việc cùng luôn khởi đầu một ngày bằng việc họp nhanh (standup). Một nhóm tệ hại nhất tôi từng gặp cũng làm như vậy. Mọi người tung hô ý kiến của Lean Startup về “Minimum Viable Product” nhưng họ cũng nói về nó như là một thiết kế lỗi thời. Họ muốn một thiết kế phải “đẹp” và “hoàn hảo” để bất kì dự án mới nào đều có thể thành công. Các cuộc họp trực diện có thể cực kỳ hiệu quả nhưng liệu có khả thi cho các nhóm làm việc từ xa ở các vùng địa lý khác nhau? Câu hỏi là: ai mới đúng? Ở đây, như thường lệ, câu trả lời là “điều đó còn tùy”.

Đừng hiểu lầm tôi. Tôi không khuyên bạn vứt bỏ tất cả những phương pháp tốt đã được tạo ra. Tôi chỉ muốn nói rằng các hệ thống cũng như phương pháp bạn chọn cho bất kì dự án nào nên mềm dẻo và linh hoạt; tùy thuộc vào nhóm phát triển cũng như hoàn cảnh cụ thể.

Thật may mắn là tôi được làm việc cho một công ty sử dụng phương pháp Agile nhưng vẫn quan tâm đến những gì thực sự quan trọng. Điều quan trọng nhất của phương pháp phát triển linh hoạt (Agile development) nằm trong chính tên của nó. Bạn phải linh hoạt. Và bạn phải tiến nhanh. (Tất nhiên thực tế là bạn phải viết mã kiểm tra. Điều đó không có trong tên phương pháp nhưng nó cũng rất quan trọng). Theo kinh nghiệm bản thân của tôi, sự trì trệ trong phần mềm chịu ảnh hưởng của hiệu ứng Lindy. Vì vậy bạn phải chuyển gia mã lệnh thường xuyên và liên tục; hiện tại trì hoãn càng nhiều, tương lại bạn càng trì hoãn nhiều hơn. Giống như một con cá mập, nếu bạn không bơi, bạn sẽ chết đói.

Công việc chết tiệt là công việc của bạn

Về cơ bản, công việc của người quản lý là giúp người khác làm việc hiệu quả hơn. Cách tốt để thực hiện điều đó là gì? Thực hiện công việc theo cách của họ. Điều này có nghĩa là bạn phải tìm ra công việc quan trọng nào mà lập trình viên ghét nhất rồi làm việc đó cho họ.

Rất hiếm lập trình viên thích viết tài liệu. Điều này đồng nghĩa viết tài liệu là công việc của bạn. Việc kiểm tra là thực sự quan trọng nhưng cũng chẳng mấy lập trình viên thích viết mã lệnh kiểm tra. Đây cũng là công việc của bạn. Không phải toàn bộ mã lệnh kiểm tra, việc này không cần thiết, nhưng phải đủ để tạo ra một ví dụ, một chuẩn để thúc đẩy những thứ tiếp theo. Bạn không phải là lập trình viên? Hãy học, đủ để tự mình viết mã lệnh kiểm tra. Nếu bạn là một lập trình viên? Hãy xây dựng bộ khung kiểm thử sao cho người khác có thể dễ dàng thêm vào nếu cần. Nếu bạn nghĩa kiểm tra chất lượng là công việc của người khác hay không thuộc trách nhiệm của bạn thì bạn thực sự là một nhà quản lý rất, rất, rất tồi.

Bạn cũng phải làm công việc chết tiệt khác là kết nối mọi người với nhau. Nếu một lập trình viên nói với bạn “đây là một mớ bòng bong, chúng ta phải chấp nhận thương đau bằng việc tái cấu trúc và làm lại cho đúng, tất nhiên phải lui thời hạn hoàn thành lại”, bạn có lẽ cần phải ủng hộ ý kiến đó dù sẽ phải chấp nhận mất mát trong ngắn hạn. Về lâu dài, bạn sẽ được đền đáp. Chỉ giữ những vấn đề kĩ thuật lại nếu nó không gây ra ảnh hưởng về lâu dài.

Kết luận của kết luận của kết luận: con người chính là vấn đề

Thật không may, có lẽ bạn cũng đã biết, con người thật đáng ghét. Người ta chõ mũi vào chuyện của bạn, trêu ngươi, làm ngơ, làm phiền, biến mất, bỏ rơi hoặc mất niềm tin vào bạn; thông thường chẳng vì lý do chính đáng nào cả. Thử đoán xem? Nếu bạn là một nhà quản lý, sự mất kiểm soát của họ là của bạn và ngay cả những vấn đề của họ cũng là vấn đề của bạn. Hãy làm quen với điều này. Bạn cần sớm nhận ra vấn đề của mọi người và có kế hoạch ứng phó với các vấn đề đó.

Ngoài ra, mọi người làm việc theo những cách khác nhau với tốc độ khác nhau. Đó là cách lịch sự để nói rằng việc thuê nhân viên thực sự là quan trọng, bởi vì như tôi đã nói, con người thật sự đáng ghét.

Nhưng đợi chút, bạn có biết cách làm cho mọi người (thật kinh ngạc) ít đáng ghét không? Không phải tôi cố tính tạo sự chú ý nhưng bài học đáng nhớ nhất trong sự nghiệp của tôi là: khi mọi người thấy có thể tin tưởng bạn cũng là lúc bạn thấy tin tưởng mọi người. Tôi thề đó là sự thật!

Vì vậy đừng bao giờ phỉ báng bất kì ai. Lời khen đáng giá nhất mà tôi nhận được là từ ông chủ cũ sau cuộc phỏng vấn. Ông ấy chậm rãi nói với tôi: “Tôi khi biết anh làm thế nào nhưng khi anh nói, mọi người trở nên chân thành hơn”. Hãy nói sự thật theo cách bạn nhìn nhận. Nói khách sáo, xin đừng hiểu lầm tôi, nhưng phải thật lòng. Chỉ có như vậy bạn mói nhận được sự tin tưởng từ người khác.

Về cơ bản bạn là người phiên dịch kĩ thuật cho mọi người

Những nhà quản lý diễn giải toàn cảnh dự án thành những nhiệm vụ độc lập cho từng lập trình viên cùng với những chi tiết cũng như các tương tác cụ thể sẽ diễn ra. Họ cũng diễn giải lại công việc thực hiện bởi lập trình viên nhằm giúp khách hàng, người vận hàng cũng như người dùng cuối có thể hiểu công việc đã hoàn tất. Và có lẽ điều quan trọng nhất là diễn giải lại chi tiết lỗi, hạn chết và cơ hội cho khách hàng, người vận hàng cũng như người dùng cuối. Bất kì dịch giả chuyên nghiệp nào cũng sẽ nói với bạn rằng điều này có nghĩa bạn cần phải hiểu công việc sâu sắc hơn chính bản thân tác giả. Với họ, đó là trực giác nhưng với bạn, đó là công việc. Chia nhỏ mọi thứ theo cách làm sao để bất kì ai đều có thể hiểu được.

Dưới danh nghĩa của một tác giả, tôi xin nói rằng những dịch giả không nhận được bất kì vinh quang nào cuốn sách mang lại. Tất cả những quyết định tốt có được là do tác giả. Tương tự vậy, những người sáng lập (trong trường hợp của chúng tôi là khách hàng) nhận được ca ngợi về sự sáng tạo còn lập trình viên nhận được sự ca ngợi về mã lệnh. Chẳng ai nhìn một em bé xinh xắn rồi ngợi ca những nữ hộ sinh cả.

Vậy thì tại sao lại phải làm công việc này? Lý do như tôi nói là từng cá nhân lập trình viên có thể kiểm soát rất tốt nhưng học lại thiếu tầm ảnh hưởng. Không làm và nhìn nhận theo cách của họ, quyết định bạn đưa ra sẽ ảnh hưởng vĩnh viễn đến việc liệu cái bạn xây dựng có tốt hay không. Và nếu điều đó chẳng có ý nghĩa gì với bạn, bạn không chỉ là một nhà quản lý tồi, bạn còn đang hoàn toàn sai đường lạc lối.


1 Comment

Phát triển phần mềm theo định hướng YOLO và những phương pháp hài ước khác

Tác giả: Natali Vlatko
Bài gốc: YOLO Driven Development (and other hilarious IT methodologies)

Lược dịch

<< trong trường hợp bạn chưa biết, YOLO là viết tắt của cụm từ You Only Live Once – Bạn chỉ sống duy nhất một lần mà thôi >>

Bạn có biết sự tồn tại của một phương pháp có thể thay đổi hoàn toàn cách bạn lập trình: YDD – YOLO Driven Development. Bỏ qua những dòng mã rõ ràng, cặn kẽ sang một bên; hãy cởi mở với những phương pháp phát triển thay thế khác.

Bạn có thể tưởng tượng chúng tôi vui đến thế nào khi nhìn thấy những tuyên ngôn của một phương pháp mang tính đột phá trong hòm thư của mình không? Todor Grudev, nhà tiên tri của YDD, đã khắc lên đá (tại GidHub) 17 điều răn của phương pháp phát triển này.

Hãy khắc ghi, YOLO Driven Development!

# Không tái cấu trúc (refactor) lại mã lệnh, coi nó như một cách làm tồi. YOLO

# Việc không hiểu tại sao và làm thế nào một vấn đề được thực hiện luôn là điều tốt. YOLO

# Đừng bao giờ kiểm tra lại mã lệnh của chính mình, hãy yêu cầu một người nào đó. YOLO

# Sẽ chẳng ai đọc mã lệnh của bạn đâu, vì vậy đừng tốn công viết chú thích làm gì. YOLO

# Tại sao phải làm một việc theo cách dễ dàng khi bạn có thể “phát minh lại cái bánh xe”? Việc kế thừa và phát triển trong tương lai chỉ dành cho lũ ngốc mà thôi. YOLO

# Không bao giờ đọc tài liệu. YOLO

# Đừng phí thời gian với những vấn đề cốt lõi. YOLO

# Không viết tài liệu đặc tả . YOLO cũng chính là YDD (YOLO DRIVEN DEVELOPMENT)

# Không cần tuân theo các qui ước đặt tên. YOLO

# Trả tiền cho những bài hướng dẫn trực tuyến luôn tốt hơn việc đọc và nghiên cứu. YOLO

# Luôn sử dụng môi trường thành phẩm (production evironment) khi làm việc. YOLO

# Không mô tả điều bạn đang muốn làm, hãy hỏi những câu hỏi vu vơ về việc làm thế nào để hoàn tất nó. YOLO

# Không thụt lề mã lệnh. YOLO

# Các hệ thống kiểm soát phiên bản chỉ dành cho những kẻ bất tài. YOLO

# Phát triển trên một hệ thống tương tự như hệ thống triển khai cũng chỉ dành cho những kẻ bất tài! YOLO

# Không phải lúc nào tôi cũng kiểm thử mã lệnh của mình. Nhưng nếu tôi phải làm, tôi sẽ thực hiện công việc đó trên môi trường thực tế. YOLO

# “Người đàn ông thực thụ” sẽ triển khai ứng dụng qua ftp (File Transfer Protocol – giao thức truyền tệp tin). YOLO

Hãy quên đi những truyền thống cũ kĩ của phương pháp phát triển hướng kiểm thử hay hướng hành vi. Phương pháp mới sẽ giúp bạn tống cổ các chuyên gia tin học đi! Ruby.zigzo tóm tắt lại tuyên ngôn của YDD như sau: “Đây là một trò đùa, đừng làm theo bất cứ điều gì hoặc… cứ làm theo! YOLO!”

Tuy nhiên, một lệnh tìm kiếm đơn giản “because YOLO” trên GitHub cũng mang lại hơn 600 kết quả, điều đó chứng minh rằng khá nhiều lập trình viên đã bắt đầu áp dụng phương pháp YOLO:

                            (map(lambda __suchwoow:\
                map(lambda  __because___yolo__:\
      __lololol_.__setitem__((      (__because___yolo__))  ,                (0)),
range(2*(__suchwoow),               ((very_math)),     __suchwoow               ) ),

Ôi không, bạn không áp dụng…

YOLO Driven Development không phải là cách bạn thích? Tốt thôi, dưới đây là một số phương pháp phát triển hài ước khác bạn có thể vận dụng.

Phương pháp chim bồ câu

Sếp bay đến, ị lên mọi thứ rồi bay đi.

ADD (Asshole Driven Development – phát triển hướng “hậu môn” :D)

Một phương pháp yêu thích trước đây dành cho bất kì nhóm nào, trong đó những gã xuẩn ngốc nhất luôn đưa ra quyết định chính. Sự từng trải, cách thực hiện và tính lô-gíc mặc nhiên không cần tính đến.

Phương pháp NDAD (No Developers Allowed in Decisions – không ai được đưa ra quyết định)

Về cơ bản các lập trình viên bị cấm đưa ra các quyết định liên quan đến dự án, từ thiết kế những phần cốt lõi cho đến thời điểm kết thúc dự án. Lý do là những nhà lãnh đạo trung và cao cấp hiểu rõ điều họ muốn, làm thế nào để thực hiện và mất bao lâu để hoành thành nó.

FDD (Fear Driven Development – phát triển hướng sợ hãi)

Phân tích chứng minh rằng trạng thái tê liệt, điều có thể làm chậm lại toàn bộ dự án, là do những nhà phát triển sợ gây ra sai lầm, làm hỏng bản build hoặc gây ra lỗi. Khởi nguồn cho lo ngại của một lập trình viên có thể được qui cho việc thất bại trong vấn đề chia sẻ thông tin hoặc quy trách nhiệm cho những thành viên có thể thay thế trong nhóm.

CYAE (Cover Your Ass Engineering – bao che cho những kĩ thuật viên cặn bã)

Scott Berkun diễn tả hùng hồn rằng: động cơ đằng sau những nỗ lực cá nhân là để đảm bảo rằng khi sản phẩn bị chê bai, họ không phải là người gánh nhận tội lỗi.

Liệu còn phương pháp kỳ lạ nào khác mà chúng tôi quên chưa đề cập tới không? Nếu bạn biết, hãy cùng chia sẻ nhé!