Có cách nào để nhanh hơn trong việc giải quyết lỗi không? Tôi vừa có một cảnh báo từ ông chủ của tôi [đóng cửa]

Tôi vừa được sếp nói rằng tôi sẽ nhận được đánh giá hiệu quả tiêu cực vào thứ Hai. Anh ấy muốn nói chuyện với tôi về lý do tại sao tôi quá chậm và tại sao tỷ lệ sửa lỗi của tôi quá thấp.

Tôi thích lập trình và giải quyết vấn đề nhưng tôi thực sự thấy công việc của mình thực sự rất khó.

Tôi thực sự đã là một lập trình viên trong khoảng 10 năm. Nhưng đây là công việc linux nhúng đa luồng đầu tiên của tôi - Tôi đã ở đây 2 năm và rõ ràng với mọi người rằng tôi vẫn đang vật lộn. Và tôi nghĩ rằng tôi đã trở nên mất tinh thần và cảm thấy bị thiệt thòi đến mức tôi đã mất rất nhiều ngọn lửa mà tôi có khi bắt đầu công việc.

Có ai đã từng ở trong một tình huống tương tự và làm thế nào để bạn tăng tỷ lệ sửa lỗi của bạn?

Cập nhật: Tôi đã xem xét. Tôi đã được đưa vào 3 tháng 'chương trình phát triển nhân viên' (thuộc loại được đề cập bởi Dunk). Không chắc chắn liệu tôi có thể biến điều này xung quanh. Nhưng ngay cả khi tôi phải tiếp tục, tôi đã học được rất nhiều từ kinh nghiệm này.

Cập nhật khác

Bây giờ là khoảng 6 tuần kể từ lần đánh giá đầu tiên. Lời khuyên của tôi cho bất cứ ai phải đối mặt với tình huống tương tự là hãy đủ khiêm tốn để nhận những lời chỉ trích và học hỏi từ những sai lầm của bạn. Và để không sợ trông ngớ ngẩn. Hỏi tải và tải câu hỏi. Cho mọi người biết bạn đang cố gắng học và tiếp tục hỏi cho đến khi bạn hiểu. Nhưng hãy chuẩn bị cho nó để không làm việc ra. Tôi đang xây dựng một danh mục mã ... cũng như cho nó bức ảnh đẹp nhất của tôi.

Một bản cập nhật khác

Tôi do dự khi đưa nó lên đây, vì tôi lo ngại rằng tôi sẽ không thể giới thiệu các nhà tuyển dụng trong tương lai vào hồ sơ stackoverflow của mình ... Nhưng dù sao, nó có thể được ai đó quan tâm khi đọc câu hỏi này, nhưng tôi thực sự đã mất công việc vài tuần trước. Tôi đang chuẩn bị cho tất cả các kỹ năng tôi cần - Tôi đã học được rất nhiều từ những lời khuyên được đưa ra ở đây.

Nhiều câu trả lời đã đặt câu hỏi về phương pháp / chiến thuật / số liệu / sếp của bạn. Nhưng bên cạnh đó là điểm. Có lẽ bạn chậm. Mỗi phòng của các nhà phát triển phải có MỘT chậm hơn các phòng còn lại, phải không? (Đó chỉ là lý thuyết tập hợp thẳng.) Vì vậy, hãy giả sử đó là bạn. Câu trả lời là, TẠI SAO bạn chậm? (Rõ ràng đó là câu hỏi bạn phải trả lời trước khi bạn có thể giải quyết câu hỏi đã nêu của mình về cách làm thế nào để nhanh hơn.)

Có thể có tất cả các loại lý do, nhưng đây là một số giải thích có thể xem xét:

1. Bạn kém thông minh hơn họ . Điều đó là có thể, phải không? (Các nghiên cứu đã chỉ ra rằng chúng tôi TẤT CẢ là ít phổ biến , ít thú vị , và (nó sẽ đi theo) kém thông minh hơn bạn bè của chúng tôi.) Vì vậy, có lẽ bạn chỉ là chậm não. Sau đó, một lần nữa, trong trường hợp của bạn, tôi nghĩ rằng điều này là không thể. Nhìn lướt qua hồ sơ StackOverflow của bạn cho thấy rằng bạn có một lịch sử đặt câu hỏi thông minh về một loạt các chủ đề. Vì vậy, bạn rõ ràng là một người suy nghĩ và có lẽ là một người tốt ở đó.

