Các bài viết ngắn - phần 4

StackOverflow Survey Result 2022

StackOverflow vừa gửi đến cộng đồng lập trình viên kết quả của cuộc khảo sát với hơn 70,000 lập trình viên(LTV) trên toàn thế giới tham gia.

Một số điểm thú vị ở kết quả này mà mình thu được là:

1. Đa số LTV trên 45 tuổi học từ sách, còn người trẻ hơn thì học từ các khóa học hay chứng chỉ trực tuyến.

2. Docker nay đã đồng hành cùng Git trở thành công cụ cơ bản của mọi LTV

3. Rust là ngôn ngữ được LTV yêu thích nhất, tiếp đến là Python, Typescript

4. Angular.js liên tiếp 3 năm được xem là đáng lo ngại nhất. React.js liên tiếp 5 năm được xem là được mong muốn nhất.

5. 85% LTV cho biết công ty của họ cho phép được làm việc từ xa

6. 62% LTV cho biết họ giành hơn 30 phút mỗi ngày để tìm kiếm cách giải quyết các vấn đề

Mời bạn đọc thêm về các số liệu rất thú vị này ở bản kết quả đầy đủ này nhé, có các biểu đồ rất dễ nhìn.

Vì sao feedback rất quan trọng

🎙Feedback có thể hiểu là đưa ra ý kiến phản hồi của một ai đó về một cái gì đó, sau một chuyện gì đó. Có 3 loại feedback thường thấy là:

🥳 Positive feedback: Phản hồi mang tính tích cực. Đưa ra để đối phương biết mình ghi nhận những cố gắng của họ rằng đang làm tốt một việc gì đó, khích lệ để tiếp tục phát huy.

✅ Constructive feeback: Phản hồi mang tính xây dựng. Đưa ra cho đối phương biết hành động của họ cần thay đổi

🤬 Destructive feedback: Đây là thể loại constructive feedback phiên bản lỗi, được đưa ra một cách vội vã, thiếu tế nhị, không đúng nơi đúng chỗ, hoặc đúng người nhưng sai thời điểm. Cũng là loại feedback phổ biến nhất trên đường, trên mạng. Tác dụng của nó là 0, còn tác hại thì vô cùng.

Vậy thì đưa ra feedback như thế nào cho hợp lý?

👨‍🦱 Be specific Đưa ra feedback đúng nơi, đúng chỗ và đúng nội dung. Và feedback như thế nào để người ta dễ take action được. ⏳ Be timely Thường thì realtime feedback là tốt nhất, nhưng nếu tình huống không cho phép thì cũng nên feedback trong 48h.

Để đưa ra feedback tốt hơn người ta nghĩ ra rất nhiều mô hình, bạn có thể search thêm với từ khóa “feedback model”. Nhìn chung các mô hình này đều xoay quanh 4 yếu tố:

👉 Context: tình huống sự việc xảy ra 👉 Behavior: hành vi những người liên quan đến vấn đề bạn đang feedback một cách khách quan nhất 👉 Impact: nói về ảnh hưởng mà hành động đó gây ra 👉 Follow up: đưa ra gợi ý cho người nhận feedback

Đây là tóm tắt nội dung của bài blog “Vì sao feedback rất quan trọng?” của anh Huy Trần trên blog snacky.blog

Bạn cũng có thể nghe nội dung bài viết này trên podcast của mình ở đây

Lộ trình lên đai của lập trình viên

Một định hướng phát triển nghề nghiệp rõ ràng sẽ giúp bạn định hướng mình đang ở đâu, đang đi theo hướng nào và sẽ là ai trong năm hay mười năm tới 🧐

Got It AI Blog giới thiệu về “Lộ trình lên đại của lập trình viên” vô cùng chi tiết và sinh động với các hình vẽ minh họa

Giai đoạn đầu tiên mà bất cứ ai cũng phải đi qua gọi là “Starting Track”, với 3 cột mốc lần lượt là:

1. Junior Software Engineer hay Software Engineer Intern

2. Software Engineer

3. Senior Software Engineer with Tech Lead add-on

Sau giai đoạn đầu, bạn sẽ đứng ở ngã ba đường, nơi bạn có hai hướng để đi: “Individual Contributor Track” hoặc là “Managerial Track”

Với “Individual Contributor Track”, có 3 cột mốc lần lượt là:

1. “Staff Engineer”

2. “Senior Staff Engineer”

3. “Principal Engineer”

Với “Managerial Track”, có 3 cột mốc lần lượt là:

