#cs@worcester

[sensinci]

Apprenticeship Pattern: Record What You Learn

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

In response to the question, “Will this pattern cause you to change the way you will work?”, my answer is a resounding yes. I’ve read this pattern multiple times before writing this blog post and have slowly been successfully developing my own personal journal/“Breakable toy”. I think one of the reasons why this has been so effective for me has to do with the following line I found interesting while reading this pattern, “The private record allows you to be painfully honest with yourself about the progress you are making”. In my journal, I get to reflect on how well I truly know certain technologies and what I still want to learn. And whenever I learn something new, I write about it in a way that is meaningful to me (as opposed to doing work for a class deadline). Therefore, I completely agree with the information in this pattern. It has been a super beneficial process for me so far and it is rewarding to physically see the evidence of what I've been learning in one localized place. I’m happy that if I have taken anything from this book, it is a journal/“Breakable Toy” I can continue using in my career and life.

[sensinci]

Sprint 2 Retrospective Reflection

In this blog post, I will reflect on the second sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

To start off discussing what worked well, one of our biggest accomplishments, if not our biggest accomplishment (in my opinion) was successfully creating a functioning docker image that we were all able to pull and use on our individual laptops. This was a big milestone for us because during sprint 1 we were running into compatibility issues and had no standardized way of creating and sharing code with one another.

For things that didn’t work that well, I would like to bring up something that was a common theme in our retrospective meeting: our lack of regularly documenting our work. I think this was something that we started off on the right track at the beginning of our sprint after having discussed this as an important thing to do in our first retrospective meeting. But with spring break, the week we had off from class, we fell back into the habit of doing work without documenting as we go along. Another thing I would like to mention for this category were the issues we created that started with “Learn to…”. By creating these kinds of issues, it made it difficult to deliver something tangible as it relates to our capstone project. While there was a lot that we learned, it should be represented in the future by applying our new knowledge in a practical way. Lastly, I would like to mention that although we had a functioning docker image to use, it has been incredibly slow to use while on campus/in class. There were classes where I felt like I was simply working on setting up my container just to shut it down by the time class was over.

In our retrospective meeting, one of the big things we discussed we could all improve on as a team is thoroughly knowing our issues board. As a team, we should constantly be reading, updating, asking clarifying questions, and breaking down issues into manageable steps. Part of me was afraid of touching issues that my peers created because I didn’t want to change their original idea, but it is exactly this collaborative process that is needed to create a productive sprint. Doing this clarifies the work at hand and prevents things like creating duplicate issues.

When it comes to changes that I can make to improve as an individual, my goal for sprint 3 is to use my class time more effectively. This last sprint has taught me that it is especially difficult for me to dive into my code when my peers are around me. Some of the best technical work I have done comes from me working in an independent, library-like environment. Because of this, I will focus on using daily standup meetings and my class time as an opportunity to get very comfortable with our issues board. If there are issues that require further details I can add them in class and if there are questions I need to ask my peers about issues they’ve created I can ask them in person. I believe making this small change will be more effective than spending my hour and fifteen minutes in class trying to code with intermittent distractions that may pertain to the capstone, but do not always pertain to what I’m coding.

Links to evidence of activity on GitLab with descriptions:

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/21

I created this issue.

While I did not post the comments on 3/1, I helped Sofia write the comments where we created smaller steps on how to go about setting up a Docker image with the React Native framework.

While I did not post the comment on 3/14, I encouraged my teammate to write up the documentation on creating a container for React Native and the third party application, Expo. Additionally, I followed the steps in case there were any clarifying edits that needed to be made.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/22

I created this issue.

We learned that adding the extension ID of the dependency in question, along with its version, to the package.json file is how we go about adding/removing dependencies to a Docker image.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/23

I created this issue.

I responded to my classmate by adding a clarifying description to this issue.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/24

I created this issue.

I had a conversation with Sofia on how another issue essentially covers the basics of this issue so it was redundant to have both. As a result of this conversation, this issue was abandoned.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/25

I created this issue.

