Là một sinh viên mới tốt nghiệp bắt đầu một nghề nghiệp mới trong công nghiệp, bạn có thể thấy công việc vừa kích động và thất vọng. Là một nhân viên mới, bạn muốn biết người khác nghĩ gì về bạn và làm sao bạn có thể là một phần của tổ của họ? Bạn có lẽ thấy rằng có nhiều điều bạn không biết và điều bạn đã học trong trường và điều xảy ra trong công ti khác biệt thế. Bạn muốn cảm thấy được đón chào nhưng không biết phải làm gì nên bạn cảm thấy lúng túng. Về căn bản, bạn không một mình bởi vì mọi người cũng cảm thấy theo cách đó khi họ là người mới với công việc.

Để tôi bắt đầu bằng kinh nghiệm riêng của mình quãng 40 năm trước đây. Trong việc làm đầu tiên của mình, tôi và vài người phát triển mới được trao nhiều tài liệu để đọc bởi vì mọi người trong công ti đều bận rộn và không có thời gian dành cho chúng tôi. Tôi phải uống nhiều cà phê để giữ cho mình tỉnh thức và tôi sợ vì tôi không hiểu gì về những tài liệu đó. Sau vài tuần dài uống nhiều cà phê, cuối cùng chúng tôi được phân công sửa một số mã trong một ứng dụng bảo trì. Chúng tôi coi lại hàng nghìn dòng mã mà ai đó đã viết để hiểu dự án này nhưng chúng tôi không biết phải làm gì vì phần lớn mã không có chú thích và không có tài liệu.

Vào thời đó, ngôn ngữ lập trình là hợp ngữ, không phải là các ngôn ngữ bậc cao hơn như C++ hay Java ngày nay. Vài người mới không sửa được mã, và được bảo đi đọc lại thêm tài liệu. Tôi đã sửa được mã khi được bảo và sống sót qua nhiệm vụ đầu tiên đó. Sau sáu tháng, tôi có khả năng hiểu cách chương trình đó làm việc. Đáng sẽ cần thêm ba tháng nữa trước khi tôi hiểu chương trình này đầy đủ và bắt đầu đánh giá được nhiệm vụ được phân cho trong việc làm đầu tiên của mình. Lời khuyên của tôi với những người phát triển mới là bạn không nên cảm thấy thất vọng bởi vì mọi người có lẽ cũng cảm thấy theo cùng cách vì phải tốn thời gian để học mọi thứ với việc làm mới.

Kinh nghiệm của việc làm đầu tiên của tôi còn lại với tôi trong một thời gian dài. Ngày nay, là người quản lí cấp cao, tôi yêu cầu những người quản lí dự án phải dành thời gian cho các nhân viên mới, giúp họ và làm cho họ cảm thấy được đón chào trong vài tuần đầu tiên. Qui tắc đầu tiên của tôi là “Không xem tài liệu” ít nhất trong vài tháng đầu để cho không ai phải uống nhiều cà phê như tôi đã uống nhiều năm trước. Qui tắc thứ hai là người quản lí dự án và thành viên tổ phải ăn trưa cùng nhân viên mới trong vài tuần đầu để làm cho họ cảm thấy được đón chào, và dần biết họ. Tuy nhiên, tôi hiểu những người phát triển có kinh nghiệm nhìn người mới thế nào khi họ bắt đầu làm việc cùng nhau và đôi khi điều đó có thể làm thất vọng cho cả hai phía. Mọi người khác nhau thấy các vấn đề theo những cách khác nhau và có ý tưởng khác nhau về cách chúng có thể được giải quyết. Thật khó cho người phát triển có kinh nghiệm KHÔNG giận khi một thiết kế tốt được thực hiện theo cách thiếu kinh nghiệm và vụng về. Tất nhiên, người có kinh nghiệm có những cách nào đó để làm mọi sự và họ bao giờ cũng thích hay không thích những cách tiếp cận nào đó.

Tôi đã có nhiều thảo luận với những người phát triển có kinh nghiệm trên chủ đề này. Qua nhiều năm, tôi đã thu thập một số lời ghi chép mà tôi chia sẻ cùng các sinh viên ở Carnegie Mellon. Sau đây là cách nhìn của người phát triển có kinh nghiệm về nhân viên mới mà bạn có thể thấy có ích:

