Author Archives: kylequad

Apprenticeship Patterns: Draw Your Own Map

The final Apprenticeship pattern I would like to discuss is titled “Draw Your Own Map.” This pattern is written for developers who feel that none of the career paths their employer provides is a good fit for them. It reminds us that it is up to ourselves, not our employers or anyone else, to determine what the next step in our careers should be. The pattern recommends that we develop possible career maps made up of small, specific steps we want to achieve. If our maps conflict with our employers’ expectations, we should simply seek out other opportunities that better fit. These maps are never set and can be altered as our circumstances change, but they will always help guide us towards the career we want.

As I’ve gotten closer to finishing college, I’ve become increasingly worried about my future. I don’t have any definite goals or plans for my career, and I don’t know how to create these plans or put them into action. I chose to read this pattern because it seemed like it might help me figure out a plan for myself. After reading the pattern, I at least think it provides some useful advice. I like that the pattern emphasizes the importance of achievable steps and advises against high-level goals. This makes me think differently about my lack of long-term goals, as I now understand that it is easier to succeed by planning short-term steps. Additionally, the pattern helped me realize the importance of following my own plan instead of one set by my employer. I have had miserable jobs in the past which I felt trapped in due to a sense of obligation towards my employer, but reading the pattern pattern assured me that I do not have this obligation.

One problem I had with this pattern, which also applies to the other patterns I read, is that it assumes the reader is already employed as a developer. For this reason, the pattern doesn’t quite provide the help with actually creating goals that I was hoping for. Despite this, I think the pattern gives a crucial piece of advice in the second paragraph, where it emphasizes the importance of taking a first step. Even without a clear plan, taking a step is crucial for building momentum that can lead to success. Despite not having clear goals for my future, I already know I want to work on regaining my passion for programming in the short-term. After finishing college, I should focus on pushing myself to take this step. Hopefully, I will develop the motivation to keep programming and eventually be able to draw a map for myself to follow.

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

Sprint 3 Retrospective

I think Sprint 3 was the most effective sprint of the semester. I think the success of this sprint was largely due to the team improving our GitLab use and our communication with each other. Unlike the last sprint, the new issues we put on our board for this sprint were specific and clearly defined. Most of the new issues were created with a new template that included sections about how the issue would be worked on and what would be produced as a result. This made it much easier to understand what needed to be done, helping us make more progress. I also think we were more open to communicating with each other, both during our meetings and while working separately. We spent more time in our meetings answering each other’s questions and sharing our progress, which personally helped give me a better understanding of things that confused me as well as the overall state of the project. We were also more active on GitLab outside of our meetings. Every team member participated frequently in discussions on issues and merge requests, which helped us complete issues and merge changes efficiently.

Although this sprint was very effective overall, we still faced a few problems. I think the main troubles we encountered were coordination and time management. Although we were all more active on GitLab, we didn’t know exactly when our teammates would be active or what they would be working on. In my personal experience, this made it difficult to make progress sometimes. Whenever I needed input from a teammate, I would simply wait to ask them in the next meeting because I didn’t know if they would be available to discuss on GitLab. I think coordination issues such as this led to problems with time management. Since our progress was slower than it could have been, we ended up having many issues left unfinished in the last couple of days of the sprint. We did arrange a last-minute meeting to work on these issues, which I thought was effective, but if we had managed our time better this would not have been necessary.

To improve as a team, I think we could’ve focused on our time management. This would’ve been difficult, since we all had different schedules and other classes to work on, but there are a few small changes I think we could have made to make coordination easier. First, we might have tried setting due dates on issues. I think this could have helped us manage time better to avoid having issues pile up at the end. It may have also increased collaboration outside of meetings by encouraging multiple team members to work on each issue at once. Also, I think we could have tried having more meetings outside of class. These would’ve been difficult to arrange because of our different schedules and may not have been necessary, but the one we had this sprint was extremely helpful. I think trying to have more meetings where we work together on issues would have helped the team get more done.

To improve as an individual, I think I should continue to work on my communication and participation. As I mentioned earlier, I frequently avoided commenting on GitLab, mainly because I didn’t want to disturb anyone when they weren’t available. This caused me to miss out on important discussions, such as those that took place during planning and on certain merge requests. I started making an effort to participate more during the end of the sprint, but I still found it difficult to do so as my other classes demanded my time and drained my motivation. If I am able to participate more in future projects, I would like to focus on contributing to discussions more and keeping myself informed. I need to stop stressing over my comments so much and just focus on saying what I need to.

