Kỳ vọng tốt nghiệp so với thực tế [đóng cửa]

Khi chọn những gì chúng ta muốn học, và làm với sự nghiệp và cuộc sống của chúng ta, tất cả chúng ta đều có một số kỳ vọng về những gì nó sẽ diễn ra. Bây giờ tôi đã ở trong ngành được gần một thập kỷ, tôi đã suy nghĩ một chút về những gì tôi nghĩ (hồi tôi còn học Khoa học Máy tính), cuộc sống làm việc sẽ như thế nào, và nó thực sự biến thành như thế nào thì, là, bị, ở.

Hai cú sốc lớn nhất của tôi (hay tôi nên nói, những kỳ vọng đã bị phá vỡ) cho đến nay là số lượng công việc bảo trì liên quan đến phần mềm và sự thiếu chuyên nghiệp nói chung:

1. Bảo trì : Tại uni, tất cả chúng ta đều được bảo rằng phần lớn công việc phần mềm là bảo trì các hệ thống hiện có. Vì vậy, tôi biết để mong đợi điều này trong bản tóm tắt. Nhưng tôi không bao giờ tưởng tượng chính xác điều này sẽ trở nên quá sức như thế nào. Có lẽ đó là thứ gì đó tôi tinh thần trừng phạt và hy vọng tôi sẽ xây dựng những thứ mới mẻ từ đầu rất nhiều. Nhưng nó thực sự là trường hợp mà hầu hết các công việc đang bảo trì quá mức, sửa lỗi và định hướng hỗ trợ.

2. Thiếu tính chuyên nghiệp : Tại uni, tôi luôn có ấn tượng rằng công việc phần mềm thương mại rất định hướng theo quy trình và được thiết kế nghiêm ngặt. Tôi đã có hình ảnh về các quy trình ISO, các tài liệu kỹ thuật, mọi tính năng và lỗi được ghi lại nghiêm ngặt và một môi trường chuyên nghiệp nói chung. Nó đến như một cú sốc lớn khi nhận ra rằng hầu hết các công ty phần mềm hoạt động không khác gì một nhóm sinh viên làm việc trong một dự án lớn kéo dài một học kỳ. Và tôi đã làm việc trong cả cửa hàng hack nhanh nhẹn và doanh nghiệp vừa và nhỏ. Mặc dù tôi không nói rằng nó luôn luôn hoàn toàn "không chuyên nghiệp", nhưng chắc chắn cảm giác như ngành công nghiệp phần mềm (nói chung) khác xa với ngành kỹ thuật mạnh mẽ mà tôi mong đợi.

Có ai khác có kinh nghiệm tương tự như vậy? Những cách mà kỳ vọng của bạn về nghề nghiệp của chúng ta sẽ khác với thực tế là gì?

Tôi cảm thấy bạn đàn ông. Thực tế tôi mới tốt nghiệp cách đây hơn một năm, đã nhảy vào lời mời làm việc đầu tiên theo cách của tôi và nhận được cú sốc lớn nhất trong cuộc đời tôi.

Những điều tôi không mong đợi:

Căng thẳng ở trường và căng thẳng trong công việc không giống nhau - Sự căng thẳng khi làm việc trong một dự án trường học với bạn bè, hoặc làm việc một mình, ngay cả với thời hạn luận án lờ mờ hoặc bảo vệ dự án đặc biệt không so sánh với sự căng thẳng của thời hạn công việc dường như vô lý, vấn đề giao tiếp , (một chút về chính trị văn phòng) và thời gian khủng hoảng.

Thiếu các thực tiễn tốt nhất - Giống như kinh nghiệm của bạn về tính chuyên nghiệp. Trước khi nhận công việc đầu tiên và trong thời gian đào tạo, tôi đã vội vàng xem xét và đọc về các thực tiễn tốt nhất trong cả lập trình và công nghệ phần mềm. Những điều này không theo sau cũng như vì lý do không thực tế và, công bằng, thực tế. Và đôi khi, kiến ​​thức của bạn rất ít so với những người khác chỉ sợ những điều chưa biết và coi thường những thực hành này.

