khi tiếp thu 1 nguồn kiến thức nào đó thì ta thường bắt buộc phải đảm bảo rằng kiến thức đó đúng, hiện nay mình thấy trên mạng xuất hiện rất nhiều blog của các ltv cả người việt lẫn người nước ngoài, hoặc là các trang blog lớn như kipalog,viblo … chia sẽ rất nhiều kiến thức về lập trình, tuy nhiên mình được 1 anh chỉ rằng nếu học thì phải tìm sách có nhà xuất bản được kiểm tra các thứ rồi , hoặc lên trực tiếp website của nhà phát hành, nhà phát triển công nghệ để xem, chứ các blog nó chỉ như cưỡi ngựa xem hoa chỉ mang tính tham khảo thậm chí 1 số bloger còn bê nguyên bài của người khác sang mà không kiểm tra tính đúng đắn, vậy có nên tin tưởng vào kiến thức được chia sẽ trên các trang blog? nếu 1 bài post được đăng bởi 1 trang blog uy tín và 1 tác giả uy tín thì mình có cần kiểm chứng lại những kiến thức mà họ chia sẽ không? kiểu như họ nói blabla về kiến trúc bên dưới đi sâu vào nhân của hdh này nọ mà mình không thể kiểm chứng trực tiếp đc hoặc mình ko có kiến thức về mảng đó thì mình có cần phải tự đi xác thực lại thông tin đó hay không, hay chỉ cần TIN?
cho mình hỏi việc 1 người có tìm hiểu về 1 việc gì đó 1 lần rồi, khi bắt tay vào làm gặp lại vấn đề đó,vì có kinh nghiệm về việc đó rồi nên khi làm sẽ ít mắc sai xót và nhanh hơn (chiến thuật này mình áp dụng từ việc học của mình vd: làm các dạng đề, nhớ, hiểu công thức nên khi thi dễ đạt điểm cao), thì trong công việc có được đánh giá cao không nhỉ, giả sử mình may mắn đọc trước hoặc tìm hiểu trước về 1 công nghệ này, rồi sau đó khi làm mình đụng trúng task có công nghệ này >> mình dễ dàng hoàn thành task, nhưng lỡ ko may đụng trúng task khó, chưa từng có kiến thức về nó mình vừa phải đọc phân tích, kiểm nghiệm và áp dụng rồi cuối cùng dẫn đến trể deadline thì lỗi là do mình yếu kém phải không nhỉ, vậy có cách nào để mình chuẩn bị kiến thức để giúp mình hoàn thành công việc tốt nhất không nhỉ? và nếu trong trường hợp các bạn là sếp thì các bạn nghĩ sao về 1 nhân viên như vậy? ko tài năng nhưng cần cù và luôn mong hoàn thành công việc
Đọc blog và đọc sách không loại trừ nhau. Tất nhiên đọc sách không hẳn có không thú vị hơn nhiều so với đọc blog, nhưng không loại trừ người ta viết sách trên blog, người ta viết blog trong sách. Do đó, đừng đối lập blog với sách, cứ đọc cả 2. Ở bữa tiệc người ta bưng ra một đĩa trái cây mà bạn chỉ chăm chỉ ăn một loại thì bị… ăn chửi.
Ngày trước thế giới (mình chỉ muốn giới hạn trong lĩnh vực việc làm) vận hành theo cách khác, còn ngày nay vận hành theo cách khác. Nhất là đang trong đại dịch Covid-19 và trở về sau.
Trước đây người ta đào tạo chứng chỉ và tuyển dụng bạn dựa trên chuyên môn, dựa trên nghề mà bạn thành thạo để đưa bạn vào một vị trí.
Ngày nay, người ta không đào tạo theo các chứng chỉ kiểu MCSA, MCSE: dựa trên công nghệ, mà chuyển sang đào tạo kiểu Role-based. Các nhà tuyển dụng KHÔNG quan tâm bạn được đào tạo cái gì, bằng cấp gì cũng không quan trọng (chỉ giới hạn trong lĩnh vực CNTT vì nếu là luật sư/ bác sĩ không ai tuyển “thần y” vào làm ở bệnh viện/ tòa án) miễn bạn có thể đáp ứng được các yêu cầu và trải qua nhiều vòng phỏng vấn (để họ loại bỏ những ứng viên có năng lực ảo). Đọc thêm bài này. Gần đây nhất VN có một vụ đình đám, ngay tại VN thể hiện xu hướng này rõ nét. Đó là Hiếu PC chưa hoàn thành đại học, thậm chí còn từng là tội phạm nhưng anh ấy nghiễm nhiên được trở thành chuyên gia của một trung tâm quốc gia, đây không phải là trường hợp thuộc loại quá đặc biệt mà xu hướng này đang tiếp tục. Tài năng thiếu chứ công việc không bao giờ thiếu.
Ý 2 của bạn là việc học của học sinh, học và làm bài tập. Nếu cứ tư duy theo kiểu học tầm chương trích cú này thì tương lai chỉ là thợ code chứ không thể trở thành lập trình viên theo nghĩa người có thể tạo phần mềm. Dễ hình dung, bạn cần phân biệt một công nhân may (thợ code) với một thợ may lành nghề mở tiệm may đồ kiểu (lập trình viên). Cho nên, việc chuẩn bị kiến thức không có ích nếu nó không hướng vào việc bạn trở thành một người có học thức nhé. Kiến thức là cái luôn đã có sẵn, nhiều vô kể, bạn có chuẩn bị hay không cũng không làm kiến thức của XH bị hao hụt, bạn có thể cào kiến thức như người ta đi cào sò, cào hến. Cái ở đây đối với bản thân mỗi người là nâng cao năng lực bằng cách học (học theo nghĩa chính thống và phi chính thống, chủ động & thụ động) và thực hành cho nhuần nhuyễn rồi áp dụng vào việc giải quyết các vấn đề do cuộc sống đặt ra. Ngoài ra, người học cần luôn tự vấn, trăn trở để trả lời câu hỏi “có cách nào làm tốt hơn?” nếu đã tốt rồi có thể tốt đến mức nào nữa, giúp cho những dòng code ngày càng đẹp hơn, hiệu quả hơn, các “bài toán” được giải trông ngon lành hơn. Cái này thì phải giao lưu cọ xát trong những cộng đồng lập trình viên, tham gia các thử thách như các cuộc thi hackathon, barcamp, bootcamp,…
thanks bạn, vì hồi trước mình đi thực tập, có 1 anh hướng dẫn nói chỉ nên học cái cần thiết cho công việc hiện tại thôi ko nên học dư thừa … vd: hồi đó mình đi thực tập bên C# lúc đó chưa biết tý gì về C# cả, nên mình có tải vài cuốn sách C# như c# in nutshell, c# Head First về để nắm cơ bản, nhưng ảnh bảo cứ làm tới đâu học tới đó nhiều cái trong sách chả bao giờ dùng học làm gì, ảnh bảo mình viết tốt bằng ngôn ngữ nào thì cứ port 1 project từ ngôn ngữ đó sang C# rồi vừa học vừa tìm, mình thấy học kiểu như vậy thì nhanh nhưng nó như mì ăn liên nên hơi băng khoăng @@
Nếu bạn có mentor chỉ đường thì nên cân nhắc, cái khó nằm ở chỗ là làm sao bạn biết cái gì cần cái gì không. Nếu không có đường vạch sẵn thì thà đi từ nền tảng.
Bạn muốn port ngang thì phải sử dụng thành thục 1 toolchain từ trước chứ ko thì học từ đầu.
Thường thì cậu đọc nguồn nào cũng cần phải cross-check. Tuy nhiên, mức độ cậu cần cross-check phụ thuộc vào một số thứ:
Cách trình bày vấn đề của người viết. Nếu nó logic, đi thẳng vào vấn đề (không lan man), chi tiết và trùng với những gì cậu đã biết, cậu không cần cross-check.
Reputation của người viết. Nếu article đó từ một engineer có tiếng, người có nhiều năm kinh nghiệm, hay người đã viết ra nhiều article đúng.
Những người như vậy thường có nhiều người đọc, và họ cũng đã kiểm chứng kiến thức đó cho cậu rồi, nên cậu không cần cross-check nhiều.
Ngoài việc đọc các article đó, cậu nên đọc kỹ cả các thảo luận liên quan ở phần comment.
Nếu article đó từ một engineer tồi, cậu sẽ nhận ra điều đó dễ dàng thôi. Ví dụ:
Những bài viết hay gặp các lỗi trình bày vặt vãnh (ví dụ như lỗi chính tả, viết “bloger” thay vì “blogger”, viết sai dấu chấm, dấu phẩy, hoặc không format đoạn văn…).
Đó thường là biểu hiện của một bad writer - một red flag to tướng đối với bất cứ bài viết nào.
Những bài viết đưa ra một lập luận nào đó phi logic/quy chụp chung cho tất cả (ví dụ: “các blog nó chỉ như cưỡi ngựa xem hoa, chỉ mang tính chất tham khảo” - tớ ví dụ thôi, chứ không chỉ trích bất cứ ai có logic kém/quy chụp nhé! ).
Đó là biểu hiện của một người có logic kém. Cậu không muốn đọc mấy bài viết của mấy người như vậy đâu
Copy & paste mà không đưa ra reference tới source. Đây là dấu hiệu của beginner, không phải expert.
Người cậu muốn đọc quan điểm là expert, đúng không?
Cậu có câu trả lời sau khi đọc đoạn phân tích trên rồi ha
Một tác giả uy tín thường có rất nhiều người đọc. Họ đã check cho cậu rồi, nên cậu không cần làm điều đó.
Tuy nhiên, nếu cậu có thể làm được điều đó, thì cậu cứ làm thôi
Nếu cậu không có kiến thức về mảng đó, cậu buộc phải đọc tất cả các khái niệm, những bài báo liên quan… để hiểu bài viết và lĩnh vực đó. Nếu không, cậu chẳng có lý do gì để đọc thứ mà cậu không hiểu/không muốn hiểu (trừ khi cậu cần nó để ba hoa với các engineer khác, vốn không được thực tế cho lắm, và cậu cũng sẽ phải đối mặt với các counter question không dễ chịu lắm đâu ). Việc “tin” không có ích cho cậu nếu cậu không hiểu nó
Nếu cậu không thể kiếm chứng trực tiếp được, nhưng cậu đã có kiến thức cơ bản về lĩnh vực này, cậu hẳn có thể phần nào kiểm chứng được bài viết có phù hợp với kiến thức cậu đã có không. Nếu có, đó là dấu hiệu tốt cho một bài viết đáng tin rồi
Có chứ cậu
Thường mọi người không quan tâm tới việc cậu đã biết hay chưa, mọi người quan tâm tới việc cậu hoàn thành tốt hay không thôi. Việc đánh giá này có thể theo từng project, cũng có thể theo một quá trình dài, khi xem cách cậu thể hiện khả năng của mình với các dạng vấn đề khác nhau.
Việc cậu đã biết một thứ gì đó, rồi hoàn thành task đó tốt nhờ kinh nghiệm này là một việc hoàn toàn bình thường và healthy. Đó cũng là sự khác biệt của một người “có kinh nghiệm” và một người không có điều này đó
Tất nhiên là do cậu yếu kém rồi
Những người có kinh nghiệm cũng sẽ có thể gặp vấn đề khó (thậm chí ở mức nhiều hơn so với một fresher/junior). Tuy nhiên, cách họ tiếp cận, phân tích, thiết kế, cài đặt, kiểm thử… để đưa ra solution kịp tiến độ (well, họ cũng thường có khả năng estimate tốt, đủ để không đưa ra deadline điên rồ cho một vấn đề mà họ cũng không biết cách xử lý).
Việc cậu bị trễ deadline thể hiện hoặc cậu estimate rất tồi, hoặc kỹ năng tiếp cận vấn đề, phân tích, thiết kế, cài đặt, kiểm thử… rất tồi.
Có chứ.
Cậu hoàn toàn có thể tự học thêm vào thời gian rảnh những công nghệ mà cậu thấy có ích cho career của cậu. Cậu cũng hoàn toàn có thể nghiên cứu trước các công nghệ khi cậu thấy dự án sắp tới có khả năng dùng.
Những việc này rất có ích cho cậu, và giúp cậu hoàn thành công việc trong tương lai một cách tốt nhất.
Ngoài ra, cậu cũng có thể tự thiết lập framework giải quyết vấn đề của chính mình. Cái này tớ nghĩ còn quan trọng hơn cả việc nghiên cứu các công nghệ, tuy nhiên, cậu cần rất nhiều thời gian để hình thành ra điều này.
Tớ sẽ không đánh giá nhân viên của tớ chỉ qua kết quả làm việc, mà còn qua nỗ lực, sự tiến bộ của họ. Có thể họ không làm tốt trong những task đầu, nhưng tớ kỳ vọng sau khi được hướng dẫn, họ cải thiện và có xu hướng tiến bộ lên.
Tuy nhiên, đây là quan điểm cá nhân, nên cậu đừng kỳ vọng tất cả các manager khác cũng có quan điểm tương tự
Mở rộng ra cho cậu, một kỹ sư tốt, ngoài năng lực giải quyết vấn đề, hiểu biết cơ bản và chuyên sâu về lĩnh vực của mình, còn là một kỹ sư mong muốn học hỏi, tìm tòi, get things done, high ownership trong bất cứ hoàn cảnh nào.
Nếu không có mong muốn học hỏi, tìm tòi, kỹ sư đó không thể phát triển được.
Những bạn có xu hướng cãi lại tất cả mọi góp ý là những bạn thuộc nhóm này.
Nếu không có tinh thần “get things done”, kỹ sư đó rất có khả năng over-engineering tất cả các vấn đề => engineering cost sẽ rất cao.
Đồng thời, kiểu kỹ sư không có tinh thần này thường có xu hướng đùn đẩy vấn đề nữa.
High sense of ownership có thể nói là kỹ năng quan trọng nhất, và cũng rất khó kiếm.
Các kỹ sư có khả năng này có xu hướng làm việc chu toàn, tới mức manager của họ không cần phải assign task cho họ. Họ là người tự định nghĩa ra công việc của họ.
Hi vọng qua chia sẻ trên, cậu sẽ hiểu cậu nên làm gì để ít nhất, có thể trở thành một kỹ sư tốt
Theo mình nghĩ, sách thì có nhiều kiểu sách, mà blog thì cũng có nhiều kiểu blog.
Cái chính là bản thân mình phải biết chọn lọc thông tin.
Ví dụ có cuốn sách nói số kích thước của con trỏ tối đa là 4byte tại thời điểm chỉ có hệ điều hành 32bit, thì nó là chính xác. Nhưng tại thời điểm hiện tại, nó đã không còn chính xác nữa. Không phải cuốn sách nói sai mà nó đã không còn hợp thời đại, và người đọc cũng không biết chọn lọc nội dung.
Theo cảm quan của mình, một cuốn sách của một nhà xuất bản uy tín sẽ được biên soạn, kiểm tra nội dung kĩ lưỡng rồi mới xuất bản. Như vậy đọc sách sẽ có một chút gì đó đã được 1 nhóm nhỏ công nhận.
Blog thường mang tính trải nghiệm, chia sẻ quan điểm, ý hiểu cá nhân. Chưa được double check, và sẽ cần phải thảo luận thêm rất nhiều.
Nếu bạn là người ham học hỏi bạn sẽ luôn tìm cách nghi ngờ, diễn giải thông tin mà bạn nhận được. Bạn đọc được 1 thông tin trong sách, bạn chưa hiểu bạn sẽ hỏi trên các blog, diễn đàn để xác nhận thông tin đó. Và ngược lại khi bạn đọc blog cũng vậy.
Thông tin đến từ nhiều nguồn nhưng đích đến cuối cùng lại là bạn. Đừng từ bỏ nguồn thông tin nào cả, hãy thu thập, chọn lọc, và phán đoán thông tin. Và biết đâu, trải qua quá trình tích lũy, kế thừa, phát triển thông tin, bạn lại viết 1 cuốn sách hoặc 1 blog thì sao ;)))
2 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?
). Việc “tin” không có ích cho cậu nếu cậu không hiểu nó 
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?