Category Archives: Retrospective

Sprint 3 Retrospective

(I’m sorry if some sentences are hard to understand. I am pretty sick at the moment, and it’s hard to make sense sometimes)

Our third sprint had two end goals, deploying a demo locally using minikube then hosting it using AWS EKS, and discussing with the other teams on what they’re working on so we can make a schematic from their work in a hosted Kubernetes Cluster. We ended up discussing it with the other teams and were able to create the final schematic. We were also able to deploy a local demo of the Kubernetes Cluster, but we had issues deploying a demo on AWS EKS.

What worked well was discussing with the other teams to get information on how the final schematic would look like, and how our team worked together in organizing the information from talking with the other teams (1). There were also many regards while working on the final project where we came together as a group to set up a schedule, how we’re going to do the presentation, and when we should do it. Afterwards, we were able to use this information to create a schematic illustrating each of the different team’s works inside of a deployed Kubernetes Cluster (2).

I think part of the reason the third sprint was the most difficult was that it was the last sprint in the semester. For example, I and some of my other teammates had a lot of projects we had to get done while due dates were getting close. This made it harder to focus a lot of time on working on the project. Maybe if we focused more time on this project, we would’ve been able to get a demo out, but it isn’t a guarantee that it would’ve happened.

As a team, I think we could’ve been more communicative and dedicated more time to working together on the project. There was a lot of not knowing towards the end on whether or not someone was working on something because communication on some level broke down, especially when some people in the team were busy with other things. This led to troubles with communication, especially when working on the final project. There were times where we agreed to finish work by a certain deadline, but not everyone finished by it.

As an individual, I was constantly trying to push myself to be more active in communication with my team members about updates. However, this does not mean that I was good at it, or I did it without flaws. From my role as a scrum master during this semester, I think that I need a lot more experience in communicating with my team members and being more assertive in initiating conversations and keeping planned dates we agree on in check. 

Links:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/49 – An organized compilation of six issues from our team members’ discussions with the other teams.
  2. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation/-/issues/1 – Final Diagram of a Kubernetes Cluster hosting the docker images worked on by the other teams.

From the blog CS@Worcester – Chris's CS Blog by Chris and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Our second Sprint had the end goal of deploying a demo Kubernetes Cluster. This cluster would most likely be deployed locally using Minikube and Kubectl, and would use a demo so we could understand the process.

We weren’t able to get to the issue that would have us create a Kubernetes Cluster, but we still made a lot of progress and ended up getting close. 

What worked well was the use of teamwork between issues. What I mean by this is, one team member would research something for one issue, and that research would be important for another team member working on another issue after the fact (1). The research and the results of what we produced while working on our issues is informative, and is vital for our goal of our team for this class and what was our goal for Sprint 2. The quality of our work was pretty good, and I think we’re progressing nicely, albeit a bit slowly, to a competent end product.

What didn’t work well was some of our organization during the sprint. As mentioned above, we weren’t able to finish the demo for the end of this sprint (2), and I believe there were a few examples for this. The first reason was spring break. We didn’t progress on any issues during the break, and coming back took time to get back into gear. The second reason was the class cancellation on the 21st of March. This was right after spring break, and it was a bit difficult to get back into it. Even still, we should’ve started working on issues like normal, but it took some time to organize and it caused us to stall for a few days (3). Finally, a lot of work relating to a Kubernetes Cluster is a concept that is new to us, and it involves quickly learning new things. (4) This spring required us to deploy a demo within a relatively short amount of time. As such, I think Sprint 2 was more difficult than the first sprint, and this spike in difficulty was a big factor in our work progress.

As an individual, I felt that I could improve by interacting with my team more. Some of our issues could’ve been worked on concurrently, and it’s very easy to simply keep working on individual issues without understanding the greater context of what we’re doing. Since we’re trying to set up the infrastructure for a Kubernetes Cluster, everyone needs to understand the context of their work in the project (5). I felt like maybe I could’ve started a conversation or two with my teammates about the project. I did it once or twice, but maybe initiating one or two more conversations would have been helpful.

As a team, communication is something that I think we need to improve on. For example, after the break we should’ve started communicating to roll back into action after not working on anything for a while. Another thing that we struggled on was communicating outside of class on setting up some of the sprint issues, which caused us to lose one point on our grade.

By the end of Sprint 2, we progressed and learned a lot. I feel comfortable about this project, and our work for our next sprint as laid out by our second sprint.

(1) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/28 – This issue provides a lot of good information about Kubectl, which will be very helpful on deploying a demo cluster.

