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 ý kiến rộng hơn về kinh dinh, và dùng các phương tiện một cách hiệp
Paul McGough, CTO của Qwyit giải thích về những xung đột nảy 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ự kết 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 đôi khi 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 trò chuyện 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ụ tậ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 xa vắng 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 trước nhất họ phải tự hỏi mình làm thế nào để phục vụ cho mục tiêu 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 đích ban sơ. “
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 duyệt y 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 duy nhất
Hector Aguilar, CTO và phó chủ tịch 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, vì 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 duy nhất nào cho bất kỳ vấn đề khăng khăng”, 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 báo từ ắt 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á mục tiêu.”
5. Tránh vung phí thời kì
Lee cho biết: “Tôi đã dành cả trái tim vào các vận dụng sang trọng sự quá trình bảo đảm chất lượng chi tiết, chỉ để không có bất cứ sự thay đổi 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à tri thức và kinh nghiệm mà bạn thu thập duyệt 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ập hợp vào những gì bạn sẽ đạt được . “
6. Không tin tưởng 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ở nên đơ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ọ thay đổi 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 hiểm nguy chỉ đơn giản giả định rằng một người nào đó đã xác định và kiểm tra kỹ lưỡng hết thảy các trường hợp rìa có thể xuất hiện trong áp 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 để đổi thay các component mà chúng được 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ư luôn kết liên 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à tuồng như khó làm được dễ dàng hơn.”
8. Đừng quá tin tưởng vào framework
“Framework có thể giúp bạn tiết kiệm 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ở nên phạm 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 tất tật trong một framework, hãy bảo đảm rằng bạn hiểu xác thực những gì bạn đang kinh doanh”
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 kì, và bạn nên liền quan sát code,” Kodumal nói. “Một vài năm trước đó có lẽ là tuyên bố khai khẩn đơn giản, nhưng bây chừ 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 tin nhất thiết
Mike Duensing, CTO và phó chủ tịch 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 vì sao công việc của họ được ưu tiên”
0 nhận xét:
Đăng nhận xét