Sprint #1 Retrospective

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Use the Source

The pattern I am writing about today is use the source. The problem is that an apprentice can be using bad habits, but he will not know if he is not reading someone else’s code. The author specifically mentions that the apprentice should look at the source code of the tools he is using. One reaction I had to this was an interview experience I had. I solved a coding problem, and my interviewer asked my what the time complexity was. I was using the Java library method Arrays.sort() but I did not look up what the time complexity of that library method. I eventually figured it out. But it made me realize that I should know more about the libraries that I am using in my code.

The author also mentions the importance of refactory code. When reading somebody elses codebase. The craftsmen should look for ways to improce the codebase, and understand why the project is built in the way that it was. This experience could also lead to apprentice refactoring his own code. The author also mentions code reviews. This is something I am really looking forward to as a professional Software Engineer. When we learn the fundamentals school, we are usually working alone, or in a small group. But in the professional world, we collaborate. This will give myself, as an apprentice an oppurtunity to learn from the source code of my coworkers. Open source is another great way for new craftsmen to gain this experience.

The author recommends that the apprentice contribute to open source, so he can read source code, and learn from it. He also mentions that if a programmer can understand a program from the source code, that means he is a good craftsmen. This makes a lot of sense to me, and understandy the code base is typically what a programmer does on their first day or days on the job. In order to contribute to a project of any size, the craftmen should know what the code currently does. So I agree that using the source is an incredibly important skill.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Reflection on The Deep End Apprenticeship Pattern

The Deep End is an Apprenticeship Pattern that encourages software apprentices to take risks, to challenge themselves, and to take opportunities they may not normally take. It makes sure to warn readers that this does not mean that they should jump into things that they are completely unqualified for, or do things with no thought or preparation. However, it is saying that we should be willing to take risks in order to further our learning, and should be willing to try things, even when there is a chance of failure.

I think that this pattern offers a very good way to ensure that we continue our learning, as stagnating at one job, on one project, is no way to continue our lifelong learning, tying into the Long Road apprenticeship pattern that I have discussed previously. We have to be willing to take risks and risk failure if we want to move forward (the same principle used in the Breakable Toys apprenticeship pattern). I also really liked the idea of keeping some sort of record of your own accomplishments, some archive of code we’ve written previously, how long it was, how many group members you worked with, and how large the codebase was. With this sort of history, not only can you track your progression and always look for bigger things and more learning opportunities, but you can also have a record of what you have done that you can go back to in the future, which also follows principles laid out in the Record What You Learn pattern. Being able to go back and see how you’ve changed can be an invaluable tool, and if you don’t risk failure, you will never be able to progress past a certain point.

This pattern has presented a great strategy as to how to keep track of my accomplishments and is great motivation to actually take risks in my professional career. I want to continue to grow my skills and grow, and unless I am willing to fail, I will never get anywhere. As for something I disagree with from the pattern, I guess the only thing I really disagree with is the idea that line numbers and team sizes are the metrics that your career should be based on. I think they can be useful to keep track of and consider, but in the pattern, it is kind of implied that these are the main metrics to measure your performance, and I’m just not sure they are the best ones. Regardless, I don’t think that invalidates the value of the point of this pattern.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Study the Classics

                Often when we as people begin our education in any field we tend to lean either towards readings and studying our predecessors, or jumping into a more practical hands on approach. I myself have often leaned towards a hands on approach to learning. I find myself learning best when thrown into real work rather than boring myself reading textbooks and taking note of the though process of our predecessors. This is exactly how I have honed my craft for a majority of my time as a software craftsman so far. While this method of studying has its merits, it has also hindered my growth by minimizing exposure to the thoughts and theories of others before me.

                Oshineye and Hoover go into detail within this section explaining how and why we ought to delve into the books written by those who came before us. Classics such as Rodney A. Brooks’ Robust, Layered Control System for a Mobile Robot” and Valentino Briatenberg’s “Vehicles: Experiments in Synthetic Psychology” have long been used in the world of robotics and for good reason. They present a series of theoretical ideas and thought processes that yield results that may have otherwise been unexpected. Briatenberg’s Vehicles guides people that are new to robotics into a mindset that inspires out of the box thinking.

Briatenberg’s vehicles are examined not for their capability, but for their behaviors and different configurations exhibit different behaviors. Along with this, one might read Brooks’ work and apply the idea of subsummation to one of Briatenberg’s vehicles. Starting with simple behaviors that are subsumed by higher level thinking can be applied to vehicles to ensure they at the very least can perform certain task such as avoiding collisions with objects while carrying out their main goal.