Những gì họ giảng dạy trong nhà trường là chỉ là đỉnh của tảng băng trôi - Nghĩ rằng những gì tôi đã học tự nghiên cứu và từ các lớp đã đủ để làm cho tôi qua, tôi đã bị sốc để nói rằng ít nhất như tôi nhìn chằm chằm chết lặng ở phần đầu tiên của mã tôi đã Có nghĩa vụ phải duy trì. Rất nhiều kỹ năng tôi sử dụng bây giờ đã được học trong công việc hoặc trong khi làm việc mà tôi cứ tự hỏi liệu tôi có thể làm được mà không cần bằng đại học hay không. XD

Tầm quan trọng của giao tiếp - Làm cho tôi nhận ra tất cả những lớp học tiếng Anh đó là để làm gì. Trước thế giới thực, tôi không thể thấy sự liên quan của việc có ba đến bốn lớp tiếng Anh khác nhau ở trường đại học khi nó được dạy từ khi chúng tôi học lớp một. Bạn không có ích gì trong công việc khi bạn có thể nói chuyện với máy tính nhưng không nói chuyện với mọi người.

Hầu hết các công việc bạn làm không đột phá

Khi ở Uni, tôi làm việc theo thói quen AI để điều khiển robot chơi bóng đá, tôi đã xây dựng trình biên dịch và hack vào nhân hệ điều hành.

Nhưng trong thế giới thực, 99% ^* phát triển phần mềm thực sự khá nhàm chán. Tôi luôn ngưỡng mộ các kiến ​​trúc sư hoặc nhà xây dựng, khi được hỏi "bạn làm gì để kiếm sống?" có thể chỉ vào một tòa nhà hoặc bất cứ điều gì và nói "Tôi đã làm điều đó ". Nhưng hầu hết các nhà phát triển phần mềm không thể làm điều đó. Khi được hỏi "bạn làm gì để kiếm sống?" gần nhất mà tôi từng có thể đến là khi tôi làm việc cho một công ty xây dựng phần mềm xử lý tin nhắn SMS cho các đài phát thanh và tương tự ... Tôi có thể nói, "bạn biết khi bạn nhắn tin tới một đài phát thanh để bình chọn cho một bài hát, tôi đã viết phần mềm xử lý những phiếu bầu và nội dung đó. " Vẫn không có nơi nào tuyệt vời như có thể chỉ vào một tòa nhà và nói "Tôi đã xây dựng nó."

Tất nhiên, có những người có thể nói "Tôi làm việc trên Windows" hoặc bất cứ điều gì, nhưng tôi chắc chắn họ không thực sự nói với ai đó vì sợ những câu hỏi đang được rất tiếp theo "Tôi không thể nhận được máy in của tôi để làm việc, bạn có thể sửa nó cho tôi không? "

^* và 62% của tất cả các số liệu thống kê được tạo thành tại chỗ

Nếu bạn nhìn vào phần mềm ngày nay, qua lăng kính của lịch sử kỹ thuật, đó chắc chắn là kỹ thuật của một loại nhưng đây là loại kỹ thuật mà những người không có khái niệm về vòm đã làm. Hầu hết các phần mềm ngày nay rất giống một kim tự tháp Ai Cập với hàng triệu viên gạch xếp chồng lên nhau, không có tính toàn vẹn về cấu trúc, mà chỉ được thực hiện bởi lực lượng vũ phu và hàng ngàn nô lệ. -Alan Kay, 2004

toàn bộ cuộc phỏng vấn: http://queue.acm.org/detail.cfm?id=1039523

Tôi không phải là bác sĩ thú y trong ngành; Hoàn toàn ngược lại, tôi mới tốt nghiệp nhưng từ một trường CS hàng đầu ở Mỹ Nhưng cảm giác bản năng của tôi là cách chúng tôi xây dựng phần mềm là sai. Thay vì nhấn nút tạm dừng và xem xét lại các nguyên tắc cơ bản về cách chúng tôi lập trình, chúng tôi đã nhanh chóng chuyển tiếp bằng cách sử dụng các mô hình ngày từ những năm 50, 60 liên tục thêm một chút đường lên trên. Nếu chúng ta cứ tiếp tục như vậy, chúng ta sẽ không bao giờ vượt qua được nơi chúng ta đang ở. Con người không thể quản lý sự phức tạp của những thứ có kích thước của cơ sở mã MS Windows. Chúng ta cần một cách mới. Tôi không biết đó là gì.

