Liệu việc viết code có quan trọng?

Bài viết được dịch từ blog Coding Horror

Bài viết 10 Bí quyết để giúp một lập trình viên trở thành doanh nhân của tác giả Ian Landsman là một lời khuyên tuyệt vời. Thậm chí nếu bạn không có ý định trở thành một doanh nhân đi chăng nữa.

Một trong những vấn đề lớn nhất mà tôi nhìn thấy ở các lập trình viên đó là họ suốt ngày chúi mũi vào những dòng code của mình mà không còn quan tâm đến vấn đề gì khác. Họ dành ra vô số thời gian để tạo ra một chức năng hoàn hảo hoặc xây dựng các đặc trưng để khoe khoang về công nghệ mới nhất nào đó. Hiện nay bạn phải viết code để có thể tồn tại trong ngành kinh doanh phần mềm. Đó là code viết ra phải có chất lượng cao mà không có nhiều bug hoặc thiếu an toàn. Tuy nhiên, phần code tốt nhất trên thế giới đó sẽ trở nên vô nghĩa nếu không ai biết về sản phẩm của bạn. Code đó sẽ trở nên vô nghĩa nếu mấy gã ở Cục Thuế đến và tống cổ bạn vào tù bởi vì bạn vẫn chưa thực hiện nghĩa vụ thuế. Code đó sẽ trở nên vô nghĩa nếu bạn bị kiện tụng bởi vì bạn đã không bận tâm về việc có một bản quyền phần mềm đã được tạo ra bởi một gã luật sư nào đó.

Ngày nay một lập trình viên cần phải có nhiều kỹ năng mới có thể thành công.Ngày nay một lập trình viên cần phải có nhiều kỹ năng mới có thể thành công.

Đọc tiếp >>

Trong lập trình: giải pháp tồi hơn đôi khi lại tốt hơn

Bài viết được dịch từ blog Coding Horror

Mặc dù có một chút khó khăn để có thể phân tích thấu đáo, nhưng tôi đã bị thu hút bởi bài viết The Rise of “Worse is Better” (Sự gia tăng của xu hướng “tồi hơn thì tốt hơn”), bởi vì nó chạm đến một chủ đề mà tôi đã để ý nổi lên trong các bài viết trên blog của mình, đó là: hãy loại bỏ những cái phức tạp, thậm chí khi giải pháp phức tạp trên lý thuyết lại là hướng tiếp cận đúng đắn hơn.

Trong lập trình đôi khi giải pháp tồi hơn lại cho kết quả tốt hơn.Trong lập trình đôi khi giải pháp tồi hơn lại cho kết quả tốt hơn.

Đọc tiếp >>

Lập trình viên nói đi đôi với làm

Bài viết được dịch từ blog Coding Horror

Tôi tin rằng tất cả các lập trình viên cần thiết lập một sự cân bằng có lợi giữa…

  1. Nhốt mình trong một văn phòng riêng tư và có một cuộc hội thoại thân mật với một trình biên dịch về chương trình của bạn.
  2. Đi ra ngoài cộng đồng và có một cuộc hội thoại cởi mở với những người khác về chương trình của bạn.

Tôi đã nói về điều này một vài lần trước đây, vì vậy tôi thấy không cần thiết phải nói lại quan điểm đó.

Lập trình viên giỏi nói được thì cũng phải làm được.Lập trình viên giỏi nói được thì cũng phải làm được.

Đọc tiếp >>

Lầm tưởng về số năm kinh nghiệm trong nghề lập trình

Bài viết được dịch từ blog Coding Horror

Gần đây tôi có nhận được một email từ Andrew Stuart của công ty tuyển dụng Flat Rate ở Úc. Andrew đã thuật lại quy trình phỏng vấn kỹ thuật qua điện thoại của họ, các bước của họ dường như tương đối giống với nội dung tôi đã phác thảo trong bài viết Phỏng Vấn Lập Trình Viên Qua Điện Thoại Đúng Cách. Tôi rất vui khi nghe thấy rằng cách đó hiệu quả. Thực ra, một buổi phỏng vấn qua điện thoại đúng cách là rất quan trọng. Tôi hoàn toàn đồng ý với Andrew là: bạn nên chắc chắn đến 95% về một ứng viên nào đó sẽ là một nhân viên tuyệt vời trước khi họ bước chân vào một phòng phỏng vấn. Bất cứ thứ gì ít hơn đều là một sự lãng phí thời gian rất lớn của mọi người.

Liệu chúng ta có nên yêu cầu số năm kinh nghiệm của ứng viên không nhỉ?Liệu chúng ta có nên yêu cầu số năm kinh nghiệm của ứng viên không nhỉ?

Đọc tiếp >>

Vụ án về việc phân biệt chữ hoa chữ thường

Bài viết được dịch từ blog Coding Horror

Lời bàn của Vinacode:

Ở bài viết này thì mình cũng không bàn luận gì nhiều, mình chỉ xin làm rõ một chi tiết là trong bài này tác giả sử dụng tên Keanu Reeves làm ví dụ (đó là tên của một nam tài tử ở Hollywood).

Một trong những vấn đề nguy hại nhất của các ngôn ngữ lập trình dựa trên ngôn ngữ C đó là chúng phân biệt chữ hoa và chữ thường. Trong khi quyết định này có thể có ý nghĩa vào năm 1972 khi mà ngôn ngữ này được tạo ra, một điều kỳ lạ là tại sao sai lầm của Kernighan và Ritchie lại bị ghi nhớ mãi một cách mù quáng trong 30 năm vừa qua.

Sẽ là tốt hơn nếu các ngôn ngữ lập trình không phân biệt giữa chữ hoa và chữ thường.Sẽ là tốt hơn nếu các ngôn ngữ lập trình không phân biệt giữa chữ hoa và chữ thường.

