Author Archives: kumarcomputerscience

B5: Expose Your Ignorance

          The “Expose Your Ignorance” pattern is described as a way to come to terms with the fact that you won’t know everything in your field. Everything starts as a learning process when you enter a new team. It becomes easier as time goes on and creates a better environment when your team sees you making sufficient progress and growth. The pattern explains that creating a strong relationship with clients and colleagues causes them to grow more interested in your growth as a developer because of the increased efficiency you gain which in turn helps push development even further. Telling people the truth that you’re in the process of learning new skills may make them see you as an amateur but it is certainly better than giving them false promises of creating a finished product on time when you can’t quite deliver on it. This also brings up the point of asking questions, since questions can also show your ignorance but that shouldn’t matter as much since it all is a learning experience. You must ask questions if you plan on putting your pride aside and showing your team that you truly want to learn without taking any shortcuts.

          I found the importance of being honest with your team very useful to expose your skill set to them. The idea of letting your team exactly what you can and can’t do will help them better gauge what tasks they should start you off with to make the learning process easier. I enjoyed the fact that the book doesn’t tell you to shy away from asking questions. Questions can make you seem much more ignorant but the reason why you ask questions is to learn in the first place. This pattern expresses the importance of learning through honesty with your teammates which I will incorporate into my own experiences. The honesty aspect also will help with trust within the team as it shows that I’m not willing to hide anything from them. I overall enjoyed this pattern and agree with it completely. It repeated some very important aspects of teamwork and honesty that I will make sure to never forget.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 1

          We learned quite a bit in our first sprint for the AMPATH project which ranged from troubleshooting compiling errors to understanding team dynamics. After some reflection, I found that the mutual troubleshooting that our team did allowed us to bypass any icebreakers that were needed. We were able to professionally and respectfully look into each other’s problems while making sure that no one was left in the dark. After learning about our team dynamic, I will proceed to do more involved communication through slack rather than other private forms of communication. We had begun to use texting a form of communication but quickly changed to slack to ensure that everything was able to be pulled up easier in the future for documentation and blogs. We learned to better troubleshoot using sites such as stackoverflow and GitHub to find information on node as well as npm versions. The start of our first sprint consisted of working on the front end of the project to make sure it was able to run and look into the server side as well to gain more information on how it worked. We had many problems when trying to make the ng2-amrs repository to work when we cloned them on to our own computers. We consulted each other and the various other teams to understand the common problems everyone was having and fix them together. After cloning the proper files onto our computers, we immediate ran into problems when trying to run the project. We were met with various errors that we were able to fix by updating our versions of npm and nodeJS. The npm version was easy to update through commands in the terminal but various team members were having issues with updating node through the terminal, so a manual reinstallation was necessary. During the installation, we found that we must check a box that allowed node to install packages that may be needed as a project is built to ensure that the project could continue to compile. After this error, I happened to get a windows x64 compatibility error for certain files within the project, specifically a file named style.scss. Fortunately, our professor was able to locate a solution to the error and explained that we should type the command “npm rebuild node-sass” to rebuild that node so that it would work with our version of windows. After trying to build the project once more, we ran into another error when running the command “ng build –prod” which would have let us build the project and figure out any other errors we were having. The error said that the javascript process ran out of memory which seemed quite odd. Our teammate Harry was able to troubleshoot this error from stackoverflow using google and emailing people from AMPATH. We were able to change some of the memory restrictions on the javascript process and ran the command npm start which allowed us to fully compile the project and get an interface running. We currently are still facing issues because the project says that it was compiled with warnings which we have not delved into yet as we are awaiting more information from AMPATH. Our troubleshooting methods were mainly using our resources from the internet to find out why the project was running into issues until we were able to properly compile it into a workable interface.



Node JS manual update

Style.scss error

