[Funland] 30 tuổi, học lập trình em nên bắt đầu từ đâu

[Genesis_GV80]

em hóng cụ chủ thớt chuyển nghề thành công chưa ạ ?

 

[ruby_eagle]

em hóng cụ chủ thớt chuyển nghề thành công chưa ạ ?

Ko biết đã chuyển hay chưa nhưng mà cụ ấy bị tịch thu bằng lái rồi

 

[alo123567]

Cụ này cũng dân điện tử giống em.
Nhưng khác là em ra trường làm có 1 năm bên bảo hành phần cứng của FPT.
Xong em chuyển sang IT luôn.
Điện tử với tự động hóa thì về cơ bản lập trình cũng đc học ở trường ,, không nhiều sâu rộng như bên IT thôi.
Nhưng vẫn ok vì đi làm có dùng mấy kiến thức ở trường đâu. Đấy là 20 năm trước , giò mới chia nhiều chuyên ngành IT khác nhau.
Vấn đề có chuyển sang làm dev, code, lập trình đc hay ko, nó ko khó phần kỹ thuật.
Nó khác phần cách làm việc.
Dân điện tử thì kiểu làm mày mò, sửa chữa, đo đạc nhiều.
Vừa làm vừa chơi để suy nghĩ.
Làm IT như em thích hợp làm system
Em thử chuyển chuyên dev mà ko hợp, kiểu 8 tiếng ngồi code theo đề bài.
Liên tục ngày nào cũng như ngày nào
1 vài tuần thì còn được, hơn thì ko làm đc.
Nên chuyển đổi thành công hay không chủ yếu do có chấp nhận cách làm việc kiểu dân dev ko thôi ah.

 

[alo123567]

đến tầm 40 tuổi thì ai còng lưng gõ code nữa đâu nhỉ ?

Đói thì vẫn phải gõ

Em vẫn design fix và code cho sinh viên.
Nhung mà bảo em làm nghề dev thì em chịu.

 

[alo123567]

Lập trình chung chung thì nó rộng lắm, trước hết cụ phải biết cụ muốn làm về cái gì hoặc công việc cụ định làm như thế nào. Tôi sẽ liệt kê 1 số phương án cụ xem

Học và bắt tay vào việc được nhanh thì cụ bắt đầu với frontend trước, làm quen với html, css, javascript rồi thêm 1 cái framework đang nổi nào đấy như react, vue hoặc angular. Đấy là để vào việc được thôi, còn muốn giỏi cũng mất nhiều thời gian và công sức.

Cụ cũng có thể làm backend, học lâu hơn 1 chút. Bắt đầu bằng Python, Java, .Net cho thông dụng, phổ biến rồi tuỳ công việc tiếp theo mà học thêm những thứ khác.

Một hướng nữa là đi làm mobile app, cái này cũng mất thời gian vì vẫn phải học Java, Kotlin cho Android hoặc SWIFT cho Apple. Muốn làm một phát ăn ngay cho cả 2 thằng thì cụ theo react native hoặc flutter.

Nếu cụ đã có kiến thức về điện tử thì đi làm nhúng có vẻ là lựa chọn tối ưu nhất. Cái này thì cụ lại phải ngồi cày C, C++ hoặc bây giờ có thằng Rust cũng đang lên.

On the job training nói chung là rất ổn vì bắt tay vào làm người thật việc thật, nhưng sẽ hiệu quả hơn khi cụ có kiến thức cơ bản nếu không dễ nản lắm. À mà nhanh nhất có khi đi làm test, tôi thấy FPT còn tuyển cả kinh tế, tài chính các kiểu đi làm tester mà.

Nguồn tài liệu học thì bây giờ nhiều, nhan nhản trên mạng. Nhưng cá nhân tôi thấy tốt nhất là tham gia vào vài khoá học online trên Coursera, Udemy hoặc edX. Chương trình họ tổ chức hệ thống và dễ hiểu. Nếu không cần chứng chỉ thì Course ra là free còn Udemy cụ canh lúc nó giảm giá cũng chỉ 10-20USD/ khoá.



Cái này là quan niệm sai lầm, đẻ ra từ lộ trình thăng tiến nghề nghiệp của các công ty outsource Việt Nam vẽ ra: gõ code tầm 3 năm, xong lên lead rồi chuyển sang làm project manager. Đã lên lead rồi là thôi, không phải code nữa, ngồi chỉ tay 5 ngón là đủ. Ông nào tầm trên 30 mà vẫn ngồi code, làm chuyên môn là bị nhìn như loser.