I created a clarifying description with steps for this issue.

[sensinci]

Apprenticeship Pattern: Familiar Tools

The pattern I decided to read is titled “Familiar Tools” from chapter 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that this pattern presents asks the reader how they plan on completing a work project if there are so many new things to learn with each project (from the technical to non-technical aspects). The solution to this problem starts by informing the reader that they should have a reliable set of familiar tools to use for each project they start. However, the reading goes on to explain that readers should be weary about how they use these tools and how dependent they are on these tools. A larger message stresses the importance of how in the process of becoming a journeyman, we may need to painfully abandon some tools and learn new, better, more effective tools in their place. The text ends by encouraging readers to either build a toolbox they can bring to a project, or if they already have a toolbox, examine potential replacement tools.

Reading this pattern was surprisingly encouraging. I don’t think that was an intention of this reading but the reason it had this effect on me was because as someone who is in the beginning of their journey in software development, it can feel pretty intimidating to just be starting out when there are people who have been working in this field for years. And yet, that person and I may be in the process of learning some of the same things today. While the other person is likely to have much more experience in using tools than I am, it is comforting to know there are things we will be learning at the same time.

This pattern has changed the way I think about my work because it has gotten my wheels turning as to what five tools I would like to have in my toolbox and what tools I think I need to continue exploring.

Lastly, there isn’t anything significant in this pattern that I disagree with. This is another pattern I enjoyed reading.

[sensinci]

Apprenticeship Pattern: Expose Your Ignorance

The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

Lastly, there isn’t anything significant in this pattern that I disagree with. It was an enjoyable pattern to read and one where I learned some valuable information.

[sensinci]

Apprenticeship Pattern: Stay in the Trenches

The pattern I decided to read is titled “Stay in the Trenches” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern spoke about how people often equate being promoted into a managerial role with success but how this can actually take you away from the craft of programming. The pattern goes on to talk about how we should work with our employers to see if they can reward us in other ways that keep us close to the act of programming. Next, the pattern discusses how it is easy to apply this pattern selfishly but that experienced developers will find ways to make choices that will help their co-workers as well. Lastly, this pattern ends with suggesting its reader to come prepared with alternative rewards in case they don’t like the rewards offered by their potential employers, especially if they take them away from programming.

The most thought-provoking piece of information I got from this pattern was the bit about how I should make choices that are in my best interest, but how those choices don’t have to be blind to the needs of those around me. It was interesting to hear this because in a pattern that I’m learning about negotiating and advocating for myself, I’m also being taught how I can still be compassionate to others on my team. This is refreshing to hear because it seems like developing can often be a cut throat and intense environment to work in.

As far as how this pattern has caused me to change the way I think, I would say it re-enforced some of the beliefs I had. In a way, I’ve learned first hand what this pattern has described. I started working in human services as a residential counselor and worked my way up to managing a group home on my own. I learned the hard way that by entering a managerial role, I did a lot less case management and had less time with the individuals I served than when I was a residential counselor. Because of this and some other factors, I decided to step down back to the role of a residential counselor which I personally find more rewarding. This realization I made is the kind of message I got from reading this pattern. If I am passionate about programming, I need to be mindful of the opportunities I may receive in the future and make sure they are aligned with my desire to be a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It was reassuring to hear something I have learned in life being echoed in this book, even though it was in a different career path.

[sensinci]

Apprenticeship Pattern: Draw Your Own Map

The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It has encouraged me to start thinking about my own map and it has made me peek at some new potential patterns for me to read next (e.g. Expand Your Bandwidth, Use Your Title).

[sensinci]

Sprint Retrospective Reflection

In this blog post, I will reflect on the first sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with one sentence descriptions.

To start off discussing what worked well, I would like to pick one thing I decided on doing without much prompting. In addition to checking in with my team during the week and through discord, I made an agreement with myself to try to submit at least once a week a “bigger” message on our GitLab that would hopefully be useful. While I think it is important to post links and resources for us to learn more about certain tools and technologies, I wanted to include some posts/documentation on bigger conversations we had during our stand up meetings and detailed documentation of my setup process with certain technologies (e.g see post on setting up React native and post on the user flow diagram).

