Author Archives: sserafin1

Retreat into Competence

Retreat into Competence is an apprenticeship pattern that focuses on the idea that when you find yourself in a situation where you are overwhelmed with new information, it is alright to withdraw back into something you are more comfortable with. By doing this you allow yourself to gain back your mental composure, and gives you the opportunity to reflect on how far you’ve come as a developer.

I believe this apprenticeship pattern is incredibly true and helpful, as I have frequently found myself in situations where I do not feel confident in my abilities and as a result I get overwhelmed and stop being productive. When I first started my internship last summer, I was expected to use Python as the primary language. Up until that point I only had limited experience with Python, so I had many moments when I felt like I was in over my head with trying to learn a new language and also meet deadlines for the projects I was working on. During those moments I would often get a pretty bad case of imposter syndrome, and start believing that I wasnt good enough for the job. What helped me push through this was a similar technique to what is taught in this apprenticeship pattern. Whenever i felt overwhelmed with a certain aspect of the project, I would go back to a part of that project I felt comfortable with and work to improve on what I already built. By doing this I was able to stop the mental block, and by working on familiar material I felt like I was making progress. This in turn helped me figure out issues I was having with other parts of the project and slowly push through them to finish everything up.

Since I have used this apprenticeship pattern in the past with success, I am almost certain to use it again in the future. Since I just graduated and am about to start my new career, I am sure plenty of situations will pop up where I again feel overwhelmed. When those situations arise, I now have a strategy I know will work, and I can rely on it to help me get through whatever issues might come my way.

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

Expand Your Bandwidth

Expand your bandwidth is an apprenticeship pattern that teaches the idea that as well as learning and improving at tasks that we are comfortable and familiar with, we need to be able to learn about completely new and novel ideas in order to excel in our fields. The pattern mentions signing up for online blogs, newsletters, and online forums as a way to learn about new ideas. The authors also mention that while this pattern is important in order to excel in software development, its also important to know when to use it, and when you should instead focus your efforts on the task at hand. Their approach to this is to try to designate time every now and then to learning new things, but don’t spend more time than necessary on that learning.

I agree with this pattern and I think it is a good approach to the idea that people are meant to be lifelong learners. It isnt realistic to expect us to always be learning new things, as that constant influx of new information can be jarring and oftentimes unnecessary in the things we are currently pursuing. This approach teaches us that its important to set aside time for learning new things, but not in a way that it interferes with our current tasks. As a college student I have been introduced to plenty of novel concepts throughout my undergrad program, so I understand the importance of learning new ideas. Likewise, once I go out into the work force I will most likely specialize in a specific set of tools, and my learning will narrow down to mainly encompass those tools that I will end up using. Looking forward into this future I can see the issues that the authors mention in this pattern, where not expanding your knowledge base can prevent you from becoming the best you can, and I agree that the solution is to periodically go out of your way to learn about new ideas and concepts.

I have not really applied this apprenticeship pattern much in my life as of yet. A lot of my learning has come from my undergraduate program, and as such I have had the privilege of being exposed to a wide knowledge base. I do however, plan on incorporating it in my future career, since I believe that acquiring new knowledge will be important if I want to have a successful career as a developer.

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

Sprint 3 Personal Retrospective

This final sprint was much more of a struggle than the other two prior sprints. Since we got a lot of progress done in achieving our goals throughout the past two sprints, we figured that this sprint would let us bring everything together and finalize everything we have worked on up until this point. Unfortunately due to unforeseen issues, we were unable to reach all of our goals, an we were instead stuck on one task for a vast majority of the sprint. Our goal this sprint was to test the backend and the endpoints to ensure that they can all work with each other in the way that we planned. We initially thought that we had solved many of the issues with the backend that have been plaguing us in the past sprints, but unfortunately that was not the case. In order to test the endpoints we needed to be able to run the backend, and when we attempted to do that we realized that what the previous group had left us was not configured correctly and was also missing a lot of important code. Upon realizing this, Kurt and I went to work trying to figure out what exactly was missing and preventing the backend from running correctly. This debugging took up a vast majority of the time, and in the end Kurt was able to figure out what the main issues were and managed to get the backend partially running. This was still not enough for us to get our endpoints tested however.

