Monthly Archives: March 2020

Dig Deeper: Finding the Marianas Trench of knowledge

This particular pattern is quite resonant with me, or at least the context section of it, considering it describes my entire academic experience in computer science fairly well. An excellent analogy would be a lake a mile wide but a foot deep; or at least it would be but a foot is very generous to the depth of my knowledge and a mile is delusional considering the limited scope of languages and tools I am familiar with. However, the sentiment expressed in this section still holds: “You learn only enough about any tool to get today’s job done”. I’m ‘you’. It is not for a lack of interest, at least not in all the subjects we have covered, that I do not go very deep into them – it’s exclusively a matter of time and mental resources. I have found that I have only had the time and energy to cover a subject as much as it takes to complete the require work or project associated it.

An example that comes to mind was last semester when working on both a REST API and Angular web front end – and by working on, I mean learning frustratedly as quickly as possible while working with both for the first time independently. There felt like so little time that I had to at one point neglect the JDBC features built into the Spring Initializer because I simply did not have the time to dig through the documentation. I had to instead use a less efficient and redundant method I knew well. Additionally, on the front-end side, I was able to brute force a lot of scalability because it was easier to use the limited knowledge I had to write ngOnInit and onResize methods to handle window sizing; as opposed to learning built in scalability tools or utilizing CSS more effectively.

To learn these methods would have taken a considerable amount of time that I simply did not have. Luckily this semester the pace at which the site is being built is much more manageable, as is the distribution of work amongst four people. So, with this time I hope to gain a better understanding of the tools and techniques I wish to utilize, before I do so. The pattern suggests writing a blog post, unfortunately this one does not fit that prompt. Speaking of which, I find the idea of going back to read a technological paper from 1976 to be a massive waste of time – but that’s just me. Regardless, and as always, I will seek a more reasonable middle ground between the pattern and what I find effective.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Reflect As You Work

This apprenticeship pattern caught my eye for discussing the Peter Principle, which states that an individual will only be promoted if they do well in a position. The result of this is an organization full of people who have been promoted to positions in which they no longer perform well, creating an incompetent organization.

Reflecting as you work is meant to prevent this. The idea is simple enough: constantly probe your work process and ask yourself whether it is ideal. Take note of the positive aspects, but also the negative aspects so that they can be fixed.

The pattern suggests focusing on increasing skill rather than experience. This is a subtle but important distinction, because spending a lot of time doing a single thing wrong is still a lot of experience, but it’s not necessarily useful as a professional.

In certain parts of our industry,
it is quite easy to repeat the same year of experience 10 times without making significant progress in your abilities.

Apprenticeship Patterns

I certainly reflect on my work when it’s done, but I tend to focus on the work itself rather than the process. I’ve spent countless hours before a project commit making sure every line of code is perfect and the necessary documentation is in place. This led to nice code and happy professors or managers, but it didn’t help my work process. It was doing more of the same; obtaining a good result, but without improvement in workflow.

Figuring out how work processes connect is a helpful practice to identify counterproductive habits. We tend to take the path of least resistance and easily fall into a workflow that we assume works best for us, but this may be an illusion due to our limited scope of experience. We know redundancy can be reduced within a project’s architecture. We strive for this. Why then, would we not give our work process the same courtesy?

This pattern is a great example of software development’s being more than simply writing code. And by writing code, I mean using tests, DevOps, OOP, and anything else that can be considered a software engineering practice. As the entire book aims to prove, software development is an organic, human process. Moving from a software apprentice, to journeyman, to master requires understanding your own flaws, not just the flaws in your product.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 7: Sustainable Motivations

I feel like most people have been in this situation: you have passion for a hobby and decide that you want to take your craft to the next level. In doing so, a mountain of unforeseen stress and complications arise and at some point along the way you might even forget what motivated you to get to where you are in the first place. Sustainable motivations are important no matter what you are applying this pattern to. This pattern is especially important in the life of a software craftsman.

In an industry where it is all too easy to retreat into competence because the pay is “good enough”, it is easy to lose sight of the motivation that made you decide to devote your life to becoming a software developer. I can’t even describe the joy I felt as a sophomore in high school when I set out to make an, albeit shoddy, clicker game in JavaScript, and after slaving over the code for days I finally understood exactly how a game loop had to function in order to make the game playable. I proceeded to spend that weekend glued to my screen implementing all of the features I had only dreamed of days before, barely remembering to relieve myself periodically. It is that entering into a state of flow and  working through complex problems with the end result being something I created that made me fall in love with the craft. Sometimes I fall victim to forgetting what it is about programming that I love since it feels like I have been in school for a long time and the future in regards to employment and making ends meet is up in the air. To quote David Wood, “do what you love and the money will follow”. Making sure to never let your motivations become misguided is important into keeping energy and creativity levels as high as they can be.

