Làm thế nào để đề xuất thay đổi như một nhân viên được tuyển dụng gần đây? [đóng cửa]

Gần đây tôi đã được thuê trong một công ty lớn (hàng ngàn người, để đưa ra ý tưởng về quy mô). Họ nói rằng họ thuê tôi vì sự nghiêm khắc của tôi và vì tôi, mặc dù còn trẻ (tôi 25 tuổi), có kinh nghiệm làm lập trình viên C / C ++.

Bây giờ tôi đã vào, tôi có thể thấy rằng toàn bộ hệ thống đã cũ và thường sử dụng các công nghệ lạc hậu. Không có quy ước đặt tên (tệp, chức năng, biến, ...), họ không sử dụng Kiểm soát phiên bản, không sử dụng ngoại lệ hoặc đa hình và có vẻ như hầu hết mọi người đều mất niềm đam mê của mình (một số trong số họ chỉ mới 30 tuổi ).

Tôi muốn đề xuất thay đổi somes nhưng tôi không muốn trở thành "chàng trai mới muốn thay đổi mọi thứ chỉ vì anh ta không muốn hòa nhập". Tôi đã cố gắng "hòa nhập", nhưng thực sự, tôi phải mất một tuần để làm những gì tôi sẽ làm trong một buổi chiều, chỉ vì những công cụ kém mà chúng tôi buộc phải sử dụng. Rất nhiều đồng nghiệp của tôi không bao giờ nhìn vào "những thứ" và kỹ thuật mới mà mọi người sử dụng ngày nay. Giống như họ vừa bỏ cuộc. Tình hình thực sự rất bực bội.

Bạn đã bao giờ ở trong một tình huống tương tự và, nếu vậy, bạn sẽ cho tôi lời khuyên gì? Có một cách tinh tế để thay đổi mọi thứ mà không trở thành con cừu đen ở đây? Hay tôi cũng nên từ bỏ đam mê và năng lượng của mình?

Cảm ơn bạn.

Cập nhật

Theo lời khuyên quý giá của bạn, tôi đã có thể đề xuất các thay đổi và hiện đang chịu trách nhiệm về nhóm phải tạo và triển khai Subversion: D Cảm ơn tất cả các bạn!

6 tháng sau

Tôi nghỉ việc và tìm thấy một môi trường thú vị hơn nhiều, với mức lương tốt hơn nhiều, và những thử thách thú vị hơn. Tôi sẽ không quay trở lại vì bất cứ điều gì.

Tôi đã ở trong một tình huống tương tự tại công ty trước đây của tôi, nơi tôi đã ở trong 5 năm. Khi tôi tham gia năm 2004, họ là:

• vẫn sử dụng Microsoft Access cho cơ sở dữ liệu của họ (ngay cả những doanh nghiệp quan trọng)
• sử dụng Visual Basic 6 hoặc Access / Excel VBA để phát triển
• sử dụng nhiều bên thứ ba thay vì sử dụng tài nguyên phát triển nội bộ (các nhà quản lý doanh nghiệp đã lãnh đạo các dự án phát triển của riêng họ và 90% thời gian đưa ra các hợp đồng để đấu thầu mà không có kiến ​​thức về CNTT)
• thở hổn hển không kiểm soát phiên bản.

Khi tôi rời đi năm ngoái, công ty là:

• sử dụng riêng .NET và C #
• đã trục xuất tất cả sự phát triển của Access
• sử dụng SVN để kiểm soát phiên bản
• có 2 hộp SQL Server mạnh mẽ và đang di chuyển cơ sở dữ liệu Access hiện có sang SQL
• tất cả sự phát triển đều thông qua các đội trong nhà và chỉ tham gia đấu thầu nếu nguồn lực bị hạn chế

Lúc đó tôi chưa tròn 21 tuổi và người trẻ nhất tiếp theo trong nhóm phát triển là 30. Tôi đã không tự mình làm tất cả. Người quản lý CNTT đã gia nhập công ty cùng một lúc và muốn mang lại sự phát triển thông qua CNTT.

