Không có con đường tắt nào để có được công việc dành cho nhà phát triển: Học cách viết mã theo cách chậm rãi

Kể từ khi bắt đầu Boot.dev , tôi đã tràn ngập cái mà tôi gọi là "câu hỏi cát lún". Nhìn bề ngoài, một câu hỏi cát lún có vẻ là một câu hỏi hay. Nếu bạn có thể trả lời nó, nó sẽ đưa bạn từ vị trí hiện tại (ca đêm tại cửa hàng Wendy's) đến nơi bạn muốn (nói với bạn bè rằng bạn làm việc tại Netflix btw).

Các câu hỏi cát lún đều là về việc tìm đường tắt.

Tôi cần một công việc phát triển trong 3 tháng; cách tốt nhất để làm điều đó là gì?

Tôi thấy bạn đã đặt ra 20 khóa học trong lộ trình học tập phụ trợ của mình, nhưng *nháy mắt* tôi có thể bỏ qua khóa học nào?

Có gì sai với phím tắt?

Bây giờ, tôi muốn nói rõ : Hoàn toàn không có gì sai khi muốn đi một con đường ngắn hơn để đạt được mục tiêu nghề nghiệp của mình. Bất cứ điều gì khác sẽ là điên rồ. Nếu có một liều thuốc nào đó có thể biến bạn thành một nhà phát triển cấp cao chỉ sau một đêm, tôi khuyến khích bạn hãy dùng nó.

Về lý thuyết, tối thiểu hóa giáo dục có vẻ như là một chiến lược vững chắc, nhưng nó không hiệu quả trên thực tế.

Tại sao? Bởi vì đích đến không xác định .

Thuật toán của Dijkstra thật tuyệt vời nếu bạn biết mình đang đi đâu. Nếu không, bạn cần thứ khác.

Không ai biết họ sẽ đi đâu

Bối cảnh công nghệ là một cụm phức tạp. Tôi đã học khoảng 10 ngôn ngữ lập trình khác nhau ở trường đại học và thậm chí sau 3 năm lấy bằng, tôi vẫn không biết rằng cuối cùng mình sẽ làm kỹ sư phụ trợ viết cờ vây.

Tôi đã phỏng vấn về đủ thứ điều vô nghĩa, từ hệ thống nhúng đến phát triển giao diện người dùng. Vâng, hóa ra lớp Prolog của tôi không giúp được gì nhiều trong cuộc phỏng vấn đầu tiên của tôi, nhưng bạn biết không? Điều đó không gây tổn hại gì cả , và bây giờ, khi ai đó nói, "Đó là một hệ thống khai báo," nét mặt của tôi không phản ánh sự thiếu hiểu biết.

Nếu bạn biết chính xác những khái niệm nào bạn cần nắm vững để vượt qua cuộc phỏng vấn đầu tiên thì bạn có thể tìm ra một con đường tắt hiệu quả. Vấn đề là không có một tập hợp kiến thức chính xác nào luôn đủ để vượt qua mọi cuộc phỏng vấn đầu tiên có thể.

• Mỗi công ty đều có kho công nghệ vui nhộn của riêng mình

• Mỗi PM đều có phiên bản "nhanh nhẹn" của riêng mình

• Mỗi người quản lý tuyển dụng đều có quy trình phỏng vấn 7 bước của riêng mình

• Mỗi công việc đòi hỏi những kiến thức phức tạp khác nhau

  
  

Bạn không biết mình sẽ làm gì hàng ngày trong công việc đầu tiên khi bắt đầu học viết mã. Tôi nghe mọi người nói những câu như, "Tôi thậm chí chưa bao giờ sử dụng các kỹ năng DSA của mình tại nơi làm việc" và khi kiểm tra kỹ hơn, hóa ra họ là một "nhà phát triển" WordPress.

Vì vậy, tôi không nên quan tâm đến con đường ngắn nhất?

Bạn nên; nó không phải là nơi bạn nghĩ bạn sẽ tìm thấy nó. Con đường ngắn nhất để trở thành một lập trình viên không liên quan đến việc giảm thiểu số lượng thứ bạn cần học và xây dựng. Kiểu suy nghĩ đó dẫn đến một hành trình dài hơn và mệt mỏi hơn về mặt tinh thần. Một cái gì đó như thế này:

1. Chuyển trực tiếp vào khung web (có thể là Next.js vì bạn là người cơ bản).
2. Nhận thấy bạn có tài năng xây dựng ứng dụng TODO
3. Nhận ra rằng bạn không thể xây dựng một "hello world" nếu không có hướng dẫn
4. Cố gắng khắc phục điều đó bằng cách thực hiện nhiều hướng dẫn hơn
5. Đọc trên Twitter rằng chắc chắn Rust là ngôn ngữ tốt nhất
6. Thừa nhận thất bại dưới tay người kiểm tra khoản vay
7. Lặp lại các bước 1-4 n lần, trong đó n là d4_roll * your_stubbornness

Đường đi ngắn nhất (hoặc ít nhất là đường đi ngắn hơn) thường trông như thế này:

1. Tìm hiểu các khái niệm lập trình/CS cốt lõi bằng một số ngôn ngữ

2. Tạm thời quyết định loại chương trình bạn muốn làm (frontend, backend, mobile, v.v.)

3. Tìm hiểu các nguyên tắc cơ bản của loại lập trình đó trong các công nghệ phù hợp với nó

4. Không ngừng học hỏi và xây dựng trong khi tìm kiếm việc làm

   
   

Đừng hiểu sai ý tôi, con đường thứ hai này vẫn không hề ngắn. Lập trình không dễ dàng; xin lỗi nếu bạn được thông báo là như vậy, nhưng nếu bạn sẵn sàng nỗ lực, bạn có thể tránh được việc phải đi dạo không mục đích qua vòng thứ 9 của địa ngục hướng dẫn.

Đừng sợ công việc

Mọi người dành hàng thiên niên kỷ để cố gắng tìm ra con đường học tập ngắn nhất hoặc cố gắng tránh học những thứ mà "họ sẽ không bao giờ sử dụng lại". Họ sẽ lãng phí hàng tháng hoặc hàng năm mà không học được gì để tránh làm bất kỳ công việc không cần thiết nào. Tại sao không cắn răng và có nguy cơ dành một vài ngày để học điều gì đó không thể áp dụng trực tiếp cho công việc mà cuối cùng bạn sẽ nhận được không?

Dogecoin lên mặt trăng?

Hãy thành thật 100000000%. Một số người đang tìm kiếm một kế hoạch làm giàu nhanh chóng theo kiểu cũ. Sau vài tuần vật lộn với các vòng lặp, họ sẽ từ bỏ và mua bot giao dịch tiền điện tử được hỗ trợ bởi AI trên Fiverr. Đừng giống như những người đó.

Trở thành kỹ sư phần mềm KHÔNG phải là kế hoạch "làm giàu nhanh chóng". Đó là kế hoạch "lên-thượng lưu-trung lưu-chậm"

Bí quyết để "làm được"? Bạn phải thực sự trở nên tốt hơn.

Vì vậy, thay vì sao chép/dán bừa bãi từ StackOverflow để "sửa" lỗi tiếp theo mà bạn gặp phải, hãy dành thêm vài phút để tìm hiểu ý nghĩa của lỗi đó. Tôi không thể bắt đầu cho bạn biết có bao nhiêu PR mà tôi đã xem xét "sửa" thứ gì đó nhưng chỉ là một bản vá của một bản vá vì nhà phát triển chưa bao giờ tìm hiểu vấn đề cơ bản.

Ví dụ: một nhà phát triển Java cũ (luôn luôn là nhà phát triển Java) nhận thấy rằng đôi khi hàm này (trong Go) bị hoảng loạn:

 // sendEmail sends emails, but sometimes panics func sendEmail(e *email) error { // ... }

Họ truy cập thẳng vào Google và nhận thấy rằng sự hoảng loạn trong Go có thể được "giải quyết" bằng recover . Vì vậy, họ mở một yêu cầu kéo:

 func sendEmail(e *email) error { defer func() { if r := recover(); r != nil { log.Println("recovered from panic in sendEmail") } }() // ... }

Kiểu này có hiệu quả không? Tuy nhiên, một nhà phát triển giỏi hơn sẽ cố gắng hiểu và khắc phục vấn đề cơ bản trong mã. Họ sẽ thêm các kiểm tra nil hoặc ngừng hoàn toàn việc sử dụng con trỏ cho hàm này...

 // now sendEmail never panics func sendEmail(e email) error { // ... }

Bạn muốn có xu hướng trở nên tốt hơn chứ không phải hướng tới mục tiêu cuối cùng. Không có “kết thúc”. Có quá nhiều thứ để học. Phạm vi của tất cả công nghệ phần mềm lớn hơn phạm vi không gian tên chung của chương trình gần đây nhất của bạn.

Đó không phải là lời khuyên bạn muốn

Để có thân hình cân đối, từ bỏ cơn nghiện, xây dựng doanh nghiệp và tất cả đều khó khăn để có được công việc phát triển đầu tiên. Đừng tự làm khó mình bằng cách lãng phí thời gian tìm kiếm lối tắt.

Hãy tìm hiểu những nội dung mang tính nền tảng lâu dài, xây dựng các dự án mà bạn quan tâm và bạn sẽ ngạc nhiên về mức độ mình có thể đạt được chỉ sau một hoặc hai năm nỗ lực nhất quán.

Cũng được xuất bản ở đây .