Lập trình viên hạnh phúc

Tôi đã suy nghĩ về điều này rất lâu, và nhân tiện vừa rồi bạn tôi có chia sẻ một bài báo khoa học về cảm xúc của lập trình viên ảnh hưởng tới công việc thế nên tôi muốn viết một bài blog nói về cái mà tôi cho rằng là lập trình viên hạnh phúc.

Lập trình viên Hạnh Phúc

Lập trình viên hạnh phúc là gì. Để tôi giả định một ngày làm việc thông thường.

Tôi thức dậy vào lúc 6h30 sáng, sau khi tắm rửa, tập thể dục và ăn sáng, tôi đến công ty lúc 8h. Tôi khoan khoái nhấm nháp ly cà phê sữa nóng hổi vừa ngồi đọc báo, cập nhật tin tức, lướt Facebook và trả lời thư điện tử*. Đến 9h, tôi bắt đầu làm việc. Đầu tiên, tôi mở Trello để kiểm tra các đầu việc và thời hạn còn lại, kế đó tôi mở Sketch để xem các phần thiết kế mới được cập nhật. Tôi nghĩ đến thời hạn cuối vào cuối tuần và vui vẻ mở dự án lên và tiến hành viết mã. Tôi say mê viết mã đến tập 12h trưa, tôi liếc xem đồng hồ và đứng dậy đi ăn trưa cùng mọi người. Đến 12h30 tôi quay lại công ty và ngủ một giấc ngủ ngắn sau đó thức dậy lúc 1h và tiếp tục công việc viết mã. Tôi lại hết sức tập trung vào công việc, trao đổi với cộng sự đến chiều. Tôi ra khỏi công ty lúc 5h và hoàn toàn an tâm, nhẹ nhõm về mọi thứ. Tôi đi ăn tối, mua sắm và quay về nhà lúc 7h30 sau đó tắm rửa và bắt đầu trực tuyến. Tôi có thể dành cả tối để đọc tin tức, tán gẫu bạn bè, trực tuyến Facebook hoặc học thêm một công nghệ mới. Tôi đi ngủ lúc 11h30.

Cuối tuần, nếu không phải bận lịch hẹn hò, gặp gỡ hay nghiên cứu. Tôi lên lịch trình đi chơi. Tôi mang theo chiếc máy ảnh, chiếc balo da, găng tay, áo bảo hộ và trèo lên con mô tô thân thương và làm một cuộc hành trình về miền dân dã.

Những vấn đề

Đối với tôi, một ngày như vậy là hạnh phúc và một lập trình viên có những ngày như vậy thì người đó là lập trình viên hạnh phúc. Mọi thứ rất đơn giản nhưng tôi đã từng lâm và nhiều tình huống rắc rối, nó cản trở tôi tiến tới một ngày hạnh phúc mà tôi đặt ra. Bỏ qua hết tất cả yếu tố khách quan như việc con xe già của tôi dở chứng ban sáng khiến tôi phải đi làm bằng xe bus hay việc bà bán phở gà mà tôi thích đột nhiên nghỉ bán để đi du lịch thì tôi vẫn thường gặp kha khá các điều sau đây:

  • Tôi dậy trễ vì tôi không thể đi ngủ sớm.
  • Tôi không thể đi ngủ sớm vì tôi phải làm việc ngoài giờ.
  • Tôi phải làm việc ngoài giờ bởi vì tôi phải làm nhiều việc.
  • Tôi phải làm nhiều việc bởi vì dường như công việc của tôi không bao giờ kết thúc, nó cứ kéo dài mãi, phát sinh mãi.
  • Các công việc của tôi kéo dài mãi, phát sinh mãi là do tôi phải làm theo cách mà tôi cho rằng nó đã sai ngay từ đầu nhưng tôi không cách nào sửa được.
  • Tôi mất rất nhiều thời gian để xây một thứ mới, tôi không biết rằng nó thực ra có thể làm nhanh hơn gấp 4 lần với số lượng mã ít hơn gấp 8 lần. Để đủ thờ gian, tôi đã không đọc báo buổi sáng, tôi cũng thường xuyên không ăn trưa.
  • Tôi không an tâm về sản phẩm và luôn nơm nớp lo sợ mọi thứ sẽ đỗ vỡ theo cái cách mà tôi sẽ không thể nào ngờ tới.
  • Tôi không kiểm soát được toàn bộ sự vận hành của hệ thống.
  • Tôi mất rất nhiều thời gian để đọc hiểu và tôi không biết phải bắt đầu viết mã từ đâu. Tôi không thích làm tính năng mới và nổi khùng mỗi khi cần sửa lại tính năng cũ.
  • Tôi luôn phải thủ sẵn máy tính xách tay có kết nối mạng và điện thoại bật sẵn chế độ thông báo, kể cả lúc đang ăn hay đi chơi với bạn gái. Và điều này làm bạn gái tôi nổi khùng.
  • Tôi thấy xa rời với đồng đội vì tôi cho rằng tôi làm nhiều hơn họ, tôi suy nghĩ nhiều hơn họ.
  • Tôi làm việc luôn cuối tuần.
  • Tôi hay bị xao nhãng.
  • ....