SVN là thành tựu đầu tiên của tôi. Tôi đã có một cuộc họp với quản lý trực tiếp của mình và nhấn mạnh một vài tình huống mã được đặt trực tiếp hoặc thay đổi gây ra vấn đề và nhấn mạnh thực tế là không có trách nhiệm - về cơ bản, anh ta không thể đổ lỗi cho ai bắt đầu lắng nghe

Sau đó, tôi cùng nhau trình bày cho nhóm và giải thích khái niệm kiểm soát phiên bản và giới thiệu một vài tình huống trong đó SVN có thể giúp chúng tôi phát triển. Những người trẻ hơn đã coi nó như một con vịt để tưới nước, những người lớn tuổi hơn không nhiều nhưng họ đã cố gắng và không phàn nàn về những người đã sử dụng nó.

Một thành tựu lớn khác là mang lại một hệ thống hoàn chỉnh trong nhà - Tôi dẫn đầu một dự án giúp công ty tiết kiệm được 120 nghìn bảng mỗi năm khi cấp phép. Tôi đã dành khoảng 2 tháng thời gian rảnh rỗi để viết một hệ thống mới, và trình bày cho người quản lý CNTT và giải thích về việc tiết kiệm chi phí. Sau đó, anh ấy cho phép tôi trình bày nó cho doanh nghiệp và giải thích cách chúng tôi có thể thực hiện bất cứ điều gì họ thích vào hệ thống - không còn bị giới hạn trong các hệ thống "ngoài luồng".

4 tuần sau, hệ thống của tôi đã được thử nghiệm ở 10 địa điểm và 6 tháng sau nó đã hoạt động. Một năm sau họ đã hủy hợp đồng của bên thứ ba, xóa tất cả dấu vết của nó khỏi mạng và đến với chúng tôi để yêu cầu nâng cao lớn cho hệ thống nội bộ của chúng tôi.

Lơi khuyên của tôi danh cho bạn:

• nếu bạn quan tâm đến công ty, hãy gắn bó với nó Nếu người khác không thích cách tiếp cận của bạn, hãy để họ đồng ý với bạn - đó là tất cả về sự thỏa hiệp
• Điều chỉnh các đề xuất cho người bạn đang nói chuyện - các nhà quản lý muốn nghe về cách họ có thể a) tiết kiệm tiền, b) đổ lỗi chính xác cho mọi người khi có sự cố, nhưng các nhà phát triển muốn nghe cách họ có thể a) tiết kiệm thời gian, b) gắn bó cho bản thân họ, ví dụ
• nếu bạn đam mê thay đổi (nghe có vẻ giống bạn) thì hãy cho mọi người thấy sự nhiệt tình của bạn và đừng nản chí khi họ không nhiệt tình
• Đừng nói về việc thay đổi. Làm cho họ. Khi bạn bắt đầu tạo ra công việc tuyệt vời trong thời gian ngắn hơn những người có kinh nghiệm hơn, mọi người sẽ bắt đầu hỏi "tại sao?"

Họ nói rằng họ thuê tôi vì sự nghiêm khắc của tôi và vì tôi, mặc dù còn trẻ (tôi 25 tuổi), có kinh nghiệm làm lập trình viên C / C ++.

Nhiều khả năng vì bạn rẻ hơn.

Bạn đã bao giờ ở trong một tình huống tương tự

Đúng.

bạn có lời khuyên gì cho tôi

Rời khỏi.

Có một cách tinh tế để thay đổi mọi thứ mà không trở thành con cừu đen ở đây?

Có thể có. Giới thiệu những thay đổi và chứng minh cách họ cải thiện mọi thứ cho mọi người. Sau khi bạn đã thực hiện nó một số lần, bạn có thể nhận được sự đánh giá cao từ những người không bị mất.

Hay tôi cũng nên từ bỏ đam mê và năng lượng của mình?

