Tôi vừa mới bắt đầu sự nghiệp là một nhà phát triển web cho một công ty cỡ trung bình. Ngay khi tôi bắt đầu, tôi đã nhận được nhiệm vụ mở rộng một ứng dụng hiện có (được mã hóa kém, được phát triển bởi nhiều lập trình viên trong nhiều năm, xử lý các nhiệm vụ giống nhau theo các cách khác nhau, cấu trúc không).

Vì vậy, sau khi tôi mở rộng thành công ứng dụng này với chức năng được yêu cầu, họ giao cho tôi nhiệm vụ duy trì hoàn toàn ứng dụng. Tất nhiên đây không phải là vấn đề, hoặc tôi nghĩ vậy. Nhưng sau đó tôi đã nghe nói tôi không được phép cải thiện mã hiện có và chỉ tập trung vào sửa lỗi khi có lỗi được báo cáo.

Từ đó trở đi tôi đã có thêm ba dự án giống như trên, mà bây giờ tôi cũng phải duy trì. Và tôi đã nhận được bốn dự án nơi tôi được phép tạo ứng dụng từ đầu và tôi cũng phải duy trì những dự án đó.

Tại thời điểm này, tôi hơi bắt đầu phát điên từ các thư hàng ngày của người dùng (người quản lý đọc) cho mỗi ứng dụng tôi phải duy trì. Họ hy vọng tôi sẽ xử lý các thư này trực tiếp trong khi cũng làm việc với hai dự án mới khác (và đã có thêm năm dự án xếp hàng sau đó). Điều đáng buồn là tôi vẫn chưa nhận được báo cáo lỗi về bất cứ điều gì mà tôi đã tự mã hóa. Vì thế tôi chỉ thỉnh thoảng nhận được những yêu cầu thay đổi khác nhau 180 độ.

Dù sao, điều này là bình thường? Theo tôi, tôi đang làm công việc tương đương với cả một nhóm các nhà phát triển.

Tôi có phải là một thằng ngốc khi ban đầu tôi mong đợi mọi thứ sẽ khác đi?

Tôi đoán bài đăng này đã trở thành một cơn thịnh nộ lớn, nhưng xin vui lòng cho tôi biết rằng điều này không giống nhau cho mọi nhà phát triển.

PS Mức lương của tôi gần như bằng nếu không thấp hơn nhân viên thu ngân ở siêu thị.

Trong một lần thực tập, tôi thấy mình đã dành nhiều thời gian để sửa lỗi. Bạn phải nhận ra rằng là một nhân viên cấp mới, bạn sẽ không có được công việc quyến rũ nhất, bạn sẽ có được công việc nặng nề mà không ai muốn. Thật không may, nhưng đó là cách nó ở mọi công việc.

Ngoài ra, bạn phải nhận ra rằng đối với một công ty, việc có mã hoạt động quan trọng hơn việc có mã sạch. Từ quan điểm của công ty bạn, bạn thay đổi cấu trúc hiện tại là tiền lãng phí khi làm lại một cái gì đó đã được thực hiện và giới thiệu nhiều lỗi hơn nữa. Thông thường các loại công ty này không phải là công ty máy tính / phần mềm nên không có người quản lý đủ cao nào có nền tảng kỹ thuật để biết rằng đôi khi bạn cần phải thực hiện các cuộc đại tu lớn này. Điều đó nói rằng, nếu công ty của bạn được điều hành bởi những người có năng lực kỹ thuật và họ hiểu giá trị của mã tốt, bạn có thể sẽ mất nhiều thời gian hơn, mặc dù đôi khi bạn cần chọn các trận chiến của mình (mục đích chính của một doanh nghiệp vẫn là kiếm tiền ).

Điều đó nói rằng, bạn không phải là không có lý khi muốn có thể để lại dấu ấn của bạn trên phần mềm và muốn công việc có ý nghĩa hơn. Thật không may là bạn phải xử lý rất nhiều dự án cùng một lúc trong khi bảo vệ các yêu cầu từ rất nhiều nhà quản lý khác nhau.

Là một lập trình viên, thực tế là bạn sẽ dành nhiều thời gian hơn để duy trì và sửa đổi mã của người khác hơn là bạn sẽ tự viết từ đầu. Nếu đây là một vấn đề cho bạn thì có lẽ bạn nên gắn bó phát triển như một sở thích và theo đuổi một nghề nghiệp khác. Nếu bạn ổn với việc duy trì mã, nhưng bạn cảm thấy mình không được sử dụng hiệu quả hoặc đang bị quá tải, thì đó là vấn đề bạn cần thảo luận với người quản lý của mình. Nếu vấn đề của bạn nghiêm trọng hơn thế hoặc nếu bạn cảm thấy người quản lý của mình không biết cách quản lý hiệu quả bộ kỹ năng của mình thì đó là một ý tưởng tốt để xem xét tìm vị trí tại một công ty khác. Với mức lương thấp đã nêu, đây có lẽ là cách hành động tốt nhất của bạn.

Có vẻ như quản lý có vấn đề trong việc quản lý khối lượng công việc của bạn và ưu tiên các nhiệm vụ. Bạn nên nói chuyện với người quản lý của mình và khiến họ hiểu rằng bạn đang bị quá tải và bạn không thể thực hiện công việc hiệu quả nếu mọi người tiếp tục bắn phá bạn với những yêu cầu mà họ muốn thực hiện ngay lập tức.

Điều đó làm cho bạn nhảy từ một nhiệm vụ và dự án khác, lãng phí rất nhiều thời gian chuyển đổi bánh răng trong tâm trí của bạn. Để công việc phát triển phần mềm hiệu quả, người ta sẽ có thể đắm mình vào một nhiệm vụ và tập trung hoàn toàn vào nó. Càng nhiều lần gián đoạn, càng lãng phí thời gian bởi chuyển đổi ngữ cảnh. Nghiên cứu cho thấy phải mất khoảng 15 phút để đắm mình và đi đến trạng thái dòng chảy nơi tâm trí của chúng ta hoạt động hiệu quả nhất. Nếu bạn bị gián đoạn cứ sau 15 phút, bạn sẽ không bao giờ bị chảy, đây là một sự lãng phí rất lớn cho cả bạn và công ty.

Vì vậy, bạn nên cố gắng đàm phán một chế độ làm việc hợp lý hơn với người quản lý của bạn . Điều này nên bao gồm ưu tiên các yêu cầu đến và lập kế hoạch trước ở một mức độ nào đó . Tất cả các yêu cầu của người dùng nên được duy trì trong một danh sách, được sắp xếp theo thứ tự ưu tiên. Và các ưu tiên không nên được quyết định bởi người yêu cầu (vì tự nhiên mọi người nghĩ rằng yêu cầu của anh ấy / cô ấy là quan trọng nhất trên trái đất), không phải bởi bạn, mà bởi một người có đủ kiến ​​thức kinh doanh và tổng quan về toàn bộ các sản phẩm bạn đang duy trì ( các chủ sở hữu sản phẩm ).

Lý tưởng nhất, tất cả các yêu cầu đến phải được nhập vào một bộ theo dõi vấn đề như JIRA hoặc Mantis . Hoặc ít nhất là gửi qua thư cho chủ sở hữu sản phẩm, không phải bạn. Và anh ấy / cô ấy nên giải quyết tất cả các khiếu nại từ người dùng về "tại sao yêu cầu của tôi chưa sẵn sàng?!", Cho phép bạn tập trung vào công việc phát triển. Nếu điều này là không thể đạt được, ít nhất bạn nên đàm phán một số cửa sổ thời gian khi bạn xem xét các yêu cầu đến và giải quyết chúng, dành một phần thời gian không bị gián đoạn chỉ để phát triển.

Nếu điều này là có thể, bước tiếp theo có thể là lên kế hoạch trước ở một mức độ nào đó. Đó là, ước tính thời gian cần thiết để thực hiện các yêu cầu ưu tiên hàng đầu, sau đó sắp xếp thời gian của bạn thành các lần chạy nước rút , có thể là một hoặc nhiều tuần mỗi lần và phân bổ đủ các nhiệm vụ cho lần chạy nước rút tiếp theo để trang trải thời gian của bạn.

Bạn có thể muốn giữ một phần thời gian của mình cho các yêu cầu khẩn cấp đến, nhưng phần còn lại có thể được lên kế hoạch trước. Và bạn cũng có thể thích tổ chức công việc trên các dự án khác nhau thành các "vệt" riêng biệt, nghĩa là làm việc cho dự án A vào thứ Hai, dự án B vào Tueday-Thứ Tư, dự án C vào sáng thứ Năm và D vào chiều, v.v. giảm chuyển đổi ngữ cảnh.

Bằng cách này, bạn có một ý tưởng sơ bộ về những gì bạn sẽ làm trong một hoặc vài tuần tới. Hơn nữa, điều này cũng đưa ra một lộ trình cho khách hàng của bạn: họ có thể thấy khi nào họ thực hiện yêu cầu nào. Bạn có thể hoặc không muốn đề cập đến từ "nhanh nhẹn" cho người quản lý của mình ở đây - về cơ bản đây là sự phát triển nhanh , nhưng một số người phản đối nhanh nhẹn mà không thực sự biết nó là gì :-)

