Category Archives: Week 8

Moving on with Story Mapping Tools and Creating Setup Diagrams

Last week started on Tuesday by meeting with Dr. Wurst. In our research meeting we discussed various topics from the previous week’s work including the story mapping tools and the continued discussion on which platform to use for LibreFoodPantry for communications. We decided that based on my findings and what we currently know, is still the best story mapping tool and that we will start using this to transcribe the LFP user story map created during the June story map using this and I should update the GitHub issue card regarding this. Frequently when talking about various things it seemed that we will need a server for hosting various tools for the LFP projects so one thing I will look into is what services (if any) have free server time for open source projects. After discussing the workflow documentation I created for the shop setups I learned I needed to create diagrams for these and research or create my own way of modeling different things in GitLab and GitHub such as repository structure and permissions. 

Wednesday I briefly updated the issue card regarding if we are still creating documentation for GitLab Free since it has restrictions on the number of issue boards you can create. I also updated the story mapping card with what Dr. Wurst and I discussed the previous day about reaching a decision on which tool we are using so we can move forward with that. 

Friday I looked at the updates to the story mapping issue and started working on transcribing the user story map created during the June retreat from the pictures taken and put onto the Google Doc during the retreat. I found that this went pretty smoothly using and following the format for the shop-level workflow we previously did in this tool made it easy. I updated the issue on GitHub with my work in progress story map and asked for it to be reviewed to make sure I got the colors and card positions correctly. I then tried pushing the workflow documentation to the LFP/Community GitHub repository and ran into a permissions error so I had to email Dr. Wurst to get write permissions for the repository. I switched the documentation extension over to .md so it would be recognized as Markdown by GitHub and the operating system. I then started working on creating diagrams for the various setup workflow documents. I started out by drawing the initial diagrams on a whiteboard then I would transcribe them over to a digital format to be stored in the GitHub repository. I tried using the yEd tool that Dr. Wurst suggested for creating diagrams and found that it was a bit tricky with yEd being a lot more restrictive in where you can place things after previously using for making diagrams. Although after using it for a couple of hours, I found that it is easier to have consistent formatting with this tool versus and I’m starting to warm up to it more. One thing I want to figure out is where and what format should these diagrams be stored in the repository and should they be included in the setup documents. I ended up finishing the diagrams for both GitLab Gold and GitLab Free, along with refactoring the documentation, and started working on the ones for GitHub Free. When I went to use the shop manager test account on GitHub I found out that all of my GitHub testing accounts had been flagged by some kind of auto spam detection bot so I emailed Dr. Wurst regarding what I should do about this and ended the week with this. Next week I will continue finishing up the setup diagrams and documentation and move on to the workflow ones, along with responding to Dr. Jackson’s additional questions on GitHub.

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.

Dig Deeper

We live in a world where different complex software projects have different deadlines and they use a variety of tools to finish the projects. Most of the time employers cannot afford to hire too many specialists to fill every role. You learn only enough about any tool to get today’s job done. You select some … Continue reading Dig Deeper

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Hello dear readers. Here we are again in another blog post with another Apprenticeship Pattern. Today’s Pattern is called ‘Record What You Learn” and by the name you can kinda tell what this is all about.

One day before I started my job, one of my friends gave me the same advice “Take a notebook with you and write down everything they explain. Sometimes even the easiest things can be forgotten. Also this gives a good first impression on how seriously you take your job.” I got to say that my friend was definitely right and I can say with prof from my experience at my job and also from this pattern that I am writing today.

This pattern talks about the learning process and how important it is for you to record what you are learning. When starting a new job or working in a new project, you will be facing a bunch of new material and believe me you won’t remember all of that. It is very important for you to keep notes about everything you are learning but not only. There are a lot of people out there who keep notes and when they go back to review, they don’t even understand their own writing or what they were trying to note.

It is true that is very important to keep notes but it is also as important to keep clear notes. The authors strongly suggest to keep a blog post about these new information that you are being exposed but I would say that a blog  is not required or necessary. In my opinion it is perfectly fine to have all your notes stored in a notebook as long as everything is clear and clean. I would say that another advantage of the blog posts is that while writing about you learned, you also reflect about it.

It is totally your choice to decide on how you would like to record and store all your notes. I personally was very happy to show up on my first week of work with a notebook with me. Even after 6 months I needed to look at that notebook once in a while. Another use of my notebook was for my new teammates that joined the team. As I passed it along, they also found it very helpful and started to create their own.

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

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

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

“Practice, Practice, Practice” Apprenticeship Pattern