Nguyên nhân và giải quyết

Tại sao tôi lại phải tiêu tốn quá nhiều quỹ thời gian vào những việc mà lẽ ra tôi có thể tránh được, tại sao tôi phải dành quá nhiều công sức mà lẽ ra tôi có thể dành những năng lượng và thời gian đó để làm những điều khác có ích hơn như nghiên cứu thêm công nghệ mới, đọc sách, học đàn, tập bơi hay chạy mô tô đi du lịch. Trạng thái tâm lý luôn luôn trong tư thế sẵn sàng vì không gì đảm bảo rằng hệ thống không sụp đổ vì một lý do không rõ nào đó, luôn đè nặng và khiến tôi không thoải mái. Nói cho cùng, những rắc rối kia nó đều liên quan tới nhau cả, cái này là hậu quả của cái kia và kéo theo cái nọ. Mỗi người sẽ có một tình huống khác nhau, nhưng đều dẫn tới chung một kết quả là sản phẩm tồi, nhiều lỗi tốn thời gian phát triểnkhông hạnh phúc. Vậy tóm lại nguyên nhân là do đâu, tôi sẽ không thể nêu hết được nhưng tôi nghĩ rằng những nguyên nhân sau đây là thủ phạm chính.

1. Làm được nhiều không quan trọng bằng việc kiểm soát được việc mình làm

if-else Lỗi là bình thường, bất kể sản phẩm nào cũng gần như chắc chắc có lỗi. Thế nhưng chẳng ai thích nhận câu trả lời là không biết khi một lỗi xảy ra cả, và việc ngồi soi lỗi không xác định, mò mẫm trong mớ hỗn độn rất mất thời gian. Nói thì dễ, vậy làm gì để khi lỗi xảy ra ta không phải ngớ người ra và trả lời là không biết. Đơn giản nhất là kiểm soát tốt việc bạn làm, càng tiến gần tới con số 100% thì bạn sẽ không bao giờ phải nói ra câu không biết khi có lỗi xảy ra. Vậy làm sao để kiểm soát tốt việc mình làm? câu trả lời là hiểu việc bạn làm, hiểu các đoạn mãbạn viết. Việc bắt buộc hiểu toàn bộ các đoạn mã cũng đòi hỏi bạn phải có nổ lực nhiều hơn trong việc đọc các tài liệu, và tìm hiểu các khá niệm, kiến thức có liên quan tới dự án bạn đang xây dựng.

