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 dinh, và dùng các phương tiện một cách hợp
Paul McGough, CTO của Qwyit giảng giải về những xung đột nảy 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ự kết hợp thực sự đò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 chuyện trò của team hoặc những người dự 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à sắp đặt liên tục”.
2. Tập trung 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 rời 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 hết 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ủ tịch của ClearArmor Corporation, từ góc độ quản lý rủi ro, các lập trình viên cần đảm bảo an ninh cho phần mềm mà họ tạo ra phê duyệt việc 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ó nghĩa vụ 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ì chưng 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 đề nhất mực”, 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ự thống nhất thông báo từ tất thảy 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 hoang thời kì
Lee cho biết: “Tôi đã dành cả trái tim vào các vận dụng qua 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 yếu 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ê duyệt quá trình viết code, giống như không 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ự giao hội vào những gì bạn sẽ đạt được . “
6. Không tin tức 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ọ đổ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 hiểm chỉ đơn giản giả định rằng một người nào đó đã xác định và soát kỹ lưỡng tất thảy 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 kiến 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 hiện đổi thay 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 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 để thực hành dự án là phải có nhiều nhân viên biết về nó, CTO và đồng sáng lập của Pepperdata cho biết.
“Các kỹ sư thẳng băng 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à chừ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 bít tất 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 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 thẳng tuột quan sát code,” Kodumal nói. “Một vài năm trước đó có nhẽ là tuyên bố vỡ hoang đơn giản, nhưng hiện giờ nó hỗ trợ các cô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 cố định
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 báo nhất có thể và vài lý do vì sao công việc của họ được ưu tiên”
No comments:
Post a Comment