Given that this sprint was more of a challenge than initially expected, there are definitely things that we could have done better as a group in hindsight. One of the bigger mistakes I believe we made was that we didnt have everyone working on the backend problem. Since this was the priority, it should have been a team effort to try to solve it and get it running as fast as possible so that we can test the rest of our code. Unfortunately since in the beginning we didnt realize the scope of the issue we never organized the work in that way. Many of the team members were forced to wait until the backend was complete before they could try to do the tasks that they were assigned. However since the backend never ended up getting fully completed these team members did not have as many opportunities to contribute.

Given hindsight about my performance in this sprint, and knowing what the issues we faced were I can look back and see that there were definitely things I could have done better. One of the main things that comes to mind is my initial approach to trying to solve the backend issue. At first I simply attempted to brute force the problem, moving code and files I thought might be affecting the issue around in the project to see if that changed affected anything. This proved to be a useless exercise in the end and resulted in me wasting more time than I should have. If I could do it again I would approach the issue more slowly, reading through all the relevant code and researching what issues may cause the kinds of problems that we were experiencing.

I do not have any gitlab links to share, since I was unable to get the backend working and therefore had nothing to push. As I mentioned a majority of my work was brute force trial an error where I attempted to figure out the issue.

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

Find Mentors

Find Mentors is an apprenticeship pattern that talks about the importance of having someone that you can directly go to for help or ask questions in order to further your own understanding about the subject matter. This pattern talks about the importance of having a mentor, and the difficulty associated with finding a good one. Mentors can give you insights that you might not otherwise be able to figure out on your own, and guide you in a direction that will be the most beneficial for you. The main issue is finding a mentor who is not only competent in what they do but also willing and able to take the time to help you.

In my internship I was fortunate enough to be part of a small company with a tightly knit culture. As a result I was able to get to know a lot of the people in the engineering department and likewise I was able to pick their brains for new knowledge. I was also fortunate to have a very competent programmer manage me, as I was able to frequently ask them for questions or assistance with certain tasks that I otherwise would have taken much more time and effort trying to figure out on my own. They were essentially my mentor for the span of the internship, even going out of their way to recommend resources for me to look into on my own time that they believed would be beneficial to me. As a result of this experience I whole heatedly agree with this apprenticeship pattern, and I believe that if possible everyone should try to find someone to mentor them. This however brings up the issue mentioned in the initial paragraph, and that is finding good and willing mentors.

After my internship ended it became difficult for me to ask that same engineer for advice, and since then I haven’t really had anyone on the same level as them to directly mentor me. This is why I believe that it can be an issue trying to find a mentor outside of work. When you’re in the office its easy to get in touch with people smarter than you and get help, however outside of that environment its difficulty to find someone who is willing to give up some of their time to help what in many cases is a stranger. The authors do give some advice on how to go about this, and I believe that it is good advice that may eventually lead to a connection. But it still boils down to finding someone that wants to and has the time to help you.

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

Practice Practice Practice

Practice Practice Practice is an apprenticeship pattern that focuses on the idea that deliberate practice is the best and most efficient way to learn and master a craft. This apprenticeship pattern is similar to breakable toys, but it is more focused on the actual act of practicing rather than the consequence free ability to make mistakes. The pattern talks about doing challenging tasks repeatedly, and noting on what improvements and takeaways you have each time you complete the task. The authors liken it to a sort of programming dojo, similar to that of a martial arts studio, where repetition of motions without opponents is essential to excel in the martial art.

I absolutely agree with this apprenticeship pattern, and believe that practice is realistically the best way to actually learn to become a better programmer. While lectures at school are useful to learn about the subject matter, to truly understand it and begin to master it you need to be able to apply it yourself. I have first hand experience with this thanks to the internship I did last summer. While I do learn a lot in school, lectures and assignments only go so far. Being exposed to real world code and having to learn a lot on the job taught me a lot of practical skills that I otherwise would not have quickly learned. I was also surprised by how quickly I picked up on these things, and that even a little bit of repetition managed to ingrain new information into my head.

While I agree that this apprenticeship pattern is very useful, it can be hard for me to implement in my own life. If I am directed and given tasks to do then I will happily do them and learn new things in the process. The issue comes in when I need to self direct, and that can be difficult for me at times, especially with projects or activities that don’t necessarily peak my interest. For example, in order to practice for interviews I did leetcode questions as often as I could. While I did learn new things through the repetition that came from that, as time went on it became more of a chore and less of something I wanted to do and as such I began to do it less often. I hope to improve on this over time, and be able to stick to repetition for the sake of practice and improvement. Because while I can learn a lot at work, Ill have a harder time improving quickly if I also don’t practice on my own time.

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

Sprint 2 personal Retrospective

For our second sprint I think our group improved in many aspects of the process. Last sprint there was a lot of confusion around what exactly needed to be done and how, as well as issues with managing time and expectations. The group also had relatively poor over all communication over discord, although that was more attributed to the fact that many tasks did not really need to involve more than one team member at a time. We addressed those issues in the last sprint retrospective and this sprint I believe that we did much better over all. Firstly we communicated much more than before, using discord more often to ask questions or gather information that we need from other groups. We also had more clear goals this sprint, which consisted of getting many aspects of the back end written up and hopefully working, as well as finishing up refactoring the front end. The team did a good job getting all the tasks done in a timely manner, even writing in stand-in code in areas where another team member was working on implementing a feature. In this case that team member was me, as I was working on inventory.js my team was finishing up their endpoints, and since they could not connect to anything they created stand-ins while I finished up my portion of the project. Another area I think we did good in this sprint was being timely with merge request approvals. This sprint if a merge request was created it tended to be approve within a few hours.

As a team I think we did much better this sprint compared to the previous sprint, and we flushed out pretty much all the big issues we had before. I do not really have any suggestions for things that we could improve going forward as a team. We communicated well, managed our time and work load well, and in the end got almost everything we needed done. As a team we have found a system that works. As an individual however I definitely have some things that I know I can continue to work on to improve going forward. The biggest is still time management. I did better with my own time management this time but I still could do better as I did leave many issues for later in the sprint; however I did not save them for the last second like I did before.

Since there was not too much that can be criticized with the teams performance this sprint, there are not many things I believe that we need to directly address to improve on next sprint. We will however need to keep this level of performance, and most likely bring it up a notch next sprint. While we have not had a planning session yet, we have discussed an abstract of what will happen next sprint, and the main focus will be testing and fixing bugs. Given that this will be a very involved task we will need to be communicating even more and there will have to be more collaboration between members as bugs may pop up in multiple areas of the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/blob/BackendCreation/src/data/inventory.js

I primarily worked on getting inventory.js written out with the correct endpoint connections so that the team members working on the endpoints can use them to connect to the DB.

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

Sustainable Motivations

Sustainable Motivations is an apprenticeship pattern that touches on the idea that despite loving programming issues such as frustration, lack of motivation, and in extreme instances burnout are still very possible. This apprenticeship pattern discusses how to deal with issues and attempt to mitigate them before they even really begin. One way to go about this is to make sure you keep a healthy balance between your work life and personal life. The apprenticeship pattern also gives anecdotes about times other developers dealt with an issue regarding a loss of motivation or uncertainty about what direction they want to take their careers.

To be honest this apprenticeship pattern did not click with me as well as the other ones I have read about so far. While I agree with the overall statement that you need to keep your ambitions and work in check to ensure you can maintain a steady level of motivation, it doesn’t really go into too much detail on how to go about it. The example I mentioned in my initial paragraph is one of very few where the authors actually talk about ways to manage this issue. They do reference another apprenticeship pattern called walking the long road, which discusses similar issues; but as an over all approach to trying to solve the specific problem they presented in this pattern the solutions given were mostly abstract and anecdotal. There is not too much that I can clearly take away from this pattern. Regardless there is still some lessons that I think are valuable, mainly the example I mentioned earlier regarding balancing time.

In my own life I have struggled with healthy balance of time. I tend to fluctuate between two extremes, either over focusing on work and sacrificing my personal life, or over focusing on my personal life and having my work suffer. Given this I can understand what this pattern is trying to say in that regard. While I was aware of this balancing issue in my life and have improved on it over time, reading through this pattern emphasized the importance of a good work life balance through anecdotal examples of issues other developers have also gone through.

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

Breakable Toys

Breakable toys is an apprenticeship pattern similar in spirit to Be the Worst. They both encourage us to improve by failing in one sense or another. While the Be the Worst apprenticeship pattern focuses on joining a team where you are the worst in order to learn from others on your team, Breakable Toys emphasizes working in an environment where failure is not only possible but even encouraged. Such an environment usually means working on your own projects where any mistakes you make have little to no consequences and allow you to learn from them.

Overall I think that this pattern makes sense, and is a good way to improve ones skills as a developer. I whole heatedly agree with the idea that failure is integral to improving in anything, and especially when applied to programming. I know that whenever I make a mistake I tend to remember that mistake and in most cases I am able to learn from it and improve myself. When writing code for class projects or assignments I frequently screw up certain feature implementations and as a result I learn of a better way to do what I failed to do. Be it through personal research after the fact or direct guidance from someone more experienced than I.

Personally I haven’t really created an environment for myself where I can comfortably fail. While I definitely learn a lot from mistakes I make at school, I wouldn’t go as far as to call that a safe place to fail frequently. Ive had a few personal projects in the past, but I never really thought of them as more than things to slap on a resume or to pass the time. Having read this apprenticeship pattern however, I definitely have a different outlook on those past projects, and will also have a different outlook on future ones. I will likely try to work on projects that heavily involve tech stacks I am not familiar with in order to attempt to learn from my failures working with them. It will be difficult at times as I can be impatient, and the slow initial progress with some of these projects might be discouraging, as well as any screw ups that might come along. But since I will be more aware of the fact that these setbacks are actually helping me in the long run I hope it will help me keep pushing forward.

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

Be The Worst

Be the worst is an apprenticeship pattern from chapter four that focuses on surrounding yourself with people who are better than you in order to constantly keep improving yourself. The chapter argues that if you are the best in your respective group then you will not grow and improve as a person.

I whole heatedly agree with a majority of the points made in this apprenticeship pattern. From personal experience alone I know that this idea holds true. While in a classroom environment I am definitely not the best, but I am also not the worst. I tend to work with people at a similar skill level to me when I work on group assignments or in class work. While I still learn things in these environments, I know that I miss out on more nuanced knowledge that’s gained by experience. In an environment where most if not everyone is better than me, I could learn things from people that I would most likely not learn in a classroom environment. During my internship I was surrounded by talented programmers, and as such I was taught many different tips, tricks, and skills that I probably would not have otherwise learned.

Another thing I really resonated with in this pattern is the fear that being the worst in the team will result in lower overall performance or cause me to hold others back. This idea is daunting, but it also lights a fire under me and forces me to improve in order to keep up. One thing I do not necessarily agree with is the statement that joining a team as the worst member is selfish. I do not thing that is true, as long as you join that team with the intention of working harder than everyone else to keep up and improve. The team also may benefit from you joining, since because you may be inexperienced, you can potentially learn new ideas quickly and the team may be able to mold you to their needs as a result. This can be a win-win for everyone, you continue to improve yourself while the team gets to mold you to their needs.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Reading chapter one of Apprenticeship patterns was an interesting experience as the authors give an interesting history lesson on the overall origins and initial hierarchy of master craftsman all the way down to the apprentices. It was really interesting to see the authors apply software development to this idea of masters and apprentices, and especially the idea that one of the best ways for a newbie programmer to perfect their craft is to place themselves in the roll of an apprentice. Ive always been told to surround yourself with smarter people if you want to improve, and this book seems to agree on that front. I found the list of values included in the introduction to chapter one to be a useful summary and overview of the basic principals that make someone a good apprentice, and in turn will allow them to greatly improve in the art of software development and apply these improvements in their careers.

The introduction to chapter two, emptying the cup introduced me to an idea I wasn’t too familiar with. I never really considered that even though I may be coming into this field as a newbie, that I may still have developed bad habits that I will need to break. As I learn more and progress I will need to learn how to “empty my cup” and clear my mind of existing bad habits and replace them with better, more productive habits. Chapter 3 introduces the idea that there is always much more to learn. Even if you have plenty of certificates or degrees, there will always be someone who knows more. I’m in a stage in my education and career where it often dawns on me how little I know. Often times I feel like everyone is better than me and that I may have picked the wrong career path, even though I enjoy what I do. But I have slowly learned to overcome this feeling. Similarly chapter four emphasizes this even more by stating that its easy to be slightly better than everyone else, but becoming complacent in this position is counterproductive if you ever truly want to be great at your craft. I definitely resonate with this idea, and I know that I have been guilty of becoming complacent in the past. Ego is a strong emotion, and I know I need to be able to understand that I always have more to learn. Finally chapters five and six both seem to cover a similar idea, and frankly it ties back to all of the previous chapters as well. The idea that you are always in a state of learning. While right now I may be in school and my curriculum is laid out for me, that wont always be the case. Reading these introductions gave me a heads up that if I truly want to be considered great at software development someday, I will need to continuously learn and improve myself.

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