Ví dụ: khi tôi phát triển một tính năng tải lên một hình ảnh tôi gọi một lời gọi API để tải lên hình ảnh đó nhưng tôi nhận được kết quả trả về là một mã lỗi 400 và kèm theo tin nhắn thông số không hợp lệ. Tôi biết ngay vấn đề nằm ở đâu bởi vì tôi tuân thủ các quy tắc nên tôi biết đoạn mã nào đã trả về mã lỗi đó, việc còn lại chỉ là tôi xem lại các thông số gửi lên có thoã yêu cầu không. Việc kiểm soát tốt các đoạn mã bạn viết ra phụ thuộc nhiều vào trình độ của bạn, việc ứng dụng các quy tắc trong lập trình và tư duy của bạn. Nhưng hãy cố làm sao giữ cho mọi thứ thật rõ ràng tránh các kiểu logic ngầm định, đảm bảo các tính độc lập, ngắn gọn. Ngoài đặc thù riêng của nền tảng bạn đang xây dựng nó còn có các nguyên lí chung khi viết mã. Bạn hãy thử tìm hiểu thêm về nó.

2. Căng thẳng xảy ra không phải do việc quá nhiều mà là do đoạn mã tồi

if-else Bạn đã bao giờ được giao một đầu việc là bảo trì và phát triển một tính năng có sẵn, nhưng khi bạn nhìn vào trong đoạn mã đó thì bạn nhận ra rằng cuộc đời của bạn sắp khổ rồi không? Có đó, nếu như bận phải mất hàng giờ đồng hồ để đọc hiểu đoạn mã đó đồng thời mất thêm hàng giờ đồng hồ nữa để quyết định viết thêm đoạn mã mới ở đâu hoặc sửa lại các đoạn mã cũ theo yêu cầu mới. Nó là trong trường hợp lạc quan nhất, bạn tìm được đoạn mã của tính năng đó trong dự án. Nhưng có trời mới biết được liệu bạn sửa chỗ đó trong dự án nó có làm hỏng luôn một chỗ nào đó khác của dự án không (kiểm thử tự động là xa xỉ). Và vấn đề ở đây là bạn không chắc chắn. Tâm lý không chắc chắn thực tế sẽ làm bạn khó chịu và gây ra một tâm trạng không mấy thoải mái khi làm việc (tôi hay nói đùa nó là một nỗi đau kéo dài). Để tôi nói lại nhé, thay vì bạn mở dự án ra, theo các quy tắc bạn tìm được đến đoạn mã đó và sửa chữa nó, bạn chắc chắn rằng nó độc lập với các đoạn mã khác và bạn có thể an tâm rằng mọi thứ trong tầm kiểm soát thì mọi chuyện lại không như thế mọi việc có thể xong trong vòng 20-30 phút thì bạn đang phải mất cả buổi sáng và mọi thứ vẫn còn chưa chắc chắn.

Thời gian là thứ vô giá, nếu bạn làm việc nhanh hơn bạn sẽ làm được nhiều hơn. Về lâu dài, căng thẳng sẽ dẫn đến nhiều hệ luỵ, bạn không còn chút động lực nào cho công việc, cảm thấy ngán ngẫm khi phải làm công việc đó, cảm thấy bực dọc mỗi khi phải mở dự án ra sửa hoặc thêm tính năng mới hoặc thậm chí nổi khùng vì không thể sửa tận gốc một lỗi. Những tâm trạng đó rồi sẽ biến ngày làm việc của bạn trở thành tồi tệ, công việc tồi tệ và bạn luôn xem mình là nạn nhân, thật bất hạnh và tội nghiệp. Điều thê thảm hơn là đôi khi chẳng ai hiểu, bởi vì họ đơn giản là không ở trong tình thế của bạn, điều này còn làm bạn suy sụp hơn vì không có bất kì sự đồng cảm nào. (căng thẳng là nguyên nhân của nhiều hành động kì lạ mà lập trình viên hay làm: vò đầu, bứt tóc, la hét, chửi bới, weirdo...).

3. Bạn phải xây dựng nhanh một sản phẩm không đồng nghĩa với chất lượng tồi