Lưu ý rằng ngay cả khi vị trí hiện tại của bạn có vẻ được công ty đánh giá thấp, bạn càng duy trì nhiều dự án, bạn càng có nhiều quyền lực đàm phán .

Tìm kiếm và đào tạo một người thuê mới để duy trì tất cả các dự án này cần thời gian đáng kể (= tiền) cho công ty. Và bạn có thể chỉ ra một cách đúng đắn rằng mã của bạn tốt hơn rất nhiều so với các phần kế thừa của các ứng dụng này, vì vậy không có gì chắc chắn rằng họ có thể dễ dàng tìm thấy một ứng cử viên có khả năng tương tự với cùng số tiền. Chưa kể rằng nếu họ không cải thiện điều kiện làm việc, họ sẽ khiến anh chàng tiếp theo chán ngấy và bỏ cuộc nhanh như bạn ... Hãy cố gắng làm cho họ hiểu rằng đó là lợi ích tốt nhất của riêng họ để giữ bạn, và để giữ cho bạn hạnh phúc ở nơi bạn đang ở :-) Điều này có thể cung cấp cho bạn một số sức mạnh để đàm phán các điều kiện trên và / hoặc yêu cầu tăng lương.

Bạn có bao nhiêu quyền lực đàm phán - đó là một câu hỏi lớn. Quản lý của bạn có thể hoặc không thể cởi mở với những ý tưởng này, và có thể hoặc không thể tôn trọng bạn đủ để thực hiện những lời cầu xin của bạn một cách nghiêm túc. Nhưng nếu bạn chơi bài tốt, bạn có cơ hội. Và nếu họ từ chối ... bạn luôn có thể tìm kiếm một nơi làm việc tốt hơn. Tình huống này không giống nhau cho mọi người bắt đầu, mặc dù (đáng buồn thay) trải nghiệm của bạn khá điển hình. Nhưng thực sự có những nơi làm việc tốt hơn ngoài kia . Chất lượng nơi làm việc chỉ tương quan lỏng lẻo với vị trí địa lý, nhưng cảm giác của tôi là ở Bắc Âu bạn có cơ hội cao hơn mức trung bình. Vì vậy, nếu bạn không thể cải thiện đáng kể tình trạng hiện tại của mình, bạn nên bắt đầu tìm kiếm ngay lập tức , trước khi bạn hoàn toàn chán nản và kiệt sức.

Sẽ tốt hơn rất nhiều khi tìm kiếm một công việc trong khi bạn vẫn còn một công việc, vì vậy bạn không cần phải chấp nhận lời đề nghị đầu tiên chỉ vì bạn cần tiền ngay lập tức. Cuối cùng, bạn sẽ tìm thấy một nơi tốt hơn :-)

PS Mức lương của tôi gần như bằng nếu không thấp hơn nhân viên thu ngân ở siêu thị.

Heh tôi muốn viết một cái gì đó về cách thương lượng cho đến khi tôi đọc nó. Bây giờ tất cả những gì tôi có thể nói là rời đi! Giả sử đó là một nửa số tiền mà một nhà phát triển có bằng cấp thường kiếm được. Và giả sử rằng mọi thứ được cải thiện và họ cung cấp cho bạn ngay lập tức mức tăng 10%, bạn có thể tự mình nhận ra mất bao lâu để đến đó. Có vẻ như bạn không học được gì trong công việc và dường như bạn không bị bao vây bởi các kỹ sư giỏi ở đó, vì vậy thật lãng phí thời gian.

Tôi cũng ở trong một tình huống tương tự, và tôi có thể nói với bạn rằng nếu bạn tiếp tục theo dõi nó thì nó không bao giờ kết thúc. Ban quản lý sẽ tiếp tục đưa nó vào bạn, bởi vì ... họ có thể.

Có một vài suy nghĩ bổ sung mà tôi có về chủ đề này.

1. Làm những gì bạn yêu thích. Nếu bạn không thích nó, hãy chuẩn bị tinh thần để cố gắng tìm ra thứ mà bạn có thể yêu thích.

2. Giao tiếp. Truyền đạt rõ ràng sự bất lực của bạn để cung cấp cho những kỳ vọng không thực tế. Theo kinh nghiệm tương tự của tôi, kiến ​​trúc sư (người đã làm nhiều việc nhất) nói: "bạn phải quản lý những kỳ vọng của người khác về bạn."

3. Kiệt sức. Nếu bạn chưa trải qua sự kiệt sức, đừng cám dỗ số phận. Nó hút cuộc sống và tâm hồn của bạn ra khỏi tâm trí của bạn. Mặc dù nỗ lực hết sức, mục đích làm việc của bạn trở nên xám xịt, thê lương và vô nghĩa. Tôi truyền đạt lời khuyên này bởi vì bạn phải, bằng mọi giá, tránh kiệt sức.

4. Đào tạo. Đây là lớp lót bạc. Đào tạo và kinh nghiệm của bạn, trong khi bực bội, và có lẽ được trả lương thấp, trên thực tế, rất có giá trị cho sự nghiệp của bạn. Đây là ân huệ tiết kiệm của bạn để nhận ra điều này bởi vì bạn có thể tiếp thu càng nhiều việc học càng tốt và trì hoãn bất kỳ trần kính không thể tránh khỏi.

Tập trung vào những tài năng và kỹ năng bạn đang phát triển ... Những điều này sẽ đưa bạn qua những cơ hội tiếp theo trong sự nghiệp.

Bạn đang giải quyết nhiều vấn đề ở đây ... Hãy bắt đầu với điều hiển nhiên ...

Điều này có bình thường không?

Trời ơi không. Nhưng ... nó có phổ biến không? Không may là đúng vậy.

Liên quan đến lỗi sửa lỗi

Mặc dù điều đó không tha cho phần còn lại của mớ hỗn độn mà bạn phải giải quyết và nhiều dự án họ làm bạn quá tải, tôi chỉ muốn lưu ý nhanh rằng phương pháp "sửa lỗi" chỉ gây khó chịu cho bạn với tư cách là nhà phát triển , có thể là một cách tiếp cận hoàn toàn hợp lý cho công ty và quản lý của nó.

Bề mặt cho nhiều lỗi và chi phí

Càng chạm nhiều mã, bạn càng có nhiều khả năng giới thiệu các lỗi, ngay cả khi ý định của bạn là cải thiện nó. Điều đó có nghĩa là thời gian phát triển kéo dài, thời gian thử nghiệm và chi phí. Và nếu nó trượt qua một bản phát hành dịch vụ có khuyết tật từ trung bình đến cao, thì đó là một mớ hỗn độn lớn đối với họ.

Tiếng ồn / Sương mù trong Nhật ký của bạn

Từ góc độ SCM, cũng có ý nghĩa nếu bạn làm việc trực tiếp với chi nhánh của một bản phát hành dịch vụ, vì bạn muốn có một cái nhìn rõ ràng về các thay đổi liên quan đến sửa lỗi. Nếu có 15 cam kết với hàng ngàn thay đổi xung quanh một lỗi thực sự cần thiết có thể là thay đổi mã 1 dòng, thì thật khó chịu.

Vì vậy, là một người thuê mới, việc yêu cầu bạn kiềm chế tái cấu trúc và / hoặc cải tiến phần mềm là điều hợp lý hơn, và theo ý nghĩa của tôi là "phẫu thuật" càng tốt với các lỗi của bạn. Nó chỉ làm đau đầu ở vịnh.

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

Bây giờ, điều đó KHÔNG có nghĩa là sẽ có những cách để đạt được cả sự tỉnh táo về quy tắc và sự tỉnh táo trong tâm trí của những người liên quan. Là thiếu niên, họ nên có ai đó xem xét các thay đổi của bạn, đặc biệt là các lỗi và đảm bảo rằng chúng được chấp thuận trước khi đưa vào bản phát hành dịch vụ. Điều đó sẽ ngăn chặn hoặc hạn chế những thay đổi căn bản, và an toàn hơn.

Dự án từ địa ngục

Mã crap, bầy lập trình viên, sao chép, kiến ​​trúc tào lao

Một lần nữa, ma quỷ ủng hộ ở đây, nhưng chỉ cho thấy rằng yêu cầu ban đầu của bạn có chứa một vài bit không có kết quả.

Quan điểm của tôi là thế này: Tôi thực sự thực sự thực sự hiếm khi chiếm lấy một cơ sở mã không ở trạng thái này. Và trong trường hợp không may mà tôi đã làm, gần đây họ đã bắt đầu các dự án hoặc nguyên mẫu đã được khởi động bởi các lập trình viên xuất sắc. Nhưng đại đa số đáng kinh ngạc trong số họ trông giống như tào lao, và một số đáng sợ trong số này là tào lao thực sự. Ngay cả những người bắt đầu bởi các lập trình viên giỏi hoặc giỏi cũng có thể trở nên tào lao, thời hạn và các cam kết khác giúp ...

Chào mừng bạn đến với kỹ thuật phần mềm công nghiệp thực tế!

Và bạn biết điều gì thú vị? Nó thường tồi tệ hơn trong thế giới phát triển web. Thưởng thức! :)

Quá nhiều dự án và yêu cầu, không đủ thời gian và thời gian

Vấn đề nằm ở đây có lẽ nằm ở:

• quản lý của bạn (có thể vô thức) lạm dụng bạn ,
• đồng nghiệp của bạn (có thể vô thức) lạm dụng bạn ,
• bạn (có thể vô tình) không che mông của bạn và chiến đấu đủ để chiến đấu .

