Author Archives: howbrash

Apprenticeship Patterns – Share What You Learn

So this is a pattern that I’m entirely unfamiliar with, as I don’t consider my understanding of a majority of the material sufficient enough to be able to reliably pass it on to another person. However, the pattern immediately addresses this by noting that every little nugget of knowledge can be valuable to someone who might be unfamiliar with it. And as a result, that bit of understanding can thereafter be passed on again, and cascade from the little help that I might have given a fellow programmer. In some ways, it may even be more beneficial to learn tidbits from a peer, as the author mentions that we would be speaking the same language in terms of familiarity. 

While the pattern references the fact that people may not appreciate what you share, I wholeheartedly agree that properly teaching somebody else will solidify the techniques in one’s own mind. If someone is struggling but isn’t willing to hear what you have to offer, they need to improve over several areas in their own right. 

I find it fascinating that the author mentions to be cautious about what you share, as you might be stepping on the toes of a higher up, and unintentionally disclose something that was valuable to an employer. It’s certainly something I’ve never considered before and will take into account going into the future. I’m also glad he mentions the fact that sharing a lesson could be interpreted as conceited or aloof, because from personal experience I’ve lost respect for people like this faster than a Hello World program executes. All in all my takeaway is to temper what you say and read the room when deciding when or when not to share; quite the valuable lesson. 

In the Action portion, I don’t necessarily agree with the recommendations made. Of course there’s no problem with writing blog posts and sharing workshops, but I regard the most important lesson to be to think about how you would engage with someone treating you the same way, if you were approached by them in the same situation. Teach in engaging ways and foster curiosity in your peers, but only if they are willing to accept your olive branch. It’s ultimately a waste of time to preach at someone who isn’t really listening, and worse, judging you for engaging with them.   

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Breakable Toys

My biggest takeaway from this is to simply build more things that don’t work, so later on I have the knowledge to make things that do actually work. The quote of the three ball juggler not attempting to push the limit to five balls during a performance is an analogy that really spoke to me in that regard. 

I think the idea of building a personal wiki would be a phenomenal practice for my growth, as I’m constantly forgetting general syntax or git commands that sometimes slow my production rate to a crawl. I built a game for another class that emulated the classic Flappy Bird from a few years ago, and getting that to function would have taken my ages and ages without the help from my groupmates. But reflecting on the experience now, the amount of times we broke that game and the thrill of being able to actually PLAY what I made was something I’d never experienced. Nor with any other art, as I’ve never been one to share any of the sparse create projects I seldom try to come up with. Reading this pattern has kind of put that creation process in a better context for me now, and I hope I retain that going forward as I expand my portfolio to apply for career positions in the future. 

I also like the idea that I own these broken things, but that they will stay with me wherever I go. Just because I can’t make something work at first, doesn’t mean years or months down the road I can easily slap on some extra padding and see how much I’ve grown as a creator. 

Reading on, the Action section really sums up everything that I just reflected on. Especially the wiki idea, which will be the first thing that I try to implement. I know I’ve kind of been harping on very similar patterns, as referenced in the See Also section, but I think this is the biggest area of improvement that I need to work on. For my last post I’ll be sure to expand into a more diverse pattern just to expand the repertoire, but I think it was important for me to recognize the importance of my harping on these specific topics.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

Oddly enough, I found this sprint to be a tad more challenging than both the first and second. I’d say this is primarily because we were nearing the end of our project, and the team had some difficulty accurately choosing and weighting our epics and issues. I’m unsure if the rest of the team would agree with this sentiment, but it’s certainly something I felt at the beginning of the sprint. We all eventually found worthwhile contributions to work through, but the lack of cohesion or agreement at the beginning was a little jarring. 