The goal of these theories and mindsets presented by classic literature is the same as the very text put together by Oshineye and Hoover. It will not directly help with your skillset as a software craftsman, but it can lead to utilizing what you do have in new and interesting ways. An adherence to a certain design philosophy and being willing to experiment in ways that may not have been directly taught to you is important in forwarding your own skills as a craftsmen as well as forwarding the industry when one becomes a master craftsman.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Expose your ignorance

I was reading chapter two on “Expose your ignorance” and got so caught up to it. When working with my team this semester, if there is something that I learned is to ask questions and not be afraid to show my “ignorance” like the book calls it. Sharing and exposing myself helped me understand that we should never feel less smarter than others just because they know better than we do, because learning and knowledge is open to everybody and it is not impossible to reach their level or even better, surpass them.

It can always happen to be caught up in the middle of a project that we do not know anything about. Some people might, and some might not. In that situation, we should let our ignorance awaken our curiosity so we can easily ask questions. People in general hate being seen as ignorant because we always want to show that we have knowledge, experience, skills required for the position or project. So, because of that, we find ourselves faking our knowledge and skills just to impress others. But software development does not work like this, it’s either we know or we don.t because the more we try to hide our ignorance, the more we’re sinking ourselves; And there will be a moment when it will be hard to get out of that place we got stuck on our own.

I love what the author said about the runner: ” She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end”. Craftsmen need to have the courage and humility to set aside their expertise and wear the “white belt” as they pick up an unfamiliar technology or learn a new domain.

One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it. As, software developers, we should not run away from knowledge and being shy or scared to expose our ignorance is not doing anything god to us. I am proud of asking questions and showing that I don’t have or I barely do have knowledge about a certain domain. And it is something that I do even with my team. When I am not familiar with something or don’t know how to do it, I just ask and the one that have the answer will provide it to me and help me understand. This is how I increase my knowledge and skills.

This is where “The long road” will take place. By exposing our ignorance, and then confront it. We will spin the missing threads much more quickly than we will by faking it in order to appear competent. And let’s remember that while we are exposing our ignorance, we are also exposing our team to our learning ability.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Be the Worst

When reading this chapter, I found it challenging because I asked myself who actually wants to be the worst? I tried to project myself and put myself in that specific position and I found it very hard to do. However, after second thoughts, deep reading, and analysis, I am very impressed and humbled by the content of this book and this chapter. They say: “You have to be the best”, “You have to master what you do”, “You have to always be the head”. However, we never hear the opposite of those sentences. We never hear: “Be the worst”, “It’s okay to start at the end of the queue”, “We all started from the bottom”. It is discouraging to know that nowadays when working as an apprentice, the expectation and the pressure is greater than the willingness to be understanding and people tend to forget that they have been there once and act as if they were the best from the start.

 There are points the author mentioned that I found important when being the worst in a team. He talks about couple of risks associated with it like brining the team down, the risk of getting fired when falling behind or inability to catch up and feel bad about ourselves. This part tells us that it is a great thing to accept being the tail of a lion. However, it comes with some risks that require hard work and regularly updating ourselves on where am I? Am I making progress? How much time the team is granting me and what happens if I don’t meet specifications? Being the worst is just a way to make us confident in the lion’s den, but we must really be motivated to learn, we must show the desire of doing better, bringing ideas that get us noticed with time.

The last interesting point the author mentioned was reaching out, asking to join a team and observe the team’s dynamics and ways of operation. For me, this is great because it shows the desire for personal growth and the team might be motivated to take you in because you have shown initiative and interest. I feel more confident now to “Be the Worst” in a team of professional software developers because that position will unleash my confidence, allow me to be myself, learn and improve at the same time in my craftsman’s journey.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Post #3

“Craft over Art” was a great apprenticeship pattern to read about and I found myself relating to the ideas with my own work. A craft is an art that has functionality – a painting you can look at and hang on the wall, but a table or couch provides you with functionality. Good software should be written so it looks good and performs is purpose.

When constructing a piece of software it’s important to look at the tools we are going to use. A programming language, a laptop or PC, a good IDE, Unit Tests, and an outline of what the system should look like. No one starts a craft such as furniture building by grabbing a piece of wood and one by one assembling the project. They first create a blueprint with measurements, a model, and gather all necessary materials before they begin following their blueprint. I enjoy this analogy because I’ve made this mistake in the past when writing code. I would usually go line by line and fix mistakes one by one as I find them. This way of writing code is quite slow and it can be easy to drop a project because it seems too large or difficult. Now I follow a plan when I write my code and even if a method I’m working on has issues, I’ll move on to the next method. I’ll also create my methods before hand and leave them empty until I begin working on one to ensure I’m still following the system I designed for the project.

Art is also an important factor of crafting. If my code is messy, unorganized, and does not have good flow it will be incredibly difficult to refactor the code later on. When we enter the workforce it’s unlikely we will be writing a piece of software completely on our own. Your code will be combined with dozens and hundreds of other programmers work and it’s important that the system works well together.

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