1) “Người mới không hỏi câu hỏi, họ dường như hiểu mọi thứ nhưng khi thực hiện, họ làm sai cả.” Tôi thấy rằng khác biệt chính thường là giữa “Lí thuyết và thực hành” hay “ý kiến cá nhân” về những cách tiếp cận nào đó. Người phát triển có kinh nghiệm biết đích xác cái gì cần làm và cách tiếp cận nào nên được dùng cho dự án này bởi vì họ quen thuộc với các qui trình của công ti. Những người mới KHÔNG như vậy, họ thử tạo ra giải pháp riêng của mình và thấy rằng nó đưa tới bất đồng nào đó. Cho dù không có “cách đúng” trong việc giải quyết vấn đề, cách tiếp cận tốt hơn là “Nếu bạn không biết, hỏi câu hỏi về cách tiếp cận nào nên được dùng. Hỏi người có kinh nghiệm để xem lại cách tiếp cận của bạn trước khi thực hiện nó.”

2) “Người mới không biết cách kiểm soát mã của họ. Họ không có khái niệm về quản lí cấu hình hay kiểm soát phiên bản. Họ làm lộn xộn mọi thứ.” Tôi thấy rằng nhiều người phát triển đã không thực sự hiểu rõ quản lí cấu hình, hoặc trường của họ không dạy điều đó hoặc họ không hiểu nó rõ. Đây là vấn đề về tri thức có thể được giải quyết với đào tạo thêm. Khái niệm về môi trường phát triển, môi trường kiểm thử, môi trường sản xuất hay đưa ra, kiểm soát sửa đổi, và số hiệu phiên bản nên được nhấn mạnh và cũng không mất lâu thời gian cho người phát triển mới hiểu khái niệm này.

3) “Người mới không thấy toàn thể bức tranh. Họ chỉ hội tụ vào một phần nhỏ chi tiết và bỏ lỡ mục đích chính.” Phải mất chút thời gian để học về cách toàn bộ hệ thống làm việc và hiểu cách tất cả các phần khớp với nhau. Trong khi điều tốt là bắt đầu với một phần nhỏ, tôi thường thấy rằng những người phát triển mới hội tụ quá nhiều vào chi tiết và chưa bao giờ thấy phần của họ làm gì cho toàn thể hệ thống. Hiểu cách toàn thể hệ thống làm việc là chủ đề về kiến trúc hệ thống, nhưng nhiều trường không dạy kiến trúc trong chương trình khoa học máy tính của họ. Tôi khuyến cáo rằng người quản lí dự án hay người phát triển có kinh nghiệm giải thích về kiến trúc hệ thống cho người phát triển mới sau khi họ đã làm việc được vài tháng với dự án. Người mới phải cảm thấy thoải mái với dự án và các chức năng của nó trước khi họ có thể đánh giá được thiết kế và kiến trúc hệ thống. Người mới cần hiểu rằng cho dù phân công việc của họ là một phần nhỏ nào đó nhưng các phần này khớp vào trong “hệ thống lớn”. Điều quan trọng là cần đọc tài liệu nào đó về dự án rồi hỏi các câu hỏi về cách mọi sự làm việc cùng nhau. Lời khuyên của tôi là “Nếu bạn không hiểu, hỏi các câu hỏi đi.” Không ai cười bạn khi bạn là mới và họ mong đợi rằng bạn sẽ hỏi các câu hỏi. Tuy nhiên, họ sẽ cảm thấy không thoải mái nếu bạn KHÔNG hỏi câu hỏi. “Không có câu hỏi tồi mà chỉ có im lặng tồi.”

4) “Một số người nghĩ họ khôn. Họ muốn thay đổi mọi thứ. Họ làm mọi thứ lộn xộn lên.” Tôi thấy rằng một số  người phát triển mới muốn gây ấn tượng với người quản lí bằng cách gợi ý những điều mà họ có thể không hiểu hết. Một số đã tự làm mình bối rối khi họ cố thiết kế lại toàn thể hệ thống trong vài tháng đầu của họ. Vì họ muốn chứng tỏ rằng họ biết cái gì đó, họ thường cáu bẳn với nhiều người phát triển có kinh nghiệm. Lời khuyên của tôi là “Là người mới, bạn cần thời gian để học về hệ thống, cách thiết kế được thực hiện; lí do cho việc làm điều này theo cách đó, cũng như các cá tính của người phát triển khác. Bạn là một phần của tổ cho nên đừng cố đứng ra như người anh hùng bởi vì bạn biết cái gì đó. Điều tốt là bạn có thể có ý tưởng nào đó nhưng bạn còn cần biết lưu ý, đừng xúc phạm người nào, bạn có thể gợi ý cái gì đó cho tổ và hỏi ý kiến của họ. Cách tiếp cận tốt hơn là gặp những người có kinh nghiệm và yêu cầu họ thảo luận với bạn về cách tiếp cận của họ như một phần của việc học của bạn. Sau đó, bạn có thể chia sẻ điều bạn nghĩ với họ và yêu cầu phản hồi từ họ, bạn sẽ học nhiều hơn về họ vì họ cũng học cái gì đó từ bạn.