An important distinction between motivations can be made. That is intrinsic versus extrinsic. The more intrinsic your motivations, meaning doing so because you find it personally rewarding, versus extrinsic motivations, doing so because you seek a reward, the more sustainable your motivations will be. I know I am extrinsically motivated by money and the desire to succeed for my family and teachers, and I am intrinsically motivated by the desire to create, the desire to increase the complexity of life, and the desire to solve problems. I find this pattern important because motivations truly change your outlook and mood when facing life. This pattern applies to everything in life and I think writing down motivations is a good exercise for my software development career and in life.

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

Completed tasks

I was worried about how well my team would work together at the start of the sprint. We are all rather quiet and I feared that would impact our project. Even Professor Wurst expressed some concern. While I feel our communication could use improvement, I think we did a fine job completing what we planned to do in this sprint.

We divided the sprint tasks amongst us and mostly worked on our tasks independently. All work that was completed was shared so that others could study and review the tasks they did not work on. While this worked for our first sprint, I am hesitant to repeat this method as I believe it can lead to confusion in the group. For our next sprint, I think we should try and assign tasks to multiple people so we can emphasize that the responsibility for the tasks fall on the entire group.

I feel we did a great job of sharing our work and resources. Most of our decisions are public on gitlab so that it is clear why we did what we did.

My primary focuses this sprint were learning how to set up a mongo database and how create a REST API for it. One thing I think I could improve on is the frequency of my updates. I generally completed a task before making my work public. It may be beneficial to update more often. Something I would like more from my team is feedback. While my work was reviewed, I have not felt like I have received any real criticism, constructive or otherwise.

By the end of this sprint, we had a good skeletal structure of the update module. We implemented test versions of the technologies we would use in our full stack application and completed a small MEAN stack, a full stack app using MongoDB, Express.js, Angular.js, Node.js. With what we completed in this sprint, I believe the coming sprint will be clearer in scope and better planned.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Developing for LFP Again: First Sprint Retrospective

For over the past month I have been working as a member of the UpdateGuest team as part of developing for the LibreFoodPantry community. This blog post is a retrospective for the first sprint our team had. During this first sprint our team focused on setting up the UpdateGuest service and beginning the research into the tools we want to use to implement this service.

The issues that I was assigned to work on for this first sprint mostly focused on figuring out what we needed from other teams for the UpdateGuest service to function and what information the UpdateGuest service needs to store and to provide for other services under the VisitModule.

Specifically looking at the work I did this sprint:

The first issue I worked on was determining what data fields UpdateGuest would store, this was relatively simple and we decided that our service would mostly be using the fields the RegisterGuest team was storing since our service pulls guest data from theirs.

The second issue I worked on was a quick one creating a .gitignore file for one of our projects.

The third issue I worked on was determining the endpoints UpdateGuest needed from RegisterGuest to be able to get data from their service, this was solved quickly as the RegisterGuest team posted an issue where they listed all of the endpoints their service would have and this was all we needed.

The last issue I solved was what endpoints UpdateGuest needed to create for other services to use (along with our own), this became a discussion on many things, mostly with our team and the RegisterGuest team, to coordinate the endpoints and data they needed from us and how to format the endpoints and the data we are sending back and forth, but also how our service functions in general.

Finally, I helped to discuss and merge the creation of the Angular app for the UpdateGuestWebUI project.

I think that during this first sprint that our team did well. We successfully completed nearly all of the issues that we initially proposed to work on at the beginning of the sprint and even managed to create a couple of new ones and pull some additional issues from the backlog that were completed. Our pacing and completion of issues was mostly on track with the weighting system we used when creating the issues during sprint planning, although this might need some refining. We had good meetings in class where we all talked about what we were working on and we resolved any issues or questions that were ongoing with our work. We also used GitLab effectively to coordinate all of this work and document the different discussions and work as it was ongoing throughout the sprint.

I think that some things could be improved. I think that we could all try talking and communicating a bit more both in-class during our sprint meetings and outside of class either on issues on GitLab or on Discord. From Dr. Wurst’s suggestion I think we should establish some working policies for the rest of the semester’s sprints, especially about communication, but also when work should be done on the project. I think this is necessary so that others have time to contribute and interact on other group member’s issues and work before class meetings, so we are better prepared to discuss them in-class. I think specifically we need to define a team policy of replying to comments on GitLab or Discord when someone directly mentions an individual or the whole team asking for input that helps to solve or facilitate an issue.

Individually I think that I need to improve on my own communication skills and in helping facilitating team meetings in-class. Most importantly, I think that I need to get better at letting others talk and understanding the points they are making, especially if their opinions or solutions differ from my own, before I comment on them. Additionally, I think I need to get better at articulating my explanations of solutions and trying to not sound condescending while doing this. I also think that I could improve on my response time when directly mentioned on GitLab on issues.

Overall, I am excited to be working on a LibreFoodPantry project again and look forward to the remaining sprints as we continue developing our services this semester.

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

Retrospective #1

Now that Sprint 1 has come to an end, it is time for the retrospective blog. I will start by including everything I contributed to this sprint:

This link is a note in an issue where I have put a document discussing the Pros and Cons of whether we should be using a relational database or not. I put some examples of relational databases and non-relational databases for when I was making a decision along with links explaining a few of them.