Không đời nào. Bạn còn trẻ và bạn phải tận dụng tối đa các cơ hội. Đừng lãng phí năm "ở đâu đó". Nhìn vào vị trí này và hiểu liệu nó sẽ cung cấp cho bạn kinh nghiệm quý giá để thúc đẩy sự nghiệp của bạn hơn nữa. Nếu bạn nhìn thấy cơ hội, hãy khám phá chúng. Nếu không có ai và đó chỉ là "một công việc", hãy ra ngoài. Thực tế cho thấy, những người mất niềm đam mê (hoặc chưa bao giờ có nó) không thể có được nó. Hãy tìm một đội ngũ những người đam mê và tham gia cùng họ.

Dẫn bằng ví dụ . Thay đổi nhỏ bất thường tại thời điểm. Kéo qua một đồng nghiệp và giới thiệu một cái gì đó cho họ. Nếu họ không hiểu thì đừng bao giờ thử lại lần khác.

Nó sẽ tốn thời gian. Chỉ cần đừng kéo mọi người ra khỏi vùng thoải mái của họ quá nhanh.

Buồn nhưng đó là lý do tại sao bạn ở đây và họ không.

Ví dụ. Thiết lập kiểm soát phiên bản cục bộ và chỉ cho họ cách nó có thể giúp đỡ. Sau đó cung cấp cho họ một số tài nguyên (đọc đơn giản) có thể sao lưu cho bạn.

Một điều khác về các công cụ . Đôi khi bạn phải bỏ tiền của mình để mua các công cụ tốt hơn. Tôi biết đó không phải là "việc đã làm" nhưng khi tôi nói chuyện với các ngành nghề khác, tôi thấy nhiều kỹ sư 'thực sự' thời trang / mua bộ công cụ của riêng họ để thực hiện công việc tốt hơn. Tôi đã luôn luôn làm điều này khi tôi có thể thấy rằng tôi tự cứu mình khỏi các kỹ năng teo.

Tôi là một ông già (51) và tôi đã gặp vấn đề tương tự ở mọi công việc tôi từng làm. Có lẽ nó xuất phát từ việc luôn là người thông minh nhất trong phòng! :-) Nghiêm túc, mặc dù, khi bạn biết cách làm đúng và họ không, bạn thường nghĩ, "Này, tôi sẽ cho mọi người thấy kỹ thuật mới và cải tiến này và tất cả họ sẽ bị ấn tượng và muốn nhảy vào sử dụng nó. " Nhưng trong cuộc sống thực, 90% thời gian, bạn chỉ cho mọi người một cách tốt hơn và họ đưa ra một danh sách dài những lý do để giải thích tại sao cách họ làm việc đó lại tốt hơn. Khi bạn chứng minh rằng lý do của họ không hợp lệ, họ sẽ đưa ra những lý do mới, thậm chí còn tệ hơn. Tôi đã có rất nhiều lần tôi

Ngay cả khi bạn thực sự là một thiên tài, bạn phải chấp nhận rằng không ai khác biết bạn là thiên tài cho đến khi bạn chứng minh điều đó. Tôi nhớ đến Kris, một người bạn của tôi, người đã bắt đầu một công việc mới sau khi trải qua 10 năm với một công ty. Ngay sau khi bắt đầu công việc mới, anh ấy đã có mặt tại một cuộc họp nơi họ đang thảo luận về một số vấn đề kỹ thuật và anh ấy bắt đầu đưa ra giải pháp đề xuất của mình. Sau đó, một người khác ngắt lời và nói, "Vâng, cảm ơn. Bob, bạn nghĩ gì?" Lúc đầu anh bực mình: Anh biết câu trả lời đúng, nhưng không ai quan tâm! Thay vào đó họ đã đi với ý kiến ​​của một người biết ít hơn rất nhiều sau đó anh ta đã làm. Nhưng sau đó anh ấy nhận ra, tại công việc cũ của tôi, tôi đã tạo dựng được danh tiếng như một người biết anh ấy đang nói về điều gì, vì vậy khi tôi nói chuyện, mọi người lắng nghe. Ở đây, tôi chưa có tiếng tăm, nên không ai quan tâm tôi nghĩ gì.