Apprenticeship Patterns Post #2

This week I really enjoyed reading “The Long Road” from the apprenticeship patterns. In computer science, often many of us feel like we need to learn as much as we can in the four years we are getting our degree and then go out and apply that in a full time position. The reality is that we only learn the basics in our undergraduate degree – enough to gain strong logic and critical thinking skills and enough to get that first job. The real learning comes from actually working as a software developer and there is no “end” to how much you can learn in software engineering.

The tech industry is constantly evolving and every two years it seems like there is a shift in how technologies are used or new technologies are introduced. A software engineer cannot stop learning once they have learned everything it takes to perform their programming job well. Skills they learn in that job will always carry over, however they may end up working with completely different or newer frameworks and they have to start the process of learning again. That’s why as software engineers we should have the mindset of “always learning” rather than “learning something new when needed to”.

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

Sweep the Floor

I had the opportunity to participate in a formal summer program to learn how to make simple websites. When I was twenty-two years old, I was hired and brought me back every summer and winter vacation during college. I didn’t know anything about how to make a website when I started my first project. For fun, I wrote some code to make small programs and scripts. There were few places where I could add value to the company’s operations when I first started my website for that program. I couldn’t build a website, and I couldn’t possibly teach people how to do so.

Many of the successful Programming leaders were hired by the company to teach a PHP course at the time. Since I was not good enough, I decided to start working on other tasks. I’d also set up the computers, install the appropriate software for the exercises, and clean up the space. These duties helped me gain confidence in my ability to contribute to the team and the firm. Even though I was having difficulty learning to code, I was still able to contribute with specialized talents and duties that required less competence.

As I was continuing working on the program, I was gradually given more technically difficult jobs. They were, however, frequently the ones you’d allocate to the lowest man on the totem pole. Moving servers, setting out backup methods, and updating material on the website are all tasks that need to be completed. These assignments allowed me to achieve little triumphs at a time when it was difficult to achieve them by creating code.
Playing the part of a typical program taught me humility and respect for experienced trainees. I decided to choose to sweep the flooring partner because it resonates with everything in my previous job experience.

It’s true when Paul Pagel described young apprentice like One of the pillars of a successful apprenticeship is humility. Humility, when combined with ambition, will keep you focused and moving in the right route. You risk prematurely declaring your apprenticeship complete and missing out on critical lessons if you don’t have them. Perhaps you’re pleased with a large project or subsystem you’ve completed and believe it demonstrates that you’ve progressed to the level of journeyman. Perhaps. Have you, on the other hand, delivered something important across several platforms? How much more would you learn if you attempted to learn a new language? The natural tendency of any ambitious apprentice is to attempt to beat the clock and become a journeyman as soon as feasible.

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

Learn How You Fail

According to Atul Gawande, Software is not a product, it’s a medium for storing knowledge. Therefore, software development is not a product-producing activity, it is a knowledge acquiring activity. Knowledge is just the other side of the coin of ignorance, therefore software development is an ignorance-reduction activity.

The value of failure-based learning is undeniable. Organizations that excel at it, however, are extremely rare. This disparity is not due to a lack of desire to study. Managers in the vast majority of the companies such as pharmaceutical, financial services, product design, telecommunications, and construction firms; hospitals; and NASA’s space shuttle program, to name a few—were genuinely interested in helping their companies learn from failures and improve future performance. They and their teams had spent many hours on after-action evaluations, postmortems, and other similar activities in certain circumstances. But, time after time, we noticed that arduous efforts yielded no tangible results. The reason for this is that those managers were approaching failure incorrectly. 

As a former manager myself, I always thought about what my boss would say if I did not meet all the requirements left out for me to accomplish in a tiny window. I overstress myself to succeed, and by trying too hard, I kept getting crashed over and over until I realized that was not the best approach. I never got the results that I was looking for with that mindset. Failure is hard to accept because we usually associate it with a negative aspect instead using it to learn and produce success for tomorrow. As I was told if you never fail, you don’t know what success is. 

As Phillip Armour, in his paper “The Five Orders of Ignorance,” As I paraphrase it; Continuous learning can either be a blessing or a curse. Learning a new skill may be excruciating, especially when done under duress and with no supervision. However, the software developer, like the athlete who must deal with bodily fatigue after intense workouts, must deal with the mental dissonance that comes with learning something new. That discord might be viewed as a positive indicator of growth. On the surface, self-reflection, detecting failure through feedback loops, and discovering your deficiencies all appear unpleasant, yet these patterns are helping you lessen your ignorance. The alternative is to concentrate solely on what you already know, but this is not the path to mastering software craftsmanship; rather, it is the path to specializing in a single field. 

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