Khá nhiều bạn vẫn còn suy nghĩ rằng việc xây dựng nhanh một sản phẩm phải đánh đổi bằng chất lượng sản phẩm hoặc nếu sản phẩm thay đổi yêu cầu liên tục thì việc xây dựng nó ổn định là điều không thể. Không phải như vậy, việc chất lượng sản phẩm tồi là bạn chọn sai người chịu trách nhiệm chứ không phải là vì thời gian giới hạn. Thực tế nếu bạn làm đúng cách, bạn còn có thể rút ngắn thời gian phát triển hoặc sửa chữa xuống hơn nữa trong khi chất lượng sản phẩm và các đoạn mã viết ra vẫn được đảm bảo. Cái chính là bạn cần tìm đúng người và trả đúng giá. Tin tôi đi nó sẽ có giá trị hơn gấp trăm lần.

Có một chiêu trò tôi đã đọc đâu đó trong giới lập trình đó là thuê hàng loạt người rất giỏi về xây dựng nền tảng trong thời gian ngắn, sau đó sa thải họ và thuê lại những người khác tay nghề thấp hơn để bảo trì, chỉ giữ lại một vài người giỏi ban đầu, bởi vì rằng bảo trì và thêm tính năng trên một hệ thống đã ổn định thì không cần phải giỏi. Trong trường hợp này hãy nên chọn công ty làm sản phẩm chất lượng cao thay vì chơi trò này vì nó vi phạm đạo đức nghề nghiệp.

4. Bạn không sử dụng cấu trúc, giải thuật vì bạn không biết chứ không phải là bạn không cần

Việc một tính năng khó phát triển và bảo trì không phải do yêu cầu khó mà là do việc cấu trúc tồi. Việc cấu trúc tồi là do hạn chế trong kiến thức hoặc thiếu hiểu biết. Nguyên nhân dẫn đến việc kiến trúc tồi còn do quá trình làm việc độc lập, không tiếp thu cái mới và quan niệm sai lầm rằng mình sẽ không cần kiến thức chuyên môn, việc học những lý thuyết ấy là nhàm chán và vô ích. Thực tế cho thấy đa phần bạn không áp dụng là do bạn không biết chứ không phải là do bạn không cần chúng.

Ví dụ khi chúng ta cần xây dựng một hệ thống cần giải quyết rất nhiều yêu cầu xử lý, bạn lưu chúng lại trong cơ sở dữ liệu và cho thiết lập định thời cứ mỗi 30 phút sẽ quét dữ liệu một lần rồi tiến hành lặp qua các công việc để thực hiện. Bạn cho rằng mọi thứ sẽ ổn thôi, nhưng thực tế thì không bao giờ như bạn nghĩ. Bởi vì trong 30 phút nếu có rất nhiều yêu cầu xử lý tới thì khi đến lần quét tiếp theo rất có thể hệ thống của bạn sẽ quá tải, hơn nữa trong 30 phút, nếu như xử lý chưa hết các yêu cầu thì hệ thống của bạn sẽ bị chồng chéo yêu cầu nếu bạn tiến hành quét lần nữa. Lúc này bạn cố gắng cải thiện bằng cách đặt một cờ để báo quá trình xử lý diễn ra xong hay chưa. Nhưng rồi bạn phát hiện nó vẫn không ổn bởi vì bạn không thể kiểm soát được vòng lặp nếu có quá nhiều công việc trong một lần quét nó sẽ làm tràn bộ nhớ hoặc nếu tiến trình bị chết giữa chừng thì hệ thống của bạn sẽ dừng vì cờ không được tắt đi. Cứ như thế, bạn gặp hết vấn đề này đến vấn đề khác khi cố cải thiện tình hình hiện tại, bạn ngày càng lún sâu hơn và mọi thứ vượt ngoài tầm kiểm soát. Cũng cùng là việc này, nhưng ở một mức hiểu biết cao hơn, bạn sử dụng cấu trúc hàng đợi cho các tiến trình xử lý. Vừa đơn giản để tối ưu hoá số lượng song song (nhiều hàng đợi), vừa đảm bảo số lượng công việc luôn được xử lý với hiệu suất cao nhất.

5. Việc có một cấu trúc đẹp cũng chưa chắc dự án đạt chất lượng