2. Bạn trải quá mỏng. Hồ sơ SO tương tự của bạn cho thấy rằng các câu hỏi của bạn bao gồm rất nhiều công nghệ trong 2 năm qua (đồ họa, web, python, c ++, c, linux, nhúng, chủ đề, ổ cắm, v.v.). Cá nhân, tôi biết rằng khi tôi rơi vào tình huống phải (hoặc muốn) đi sâu vào vô số dòng khác nhau, tôi thấy mình đang bơi ngược dòng rất nhanh (hay nói đúng hơn là rất chậm ). Có lẽ những gì bạn thực sự cần ở đây là FOCUS . Và có thể là một liều ưu tiên lành mạnh . Có cách nào bạn có thể bỏ các nồi ít quan trọng hơn vào ổ ghi phía sau và tăng nhiệt cho món ăn chính không?

3. Bạn không có niềm vui. Khi lửa tắt, động cơ hơi nước sẽ được giảm tốc. Bạn đã thừa nhận trong bài viết của mình rằng tinh thần của bạn đã bị ảnh hưởng nặng nề gần đây. Thật không may, bạn đã bị nuốt vào vòng xoáy hút sóng hài âm tự củng cố - một lực có thể phá hủy các cây cầu . Đó là một vòng xoắn quá quen thuộc: nhiệm vụ khó khăn -> căng thẳng -> thời hạn bị bỏ lỡ -> căng thẳng hơn -> cơ chế đối phó kém -> căng thẳng hơn -> chần chừ -> nhiều thời hạn bị bỏ lỡ -> chỉ trích / buôn chuyện (thực tế hoặc tưởng tượng) - > còn căng thẳng hơn. Bạn nhận được hình ảnh. Điều này hiếm khi dẫn đến bất cứ nơi nào hữu ích. Học một bài học từ những ngày tôi đi bè nước trắng: Khi bạn bị hút dưới nước bởi dòng điện lưu thông ở mặt sau của lớp 4 nhanh chóng, áo phao của bạn sẽ KHÔNGphao bạn trở lại bề mặt. Chiến lược tốt nhất (mặc dù không trực quan) là tìm đáy sông và đi ra khỏi riptide. Vì vậy, lời khuyên của tôi cho bạn là: tìm một số nền tảng , anh chàng, (bạn bè, nhà thờ, những thói quen mới lành mạnh, v.v.) và tận dụng nó để giải cứu bản thân khỏi vòng xoáy.

