Sprint 1 Retrospective

Wiki: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/wikis/home

For our first sprint, we mostly focused on learning what we need in order to build the inventory system such as Vue.js, Express, and API. I worked on researching Express by finding, studying, and recording resources such as Express tutorials and syntax guides among other sources. I also got in some practice writing and running Express JavaScripts, though not as much as I’d like to since there weren’t many examples I could find online. The team also created repositories for each component of the inventory system and a wiki where each member can place links to helpful resources. The link to the wiki, which include the resources on Express that I found during the sprint, can be found in the link above. If I were to describe what worked well, I wouldn’t know what to say since this sprint focused on learning rather than building. The same also applies for what didn’t work well since components can’t work incorrectly if you don’t build any.

Overall, I feel our team did fairly well considering one of our team members was incapacitated for a good amount of the sprint. We were able to finish tasks that amounted to 13 weight out of the tasks planned that amounts to 18 weight. That’s six weight for each remaining team member with one extra. The only thing I remember the team really struggling on was getting used to working in the structure of a sprint. So, I can’t really think of a way the team can improve outside of getting use to the workflow and structure of a sprint. It’s about as specific an area I can think of for improvement and it’s a pretty general area. And when I talked to my team in our sprint retrospective, they couldn’t think of much to improve on as a team either.

However, I can think of a bit more to say if we’re talking about what to improve as an individual. For example, the entire sprint I had a general feeling that I didn’t have a clear goal in mind outside of “study Express”. This probably resulted me to not have as fast of an output as I could have and also caused me to worry more that I wasn’t doing enough work. It’s also one of the major reasons why I couldn’t practice writing and running Express JavaScripts as much as I’d like to outside of the other reason I mentioned earlier. Another area I could improve on is summarizing the outcome of each task assigned to me. I say this because I didn’t realize I was supposed to do this until the meeting near the end of the sprint. But then again, this issue kind of ties back to what to improve as a team; getting use to the workflow and structure of a sprint. So, all I can really think on what to improve on as an individual is planning on a specific goal for each sprint to give a clearer direction and remembering to summarize the outcome of each of my tasks.

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

Boundary Value Testing & Equivalence Partitions

            I was looking for some materials to supplement the work we are doing in Software Quality Assurance and Testing (CS-443) and I came across a nice article from ReQtest entitled What is Boundary Value Analysis and Equivalence Partitioning? I found this to be a good supplement to our in-class activity on boundary value testing, summarizing some of the key ideas. It helped me nail down the concepts and is a nice, short resource for me.

            The article begins describing boundary value analysis. It highlights it is focused on, well, the boundary values, as, “for the most part, errors are observed in the extreme ends of the input values.” This directly relates to the topics covered in class, but is limited as it is mostly focused on single inputs, rather than testing for multiple inputs like we did in class. The article then provides a couple example for an input domain of 1 to 100. The exact boundary values would be 1 and 100, just below boundary values would be 0 and 99, and just above boundary values would be 2 and 101. This seems similar to robust boundary value testing. However, the article doesn’t consider multiple inputs, so there is no noting of nominal inputs or the single fault assumption, or worst-case boundary value testing. Nonetheless, I find it is a concise way of summarizing normal boundary value testing.

            The article then goes on to describe equivalence partitioning, which is the division of, “test input data into a range of values and selecting one input value from each range.” This goes more towards describing the domain of input values and somewhat alludes to physical and arbitrary boundaries. These are not described within the article, but are worthy of noting. The example given is again in the 1 to 100 acceptable range. The article states that one valid input class is anywhere within the 1 to 100 range, another is any value below 1, and the last is any value above 100.

            Together, these two topics do well to sum up the different ranges of inputs for boundary value testing, with equivalence partitioning touching on a little bit of worst-case boundary value testing. Overall, I thought this was a worthwhile article and was helpful. I can see myself returning to it when I actually am writing tests. Boundary value testing is quite useful in many cases, so it’s a topic I’m happy and interesting in learning more about and practicing.  

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