Tôi nghĩ rằng đây là lý do cơ bản cho cảm giác rằng các cửa hàng phần mềm lớn và nhỏ dường như tạo ra phần mềm bằng cách hack nó với nhau mà không có sự hiểu biết sâu sắc về các nguyên tắc cơ bản.

Tôi đã không nhận được một văn bằng, nhưng tôi đã chọn một chút tại các thư viện và phòng thí nghiệm đại học và cao đẳng.

• Big Iron - Các công nghệ họ đang giảng dạy chủ yếu là máy tính lớn và máy tính mini. Trưởng khoa của một trường đại học nói với tôi rằng tôi sẽ không thể có được một công việc vì tôi thậm chí còn không biết chủ nhân là gì. Tôi không có ý định làm việc trên các máy tính lớn vì tôi không đủ khả năng, nhưng tôi sẽ không ngu ngốc đến mức không chuẩn bị một chút. VAXen rất tuyệt và tôi mong được trả tiền để viết mã trên Micro VAX của chính mình trong tủ của tôi. Thật là một sự xấu hổ mà thị trường hoàn toàn nổ tung. (Hóa ra tôi có hai vị trí làm việc với máy tính lớn là nhà thầu cho IBM.)

• Kỹ thuật phần mềm - Trước thềm lập trình có cấu trúc, SASD và các phương pháp thiết kế khác, bạn có thể nghĩ rằng chúng tôi sẽ trở thành những kỹ sư thực thụ. Tôi đã làm. Nhưng các giáo viên đã hướng dẫn rất ít về các kỹ thuật thiết kế mà tôi đọc trong thư viện. Các sinh viên được tự bảo vệ mình và micros khiến cho việc viết mã trở nên quá dễ dàng cho đến khi họ nhận được câu trả lời mà họ hài lòng. Tôi đã không nhận ra nó tồi tệ như thế nào trong thị trường việc làm. Bằng cách nào đó tôi đã phải thực hiện một chút mã mới, vì vậy nó không quá nhàm chán. Nhưng tôi cũng đã tiếp quản rất nhiều, và họ đã tệ đến mức giống như một dự án mới vì tôi phải sửa rất nhiều mã. Đó là sự kết hợp giữa nghiên cứu chức năng hiện có và tạo mã mới (thay thế nó); viết các công cụ để đơn giản hóa quy trình và thiết lập quản lý dự án tốt hơn.

• Sự nghiệp công nghệ cao - Đó là một điều khi các trường học có các tòa nhà và thiết bị cũ (thiết bị thẻ đục lỗ đã được thay thế trong học kỳ trước khi tôi bắt đầu năm 1984), nhưng khi bạn làm việc trong một nhà kho thiếu ánh sáng hoặc cho một ông chủ treo cổ khi khách hàng gọi đường dây hỗ trợ, bạn bắt đầu nhận ra mô tả công việc của mình không có khả năng bao gồm nấu bỏng ngô với laser 5 megawatt.

• Phát triển chủ yếu là làm việc theo nhóm. Điều đó có nghĩa là giao tiếp (nói và đọc), đọc mã của người khác và sử dụng lại các mô-đun trước đó (cả trong nhà và bên ngoài) là điều phải đối mặt gần như hàng ngày. Ở trường đại học của tôi, ít nhất tôi đã phải viết mã với nhiều người hơn trong một vài lần, vì vậy tôi nghĩ rằng phần chính của công việc là viết mã một mình, ở nơi hoang dã. Không phải vậy.
• Giải thích mọi thứ cho những người không phải là nhà phát triển là khó (cũng được bảo vệ cho điểm đầu tiên) và bạn có trách nhiệm đưa ra quan điểm của mình (không phải là 99% khác của thế giới).
• Bài kiểm tra tốt là bài kiểm tra thất bại. (ít nhất là lần đầu tiên) Và, tất nhiên, không có thứ gọi là mã không có lỗi. Bạn không phải là một lập trình viên tồi nếu bạn có lỗi. Lỗi chỉ là một phần (rất quan trọng và tốn thời gian) trong công việc của bạn.
• Không có đạn bạc. Mỗi công nghệ đều có ưu điểm và nhược điểm.
• Đại học không dạy bạn những công nghệ tiên tiến. Nhưng ngoài ra, 90% công trình sử dụng các công nghệ khá cũ. Mà nhân tiện, đôi khi là những gì cần thiết.
• Những người phi kỹ thuật đưa ra quyết định về các giải pháp kỹ thuật , chủ yếu là vì lý do bí truyền như bảo trì, hợp tác, sẵn sàng của công nhân ...
• Bạn chỉ mới bắt đầu , padawan trẻ .