(2) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/41 – This issue is the demo issue. It is not yet done at the time of writing this.

(3) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/24
– An example of me starting this issue a few days after coming back from break, which should’ve been done by Monday.

(4) https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/24 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/35 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/28 https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/39
– Four examples of different things that we need to know while working with an issue.

(5)- For example, the demo would require us to deploy the projects listed by this issue: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/34, concurrent to understanding and creating anatomy posited by this issue: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/35

From the blog CS@Worcester – Chris's CS Blog by Chris and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

For our first sprint, our goal was to familiarize ourselves with the different components of a system that we need to work with and that we don’t know. Most of the issues present in our first sprint dealt with researching these aforementioned components, for instance, RabbitMQ, EKS, and Kubernetes. As such, most of our issues were researching the anatomy of what we’d be working with via AWS EKS. I believe our main difficulty was determining what we needed to research, and what was useful or not.

To get what did not work best out of the way first, some team members, myself included, missed the deadline on some of the issues. In my case, this was due to the fact that we are unfamiliar with much of what we’re researching, thus, the issue I dealt that I’m referencing with was denser than I expected it to be because it’s difficult to project precisely how long each issue would take, or if we need to split it up into several smaller issues1. 

What worked well was our team’s communication with each other in class, and in some of the issues. It took a few classes to warm up to each other. I think the descriptions and how we formatted our research also worked well. In general, we used markdown to break down our research into more digestible sections that made it easier to understand2. Another thing I thought worked well was the description of what we may be looking for in the issue descriptions. While difficult to be too specific, it helped as a starting point for the other team members to begin once they finally started on the issue3. 

As an individual, I think I could improve on meeting issue deadlines in a more timely manner. While I mentioned earlier that the issue was denser than I thought it would be, I also should’ve managed my time better, and started working on this earlier to fully understand the time it would take, so that I might’ve been able to mention it in the next class. I also think that I should’ve talked more through the GitLab Issues / Epics rather than other means. While I did communicate using the aforementioned means, it may be better to discuss more, especially as our future sprints will more than likely demand it.

As a team, I think we should institute a better application of rules throughout the issues. While writing this, I realized the issues implement markdown format differently than others4 5. I don’t think this is a big deal, but it may be better to implement some form of standard across the issues. I also think that we may need to communicate a little more via the GitLab Issues / Epics. In this first sprint, most of the issues were independent research that usually didn’t cross over into other issues very much, hence there was little need for communication between team members. However, given that the second and third sprints will involve deployment, it is both required and vital that we communicate on GitLab.

Evidence:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/13#note_848604859 – A note left by me explaining why it took extra time.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14 – An example of research using markdown to partition the different parts of research as mentioned above.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/4 – Example of an issue’s description that includes a brief description and several points of interest.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11 – An issue description using spacing to separate sections.

5. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15 – An issue using titles in markdown to separate sections.

From the blog CS@Worcester – Chris's CS Blog by Chris and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.

Issues I was Assigned to:

Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.

Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.     

List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.

Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.

Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.  

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

At the end of last week, we finally conclude our third sprint in our development process of the LibreFoodPantry, aiming at a deloyable environments so that they all are isolated in their own space. This is also our last sprint so we tried our best to wrap it up as much as possible, so that the team after us can easily pick up from where we left off. We were able to work together more this time, comparing to us having to separately work on our own stuff in the previous sprint. We finally got a working, operational and deployable user interface as well as a fully implemented, buildable and deployable backend system with REST API and mySQL database. We were also able to adapt with the online communication and worked more effectively with each other.

List of what we accomplished during the last sprint:

       – Successfully integrate Docker into frontend UI and the REST API, allows them to communicate with the existing mySQL container with configurable parameter in config.json file (REST API Docker, ApproveGuestWebUI Docker)

–         –  Having an operational admin page user interface or ApproveGuestWebUI, although without actually data fed from backend systems, but mocked with data points (ApproveGuestWebUI Epic)

–         – Having a mocked or stubbed backend for the frontend to test connections establishing mechanics (Registration Stub)

It seems that we did not do a lot for this sprint, but it was actually much more challenging for us because of more advanced technologies that we have to research on and a lot of new barriers that we have, such as us having more things to do for our career and other classes, voice and video communications became harder as the internet becomes unstable, for me at least, etc. Despite all of that, I think we did a very good job wrapping up all the work we have done from the sprint and even make it deployable, so the next group can just skip the hard part of Docker and focus more on the part of developing operational products for the food pantry. We think that is much more important than to waste time on getting them to be able to run on an actual server, so I heavily prioritized to get it done, both on Docker Desktop and Docker Toolbox. I would say that out of all the sprints, this one is pretty boring since I personally had to read a lot comparing to the two last one that all I do is setting up systems, coding, and a whole lot of checking on people if they can run the same system and if they need some help.