I am writing this blog post about the “Practice, Practice, Practice” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about the desire to improve and learn despite not having the opportunity to do so while working. The obvious solution that the book presents is to practice on your own time, while not working. Practicing something is certainly important; the process of practicing working with some idea is actively developing experience with that topic, rather than just reading about it and recognizing it. I have spent a lot of time reading about many different algorithms, and a lot of it does not really stay until I make it relevant by directly implementing it myself. The only consequence of doing this is educational, though; doing this while working would not be the appropriate time. Practice generally does not yield some purposeful product, whatever it is that is created in the end is only for the sake of experience. The book brings up a point about practicing the wrong things. I think this can be important. I have spent a lot of time practicing trying to write programs using the fewest amount of characters possible, which for obvious reasons is not a good way in general to go about programming. The result is typically a barely readable mess of what amounts to glorified machine code. I became good at it, but certainly the time would have been much better spent practicing something more practical than code golf. After gaining a lot of experience with different topics that I found interesting, I have been able to recognize situations where things I have practiced in the past are relevant and knew how to implement them as a solution. What I have noticed along the way is that now I would rather spend my time applying what I know than taking the time to practice something new and not produce anything meaningful. I still am interested in learning about a lot of things, but practice takes a lot of time, so the only way to learn is to take the extra time.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

nurtured your passion

Hello everybody and welcome to another CS 448 apprenticeship patterns blog post. After coming back from spring break which was a relaxing week, the pattern that I will be discussing today is nurtured your passion. This blog covers how to protect your passion for software craftsmanship. I agree with this article when it goes over that the environment can disrupt your passion for software craftsmanship. This article gives good advice on how to keep your focus on becoming software craftsmanship like finding something at work that interests me and that I can enjoy. Also, it’s important to find the time to work on a project that is more enjoyable. I agree on this because during the beginning stage of my programming journey I would work on learning the fundamentals of programming and problem solving which was not really enjoyable and at times I felt like quitting but when I eventually move to the more advanced classes I found that I was working on more application based projects so that made me more passion to learn more but if I was just working on the fundamental stuff than I would probably quit programming because it wasn’t as enjoyable like creating applications. One of the other tips that it gives is studied the classics which was to learn the fundamentals which I understand is important, but I figure it’s better for me to learn the classics and work on the enjoyable project at the same time. I like that tip that you should find an environment that is comfortable to work in because certain stuff can bother you like co-employees, the rate of pay etc. and this can affect your passion for software craftsmanship. All in all, I think this pattern is helpful like all the rest but there were some things I didn’t think we have control of sometimes because yes, we could also leave an annoying situation but many jobs I know from experience always has its flaws but finding a job that provides more enjoyable work it more reasonable. I think this pattern is great and it inspires me to be more in control of my journey.

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

Pattern 4 – A Different Road

After writing about “The Long Road” in my last post, I decided to read the referenced “A Different Road” pattern. This pattern is exactly as described in “The Long Road”. It is a pattern that basically tells you that it is ok to step away from software development and that even if you leave, you will carry what you have learned into whatever path you choose to take. This pattern also warns readers about the difficulties that may arise if they want to come back to the world of software development after taking a break of any kind.

Compared to “The Long Road”, I very much align more with this pattern. I agree that the problem solving techniques learned throughout years of software development can be useful in other career or life paths. I feel like this pattern should have given more insight into this aspect of choosing a different road. This section didn’t really discuss how one might move from a developer position to a project manager position where such technical insight would be a massive benefit to a company. Being in a position like this and having a strong understanding on the feasibility of reaching deadlines and being able to relate to the developers working under you makes you a great asset to your company. The pattern instead gives examples of teaching and full time parenthood.

I entirely agree with the aspect of this pattern that talks about how difficult it is to find a job after having a gap in employment. I follow several computer science career related forums and this is a very common point of conversation. Whether it is a young adult who takes a gap year after graduating, or a parent who takes off the first year of their child’s life to bond more, they both often have trouble finding work after their gaps. This all varies company to company and there are definitely companies out there that value work-life balance as a core principle of the the company’s mission statement. From my experience, companies that have more of an older employee base are more work-life balance heavy. They tend to have more of an understanding of the 40-45 hour work week. There are also companies in the area of defense contracting that almost “have” to have their employees work a maximum of 40 hours a week due to contracts. It is all about putting in the effort to get back into work and finding a company that will work for you. If they don’t understand a reason for taking a break, they probably aren’t a company you want to work for.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Confronting the limited knowledge

For this week, I have decided to read another pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. It is called “Confront Your Ignorance” for this pattern. I chose this one because since I have read about job titles in the last blog post, I believe that there is a need to go back and understand the basics of knowing what to do with self-awareness when it comes to learning materials.