Kể từ đó, tôi đã bắt đầu nhận ra rằng thực tế rằng mã hóa là công việc bạn làm cùng với nhiều người hơn, đặc biệt là bây giờ nguồn mở nổi bật hơn. Nhưng khi tôi học đại học (cuối những năm chín mươi), tôi đã bị thuyết phục rằng tôi sẽ làm mọi thứ từ đầu và không bao giờ nhìn vào mã của người khác hoặc phải phối hợp với người khác ...

Nhìn lại, với tôi một trong những phần tốt nhất là học và dạy người khác .

• Lập trình máy tính là phi vật lý và không trực quan.
  • Khi một người xây nhà hoàn thành công việc của mình, anh ấy / cô ấy có thể đi bộ xung quanh và ngay lập tức nhìn thấy / cảm nhận nếu có bất cứ điều gì sai. Một lỗi lập trình máy tính không thể được phát hiện theo cùng một cách và có thể ẩn trong hệ thống trong nhiều tháng hoặc thậm chí nhiều thập kỷ.
  • Mặc dù một lập trình viên có thể nhìn / cảm nhận một đoạn mã nguồn thông qua việc xem xét mã, nhưng nó không được đảm bảo để phát hiện ra mọi lỗi có trong mã. Tuy nhiên, một máy tính sẽ có thể tái tạo chính xác lỗi mỗi lần bằng cách thực hiện chương trình với đầu vào nhất định. Do đó, sự hiểu biết của con người về một đoạn mã nguồn luôn là một mô hình không hoàn hảo về bản chất của nó là các hướng dẫn cho máy tính.
• Rất dễ dàng để mã một chương trình xử lý các trường hợp phổ biến nhất, nhưng hoàn toàn không xử lý các trường hợp cạnh.
  • Trong các chuyên ngành khác, việc áp dụng một biện pháp khắc phục hậu quả là tương đối dễ dàng. Thậm chí có thể có một kiến ​​thức cơ thể đặc biệt dành cho các hành động khắc phục. Không có điều đó trong Phát triển phần mềm.
  • May mắn thay, phát triển dựa trên thử nghiệm giúp mã hóa các trường hợp cạnh mà mã được cho là xử lý.
  • Thêm Mặt khác, phương pháp phát triển phần mềm nào đó dường như gợi ý rằng chúng ta có thể trích xuất giá trị kinh doanh (nhanh hơn thời gian để thị trường, vv) bằng cách có ý thức lựa chọn không đến trường hợp xử lý cạnh, và để giao tiếp những quyết định cho khách hàng.
• Khách hàng có thể tìm thấy các giá trị kinh doanh trong một phần mềm chỉ xử lý các trường hợp phổ biến nhất, do đó các nhà cung cấp phần mềm không quá quan tâm đến việc xử lý các trường hợp hiếm gặp.
  • Khách hàng chỉ cần học cách tránh các cạnh thô.

Thêm

• Sự thanh lịch của mã nguồn không được coi trọng.
  • Khách hàng không thấy sự thanh lịch của mã nguồn. Họ chỉ thấy sự thanh lịch của giao diện người dùng và các tương tác.
  • Mặt khác, các lập trình viên thường không coi trọng sự thanh lịch của giao diện người dùng và họ thường không ở trong một dự án trong một thời gian đủ dài để bắt đầu đánh giá cao một thiết kế phần mềm thanh lịch.
  • Bởi vì cả khách hàng và lập trình viên đều không coi trọng sự thanh lịch của mã nguồn, nên nó cũng sẽ không được các doanh nghiệp coi trọng.

Thêm

Hai xu của tôi: chỉ cần quen với nó.