Despite this, I’d say the team got some of the harder pieces of work done near the end of the sprint. I certainly remember the getRange file for the API being a huge hurdle to get functioning, but with Jeff and Kenny working together they made it work in the end. Personally, I felt a little stuck after implementing a few new schemas in the API, as I had elected to work on the key validation from the other groups’ projects. I thought I’d give it a shot, as encryption has always been pretty fascinating to me with all the different types of encoding techniques that exist. However, I soon found I was quite far out of my depth; I ended up staring at StackOverload and random forums trying to get the verification working for a lot of class time. There were a few times I thought I had cracked it, but unfortunately it broke the code every time I pushed it into our repository.

In the future and during my career, it’s pretty crucial I learn to reach out or actually post something on one of these forums for help. I’m sure during the process of an actual situation my seniors will be vastly more knowledgeable than me on basically everything, so this is a skill that should hopefully develop naturally. Of course it’s important not to be an incessant pest, but with my genuine willingness to improve I’m sure I’ll be fine.  

Overall, I was still really satisfied with the team this sprint. I think we all found our roles and niches in the project to work on, and were more than willing to answer questions and help out whenever it was needed. I found the capstone to be a great introduction to my future career opportunities, and the familiarity I garnered over the semester should boost my competency level pretty far beyond what it would have been otherwise. I also look forward to working on a team with a dedicated scrum leader who I can look to for some direction if I feel lost.

One thing that I do think the team could have communicated better on was our presentation. I know it’s pretty separate from the actual work we were doing, but for a good amount of time I had no idea what I was supposed to be covering in the video. I defaulted to whatever the team didn’t initially choose, as I wanted them to be more interested in what they were presenting. Unfortunately, it was difficult to glean my responsibilities as some members were quick to post what they preferred, while others didn’t accurately mention their coverage. In the end I just went over the API, and I hope I didn’t overlap all too much with the others’ videos. Regardless, that’s a minor gripe, and I don’t blame anyone because it’s the end of the semester. 

As for some contributions, I added these pretty minor things to the API over the sprint.

I also helped out a bit on the getRange before I started working on the backend key validation. It starts on line 56 of this link.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Unleash your Enthusiasm

In opposition to my personal experience with almost every other pattern, this is one that I very much struggle with. I have enthusiasm for certain things, but I find my motivation and discipline to be very shaky in my average lifestyle. This might have to do with personal mental health struggles and general disposition, and to be fair I’m still young enough to be unfamiliar with a passion I could truly want to pursue.  

To be completely honest, I believe this is the most difficult pattern for me to grapple with. I’ve certainly been involved with different types of projects where I was more enthusiastic compared to my other teammates, but they are few and far between. However, something that I can aspire to learn is the freedom of my enthusiasm as a “responsibility of the apprentice.” I find this line to be profoundly interesting, as I would have originally thought that the more experienced veterans embodied this type of archetype. Upon reflection though, I realize how mistaken I was, as innovators can’t be pigeonholed into time spent in an industry; rather the fresh ideas that emerge from newly aspiring minds are the most important part of the process. Regardless, I’ve learned that despite age or experience, a person who’s passionate about whatever they’re working on has (somewhat) the inherent obligation to innovate in the industry they work in. 

Unfortunately, I’m of the mindset that one should do the bare minimum to pass as a competent employee; I don’t know if this is because I’ve worked enough minimum wage jobs to understand the dynamic, or if I’m a lazy person inherently. Not to say that going above and beyond is a bad thing, but that raising the expectations eventually leads to a standard for most people that is unfair and not an expected level of engagement with the job. 

Anyways, with the last portion of the “Action” section, I see a true position where I’m lacking in my work ethic. I’ve certainly been in the place where I’ve declined to present an idea that may or may not be applicable to the project in question. It’s not that I’m reluctant to share, but more so I’m not inclined to add an argument/idea where it’s not necessarily necessary. I absolutely contribute where I think an idea may be beneficial, but in my experience it’s not worth the hassle to say something that could be thrown out with a disregard to the necessity of the point being made. Regardless, I’m certainly going to take this advice to heart and implement it in the future.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The White Belt