For future improvement, if we have a chance to work more on the project, I think it is better to centralize our work source into either backend or frontend, then move on to another. I believe it is better that way so all the team member can know what other members are doing and learn both the backend and frontend stuff. Another improvement that our team can use is more official communication and well documenting our steps of implementing. It is the same problem that persists from the last run, but we did make sure to have more transparency in what we do this sprint, which I think is a major effort from us.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This past week was the end of our third and final Sprint for the Capstone class. It all went well, and in the end, we got a deployable project and we have completed most of our tasks successfully. I will write about my tasks and my overall impressions of this Sprint. In this particular sprint most of our teams efforts were focused on getting the Docker containers working together and because of that some of our task will overlap more than other times.

Tasks:                                                                                                                                                                

  1. Issue #35: Create REST API Docker container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/35
    Just like the title says, creating a working Docker container for the REST API.
  2. Issue #47: Create MongoDb Docker Container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
    Same as before, creating a working container with a MongoDB schema.
  3. Issue #37: Establish communication between All Docker Containers
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/37
    Probably the hardest part of this whole project, getting all the separately working Docker containers to talk to each other.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, even though we were cutting it a little bit close this time. When it comes to my tasks some of them were somewhat easy and did not require a lot of time, but some were very time consuming and research heavy as well as required cooperation of the whole team to solve (yes issue 37, I am looking at you). What I am also very grateful and happy about is the way our team was able to find time and “place” to be able to work on these tasks. My busy schedule was as always, a challenge to work on things as a team, but in the end we were able to do it.

What didn’t work well?

As always: comments. Due to the difficulty of this particular sprint our team was meeting online a lot to brain storm things together, we were in constant communication and in my opinion this made us ovewrlook the need for leaving comments on this project for future teams and the work that they will be performing.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet but with some minor adjustments it will be ok. As I have mentioned before I think we should work on our problem descriptions, we need to be more specific and detail oriented as well as maybe splitting the problems into smaller subtasks with less of a weight assigned to them so they can be worked on at a faster pace with the feeling of “getting things done”.

What changes could be made to improve as an individual?

The only thing that I can think of after this Sprint is, I would say, my lack of time to spent on the project compared to my classmates but that is something beyond my control. Overall, I am very satisfied with what I have done this time. I have done things that were useful for the group and the state of our project. OK, maybe as I have said earlier, Comments, I should have made more of those.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don’t really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end.

List of what I accomplished during the last sprint:

– Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build

– Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data

– Successfully established connection between REST API and mySQL database on each member’s machine with a customizable config file to fit with multiple server setup

– Completely overhaul and clean up code for REST API to be more optimized and modular

– Front end wise, John and Kevin was able to make a few basic component to display guest information, made a lot of effort to learn about Material design, and experimenting with communication with the REST API

With a lot of work putting in developing the back end, I learned a lot about how to make connection between REST API system and mySQL. There are a few small things that I can pick up through this run too, like the differences between Docker Desktop and Docker Toolbox, making CI/CD script with different images, and so on.

During this run, it went really smoothly and we only ran into multiple communication issue, and small things during the development process like the date and time is behind when data point is fetched from the database because of timezone differences for some reason, or having to deal with numerous bugs that the default date object in Java caused. Other than those, I think we’ve done it pretty well. 

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

This past week was the end of our second Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #25: Connection between Database and Rest API Backend
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/25
    Creating a Rest API backend that talks to the Mongo Database with specified queries and retrieves total weight.
  2. Issue #2: Fix CI Setup
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/CheckoutService/-/issues/2
    As the name implies, fixing the CI/CD setup for GitLab pipelines, after copying from master it no longer worked.

What worked well?
This time around the Sprint and our lives in general were drastically changed due to ongoing COVID-19 outbreak and the implementations of federal emergency and stay at home orders. It all began normally we started this Sprint like we have before with everyone working on our tasks and meeting once a week for a group session to tackle the problems together. After the outbreak what worked well was very little. In my case finding time and just organizing anything due to my work switching to a “work from home” situation was extremely challenging. One thing that might be working in our favor is that due to most people not working we can call in an online meeting a lot easier since we are all at home. There will still be some time constraints of course.

What didn’t work well?