Kỷ luật là quan trọng, việc đặt ra các quy tắc khi lập trình là phải tuyệt đối tuân theo. Nếu không nó sẽ tạo ra các kẻ hở, tiền lệ xấu rất nguy hiểm dẫn tới mất kiểm soát dự án. Một căn nhà tuyệt đẹp vẫn có thể bừa bộn nếu như bạn ở dơ. Dự án đẹp vẫn có thể nhiều lỗi và mất kiểm soát nếu như bạn không tuân theo các quy tắc khi viết mã.

Các lỗi mà bạn thường mắc phải: nếu-thì lồng vào nhau, gọi lời gọi hàm lồng vào nhau, những hàm vô nghĩa (việc tạo ra một hàm chỉ để gọi một hàm khác là vô nghĩa, một hàm rỗng là vô nghĩa...), việc tạo ra một hàm làm hai việc khác nhau là không rõ ràng, hàm quá dài, không chịu xoá đi các đoạn mã không dùng nữa hoặc các đoạn mã lỗi thời. Việc thiếu các quy tắc và quy định các giá trị mặc định, các giá trị rỗng/không xác định dẫn tới các lỗi đỗ vỡ ứng dụng vì truy cập vào vùng nhớ không xác địnhv.v... tôi có thể kể nhiều hơn nữa nhưng những thứ này nó thuộc về phạm trù quy ước từng đội và hoàn toàn có thể tự xây dựng hoặc tìm hiểu trên mạng rất nhiều. Nó là tối quan trọng trong việc giữ một dự án sạch sẽ gọn gàng. Chẳng có ai than phiền một dự án sạch sẽ gọn gàng cả. Nhớ rằng, viết mã càng ít thì càng ít tốn thời gian hơn cho việc đọcsửa vì vậy, hãy thẳng tay xoá những thứ không sử dụng hoặc không cần nữa.

6. Lý thuyết lập trình không nhàm chán và vô ích

Tôi thường thích tìm hiểu những vấn đề của lập trình, của ngôn ngữ, những nguyên tắc và phương pháp. Ngoài ra tôi cũng tìm đọc sách tâm lý học. Tôi thường đem chúng vào thực tiễn khi đặt bản thân vào một tình huống hoặc suy nghĩ về kết quả của một hành động sau khi nó đã diễn ra để rút ra được bài học. Tôi nghi ngờ rằng có thể nó chỉ đúng với tôi, cho nên tôi thường trao đổi với mọi người về những tình huống đó xem họ có nghĩ giống tôi không nằm loại ra những kết luận mang tính sở thích chủ quan. Điểm mấu chốt đó là cách tôi học và kiểm thử các kết luận bằng việc trao đổi với cộng đồng vì vậy bạn đừng ngại chia sẻ những quan điểm của mình với người khác và lắng nghe thêm từ họ.

Các kiến thức hàn lâm và việc áp dụng chúng vào công việc thực sự nâng cao chất lượng của sản phẩm rất nhiều và mang lại nhiều điều thú vị cho nên cũng đừng xem nhẹ việc học những kiến thức ấy vì cho rằng chúng nhàm chán. Tin tôi đi, vì tôi rất hay nghe ai đó đặt ra một vài câu hỏi thực sự rất ngớ ngẫn vì kiến thức chuyên môn không nắm. Nền tảng có vững thì mới xây được cao, chẳng ai xây một toà tháp trăm tầng trên cái nền của một ngôi nhà cấp bốn cả. Và trình độ cũng như phương pháp của việc xây một ngôi nhà với việc xây một toà tháp là hoàn toàn khác nhau.

7. Năng lượng và sự chú ý là có giới hạn, đừng phung phí

Tôi cho rằng, mỗi người có một giới hạn năng lượng và sức chịu đựng nhất định. Tôi sẽ giả định rằng nó là 100 điểm. Mỗi ngày chúng ta giành ra 50 điểm trong số ấy để quan tâm tới xã hội, gia đình, bạn bè (tôi thường cố gắng không quan tâm tới chuyện vô nghĩa hoặc tranh cãi vớ vẫn nên chỉ mất 30 điểm cho những việc này) và 50 điểm còn lại cho công việc. Vì vậy trong công việc, tôi phải phải làm sao tối ưu 50 điểm ấy để nó chuyển hoá hoàn toàn thành sản phẩm và không bị thất thoát.