Người quản lý của bạn nên biết rằng bạn đang làm việc với quá nhiều dự án để quản lý. Nếu họ không, hãy chắc chắn rằng họ càng sớm càng tốt. Hãy chắc chắn rằng họ biết đó không phải là một nick-pick trong công viên và bạn cảm thấy bị áp lực, và nó cần phải dừng lại.

Cố gắng có một cái nhìn xung quanh và đảm bảo rằng đồng nghiệp của bạn không làm chệch hướng nhiều nhiệm vụ và dự án hơn đối với bạn, bằng cách thực sự (bằng cách nói "X sẽ có thể chăm sóc điều đó") hoặc gián tiếp ("Tôi không phải là người phù hợp cho này, tìm người khác "-> cuối cùng là bạn).

Giai thoại cá nhân ở đây: Tôi đã thực tập vài năm trước và chỉ vào ngày cuối cùng của tôi, khi tôi nhận được đánh giá của mình, ông chủ của tôi đã nói với tôi, mặc dù rất hài lòng với công việc của tôi, rằng một trong những người quản lý có cảm giác tôi đã dỡ một số "nhiệm vụ không mấy vui vẻ" cho một thực tập sinh khác khi họ muốn tôi đến đón họ. Tôi đã chết khi khiến họ cảm thấy thất vọng, và với ý nghĩ rằng tôi sẽ trông như bị buông lơi, khi ý định của tôi hoàn toàn ngược lại: tôi đã cố gắng để thực hiện các nhiệm vụ khó khăn hơn và có một đối tác thực tập trẻ hơn với ít tóc hơn vấn đề. Tôi không nhận ra rằng, nếu tôi ở vị trí của anh ấy, tôi sẽ cảm thấy buồn chán vì thiếu thử thách và có lẽ cảm thấy như cách anh ấy làm. Vấn đề là, bạn cần giao tiếp để đảm bảo không ai đưa ra giả định sai về 3 điều rất khác biệt:

• những gì bạn có thể làm ,
• những gì bạn muốn làm ,
• và những gì bạn sẵn sàng làm .

Vì vậy, đó cũng là một phần lỗi của bạn khi để nó trở thành như vậy. Nhưng đó là chuyện bình thường, đó là bài học mọi người cần học. Nó chứa trong hai chữ: N - O .

Bạn thường sử dụng nó làm tiền tố cho một câu trả lời dài hơn nhưng không quá nhiều phí: Không, tôi không thể làm điều này. Không, tôi không biết làm thế nào để làm điều này. Không, tôi không chắc tôi là người phù hợp cho việc này. Không, tôi chưa bao giờ làm điều đó.

Lúc đầu, rất dễ cảm thấy như bạn chỉ có thể nói "vâng, tôi (cuối cùng) sẽ làm điều đó", và chồng chất mọi thứ lên và hoàn thành chúng, có thể bằng cách thêm vài giờ vào. Điều đó hoàn toàn sai. Bạn cần hiểu rằng thời gian của bạn là, sau khi các kỹ năng của bạn, tài sản quý giá nhất của bạn, cho bạn và cho công ty của bạn. Nếu nó bị lạm dụng, nó sẽ tác động đến các dự án, thời hạn và ngân sách . Đơn giản vậy thôi.

Ngoài ra, có vẻ hơi lo lắng rằng bạn sẽ có quá nhiều người để báo cáo. Bạn có thể giao dịch với nhiều khách hàng và nhiều chủ sở hữu dự án hoặc thậm chí các bên liên quan chính mà bạn cần liên lạc. Nhưng, về tổng thể, đặc biệt khi bạn là một người thuê mới, bạn chủ yếu chỉ nên báo cáo cho một vài người quản lý (và rất có thể chỉ là người quản lý trực tiếp của bạn và có thể là nhà phát triển chính hoặc nhà phát triển cao cấp). Làm thế nào mà nó có được theo cách này? Tôi không biết. Nó có thể là một vấn đề tổ chức tại công ty của bạn, hoặc nó có thể là kết quả của việc bạn làm một ân huệ và sau đó được liên hệ trực tiếp, và không nói "không". Hoặc có thể là người quản lý trực tiếp của bạn gặp vấn đề với việc gửi các nhiệm vụ, đối với tất cả những gì tôi biết (tôi thực sự đoán, nhưng mô hình có thể nhận ra và nổi tiếng).

Tôi khuyên bạn nên thực hiện các thao tác sau khá nhanh: hãy nói chuyện trực tiếp với người quản lý trực tiếp của bạn, giải thích rằng những người quản lý khác có thể hơi khó tính hoặc (có lẽ ít than vãn hơn) rằng bạn có quá nhiều thứ chồng chất từ ​​quá nhiều người, và rằng bạn cần đầu vào của anh ấy (và có thể là của họ) để biết nên ưu tiên cái nào.

Yêu cầu thay đổi 180 độ

Đây là một vấn đề lớn khác. Có lẽ chúng không phải là lỗi của bạn, nhưng bạn có thể cố gắng giúp họ giải quyết.

"Yêu cầu thay đổi suy thoái 180", như bạn gọi chúng một cách đẹp mắt và nhạy bén, là một dấu hiệu rõ ràng cho thấy các yêu cầu không rõ ràng và không ai cố gắng hết sức để chúng được đục và xóa theo thời gian.

Đó thường là khi ai đó cần lấy điện thoại (hoặc tốt hơn, trên đôi chân của họ) và nắm lấy các bên liên quan và nói với họ rõ ràng: "đó là nơi chúng tôi đang ở, đó là nơi bạn muốn chúng tôi đến, bạn có xác nhận chúng tôi không đi đúng hướng? ". Không có câu trả lời rõ ràng ngay từ đầu, nhưng thời gian càng trôi qua, chúng càng trở nên rõ ràng hơn, hoặc dự án này là một thảm họa đang chờ xảy ra.

Thông thường tôi sẽ nói nắm lấy tất cả các bên liên quan trong tầm tay, đặt chúng trong một căn phòng, đưa họ qua các vấn đề tranh chấp và tăng dần cố gắng giải quyết những vấn đề này - và nhận được các ưu tiên trong khi bạn ở đó. Tuy nhiên trong trường hợp của bạn, đây có thể không phải là cuộc gọi của bạn để thực hiện. Nhưng bạn đề cập đến họ thực sự đã cho bạn trách nhiệm của các dự án; Vì vậy, nếu đó thực sự là trường hợp, thì hãy chịu trách nhiệm và làm điều đó. Và đừng ngại nói "chúng ta KHÔNG THỂ làm điều đó" , hoặc thậm chí "chúng ta sẽ không làm điều đó" . Điều thực sự quan trọng là giới hạn phạm vi của một dự án.

Nếu không có phạm vi, không có yêu cầu rõ ràng nào ở cuối cuộc thảo luận.

Quá tải thư điện tử

Mọi người có xu hướng hành xử khác nhau dựa trên phương tiện truyền thông họ sử dụng. Cá nhân tôi, mặc dù tôi là một người khá ít nói (và đã làm việc chủ yếu ở nước ngoài, vì vậy tôi cũng không thích nói chuyện điện thoại nhiều), tôi thích theo thứ tự ưu tiên dựa trên năng suất:

• nói chuyện với người mặt đối mặt ,
• nói chuyện với mọi người trên điện thoại,
• nói chuyện với mọi người qua IM,
• nói chuyện với mọi người qua email.

Email rất tốt để theo dõi, để nhận xác nhận, để gửi ghi chú.

Để lập kế hoạch, lập kế hoạch và thảo luận về các điểm có vấn đề, chúng gần như vô dụng. Hãy gõ cửa nhà chàng cho đến khi anh ấy / cô ấy mở nó ra và ngồi xuống với một quyển sổ ghi chép và một bản sao tài liệu của bạn để làm rõ mọi chuyện. Khi bạn đã hoàn tất, sau đó gửi email và yêu cầu xác nhận. Nếu nó trở lại với một câu trả lời tiêu cực hoặc một nỗ lực hơi bị che giấu trong việc lén lút một cái gì đó khác trong phong bì, hãy đi bao vây văn phòng của người đối thoại của bạn một lần nữa.

Đây là kỹ thuật phần mềm. Nó thường hiệu quả hơn khi bạn không gõ bàn phím và thực sự có thể cắt giảm trả trước trên crap bạn sẽ cần phải xử lý.

Làm việc có giá trị trong nhóm

Bạn đang làm tương đương với giá trị công việc của một nhóm? Có lẽ.

Bạn đang làm tương đương với giá trị công việc của nhóm của bạn? Chắc là không.

Ý tôi là nhóm của bạn có lẽ đang bận làm việc và bạn làm việc quá sức. Và đó là vấn đề: bạn đang quá tải với những thứ nên bị đẩy ra khỏi các mốc thời gian của dự án hiện tại hoặc trao cho ai đó có thời gian trong tay họ.

Tôi có phải là một thằng ngốc khi ban đầu tôi mong đợi mọi thứ sẽ khác đi?

Không; Chỉ mới tham gia bữa tiệc. Nó giống như một mối quan hệ đầu tiên hoặc mối quan hệ. Bạn sẽ vượt qua nó.