1. “Engineering Manager”

2. “Director of Manager”

3. “Vice President of Engineering”

Qua đây bạn có thể thấy nếu một lập trình viên không thích làm quản lý thì con đường “Individual Contributor” là hoàn toàn khả thi và có khi còn có mức lương khủng hơn manager nữa. Nếu quan tâm bạn hãy tìm hiểu kỹ để chọn con đường phù hợp với kỹ năng của mình nhé 😉

Bạn có thể ghé đọc bài viết chi tiết ở GotIt AI Blog

Techie Story

“Techie Story” – một sister-site của cộng đồng Webuild mà mình cũng vừa biết đến. Mình đã đọc một lèo hết năm sáu câu chuyện của mọi người đủ thấy các câu chuyện chân thực và cuốn hút đến mức nào rồi.

Bạn có thể bắt gặp:

– Lam Do – Software Engineer tại Facebook kể về những điều khó nói của nữ giới trong ngành CNTT

– Đức Nghiêm – từ startup community đến ông bố đã học làm bố trong ba năm với cô con gái có năng khiếu logic như thế nào

– Chị Cúc – Google Intern với câu chuyện đầy nghị lực của một người mẹ đã cắp sách đến trường sau khi con đi học mẫu giáo, ngững dòng tự truyện đầy nghị lực làm mình cảm thấy bản thân có thêm thật nhiều động lực(vì mình cũng là một bà mẹ)

– Thắm Lê – Lead Software Engineer tại Chợ Tốt, với các tâm sự hơi khó đọc của nữ giới ở những năm đầu ngành công nghệ ở VN cũng là động lực giúp chị càng tiến xa hơn trên con đường chị đã chọn

Ngoài ra còn nhiều câu chuyện khác của các anh chị trong ngành nữa, ghé Techie

Gỡ lỗi chương trình

Hôm nay mình muốn nói về “Gỡ lỗi”(Debugging)🐞, một qui trình sửa lỗi trong chương trình phần mềm. Điều quan trọng đầu tiên cần nhớ là:

Đừng cảm thấy thất vọng khi bạn tạo ra một con bug.

Khi viết một chương trình thì việc gặp bug 🐞 là việc đương nhiên 🥲. Mình sẽ giới thiệu một số mẹo và kỹ thuật để nhận dạng bug và sửa nó hiệu quả:

✍️ Mô tả vấn đề(Describe the problem)

Để fix bug, đầu tiên bạn cần mô tả được vấn đề mà mình gặp phải.

🐞 Tái tạo lại lỗi(reproduce the bug)

Rất nhiều khi bug chỉ thỉnh thoảng xuất hiện. Để fix được những bug như vậy lập trình viên cần biết cách tái tạo lại con bug đó và tìm hiểu chính xác vấn đề mà trường hợp đó gặp phải là gì thì mới có thể sửa lỗi được.

💻 Thử thực hiện chương trình như máy tính(Play computer)

Với một chương trình phức tạp như có logic với nhiều điều kiện rẽ nhánh, hay gọi nhiều hàm khác nhau, thì việc sửa lỗi sẽ càng khoai hơn. Lúc này bạn cần tưởng tượng mình là máy tính, và với đầu vào cụ thể nào đó, bạn tự kiểm tra từng dòng một của chương trình như cách máy tính chạy để tìm manh mối cho lỗi của mình.

🏹 Sửa lỗi(fix the errors)

Viết chương trình mà editor báo lỗi hay chạy chương trình mà bị lỗi là lỗi có thể thấy và sửa ngay được. Còn nếu chương trình chạy không đúng thì cần kiểm tra lại từng đoạn code, từng dòng code, hiểu rõ từng thứ mình viết ra thì mới mong sẽ tìm ra manh mối 🧐

🛠 Dùng các công cụ hỗ trợ kiểm tra lỗi(print, log, debugger)

In ra các dòng để hiển thị kết quả của biến, hay đơn giản là code có chạy vào đó không cũng là một cách debug. Thêm nữa hãy học cách dùng debugger là như hổ mọc thêm cánh luôn nhé 😎

Mời bạn ghé đọc thêm chi tiết ở bài blog này của mình nhé.

Nội dung này thuộc BeautyOnCode’s short posts là các bài viết ngắn tóm tắt nội dung và ý kiến cá nhân từ các nguồn như các slack channels (công ty, cộng đồng), các new letters, …

Bài viết này đăng từ bài gốc của blog BeautyOnCode tại đây.

BeautyOnCode.