Kết quả cuối cùng là đẻ ra một đội ngũ thiếu kinh nghiệm, cái gì cũng biết một tí nhưng cuối cùng lại không biết cái gì cả. Rất nhiều bạn ra trường được đi làm 2, 3 năm đã thấy lên senior với principal engineer rồi. Tài năng tất nhiên không đợi tuổi nhưng tài năng như thế thì nhiều quá :/

Thời trước thì cái tài năng cụ nói bên IT nó gần như 'luật bất thành văn'.

 

[alo123567]

À cách làm việc của dân điện tử nó khác bên dev nhá.
Làm thử bên dev kiểu nhận phiếu giao việc, code theo đề bài, hì hụi, em mới hiểu làm công nhân là như thế nào.
Đúng gọi là công nhân cổ cồn.
Ví dụ bên điện tử, sửa được 1 pan là khoái, ko xác định thời gian, tất nhiên cũng có phiếu giao việc.
Sửa xong trao đổi nhau.
Bên code dev thì ko có đợan code xong là khoái, trao đổi nhau tôi code thế lọ ông code thế chai.
Chưa xong code đã bị giục. Mệt người.

 

[lookyoung]

À cách làm việc của dân điện tử nó khác bên dev nhá.
Làm thử bên dev kiểu nhận phiếu giao việc, code theo đề bài, hì hụi, em mới hiểu làm công nhân là như thế nào.
Đúng gọi là công nhân cổ cồn.
Ví dụ bên điện tử, sửa được 1 pan là khoái, ko xác định thời gian, tất nhiên cũng có phiếu giao việc.
Sửa xong trao đổi nhau.
Bên code dev thì ko có đợan code xong là khoái, trao đổi nhau tôi code thế lọ ông code thế chai.
Chưa xong code đã bị giục. Mệt người.

Tất nhiên quy trình, môi trường làm việc của các công ty outsource khác với product. Bản thân các công ty outsource cũng có mức độ maturity khác nhau, từ công nhân code theo specs chi tiết do khách hàng đưa hoặc chỉ nhận đầu bài về business model.

Nếu hứng thú cụ có thể đọc về pair programming, mob programming, code review, daily scrum, refinement, retrospective and planning để hiểu thêm về teamwork trong phát triển phần mềm theo agile, mô hình hiện nay đang là phổ biến nhất.

 

[okokyatoho]

U50 còn kịp không các cụ, cháu thất nghiệp rồi

 

[alo123567]

Tất nhiên quy trình, môi trường làm việc của các công ty outsource khác với product. Bản thân các công ty outsource cũng có mức độ maturity khác nhau, từ công nhân code theo specs chi tiết do khách hàng đưa hoặc chỉ nhận đầu bài về business model.

Nếu hứng thú cụ có thể đọc về pair programming, mob programming, code review, daily scrum, refinement, retrospective and planning để hiểu thêm về teamwork trong phát triển phần mềm theo agile, mô hình hiện nay đang là phổ biến nhất.

Em làm rồi cụ
Đầu tiên em làm mấy công ty hệ system, support, sau em nhẩy vào 1 công ty này
Công ty này đối với em là quan trọng, vì coi như chuyển hẳn sang phần lõi của IT
Lúc em vào mới có 5, 6 người, lại tham gia thầu và dự án của JBIC chỉ định
Nên em phải tham gia đủ các khâu, từ khi bulding của khách hàng còn chưa xây xong
Họp hành các kiểu con đà điểu.
Cho đến lúc bắt đầu thuê bên B như là Fpt, Mitec làm outcsource cho bọn em
Trong lúc đấy bọn em cũng làm mấy cái soft khác nữa.
Nên coi như bọn em hầu như ai cũng tham gia và nắm quy trình hết.
Sau công ty mở rộng, tuyển thêm thì lại chia ra bắt quản.
Lý do em bỏ và quyết định chuyển hẳn sang bên dev kiểu oursuorce là vì hồi đó bắt đầu có cơ hội đi dạng H1B.
Xác định làm dev từ junior hoặc có số năm kinh nghiệm hơn tý thôi chứ ko ai họ nhận sang làm senior đâu cụ
Nên kiểu teamwork app in house như cụ nói em đâu lạ đâu, làm vị trí gì cũng chán lắm, lúc không có project làm cũng áp lực. Nhận lương ngồi chơi báo cáo láo.
Lúc có project thì ép nhau tiến độ.
Em với các chú bên đối tác thì gần như một nhà lạ gì đâu cụ.
Agile sau này cụ ạ
Tầm 2k bọn em chỉ có waterfall thôi
Mà mấy cái lý thuyết ý để vẽ proposal cho đầy nộp tài liệu thầu chứ làm gì đâu cụ

 