Tôi đoán bài đăng này đã trở thành một cơn thịnh nộ lớn, nhưng xin vui lòng cho tôi biết rằng điều này không giống nhau cho mọi nhà phát triển.

Điều này cũng tương tự đối với mọi nhà phát triển trong các tổ chức hỗn loạn, có thể là những người khởi nghiệp hoặc những người khổng lồ có uy tín, và không có kinh nghiệm hoặc sự tự tin để khiến mọi thứ di chuyển một chút để đưa ra cơ hội sống sót của bạn ở bên phải của quy mô.

PS Mức lương của tôi gần như bằng nếu không thấp hơn nhân viên thu ngân ở siêu thị.

Tôi đã làm mức lương xứng đáng cho các công việc sẽ xuất hiện crappy. Đó không phải là con số trên tấm séc được tính, đó là bối cảnh. Bạn làm gì, tuổi của bạn, nơi bạn sống và làm việc, v.v ...

Điều đó đang được nói, nếu bạn được trả lương quá thấp, làm việc quá nhiều và không hoàn toàn là đàn em, hãy yêu cầu tăng lương hoặc nhận một công việc mới!

Thật đơn giản:

• nếu họ coi trọng những gì bạn làm, họ sẽ sẵn lòng tăng lương,
• nếu họ không, tương lai trong công ty này sẽ không có vẻ gì là màu hồng (ít nhất là đối với bạn, đó là điều quan trọng), vì vậy đừng cảm thấy tồi tệ khi rời đi.

Xin lưu ý rằng yêu cầu tăng lương là một điều tốt, mặc dù lúc đầu bạn sẽ không bao giờ nghĩ như vậy. Nó chứng tỏ bạn theo dõi những gì bạn làm, và gợi ý rằng bạn để mắt đến lựa chọn khác trong khi vẫn sẵn sàng ở lại trên tàu. Và đó là một điều tốt để làm quen với việc yêu cầu họ, vì họ giống như các cuộc phỏng vấn xin việc hoặc mặc cả nói chung: đó là điều cần phải thực hành và họ sẽ không từ trên trời rơi xuống nếu bạn không tự mình tiếp cận họ. Một số công ty sẽ phân phối tăng lương thường xuyên mà không được yêu cầu, nhưng điều đó chỉ bởi vì họ đủ thông minh để biết rằng điều đó khiến bạn nửa hạnh phúc và ít sẵn sàng thay đổi, và họ muốn cắt cỏ dưới chân bạn (hầu hết mọi người sẽ cảm thấy hơi khó chịu về việc tăng một đề nghị tăng lương mà họ đã được cung cấp trực tiếp).

Cách tiến hành với yêu cầu này nằm ngoài phạm vi của dự án NÀY ngay tại đây, vì vậy tôi sẽ không đi sâu vào chi tiết. Nhưng tôi khuyên bạn nên chuẩn bị một bản ghi ID cam kết SCM của bạn, về các lỗi và thành tích cố định của bạn và bạn cũng chuẩn bị các báo cáo so sánh chúng với nỗ lực chung của nhóm. Cách này:

• bạn có thể tự đo lường nếu bạn thực sự làm được nhiều hơn so với các đồng nghiệp của mình hay không,
• bạn có thể giữ vững lập trường nếu họ nói rằng yêu cầu của bạn không chính đáng.

Ngoài những bình luận của người khác:

1. Vâng, đó là bình thường đối với một nhân viên cấp nhập cảnh được giao những công việc mà không ai khác muốn làm.

2. Bạn nên xem đây là một khối xây dựng cho sự nghiệp tương lai của bạn.

Vậy bạn nên làm gì? Để chứng tỏ bạn là một nhà phát triển chuyên nghiệp, bạn cần đảm bảo công việc của mình được cấu trúc và lên kế hoạch, nếu không, bạn có thể khó xây dựng những điều tốt đẹp mà bạn hiện đang làm - vì vậy bạn nên cố gắng làm những việc như sau (nếu bạn chưa có).

1. Đăng nhập công việc của bạn một cách chính xác, cho từng dự án. Vì vậy, nếu bạn dành một giờ để sửa lỗi cho dự án A, hãy đăng nhập lần này. Điều này sẽ hữu ích để hiển thị cho người quản lý của bạn nếu bạn muốn thảo luận về khối lượng công việc.

2. Viết bài kiểm tra đơn vị. Bạn đề cập đến một số dự án bạn duy trì có đầy lỗi, vì vậy tôi đoán là có rất ít (nếu có) thử nghiệm đơn vị. Đối với mỗi báo cáo lỗi, hãy viết một bài kiểm tra đơn vị sao chép lỗi, sau đó sửa lỗi. Điều này sẽ giúp đảm bảo không có hồi quy xảy ra, cải thiện chất lượng mã và đóng vai trò là nền tảng để tái cấu trúc mã nếu bạn có cơ hội (ví dụ: nó có thể giúp bạn thuyết phục các bên liên quan rằng việc viết lại một số phần có thể cải thiện chất lượng mà không giới thiệu các lỗi mới, do bộ kiểm tra đơn vị).

3. Tìm kiếm một công việc mới - bạn làm việc trên nhiều dự án cùng một lúc, bạn đã viết mã từ đầu và có lẽ bạn đã trải nghiệm toàn bộ vòng đời dự án - đây đều là những kinh nghiệm tốt để áp dụng ở nơi khác.

Tình hình của bạn hơi khó chịu, nhưng vẫn bình thường. Nhưng cách bạn xử lý nó là rất xấu. Dưới đây là những gì bạn cần làm:

• Hãy cố gắng đối đầu với ông chủ của bạn. Bạn nên có một số bằng chứng (số) về thời gian cơ sở mã xấu thực sự tốn bao nhiêu thời gian. Nếu anh ta không hiểu những thứ như nợ kỹ thuật, hãy ngừng đề cập đến nó. Nó sẽ phá hỏng đầu của bạn, và bạn có thể bị đánh dấu là một anh chàng 'thái độ xấu'. Đó không phải là công việc của bạn để dạy sếp của bạn làm công việc của mình.

• Duy trì tồn đọng của riêng bạn (kanban). Khi nhiệm vụ mới xuất hiện, hãy kết thúc và cho biết thời gian hoàn thành ước tính.

• Tăng thời gian trả lời của bạn, kiểm tra email của bạn chỉ hai lần một ngày. Điển hình là trước bữa trưa và ngay trước khi bạn rời đi. (Kiểm tra email không nên được theo sau bởi mã hóa, vì nó có thể phá hỏng đầu của bạn).

• Thực hiện cải tiến mã nhỏ như là một phần của mỗi nhiệm vụ. Nó chỉ đơn giản là công việc của bạn để cải thiện mã, kỹ năng và công cụ bạn đang sử dụng. Nó cũng sẽ thúc đẩy đạo đức của bạn trong dài hạn.

• Không có dự án chuyển đổi trong ngày. Hôm nay bạn chỉ đơn giản là làm việc trên dự án X, và bạn sẽ bắt đầu nhiệm vụ khác cho Y vào ngày mai.

• Phân bổ một giờ mỗi ngày để giữ cổng. Nó có nghĩa là những nhiệm vụ nhỏ không quan trọng để làm. Nếu tác vụ này mất hơn 10 phút (không có lý do gì là lý do), nó sẽ đi vào phần tồn đọng và bạn thông báo cho người quản lý rằng nó sẽ bị trì hoãn.

Bây giờ đến phần khó khăn. Hiện tại các nhà quản lý không liên lạc với nhau và chỉ cho rằng bạn sẽ hoàn thành dự án của riêng họ với mức độ ưu tiên tối đa. Điều này mang lại rất nhiều căng thẳng trên đầu của bạn, bởi vì bạn đang ở giữa các cuộc tranh luận. Bạn cần buộc các nhà quản lý bắt đầu điều phối công việc của bạn. Cuối cùng, bạn nên có một hồ sơ tồn đọng & đơn giản và các nhà quản lý nên bắt nạt nhau mà không có bạn.

Vì vậy, hãy làm một số vai trò đơn giản. Có ba người quản lý và dự án (Xavier với dự án X, Yvonne với dự án Y và Zed với dự án Z). Bạn có tồn đọng trong hai tuần, 5 ngày cho X và 5 ngày cho Y.

• Z yêu cầu bạn thực hiện một số nhiệm vụ (1 ngày)
• Bạn trả lời rằng nó sẽ được thực hiện trong 11 ngày.
• Z trả lời rằng đó là nhiệm vụ đơn giản và không nên mất nhiều hơn một ngày (lưu ý rằng Z áp dụng áp lực nhỏ).
• Bạn trả lời rằng bạn hiện đang làm việc cho X và sau đó cho Z. Bạn có thể thực hiện công việc của cô ấy sau đó.
• Z trả lời bạn nên thực hiện nhiệm vụ của mình ngay lập tức (tăng áp lực, vi phạm trực tiếp lãnh thổ X và Y).
• Bạn trả lời rằng làm nhiệm vụ của cô ấy sẽ trì hoãn công việc cho X và Y. Anh ấy nên hỏi họ trước. Bạn cũng CC X và Y.

Bây giờ có hai kết thúc:

• Người quản lý sẽ bắt đầu sủa nhau, nhiều email, có thể là một số cuộc họp ... Bạn nên tránh xa và để người chiến thắng giao cho bạn một nhiệm vụ.

