Category Archives: CS448

Helpful Advice for Seeking Employment

Today’s chapter in Apprenticeship Patterns is “Concrete Skills”.

This pattern provides an overview to the idea of more specific skills developers should have as they start their careers.

I think that this pattern serves as a good introduction to this topic. This pattern seems especially relevant to where I am now as I will soon be looking for employment after graduation and this is a good general reminder of things that software development managers are looking for.

I like and agree with the idea of creating a project for demonstrating your knowledge of the skills that you have acquired. This is what my team has been doing for our work so far this semester on the UpdateGuest project and I, along with my teammates, think this helps to cement the knowledge gained when learning new tools and languages. This pattern serves as another good reminder that this is also something I want to do more of with my personal project and I particularly want to start moving away from using languages I already know to learning and improving my abilities in these “concrete skills” with new and different tools that I am more unfamiliar with. I specifically want to get better at some of the examples mentioned in this pattern including web design and JavaScript, along with Angular as these three things seem like important requirements for developers now.

Although I think this pattern provides helpful information, I do wish that this pattern was more specific and detailed. I believe this pattern could benefit from expanding upon the information it offers. I also think that it would benefit from including an example CV showing how these skills are listed and defined on a real document. After reading this “action” section, I am now curious as to what the most important skills are for a starting position in the DevOps field and if I already know any of these skills. Again, I think this section could benefit from suggestions as to where to go to look for these besides people you may know.

Altogether I did find this pattern helpful and a useful reminder of what the most important parts of a resume are for a software developer. This is true especially as I move on to creating and refining my own resume in preparation for getting my first job in the software development field.

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.

The Benefits of Being a Beginner

This evening I continue my reading of Apprenticeship Patterns with the third pattern titled “Unleash Your Enthusiasm”.

This relatively short pattern describes the benefits and possible disadvantages, along with how to handle the “enthusiasm” of being a new developer.

I both agree and disagree with both of the areas of this pattern that describe the “context” and the “problem”. In my current situation and from my memory of the time I have spent in the software development courses so far, I have found that the professors I have worked with and learned from can have more “enthusiasm” than I do. I think that this is one of my favorite parts about taking this track of computer science was getting to learn from people who enjoy the work and learning as much or more than I do. I think this was specifically the case last summer with my work on the LFP community which really helped to motivate me to contribute to it and kept me going. At the same time, I also agree with the idea this pattern presents that a rather unenthusiastic group can bring down the mood of someone excited about being new to the field.

I do understand the rather unfortunate idea of only being excited about projects outside of regular work. I personally find this to be true and that although I usually enjoy working on my project, it is not just because of the topic or the self-interest, but also because of the freedom allowed in the workflow when you work on your own project. I think this point about a group’s attitude while working is something I want to keep in mind when I begin looking for a job as a software developer, as I would prefer to have a job where everyone enjoys the work they do and encourages this passion in each other.

Overall the quality this pattern describes seems like one of the best perks of being new to this field. I do worry that for me this quality will diminish over time and I hope that I haven’t lost it already before I’ve even started. I think that this pattern does a good job of pointing out this quality of a beginner’s enthusiasm and that it is something I want to work towards keeping now that I am more aware of it.

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.

Learning how to Learn

Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.

This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.

This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.

I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.

I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.

One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.

For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools 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.

Beginning the Patterns

This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.

This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.

I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.

I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.

I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.

Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.

I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.

This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.

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.

Second Sprint Retrospective

This week concluded the second sprint with my work on the UpdateGuest team developing for LibreFoodPantry. This sprint was exciting as we began creating the implementation of our service.

One of the first issues I helped work on this sprint was coming up with questions for the Thea’s Pantry staff member for when they came to our class.

During this sprint our team also focused on improving working together as a team as were beginning to implement our service.

An issue directly related to this included standardizing our IDEs as we prepared to code together on this project.

Secondly, as part of learning to code as a team I also re-read the first five chapters of Clean Code by Robert C. Martin to review best coding practices.

Additionally during this sprint I helped to implement the web interface for our frontend service where I began to learn how to use Angular again and also learned how to use Angular Material. This issue has two merge requests associated with it, one mainly adding Angular Material to the project, and another adding the implementation of the Web UI.

During this sprint I also reviewed and commented on two different merge requests. The first merge request was for implementing MongoDb for our backend service. The second was for the front end architecture document.

