Tôi luôn cố gắng để tôi của ngày mai hoàn thiện hơn hôm nay. Thế mạnh và điểm yếu của bản thân luôn là chủ đề mà tôi hay nghĩ tới. Đó cũng có nghĩa là tôi phải cân nhắc xem mình đầu tư thời gian vào cải thiện mặt nào là giá trị nhất.

Cách suy nghĩ trên không chỉ đơn thuần là để phát triển bản thân. Việc hiểu rõ điểm yếu và thế mạnh của từng cá nhân còn là một kĩ năng cần thiết trong tuyển dụng. Chúng tôi từng mắc sai lầm và thuê một lập trình viên cực kì giỏi…ở những lĩnh vực mà chúng tôi không cần tới.

Đối với lập trình viên, kĩ năng quan trọng nhất trước tiên chính là khả năng lập trình. Việc viết code chính là trách nhiệm của developer. Thật không may là nó là một việc đầy thử thách. Đặc biệt là trong việc đánh giá khả năng lập trình của mỗi cá nhân.

Lập trình thực chất chỉ là giao tiếp với máy tính. Điều này được nhấn mạnh hơn khi các lập trình viên thì viết mã bằng ngôn ngữ lập trình. Cũng tương tự như trong ngôn ngữ: biết tiếng Anh là một chuyện. Nhưng có thể viết thơ bằng tiếng Anh là một câu chuyện khác. Hay là tiểu thuyết viễn tưởng. Hay truyện phi viễn tưởng thì để phục vụ công chúng. Hoặc là các tờ  báo khoa học. Biết một thứ tiếng là một chuyện. Nhưng có thể sử dụng thuần thục nó hay không còn phụ thuộc vào khả năng chuyên môn ngôn ngữ của từng người trong từng bối cảnh nhất định.

Nói tiếp về việc viết tiếng Anh, một nhà văn và một biên tập viên có những kỹ năng khác nhau. Yêu cầu về hiểu ngữ pháp, cấu trúc câu, v.v. thì có những điểm tương đồng. Tuy nhiên, cách tư duy của mỗi người thì khác nhau. Đối với các lập trình viên cũng vậy, có một sự khác biệt lớn giữa việc viết mã từ đầu hoặc lặp lại trên hệ thống có sẵn. Trừ khi nhà phát triển đó chính là người bắt đầu, còn không, anh ta mà giỏi làm việc với hệ thống có sẵn mới lạ.

Hầu hết giai đoạn đầu sự nghiệp của tôi là như vậy. Trong mấy năm đầu mới tốt nghiệp, tôi rất ít khi được khởi tạo một dự án nào từ đầu, mà công việc của tôi thường đã có một sản phẩm sẵn. Và tôi phải đưa ra các quyết định dựa trên hệ thống ấy. Nó đã đi vào hoạt động, có chức năng làm việc rõ ràng, và bạn phải dè chừng để không làm ảnh hưởng đến chức năng ấy, điều này giới hạn những việc một lập trình viên có thể làm. Tôi học được kỹ năng là xem xét những gì bị giới hạn và xem mình làm được những gì trong phạm vi giới hạn ấy. Biên tập viên thì không thể làm cuốn tiểu thuyết từ giết người bí ẩn thành chuyện tình lãng mạn được. Đó là điều mà tác giả đã quyết định trước đó rồi.

Những nền tảng như vậy, dù có chất lượng tệ đến mấy thì nó vẫn mang vai trò làm mốc cho developer. Giúp cho việc giảm thiểu bớt những quyết định phải đưa ra cũng như có được những hướng đi rõ ràng và đơn giản hơn.

Còn nếu chúng ta bắt đầu với một project từ con số không thì có thể nói có gần như là vô hạn các khả năng có thể xảy ra. Bạn có thể chọn bất cứ thứ gì mình muốn. Thường thì các developer sẽ dựa trên những kinh nghiệm từ project cũ nhưng nó vẫn chưa phải là cách giải quyết tốt nhất. Đó là do những hệ thống đó đã có sẵn cho bạn và chúng ta thực chất chỉ là dùng các giải pháp nằm gói gọn trong một giới hạn được đặt ra. Còn giờ khi đã không còn những cản trở ấy thì ta sẽ có những lựa chọn tốt hơn. Vấn đề ở đây là việc bạn có thể đưa ra quyết định đúng đắn trong hàng tỉ những khả năng khả thi.