• Sẽ không có gì xảy ra, Z sẽ hỏi bạn hai ngày sau nhiệm vụ của anh ấy là ở đâu. Bạn trả lời rằng hiện tại bạn đang làm việc cho X và anh ấy đã không đề cập bất cứ điều gì về dự án Z. Một lần nữa CC X.

Bây giờ loại hành vi này có thể khiến bạn bị sa thải. Nhưng tình hình của bạn không bền vững, và có lẽ bạn sẽ sớm bỏ việc. Giải pháp này chỉ hoạt động nếu các nhà quản lý đang cạnh tranh với nhau (rất bình thường). Bạn cũng nên lưu giữ hồ sơ về công việc của bạn (tồn đọng), trong trường hợp ai đó sẽ phàn nàn, rằng bạn đang nghỉ việc.

Bảy năm trước tôi đã thực hiện khá nhiều công việc bảo trì 100% trong một thời gian và đã viết một bài báo về nó: Nghệ thuật lập trình bảo trì . Một phần bạn có thể thấy hữu ích:

1. Thích nó

Làm thế nào bất cứ ai có thể thích lập trình bảo trì? Các nhà phát triển mơ ước trở thành kiến ​​trúc sư trưởng trong đội của họ, và khi họ kết thúc việc duy trì phần mềm hiện có, nó cảm thấy gần như là sự trừng phạt. Không cần phải như vậy: lập trình bảo trì có những thách thức riêng và đòi hỏi nhiều sự sáng tạo, khả năng thích ứng, sự kiên nhẫn, kỷ luật và giao tiếp tốt. Điều này cũng có thể tốt cho sự nghiệp của bạn: có các mục nhập mạnh mẽ như ứng dụng doanh nghiệp n-tier 24/7 của Architected 24/7 trong hồ sơ của bạn có vẻ tốt, nhưng nhà tuyển dụng thực sự coi trọng những người giải quyết vấn đề; và lập trình bảo trì có thể là một cơ hội tốt để thể hiện kỹ năng giải quyết vấn đề của bạn.

Vấn đề của bạn nghe có vẻ như bạn đang nghe thường xuyên hơn. Nó dường như là một công việc có thể dễ dàng phù hợp với The Daily WTF .

Rất nhiều tổ chức tập trung nhiều vào bán hàng hoặc đẩy tính năng hơn là chất lượng. Điều mà các công ty không nhìn thấy là có nhiều hơn những phẩm chất bên ngoài của một phần mềm. Ward Castyham đặt ra thuật ngữ nợ kỹ thuật .

Bạn cũng có thể muốn đọc Steve McConnell về nợ kỹ thuật . Anh ấy có một số điểm thú vị. Trong Google Tech Talk, Ken Swaber nói về phát triển phần mềm nhanh . Một phần tốt là về một câu chuyện tương tự như của bạn. Anh ấy nói về một dự án phần mềm đã trở thành "bản lĩnh" sau 10 năm lập trình bởi nhiều lập trình viên khác nhau mà không bao giờ thực hiện bất kỳ tái cấu trúc nào . Tôi nghĩ rằng nếu bạn xem video này, bạn sẽ thấy rất nhiều điểm tương đồng với những gì bạn mô tả.

Bất kỳ hệ thống phần mềm nào cũng sẽ giảm chất lượng khi nó được mở rộng. Trong thực tế để sống sót nó sẽ phải. Các Luật Lehman giải thích nguyên tắc này khá tốt. Cuối cùng, nó sẽ sôi sục với câu hỏi sau: "Làm thế nào để tôi thuyết phục sếp của bạn thực hiện tái cấu trúc?" .

Làm thế nào tôi tiếp cận một vấn đề tương tự:

• Tôi đã đối mặt với ông chủ của mình và giải thích rằng chất lượng mã xuống cấp khi chúng tôi tiếp tục phát triển ( Luật Lehman ).
• Tôi đã cố gắng giải thích cho ông chủ của tôi về khái niệm nợ kỹ thuật . Và rằng cách anh ấy cho phép bạn làm việc là một cách sẽ khiến anh ấy mất tiền trong thời gian dài.
• Để thực sự cho anh ấy thấy vấn đề nghiêm trọng như thế nào, tôi (trong thời gian riêng của tôi) đã thực hiện một phân tích mã tĩnh. Các ông chủ không hiểu phần mềm, nhưng họ hiểu các con số. Mặc dù các số liệu mã có sai sót của họ , thật tốt khi có một cái gì đó có thể đo lường được mà bạn có thể nói về. Hãy thử tìm hiểu các bài đọc bình thường cho các số liệu này và bạn sẽ ngạc nhiên khi so sánh điều này với cơ sở mã của riêng bạn.
• Nếu không có gì giúp và không có gì thay đổi, điều duy nhất bạn có thể làm là giải thích rằng một tính năng mới nhất định sẽ yêu cầu một số thao tác lại của các phần khác trong cơ sở mã của bạn. Giải thích rằng nếu bạn có mã trùng lặp và họ cũng muốn thay đổi thứ gì đó thì chi phí thay đổi cũng trùng lặp.
• Một câu trả lời chung cho điểm trước sẽ là không ai hỏi và do đó không được trả tiền cho việc làm lại này. Rằng "có lẽ" việc làm lại này là thừa. Bạn sẽ phải giải thích rằng phần mềm sẽ luôn phải thay đổi. Giống như Luật Lehman nói; nó sẽ phải thay đổi để tiếp tục sử dụng. Nếu không, các chương trình khác đã thay đổi sẽ luôn tồn tại. Đó là những người mong đợi sự thay đổi và có thể thích nghi với sự thay đổi sẽ tồn tại. Đây là những gì phát triển phần mềm nhanh là tất cả về. ( Wikipedia )

Ông chủ của tôi ngày nay sử dụng khái niệm nợ kỹ thuật để giải thích cho khách hàng của chúng tôi rằng đôi khi chúng tôi cần phải làm lại các phần của phần mềm chúng tôi xây dựng. Chỉ cần chứng minh rằng - nếu bạn có một ông chủ hợp lý, có thể thay đổi mọi thứ cho tốt hơn.

Tình huống bạn đang phải đối mặt là gần như (nếu không hoàn toàn) giống nhau đối với nhiều người mới.

Điều này xảy ra trong các giai đoạn ban đầu của sự nghiệp. Đây là một nhược điểm: Chúng tôi phải khắc phục vấn đề này và chứng minh giá trị của chúng tôi đối với công ty (có thể là quy mô trung bình hoặc MNC ). Chúng ta có thể đưa ra quyết định về những gì hoàn cảnh yêu cầu chúng ta làm. Vì vậy, không có gì có hại trong việc nỗ lực trong công việc, miễn là bạn được chú ý đến nó và đứng như một cá nhân cho công việc của bạn. Nếu bạn có giá trị, công ty sẽ thông báo! Adios và may mắn nhất.

Theo tôi, một công ty cấm tái cấu trúc là không đáng để làm việc. Refactoring là một kỹ năng phát triển phần mềm cần thiết, và các công cụ điều khiển phiên bản làm cho nó rất dễ dàng để phát triển những thay đổi trong sự cô lập mà không làm hư các 'thân' (trong trường hợp một cấu trúc lại thực sự làm phá vỡ một cái gì đó). Như chú Bob nói (diễn giải): "Bạn không nên yêu cầu trở thành một chuyên gia và thực hiện đúng công việc của mình."

Bảo trì lập trình không bao giờ có nghĩa là duy trì mã xấu.

Tôi đã nhận được email này năm năm trước từ một trong những người bạn của tôi.

Email body:    

Một kỹ sư thực tập sinh mới gia nhập hỏi ông chủ của mình "ý nghĩa của Thẩm định là gì?"

Sếp: "Bạn có biết ý nghĩa của việc từ chức?"

Thực tập sinh: "Có tôi làm"

Sếp: "Vì vậy, hãy để tôi làm cho bạn hiểu thẩm định là gì bằng cách so sánh nó với việc từ chức"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Thực tập sinh: "Có ông chủ đủ rồi, giờ tôi đã hiểu tương lai của mình. Để thẩm định tôi sẽ phải từ chức ... !!!"

Nếu tôi là bạn, tôi sẽ dành vài giờ sau khi làm việc xây dựng lại ứng dụng miễn phí. Nó có lẽ sẽ là một nhiệm vụ thú vị. Khi bạn hoàn thành nó, hiển thị nó cho ông chủ của bạn. Nếu nó hoạt động và bạn đang bảo trì nó, anh ta sẽ không có gì phải lo lắng. Điều này sẽ làm cho công việc của bạn dễ dàng hơn nhiều và sẽ mở rộng tầm nhìn của những người cấp cao hơn cho tiềm năng của bạn trong công ty.

Tôi là một sinh viên đại học toàn thời gian làm việc thực tập bán thời gian với giá 10 đô la Mỹ một giờ. Tôi làm công việc QA nhàm chán, lặp đi lặp lại và dễ dàng. Tôi coi mình là người cực kỳ may mắn, vì tôi biết một ngày nào đó điều này sẽ mở ra những cánh cửa lớn hơn và tốt hơn.