Links to my GitLab Contributions:

These are issues I directly worked on, where I left comments about my progress and had discussions with teammates:

I also helped with resolving the Angular Testing issue, which was left over from Sprint 2:

These are merge requests I created to merge branches I worked on, where I also worked with teammates to resolve problems before merging:

I also took part in discussions on these merge requests:

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

Apprenticeship Patterns: Concrete Skills

The next Apprenticeship pattern I’ve decided to discuss is titled “Concrete Skills.” This pattern is targeted at developers who wish to join a talented team in order to find better learning opportunities. The problem here is that professional development teams have no incentive to hire new developers who cannot immediately contribute to their work. The pattern explains that, in order to acquire a position in such a team, a developer should develop concrete skills. These are specific skills that a developer is particularly experienced with, such as working with a certain language or development framework. By knowing and being able to list their concrete skills, a developer can help themselves gain the trust of professional teams and begin a career as a software developer.

I chose to read this pattern because I have often experienced fears regarding my ability to find a career with my current experience level. I frequently feel that my current skill set is not good enough for me to be useful on any professional development teams. I think this pattern has helped clarify my reasoning behind these fears. Development teams focus on concrete skills when determining who to accept, while I have always been focused on my overall skillset. This perspective has caused me to focus on what I don’t understand when looking over the work of experienced developers, which has only served to discourage me and make me feel inadequate.

In order to get a start as a software developer, I should focus on determining what my concreate skills are and solidifying them. This pattern helped me understand that concrete skills are more important than overall experience to teams accepting new members. For this reason, I should focus less on what I don’t know and how I compare to other developers, and I should instead concentrate on the skills I already have. In the time I have been pursuing software development, I’ve become skilled at programming in many languages, especially Java. I’ve also learned to use tools like Git and frameworks like Angular, and I’ve done lots of work with creating GUIs. These are just a few of my concrete skills, and I’m sure many of them would be useful on a development team. If I start concentrating more on solidifying these skills and less on grasping at skills I don’t have, I could likely put together a list of concrete skills that would help me find a place on a professional team.

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

Apprenticeship Patterns: Record What You Learn

Today I have decided to post about the “Record What You Learn” pattern. This pattern is targeted at developers who find themselves repeatedly learning about the same topics. Some lessons just never seem to stick in their memories, and they often forget the details of their past works. According to the pattern, simply recording what you learn in a journal, wiki, or blog can be an effective solution to this problem. Keeping such a record not only helps reinforce old lessons, but it can provide us with a powerful tool for drawing new connections in our knowledge and developing new lessons to pursue. A record also helps us understand how we came to develop our skills and allows us to easily share our experiences with others.

I decided to read this pattern because I often find myself repeating old lessons. Many programming projects I have worked on, both on my own and for school, have required me to reapply topics I worked with in the past. More often than not, I struggle to remember all the details I need and have to search for tutorials or guides to refresh my memory. In fact, my list of bookmarks in my browser is crowded by tutorials that I have needed to return to many times. Whenever I find myself searching for help with an old skill, I just get frustrated with myself for having a poor memory. I never even considered keeping a record of my lessons to make them easier to remember.

Reading this pattern has definitely changed my perspective on my troubles with remembering old lessons. I may be having these difficulties because I have not done anything to reinforce my lessons, and not simply because my memory is bad. I definitely think keeping a record in a journal or a personal wiki would be helpful to me. Instead of searching through my list of bookmarked tutorials for hours searching for one bit of information, I could simply refer to my own record to find what I need quickly. A record would also make it easier to reflect on my past lessons, which I think could help motivate me to continue learning new things. In addition, a record might make it easier for me to help others learn skills, as it would allow me to look back on how I learned those skills myself. I was honestly surprised by how useful recording what you learn can be, so this pattern has made it clear that creating a record of my lessons would be worth doing.

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

Apprenticeship Patterns: The Long Road