Tôi đã ở công việc hiện tại được 2 năm và chỉ trong vài tháng gần đây, ý kiến ​​của tôi đã bắt đầu có trọng lượng thực sự. Bạn phải kiên nhẫn.

Mặt khác, những người mới thường có một triệu đề xuất cải tiến thực sự không thực tế, vì họ chưa biết đủ về tổ chức và vì vậy họ không biết tại sao mọi việc lại được thực hiện theo cách của họ. Đôi khi mọi người tiếp tục làm một cái gì đó theo cách tương tự trong 20 năm bởi vì đó chỉ là cách nó luôn được thực hiện và không ai từng nghĩ sẽ tìm kiếm một cách tốt hơn; nhưng đôi khi mọi người tiếp tục làm một cái gì đó theo cách tương tự trong 20 năm bởi vì kinh nghiệm đã cho thấy đó là một cách tốt để làm điều đó và mỗi khi họ thử một thứ gì đó khác nhau thì đó là một thảm họa. Vì vậy, đừng quá nhanh để kết luận tất cả những người này là những kẻ ngốc. Tìm hiểu lý do tại sao họ làm theo cách cũ trước khi bạn đưa ra đề xuất mới tuyệt vời của mình. Tôi đã có rất nhiều lần trong đời khi tôi

Tìm đồng minh, những người cũng muốn cải thiện công ty.

Có một cái gì đó được nói để bảo lãnh bây giờ và để chúng bị thối rữa. Tuy nhiên, nó sẽ trông tuyệt vời trong sơ yếu lý lịch của bạn nếu bạn vô địch kiểm soát phiên bản thành công và các cải tiến khác.

Sử dụng Joel Test trong các cuộc phỏng vấn trong tương lai của bạn. Hãy nhớ rằng bạn đang phỏng vấn công ty quá.

Lời khuyên đầu tiên của tôi là đừng cố gắng thay đổi quá sớm. Đầu tiên hãy nổi tiếng là một nhà phát triển đáng tin cậy, người có thể hoàn thành công việc. Ngay bây giờ là người mới, bất cứ điều gì bạn đề nghị là đáng ngờ; họ chưa biết và tôn trọng bạn. Lấy sự tôn trọng đó là bước đầu tiên của bạn. Sau đó là thời gian để bắt đầu giới thiệu thay đổi.

Chọn bạn mặt đất cẩn thận. Bắt đầu với kiểm soát phiên bản không phải là công nghệ mới. Bởi vì đó thực sự là thay đổi quan trọng nhất. Bạn thậm chí có thể làm điều đó chỉ với mã của mình và sau đó đảm bảo rằng khi bạn phải quay lại phiên bản trước hoặc copmpare để tìm hiểu những gì đã thay đổi, bạn cho mọi người biết nó dễ dàng như thế nào trong cuộc trò chuyện thông thường.

Sử dụng kiến ​​thức hiện tại của bạn để trở thành người tỏa sáng và sau đó mọi người sẽ bắt đầu hỏi bạn làm thế nào để thực hiện điều này. Khi lần đầu tiên đến nơi làm việc, tôi làm việc cho một cơ quan kiểm toán của chính phủ. Các tiền bối đều chống lại việc có máy tính riêng của họ (vì đó là công việc cho các thư ký). Các đàn em đã chộp lấy tất cả các máy tính đầu tiên và bắt đầu làm những việc mà các đàn anh không thể làm với Lotus 1-2-3 và Harvard Graphics và đột nhiên, những người lớn tuổi quan tâm vì các chàng trai trẻ đang thu hút sự chú ý của quản lý cấp cao.

Thay đổi văn hóa tổ chức không phải là vấn đề kỹ thuật, đó là vấn đề chính trị. Làm một số đọc về quản lý chính trị văn phòng. Bạn sẽ cần hỗ trợ chính trị ở mức cao.