Có, bạn sẽ luôn phải duy trì các ứng dụng, được viết bởi cả bạn và người khác. Ngoại lệ duy nhất là nếu bạn viết một chương trình không bao giờ cần bảo trì. Vì vậy, bạn tốt hơn để bảo trì tốt.

Tôi nghĩ rằng có một gợi ý tinh tế trong câu hỏi của bạn về một lỗ hổng trong cách tiếp cận của bạn. Đó là, sửa lỗi không liên quan đến việc cải thiện mã.

Nhưng sau đó tôi đã nghe nói tôi không được phép cải thiện mã hiện có và chỉ tập trung vào sửa lỗi khi có lỗi được báo cáo.

Tôi không thể tin rằng ai đó đã nói với bạn "bạn phải sửa lỗi mà không cải thiện mã." Điều này là cả khó khăn và không thể. Những gì bạn không thể làm là viết lại ứng dụng chỉ vì bạn không thích hoặc cảm thấy khó hiểu, cách tiếp cận được sử dụng trong cơ sở mã hiện có.

Lời khuyên của tôi là học cách tái cấu trúc. Bất cứ khi nào bạn đang sửa một lỗi, bạn có cơ hội để cải thiện ít nhất một số mã. Bao nhiêu cơ sở mã được tái cấu trúc phụ thuộc vào lỗi là gì và mã tốt hay xấu. Nhưng nếu bạn đang sửa lỗi và cố tình để lại mùi ở khắp mọi nơi, thì bạn không làm việc của mình và bạn đang xây dựng nợ kỹ thuật .

Một số lỗi thực sự được khắc phục đơn giản bằng cách tái cấu trúc và đôi khi việc tái cấu trúc lại hữu ích để giúp bạn hiểu mã . Điều này là do tái cấu trúc phải cải thiện khả năng bảo trì và sự gắn kết của mã.

Khi tôi ước tính một sửa lỗi, tôi thường sẽ đưa ra quyết định về việc liệu một công cụ tái cấu trúc chính sẽ là cách tốt nhất để thực hiện hay không, và tính đến điều đó. Tương tự với các bài kiểm tra đơn vị. Cả hai điều này nên là một phần trong cách bạn viết mã, không phải là thứ gì đó tùy chọn liên quan đến thời gian thêm.

Vì vậy, bạn không nên hỏi "tôi có thể cải thiện mã khi tôi sửa lỗi không?" Bởi vì dù sao bạn cũng nên như vậy. Bạn không nên hỏi "tôi có thể sử dụng tái cấu trúc để sửa lỗi không?" Bởi vì nếu mã khiến ứng dụng bị lỗi là rất cần tái cấu trúc, bạn vẫn nên làm điều đó. Bạn không nên hỏi "tôi có thể viết bài kiểm tra đơn vị khi tôi sửa lỗi này không?" Bởi vì bạn nên viết một bài kiểm tra hồi quy trước khi bạn bắt đầu cố gắng sửa lỗi.

Lưu ý: Tôi cảm thấy một số thuộc tính cho câu trả lời này nên đến Jeff Atwood, khi tôi liên kết 3 bài viết của anh ấy.

Đây là tất cả về tiền bạc. Tôi đoán là với tư cách là một người bắt đầu, có lẽ bạn quá tử tế với những khách hàng đã nhận được nhiều hơn số tiền họ đã trả.

Tìm hiểu để báo giá cho các yêu cầu mới. Điều này là xa dễ dàng và khách hàng sẽ thường xuyên thử bạn. Nếu bạn có thể, hãy tranh thủ sự giúp đỡ của một người quản lý dự án / sản phẩm có kinh nghiệm.

Một khi bạn nghĩ về tiền bạc, việc giao tiếp với quản lý trở nên dễ dàng hơn rất nhiều. Nếu khách hàng hiện tại của bạn cung cấp tiền toàn thời gian, bạn không nên nhận các dự án mới. Nhưng bạn sẽ hiểu rằng quản lý vẫn sẽ cố bắt nạt bạn làm chúng.

Nếu bạn thực sự có giá trị đối với công ty, bạn sẽ có được quyền lực thương lượng. Bạn có thể yêu cầu họ thuê thêm người, nhận ít dự án mới hơn, giúp bạn giảm tải bảo trì hoặc tăng lương.

Đây không phải là quyết định của nhà tuyển dụng của bạn đối với bạn trong phạm vi, rằng bạn bị cấm cải thiện mã hiện có. Sử dụng đánh giá chuyên nghiệp của riêng bạn. Khi bạn đang ước tính công việc, tôi sẽ tính thêm thời gian để cho phép tái cấu trúc, nếu nó sẽ tăng năng suất trong tương lai.

Dù sao, có vẻ như bạn không giao tiếp hiệu quả với chủ nhân của mình.

1. Bạn có bằng chứng rằng tái cấu trúc sẽ tiết kiệm tiền. Soạn thảo đề xuất cho một dự án tái cấu trúc và chứng minh doanh nghiệp có thể tiết kiệm được bao nhiêu thời gian và tiền bạc. Phác thảo chính xác những thay đổi bạn sẽ thực hiện đối với mã và mất bao lâu.

2. Giữ một bản ghi chính xác để ghi lại thời gian bạn dành cho mã hóa, các cuộc họp và trả lời email. Điều này sẽ bảo vệ bạn nếu bạn tụt lại phía sau lịch trình.

3. Chậm lại. Điều này có vẻ hơi phản cảm, nhưng thời gian của bạn sẽ chỉ bị lạm dụng nếu bạn làm mọi thứ nhanh chóng. Mọi người sẽ tôn trọng thời gian của bạn nhiều hơn nếu bạn làm ít hơn. Ví dụ, tôi sẽ chỉ kiểm tra email một hoặc hai lần mỗi ngày. Nếu không, bạn có nguy cơ kiệt sức.

4. Xem xét mức lương của bạn, không đáng để đau đầu hơn. Hãy chắc chắn rằng bạn đi đúng giờ mỗi ngày. Đừng bỏ thêm giờ mà không được bồi thường. Ngoại lệ là nếu có các lựa chọn thăng tiến tốt, hoặc nếu danh tiếng của công ty sẽ thúc đẩy rất nhiều hồ sơ của bạn, thì bạn sẽ chỉ phải mút nó.

Không biết nhiều hơn, tôi chỉ đề nghị bạn cố gắng cởi mở hơn với những người quản lý của mình. Có thể bắt đầu tăng ước tính nhiệm vụ của bạn. Liên tục nhắc nhở họ về khối lượng công việc của bạn bận rộn như thế nào. Ngoài ra, bạn nên gặp sếp của mình và giải thích rằng bạn muốn tăng lương trong vòng sáu tháng tới, và hỏi làm thế nào bạn có thể cải thiện hiệu suất của mình để đạt được mức tăng lương này.

Chúc may mắn.

Theo kinh nghiệm của tôi, thế giới học thuật hoặc 6-12 tháng đầu tiên của một công ty khởi nghiệp định hướng công nghệ là hai lĩnh vực đáng tin cậy duy nhất mà bạn sẽ gặp phải một bảng trống thực sự. Cả hai đều có chi phí riêng nhưng nếu bạn thích viết mã và thường bị kinh hoàng bởi chất lượng mã bạn tìm thấy trong tự nhiên, bạn nên bắt đầu hướng sự nghiệp của mình theo một trong những hướng này.

Hãy thử nói chuyện với nhà tuyển dụng của bạn và xem nếu bạn có thể giải quyết điều này. Nghe có vẻ như bạn đang nghĩ về điều này, và nó không liên quan gì đến việc trở thành một lập trình viên tồi.

Các công ty web nhỏ hơn có xu hướng có rất nhiều dự án đang diễn ra cùng một lúc, điều này theo nhiều cách khiến bạn rơi vào tình trạng khó khăn. Hoặc cố gắng làm tốt nhất tình huống của bạn, hoặc cố gắng tìm một công việc mới nếu bạn nghĩ bạn có thể. Tôi hứa có những công việc mã hóa tốt hơn ngoài kia, vì vậy đừng để công việc đầu tiên này làm bạn sợ.

Chúc may mắn, và tôi hy vọng cả bạn và đồng nghiệp của bạn hiểu được lực hấp dẫn hoặc nỗ lực của bạn!

Kinh nghiệm cá nhân

Giống như nhiều người ở đây tôi cũng nhận ra tình hình của bạn. Về cơ bản, tôi đã có công việc mã hóa đầu tiên với mức lương thấp và phải duy trì rất nhiều mã được xây dựng với cấu trúc kém. Lúc đầu, tôi thấy buồn cười khi học những thứ mới, nhưng cuối cùng tôi có rất nhiều dự án để duy trì, những dự án mới để thực hiện và một bảng trắng ngày càng lớn hơn mỗi ngày với những điểm tôi đã làm với tôi nhận ra rằng nó không hoạt động

Sau khi chịu đựng được hai năm, tôi đã nghỉ việc và tìm một công việc mã hóa khác vài tháng sau đó hoàn toàn phù hợp với tôi.

Dù sao, nhiều lần, không chỉ các dự án của bạn có thể là vấn đề. Tôi thấy mình thoải mái hơn ở nơi làm việc khi tôi được công nhận và tôn trọng công việc của mình. Vấn đề với tình huống mà bạn gặp phải là nhà tuyển dụng của bạn chỉ có thể nhận thấy các lỗi phát sinh từ các dự án đã tạo và không phải là thời gian bạn mất để xóa tất cả các lỗi khác.