For things that didn’t work that well, I would like to discuss some of the technological difficulties I had. For the first couple of stand up meetings, I thought I would be able to do this capstone with my old laptop. After realizing that this capstone would require some more CPU power than my laptop could offer, I purchased a laptop that was more appropriate for the demands of this course. After setting up my laptop, I noticed a significant change in the amount of work I could then produce. I do think there is a minimum laptop requirement as far as performance is concerned, especially when we are testing frameworks and downloading various software/programs to build our first app. For example, I ended up downloading Android Studio for this capstone and this is a large application. There was no way I could have used my old laptop with Android Studio. I’m happy with the purchase I made and I know it will last me into the first couple of years of my professional career.

One thing my team could improve on for the next sprint is better documentation. This is something Dr. Wurst had mentioned and also a bigger conversation we had as a team during our retrospective team meeting. We discussed how although we may be doing a lot of work and research on our own, if we are not documenting this process, it’s like it never happened to future groups who join this capstone project. We discussed how sometimes it’s difficult to document as we work because it breaks up our “flow”. One solution we came up with to address this problem is setting aside 10-20 minutes at the end of our work to strictly document what was done.

One thing I think I can work on doing better in our second sprint is documenting the work I have done. This was especially a challenge for me in the beginning when I was transition from one laptop to another, but now that I have a more reliable set up, this is something that should not be as much of a challenge to do. Moving forward, I like the idea of checking in at least once a week with my teammates outside of regular class time to update them on the progress I have made. This would be a great way to build a routine where I am regularly creating some form of documentation.

Lastly, I will include links as evidence of activity on I’ve contributed to GitLab with one sentence descriptions.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/17#note_852841115\

In this post, I wrote some notes on some of my research in deciding whether React was a viable framework for us to use.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2#note_848876182

In this post, I posted a digital version of the user flow diagram we had discussed in class.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2#note_840272759

In this post, I posted some documentation notes on setting up react native in addition some of code and screenshots of a potential place for us to start.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/9#note_839072762

In this post, I made a comment about the difference between the LICENSE.md and LICENSE_FOR_CONTENT.md files.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/commits/main

I posted six required files to our General repository.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/5#note_839049184

I posted a link that teaches about .gitattributes in a straightforward manner.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/10#note_838060720

Communicated with my team that I moved something to “Needs Review” for them to pick up and move to the “Done” category. 

Links to issues I’ve opened/created:

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/12

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/11

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/10

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/10

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/8

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/7

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/6

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/6

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/5

[sensinci]

Apprenticeship Pattern: Nuture Your Passion

The pattern I decided to read is titled “Nurture Your Passion” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that I think best summarizes this pattern is the one that states, “The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.” I really liked this quote because I’ve heard so many stories of young software developers who do amazing work at their first couple of jobs, but suddenly stop working because they are not feeling fulfilled. I think part of the reason for that is because many software developers enter the field and work themselves to the bone without really thinking about the “why” behind their work.

The reading adds that the jobs can foster a highly competitive, fast paced, and toxic work environment that further leads to developers burning out. The reading provides some potential solutions to this problem: 1. work on something you like 2. seek out kindred spirits 3. study the classics 4. draw your own map 5. set boundaries

One of the most thought-provoking things I took away from this reading was how by setting boundaries in my first job as a developer, I may get passed over for pay raises, promotions, kudos, or popularity. But on the other hand, by taking care of myself I am less likely to burn out and have a more sustainable career.

Therefore, I would say this pattern has indeed caused me to change the way I think I will work in my profession. While I want to be seen and known as a hard worker, I also think it is important for me to be mindful of how I am working and find balance.

Overall, there isn’t anything that stands out that I strongly disagree with. In fact, this pattern alluded to some other patterns that I am now more interested in learning and reading about to help me make sure I nurture my passion as I enter the software development field.