I think this is some of the best advice that the Apprenticeship Patterns have to offer. Stagnating in the learning process is an incredibly difficult problem to resolve, as learning is such a unique process to each individual person. I learn quite differently from my brother, while he and I learn wildly different from my father. With such a discrepancy even within a family, I think this is a very poignant point to address. From a personal standpoint, I’ve certainly experienced this phenomenon to an extensive degree. My ability to intake new information varies drastically based on how interesting I find the topic.

As the author mentions, “Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” I find this to be invaluable advice; maybe I’m a little jaded, but I believe most people have no idea how much they don’t actually know. The capacity of people to not understand how uninformed they may be on certain topics genuinely shocks me sometimes. Even worse, this type of person often thinks other people are wrong when they are woefully uneducated on whatever the topic may be. Apologies for ranting about this for so long; it’s genuinely one of the most frustrating things I find about the modern era. I blame the internet honestly. 

I don’t want to claim I’m an expert on people, but this is something common I’ve frequently observed in various jobs or interactions. To step off my high horse for a minute, I generally tend to regard myself as an idiot in most situations – not even as a self-deprecation thing. I find that humility in knowledge is one of the most valuable traits that anyone can have, in literally every situation. Akin to “not wanting to be the smartest person in a room,” I think there is, without a doubt, ALWAYS something that can be gleaned from a dispute or conversation. After opening up my biases or assumptions in some ways, my opinions have been drastically changed in ways I could have never predicted. Even if one is an expert at something, I find it incredibly important to maintain this white belt mindset.    

I realize I’ve definitely deviated from the original point of the pattern, but because I’m so adamant about this type of subject I felt the need to rant a little bit. Thanks for coming to my Ted talk. 

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Concrete Skills

Concrete Skills

This pattern is something I’m personally invested in, as the feeling of imposter syndrome is incredibly hard to shake. Depending on the career path I eventually go down, I plan to get as familiar with whatever basic techniques and software that the project will be using. I’ll undoubtedly be inexperienced and unprepared, but to demonstrate a basic level of competency with the most basic of the workload, I want to be as proficient as possible with the fundamentals. My biggest fear would be what the pattern refers to as “day care,” as I would loathe to be babysat in such a professional setting. On top of this, I thought the comment that one’s concrete skills are basically what get your foot in the door was quite insightful for someone like me lacking any sort of hiring experience. I’m also very grateful that the pattern lists a few of the concrete skills with examples like understanding of open source frameworks or basic web design. 

In addition to stressing the importance of the concrete fundamentals, the pattern also goes on to explain how your reputation can be based on the credibility of your portfolio. As you grow from being the new guy into a successful developer, your work will speak for itself and shatter that initial requirement for consistent fundamentals. While the former is still important, you won’t have to work nearly as hard to prove your utility to a team.

For the Action portion of this pattern, I’m certainly on board and will implement this in my future job searches. While considering a few different professionals, there may be consistently noted discrete skills in the CVs, so that could be a great skill to implement regardless of the career path. On the other hand, some of those skills may be niche, but hyper specific to the type of job you’d like to apply to in the future. The pattern recommends regularly examining your own CV and implementing a similar kind of honed skill set for the specific position you may be applying to. On top of this, I would say that engaging with professionals or colleagues in this manner would work to bolster professional relationships, which could lead to advances down the road if they reflect on your tenacity. 

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Sweep the Floor

This pattern really focused on the idea of your value as the new guy in a fresh team environment. Each party has no idea about the other’s techniques, patterns, thought processes, or communication abilities. While you’ll naturally get acclimated to the team through experience, it’s always a good technique to pick up some of the menail, but important work. It should show the team that you’re willing to pitch in, and if you take your time to make that menial work look stellar, then that’s an even better indicator of your talent and value to the team. It warns of becoming the team’s “gopher,” which I would say is a valid caveat; I guess I would prefer to think that most people are more professional than that.