5) “Người mới không hiểu gì về qui trình phần mềm. Họ chỉ viết mã và phạm sai lầm.” Tôi thấy rằng khái niệm về qui trình phần mềm KHÔNG được dạy trong chương trình khoa học máy tính hay trong đào tạo ngôn ngữ lập trình. Mọi công ti thường có qui trình riêng của họ hay cách họ phát triển phần mềm. Một số qui trình là “chính thức” và một số thì không, và mọi người cần thời gian để học về nó. Chẳng hạn, kiểm điểm thiết kế và giám định mã là các qui trình rất nghiêm túc trong một số công ti nhưng các công ti khác có thể không để mấy chú ý vào nó. Phải mất thời gian để làm quen với qui trình công ti là gì và biết cách đi theo nó. Đây là điều khó bởi vì điều bạn đã học trong trường có thể không phải là điều công ti đang làm (Lại khác biệt giữa lí thuyết và thực hành). Lời khuyên của tôi là trước khi bạn làm cái gì đó, hỏi các câu hỏi và nếu cần, yêu cầu kiểm điểm qui trình trước khi thực hiện.

6) “Người mới chỉ viết mã. Họ không biết về thư viện tái dụng phần mềm và không làm mã tái dụng được.” Đây là điều chung mà hầu hết những người mới đều hăm hở viết mã mà không hiểu rằng một số chức năng hay đối tượng họ làm đã có rồi trong thư viện tái dụng. Tái dụng phần mềm thường KHÔNG được dạy trong nhiều chương trình khoa học máy tính. Nhiều người mới chỉ thích viết mã bởi vì đó là điều họ biết rõ. Tuy nhiên, nếu bạn viết mã theo cách riêng lẻ của mình thì đó KHÔNG phải là thiết kế cho tái dụng và KHÔNG thể được đặt vào trong thư viện tái dụng thì có thể bạn đang làm điều gì đó không hiệu quả. Bạn sẽ thấy rằng nhiều trong những chức năng hay đối tượng đó sẽ được cần tới lần nữa. Bạn cần nghĩ về tính năng suất và tính bảo trì được, vì chìa khoá của phát triển phần mềm thành công KHÔNG phải về viết mã mà là lắp ráp các mã đã có vào trong hệ thống mới. Mã tái dụng và kiến túc hệ thống là các khái niệm quan trọng của cách mọi người dựng phần mềm ngày nay.

Có thời gian để học và có thời gian để thực hiện. Là người phát triển mới, việc của bạn là học cách những người có kinh nghiệm khác thực hiện phần mềm trong công ti. Nếu bạn không hiểu, đừng ngần ngại hỏi các câu hỏi. Bạn sẽ có cơ hội để thực hiện và quan sát người khác học khi người mới được thuê vào trong công ti.

English version

Advices to new software developers

As software developers, many of you probably remember the first week in your first job. As a graduated student starting a new career in the industry, you can find the work both exciting and frustrating. As a new employee, you want to know what others think of you and how can you be part of their team? You probably find that there are many things that you do not know and what you have learned in school and what happen in the company is so different. You want to feel welcomed but do not know what to do then you feel lost. Basically, you are not alone because everybody also feels that way when they are new to the job.

Let’s me start with my own experiences about 40 years ago. In my first job, I and several new developers were given a lot of documents to read because everyone in the company was busy and could not have time for us. I had to drink a lot of coffee to keep me awake and I was afraid because I did not understand anything in those documents. After several long weeks drinking a lot of coffee, finally we were assigned to modify some code in a maintenance application. We reviewed thousand lines of code that someone wrote to understand the project but we did not know what to do because most of the code had no comments and no documentation. At that time, the programming language was Assembly, not higher level languages such as C++ or Java of today. Several new people failed to modify the code, and were sent to review more documents again. I modified the code as I was told and survived that first task. After about six months, I was able to understand how that program work. It would be another three more months before I understood the program in full and began to appreciate the assignments given in my first job. My advice to new developers is you should not feel frustrated because everybody would probably feel the same way as it takes time to learn things on new job.