Create Feedback Loops

            The pattern called “Create Feedback Loops” in the Apprenticeship Patterns book focuses on finding ways to identify areas of knowledge which are lacking and how to overcome them. One point which I found summed up the learning pattern quite well was, “An apprentice probably shouldn’t work on not making mistakes early as much as they should be working out how to identify the mistakes you make.” In the context of feedback loops, this means that rather than skimming over the areas of understanding which are lacking, find someone to support the necessary learning and identify/correct mistakes, as this can provide a solid platform for learning. As for the areas which a “white belt,” such as myself, feels comfortable in, there should be people to feel comfortable with going to for review or correction. Essentially, you don’t know what you don’t know, which can be a huge hinderance to progress.

            I find this to be a particularly tricky learning pattern. Not that it’s hard to understand, but finding the proper resources and mentoring is not easy, especially during the current semester full of social distancing and online isolation. I think I’m very open to being corrected or shown a newer and better way to do the things I’m already good at, but finding someone to help me in the first place can be a struggle. I totally agree with the premise, but building a feedback loop is no easy task.

            I think incorporating this at a college level is definitely the best place to start, and I’m happy to be continuing my education at grad school as it gives me more time and opportunities to receive feedback in a lower pressure setting. Sure, my grades depend on my performance, but I don’t have a team/company relying on my work, and I don’t rely on the quality of that work for my well-being and forward progression as a professional. Also, having peers to work with and derive feedback loops from is better for starting as we are equals, rather than getting feedback from higher-level developers or something.

            I think one way I could implement this into my current learning is in the capstone. Perhaps there would be some time to do pair programming. I think this could be super helpful as it’s similar to working through an example problem, but I also have the support of a peer who could share knowledge and provide insight on how my train of thought is flowing, whether positive or negative. I’m happy to incorporate this pattern into my learning.

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

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Concrete Skills

For this week I choose to talk about the concrete skills pattern. I want to start it with a question that made an impression in me when I was reading it. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway.

Having knowledge is not the same as having the skill and practical ability to apply that knowledge. I believe that because I feel the pressure of it in the software class that I’m right now. Me and my classmates are working in a project that require from us to learn some new tools that we need to use. In the first month of it most of time I have read a lot about these tools and how they work but I cannot compare it with the knowledge that I will learn when I start to apply it. I always tell myself that practicing makes you perfect. That’s how you earn a concrete skill.

If you are not sure what concrete skills, you need in the book there is a suggestion for it. Collect the CVs of people whose skills you respect. You can either ask them for a copy or download the CVs from their websites. For each person, identify five discrete skills noted on the CV, and determine which of these skills would be immediately useful on the kind of team you want to join. Put together a plan and a toy project that will demonstrate that you have acquired these skills. Implement the plan. It is a good advice.

The last thing that I want to add is that is important to not get lost in the sea of knowledge. I speak from my experience. I have done that and is not the way to learn a skill.  Focus on one thing at the time. It is easy to want to know everything, but you would end up not learning anything.

References: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch01.html, Concrete Skills

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Your First Language

For this week’s blog post, one pattern that stood out to me the most was “Your First Language” I believe that the first language will be the most important one for our careers because for the next few years this will be the main language, we use to solve problems or practice to improve.  My first language technically was HTML that I learned back in a web design class at High School, but my first official language is Java from our CS 140 class. From that class and onward I have been using java for almost everything even for personal projects or in other classes.

As I was reading the rest of the article, I came across a sentence how the author states, “For several years, your first language will be the framework against which you learn other languages. The better you know your first language, the easier it will be to learn your next language.” I believe this is very true, your first language will be the foundation for the rest of the languages you will be learning. I remember when we had the CS 282 class in which we learned the C language, it was much easier for me to learn the concepts faster because I had a good understanding of the first language. Another concept that I thought was interesting is about how your first language can prevent you from learning and using other languages, the author states that “One danger of digging deep into your first language is getting stuck. It likely will remain with you throughout your career as your native tongue.” I agree with this statement, having good proficiency in one language can indeed prevent you from learning and using other languages. However, it is good to have a diverse knowledge of languages, especially in software development as each language provides an opportunity to solve problems using different paradigms.

I agree with all the statements about this pattern, it is important to look back and see that starting from “your first language” now we are all learning and getting used to different languages. Especially for me, I have been trying to learn Python since most of the companies use it nowadays and, R to analyze different types of data which I find quite interesting.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Your First Language – Apprenticeship Pattern

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.