With this pattern, it starts off with the context of that we identified gaps in our skillset, gaps that are relevant to our daily work. The problem is that we do not know how to begin in working on them while knowing that there are tools and technique to master. By to some extent, some of the people around us already know these things and there is an expectation for the knowledge. To solve this issue, we need to choose one skill, tool, or technique to fill in these gaps for the knowledge. It is necessary to make the trade-offs each day to hone these and be sure that to decide whatever it is alright to dig deeper or fix the other gaps in the future.

From this pattern, what I found interesting is the way it makes a compelling statement towards a real-life scenario. While it is alright to learn when doing the project, it is not appreciated for programmers with the code that may lead to another project instead of the one that was tasked.  Employers may not be okay with understanding if the educational needs is interfering with the project delivery. It is best to have the willingness to put the wider interests of the community. This pattern has changed my mind in approaching in what should I do generally with the knowledge that feels limited. I don’t disagree with anything since it does give a clear sense of being a good step towards in expanding your work to even teaching them to others.

Based on the content of this pattern, I would say this is an excellent read as a refresh in knowing what to do with limited knowledge on projects. This pattern has shown me ways to understand that self-awareness is one of the key things to be successful. For future practice, I will try to be more considerate with separating the practice material and then use those skills from it to give acceptable code for future projects.

Link to the pattern:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Knowing what to do with job titles

For this week, I have decided to read “Use Your Title” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one because there is a need to know what to do when seeing a job title that is given. I believe this will help me in making sure that when a job is given, it does not feel as stressful from just reading it.

This pattern starts off with the context of being hired or promoted to a position with a title as a result of dedication of learning. The problem is that the job title does not match in what you see for yourself. Because of this, there is the need to apologize or explain the difference from the skill level to the job given. By this explanation, the solution is to not let the title affect you. A job title is not meant to slow down the process or believe that the changes should be big to fully do the work. What is needed to be done is writing down a document that describes the job title and update it time to time.

From this pattern, what I found useful is the way to think about the job title as a way to help you instead of putting you down to stress. It is to make sure that the reflection shows what is it you really do and the skill level is accurate by your standings. Thanks to reading this pattern, I understand that I should be not intimidated by the job titles and instead show that I can improve my organization from one work to the next. Overall, I don’t disagree with anything of this pattern and this is because it helps me understand that the industry is very difficult to choose people that can help with the problems ahead.

Based on the contents of this pattern, I would say this is one that requires thinking from your perspective and it is effective by the end of it. This pattern has given me some ideas to approach in expressing the future jobs that might be needing clarification. For future practice, I should try to write down job positions that I found suited to my skill level and make it clear for myself so that it would not as bad at first glance.



Link to the pattern:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

A good amount of the Apprenticeship Patterns that I see when choosing one to write my blog post about have contexts, situations, and descriptions of people who are confident in their programming abilities, have a defined role on a development team, and are eager to get in the meat of the problem.

However, this context does not describe me very well. I am not confident in my abilities as a programmer yet, I do have an apprenticeship opportunity, but I have no defined role or job title, and I am nervous to tackle important complex tasks because of my inexperience. Thankfully I came across a pattern which describes my situation pretty well.

The “Sweep the Floor” pattern is for people like me who are unsure of the team and vice versa. People who want to contribute to the meaningful work in order to grow their skills and find a defined place on the team, but have only just began their position in the group. This context really spoke to me and pretty much read my mind without my thinking it.

The solution they provide is so remarkably simple that I’m surprised I didn’t think about it before to put my mind at ease. The authors suggest that in order to gain trust and find your place in the team is to in the beginning “volunteer for simple, unglamorous, yet necessary, tasks.” Hence the pattern’s title sweep the floor. If I can’t contribute to the main problem yet, then I can demonstrate my usefulness by handling tasks that are either tedious, not fun, or otherwise that the team does not want to do.

“Typically, you’ll want to focus on the edges of the system where there is less risk, rather than the core where there are usually many dependencies and lots of complexity”. This quote from the authors gave me a lot of clarity about what steps I can take in my internship to make myself known and actually be useful to the company.

However, they do highlight a risk about applying this pattern which I know all too well from other jobs I’ve had in the past; if you constantly are taking the ugly tasks nobody wants to do, there is a risk the group will want to keep you doing the boring, menial tasks. I have had this happen to me to the point where my coworkers would jokingly call me what translates to “Cinderella boy”. To mitigate this risk, the authors suggest to advocate for yourself and look for every opportunity to prove that you can produce quality work on a higher level.

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