JavaScript out of memory error

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B4: Create Feedback Loops

          The “Create Feedback Loops” pattern is seen as a way to gain a better understanding of yourself without completely suffering from a blind sense of skill. The book continues on to say that self-assessment is limited to the abilities you have which makes it narrow minded if you don’t have many skills to start with. The best way to cope with this issue is to create a system where you can receive feedback or external data on your performance. It allows a more conscious take on your weak points as seen by other people which in turn will create a much more detailed self-assessment for yourself. The book then shows the importance of feedback in various environments such as job applications where applicants can be turned down, but this can become a learning experience as well. Understanding why one was turned down for a job also is a type of feedback that can show you different aspects of your character that you didn’t see. Finding a specific task to do is the hardest part because you must find something you can measure. Once this is done, compare how that task is affected by your work and understand how your actions are affecting it.

          I found the idea of creating different feedback loops with various people very useful and interesting. The idea of getting feedback from multiple people in multiple groups of your life could be very valuable information. I personally feel that there are aspects of work that meld into our personal lives and until someone else points them out, they seem second nature to us. This idea of taking others advice even when its not work related can cause interesting changes in how you tackle problems and view the situation. I found that listening to these valuable inputs is important but it’s just as important to understand which advice to follow as not all of them are good. I disagree with the idea that self-assessment is only limited to someone’s abilities. I think that even when you have little skill, you can accurately create an ideal image of what you want using facilities like the internet to expand on what you need to work on.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B3: Be The Worst

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers Blog

          I found the article, “Why Doctors Hate Their Computers”, very interesting and though-provoking for a variety of reasons. The main reason I found this article interesting was because of all the frustration these EMRs can cause doctors and pile extra work on top of them. It was interesting to see how these systems affect different parts of the medical field such as surgeons and emergency care. The complex tensions from the extra typing and learning curve really makes doctors’ lives harder rather than easier. Many of the doctors within the article stated that they would start to bring work home, something they usually never did. This was due to the extensive learning curve of the system at first but even as time went on, many doctors that mastered the system still had a large workload. Another tension is the fact that nurses and assistants cannot take some of the workload for the doctors since they aren’t authorized to use the system or have had any extensive training on it. They must sit on their thumbs while the doctors get swamped with work. This leads to a harder personal life for doctors which can lead to worse mental health as the article stated. I was very surprised to see that many doctors were going through depression because of these system implementations and continued to have issues with their work and personal life balancing. It seems that the real customer of system was the patients to help them stay informed of their health records through online electronic means. It was a way to allow remote communication between doctors and patients so that the patient could have an easier time accessing their health records and update from their doctor. The lessons from this system implementation don’t only apply to EMRs but rather to many applications that hold a complexity that only continues to grow and become more brittle. The idea of software not being flexible causes a mass disturbance for those that need to make changes on the go which is especially prevalent in medicine but can be applied to various other industries such as construction. The reading gave me better insight and allowed me to develop a better opinion on the subject matter by explaining the positive and negatives of the system. After reading about how the frustrating interface caused doctors more work and tension, I can understand that organization must be important for all users of a program. The system was designed for the patients, but it should also have been easier to use for the doctors by making their lives simpler than where it was in the article. I will keep all customers in mind when creating software so as to make sure that the scope of the programs can be understood by every user. I agreed with the reading because I personally understand how systems can be aggravating to deal with from a backdoor perspective. It makes sense how frustrating a new system can be and how much effort it takes to get acquainted with it. I thoroughly enjoyed reading this article and found it insightful to my software development practices.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B2: Concrete Skills

            The “Concrete Skills” pattern is described as a way be able solidify and maintain skills that would be helpful in a work environment. The book explains that many teams don’t really want to hire someone who won’t be able to help with the workload. There are too many situations where you would be a detriment with the lack of experience and skills. The books then goes on to talk about the possible solutions, one being to gain the ability to learn quickly. This can help show the team that you can be put to use in a working environment and not need to be supervised. It can also build a better relationship with the team by reassuring them that their efforts and time are not being wasted. Another strategy that is important is a great understanding of your first language since it can help you create a starting point within your first job. The book explains that communication and professionalism can be a strong driving force that accent your skills within your first language to better show off what you learned to employers.

            I found this pattern to be interesting in the sense that it relates to many new software developers looking for jobs. The through-provoking idea of being thrown into a software dev team that took a chance with a new developer is daunting to me. I find that if I was in that situation, I would need to work twice as hard to prove that I’m worth keeping on the team and that I have skills that can benefit everyone. This pattern shows me that concentrating on my programming skills and knowledge will be useful, but I will also need to have good communication skills as well to make sure that the team understands my viewpoints. I haven’t really thought about how important these communication skills and professional attitudes interlock with each other, but this pattern has shown me the importance of both. I agree with this pattern for the most part, however I found that it didn’t seem to give enough information about how someone could find their concrete skills in a team setting where many team members are already much better than you at your own language. Overall, I found this pattern interesting and very insightful.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B1: Learn How You Fail

          The book describes the “Learn How You Fail” pattern by talking about failure in general throughout a developer’s life. It explains that everyone fails at some point in their life and it shows the potential of growth. The blog continues to say that identifying where an individual specially fails can create better self-knowledge for their habits and behaviors. The main goal of this pattern is to then learn from these habits and behaviors to correct the ones that limit your potential. It brings to light the importance of creating an accurate self-assessment and awareness of weaknesses to find a realistic goal that can be accomplished. The book gives an example for coding where the programmer should try to use a text editor to implement a binary search in any language. Then write the tests for that search and run through it without a compiler manually to find any possible error you have made. You can compile the code after doing this to find any remaining errors that you may not have picked up.

          I found this pattern very interesting and informative in terms of self-understanding and creating reasonable goals. The way the pattern explains how habits and behaviors can become second nature which eventually leads to errors that we make unintendedly was very thought provoking. I enjoyed following the logic behind this and understanding how this can affect me in the long run as a developer if I don’t look for these errors now. This pattern has caused me to value my failures even more by teaching me more about learning from them. I always went with the logic that if I failed, I should simply not make that mistake again. However, this pattern showed me that instead of avoiding mistakes, I should naturally make them and learn from them in detail. This learning experience could provide me with deeper insight on how I will learn in the future and plan for my profession in a much easier light. I don’t disagree with the pattern at all, in fact, I thoroughly enjoyed every part of it. I especially enjoyed the example given using the text editor as a IDE to find mistakes in writing and compiling code.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Introductions Blog

          The Apprenticeship Patterns book explains how to understand the ideas of modern software development by using a simple vocabulary and a relatable lens. The first chapter goes through the importance of understanding how Software Craftsmanship is defined through the experience of real developers. The ideas of trying new things and experimenting were constantly brought up as well to enforce the mindset of individual growth. It explains that through various interviews and personal experience, they were able to understand the individual growth of various software developers and share their experiences through their years for a better understanding of the industry of today. The book delves into these ideas further by saying that the reader’s mind should be fresh and patient when learning. Many developers stick to certain practices once they learn master a specific language that they carry over which hurts their learning ability in the future. This comes into play with the self-assessment portion of the book where it explains that risks and learning curves are to be expected when tackling difficult languages but understanding personal strengths and weaknesses are key. These ideas help keep the idea of perpetual learning fresh and easier to tackle which can greatly affect how someone learns information on their own. The book continues to talk about the abundance of information through the internet and books that allow anyone access to information if they truly need it. It further pushes the idea of self-learning by talking about how many developers started by teaching themselves through constant reading and media platforms while also applying these skills into their daily software development lives.

          I found the reading to be very interesting through the use of personal experience from other developers as they went through their own hardships of learning how to compete in the industry. I specifically found the analogy of emptying the cup to be thought-provoking and useful as it seemed very relatable to me. Understanding and master a programming language feels incredible and makes the user want to apply what they learned to various other languages in hopes of learning them faster using the first language as a basis of knowledge. This can work sometimes however; many languages have their own twists which can be aggravating to learn due to the fact that it seems more complex than the first language that you originally learned. The idea of “emptying” the cup makes much more sense here to make sure that there is frustration when moving from one language to another. I found the analogy of not being able to “drink” from the cup if it’s full to be insightful because it points out the importance of letting go of some knowledge from other subjects to retain focus on the current learning objective on hand. The reading has caused me to understand how to learn from my mistakes and failures much better after reading how other developers also struggled with difficult programming terms. It’s changed my opinion of learning other skills for software development and how I would have originally tackled it which I now completely agree with. This ties into Chapter 6 which talked about constructing your own curriculum which resonated with me much more than the other chapters. As I empty my cup, I realize that my limits lie within how I intake my information and how I organize this intake to make it as easy and smooth as possible.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.