Tôi thường tối giản hoá mọi thứ từ nhỏ đến lớn. Tôi ẩn % pin đi, tôi không lưu lại những thứ mà tôi nghĩ rằng tôi sẽ không xem chúng lại lần nữa hoặc những thứ đó tôi có thể tìm lại dễ dàng hoặc chúng thường xuyên cập nhật phiên bản mới. Tôi có thể chỉ mất 20 phút cài đặt lại toàn bộ máy tính xách tay của tôi mà không cần phải sao lưu gì bởi vì tôi chẳng có gì để sao lưu cả. Tôi có thể làm việc được trên máy tính của người khác chỉ sau 10 phút tải các phần mềm yêu thích và tải các dự án của tôi về. Tôi về quê ăn tết chỉ với 2 bộ đồ (không tính bộ đang mặc), 1 cái balo 1 cái máy tính xách tay, 1 quyển sách, ví, 1 đôi vớ, chìa khoá xe và không cần cầm theo điện thoại. Tôi dự tính năm nay sẽ chỉ còn 1 bộ đồ, ví, 1 quyển sách và chiếc xe. Bí quyết ở đây là bạn hãy giữ cho mọi thứ đơn giản nhất có thể, bạn chỉ có một số lượng sự chú ý nhất định, vì vậy hãy sử dụng chúng một cách tiết kiệm nhất có thể.

8. Bạn làm gì khi bị đặt vào một tình huống đã rồi

Từ đầu đến giờ bạn chỉ thấy rằng mọi việc sẽ chỉ tốt nếu như bạn cải thiện chúng ngay từ đầu. Vậy bạn sẽ làm thế nào nếu bạn bị đặt vào một tình thế đã rồi tức là mọi thứ đi ngược lại hết với những triết lý mà bạn tuân theo. Tôi cũng đã từng như thế hơn một lần, và tôi nghĩ rằng tôi đã làm tốt chúng ở một mức độ nào đó. Cái chính là bạn phải bắt đầu cải thiện chúng, bạn phải ra sức thay đổi lại cách làm việc của đồng đội nếu như bạn là đội trưởng. Những quyết định dứt khoát của bạn chính là mấu chốt để giải quyết triệt để vấn đề tồn động, nếu như bạn phải cố gắng để giải quyết các vấn đề thì bạn phải cố gắng gấp 4 thậm chí gấp 8 lần bình thường. Mọi việc sẽ dần dần được cải thiện và bạn sẽ kiểm soát được chúng. Cụ thể là:

  • Điều tiết cảm xúc, bạn phải thật sự bình tĩnh và kiềm chế cảm xúc nếu như bạn phải làm việc với một dự án mà bạn cho rằng mã nguồn của chúng tạp nham.
  • Bạn đừng đập đi làm lại nếu như bạn không có thời gian và luôn đem lên bàn cân về lợi ích và thiệt hại nếu bạn đập đi làm lại.
  • Nếu buộc phải làm lại, bạn nên chọn ra phần cần phải làm lại nhất và tiến hành làm lại nó. Nếu đoạn mã nào không thể đọc hiểu nổi nó thì bạn cứ đơn giản là hãy hiểu thực sự yêu cầu của nó là gì, sau đó bạn xoá chúng đi và viết lại mã mới, dĩ nhiên không quên kiểm tra xem việc đó có ảnh hưởng tới các đoạn mã còn lại hay không. Việc viết lại thường sẽ nhanh hơn là đọc hiểu và sửa chữa.
  • Ra sức giải thích cho đồng đội hiểu, tạo ra các quy tắc và hãy nhớ chú ý đến cảm xúc của họ, việc họ hiểu điều bạn nói là quan trọng. Bạn hãy nêu ra lợi và hại để cho đồng đội của bạn hiểu ra và chọn cách làm thay vì bắt buộc họ phải theo quy tắc của bạn. Điều đó tạo ra sự thoải mái trong tâm lý. Độc tài chỉ thực sự tốt khi bạn tin chắc rằng bạn đúng và bạn phải là thiên tài, còn nếu bạn không phải thiên tài thì hãy cố thuyết phục đồng đội của bạn rằng bạn đúng.
  • Ra quyết định dứt khoát và tập trung cao độ. Tôi đã từng nhận một công việc là xây dựng lại một ứng dụng nội bộ. Tôi đã mất cả buổi sáng chỉ để đọc hiểu các đoạn mã. Tôi xoay sở đến trưa thì sửa được một vài lỗi nhưng tôi vẫn không thể nào làm thêm được tính năng hoặc sửa một vài lỗi khác. Sau khi đánh giá lại các yêu cầu, tôi quyết định xây dựng lại một ứng dụng nội bộ mới, và thời gian hoàn thành là dưới 4 giờ. Tôi thấy rằng mình đã làm đúng. Nếu tiếp tục với các đoạn mã di sản chắc chắn rằng có thể tôi sẽ mất đến 2 hoặc 3 ngày mà vẫn chưa xong.

Mọi sản phẩm đều có lỗi. Cách xây dựng sản phẩm, lỗi của con người, nền tảng đều thay đổi liên tục và còn tuỳ thuộc vào hoàn cảnh, vì vậy việc nó có chất lượng thấp hay cao hoặc lỗi thời hay không là có thể hiểu được. Nếu bạn tiếp quản nó, và thấy rằng cần phải cải thiện nó thì hãy bắt tay vào làm thay vì than vãn.

9. Bạn chưa thực sự làm chúng hết mình

Mọi thứ bạn làm phản ánh chính xác con người bạn, vì vậy việc chú tâm và hết mình cho một dự án dù đó là dự án của bạn hay bạn đi làm cho người khác đều tốt. Nhỡ đâu sau này, bạn cần phải cho người khác xem (có thể là nhà tuyển dụng) dự án bạn đã làm thì bạn có dám tự hào mà cho họ xem không hay vẫn sẽ cho nhưng kèm theo: Chỗ này hồi xưa làm ẩu, hay lúc này mới học viết mã nên hơi lộn xộn :p

Sau cùng

Tất cả những điều trên không nằm ngoài việc tạo ra một ngày làm việc thực sự hạnh phúc, con người sẽ cảm thấy hạnh phúc khi được làm việc chăm chỉ và sau đó được thư giãn không phải lo nghĩ. Sự căng thẳng kéo dài thì sẽ gây ra nhiều sự mệt mõi, vì vậy để chúng ta có thể thảnh thơi nhẹ nhỏm sau giờ làm việc chúng ta phải kiểm soát tốt toàn bộ những sản phẩm mà mình làm ra. Chúng ta muốn kiểm soát tốt chúng ta phải có một kiến thức nền vững, chúng ta cần phải có những luật lệ và phải có kỹ luật cao để tuân thủ tuyệt đối những luật lệ đó. Chúng ta phải mở rộng sự giao tiếp với những lập trình viên khác để trao đổi thêm về những vấn đề mà chúng ta còn chưa chắc chắn và học thêm những kiến thức mới. Sản phẩm phản ánh trực tiếp năng lực và không có gì khác phản ánh tốt hơn nên hãy làm chúng tận tâm nhất, khi mỗi dự án hoàn thành, chúng ta có thể kể về nó một cách tự hào với bạn bè, với nhà tuyển dụng hoặc với bất kì ai mà chúng ta muốn. Vậy đó, hạnh phúc với tôi có vẻ đơn giản, chắc tại tôi là lập trình viên.

Chúc các bạn trở thành lập trình viên hạnh phúc.

(*) Tác giả cố tình dịch hết mấy từ chuyên ngành thành Tiếng Việt như một trò tiêu khiển.

Huy

I gave away my old skin to hold you, as a new me. Love you, Cà Rốt Sữa

Saigon, [email protected]