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.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
