Category Archives: Week 7

Creating Workflow Documentation, Testing Boards, and Examining Story Mapping Tools

Last week I had three main areas I wanted to focus on: Creating or at least starting documentation for the workflows, looking at the different story mapping tools, and testing project / issue boards on the different platforms. 

I started on Tuesday by creating the documentation for the different workflows. I began with creating setup instructions for how to create the shops on each of the platforms. Throughout this process I used the new Shop-Level Workflow story map that we created previously and I found that this was very helpful especially with having the user roles above each step so I knew who has to perform which actions. As I was creating the documentation I was going through the steps outline in the story map on each platform with my account and the shop manager account. I did run into some issues doing this such as on GitLab the selected permission level for the shop manager in the LFP group can’t add new members or create shop subgroups, something that the story map says the shop managers should be doing. I commented on this issue on the GitHub issue card and it will probably be something that trustees have to do instead of the shop managers. By the end of Tuesday I had created the initial setup documentation for GitLab Gold and GitHub Free. 

Wednesday I read Dr. Jackson’s reply about the shop managers issue and tested out his question about whether shop managers can create their own subgroups if a trustee creates a shop subgroup for them and makes the shop manager the owner. I found that this is possible and most likely will be the solution to this permission issue. I added documentation for GitLab Free which differs slightly as it would be a standalone group instead of a subgroup of LFP. I also separated the documentation so each platform has its own document instead of having all three together. I then copied the text over and converted the documentation to Markdown so it can be pushed to the LFP GitHub organization. After that I moved on to testing the issue and project boards on GitLab and GitHub. I did this by creating boards for each test group and adding some issue cards and moving them around. I found that basic board functions worked the same on all three platforms. The biggest difference between GitLab and GitHub is that you can create labels in GitLab and that cards can automatically move as labels change or the labels will change as a card is moved across a board. This seems very helpful as it moves the card on multiple boards that use the same labels, making organization more consistent. One problem I found was that GitLab Free has restrictions on the number of boards you can create which may be a problem with the workflow we’ve designed for the shops.Saturday I started testing out the different story mapping tools. I created a new Google Sheet and created a row for each one of the features that both Dr. Wurst & Dr. Jackson were looking for in these tools. I then went through most of the story mapping tools listed on the GitHub issue card. The tools I tested were: cardBoard, miro, LeanBoard, FeatureMap, Draft, Craft, and StoreiesOnBoard. Out of all of these I tested I found that miro and Draft had the best feature sets without having to pay to use the tools. Out of all of them LeanBoard was the only I found to have direct issue tracker integration (it is a GitHub marketplace app). FeatureMap had some good features such as being able to assignee cards to users which I think would be helpful for claiming stories in the shop groups. Currently it looks like Draft is still one of the best options so far for free. Next week I will start on creating documentation for the shop workflows and possibly continue with the story mapping tools.

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 – White Belt

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

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

Pattern 3 – The Long Road

I thought the title of The Long Road would make for an interesting pattern to read, so I chose it for this particular post. This pattern describes the path that a craftsman will have to take to become a master throughout their career. This is specific to becoming a master of software development and not particularly for what is traditional success in a career path that we as newly graduating software engineers are “expected” to follow.

For this reason, I honestly disagree with the general idea of this pattern completely. The pattern does make it clear that this is the path specifically for people whose life goal is to become the best at software development and does not seek anything else out of a career in software development. I don’t see this as the norm, or generally good advice in any regard. I also feel that it is important to state that this is merely my opinion, but also one that I strongly believe in. From everything that I read about software developers who stick strictly to software development throughout their careers, they often burn out but also feel that it is too late in their careers to do anything else. These are engineers in their late 40’s and 50’s who have been working for the same company for well over a decade and feel that their knowledge in software development is so narrow because of a lack of exposure to other tech and other business domains. While this is not always the case, this is just what I’ve read and have been exposed to personally.

The pattern also preaches how admiral it is to stick to this strictly developer mindset and how money and promotions should not be a focus for you. While I think that this is important to not be the only focus in a career, this is just silly. Promotions and salary should not be a measure of your success but they should be something we all seek, and a goal for people to strive for throughout their careers. The way this pattern is worded, it seems to try to even nudge readers away from positions like architects where you aren’t specifically writing code on a day to day basis. It wants readers to avoid big picture positions and exclusively stick to coding. There is always more to learn in coding and we should all do something we love, but coding should not be the only aspiration for our careers. For that reason, this article has not changed how I will approach my career, but possibly reinforced the goals I previously had.

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.

