10 lời khuyên các CTO gửi đến lập trình viên

2366

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 công cụ một cách phù 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 thực sự đòi hỏi nổ lực của mỗi thành viên trong team” 

Có thể bạn quan tâm:

  Bookmark ngay 37 website dạy bạn mọi thứ trên đời
  10 thói quen của một lập trình viên thành công

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 liên lạc. Đòi hỏi phải lập kế hoạch và điều chỉnh để tối ưu hóa và sắp xếp 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 mục tiêu kinh doanh. 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 “tại 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 thông qua 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 đảm bảo 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, bởi 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 đề nhất định”, 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 tin từ tất cả 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 lãng phí thời gian

Lee cho biết: “Tôi đã dành cả trái tim vào các ứng 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ự 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 trọng đố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 thông qua 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 trung 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 nguy hiểm chỉ đơn giản giả định rằng một người nào đó đã xác định và kiểm tra kỹ lưỡng tất cả các trường hợp rìa có thể xuất hiện trong ứng 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à thay đổi khi có thời gian.”

7. Làm thế nào để thực hiện 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 duy nhất để thực hiện 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 xuyên 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 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ở 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 tất cả trong một framework, hãy đảm bảo rằng bạn hiểu chính xác những gì bạn đang kinh doanh”

9. Tính năng hoàn chỉnh chưa phải là kết thúc

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 suy nghĩ về những gì đang xảy ra trong thời gian, và bạn nên thường xuyên quan sát code,” Kodumal nói. “Một vài năm trước đó có lẽ là tuyên bố khai thác đơn giản, nhưng bây 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 tin nhất đị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 tin 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”

Techtalk via techrepublic

 

Life of a software engineer (Credit: Troduction)
CHIA SẺ