4. Bạn không ở trong khu vực của bạn. Michael Jordan đã làm một cầu thủ bóng chày khá khập khiễng. (OK, anh ấy vẫn tốt hơn tôi, nhưng chắc chắn là một chuyên gia phụ.) Có lẽ "linux nhúng đa luồng" không phải là hợp đồng biểu diễn của bạn. Nhưng Phát triển phần mềm là một lĩnh vực cực kỳ rộng (như bạn đã biết; cf # 2 ở trên). Là công ty của bạn đủ rộng để bạn có thể tìm thấy một ngách khác? Trong công việc cuối cùng của tôi, tôi đã được thuê như một nhà phát triển SW nhúng. (Tôi không có kinh nghiệm trong lĩnh vực đó, nhưng tôi nói với họ rằng tôi là "người học nhanh.") Tôi nhanh chóng chìm xuống như một hòn đá. Nhưng tôi vẫn làm việc chăm chỉ và tiếp tục tìm kiếm những vấn đề mà tôi đã làmbiết làm thế nào để giải quyết cho họ. Khi nó bật ra, tôi đã dần dần có thể chuyển sang các trách nhiệm mới mà tôi có thể tỏa sáng, và cuối cùng tôi đã nhận được sự khen thưởng đáng kể. Vì vậy, có lẽ bạn cần phải tái thương hiệu chính mình.

Vấn đề là: nếu bạn chậm, có một lý do. Nhưng, hey - bạn là một kỹ sư phần mềm, dude! Gỡ lỗi chính mình!

Sếp của bạn có thể đúng: bạn có thể "hoạt động kém" (nhiều hơn về điều đó trong một phút). Nhưng nó có thể không chỉ là mức độ năng lực của bạn mà đáng trách. Tôi không nghĩ rằng sẽ là một tầm với để đề xuất các lực lượng ngoài tầm kiểm soát của bạn đang khiến bạn căng thẳng, điều này có ảnh hưởng tiêu cực đến hiệu suất của bạn.

Chúng ta hãy xem xét một vài lý do mà sếp của bạn bây giờ có thể đưa ra điều này:

Văn hóa chính trị

Có thể có những lực lượng ngoài tầm kiểm soát của bạn đòi hỏi ông chủ của bạn phải nói lên mối quan tâm của mình. Điều quan trọng là phải hiểu hệ thống bạn đang làm việc. Công việc của bạn là làm cho sếp của bạn trông thật tuyệt. Cách duy nhất để làm điều đó là hiểu những áp lực mà anh ấy / cô ấy phải chịu.

Có khả năng

Có thể khả năng đó không ngang tầm, như bạn nói, ông công khai. Đây là những gì tôi sẽ làm trong tình huống này:

Nhận phản hồi cụ thể từ sếp của bạn về cách anh ta đo lường hiệu suất. Bạn không đóng nhiều lỗi như người X? Có một số lỗi bạn nên giải quyết không? Nếu bạn đang làm việc một mình thì bạn cần đảm bảo rằng những người đo lường hiệu suất của bạn đang đo lường nó một cách công bằng và không dựa trên một số ý tưởng định sẵn.

Nếu hiệu suất của bạn chậm và dựa trên khoảng cách thực, hãy xác định khoảng trống đó và đặt kế hoạch chi tiết cùng với sếp của bạn với mục đích đóng nó.

Đánh giá này cũng là một cơ hội tốt để đưa ra sự thật rằng bạn không hài lòng. Thật tốt khi bạn đã xác định rằng bạn không yêu thích công việc này. Nhưng tìm hiểu tại sao. Phần nào trong công việc của bạn mà bạn thích và những gì bạn không? Có thể công việc này không dành cho bạn ...

Một số môi trường làm việc là không thể làm việc. Tôi đã nhìn thấy những môi trường mà không ai có thể sống sót (tiết kiệm cho những người ở thời điểm ban đầu) bởi vì rất nhiều điều không có giấy tờ và các câu hỏi đã rất nản lòng.

Bạn thực sự cần phải trung thực với chính mình về những kỳ vọng và các nguồn lực được cung cấp để giúp bạn đáp ứng chúng. Vấn đề có thể không phải là bạn.

Bạn đề cập rằng có những người làm công việc tương tự như bạn, tôi cho rằng, không gặp khó khăn, nhưng có hơn 5 năm kinh nghiệm với bạn 2. Bạn cảm thấy thế nào so với các đồng nghiệp? Họ có phải là những ngôi sao nhạc rock hoàn toàn vượt xa bạn (về mặt này), hay họ cũng giống như bạn? Có lẽ họ chỉ cần biết hệ thống khi nó đơn giản hơn ... Bạn đã đề cập đến việc có 8 năm kinh nghiệm lập trình trước khi công việc này hoạt động. Làm thế nào bạn làm điều đó? Nếu bạn đã làm rất tốt, thì điều đó sẽ cho bạn biết điều gì đó.

Phần gây ấn tượng với tôi là một chút về việc bạn mô tả bản thân như đang ở trong bóng tối đối với tất cả các lỗi xảy ra theo cách của bạn. Có thể là cơ sở mã rất rộng lớn và chưa được khám phá nên những kỳ vọng có thể không hợp lý.

Đối với bạn đã làm cho nó xa như bạn có nghĩa là bạn đã làm điều gì đó đúng và có điều gì đó sẽ cho bạn.

Tóm lại, tôi nghĩ, là bạn cần cảm thấy tốt về bản thân và về những gì bạn đang làm. Và nếu điều đó có nghĩa là tiếp tục, thì nó cũng vậy.

Tốt hơn để tiếp tục hơn là có một công việc hủy hoại cuộc sống của bạn.

Đầu tiên, lưu ý: câu trả lời này chỉ có thể áp dụng cho một số khu vực nhất định khi sa thải nhân viên mà không có sự thôi việc là bất hợp pháp. Mà nói...

Đây có thể là một trường hợp sa thải Xây dựng và là bất hợp pháp.

Chiến thuật là làm mất tinh thần và hạ thấp lòng tự trọng của nhân viên cho đến khi họ nghỉ việc. Đó là một cách để công ty tiết kiệm tiền bằng cách không phải trả tiền thôi việc, hoặc giải quyết vấn đề phải đối đầu với nhân viên và sa thải họ.

Anh ấy muốn nói chuyện với tôi về lý do tại sao tôi quá chậm và tại sao tỷ lệ sửa lỗi của tôi quá thấp.

Lỗi này rất mơ hồ. Không thể để một trong hai bên tuyên bố bên kia là sai. Bạn mất một tháng để sửa một lỗi. Vậy thì sao! Điều này đặt bạn vào vị trí phòng thủ, bằng cách phải trình bày sự thật để hỗ trợ cho yêu cầu của bạn rằng cần có một tháng. Đưa ra kỹ năng, kinh nghiệm và kiến ​​thức hiện tại của bạn như là yếu tố. Là một chủ nhân, công việc của chủ nhân là quản lý thời gian và công sức của nhân viên. Người sử dụng lao động phải là người tham gia vào rủi ro liên quan đến việc sửa lỗi. Không phải nhân viên. Anh ta luôn có sự lựa chọn để gán lỗi cho người khác.

Nếu bạn là một nhà thầu và trong hợp đồng của bạn sẽ chịu trách nhiệm sửa lỗi, thì đó là một câu chuyện hoàn toàn khác.

Có sai không khi nhà tuyển dụng phàn nàn rằng bạn đang mất quá nhiều thời gian? Hoàn toàn không, nhưng anh ta không thể bắt bạn phải chịu trách nhiệm về điều đó, và anh ta không thể sa thải bạn vì điều đó. Anh ta có thể nói với bạn "Chúng tôi không còn lỗi nào đòi hỏi kỹ năng của bạn nữa và bạn được nghỉ phép", nhưng họ phải cho bạn biết thời điểm một vấn đề mới xuất hiện mà bạn có thể khắc phục. Nếu không, họ phải chấm dứt với thôi việc. Những gì anh ấy không thể làm là giao cho bạn công việc mà bạn không thể xử lý và sau đó phàn nàn về nó. Tôi nghĩ rằng điều này là bất hợp pháp.

Tôi thích lập trình và giải quyết vấn đề nhưng tôi thực sự thấy công việc của mình thực sự rất khó.

Có một sự khác biệt lớn giữa việc đảm nhận một công việc mà bạn thấy khó khăn và nhà tuyển dụng của bạn giao cho bạn công việc quá khó khăn. Nếu bạn cảm thấy các nhiệm vụ được giao cho bạn đã được thực hiện để ngăn cản bạn có một sự nghiệp với công ty, điều này có thể là bất hợp pháp.

Tôi thực sự đã là một lập trình viên trong khoảng 10 năm. Nhưng đây là công việc linux nhúng đa luồng đầu tiên của tôi - Tôi đã ở đây 2 năm và rõ ràng với mọi người rằng tôi vẫn đang vật lộn.

Đây là lý do tại sao tôi nghĩ rằng bạn đã thấy mình ở giữa một sự sa thải mang tính xây dựng. Họ không hài lòng với bạn nên họ đổ rác cho bạn cho đến khi bạn rời đi.

Và tôi nghĩ rằng tôi đã trở nên mất tinh thần và cảm thấy bị thiệt thòi đến mức tôi đã mất rất nhiều ngọn lửa mà tôi có khi bắt đầu công việc.

Chủ lao động có trách nhiệm cung cấp một môi trường làm việc an toàn và tích cực. Không có thêm thông tin (rất có thể là cá nhân), người ngoài khó có thể nói điều gì đang thực sự xảy ra ở đây. Hãy hỏi một luật sư việc làm để được tư vấn miễn phí. Họ sẽ có thể cho bạn biết nếu bạn đang được chơi.

Người giới thiệu

Tôi không phải là luật sư, nhưng Google có một số tài liệu thảo luận về chủ đề sa thải Xây dựng đáng để đọc trước khi bạn xem xét vào Thứ Hai. Điểm chính ở đây là coi chừng giảm lương, sỉ nhục và thay đổi đột ngột sự nghiệp của bạn với công ty.

Sự thật có liên quan coi chừng:

• Không hỗ trợ đúng cách cho nhân viên trong điều kiện làm việc khó khăn
• Kỷ luật quá mức của một nhân viên Áp dụng một sự thay đổi trong nơi làm việc của nhân viên trong thời gian ngắn
• Áp dụng giảm lương hoặc tiền công

Hỏi đáp pháp lý: sa thải mang tính xây dựng

Lý do để yêu cầu sa thải mang tính xây dựng

Wikipedia

các yếu tố của một sự sa thải mang tính xây dựng

Có lẽ bạn đang được so sánh với một trong những lập trình viên ban đầu của một dự án. Tôi biết rằng là nhà phát triển ban đầu của một trong những dự án mà tôi làm việc, tôi có một lợi thế to lớn khi sửa các lỗi trong đó. Tôi không nghĩ rằng đó là do thiếu tài liệu, chỉ là tôi có thể trực giác nhảy vào những vấn đề tiềm ẩn vì bộ não của tôi biết tất cả các mã.

Nếu bạn đang được so sánh với điều đó, thì bạn sẽ không đo lường được. Bạn sẽ luôn mất nhiều thời gian hơn để bắt kịp dự án và bạn sẽ không biết tất cả các điểm tương tác tiềm năng ở đâu.

Tôi đọc bình luận của bạn về việc không tìm hiểu về các công cụ và thủ thuật mà các lập trình viên khác đang sử dụng để giải quyết vấn đề. Có lẽ để sửa lỗi tiếp theo của bạn, bạn cần thử lập trình cặp. Điều này có thể cực kỳ hữu ích. Thay phiên nhau lái bàn phím. Làm nhiều chuyện

Bạn có thể sử dụng sổ ghi chép hoặc bảng trắng để vạch ra các đường dẫn chức năng, luồng và khóa vòng đời và đánh dấu nơi bạn quan sát các bit hành vi khác nhau và nơi bạn có thể chèn các đầu dò mới.

Giải quyết các loại vấn đề luồng cấp thấp này có thể thực sự khó khăn và tôi rất thông cảm với bạn. Trước đây tôi đã phải phân tích một vài gigabyte tệp nhật ký để phát hiện ra vấn đề hai dòng. Và bạn biết những gì? Tôi đã nhìn chằm chằm vào điều đó trong nhiều ngày trước khi tôi yêu cầu sự giúp đỡ từ một kỹ sư cơ sở, người đã là thực tập sinh năm trước, và anh ấy đã đưa ra một cách tiếp cận mới và phát hiện ra vấn đề trong một giờ. Vì vậy, sau khi bạn đặt một chút thời gian vào một lỗi, hãy để mắt đến nó. Nó có thể giúp rất nhiều!

Một trong những rối loạn quản lý phổ biến nhất trong ngành này là không hiểu rằng việc gỡ lỗi thực chất là khó khăn . Tôi đã có gần 20 năm kinh nghiệm và tôi vẫn thường xuyên phải dành cả tuần để tìm ra lỗi một dòng khiến chương trình bị sập một lần trong số năm mươi. Và sau đó, nếu người quản lý của tôi không hiểu những điều này, họ sẽ làm phiền tôi vì mất một tuần để thay đổi một dòng mã.

Bạn có thể làm gì về nó?

• Ghi chú khi bạn gỡ lỗi. Chỉ cần luôn có một cửa sổ biên tập mở và viết ra dòng ý thức của bạn. Nó không có ý nghĩa với bất cứ ai trừ bạn. Bạn có thể thấy rằng điều này giúp bạn gỡ lỗi nhanh hơn, nhưng điều đó cũng có nghĩa là bạn có một cái gì đó cụ thể để chỉ ra rằng bạn không chơi Nethack cả tuần.

• So sánh ghi chú với tất cả đồng nghiệp của bạn. Mất bao lâu để sửa lỗi? Các lỗi của họ có cố định không? Làm thế nào thường xuyên họ thay đổi một điều nhỏ và thấy mình bị chôn vùi dưới một đống hậu quả tầng? Câu trả lời cho những câu hỏi này sẽ cho bạn cảm giác về việc bạn có thực sự đấu tranh so với phần còn lại của bộ phận hay không.

• Kết bạn với những người QA và những người hỗ trợ khách hàng. Họ là những người có ý tưởng tốt nhất về tầm quan trọng của các lỗi. Thường thì điều này có ít hoặc không có mối tương quan với mức độ khó của các lỗi, vì vậy bạn có thể chơi trò chơi hệ thống một chút và cố gắng được chỉ định tất cả các lỗi có độ quan trọng cao, độ khó thấp. (Điều này không thực sự gian lận. Một nhóm được tổ chức tốt luôn theo đuổi những lỗi đó trước.)

• Nếu sếp của bạn đã không cung cấp cho bạn thông tin phản hồi đầy đủ về hiệu suất của bạn trong hai năm hoạt động, thì đó là vấn đề đầu tiên đưa ra trong đánh giá hiệu suất này, và sau đó khi bạn nhận được giải pháp về vấn đề đó, để nâng cao với sếp của sếp. Hãy lịch sự, và đặc biệt đừng để họ thấy bạn tức giận như thế nào, nhưng hãy nhận những lời chỉ trích cụ thể bằng văn bản.

Trong khi bạn có thể yêu thích lập trình và giải quyết vấn đề, có thể có câu hỏi là bạn áp dụng tốt những gì bạn đang học vào các lĩnh vực khác. Có bất kỳ lỗi nào trong số hàng chục lỗi gần đây bạn đã sửa tương tự đủ để những gì giúp bạn sửa lỗi này có ích với nhau không? Đây là một phần của việc nhìn lại những gì bạn đã làm và mất bao lâu để hoàn thành nó. Chỉ là một ý tưởng để xem xét.

Thứ hai, tôi sẽ xem bạn đang làm việc như thế nào. Bạn có bị gián đoạn thường xuyên không và vì vậy khi bạn cố gắng sửa lỗi A, bạn sẽ được thông báo rằng lỗi B và C có mức độ ưu tiên cao hơn? Xem xét cẩn thận những loại thay đổi trong cách bạn làm công việc của bạn có thể giúp bạn ở đây vì đó có thể là một phần của những gì ông chủ của bạn sẽ muốn biết.

Tôi đã có một số nơi làm việc nói với tôi rằng họ không thích tôi mất bao lâu để hoàn thành công việc. Tất nhiên đây là những nơi mà nếu tôi hoàn thành một việc, 5 điều mới sẽ được thả vào lòng tôi và do đó rất dễ bị choáng ngợp. Mặc dù tôi có thể không còn làm việc ở đó nữa, tôi đã không có một giải pháp tốt cho việc làm thế nào để thu hút sự chú ý của tôi vào một số điều để tôi không cảm thấy như mình đang cố gắng làm chủ 1.000 điều cùng một lúc. Nếu tôi có thể biết một vài điều quan trọng cần hoàn thành và cách đánh giá công việc của tôi, thì tôi sẽ tốt hơn nhiều nếu tôi có một danh sách "việc cần làm" dài cả dặm và dường như không ai quan tâm nếu tôi nhận được các bộ phận của nó được thực hiện. Vì vậy, có thể có một thành phần văn hóa trong tổ chức này mặc dù tôi sẽ cẩn thận khi yêu cầu mọi thứ ở đây thay đổi.

Sau hai năm làm việc, mọi người (bạn, sếp, đồng nghiệp của bạn) nên biết bạn đang đứng ở đâu. Tức là, bạn không bao giờ nên phát hiện ra rằng bạn đã làm việc kém chỉ một lần một năm; một môi trường làm việc lý tưởng sẽ cung cấp thông tin phản hồi liên tục.

Dù sao, về cách gỡ lỗi mã đa luồng: bạn chưa đề cập đến việc đây là mã của bạn hay của người khác. Có một số trình gỡ lỗi mới và máy phân tích tĩnh có thể xử lý đồng thời. Nhưng thực sự, biết các mẫu sẽ là lựa chọn tốt nhất của bạn vì bạn sẽ biết phải tìm gì.

Nếu bạn hiểu các phần quan trọng và điều kiện cuộc đua và bế tắc hoạt động như thế nào, thì bạn sẽ ở vị trí tốt hơn để phát hiện ra những điều bất ngờ. Nếu bạn thấy "giao tiếp" giữa hai luồng không có biến điều kiện hoặc nếu tài nguyên bị thay đổi mà không có thứ tự cụ thể hoặc nếu một biến cục bộ được khai báo staticmà không có lý do rõ ràng, thì bạn đã gặp lỗi tiềm ẩn! Vì vậy, hãy tìm hiểu các thực tiễn tốt nhất về tên miền của bạn và bạn sẽ ở vị trí tốt hơn để đánh giá khi có điều gì đó khác thường.

Đừng đấu tranh một mình trừ khi bạn phải. Tuyển dụng đồng nghiệp. Nhờ họ giúp đỡ trong việc săn bọ. Hỏi họ về quá trình suy nghĩ và công cụ của họ. Có lẽ đề cập đến điều này trong đánh giá của bạn như là một phần trong kế hoạch của bạn để cải thiện. Nếu mọi người xung quanh bạn đang làm tốt hơn trên hệ thống này , có lẽ họ biết điều gì đó cụ thể?

Tôi vừa được sếp nói rằng tôi sẽ nhận được đánh giá hiệu quả tiêu cực vào thứ Hai. Anh ấy muốn nói chuyện với tôi về lý do tại sao tôi quá chậm và tại sao tỷ lệ sửa lỗi của tôi quá thấp.

Xin lưu ý rằng trong bất kỳ công ty không có chức năng nào, điều này không xảy ra theo đơn đặt hàng này. Nếu sếp của bạn quan tâm đến hiệu suất của bạn, anh ta nên đặt ra các mục tiêu ngắn hạn và nói về kết quả của bạn để tìm ra vấn đề nằm ở đâu.

Thay vào đó, anh ấy quyết định đưa ra đánh giá tiêu cực cho bạn, sau đó tìm hiểu lý do tại sao. Âm thanh như anh ta không sẵn sàng liên quan đến mình trong vấn đề, và anh ta chỉ muốn kết quả trong bảng.

Đừng nhắm đến việc giải quyết lỗi nhanh hơn. Nhằm mục đích đánh giá khả năng của chính bạn, kiểm tra cách đồng nghiệp làm việc, cách họ biết những gì họ biết và nhận thức được rằng đây không phải là một công ty lý tưởng.

Đối với các mẹo thực tế, tôi sử dụng các đoạn mã và mediawiki của riêng tôi để ghi chú. Tôi luôn có trong đầu những cuốn sách nên đọc tiếp theo, và hướng đi nào để tiếp tục việc học của mình. Học tập là con đường dẫn đến một công việc tốt hơn và một cuộc sống hạnh phúc hơn.

Đầu tiên, tăng cường sự tự tin:

Vì sao khổ? Bạn có thể dễ dàng tìm một công việc mà họ sẽ nghĩ bạn là "thượng đế" chỉ vì bạn có thể nhúng Linux bất cứ thứ gì, bất kể tỷ lệ sửa lỗi của bạn là bao nhiêu.

Dù sao, không thể đặt giới hạn thời gian để săn một con bọ. Săn bọ là một kỹ năng, không nghi ngờ gì, và hiệu quả trong nó rất có giá trị.

Bạn có thể đang thiếu một số mẹo cơ bản mà người khác biết, khiến bạn chậm hơn.

Ví dụ: nếu bạn và tôi đang làm việc trên một số phần mềm trung gian Linux và tôi đang sử dụng Valgrind để tìm các vấn đề tham nhũng bộ nhớ và điều kiện chạy dữ liệu, trong khi bạn chỉ dựa vào gdb và printf, tôi có thể sẽ đá vào mông bạn, ngay cả khi bạn thông minh hơn tôi

Ngoài ra, sự hiểu biết của bạn về đồng thời như thế nào? Nếu bạn đã phát triển được mười năm, nhưng hầu hết kinh nghiệm đó không phải là mã đa luồng, đó có thể là một vấn đề.

Bạn nên nghiên cứu đa luồng một cách chi tiết: không chỉ biết cách sử dụng API, nhưng thực sự "hiểu" nó ở mức độ sâu. Nếu bạn đang thực hiện lập trình đa luồng, bạn nên là nhà phát triển có thể nhìn vào một cơ sở mã từ cách xa một dặm và phát hiện các tình huống về tình trạng chủng tộc, bế tắc, đảo ngược ưu tiên, bỏ đói ...

Gần đây tôi đã đọc cuốn sách Làm việc hiệu quả với Bộ luật kế thừa và nó đã giúp tôi tăng cường sự tự tin khi giải quyết một vấn đề trong bất kỳ cơ sở mã hóa nào.

Nếu mã bạn đang làm việc với bất cứ điều gì không hoàn hảo, tôi nghĩ cuốn sách này sẽ giúp ích. Tôi đã thấy rằng rất nhiều thời gian để sửa lỗi, trước tiên tôi cần phải cấu trúc lại mã xung quanh để thậm chí hiểu nó, và sau đó khi tôi hiểu mã, và hy vọng làm cho mã có thể kiểm tra được, theo dõi và khắc phục vấn đề ít hơn một thử thách. (Đôi khi tôi thậm chí viết lại mã chỉ để hiểu nó, nhưng sau đó hoàn nguyên các thay đổi của mình để giảm rủi ro giới thiệu các lỗi mới. Sau đó, tôi chèn sửa lỗi của mình. Kỹ thuật đó dựa trên một mẹo từ cuốn sách.)

Tôi nghĩ đề xuất của tôi chỉ giải quyết một phần vấn đề của bạn và hơi gián tiếp, nhưng cuốn sách đáng để đọc bất kể là gì, vì làm việc với mã kế thừa là điều không thể tránh khỏi đối với bất kỳ nhà phát triển nào.

Hỏi cấp trên của bạn tốc độ sửa lỗi của bạn là bao nhiêu và tốc độ sửa lỗi của nhóm là gì. Quan trọng hơn, hãy hỏi anh ấy tốc độ sửa lỗi được đo như thế nào ...

Đây là loại số liệu không thực sự là một số liệu; nếu có, nó thậm chí còn không đáng tin cậy hơn LỘC (mặc dù đo các công cụ khác nhau). Và không có một phép đo thích hợp, không có lý do gì để buộc tội bạn về bất cứ điều gì.

Nhận ra rằng bạn làm việc VỚI nhà tuyển dụng và / hoặc khách hàng KHÔNG dành cho họ. Đừng ngần ngại đề cập rằng trong các cuộc phỏng vấn, chỉ cần thiết lập hồ sơ ngay từ đầu.

Bạn là một chuyên gia có nhiều đầu tư vào doanh nghiệp nhỏ của bạn, cụ thể là chính bạn.

Bạn sẵn sàng làm việc trong khi có một Liên minh lợi ích đẩy bạn ra khỏi giá mỗi ngày.

Nếu lực đẩy đó không ở đó trong một khoảng thời gian, thì hãy tiếp tục.

Bạn đang lãng phí thời gian và sức lực của mình cho một nhà tuyển dụng ăn mày không khiến bạn quan tâm / cập nhật các kỹ năng / bài tập đầy thách thức và / hoặc thú vị để bạn làm việc. Đó là công việc của Quản lý. Khác hơn là họ hoàn toàn trên đầu .....

Giữ niềm đam mê của bạn đi, vì đó là chìa khóa.

Tôi đã ở trong những tình huống tương tự vì tôi sợ yêu cầu giúp đỡ. Đánh giá theo những gì bạn nói trong bình luận này ...

"Nhưng điều đáng thất vọng là có một số công cụ / mẹo / thủ thuật nhất định mà tôi chỉ phát hiện ra sau khi ở đó một năm rưỡi. Tôi đã được chuyển từ nhóm này sang nhóm khác (tôi đoán rằng tôi đang hoạt động kém) và tôi đang khám phá những công cụ 'ẩn' này thường xuyên như vậy. "

... Bạn có thể đã có cùng một vấn đề tôi đã làm. Gỡ lỗi là một nghề thủ công như viết mã mà không yêu cầu gỡ lỗi nhiều như vậy ngay từ đầu. Xem các nhà phát triển khác làm việc thông qua một vấn đề gỡ lỗi có thể mang tính giáo dục cao. Yêu cầu họ giúp đỡ khi bạn gặp khó khăn trong việc sắp xếp một cái gì đó. Đặc biệt là nếu bạn đang bao phủ mặt đất mà bạn chưa từng thấy trước đây. Và làm điều đó thật lý tưởng trước khi đến lúc phải hoảng loạn vì bạn không làm được gì cả.

Điều đó nói rằng, tôi đồng ý với các ý kiến ​​rằng quản lý đã làm điều gì đó sai. Nếu ai đó đang vật lộn với một cái gì đó, họ nên được giúp đỡ với điều đó trước khi niềm vui đánh giá tiêu cực bắt đầu. Chết tiệt, nếu bất cứ ai trong nhóm đang vật lộn và không bao giờ được giúp đỡ, tôi nói rằng mọi thành viên trong nhóm đó đang làm gì đó sai (mặc dù đó có thể là kết quả trực tiếp của những người theo dõi tỷ lệ sửa lỗi quá chặt chẽ).

Những gì còn thiếu từ OP là bất kỳ đề cập đến một quy trình hoặc phương pháp lặp lại nào đang được tuân theo để giải quyết các lỗi.

Vì vậy, đầu tiên, tài liệu quá trình mà bạn làm theo. Hãy chắc chắn ghi lại từng bước trong quy trình có nghĩa là gì để đạt được.

Bạn có thể phác thảo quá trình có các nhiệm vụ như thế này:

1. Hãy chắc chắn rằng bạn hiểu chính xác vấn đề đang được báo cáo.
2. Cố gắng tái tạo vấn đề.
3. Bắt đầu chia nhỏ vấn đề thành nhiều phần nhỏ hơn
4. Hãy nghĩ về những nguyên nhân có thể của vấn đề.
5. Kiểm tra những giả thuyết đó

Sẽ rất hữu ích nếu biết các lỗi đã tồn tại trong một thời gian dài hay đang được giới thiệu với những thay đổi gần đây. Nếu các lỗi đã được đưa ra với các thay đổi gần đây, thực hiện đánh giá mã và / hoặc chỉ đọc mã mà mọi người đang tạo có thể giúp đỡ.

Tôi nghĩ rằng nếu bạn có thể xác định rõ vấn đề, ví dụ: "Tôi gặp khó khăn khi nghĩ về các giả thuyết cần kiểm tra khi cố gắng giải quyết lỗi" thì bạn có thể nhận được lời khuyên tập trung hơn.