This link is another comment on GitLab basically stating that we are using mySQL because of the simplicity and it is easy to look up information on it if needed.

This is the repository for our database currently, it is currently on a separate branch and not merged with the master due to a sudden change in database fields which will be implemented first thing in the next sprint.

This is another repository that holds the results of completing the Tour of Heroes Angular tutorial. This was the last thing completed for the current sprint to give me a refresher on Angular as I haven’t worked with Angular in a little over a year.

This was our first sprint so everything obviously wasn’t going to be perfect. However, I believe that we used GitLab very well considering this is my first time actually collaborating on a big project using GitLab. I think that we created issues that were specific enough to be considered issues. We utilized the boards well too. Our communication was mainly done through class and text message, but overall, I still think we communicated every issue that needed to be communicated.

Of course there were things that didn’t work well either considering it was the first sprint and this is most of our first experiences with Agile and sprints. While I mentioned that our GitLab use was very good. There were some faults with it as well. For example, my desktop didn’t let me push to GitLab which is an issue that still needs to be resolved. I specifically had trouble working with the separate branches because it was confusing at first. Our issues weren’t created the right way at first, and had to be restarted even though there were ways to just edit them without restarting. We had good communication, but I felt as though I wasn’t as involved as I should have been with the other team members work. I also think that there wasn’t enough communication between the other groups in the class as a whole.

Some of the changes that can be made as a team is more involvement in each others work. I think that we can all spend more class time looking at each others work rather than looking at it on our own time because this allows for more discussion. I also think that our team could start communicating with other teams more. Most of the teams came to us rather than us going over to the other teams to collaborate.

My individual changes that I need to make is talking more to my team members about what they have been working on rather than focusing on my own work. I could offer more solutions to the front end team about design. Probably my biggest issue would be my procrastination. I have to start working on my assignments earlier because that has an effect on how the rest of my team performs. I think that this next sprint will be much better now that we have been exposed to this more.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

I think that the first sprint went well overall. My teammates and I completed all of the issues we assigned ourselves during the planning meeting, so the sprint was definitely a success. We accomplished this thanks to our effective use of the GitLab issue board. For the most part, our issues were clearly defined by their titles and labels, which helped us understand what needed to be done. Additionally, we assigned different team members to different issues, which made it easy to track our own issues and the progress of each other. The issue board also helped guide our in-class discussions, as the column-based structure allowed us to quickly select doing issues to discuss their progress and evaluate the needs review issues as a group before moving them to done. Finally, the board gave us a platform for discussion outside of class with each other and with other teams. We successfully used this to clarify what we needed from other teams and to answer questions among ourselves.

I think the main issue among the team during this sprint was communication. We did not always keep each other informed about our individual tasks, which sometimes made it difficult to resolve problems. During our class sessions, discussions frequently came to a stop after we reviewed our issues, leading us to silently work separately instead of collaborating. One major hinderance to our progress was an issue with our .gitignore file in the UpdateGuestWebUI repository. We had a branch where a mock Angular app was created, which had commits made before we finalized the .gitignore on the master branch. This caused unnecessary files to be committed, and we spent multiple weeks trying to find a way to remove them. We eventually found a simple solution that involved removing and recommitting every file after updating the .gitingore. It really shouldn’t have taken us that long to find such a simple solution, and I think we could have solved the problem quickly if we all worked together on it rather than focusing on our assigned issues independently.

I think there are several changes that can be made for future sprints, both for me individually and for the team as a whole. For myself, I think I could leave more comments on issues. I often made progress on my assigned issues or wanted to ask questions to my teammates, but I decided to wait until our class meetings to inform them about my progress and ask them my questions. Not only did this result in several of my contributions being undocumented on GitLab, but I also felt that it slowed the pace at which I could work. I also think that I need to work on communicating with the team in class more. During our meetings, I need to try listening better and making more contributions during discussions so that I can keep myself informed about the team’s progress and help my teammates resolve their problems more efficiently.

For the team as a whole, I think we can make some improvements to our usage of the GitLab issue board. I think we used it effectively overall, but there were some problems that caused confusion, such as an issue getting duplicated. We also exclusively used template descriptions for our issues, which sometimes made it unclear what we planned to do. I think we could better coordinate how we create and label our issues to avoid such confusion in the future. Additionally, I think the team could make improvements to communication. Instead of simply sitting in silence during class, we could explain to each other what we are working on in order to keep each other informed. Also, asking questions about issues and listening closely to comments from each other would undoubtedly help us avoid drawing problems out for too long. While this sprint was certainly an overall success, making these changes would help us work more efficiently and ultimately complete more of the project.

Links to My GitLab Contributions:

These are issues I was assigned to, where I made comments detailing my progress.

These are issues where I replied to comments from a teammate, acknowledging that their progress would help me with my assigned issues.

These are issues I opened, assigned weights and labels, and edited the descriptions of.

These are issues I moved across the board.

This is the duplicate issue that I closed.

This is the UpdateGuestWebUI repository I created and worked in. Note that the branch where I added the .gitignore and the Angular Mock branch where I resolved the .gitignore issue have since been merged into master.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.