The social distancing order is a little challenging to work as a small group like this on a project. Before we were able to meet and collectively challenge some of the problems we were having. Scheduling some of the meetings got easier but the actual work time got drastically reduced and in my case just being able to perform some tasks is rather challenging.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet and Corona Virus outbreak made that so much more challenging than before. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording. We probably should have broken the bigger tasks into smaller sub-tasks to make them more approachable as a whole.

What changes could be made to improve as an individual?

During this sprint I have again felt that I have not contributed enough to the team, the tasks I have performed were not as hard as they seemed originally, only working on the API connection to the database took a significant time. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework and with the temporary adjustments to our living conditions that has gotten even worse. This time will be a real test for all of us, test of our self-control and patience.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

At the middle of last week, our team finally concluded our first sprint, working on user approving system for the LibreFoodPantry. Overall, I think our team did pretty good on doing a lot of initial setups and communicating with other teams to make sure we can have a consistency on data across databases. For me personally, I did quite a lot of work on setting up repositories, researching on making the back-end database, and helping my teammate, as well as people from other teams on the problems that they have that are related to our module.

List of what I accomplished during the last sprint:

– Setting up repositories, including ApproveGuestWebUI, ApproveGuestService, and isApprovedWebUI, which regarding to tasks like forking from templates, enforcing rules for making changes to the source code, and informing the team about that policy.

– Researching about how mySQL database can be initialized on Docker containers, import – export existing mySQL container for future usage, and communicating to it from outside of the container (wiki page is available at link)

– As I am more interested in getting the back-end to finish in the early stage of development, I helped one of my teammate, Tyler, to make documentation about REST API endpoints and further getting feedback and making suggestion with other teams on those endpoints (wiki page is available at link).

– With all that endpoints in place, I setup the schema to potentially be what the mock and the actual database looks like and getting appropriate changes to it to match with the Register Guest module (wiki page is available at link).

– Finally, I had a lot more time towards the end of the sprint than I expected, so I dug deeper in setting up Spring Boot for the REST API and making a few objects within the program to lighten the amount of work for the next sprint.

With a lot of work that is put into initializing the project, I also learned a lot. While I did have a chance to experience SCRUM on my last internship, this time we use Gitlab as a tool to log all of our work, which I really the simplicity but professional and effective, rather than Jira and Confluence, which are more corporate driven software. I also learn to operate Docker, which I delay on getting to know it for a while as I though to myself that virtualization is a most optimal way to go, and after the last sprint, both are now under my consideration for future projects. And lastly, I learn that communication is really important, especially in the early stage of development, as a lot of data structures have to be defined and unified among the teams.

There is also the excitement, and at the same time,  frustration, of planning what to do to optimize the time and the work needed to get the job done as we had a list of questions without a clear answer on where we should head to. Although on Gitlab, we got really few comments put up, the teams had a lot of face to face conversations to make decisions on problems, and that I think is a problem that we need to record more of our conversation during the next sprint. At the end of the sprint, we are able to finish every issue tickets that we put up initially and we got quite some spare time afterward so I think we did a really great job on what we set out to do and I think the more sprint that goes on, we would be able to take a much heavier workload.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This past week was the end of our first Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #21: Define Database Schema
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/21#
    Creating a small UML diagram of possible database schema, open for further revisions later.
  2. Issue #6: Create UML Diagram for REST API Structure
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/6
    As the name implies, creating a UML diagram for REST API structure for our project, open for further revisions later.
  3. Setup production Database
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
    After deciding what our team will use as a database for the project we have made some preparations to make sure it is working correctly and we can do necessary operations with it.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, when it comes to my tasks they were somewhat easy for now and not necessarily required a lot of time, in my opinion being able to use some of the knowledge from previously taken classes was a very good example that what we learn is useful in the “field” application. What I am also very grateful and happy about is the way our team was able to find time and place to meet regularly to be able to work on these tasks. With my busy schedule it was always challenging to have a team able to work within my time constraints.

What didn’t work well?

Comments. I think as a team we were not quite there yet when it came to work on this big group project that others will take over eventually. I also believe that some of my contributions to the team could be more, after this Sprint I’m not sure I have done enough.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet but with some minor adjustments it will be ok. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording.

What changes could be made to improve as an individual?

During this sprint I have felt that I have not contributed enough to the team, what I had to make were some diagrams, only the work on the database was somewhat challenging, even though most of it was handled by my teammate and I only helped with some of the parts. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework, but to be honest I also waste some of that time. Another thing I should probably work on more is to do more research on topics assigned to me, not only finding enough to get my portion completed. As my previous post said I need to Dig Deeper.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.