Hình ảnh về các quy trình ISO, các tài liệu kỹ thuật, mọi tính năng và lỗi được ghi lại nghiêm ngặt và môi trường chuyên nghiệp nói chung mô tả công ty của tôi khá tốt. Mặc dù vậy, chúng tôi thực hiện các sản phẩm phần mềm / phần cứng cơ sở hạ tầng quan trọng, vì vậy, áp lực đối với chất lượng (ví dụ: chúng tôi được chứng nhận ISO 9001).

Tôi nghĩ sau khi tốt nghiệp rằng những người phụ trách sẽ có thể nhận ra công việc tốt từ công việc tồi tệ. Sau khi được trao bản sao thứ một triệu "mã thực sự tuyệt vời, lập trình viên hàng đầu của chúng tôi ghép lại" và có nó trông như thế này:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Tôi gần như đã từ bỏ việc cố gắng hiểu những gì diễn ra giữa đôi tai của ông chủ tóc nhọn. "Tuyệt vời" có nghĩa là cơn ác mộng duy trì, "tốt" có nghĩa là gặp sự cố trong làn gió nhẹ và "mớ hỗn độn khủng khiếp" có nghĩa là hoặc một cơ sở mã có cấu trúc tốt mà các kỹ sư đã từ chối đáp ứng thời hạn tục tĩu chỉ để giữ sự tỉnh táo của họ.

Tôi đã nghe nó lập luận rằng tất cả các kỹ thuật phần mềm sau dòng mã đầu tiên là bảo trì. Và điều đó chắc chắn phù hợp với kinh nghiệm của tôi. Mã duy nhất tôi đã viết mà cuối cùng không có phần lớn chi phí duy trì là mã không hiệu quả đến mức nó không bao giờ hoặc chỉ được sử dụng trong một thời gian ngắn.

Tôi nghĩ rằng bạn có thể tìm thấy các nhóm kỹ thuật vô kỷ luật phát triển và tuân theo các quy trình mạnh dẫn đến việc phát hành mã mạnh mẽ mà nhóm có thể có mức độ tin cậy cao (mặc dù tôi sẽ không tin tưởng rằng với số lượng lớn tài liệu). Tôi tin rằng tôi làm việc trong một đội như thế vào lúc này. Mặc dù tôi chắc chắn đã trải nghiệm các loại phát triển khác.

Mặc dù vậy, điều mà tôi đã đánh giá cao là thách thức không phải lúc nào cũng là tìm ra thuật toán hoàn hảo hay giải pháp sạch nhất cho vấn đề. Nhưng thường giao dịch tất cả các loại ràng buộc (tài nguyên, kiến ​​thức, tiền bạc, thời gian, kỹ năng, rủi ro, đào tạo người dùng trước đó, v.v.) để đạt được lợi tức cao nhất cho khoản đầu tư có sẵn. Đó là xây dựng một hệ thống phù hợp nhất với tất cả các yếu tố đó chứ không chỉ ảnh hưởng kỹ thuật.

Rất nhiều phần mềm không làm cho nó đến mức được sử dụng / mua đủ. Khi một người làm ra nó, nó có xu hướng dính xung quanh và chỉ "bị rối" trong việc bảo trì.

Sự mong đợi của người dùng đang tăng lên mỗi ngày cho các tính năng, nhưng trong nhiều lĩnh vực, chúng thấp hơn trong các lĩnh vực kỹ thuật. Giả sử phần mềm giao dịch ngân hàng chắc chắn và được thiết kế chuyên nghiệp như một chiếc ô tô hiện đại. Việc xử lý khối lượng là một điều kỳ diệu hiện đại, nhưng điều gì làm giảm độ tin cậy của mỗi giao dịch? Không nhiều lắm. Bài viết của bạn về chuyện tào lao đầu tiên của con chó con của bạn trên tấm thảm đã bị bỏ, vậy thì sao. Nó giống như những chiếc túi nhựa nhỏ ở cửa hàng tạp hóa. Họ làm cho hàng tỷ người trong số họ, họ xé và xé và bị ném đi. Hầu hết mọi người không quan tâm đủ để yêu cầu một chiếc túi tốt hơn.

Tôi nghĩ rằng phần mềm chất lượng được thực hiện, cuối cùng. Một số trong số đó tung ra thị trường sớm hơn hầu hết các sản phẩm thương mại. Ai được lái xe trong bản Beta?