Tôi đã gặp một tình huống tương tự tại công việc hiện tại của tôi. Tôi đã được thuê thẳng ra khỏi trường học để làm việc trong một nhóm mà hầu hết là các kỹ sư đã ở đây hơn 15 năm. Thực hiện các thay đổi là không dễ dàng (tôi vẫn đang cố gắng thực hiện một số việc), nhưng có thể.

Ví dụ: nhóm của tôi đang duy trì, cập nhật và sử dụng tiện ích kiểm tra DOS 16 bit. Tiện ích là một nỗi đau hoàng gia để cập nhật, vì ứng dụng đã đẩy các giới hạn của trình liên kết 16 bit đến điểm mà nếu bạn thêm mã, bạn phải xóa một cái gì đó khác để phù hợp. Khi được hỏi tại sao chúng ta lại lãng phí quá nhiều thời gian và năng lượng cho mã 16 bit, câu trả lời của họ là "vì chúng ta cần nó để chạy trong DOS để chúng ta có thể chạy nó khỏi ổ flash có thể khởi động". Tôi đã cố gắng thuyết phục họ chuyển tiện ích sang Linux 32 bit, nhưng ban quản lý không muốn đầu tư thời gian để làm điều đó (chúng tôi đã có quá nhiều việc phải làm như vậy). Vì vậy, tôi đã đi trước và chuyển tiện ích trong thời gian xuống (15 phút ở đây và ở đó vào bữa trưa, vào cuối tuần, hoặc trong khi tôi đang chờ mã khác để biên dịch). Trong một vài tháng, Tôi đã có tiện ích hoàn toàn được chuyển, được cải tiến với tất cả các loại mà ứng dụng 16 bit gốc không thể xử lý và khởi động từ ổ đĩa flash Linux. Mọi người nhận thấy khi tôi bắt đầu sử dụng nó, và đang bình luận về cách tôi có thể hoàn thành công việc nhanh hơn và cách tiện ích của tôi tạo ra đầu ra gỡ lỗi tốt hơn. Khá sớm, quản lý nghe về nó. Một khi họ thấy được lợi ích (và quan trọng nhất là công việc đã được thực hiện), họ không còn phản đối ý tưởng đó nữa.

Bài học tôi học được từ câu chuyện này là: Nếu bạn nghĩ bạn có thể cải thiện điều gì đó, hãy nói chuyện với người quản lý của bạn về nó. Nếu họ không muốn dành tài nguyên cho nó, hãy tự mình làm và chứng minh với họ rằng ý tưởng của bạn là hợp lệ và hữu ích. Sẽ dễ dàng hơn nhiều để nói không với một ý tưởng mà ai đó đề xuất hơn là một điều gì đó mà bạn thấy trước mặt có giá trị rõ ràng.

Khi nhóm / người quản lý của bạn thực hiện ý tưởng của bạn và bắt đầu thấy được lợi ích của nó, họ sẽ có nhiều khả năng lắng nghe ý tưởng của bạn trong tương lai. Tôi đã sử dụng "tín dụng đường phố" mà tôi kiếm được từ công cụ kiểm tra viết lại để thuyết phục nhóm của mình rằng chúng tôi cần bỏ hệ thống kiểm soát phiên bản cổ xưa hiện tại của chúng tôi (sẽ ẩn danh để tránh bối rối) và chuyển sang Subversion. Tôi tình nguyện lãnh đạo nỗ lực thiết lập / di chuyển để giúp đảm bảo rằng ban quản lý sẽ phê duyệt nó.

Đó là một loại "một bước tại một thời điểm". Có thể có rất nhiều thứ bạn muốn thay đổi, nhưng hãy chọn một cái gì đó nhỏ (ish) để bắt đầu. Thể hiện chất lượng ý tưởng của bạn theo cách mà nhóm và người quản lý của bạn không thể nói 'không' với. Giống như tài khoản stackoverflow của bạn, bạn càng có nhiều ý tưởng tốt, danh tiếng của bạn sẽ càng tốt và càng dễ dàng để ý tưởng của bạn được chấp nhận.