The Apprenticeship pattern I would like to focus on this week is “The Long Road.” The pattern explains that becoming a master of software development is a lifelong endeavor. This conflicts with our cultural obsession with quick results and rapid progression. Developers who wish to become masters need to understand this and learn to focus on long-term goals to help them build their skills over time. Mastering new skills can take many years, but preparing ourselves to dedicate our time towards learning such skills can open up many new possibilities. The pattern emphasizes that The Long Road towards mastery is not for everyone and that there are plenty of other paths to take. However, choosing to aim towards mastery with this path enables us to better understand the fundamentals of the craft, helping us maintain our abilities in a field that is constantly changing.

I chose to discuss this pattern because it has been referenced by several of the other patterns I have posted about. After reading through it, I definitely understand why The Long Road is so important to these other patterns. The book is targeted at those who wish to master software craftsmanship, which requires a lifelong dedication to development and programming. As such, the other patterns might not be as effective for a reader who lacks this dedication or has different goals. Reading this pattern has made me more aware of the necessity of lifelong dedication on the road to software mastery. It has also made me question if I have this dedication myself and if this path is really the right one for me.

I’ve never really had an ultimate goal in mind while studying software development. I know I enjoy programming and want to learn more about it, but I don’t know how I want to apply myself professionally. The Long Road sounds quite appealing in some aspects. It would allow me to focus on programming instead of taking higher-paying jobs which don’t interest me. It would also allow me to use the skills of others to set goals for myself instead getting discouraged by them as I often do now. However, the time and dedication required for The Long Road are frightening to me. Because of my recent struggles regarding my passion for programming, I am unsure if I would have the motivation to continue learning new software development skills for the rest of my life. I think, for the time being, I should focus on nurturing my passion for programming. This will, hopefully, help me decide if I should pursue a different path or if I am ready to walk The Long Road.

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

Apprenticeship Patterns: Sustainable Motivations

This week, I would like to discuss the “Sustainable Motivations” pattern. This pattern explains that professional software developers often must work on messy projects with unclear specifications and conflicting demands. Such chaotic projects are exhausting and frustrating to work on, which can cause developers to lose their motivation to pursue software craftsmanship. The pattern’s solution emphasizes that developers need motivations that will adapt to the difficulties presented by these projects. Developers should have multiple sources of motivation so that, when is damaged by an infuriating situation, they will have other reasons to push through their frustration until the situation gets better. The pattern recommends writing down our different sources of motivation to help us understand which are the most important. When we find ourselves loosing the desire to continue developing software, we can refer back to this list to remind us why we should continue.

As I have explained in my past couple posts on Apprenticeship Patterns, I have really been struggling with motivation over the last few years. Many software-related projects I have worked on during college have been exhausting, frustrating, or unclear. I found it difficult to complete such projects because I simply couldn’t find the effort to work on them. This pattern resonated with me because it focuses on this very issue. I especially relate to the second bulleted example given by the solution, which describes a developer whose main motivation is their enjoyment of programming. For me, this was the main reason I decided to pursue software development, and it has been discouraging to feel that enjoyment dwindle.

However, the developer in the example continued programming due to financial motivations despite a loss of passion, and they eventually regained their love for programming. Similarly, I have continued to pursue software development because of my desire to finish college. I’ve never really considered my education to be a reason to program, but in retrospect it has clearly been my main motivation for the past several years. Clearly, reading this pattern has helped me think differently about my motivations. I’ve always thought my enjoyment of programming was the only motivator I had, but I now realize that other factors, like finishing college and gaining experience, have actually been motivating me more. Hopefully, these other motivators keep pushing me to continue programming until I am able to regain my passion for it.

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

Sprint 2 Retrospective

Overall, I think the second sprint was somewhat less effective than the first for my group. Unlike the previous sprint, we had some problems that prevented us from completing everything we expected to. I think the main issue we had was a lack of clarity regarding our goals for each issue. We have not been declaring a ‘definition of done’ for our issues, so we didn’t always know what we were working towards. The biggest example of this was the “Design frontend architecture” issue. We never had a plan for what our design needed to include or how it should be made, which caused this issue to get stuck in the ‘needs review’ column for most of the sprint as we tried to work out the confusion surrounding it. Additionally, I think many of our issues were too broad. For example, we had single issues for creating a database and implementing our UI which could probably have been broken into more specific tasks. We definitely underestimated the complexity of these issues and the time they would take, which made them difficult to complete during the sprint.