Đọc tiếp >>

Lạy Chúa, ngài có ở đó không? Có tôi, Microsoft đây

Bài viết được dịch từ blog Coding Horror

Mặc dù cuối cùng bạn cũng bỏ được những tật xấu đó, nhưng bất kỳ lập trình viên nào cũng phải trả giá bằng những vết sẹo do hàng ngàn cuộc chiến tranh tôn giáo nhỏ xíu để lại. Nó là một mối nguy trong nghề nghiệp, như tác giả Steve McConnell cũng đã đề cập trong cuốn sách nổi tiếng Code Complete ở phần Thou Shalt Rend Software and Religon Asunder (Hãy tách rời Phần Mềm và Tôn Giáo ra xa nhau):

Những niềm tin và định kiến cực đoan là rất nguy hiểm trong lập trình.Những niềm tin và định kiến cực đoan là rất nguy hiểm trong lập trình.

Đọc tiếp >>

Portfolio của một lập trình viên

Bài viết được dịch từ blog Coding Horror

Việc tạo ra một portfolio (một tuyển tập những công việc mà bạn đã làm) là điều hết sức quan trọng. Nhiều nhà tuyển dụng sẽ yêu cầu nó trước khi họ quan tâm đến việc bạn có phù hợp cho một công việc hay không. Hãy dành thời gian cần thiết để tạo ra một portfolio mà sẽ gây ấn tượng với họ– nó sẽ thực sự đáng giá.

Bạn nên chuẩn bị một portfolio về các dự án đã làm khi đến buổi phỏng vấn tuyển dụng.Bạn nên chuẩn bị một portfolio về các dự án đã làm khi đến buổi phỏng vấn tuyển dụng.

Đọc tiếp >>

Hãy có tâm huyết và biết kiên nhẫn – Phỏng vấn anh Phạm Thùy Nhân tác giả phần mềm English Study

“Hãy có tâm huyết và biết kiên nhẫn. Anh cũng muốn nhắc các bạn trẻ hãy nhớ rằng máy tính và CNTT chỉ là công cụ để phục vụ cho những cái khác nên những kiến thức ngoài CNTT là rất quan trọng.” ~ Phạm Thùy Nhân

Anh Phạm Thùy Nhân tác giả phần mềm English Study.

Anh Phạm Thùy Nhân tác giả phần mềm English Study.

Đọc bài phỏng vấn của blog Vinacode với anh Phạm Thùy Nhân (là tác giả phần mềm English Study). Với trên 20 năm kinh nghiệm trong nghề lập trình, đặc biệt là lĩnh vực multimedia và xử lý đồ họa, anh Nhân cùng thương hiệu phamthuynhan PRODUCTIONS đã cung cấp ra thị trường rất nhiều sản phẩm nổi tiếng trong lĩnh vực giáo dục như: English Study, English Kiddies, Học Cùng Bi, Ong Vàng, Đậu Lém Phiêu Lưu Ký… để nghe anh chia sẻ về:

  • Những kỹ năng cần có khi theo đuổi lĩnh vực multimedia và xử lý đồ họa.
  • Một số kinh nghiệm về khởi nghiệp.
  • Cách thức để tạo ra một sản phẩm dạng game đồ họa.
  • Những nghĩ suy về vấn đề vi phạm bản quyền phần mềm tại Việt Nam.

Đọc tiếp >>

Lập trình viên học trên chiến trường

Bài viết được dịch từ blog Coding Horror

Thỉnh thoảng tôi có nhận được một số email từ một số người hỏi về việc làm thế nào để chuẩn bị cho nghề nghiệp trong lĩnh vực phát triển phần mềm. Một số sinh viên băn khoăn về việc họ nên theo học ngành nào; những người khác thì đã bị cắn bởi bug trong lập trình và họ đang quan tâm về những bước nên làm tiếp theo.

Học lập trình tốt nhất là bằng cách tham gia các dự án thực tế.Học lập trình tốt nhất là bằng cách tham gia các dự án thực tế.

Đọc tiếp >>

Code tốt nhất là không code chút nào cả

Bài viết được dịch từ blog Coding Horror

Rich Skrenta viết rằng code chính là kẻ thù của chúng ta.

Code thì rất dở. Mó mục nát. Nó yêu cầu phải được bảo trì theo định kỳ. Nó có nhiều bug mà cần phải được phát hiện. Những đặc trưng mới nghĩa là code cũ đã bị điều chỉnh. Bạn càng có nhiều code, thì càng có nhiều chỗ để cho các bug trú ẩn. Thời gian checkout và biên dịch sẽ lâu hơn. Và một nhân viên mới sẽ cần thời gian lâu hơn để có thể hiểu được hệ thống của bạn. Nếu bạn phải tái cấu trúc nó thì sẽ có rất nhiều thứ phải thay đổi.

Code được tạo ra bởi các kỹ sư. Để tạo ra nhiều code hơn thì yêu cầu nhiều kỹ sư hơn. Các kỹ sư có chi phí truyền đạt là n^2, và tất cả phần code mà họ đã bổ sung vào hệ thống trong khi mở rộng khả năng của nó thì cũng làm tăng toàn bộ phí tổn. Bạn nên làm bất cứ điều gì có thể để tăng năng suất của những lập trình viên riêng lẻ thông qua code mà họ viết. Bớt đi những đoạn code làm cùng công việc giống nhau. Số lượng lập trình viên phải thuê sẽ ít đi. Chi phí truyền thông trong tổ chức cũng sẽ giảm đi rất nhiều.

Thực ra code tốt nhất là không code một chút nào cả!Thực ra code tốt nhất là không code một chút nào cả!

Đọc tiếp >>