Những lời khuyên sau đến từ các CTO sẽ giúp các lập trình viên có được quan điểm rộng hơn về kinh doanh, và sử dụng các dụng cụ một cách thích hợp
Paul McGough, CTO của Qwyit giải thích về những xung đột phát sinh giữa CTO và các thành viên team.
McGraw nói: “trách nhiệm quản lý tiến độ công việc là của người leader. Nhưng sự phối hợp đích thực đòi hỏi nổ lực của mỗi thành viên trong team”
1. Hãy quan sát bức tranh toàn cảnh
Ben Johnson, CTO của Obsidian Security, các lập trình viên thỉnh thoảng gặp khó khăn khi quan sát thấy bức tranh toàn cảnh.
Johnson cho biết: “Khi bạn gặp phải vấn đề, rất khó để có cái nhìn toàn cảnh toàn cảnh. Mặt khác, các CTO thường không biết những gì đang được đề cập trong cuộc chuyện trò của team hoặc những người tham gia cảm thấy thế nào nếu họ không giao thông. Đòi hỏi phải đồ mưu hoạch và điều chỉnh để tối ưu hóa và xếp đặt liên tục”.
2. tập hợp vào nhiệm vụ chính
Khi các giải pháp dành cho lập trình viên nhiều hơn và dễ dàng hơn, họ dễ bi cách biệt nhiệm vụ chính McGough nói.
Các lập trình viên muốn thêm các nút bấm, nhưng đầu tiên họ phải tự hỏi mình làm thế nào để phục vụ cho đích kinh dinh. C ác lập trình viên thường làm theo ý họ muốn: Nói chung, điều này làm họ xa khỏi mục tiêu ban đầu. “
Hãy hỏi “vì sao” trước khi thêm một tính năng mới làm cho quá trình này rõ ràng hơn và giúp team hoạt động tốt hơn, tạo ra một kết quả tốt hơn, McGough nói.
3. Nhớ bảo mật
Theo James Goepel, CTO, phó chủ toạ của ClearArmor Corporation, từ giác độ quản lý rủi ro, các lập trình viên cần bảo đảm an ninh cho phần mềm mà họ tạo ra phê chuẩn việc sử dụng các kĩ thuật mã hóa tốt.
Goepel nói: “Giống như những ngôn ngữ mới, hoặc các cách tiếp cận triết học mới để code Nó có thể có ảnh hưởng lớn đến công ty, và các lập trình viên có trách nhiệm trực tiếp bảo đảm nó được giải quyết một cách đầy đủ và hợp lý.”
4. Không có một giải pháp độc nhất vô nhị
Hector Aguilar, CTO và phó chủ toạ của Okta nói: “Các lập trình viên nên lên tiếng và thách thức các giả thuyết, do có thể có hàng chục cách khác để phát triển sản phẩm hoặc khắc phục sự cố.
“Mọi lập trình viên nên biết rằng không chỉ có một giải pháp độc nhất vô nhị nào cho bất kỳ vấn đề nhất quyết”, Aguilar nói. “Khắc phục sự cố là một nghệ thuật, không phải là khoa học, và phải có sự hợp nhất thông tin từ quờ các thành viên trong team – cấp dưới và cấp cao – để giải quyết những thách thức và vượt quá đích.”
5. Tránh hoang toàng thời kì
Lee cho biết: “Tôi đã dành cả trái tim vào các vận dụng trải qua sự quá trình đảm bảo chất lượng chi tiết, chỉ để không có bất cứ sự đổi thay chiến lược vào phút chót. “Nhưng điều quan trọng cần nhớ là sản phẩm không quan yếu đối với sự nghiệp của bạn như là kiến thức và kinh nghiệm mà bạn thu thập phê chuẩn quá trình viết code, giống như chơi nhạc cụ, là một thứ mà bạn cảm thấy tốt hơn. Đừng để một chương trình làm mất sự tụ họp vào những gì bạn sẽ đạt được . “
6. Không tin cẩn các giải pháp “kỳ diệu”
Các lập trình viên trẻ có thể tìm thấy các thư viện mã nguồn mở và nghĩ rằng chúng sẽ tự động làm cho những vấn đề phức tạp trở thành đơn giản, Lee nói. Tuy nhiên, họ cần phải nhìn lại mã nguồn và xem nó được duy như thế nào, và điều gì sẽ xảy ra nếu họ đổi thay nó.
Ông Lee nói: “Dùng của bên thứ ba thường đi kèm với hiểu biết về gia công phần mềm, và đó là một hành động nguy hiểm chỉ đơn giản giả thiết rằng một người nào đó đã xác định và thẩm tra kỹ lưỡng vơ các trường hợp rìa có thể xuất hiện trong vận dụng của bạn. “Hãy nhìn sâu vào bên dưới, cảm nhận về chất lượng code, bổ sung những khoảng trống trong tri thức và chuẩn bị để làm quen với việc debug và đổi thay khi có thời kì.”
7. Làm thế nào để thực hành thay đổi trên stack
Sean Suchter nói: “Thường thì các kỹ sư biết làm thế nào để thay đổi các component mà chúng được sử dụng, và khi có các tính năng đòi hỏi phải thay đổi trên nhiều phần của stack, cách độc nhất vô nhị để thực hiện dự án là phải có nhiều viên chức biết về nó, CTO và đồng sáng lập của Pepperdata cho biết.
“Các kỹ sư ngay liên kết nhiều phần của stack trông giống như” 10 kỹ sư “, Suchter nói. “Nếu có thể cho phép nhiều kỹ sư làm việc, rất nhiều tính năng mà dường như khó làm được dễ dàng hơn.”
8. Đừng quá tin cậy vào framework
“Framework có thể giúp bạn tiện tặn thời gian, nhưng đặc biệt nếu bạn là người mới, chúng có thể dễ dàng làm cho bạn trở thành tù nhân với những hạn chế được thừa kế, các vấn đề về hiệu suất, các lỗ hổng bảo mật, “Lee nói. “Trước khi đi cả thảy trong một framework, hãy đảm bảo rằng bạn hiểu xác thực những gì bạn đang kinh dinh”
9. Tính năng hoàn chỉnh chưa phải là chấm dứt
John Kodumal, CTO và đồng sáng lập LaunchDarkly cho biết “Tính năng hoàn thiện” chỉ khoảng 10% đoạn đường.
“Là một nhà phát triển, bạn cũng cần phải nghĩ suy về những gì đang xảy ra trong thời gian, và bạn nên bộc trực quan sát code,” Kodumal nói. “Một vài năm trước đó có lẽ là tuyên bố khẩn hoang đơn giản, nhưng hiện nay nó tương trợ các dụng cụ quan sát được và giám sát, tính năng gắn cờ, và nhiều hơn nữa.” .
10. Có thể có lý do bạn không có quyền truy cập vào một số thông báo nhất mực
Mike Duensing, CTO và phó chủ toạ của Skuid cho biết: “Các CTO là một phần của nhiều kênh thông báo của một công ty, tình huống của nhà đầu tư, các kế hoạch chiến lược, các sự kiện sắp xảy ra.
“Một số vấn đề có thể sắp xảy ra, và một số chưa. Bạn ước bạn có thể đưa mọi người vào những gì đang diễn ra, nhưng nó không thể”, Duensing nói. Cách tiếp cận tốt để giải quyết vấn đề này là hãy có tương tác tốt và cung cấp cho bạn các kỹ sư nhiều thông tin nhất có thể và vài lý do tại sao công việc của họ được ưu tiên”
0 nhận xét:
Đăng nhận xét