Despite the problems, there were some aspects of the sprint that worked well. I think our communication has started to improve since the last sprint. GitLab was used for discussion outside meetings more often, especially on the merge requests. I also thought that our in-class discussions were more effective. We did a better job using our time together to discuss specific problems instead of working on our own, especially after the transition to online meetings. Although the lack of clarity in our issues made the sprint difficult, it forced us to communicate more effectively so that we could help each other understand what needed to be done.

To improve as a team, we definitely need to be more specific with our issues. This would involve splitting broad issues into more specific tasks and creating a ‘definition of done’ for each issue so that we all know what to work towards. We should all look over our proposed issues to make sure they are small enough tasks, and we should add a definition of done that we all agree on to each issue. Ideally, this would be done during the planning meeting, though we can surely continue to fine-tune our issues during the sprint. If we are able to accomplish this while maintaining effective communication, I think our final sprint will be far more effective.

Individually, the main improvement I think I need to make is to keep better track of my teammates’ progress on their issues. So far, I have been completely focused on completing my assigned issues. As a result, I could never get around to familiarizing myself with the work completed by my teammates. This prevented me from reviewing their issues and approving their merge requests. It has also made me generally uninformed about the state of the overall project and where it is heading. I feel like I have not been contributing enough to the team, since I have been so focused on my own work. For the last sprint, I hope to participate more in reviewing my teammates work to both help the project progress and to keep myself informed. I think that making our issues more specific will immensely help with this. Having more manageable and specific goals would likely reduce my anxiety about completing my issues and allow me to spend more time assisting my teammates.

Links to my GitLab Contributions:

This is the main issue I worked on, where I learned about Angular testing. I left several comments informing the group of my progress and providing links to useful resources I found.

This is a repository I made to share my project where I experimented with Angular testing with the team.

These are issues that the entire team worked on. I left comments on some and moved some across the board.

I left a comment on this issue to inform the group of a meeting I had with the other teams in class.

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

Apprenticeship Patterns: Nurture Your Passion

The next Apprenticeship pattern I would like to discuss is titled “Nurture Your Passion.” This pattern is targeted at software developers whose work environments drain them of their passion for creating software. It emphasizes that a passion for software craftsmanship is crucial for improving our skills, and that we should take steps to protect our passion if we find ourselves in such an environment. The pattern suggests several techniques we can use to strengthen our passion for software development. These include investing time into enjoyable projects, joining groups that focus on our interests, and changing our work environments.

As I mentioned in my post on “Breakable Toys,” I have struggled to stay passionate about programming since I started college. When software development became the focus of my education, I stopped working on personal projects because they took time away from more important (yet far less enjoyable) class assignments. This really damaged my ability to enjoy programming, and I think that following this pattern’s tips could help me regain some of my passion. I already expressed my desire to start working on personal projects on my own time again in my “Breakable Toys” post. While this pattern recommends this once again, it also provides several new suggestions that I think could be just as useful.

The pattern first recommends focusing on enjoyable topics while working as a way to make work less draining. This suggestion changes my perspective on how I should go about my work, as I have generally not prioritized my own interests during assignments. For example, I have recently been working on testing for my group’s project in CS-448, which has been exhausting for me since I dislike writing tests. I might try to contribute to more interesting aspects for the remainder of the project so that I can be more invested in it. The pattern also recommends joining groups and reading books that focus on topics of interest. Groups haven’t really worked for me in the past, and I’ve never been a fan of reading, but knowing that these options could help nurture my passion might make them worth trying. Finally, the pattern recommends having a list of positive ideas to talk about whenever work conversations become exhausting. Although I’m not great at conversation, I think this might be an action worth taking. Even if I never have a work environment that completely engages me, talking about my interests with others might be enough to keep my passions alive.

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

Apprenticeship Patterns: Breakable Toys

The second Apprenticeship pattern I would like to discuss is titled “Breakable Toys.” This pattern is based on the idea that experience is built upon failure. Because many software developers work in an environment that does not allow them to fail, they have trouble learning more about development and improving their skills. This pattern encourages developers to work on smaller projects outside of their work environment, giving them a way to experiment and make mistakes without the usual consequences. Creating these “Breakable Toys” allows developers to learn new things about their usual tools while working on enjoyable projects, which helps them gain useful experience that they could not have acquired in their usual work environment.