Chắc chắn bắt đầu sử dụng các công cụ bạn muốn bạn có tại địa phương (nơi bạn có thể - một số công ty dường như cũng kiểm soát những gì bạn có thể cài đặt trên hộp của mình với một nắm tay kỳ quặc). Thiết lập hệ thống kiểm soát phiên bản yêu thích của bạn và bắt đầu sử dụng nó. Trong bất kỳ mã nào bạn chạm vào, hãy thực hiện các thay đổi nhỏ giúp mã sạch hơn, đặc biệt là nơi bạn có thể viết bất kỳ mã mới nào. Nếu họ thuê bạn vì sự nghiêm khắc và kinh nghiệm của bạn, điều đó có nghĩa là họ đã tôn trọng bạn.

Gần đây tôi đã đọc H thuê Ren và Kích thích , và thấy ví dụ Kích thích là một thách thức lớn. Nếu bạn đi theo sự dẫn dắt của anh ấy, cuối cùng bạn sẽ hỏi (độc đáo) tất cả các loại quan điểm từ đồng nghiệp của bạn, giúp bạn biết rằng một nhà phát triển không đam mê sẽ không biết. Bạn sẽ dành bất kỳ thời gian rảnh rỗi nào bạn có những cách mơ ước để cải thiện. Nếu công ty thấy công việc của bạn là có giá trị, bạn sẽ trở nên vô giá. Nếu họ không, có lẽ bạn sẽ muốn tìm kiếm việc làm.

Rất nhiều người đã trả lời với các đề xuất để tập trung vào một điều nhỏ tại một thời điểm, và một số người đã đề xuất kiểm soát phiên bản. Tôi sẽ tiến thêm một bước: tạo các kho lưu trữ trên máy tính để bàn của bạn và làm việc từ các kho lưu trữ đó. Cập nhật chúng thường xuyên từ bất cứ kho lưu trữ chính nào mà công ty sử dụng. Khi (không phải) có khủng hoảng vì ai đó đã làm hỏng chủ, hãy nói với họ rằng bạn có thể cắt một bản sao mới từ kho lưu trữ cá nhân của mình.

Tuy nhiên, không trong bất kỳ trường hợp nào, hãy đặt mã công ty trên một máy mà bạn sở hữu hoặc mang về nhà . Bởi vì sau đó bạn có thể thấy rằng, thay vì là một anh hùng, bạn đang ở phía bên trái của bàn làm việc từ một luật sư (tốt nhất) hoặc thực thi pháp luật (tồi tệ nhất).

Đến từ một nhà phát triển cơ sở khác ... bạn có kỹ năng người tuyệt vời không? Bạn có ý thức tuyệt vời về sự tự kiềm chế và hiểu biết khi nào và không phù hợp để đề xuất một ý tưởng, và làm thế nào để bán tốt nhất ý tưởng đó? Ngay cả khi bạn làm thế, bạn vẫn có thể trở thành "gã đó" vì đã nói với người khác cách làm công việc của họ mà không chứng minh giá trị của bạn.

Đây là cách tôi VẪN xây dựng uy tín của mình với tư cách là một nhà phát triển cơ sở: Tôi xác định một người dọn dẹp kink / kydge / time. Sau đó, tôi sửa nó bằng cách tự động hóa nó (tệp bó, tập lệnh powershell, chương trình đơn giản, phần mềm miễn phí mới, bất cứ thứ gì vào cuối tuần) mà không làm phiền ai khác. Tôi chắc chắn biến nó thành một phần của việc tự học kỹ thuật đang diễn ra để tôi có thể nghĩ đó là "bỏ thêm thời gian để dạy cho bản thân một điều mới VÀ giúp công ty".