For the majority of the pattern, I wholeheartedly agreed with this advice. It should garner comradery with your peers, and an improved understanding of the project – I would apply this to any sort of team effort in general, because if the members operate in good faith then it should promote the team to be a more effective unit (theoretically).  The only thing that I have a bit of a disagreement with is the assertion that you might be relegated to that menial work by default, after trying to sweep the floor for too long. I’d say as long as you engage with teammates about where they are on the project, ask questions, and actually learn from those conversations, you should be at least relatively qualified to work on more challenging tasks. On top of your understanding of the different project parts, I’m confident your peers will recognize your engagement and welcome you to cooperate with different or more challenging content.   

Finally, I can understand the sentiment that one won’t appreciate the bigger picture of the project, or would get uncomfortable attempting new types of work outside of their comfort zone. These are very different problems, and require a good amount of introspection to address in my opinion. I’m going to look at the referenced patterns near the bottom to see if he elaborates further.

I think the most important lesson I got from this pattern is not to make yourself useful initially, but make everything that you tinker with is as close to your best work as you can get it. Who knows who’ll be impressed?

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

As a team, we definitely pulled out a much better sprint this time around. Our communication was far better in our class work meetings, as well as outside of class work and coordination. I again feel like I could have done more, as the further into the project we got, the harder it was to come up with consistently good issues and epics. I personally felt a little apprehensive to add specific tasks because I was unsure of how applicable or useful it would be to the team. However, I think the team felt at least a bit similar as we really had to talk it out during the planning sessions to come to a satisfactory agreement. In addition, our ranking of weight on some of the issues and the organization of them was quite messy, which is something that we’re working to improve in the third sprint. Something I struggled with was understanding how to correctly implement the authentication token, and at one point accidentally broke our backend with sloppy implementation. In the future, I need to communicate when I add a potentially code breaking file, and I should absolutely be using branches instead of recklessly pushing it to main.

On that note, after getting more comfortable with the uses of git, I feel it streamlined the process of the work by a good amount for me. I’m still grappling with having some files pass the pipeline tests, and while I deferred to teammate help to fix some of the problems I should lean into really understanding the pipeline and how to properly upload and use the tool.

I also believe I wasted a good amount of time trying to implement the testing directory in the backend. In retrospect there was no way I should have continued to try and make it useful when there were other more important aspects of the project to finish up. In the future I should evaluate the necessity of my focus, as I straight up wasted a good chunk of some classes. In addition, I could have put more effort into getting some of the http calls to work instead of researching the token authentication. Another instance of needing to prioritize.

In my opinion I’m also not asking enough questions, and instead going to stack overflow or reddit for answers, which seem to be hit or miss. There is no reason not to differ to my teammates; this is something I should work on in general though as I don’t usually ask for help with things. I think I should also be pushing more files to the repositories, just to properly track my contributions to the project for accountability. I don’t believe my team feels like I’m not contributing, but just for the paper trail I should make it a habit.

Despite this post’s mostly critical tone, I actually think we did well this time around. I think the team was happy with what we all got done, and how we can maturely talk about disagreements. As a team, the only thing we should work on is properly creating and assigning issues, but I’m satisfied with our work aside from that.

Here is where I added schemas and paths for the token validation.

While not my commit, I helped the team to get the calls functioning.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

Here is when I added a few schemas to the API repository.

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Thea’s Pantry

Despite being intrigued by the many interconnected systems, it gives me a sort of confidence that people can overcome their current level of understanding which we’re comfortable with, and can confidently connect these differing types of information to make a solution that seems to be a logical conclusion. I have to admit that such data is something that may be inconclusive to my biases that hold me to my biased endings, but I always try my best to side with the morally better decision, no matter how difficult. I certainly acknowledge the difference of opinion, and the potential radicalization I may bring, but in the light of our current civilization, I only want the best for the people of my nation.   

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.