Lương

Nếu bạn muốn có nhiều tiền hơn, bạn có thể thường xuyên nhận được nó. Tôi đã xoay sở để thương lượng mức lương của mình dưới hai năm lên mức tăng 33%.

Về cơ bản, hãy nghĩ về giá trị công việc của bạn và công ty cần bạn bao nhiêu. Nếu họ không đủ khả năng để trả cho bạn mức lương bạn đã kiếm được, thì công ty cần phải xem xét chi phí của họ hoặc nhận ra rằng việc kinh doanh của họ không hiệu quả.

Và như nhiều người đã đề cập ở đây, và tôi đồng ý, bạn là một mảnh ghép rất có giá trị của câu đố công ty. Chết tiệt, có lẽ bạn là người duy nhất có thể giải câu đố đó. :)

Vì tôi chưa thể nhận xét vì tôi là người ẩn trên trang web Stack Exchange này, tôi sẽ chỉ thêm vào thông tin ở đây.

1. Vì bạn chỉ mới bắt đầu, nên mức lương của bạn sẽ không cao, trừ khi bạn đi làm cho một công ty lớn như Microsoft, Amazon hoặc một cái gì đó tương tự. Nhưng nó không nên là của một nhân viên tạp hóa! Đừng cố chấp với điều đó lâu dài, hãy tích lũy kinh nghiệm làm những gì bạn đang làm và tiếp tục khi có cơ hội tốt hơn.

2. Đối với một mức biểu diễn đầu vào, đây là loại bình thường. Khối lượng công việc của bạn quá cao, nhưng loại công việc dự kiến. Để trở thành một nhà phát triển tốt hơn, bạn phải học hỏi từ những sai lầm của người khác. Bạn càng thấy, bạn càng trở nên tốt hơn. Nhưng điều đó ngụ ý rằng bạn đang tìm kiếm những thứ để học hỏi, chứ không phải học những thói quen xấu ...

3. Tỷ lệ bảo trì cho công việc dự án nên thay đổi theo thời gian. Nếu không, điều đó có nghĩa là công ty bạn làm việc không nhận ra làm thế nào để giữ một nhà phát triển giỏi; họ dự định sẽ làm cho bạn làm điều tương tự ngày này qua ngày khác. Thực hiện một mục tiêu hàng năm cho bản thân như nơi bạn muốn trở thành, mức lương và kỳ vọng công việc là khôn ngoan, và di chuyển theo đó.

4) Nếu bạn không vui, hãy rời đi! Cuộc sống quá ngắn để đối phó với những người ngu ngốc.

Tất cả tốt nhất.

Bạn bắt đầu sử dụng trình theo dõi vấn đề để theo dõi danh sách việc cần làm của mình.

Điều này không chỉ giúp bạn theo dõi những gì quan trọng, mà còn giúp người dùng và sếp của bạn nhìn thấy khối lượng công việc hiện tại của bạn là gì.

Ngoài ra, nếu họ từng thuê một nhà phát triển thứ hai (hoặc bạn bỏ việc và người thay thế của bạn hiện chiếm khối lượng công việc của bạn), điều này sẽ giúp quản lý khối lượng công việc và bạn sẽ có thể tránh bước lên từng ngón chân khác.

Cách duy nhất để phá vỡ chuỗi này là phát triển cơ sở hạ tầng mới được thiết kế để linh hoạt và được thử nghiệm tích hợp toàn bộ đơn vị +.

Nếu bạn quản lý để bán nó cho ban quản lý (ký tên các nhà phát triển và quản lý khác cho khái niệm này trong các cuộc họp 1: 1), thì bạn có thể từ từ đạt đến trạng thái, nơi hầu hết mã của ứng dụng nằm trong cơ sở hạ tầng và rất dễ để mở rộng và duy trì, trong khi các ứng dụng thực tế có trọng lượng nhẹ và có thể được viết khá nhanh.

Sự phát triển của cơ sở hạ tầng có thể cho phép trước tiên thay thế các bộ phận của các ứng dụng hiện có và sau một thời gian (có thể mất vài năm) thay thế toàn bộ ứng dụng.

Về lâu dài, nó có thể giảm thời gian phát triển các ứng dụng mới và thời gian bảo trì các ứng dụng hiện có trong tương lai.

Sự phát triển mới sẽ đòi hỏi sự cống hiến ít nhất 80% (tốt nhất là nhiều hơn) với một nhóm nhiều hơn một nhà phát triển (một vài ý tưởng tốt hơn một). Tất cả các nhà phát triển sẽ cần có khả năng suy nghĩ sáng tạo và phá vỡ các định kiến ​​hiện có.

Hãy thử xác định và thiết kế cấp cao như một cơ sở hạ tầng mới, sau đó trình bày định nghĩa cho các đồng nghiệp của bạn và cho quản lý.

Theo điều kiện làm việc của bạn, hãy yêu cầu lãnh đạo một nhóm cơ sở hạ tầng mới giải quyết các vấn đề này (dựa trên định nghĩa và thiết kế của bạn) và đưa các nhà phát triển mới để duy trì công cụ cũ trong khi bạn hỗ trợ họ nếu cần thiết (tối đa 10-20% thời gian). Nếu quản lý đồng ý với ý tưởng, bạn có thể yêu cầu đàm phán lại các điều khoản của bạn. Hãy chuẩn bị để tìm một công việc khác nếu họ từ chối. (Hãy nhớ rằng, công việc của bạn đòi hỏi kỹ năng, kiến ​​thức và kinh nghiệm, bạn không dễ thay thế như họ đang trả tiền cho bạn để tin tưởng.)

Người quản lý của bạn có biết về tất cả các yêu cầu thay đổi này (yêu cầu bảo trì) không? Anh ấy có nhận ra rằng thời gian của bạn đã bị mất qua các yêu cầu như vậy mà bạn không có thẩm quyền xử phạt? Hay bạn chỉ thực hiện thay đổi mỗi khi người quản lý hỏi bạn?

Đối với tôi, dường như cổng gọi đầu tiên của bạn là đặt tất cả lên bàn của người quản lý. Không ai nên đến trực tiếp với bạn. Các vấn đề nên thông qua bất kỳ lĩnh vực nào như vậy - thường là một nhóm hỗ trợ. Điều bình thường là bạn hỗ trợ mã của mình trong một khoảng thời gian chuyển giao ngắn - thường là một tuần hoặc lâu hơn. Các thay đổi nên được tính phí và tính phí (tính phí chuyển khoản) trong bất kỳ công ty nào tự phân loại là "kích thước trung bình" và điều này dường như đang được bỏ qua (không có gì lạ khi chúng tràn ngập bạn - bạn giống như một con đĩ tại vũ hội).

Cần có một quy trình yêu cầu thích hợp cho cả vấn đề nêu ra và thay đổi yêu cầu. Hỗ trợ / bảo trì là về sửa lỗi và sự cố (phù hợp với đặc điểm kỹ thuật ban đầu, nhưng không thành công do lỗi trong mã hoặc sự kiện bên ngoài - chẳng hạn như hệ thống ngược dòng bị hỏng hoặc hỏng, v.v.).

Nếu công ty của bạn không cung cấp điều này và mong bạn đối phó và chịu trách nhiệm cho vô số yêu cầu ngẫu nhiên này, thì bạn cần cân nhắc nghiêm túc để tiếp tục. Tiền lương luôn kém ở mức thấp nhất - trong công việc lập trình đầu tiên của tôi (gần 25 năm trước) tôi đã dành 8 năm cho cùng một công ty và tiền lương của tôi tăng rất ít (mặc dù nó luôn cao hơn nhiều so với một nhân viên thu ngân!). Trong vòng 2 năm sau khi ra đi, tôi đã nhân đôi số tiền đó - và hai năm sau đó tôi đã về nhà gấp mười lần so với lúc tôi bắt đầu (nhưng sau đó là một nhà thầu độc lập). Như mọi khi, kiếm được bạn thúc đẩy, tìm hiểu giao dịch của bạn và nhảy tàu đến môi trường xung quanh ấm hơn.

Có lẽ bạn đang ở vị trí để đến gặp người quản lý và nói: "Hãy nhìn xem, tôi sẽ thẳng thắn với bạn. Tiền lương của tôi rất tệ, tôi có thể nhận được N lần này với tư cách là một lập trình viên cấp đầu vào tại X.

Tôi đang làm quá nhiều thứ với A, B và C. Tôi không thể duy trì điều này. Thành thật mà nói, và không có ý định xúc phạm, tôi sẽ đi ra khỏi căn phòng này với điều này hoặc là cố định, hoặc với lá thư từ chức của tôi để lại với bạn. Bây giờ đây là tất cả trong không khí, làm thế nào chúng ta có thể làm việc cùng nhau để làm điều này đúng? "

Câu trả lời là thử và giải thích nó theo thuật ngữ có thể hiểu được;