Welcome! My name is Gulshan Kumar and I am creating this blog to help document the various subjects I will encounter while participating in my Computer Science Software Development Capstone. I hope you all learn as much as I do!

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B8: Test Cases

          I found a blog post this week that talked about Test Cases and the differences between Test cases and Test Scenarios. It starts by explaining Test Scripts and how they are the most detailed way to document testing. Test Scripts are usually a line to line description of actions within the code. It holds a lot of information on the software to relay data to the tester. It goes on to talk about how Test Cases are the second most detailed way of documenting testing work. Test Cases hold less information than Test Scripts because they only describe a specific function or idea to be tested. It allows more flexibility for the tester to find different inputs to test. It allows more detailed testing for testers that are familiar to the application for the program. The blog then introduces Test Scenarios that are known as the least detailed type of documentation. Test Scenarios hold a simple description of a function or intent a user might have when using the program. Like Test Cases, this allows more flexibility for the tester but also causes more areas that are likely to not be tested due to the undetermined scope of the problem.

          I chose this article because Test Cases were the most interesting subject when learning about the process of testing. I wanted to understand the difference between cases and scenarios which is what sparked my initial curiosity. I found that this blog was really interesting because it explains how testing can be structured based on the amount of information given. I enjoyed how the post explained the levels while also explaining how they benefit the tester through the expansive flexibility while also stating that this can lead to more grey areas of testing. I was able to grasp an understanding how these testing terms differ from each other and it expanded my visibility when looking at the testing process as a whole. The most interesting part of the blog post was the when it explained that testers can choose any of these terms to test programs depending on their knowledge of the product. This leads to the point where understanding the application of the product can also have great effects on how the tests are created. I found that there was a lack of diagrams within this post, but the information and definitions were easy to understand. I enjoyed this source very much as it easily explained the testing terms and how they differed from each other.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.