The experience of my first job stays with me for a long time. Today, as a senior manager, I require projects managers to spend time with new employees, help them and make them feel welcomed in the first few weeks. My first rule is “No document review” at least for a few months so no one has to drink a lot of coffee as I did many years ago. The second rule is project managers and team members must have lunches with new employees on the first few weeks to make them feel welcomed, and getting to know them. However, I understand how experienced developers view new people as they begin to work together and sometime it can be frustrating for both sides. Different people see problems in a different way and have different idea of how they could be solved. It is difficult for experienced developers NOT to be angry when good design is implemented in a clumsy or inexperienced way. Of course, experienced people have certain ways of doing thing and they always like or dislike certain approaches.

I had many discussions with experienced developers on this subject. Over the years, I collected some notes that I shared with students at Carnegie Mellon. Following are views of experienced developers on new employees that you may find helpful:

1) “New people do not ask question, they seem to understand everything but when implement, they did it all wrong”. I found that the main difference is often between “Theories and practice” or “Personal opinion” on certain approaches. Experienced developers know exactly what to do and what approach should be used for the project because they are familiar with the company processes. New people do NOT so they try to create their own solutions and find that it leads to some disagreements. Even there is no “right way” in solving problem, the better approach is “If you do not know, ask question on which approach should be used. Ask experienced people to review your approach before implement it”.

2) “New people do not know how to control their codes. They have no concept of configuration management or revision control. They mixed up everything”. I found that many developers did not really understand configuration management well, either their schools did not teach it or they did not understand it well. This is an issue of knowledge that can be solved with additional training. The concept of development environment, testing environment, production, or release environment, revision control, and version numbers should be emphasized and it does not take long for new developers to understand the concept.

3) “New people do not see the whole picture. They just focus on a small part in details and missing the main goal”. It takes a while to learn how the whole system works and understand how all the parts fit together. While it is good to start with a small part, I often found that new developers focus too much on the detail and never see what their part is doing for the whole system. To understand how the whole system works is the subject of system architecture, but many schools do not teach architecture in their computer science program. I recommend that project manager or experienced developers explain the system architecture to new developers after they have worked a few months on the project. New people must feel comfortable with the project and its functionalities before they can appreciate the design and system architect. New people need to understand that even their assignments are some small parts but these parts should fit into “the big system”. It is important to do some reading about the project then ask questions on how everything works together. My advice is “If you do not understand, ask questions”. No one will laugh at you as you are new and they expect that you will ask questions. However, they will feel uncomfortable if you do NOT ask question. “There is no bad question but only bad silence”.

4) “Some new people think they are smart. They want to change everything. They mess things up”. I found that some new developers want to impress managers by suggesting things that they may not fully understand. Some did embarrass themselves as they try to re-design the whole system in their first few months. As they want to demonstrate that they know something, they often irritate many experienced developers. My advice is “As new people, you need time to learn about the system, how the design is implemented; the reasons for doing that way, as well as the personalities of other developers. You are a part of a team so do not try to stand out as a hero because you know something. It is good that you may have some ideas but as long as you are careful, not to offend anyone, you may suggest something to the team and ask for their opinions. A better approach is to meet experienced developers and ask them to discuss with you about their approaches as part of your learning. After that, you may share what you are thinking with them and ask for their feedbacks, you will learn much more about them as they also learn something about you.

5) “New people do not understand anything about software process. They only code and make mistakes”. I found that the concept of software process is NOT taught in computer science program or in programming language training. Every company often has their own processes or the way they develop software. Some are “formal” and some are not, and people need time to learn about it. For example, design review and code inspection are very serious processes in some companies but other may not put a lot of attention to it. It takes time to get familiar with what the company process is and know how to follow it. This is a difficult thing because what you learned in school may not be what the company is doing (Again the difference between theories and practice). My advice is before you do something, ask question and if needed, ask for a process review before implementation.

6) “New people just code. They do not know about software reuse library and do not make reusable code”. This is a common thing as most new people are eager to code without understand that some functions or objects that they did already exists in the reusable library. Software reuse is often NOT taught in many computer science programs. Many new people just like to code because that is what they know well. However, if you code in your own stand-alone way that is NOT design for reuse and can NOT be placed in a reuse library then maybe you are doing something ineffectively. You will find that many of those functions or objects will be needed again. You need to think about productivity and maintainability, as the key of successful software development is NOT about coding but assembling existing codes into new systems. Reusable code and system architect are important concepts of the way people build software today.

There is time to learn and there is time to implement. As new developers, your job is to learn how other experienced people implement software in the company. If you do not understand, do not hesitate to ask questions. You will have the chance to implement and watch other learn as new people are hired into the company.