Ngoài ra còn cần cả khả năng debug. Bạn hẳn nghĩ rằng việc chỉ cần code nhiều thì debug cũng sẽ giỏi nhưng thật chất mindset lại hoàn toàn khác. Khi bạn code thì cũng như một người tài xế. Bạn biết mình phải làm gì để có thể tới đích.

Còn với quá trình debug thì mọi thứ lại trở nên mông lung hơn. User không bao giờ biết được hệ thống họ dùng ra sao và cũng chả quan tâm. Điều quan trọng nhất là nó phải chạy và hoạt động tốt. Và hiển nhiên nếu nó không làm được điều đó thì họ sẽ cho rằng là nó bị hỏng. Tuy nhiên để xác định được nguyên nhân của lỗi đó trong vô số hàng code có thể mất từ vài phút cho đến vài tuần.

Giả sử tính năng tìm kiếm trên một trang web bị lỗi, người dùng nhập vào tìm kiếm mà không có gì xảy ra. Tất cả người dùng đều biết là chức năng tìm kiếm không hoạt động. Lập trình viên sẽ bắt đầu kiểm tra từ đây:

  • Những lỗi này có thuộc browser console?
  • Hay là do server return những data “tệ” ?
  • Nếu đúng là như vậy thì là lỗi do server hay nằm ở front-end?
  • Và nếu là trên server thì nó nằm ở đâu?
  • Do code?
  • Hay bởi Datastore?
  • Thế còn network giữa chúng thì sao?
  • Còn nếu không phải do server mà là do code ở front-end thì những code đó là của chính developer viết ra hay từ một nhóm thứ ba được nhập vào?

Đây chỉ là những câu hỏi nếu lập trình viên thực sự sửa lỗi được. Đôi khi vấn đề có thể liên quan đến vị trí địa lý. Các nhà phát triển thường sử dụng CDN để chuyển mã và hình ảnh tới trình duyệt. CDN lưu giữ các bản sao của những tài sản này ở những nơi khác nhau trên thế giới. Điều này cho phép các trang web tải nhanh hơn, vì những người ở Châu Á không phải chờ hình ảnh được chuyển từ Hoa Kỳ. Nhưng điều này lại mang đến nguy cơ là CDN bị lỗi ở châu Á và do đó, chỉ có những người ở châu Á mới tìm ra lỗi. Các nhà phát triển ở Mỹ sẽ vô cùng bực bội vì họ sẽ không tìm được vấn đề mà người dùng gặp phải. Giống như khi người khác bảo bạn bốc mùi nhưng bạn thật sự không ngửi thấy. Thật bực mình.

cdn

Còn nhiều ví dụ khác về các lỗi rất khó chịu, nhưng điểm muốn nói ở đây là gỡ lỗi là một kỹ năng khác với coding. Đó là công việc tìm tòi hơn là xây dựng nên cái gì đó. Mỗi việc cần một kiểu sáng tạo khác nhau.

Quay ngược trở về vấn đề coding, việc viết nhanh và viết dễ hiểu cũng là hai phạm trụ rất khác biệt. Cái đầu đòi hỏi khả năng tốt trong toán học và kĩ năng thứ hai đòi hỏi sự sắp xếp có trật tự logic. Việc muốn có được cả hai khả năng này quả là như một giấc mơ. Tuy vậy, đời thật thì rất khác.

Tùy vào software cũng như yêu cầu mà các developer sẽ chia ra thành 2 thành phần khác nhau. Một developer có khả năng code dễ hiểu sẽ giúp tạo ra một nền tảng để developer viết nhanh có thể tập trung và phát triển nên các thuật toán cao cấp cho nó.

Dù sẽ là lý tưởng nếu như lập trình viên có thể hoàn thiện mọi mặt, chúng ta lại chẳng có nhiều thời gian đến thế. Các lập trình viên thường sẽ đi theo những định hướng nhất định. Điều đó cũng tốt thôi. Trong lĩnh vực phần mềm, bạn chỉ cần một chuyên gia giỏi về một mảng, nhưng có thể kéo được khả năng của cả nhóm về mảng ấy lên. Đối với các lập trình viên, điều đó có nghĩa là không phải lúc nào họ cũng cần cải thiện những mặt mà họ yếu kém. Tập trung vào mảng mạnh của họ là điều quan trọng hơn nhiều.

Cũng có nghĩa là đối với các nhà quản lý và người phỏng vấn, thật sự không có khuôn mẫu nào để tuyển dụng lập trình viên cả. Tốt hơn là họ nên cân nhắc những điểm mạnh và điểm yếu hiện giờ của cả nhóm và tìm kiếm người có thể lấp vào những khoảng họ cần.

Công dân số via professorbeekum