Nếu cách khắc phục của tôi đặc biệt tiện lợi, tôi chia sẻ nó và nói "Này các bạn, tôi đã tạo ra công cụ tuyệt vời này, nó tự động hóa XY và Z và thực hiện việc này nhanh chóng." Giữ tên của bạn trên đó. Nói lại. Vấn đề uy tín đã được giải quyết trong một vài tháng nếu bạn có tỷ lệ người thực hiện cao cho trình độ của mình và những người ở trên bạn sẽ cởi mở hơn với các đề xuất của bạn nếu bạn sẵn sàng giải thích lý do tại sao ý tưởng của bạn tốt và cách giải quyết vấn đề của họ.

Gần đây tôi đã có thể đề xuất những ý tưởng mới cho quản lý cấp trên đã được chấp nhận, chủ yếu là vì tôi đã dành thời gian để giải thích lý do của mình, lắng nghe phản hồi của họ và có uy tín trong công việc trước đây của tôi.

ĐỊA CHỈ: Nếu người quản lý của bạn đang đặt câu hỏi về hành vi của bạn ... đừng làm điều này trừ khi anh ta cảm thấy hiệu suất của bạn vẫn ở mức "25% hàng đầu", IE đảm bảo rằng sếp của bạn hài lòng với bạn trước khi bạn bắt đầu cố gắng đưa ra tất cả các loại sửa chữa thông minh đẩy bạn cao hơn vào% hàng đầu đó hoặc anh ta sẽ nghĩ bạn đang lãng phí thời gian. Nếu bạn đang đưa ra các tiện ích và giải pháp mới trong khi khơi gợi phản hồi hiệu suất tích cực nhưng anh ấy vẫn khăng khăng vi mô hóa bạn, bạn có thể gặp vấn đề nằm ngoài phạm vi của chủ đề này.

Trộn vào.

Như bạn đã nói, bạn không muốn trở thành con cừu đen. Tuy nhiên, vì bạn (như bản thân tôi) muốn thêm một số thay đổi hữu ích:

Thêm giá trị trong nền.

Thiết lập các cronjobs để kiểm tra mã của mọi người vào svn / hg / git .. Tạo các công cụ của riêng bạn, vào thời gian riêng của bạn, có thể cải thiện đáng kể các nỗ lực phát triển. Cụ thể, bạn muốn cải thiện công ty mà bạn có thể hiển thị cho người cao niên của mình trong tủ của chính bạn. Và đây là lý do:

Yếu tố Wow

Nếu bạn có thể nói "Này Alice, bạn có biết Bob vừa phá vỡ bản dựng không? Tôi có thể hoàn nguyên bản chỉnh sửa của anh ấy và bản dựng lại hoạt động". Và khi tiền bối của bạn nói rằng, chết tiệt, có thể bạn sẽ đánh thức đủ niềm đam mê trong đó mà họ sẽ vượt qua, hoặc ít nhất là khuyến khích các thực hành mới của bạn.

Đây là lời khuyên của tôi.

Tôi đã ở trong một tình huống tương tự, trước tiên tôi nên nói, công ty của tôi khá nhỏ khoảng 6 nhà phát triển, tôi là loại lập trình viên thích sử dụng công nghệ mới, công cụ mới và bất cứ điều gì sẽ giúp công việc của tôi dễ dàng hơn và sản xuất phần mềm chất lượng tốt hơn .

Khi tôi bắt đầu, chúng tôi đang sử dụng Visual Studio 2005, khi VS2008 đã ra mắt khá lâu, nhưng việc ông chủ của tôi bỏ tiền ra để nâng cấp tất cả các nhà phát triển của chúng tôi là không dễ dàng, tôi phải từ từ đưa ra ý tưởng, vì nhiều hơn "thật tốt nếu chúng ta có thể làm điều này", nhưng trước khi tôi đưa nó cho ông chủ của mình, sẽ đảm bảo các nhà phát triển khác sẽ có ý tưởng tốt, bởi vì họ sẽ là những người sử dụng nó và có một nhóm người tham gia ủng hộ sẽ trông giống như một quyết định của một người.