• Nó giống như thay dầu. Họ không khẩn cấp .... nhưng phải được thực hiện thường xuyên không hơn không kém
• sơn trên gỉ và nó sẽ trông tuyệt vời. Cho đến khi nó chảy máu qua
• xây dựng một mái nhà mới trên mái nhà bàn mà không có hỗ trợ mạnh mẽ. Nó sẽ làm việc trong một thời gian có thể. Sau đó, nó sẽ sụp đổ và làm tổn thương mọi người và bạn sẽ chịu trách nhiệm.
• a / c là tuyệt vời. Một đơn vị cửa sổ là tuyệt vời cho một hoặc hai phòng. Cố gắng đặt 146 máy điều hòa không khí cửa sổ trong một tòa nhà và bạn sẽ gặp ... vấn đề.
• Dạy 5 đứa trẻ là ổn. 10 không quá tệ. Nhưng có giới hạn. Hãy thử dạy không chính thức 75 đứa trẻ và bạn sẽ thấy điều này.

Nếu những điều này không gây được tiếng vang. Rời đi - NGÀY BẠN NHẬN MỘT ƯU ĐÃI VỀ VIẾT, không phải ngày hôm sau! Khi bạn CÓ một công việc mới, hãy để lại thông báo ZERO. Nghĩa đen là không đến vào ngày đó. Nhưng hãy chắc chắn rằng bạn có một hoặc hai đồng nghiệp biết bạn đã làm gì. Điều này thực sự sẽ giúp công ty thoát ra, nếu công ty có thể giúp đỡ, bằng cách cho họ thấy rằng sự thiếu tôn trọng và kiêu ngạo của họ phải trả giá. Công ty cuối cùng tôi đã ở BA BA BỐN CÔNG NGHỆ TRONG VÒNG 6 THÁNG KHÔNG CÓ CÔNG VIỆC ĐẾN. Nó đã đưa ra một tuyên bố ít nhất và cho người rời đi một lần cơ hội tốt để nói, 'vâng, bs tốt đẹp bạn nói mỗi ngày nhưng bạn rất đầy đủ, tôi thậm chí không cung cấp cho bạn sự hài lòng về thông báo của tôi.

Cuối cùng, phải biết rằng vấn đề này là BÌNH THƯỜNG và tiêu chuẩn 20 năm trước trước khi nhanh nhẹn, tdd, bdd và tái cấu trúc trở nên bình thường hơn. Bạn có thể đang nói chuyện với những người cao cấp, những người ngay lập tức trả lời "tôi đã tự làm việc này và nó hoạt động tốt, blah, blah, blah." Chà, ngựa và xe ngựa đã hoạt động tốt 150 năm trước. Trong các lĩnh vực công nghệ, các kỹ thuật từ 20 năm trước đã lỗi thời như vận chuyển từ 150 năm trước. Nếu họ từ chối khoản tiền phạt này. Chỉ cần biết rằng họ sẽ không bao giờ thuê bất kỳ nhà phát triển công nghệ hiện tại tử tế nào sẽ gắn bó. Họ sẽ nhận được điều tồi tệ nhất trong những điều tồi tệ nhất và điều đó sẽ làm tổn thương doanh nghiệp của họ khủng khiếp. Nếu họ phụ thuộc vào công nghệ và không thể thích nghi, họ sẽ thất bại và cuối cùng đó có thể là phần thưởng tốt nhất cho bạn. Nó '

Có vẻ như quản lý của bạn về cơ bản không tôn trọng bạn hoặc hiểu khối lượng công việc của bạn.

Bạn không nên thực hiện mọi yêu cầu tính năng đi qua. Người quản lý của bạn nên đóng vai trò là bộ đệm giữa bạn và các yêu cầu đến (ngoại trừ các yêu cầu ngắt / sửa lỗi đơn giản nhất). Sau đó, anh ấy hoặc cô ấy nên ngồi lại với bạn và xác định tính khả thi và ưu tiên cho bất kỳ yêu cầu được phê duyệt.

Ngoài ra, bạn nên kiếm gấp đôi (ít nhất) số tiền họ đang trả cho bạn.

Có vẻ như họ có thể thực sự cần ít nhất 1 nhà phát triển để làm việc cùng với bạn, nhưng với những gì họ trả cho bạn thì điều đó nghe có vẻ khó xảy ra.

Nếu họ không sẵn lòng trả cho bạn hoặc giúp bạn quản lý khối lượng công việc của bạn, tôi sẽ tìm một công việc mới. Bạn muốn làm việc ở một nơi nào đó nơi bạn là thành viên của một nhóm và nơi quản lý của bạn làm việc với bạn để hoàn thành các dự án của bạn. Xuống tàu chìm ngay khi bạn có thể.

Trở thành anh hùng trong đội một người sẽ chỉ khiến bạn kiệt sức.

Tôi chỉ là một sinh viên (vẫn) nhưng điều đó khá bình thường (từ kinh nghiệm thực tập của tôi). Đó là những gì bạn nhận được khi làm việc trong các ứng dụng hỗ trợ và web.

Tôi khuyên bạn nên hiểu khách hàng (người quản lý) muốn gì trước khi bắt đầu viết mã. Điều đó có thể khó khăn vì đôi khi chính họ không biết điều đó nên làm việc với họ cho đến khi họ đồng ý về điều gì đó. Hãy chắc chắn rằng cả hai bạn đồng ý về giải pháp cuối cùng trước khi bạn viết mã.

Ngoài ra nếu bạn là người bảo trì, bạn có thể thay đổi khá nhiều thứ trong mã - chỉ cần đảm bảo rằng nó không thay đổi hành vi hoặc đưa ra lỗi. Tôi hy vọng các nhà quản lý không 'cho phép' bạn thay đổi bất cứ điều gì vì họ đã quen và hài lòng với hiện tại và họ không muốn trả tiền cho bất kỳ thay đổi mới nào.

Cuối cùng, đừng lo lắng nếu bạn không thể xử lý một cái gì đó vì bạn đang làm một cái gì đó khác. Tôi khuyên bạn nên cho mọi người biết rằng bạn quá mải mê với công việc và yêu cầu của họ sẽ mất thời gian. Nếu bạn không quản lý sẽ chỉ nghĩ rằng bạn lười biếng. Hãy cho họ biết bạn đã có việc làm và họ có thể thuê thêm người. Không có cách nào khác để họ biết rằng công việc là quá nhiều cho một người.

Đây là một vấn đề quản lý dự án. Sử dụng một số loại quản lý dự án để quyết định những gì là ưu tiên cao nhất để làm việc trên.

a) Bạn cần tồn đọng các hạng mục để làm việc. Bạn đặt kế hoạch của bạn để cải thiện mã trong backlog.

b) Tất cả các lỗi đi vào tồn đọng

c) Backlog được ưu tiên.

d) Bạn làm tất cả theo thứ tự ưu tiên.

Lỗi rất có thể là ưu tiên cao hơn, nhưng nếu một khi bạn sửa tất cả những gì bạn có chu kỳ để chi cho các tính năng mới hoặc thiết kế tái cấu trúc.

Thật dễ dàng nếu bạn chỉ thực hiện tái cấu trúc các cải tiến tăng dần, khi bạn vượt qua các phần có vấn đề / lỗi cần khắc phục. Sau đó, bạn có thể nói với quản lý: "Tôi phải sửa A, nhưng B đã bị hỏng cơ bản và tôi phải làm giải pháp C để sửa tất cả để D sẽ dễ dàng / rẻ hơn trong tương lai" Trong đó A = Lỗi, B = The chống mẫu, C = Giải pháp, D = Lợi nhuận trong tương lai

Nếu bạn không thể biện minh công việc là một khoản đầu tư đáng làm, người kinh doanh sẽ không bao giờ chấp nhận nó.

Đây là kinh doanh như bình thường. Bạn sẽ được khai thác miễn là bạn tiếp tục làm việc ở đó. Đó là lợi ích tốt nhất của công ty để tiếp tục với mô hình này hơn là làm cho bạn cảm thấy hạnh phúc trong những gì bạn đang làm. Khi nói đến nó, họ không thực sự quan tâm. Đó là về việc tạo mã đáng tin cậy cho họ và nếu bạn là một nhóm nhạc một người, họ chắc chắn sẽ tạo ra ngân hàng cho bạn. Tại sao họ sẽ thay đổi?

Tin tốt cho tất cả những điều này là bạn là một VIP đối với họ ngay cả khi họ không biết điều đó. Những gì tôi đề nghị làm là sắp xếp thêm một số cơ hội trước khi nhảy tàu sau đó lấy chúng bằng những quả bóng và yêu cầu mức lương cao hơn. Nếu không chuyển đến một cơ hội tốt hơn. Theo tôi, bạn nên sớm tìm thấy một số công việc thú vị hơn. Mục tiêu cao như bạn có thể. Khi bạn đến một cửa hàng dành cho nhà phát triển, bạn sẽ hạnh phúc hơn nhiều như Google hoặc một số khởi nghiệp thú vị nơi có văn hóa nhà phát triển hợp tác nơi bạn sẽ thực sự cảm thấy hạnh phúc.

Những gì tôi đã làm cá nhân là sử dụng một tổ chức nhà thầu săn đầu người và nhanh chóng có được nhiều kinh nghiệm tuyệt vời, chuyển từ người này sang người khác trong khi vẫn duy trì việc làm ổn định từ nhà thầu của tôi. Nó giữ cho bạn khỏi chán và thách thức bạn. Cuối cùng, trong thời gian rảnh rỗi, tôi đã xây dựng một số doanh nghiệp nhỏ phát triển thành kinh doanh thực tế, và sau đó tôi đã nhảy ra khỏi công việc hợp đồng.