Learn how not to


On my first post I mentioned that I had no previous computer science experience to joining this program. The Capstone project is my first real experience in a development group and honestly, it was not a pleasant experience, but one in which I experienced a lot of learning on a lot of levels. This post will not exactly be entertaining or fun, nor particularly insightful to any specific programming technique, instead I will be the journey of someone experiencing what I expect is somewhat common in the development sphere.

I will start with what I dont think is normal and that is that we are all unexperienced and had no leadership we could lean on for help. There were also language barriers that complicated communication through out this process. You add to these issues, we picked up a project that was well underway with very limited access to the previous dev team. This meant combing through hundreds of files to understand what they had done, most of which were in a programming language I was not experienced with. I dont think any of these issues, nor the ones to follow would have been much of a problem if we had someone with experience to talk to or if we had the previous dev team to catch us up to speed. Which these might be real life experiences, they would not or at least should not be for a group of devs with no prior experience. That out of the way, lets answer some specific leading points.

One of the major things I would have changed if I could start this project over is to be more assertive. I am the only one on the project whose first language is English and they were all uncomfortable being the lead when dealing with the sponsor. On top of that they wanted me to take the project lead position. Which lead to two small issues for myself that ended up getting out of hand. The first being that since I had no experience I did not feel confident to lead and wanted input from the team before making decisions, but that lead to things taking much longer as they were slow to communicate, not fully understanding what the project needed/the scope of the project, on top of none them being proactive in wanting to solve any of those problems. The second thing being that I tried to give the front end to half the team and tried to be hands off (since I am very inexperienced in javascript and had enough to deal with on the server and database side). What this lead to is weeks going by without anything being done since they didnt have enough direction. If I could do it over I would probably micro-manage more and I probably would have gotten the professor involved earlier and been more assertive about finding solutions.

I would say though that this spurred on the most growth though as I was having to dig into all the code on both sides to get a firm grasp of the project, its needs and time frames. Also got better at researching answers for solutions or ideas of how to solve roadblocks. Also have a much better understanding of time frames needed to finish what seems like small tasks but end up needing a lot more research/debug time than I allotted. I would say I have much more sympathy for dev teams that are nearing the end of the project cycle and trying to polish things without breaking everything. I also have greater sympathy for the normally seen patch work that is most projects code. Once projects get to a certain size decisions have to be made about whether or not the time to fully refactor the code to ‘hopefully’ future proof the code is worth the investment, or if its more worth the time to make a work around to get all current needs met. Its an ugly battle and one that many people lose without even knowing it. Time and money constraints are one of the biggest roadblocks for dev teams.

I also want to state that I feel much more confident going into the work force due to this experience. Even if it was an unpleasant experience, I feel like it is a reflection of some of the specific issues that exist in the tech world and if I tackled it here, then it prepares me for the real issue where most of the issues will be mitigated by being apart of more experienced team.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *