Author Archives: Sensinci's Blog

Sprint 3 Retrospective Reflection

In this blog post, I will reflect on the third 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.

One of the things that worked well for me personally during this sprint was the quality of documentation that I had created. I would say that my documentation was consistent from beginning to end for sprint 3. For all the work and decisions I made for this sprint, I made sure to document it for my current teammates but also for the next students who would be taking over this project. Another thing that worked well for me this sprint, was creating a document with specific goals that I wanted to accomplish prior to each class. I regularly checked in with this document through sprint 3 and it served as my personal issues board. I kept updating the specifications of my issues but the overall gist of the issue remained intact for the duration of sprint 3.

For things that didn’t work that well in this sprint, even though I consider sprint 3 to be my most productive sprint, I also feel like I did not deliver enough minimum viable products that possessed incremental improvements. While I did produce a minimum viable product for updating our landing page, that soon got quickly incremented with another teammate’s commit. What I was really hoping I would be able to crack was creating an interactive drawing page for the writing portion of our application. While I made several attempts in creating this feature, they were all ultimately unsuccessful in producing a minimally viable product that improved on the pre-existing code.

As far as what we could improve on as a team, one of the things that I think could have made us even more successful would have been having a conversation about what we wanted the minimum viable product for sprint 3 to be. I think we knew all the work/issues that needed to be done for this sprint and we went full steam ahead, however, we probably could have benefited from taking a mental snapshot of where we were at the end of sprint 2 and where we hoped to be at the end of sprint 3.

When it comes to changes that I can make to improve as an individual, I would like to address my previous issue of what I don’t think worked that well for me in this sprint. Next time, I think I should focus on taking what is already present and making one minor incremental improvement before moving forward with an exploratory phase to create a major improvement. My initial increment doesn’t have to be much, but it would allow us to say we delivered something different from sprint 2. By doing something small and simple first, I can then focus my efforts on riskier experiments. If these experiments work out, the risk would have paid off, but if they don’t work out, I can fall back on the safe, small incremental improvement I made.

Links to evidence of activity on GitLab with descriptions:

Update to landing page (!2) · Merge requests · Worcester State University / Computer Science Department / Naturalization Interview Confidenc

  • What I essentially did for this was replace the “We want pizza” landing page to one with two separate buttons. One leads to the “Writing Portion” of our app and the other leads to the “Reading Portion” of our app.

Build a page that shows previews of the questions for the interview (#28) · Issues · Worcester State University / Computer Science Departmen

  • I asked for clarification on why an issue was closed so that it is documented.

Update landing page of docker image (#2) · Issues · Worcester State University / Computer Science Department / Naturalization Interview Conf

  • I explained my process with getting expo running for me (which is different from how one of my teammates was doing this).

Implement the component that contains a single question preview (#39) · Issues · Worcester State University / Computer Science Department /

  • I pulled and checked out the code per my teammate’s request to make sure it worked on my end.

Add a drawing feature (#18) · Issues · Worcester State University / Computer Science Department / Naturalization Interview Confidence Enviro

  • I pulled and examined Emmanuel’s code per his request and then made some exploratory attempts to implement a writing feature.

Build Spike Solution where the full text of a question is transferred from the display page to another page (#30) · Issues · Worcester State

  • I documented a potential idea for our issue with implementing the reading portion of our application.

Deploy Application (#67) · Issues · Worcester State University / Computer Science Department / Naturalization Interview Confidence Environme

  • I created an issue with some notes for whoever starts the process for this issue.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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:

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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).

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

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

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Craft over Art

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application’s appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.