Tôi nghĩ thay vì chỉ đưa ra ý tưởng cho sếp của bạn, có thể từ từ đưa ra bất kỳ thay đổi nào có thể, bởi vì tôi cảm thấy nếu bạn đề xuất ý tưởng sẽ thay đổi công ty theo cách tốt hơn, cũng cho thấy rằng bạn quan tâm đến công việc của mình và cho thấy rằng bạn có kế hoạch về làm nhà ở đó.

Điều này cũng phụ thuộc vào môi trường làm việc và tính cách của sếp bạn, nếu họ thoải mái và đối xử với bạn như gia đình và đưa ra lời khuyên, nhưng hãy đề nghị, nhưng nếu họ đối xử với bạn như một con số, tôi sẽ rất cẩn thận bạn tiếp cận nó

Có thể là một cơ hội của cả cuộc đời - thay đổi cách một công ty làm việc ở tuổi 25. Nếu họ chống lại mặc dù và thể hiện sự thù địch mọi lúc thì đó không phải là nơi dành cho bạn.

Hãy nhớ rằng, cuộc phỏng vấn của bạn là một quá trình hai chiều. Bạn có thể có cảm giác về sự cổ xưa và khả năng chống lại sự thay đổi của chúng.

Ps, tôi cũng 25 tuổi và biết bạn cảm thấy thế nào. Có lẽ bạn rất ham học hỏi và thử những điều mới hơn các đồng nghiệp của mình. Dù sao, phải quay lại công việc .NET4 này mà tôi đang giới thiệu;)

Đọc Bắt đầu mọi thứ khi bạn chỉ là một người lẩm cẩm của Joel Spolsky.

... Đôi khi bạn không có quyền tạo ra sự thay đổi trong tổ chức của mình bằng cách điều hành fiat. Rõ ràng, nếu bạn chỉ là một lập trình viên lùn ở dưới cùng của cột totem, bạn không thể yêu cầu chính xác mọi người bắt đầu tạo lịch trình hoặc cơ sở dữ liệu lỗi. Và trên thực tế, ngay cả khi bạn là người quản lý, có lẽ bạn đã phát hiện ra rằng việc quản lý các nhà phát triển rất giống với việc chăn dắt mèo, chỉ không vui như vậy. Chỉ nói "làm cho nó như vậy" không làm cho nó như vậy.

Nó có thể gây bực bội khi bạn làm việc trong một tổ chức có điểm thấp trong Bài kiểm tra Joel . Cho dù mã của bạn tốt đến đâu, đồng nghiệp của bạn viết mã xấu đến mức bạn lúng túng để được liên kết với dự án. Hoặc ban quản lý đang đưa ra quyết định tồi về việc viết mã nào, vì vậy bạn buộc phải lãng phí tài năng của mình để gỡ lỗi phiên bản AS / 400 của trò chơi lập kế hoạch nghỉ hưu cho trẻ em.

... đối phó với cuộc sống của một đội xấu có thể gây phẫn nộ. Nhưng có những chiến lược để cải thiện đội ngũ của bạn từ dưới lên và tôi muốn chia sẻ một vài trong số đó ...

Làm việc với quản lý; đừng "lừa đảo". Làm việc theo quy trình và đưa mọi thứ vào điều khoản mọi người sẽ hiểu, như "triển khai svn sẽ chiếm không gian của chúng tôi trên máy chủ, hai ngày để thiết lập và chúng tôi sẽ cần sao lưu, nhưng chúng tôi sẽ đạt được x, y, z , có thể giúp chúng ta tiết kiệm rất nhiều tiền. "

Thoát Có rất nhiều công việc ngoài kia. Đây không phải là công việc của bạn để sửa chữa một số công ty ngẫu nhiên tình cờ thuê bạn. Họ thích cách của họ, nếu không họ sẽ thuê một CTO mới hoặc một cái gì đó.