[50 chỗ]

Tetris

 

[ruby_eagle]

Tất nhiên quy trình, môi trường làm việc của các công ty outsource khác với product. Bản thân các công ty outsource cũng có mức độ maturity khác nhau, từ công nhân code theo specs chi tiết do khách hàng đưa hoặc chỉ nhận đầu bài về business model.

Nếu hứng thú cụ có thể đọc về pair programming, mob programming, code review, daily scrum, refinement, retrospective and planning để hiểu thêm về teamwork trong phát triển phần mềm theo agile, mô hình hiện nay đang là phổ biến nhất.

Theo cảm nhận của em, developer theo Agile method 3 năm nay thì cảm thấy quá rườm rà, nhiều meeting có cũng dc mà không có cũng chẳng sao, prductivity chẳng cải thiện hơn bao nhiêu. Việc sản phẩm có tốt hay không phụ thuộc vào con người là chủ yếu chứ không phải quy trình.
Thực ra 1 team chỉ cần Swarch giỏi, dev đủ tốt là đã cho ra 1 sản phẩm tốt rồi. Po, Pm chỉ theo dõi, báo cáo tiến độ, chịu trách nhiệm trước customer thôi.

 

[lookyoung]

Theo cảm nhận của em, developer theo Agile method 3 năm nay thì cảm thấy quá rườm rà, nhiều meeting có cũng dc mà không có cũng chẳng sao, prductivity chẳng cải thiện hơn bao nhiêu. Việc sản phẩm có tốt hay không phụ thuộc vào con người là chủ yếu chứ không phải quy trình.
Thực ra 1 team chỉ cần Swarch giỏi, dev đủ tốt là đã cho ra 1 sản phẩm tốt rồi. Po, Pm chỉ theo dõi, báo cáo tiến độ, chịu trách nhiệm trước customer thôi.

Agile tất nhiên nó chỉ là methodology còn việc sử dụng thế nào, hiệu quả đến đâu vấn đề chính vẫn là con người như cụ nói. Không thể mong 1 team với trình độ chuyên môn kém làm ra sản phẩm tốt được chỉ vì họ áp dụng scrum được. Ngược lại, con người tốt rồi mà không có quy trình tốt thì cũng sẽ không ra sản phẩm ngon lành được.

Với các dự án nhỏ, vài dev thì cụ sẽ thấy quy trình rườm rà, quá nhiều administration overhead nhưng khi dự án lớn lên, đòi hỏi collaboration với nhiều team nhiều domain khác nhau thì tôi tin cụ sẽ thấy giá trị của quy trình và documentation.

Tôi không tin nhiều doanh nghiệp IT tầm cỡ quyết định chuyển sang sử dụng Agile mà không nghiên cứu và thấy được tính hiệu quả của nó.

Tôi thì đã tham gia vào nhiều dự án cả waterfall và agile rồi thì tôi vẫn thích theo agile hơn. Ít giấy tờ, tăng collaboration, communication và có tính liên kết con người hơn

Cụ chia sẻ thêm về vụ rườm rà được không? Cụ đo productivity của team như thế nào, bằng velocity? Hơn nữa timebox trong Scrum guide chỉ là khuyến nghị, mình có thể triển khai ngắn hơn mà.

 

[alo123567]

Mà cụ thớt bắt đầu muộn thế, chưa chắc đã được tham gia dev trong dự án.
Khả năng bị dí cho product của người trước để lại.
Ko có việc gì chán hơn là lội code của ngừơi khác.

 

[ruby_eagle]

Agile tất nhiên nó chỉ là methodology còn việc sử dụng thế nào, hiệu quả đến đâu vấn đề chính vẫn là con người như cụ nói. Không thể mong 1 team với trình độ chuyên môn kém làm ra sản phẩm tốt được chỉ vì họ áp dụng scrum được. Ngược lại, con người tốt rồi mà không có quy trình tốt thì cũng sẽ không ra sản phẩm ngon lành được.

Với các dự án nhỏ, vài dev thì cụ sẽ thấy quy trình rườm rà, quá nhiều administration overhead nhưng khi dự án lớn lên, đòi hỏi collaboration với nhiều team nhiều domain khác nhau thì tôi tin cụ sẽ thấy giá trị của quy trình và documentation.