Craft over Art

This method talks about how indulging in your own artistic nature isn’t always the best option even if you think the product would turn out better if you did it this way. If you are being paid to build something that will solve a problem, this method of Craft over Art explains you need to really consider the situation at hand. In this method, the situation that is discussed is that you believe that you are able to do something outstanding and fantastic that will impress your colleagues. In this situation, you are building something for a user. You shouldn’t be indulging in artistic expression. A lot of the times when we are handed with a task, we can sometimes think about the most outstanding ways to do something, rather than just to get the task done. This can go two ways. Doing something outstanding for a task can be great and have it’s benefits, but what will it cost the effectiveness of it? On the other hand, we can do the task at hand and that will be that. We won’t be able to put any personal expression in it, but is that a bad thing? Of course it isn’t a bad thing. This method seems to be very similar to function over form.

It is a matter of situational awareness. This is something I really enjoyed from this article. Make more straightforward choices and do not try to “sugar coat” solutions. As soon as you start making unfavorable trade offs in certain scenarios, the outcome will not always be as you like. in other words if you want a straightforward answer, you should provide a straight forward solution. Even though this isn’t always the case, I learned that you should always try your best to just try and perform the basic tasks first without adding anything extra or unique. Quality takes time, but having the correct operations in a product is what can make all the difference.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Out of the Trenches

For this weeks blog post I will be looking into the pattern where are you told to “Stay in the Trenches”. Here you are advised to stay in the trenches even if you are offered release off the front lines into a much safer area. What does this mean in a modern day environment well you are on the “front line” to say of a programming job where you in a “grunt” position where basic programming duties fall upon you. One day you are offered a promotion where you will no longer be programming or doing to say the “dirty work” but in a more comfortable position. As it says in the pattern that most people always assume a promotion into management is associated with success. Thinking that if anyone is offered a position like that it’s a no brainier to take, meaning you are doing good.  The reason going into a management position where you are out of the trenches is that your mastery fades due to you not practicing it anymore. To counter this maybe working with your employer to find other rewards for your good work whether that be more pay or other nontraditional technical leadership roles. If your employer is inflexible then it is perhaps better to seek opportunities elsewhere. This pattern is very interesting to me as it makes a lot of sense to stay in the trenches for experience rather than dwindle. It also falls upon the person to decide whether or not they want to stay on the front line or go up the ladder into a management position.  Someone may feel more comfortable or even get more out of a management position instead of being a front line programmer. But again, that is all up to the individual and isn’t really predetermined in my mind. It all depends on what you want to do with your career and so forth so its hard to tell if I could see myself applying this method to a real life situation.

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

“Be the Worst” Apprenticeship pattern

I am writing this blog post about the “Be the Worst” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of the pattern, it is about trying to be in the presence of people with more experience than you so that you can learn from them, as opposed to being experienced already and not having the opportunity to learn from others. I can see this being a useful way to learn, but at the same time it does seem a bit selfish to put your own education above the quality of whatever it is you happen to be working on with everyone else. To be the worst may indicate that you do not actually belong where you are while you exploit the opportunity to learn. If this does not turn out to be a concern then it is still the case that you would not be performing as well as anyone else, so it may be discouraging to have a responsibility and not be prepared for it. Maybe being the worst is taking it to the extreme, but the more general goal of not being the smartest person in the room is a good way to learn from the person who does have more experience. I have been programming in the same language for the last decade and I now know everything about the language down to the exact differences between each version, and that came from being involved with other people who had knowledge that I did not have. Now there is no learning opportunity after having mastered this language, so since I have not nearly the same level of experience in any other language, it would be a significant learning opportunity to surround myself with experts in another language that I intend to become versed in. Since I have learned everything I needed to know to do the things I want to do, I have stopped learning at the same rate. Moving forward into a career, I expect it will become necessary to be just as experienced in more languages, so engaging with experienced programmers who use those languages will be beneficial.

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

Can you walk the walk?