Individually, I think I am getting better at becoming a Scrum Master and learning to listen to other people during our meetings as I help to facilitate them. Although I have found it harder to do this when we switched to online meetings as sometimes it is harder to hear people talk than in-person. During the final sprint I would still like to improve on my ability to listen to other people’s suggestions, both during meetings and on GitLab.

I do think I need to get better at being patient with the rate that changes are made. This issue specifically occurred with a merge request when I directly made changes to a branch without asking first (even though I figured I should) as I thought it would be quicker than submitting another review for it. I do regret doing this as it led to a small conflict. We did resolve this issue and as a team we have made a new working policy that helps address this issue, so each developer only works on their branch individually to help avoid merge conflicts, in addition to helping with this issue.

As a team I think we did good this sprint. We finished several issues early on in the sprint and I am particularly happy with the work that was accomplished for the backend service and the web UI. I think that our team was also better at communicating this sprint and that we have improved our communication on issues and our use of GitLab to coordinate and communicate with each other. I also think we had some great collaboration this sprint with reviewing each other’s work, discussing and implementing suggestions, and even having multiple people working on the same branch.

I also think there is further room for improvement with our communication over GitLab and in meetings. Improving GitLab communication is especially important since we no longer have face-to-face meetings, and GitLab is where most of the remaining time discussing issues and work will be spent in the upcoming final sprint.

I do wish we were able to finish all of the issues we planned on doing for this sprint, but I understand that given the many different events over the past month that other things just got in the way of this. Part of this issue also has to do with the weights issues were assigned during planning. I personally think I need to improve my weighting estimates for issues as this seemed way off for this sprint. I think this was part of the reason we were unable to finish all of our issues as issues became more involved and took longer than was originally anticipated when planning for the sprint. Additionally, I think as a team we need to break issues into both smaller and more defined tasks, that way the work is more defined and the issue weight can be estimated more clearly. These factors are something I have been trying to take into account for while planning for the last sprint.

Overall, I am looking forward to our upcoming final sprint and I am excited to see if we can finish the UpdateGuest service.

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.

Apprenticeship Pattern Review #7:Dig Deeper

In practice, algorithm problems do not arise at thebeginning of a large project. Rather, they typically ariseas sub-problems when it suddenly becomes clear that theprogrammer does not know how to proceed or that thecurrent program is inadequate.Steven S. Skiena, The Algorithm Design Manual

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees 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.

Sprint Retrospective 1

What we did as group for sprint For this sprint we as a team started our first meeting by putting in place a plan for the whole sprint, we picked the first steps of the architectural design for our API. We decided the roles for each one of us, and then divided the tasks, so … Continue reading Sprint Retrospective 1 →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

The White Belt

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is the book assigned to us in my Computer Science Capstone class, it seems like a rather interesting read from the first look I had at it. The book describes different problems and solutions that a lot of software developers struggle with at different times in their careers. It has a rather easygoing approach to those things and is a good read that should be done by every upcoming and experienced developer, in my opinion. I know I will read it.

I was blown away by the intro of the book, which is chapter 1, and then and chapter 2 made me read it all the way. It was hitting close to home in my professional development. It made me think about all the things I’m going through right now, how my enthusiasm for my job went down and how I do not learn new things as well as I used to. Especially the white belt part makes me read it over and over. I realized that I grew complacent in my current job status and the change that is coming soon does not make me excited about the new possibilities at all, the fact that I’m dreading learning new skills for work is rather laughable since that was the way I got to where I am today.

I can see how this book will be a very useful tool for anybody who works in software development. Just by glancing at the introductions of the other chapters I can see that it will definitely be a very good motivation and inspiration to move things along, either it be my schoolwork or professional work. Simple things like what the book describes, for example chapter 6: Construct Your Curriculum, have been put on hold for me because I thought I didn’t have to do much anymore and I was all set when it comes to my skillset.

I have a very good feeling about this book, and it purpose of inspiring people to grow as developers, it is very thought provoking and makes you think critically about yourself and the problem we all face. I will most likely read this whole book as soon as I can to increase my enthusiasm for the work I do, and knowledge I’m amassing both through school and my profession. It definitely makes me want to be better but at the same time I’m understanding better that I need to learn things slowly, learn to walk before I can run. I have grown lazy when it comes to programming and I want to change that after reading just parts of this book. I will try to read the whole book as soon I can.

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.

Apprenticeship Patterns

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.