Tôi không tin nhiều doanh nghiệp IT tầm cỡ quyết định chuyển sang sử dụng Agile mà không nghiên cứu và thấy được tính hiệu quả của nó.

Tôi thì đã tham gia vào nhiều dự án cả waterfall và agile rồi thì tôi vẫn thích theo agile hơn. Ít giấy tờ, tăng collaboration, communication và có tính liên kết con người hơn

Cụ chia sẻ thêm về vụ rườm rà được không? Cụ đo productivity của team như thế nào, bằng velocity? Hơn nữa timebox trong Scrum guide chỉ là khuyến nghị, mình có thể triển khai ngắn hơn mà.

Vâng, cảm giác của em như kiểu phương pháp này nói nhiều hơn làm, quá nhiều meeting nhưng output thì rất mơ hồ, kiểu retrospective, sprint planning.. lý thuyết thì rất hay, scrum master giỏi cũng chỉ là điều hành cuộc họp mà thôi, vô hình chung meeting nhiều lại làm thêm áp lực, mất time code cho dev. Cảm nghĩ của em là như vậy. Mô hình này có vẻ không nên áp dụng với team size dưới 10 người.

 

[alo123567]

Agile tất nhiên nó chỉ là methodology còn việc sử dụng thế nào, hiệu quả đến đâu vấn đề chính vẫn là con người như cụ nói. Không thể mong 1 team với trình độ chuyên môn kém làm ra sản phẩm tốt được chỉ vì họ áp dụng scrum được. Ngược lại, con người tốt rồi mà không có quy trình tốt thì cũng sẽ không ra sản phẩm ngon lành được.

Với các dự án nhỏ, vài dev thì cụ sẽ thấy quy trình rườm rà, quá nhiều administration overhead nhưng khi dự án lớn lên, đòi hỏi collaboration với nhiều team nhiều domain khác nhau thì tôi tin cụ sẽ thấy giá trị của quy trình và documentation.

Tôi không tin nhiều doanh nghiệp IT tầm cỡ quyết định chuyển sang sử dụng Agile mà không nghiên cứu và thấy được tính hiệu quả của nó.

Tôi thì đã tham gia vào nhiều dự án cả waterfall và agile rồi thì tôi vẫn thích theo agile hơn. Ít giấy tờ, tăng collaboration, communication và có tính liên kết con người hơn

Cụ chia sẻ thêm về vụ rườm rà được không? Cụ đo productivity của team như thế nào, bằng velocity? Hơn nữa timebox trong Scrum guide chỉ là khuyến nghị, mình có thể triển khai ngắn hơn mà.

Vâng, cảm giác của em như kiểu phương pháp này nói nhiều hơn làm, quá nhiều meeting nhưng output thì rất mơ hồ, kiểu retrospective, sprint planning.. lý thuyết thì rất hay, scrum master giỏi cũng chỉ là điều hành cuộc họp mà thôi, vô hình chung meeting nhiều lại làm thêm áp lực, mất time code cho dev. Cảm nghĩ của em là như vậy. Mô hình này có vẻ không nên áp dụng với team size dưới 10 người.

Mấy món các cụ đang nói là môn công nghệ phần mềm
Cụ nào học IT mềm (ngày xưa bọn em chỉ có IT cứng và IT mềm) thì có học sơ qua cái này trong trường
Cái gì nó cũng có giá, làm quản lý thì ko đi code dạo được.

 

[lookyoung]

Vâng, cảm giác của em như kiểu phương pháp này nói nhiều hơn làm, quá nhiều meeting nhưng output thì rất mơ hồ, kiểu retrospective, sprint planning.. lý thuyết thì rất hay, scrum master giỏi cũng chỉ là điều hành cuộc họp mà thôi, vô hình chung meeting nhiều lại làm thêm áp lực, mất time code cho dev. Cảm nghĩ của em là như vậy. Mô hình này có vẻ không nên áp dụng với team size dưới 10 người.

Tôi nghĩ có thể cách áp dụng timebox vào team cụ hơi cứng nhắc, tức là nếu sprint 2 tuần thì cứ phải 4h planning hoặc 1.5h retrospective. Công ty tôi hiện tại chỉ 15p daily scrum + 30p retrospective + 30p planning cho 1 sprint 2 tuần. Tôi thấy cũng không mất thời gian nhiều lắm. Ngoài ra refinement thì không cố định mà khi nào có requirement mới sẽ họp để lên giải pháp và ra user story chi tiết + rough estimate. Planning thì chỉ xem xét đưa user story nào vào sprint tiếp theo thôi chứ ko mất thời gian tranh cãi về giải pháp nữa.

