I enjoy coding. Learning new knowledge and completing a project successfully excite me the most. However, life is not always full of joy. Problems and bugs will never be absent in every development process. Especially when working in a team, you might have chances to meet some peculiar problems that are caused by an unexpected thing. If bugs and problems are inevitable, why not treat them as a learning process? I am going to share a new problem I met recently.
A New Problem Occurs During Environment Setup
This quarter, I started work on my Capstone team project. Our team decided to use a popular technical stack (MERN) to create a Job Tracker web app. Early this week, I took charge of the environment setup. I checked several online tutorials, built and test locally, push them into Github Repository and then send the setup instruction to our group chat. Later on, one of my teammates reached out to me and said the Frontend did not work properly on her end unless she made a change on a line in the client-side package.json.
I tried to reproduce this problem on my side, however the code I wrote worked properly on my end. Then I changed this line to her code, and the weird thing happened. The code that worked on her side did not work on my end. Curiosity caused me to google this problem. Finally, I found the problems were caused by the different operating systems. The syntax I used only works on Linux and macOS. The syntax which worked on her side is for windows.
A Bit of Thought
It is a new and interesting problem for me since most of the projects I did before are individual projects. When I did research about the MERN stack setup, I only paid attention to the mac version info. I didn’t expect this problem to be caused by different syntaxes on the different operating systems.
I guess I should consider more when working in a team. Instead of starting working on a task immediately, I should take some time to think about what kind of factors might cause issues so that I could be careful when working on the task.