I chose to share this pattern because of my own experiences working with Breakable Toys. When I was first learning to program in high school, I would always spend time outside of class working on my own projects. My passion for programming was at its height when it was still new to me, as I constantly wanted to learn more about it. Since starting college, however, I have felt that passion gradually fade. Programming became a central focus of my education, especially after transferring to WSU for Computer Science. My fear of failing in my classes caused me to associate programming with stress and anxiety instead of passion and enjoyment. I eventually stopped working on Breakable Toys, as my attention was completely directed towards classwork and I felt that personal projects were a waste of my time.

Reading this pattern has helped me realize how important my Breakable Toys really were. They contributed to my learning far more than any classwork ever has. They allowed me to figure out new skills at my own pace and let me experiment with them without worrying about failure. For example, due to my focus on Game Development, my Toys helped me learn more about programming graphics than my classes have and they helped me understand the basics of how game engines function by programming them myself. This pattern has made me realize that my personal projects were never a waste of time, as they helped me learn new skills quickly and enjoy myself while doing it. Going forward, I hope to get back to working on Breakable Toys outside of my work environment, as I now realize how important they are to my learning.

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

Sprint 1 Retrospective

I think that the first sprint went well overall. My teammates and I completed all of the issues we assigned ourselves during the planning meeting, so the sprint was definitely a success. We accomplished this thanks to our effective use of the GitLab issue board. For the most part, our issues were clearly defined by their titles and labels, which helped us understand what needed to be done. Additionally, we assigned different team members to different issues, which made it easy to track our own issues and the progress of each other. The issue board also helped guide our in-class discussions, as the column-based structure allowed us to quickly select doing issues to discuss their progress and evaluate the needs review issues as a group before moving them to done. Finally, the board gave us a platform for discussion outside of class with each other and with other teams. We successfully used this to clarify what we needed from other teams and to answer questions among ourselves.

I think the main issue among the team during this sprint was communication. We did not always keep each other informed about our individual tasks, which sometimes made it difficult to resolve problems. During our class sessions, discussions frequently came to a stop after we reviewed our issues, leading us to silently work separately instead of collaborating. One major hinderance to our progress was an issue with our .gitignore file in the UpdateGuestWebUI repository. We had a branch where a mock Angular app was created, which had commits made before we finalized the .gitignore on the master branch. This caused unnecessary files to be committed, and we spent multiple weeks trying to find a way to remove them. We eventually found a simple solution that involved removing and recommitting every file after updating the .gitingore. It really shouldn’t have taken us that long to find such a simple solution, and I think we could have solved the problem quickly if we all worked together on it rather than focusing on our assigned issues independently.

I think there are several changes that can be made for future sprints, both for me individually and for the team as a whole. For myself, I think I could leave more comments on issues. I often made progress on my assigned issues or wanted to ask questions to my teammates, but I decided to wait until our class meetings to inform them about my progress and ask them my questions. Not only did this result in several of my contributions being undocumented on GitLab, but I also felt that it slowed the pace at which I could work. I also think that I need to work on communicating with the team in class more. During our meetings, I need to try listening better and making more contributions during discussions so that I can keep myself informed about the team’s progress and help my teammates resolve their problems more efficiently.

For the team as a whole, I think we can make some improvements to our usage of the GitLab issue board. I think we used it effectively overall, but there were some problems that caused confusion, such as an issue getting duplicated. We also exclusively used template descriptions for our issues, which sometimes made it unclear what we planned to do. I think we could better coordinate how we create and label our issues to avoid such confusion in the future. Additionally, I think the team could make improvements to communication. Instead of simply sitting in silence during class, we could explain to each other what we are working on in order to keep each other informed. Also, asking questions about issues and listening closely to comments from each other would undoubtedly help us avoid drawing problems out for too long. While this sprint was certainly an overall success, making these changes would help us work more efficiently and ultimately complete more of the project.

Links to My GitLab Contributions:

These are issues I was assigned to, where I made comments detailing my progress.

These are issues where I replied to comments from a teammate, acknowledging that their progress would help me with my assigned issues.

These are issues I opened, assigned weights and labels, and edited the descriptions of.

These are issues I moved across the board.

This is the duplicate issue that I closed.

This is the UpdateGuestWebUI repository I created and worked in. Note that the branch where I added the .gitignore and the Angular Mock branch where I resolved the .gitignore issue have since been merged into master.

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