Agile luôn khuyến khích cải tiến, thay đổi và accountability là của cả team. Nếu bản thân cụ thấy rườm rà, không hiệu quả thì có thể raise your voice được mà. Nhưng lúc đó cụ phải thuyết phục được mọi người.

Tuỳ tính cách từng người nhưng tôi thích cái cách mà cả team có thể trao đổi, lên kế hoạch và tự estimate công việc của mình theo từng sprint hơn là nhận 1 tập specs dày cộp + task rồi ra một góc ngồi làm một mình

(Viết nhanh nên Anh Việt lẫn lộn, mong các cụ thông cảm)

 

[Xedap4banh2]

Các bác cho cháu hỏi học test phần mềm như thế nào ạ?

 

[alo123567]

Agile luôn khuyến khích cải tiến, thay đổi và accountability là của cả team. Nếu bản thân cụ thấy rườm rà, không hiệu quả thì có thể raise your voice được mà. Nhưng lúc đó cụ phải thuyết phục được mọi người.

Tuỳ tính cách từng người nhưng tôi thích cái cách mà cả team có thể trao đổi, lên kế hoạch và tự estimate công việc của mình theo từng sprint hơn là nhận 1 tập specs dày cộp + task rồi ra một góc ngồi làm một mình

(Viết nhanh nên Anh Việt lẫn lộn, mong các cụ thông cảm)

Chán nhất là đoạn dưới như cụ nói.
Ko rõ làm phần mềm giờ có khác trước chưa.
Trước, anh em làm phần mềm cũng trao dổi nát nước, thì có 1 vấn đề chắc là đặc thù riêng của bên làm phần mềm.
Nếu ko có việc thì ngồi chơi dài. Mãi cũng chán, có thể 3 tháng.
Nếu có việc, kiểu gì cũng bị chậm, bị giục tiến độ
Khá ức chế,
Không nói cố ý làm OT, thì code đến 10h đêm triền miên là chuyện bình thường.
100% project phần mềm bị như vậy
Không phải ai cũng thích nghi được cách làm việc như vậy đâu.

 

[Haiprozzz]

Theo cảm nhận của em, developer theo Agile method 3 năm nay thì cảm thấy quá rườm rà, nhiều meeting có cũng dc mà không có cũng chẳng sao, prductivity chẳng cải thiện hơn bao nhiêu. Việc sản phẩm có tốt hay không phụ thuộc vào con người là chủ yếu chứ không phải quy trình.
Thực ra 1 team chỉ cần Swarch giỏi, dev đủ tốt là đã cho ra 1 sản phẩm tốt rồi. Po, Pm chỉ theo dõi, báo cáo tiến độ, chịu trách nhiệm trước customer thôi.

Từ khi có Agile mọi phần mềm có vẻ lỗi nhiều hơn, cập nhật liên tục, bug cũ chưa hết bug mới lại sinh ra

 

[lookyoung]

Chán nhất là đoạn dưới như cụ nói.
Ko rõ làm phần mềm giờ có khác trước chưa.
Trước, anh em làm phần mềm cũng trao dổi nát nước, thì có 1 vấn đề chắc là đặc thù riêng của bên làm phần mềm.
Nếu ko có việc thì ngồi chơi dài. Mãi cũng chán, có thể 3 tháng.
Nếu có việc, kiểu gì cũng bị chậm, bị giục tiến độ
Khá ức chế,
Không nói cố ý làm OT, thì code đến 10h đêm triền miên là chuyện bình thường.
100% project phần mềm bị như vậy
Không phải ai cũng thích nghi được cách làm việc như vậy đâu.

Các công ty outsource, sống bằng vào các dự án tính tiền theo man-day đều gặp phải vấn đề này. Lúc thì ngồi không, lúc thì chạy vắt chân lên cổ.

Nếu đội ngũ quản lý tạm thời bỏ được tư tưởng làm cái gì cũng nghĩ đến man-day rate, ra lợi nhuận ngay thì tôi nghĩ sẽ không thiếu việc để làm với đội ngũ nhân lực như thế thay vì ngồi trà đá bàn chuyện thế sự vài tháng Nhưng nói là 1 chuyện còn vào thực tế thì đúng là quá khó. Bản thân nhiều bạn ở các công ty outsource cũng ko có ý định gắn bó lâu dài. Hoặc là làm vài năm rồi chuyển lên làm PO, PM ngồi chỉ tay giao việc hoặc nhảy sang chỗ khác lương cao hơn.