For the seventh week’s reading, I chose to read the pattern, Concrete Skills. This pattern focused on the problem where you want to work on a talented team to learn more and improve yourself. However, the risk of hiring someone who may not contribute directly to the work and could be a baggage is too high. The solution to this is to “acquire and maintain” concrete skills. Examples of these concrete skills are as listed “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice”. The objective of these concrete skills is to present enough understanding of what you can do on day one. This will provide a chance where your likelihood of being hired is increased. However, when you are hired, you do not have to repeat the steps in the future because you likely have built a reputation and portfolio with your current job. As such, credibility has been established and should prove to future teams that you can be useful on day one.

What I found interesting about this pattern is that it mentions “getting past crude HR filters and managers who construct teams by playing buzzword bingo”. This relates to stories I heard of HR or managers who do not have enough knowledge to do the hiring but is placed in a position to do so. As such, they would deploy tricks and systems, or “filters” in order to find the people they need. Another interesting point brought up by this pattern is the action provided at the bottom. It states that we should note discrete skills that could be useful right away for the team that you want to join. I do believe this is a good strategy to be on top of knowing what skills you can bring to the table.

This pattern has not caused me to change the way I think about the intended profession because this also useful for other professions. The process of hiring people onto a team is always a risk in one way or another. Systems are brought into place because they want to avoid issues off the bat from a new hire, as such you have to demonstrate that you can do the job they expect of you.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Breakable Toys

The Apprenticeship Pattern “Breakable Toys” refers to a scenario where the environment you’re working in doesn’t allow for you to fail, stifling your learning because failure is often the best way to learn anything. According to the author, the solution to this is to create your own “breakable toys” from which you’re able to learn through catastrophic failure that won’t have an effect on anyone but you.

The thing I find most interesting about this pattern is some of the examples it suggests to do in order to create opportunities to learn. For example, creating your own wiki and adding more interesting features without being bound by existing implementations. I can see how working on something like this from start to finish would greatly improve your ability as a software developer.

It would be great if you could be satisfied with the amount of learning that you’re able to do within your current work environment, but given the fact that businesses need to make money to survive, taking risks and learning through failure is typically not something that can consistently happen if a company wants to continue existing. That’s not to say that mistakes should never happen, but it makes sense that a company would want to avoid them as much as possible in order to retain the trust of their clients. If someone were to make a costly mistake for a company, it should be used as a opportunity to learn from it, rather than just firing that employee and moving on.

I recall there being a disruption in Amazon’s S3 service causing around 3 hours of downtime being attributed to human error. One of the employees on the S3 team was debugging an issue when he accidentally removed a larger set of servers than he had originally intended, all due to a small typo in his input. Regarding this incident, Amazon stated: “We will do everything we can to learn from this event and use it to improve our availability even further”, acknowledging that they would seek to prevent it from happening in the future. I would imagine that the employee who made the mistake may have learned a lot about the potential effects of something that seemed so insignificant.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations || S.S. 7

Sams Ships (9)From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.

The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.

I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.

The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.

Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.

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

Apprenticeship Patterns – Retreat into Competence

The Retreat into Competence pattern describes what you should do when you feel overwhelmed with how little you know. Every apprentice will eventually feel ignorant or incompetent compared to the craftsmen they will meet. This should not be a reason to worry as it is a normal and inevitable phenomenon. However, when it happens you should retreat briefly into your competence. What this means is to work on something that you already know very well in order to regain some confidence and realize how much you’ve learned since you began your journey. This pattern is relevant for people who are struggling or stretched beyond their ability. If you find yourself in this position, you may need to take a step back before you can continue going forward. However, it is important to realize that this pattern is only a short-term fix so that you don’t surrender to the comfort of working only on things that you know very well.

I enjoyed reading this pattern and found it to be useful because it is applicable to everybody at one point or another. Reading this pattern reminded me of impostor syndrome, which is when somebody persistently feels like a fraud despite evidence of their competence. I think this is something that a lot of computer science students feel since there is so much information to learn and the technology and tools we use are always changing. I think that this pattern is great advice for someone who has a case of impostor syndrome or simply feels overwhelmed by their work. Taking a step back and working on something that you’re comfortable with will allow you to clear your head and regain your composure. It is important to remind yourself from time to time how much you actually know and realize that many things you do easily now once seemed impossibly complicated. Retreating into your competence will help you spring forward when you go back to new challenges. I’m glad that I read this pattern as this advice will definitely help whenever I feel lost or overwhelmed in the future. I now know that in situations like that it will help to retreat into competence for a little while.

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