Author Archives:

Introductory Post

Hello, Welcome to my blog. Here I will be discussing topics covered in CS-343.

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

Data Structures Primer

I’ve been a tutor for this past semester to students taking Introduction to Programming. Many who have come to my session are moving on to Data Structures next semester. They asked if they could have a primer as to what to expect.

I have some resources that I have found helpful both while taking the course and tutoring it in the past. It will take me a little bit to compile a good list of those, but for now, here is a bare-bones list of topics of topics you might expect to see for a data structures course:

Part 1:
– Running time of code segments (Big-O Notation)
– Abstract Data Type (ADT)
– Interfaces (when to use “implements”, cannot instantiate them, what inheritance is)
– Superclass, subclass, method overriding/overloading
– Abstract classes

Part 2:
– Binary Search Trees
– Stacks (and its four methods — push, pop, peek, empty)
– Linked list (single, double, circular)
– Prefix and postfix notation (compare to infix)

Part 3:
– Min/Max Heap
– Hash Tables – Open and closed hashing. How to insert into a hash table given a probe sequence.
– Binary Trees (AVL and Red/BLack)
– AVL Trees – how to construct one, worst case AVL-tree
– Red Black Trees
– B-Trees, especially deletion from one
– Know recursive code and how to trace it

Bear in mind, this is an incomplete list. The topics may be presented in different order as well. The “parts” are how I remember it and might not be accurate.

I’m not sure if I’ll be able to compile a complete list of resources, but here is probably the best one for visualizing data structures: https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

Another one is CodingBat.com/java. This is especially helpful for learning recursive code. I don’t know if any of the other sections would be helpful, but they might be.

Best of luck! It will be tough, but you got it! Even if you know one or two topics from each part, you will have a leg up on learning this material.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Learn How You Fail”

For the final pattern that I will be writing about for this capstone, I wanted to write about something that I’ve felt for a while, but I did not know if my intuition was correct. I picked this one because of this line, “someone who has never failed at anything has either avoided pushing at the boundaries of their abilities or has learned to overlook their own mistakes.”

I feel that I have faced setback after setback in my life. I like to believe that it helps make me into a better, stronger, and more resilient person. When I struggle to learn something, I find that I understand it more thoroughly than if it came easy. It will also be much less likely to forget.

The struggle is something to be embraced. It should not be a reason to give up. On the contrary, it should be a sign you’re going in the right direction. It’s like a video game where you’re not progressing in the level if there’s no bad guys in the way.

I thought the “action” piece that the authors suggest is an apt one. The long and short of it is that to practice, you should use a text editor instead of an IDE to write an implementation of an IDE in one sitting. Since there is no IDE, it might catch the errors that you would have otherwise overlooked. I have not started studying for my Unix final, and this might be something I might try. However, I think we’re mostly doing things with shell scripts and the like, which is somewhat like a text editor anyway.

I think this pattern goes well what I wrote about in my retrospective just now. For as much as I enjoyed working with my scrum team, we were not perfect. Reflecting on how we fell short will ensure that the next team I work with will be even better.

I find I perform best in the areas that I have reflected the most. A part of it feels like neurotics, but it is important to do it. I reflect on most areas of my life, whether or not I am graded or paid. I feel that it is an important step to self-betterment on the way to self-fulfillment and mastery.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

At the very beginning of this sprint, on April 25, Mia was able to push the portion Dan worked on (“Tabs2”) so that we could all see it. Up until this point, the rest of us were not on the same page. We were looking at a previous one we had come up with. We were instructed by Mia to hang tight until she was able to push it.

Ryan and I were both unsure whether she would be able to, so we talked about doing it from scratch. That night, I started the process, but I didn’t get far before Mia let us all know that she was able to get it pushed. At that point, the majority of the component was done. I noticed that the button to create new slides was broken. It was a small fix, but I was able to fix the bug.

Most of this past week was preparing for the presentation. I feel somewhat that I was under utilized and that I could have done more. It is not that I did not want to do the work. I offered often to do more. Once I was able to see the component, most of it was done.

I suggested starting development for another component both before the first was completely complete and after. I was discouraged by my team from doing so. I feel like if we had, we could do at least one more component. I feel that even if we got a start and was unable to finish on another, it wouldn’t be much of a loss.

In the last retrospective, I felt different and that we should just focus on one thing and do it well. I did not realize how far along we were. (Again, I was not able to see it.) I feel that we could have easily done another component in this last sprint and a half. However, hindsight is 20-20, and I didn’t know then what I know now. This was the first time any of us had done something like this, so none of us knew what to expect.

Despite my regrets for not being able to do more, I feel this overall has been a positive experience for this entire capstone. I will be able to take what I have learned here and apply it to the next scrum team I work with. We have not been perfect in communicating, but we have done a pretty good job overall in keeping each other updated. I think we all have seen where we have fallen short, and I think we can use our failures as learning experiences.

Some of our problems came when one of us would run into a problem and the rest of us could not see what they were dealing with and, at the same time, be relying on that work. It would create a bottleneck. It was very frustrating for me to not be able to help in any way when it came to this. I am not the kind of person who likes to sit idly by when I feel I could be of some help.

What I can say about my team is that none of them are slackers. It isn’t often when I feel that I am not the one shouldering most of the work in a group project. This was a welcome change of pace, even if I wanted to contribute more. I found that in a group like this, I should have taken initiative sooner and more often. That lesson will be crucial to success in my next venture.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Sweep the Floor”

I skimmed through a few apprenticeship patterns before I found on the one that hit home with me, “Sweep the Floor.” The “problem” it presented was something that I am faced with starting every new venture at this stage on my journey. It stated, “You are a new apprentice on a project.” No matter where I go, this will describe me.

I have talked in my last apprenticeship pattern blog that I am starting as an intern at a friend’s start up, and I will be taking the advice presented here and applying it to this and the next venture I go to afterwards.

The solution advocates for doing the “simple, unglamorous, yet necessary, tasks.” It is tempting to do the opposite and try to do the “fun,” “exciting” things, but it stresses to not to, and prove yourself through the small tasks.

I have had the thought that in most fields that you don’t need a degree for, one would start at an entry level job. From there, they would work their way up. The stories friends have told me about their grueling interview processes scare me. I would prefer to start at an “entry level” position over starting off with a position that I feel way over my head.

I know I have talked here in the past about apprenticeship patterns that advocate for taking on big assignments even if you don’t feel ready — the pattern “diving deep” in particular. However, I think that diving deep comes after you have laid out the foundation with this pattern. I’m going to try to not let the bigger tasks intimidate me, but i won’t think that the small tasks are beneath me.

On the contrary, the small tasks are incredibly important — not just for the use of the company, but for learning new skills. The pattern did make a point to say that many who have spent a lot of time and money getting their degree might consider this beneath them, but I don’t feel that way. A little over a year ago I was working fast food, taking out the trash, and literally sweeping the floor. I was happy to literally do it then, and I will be happy to figuratively do it for any company that accepts me as part of the team. I want to be a team player, and I will be glad to do small tasks that are important to the team. Moreover, I will volunteer for them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.”

I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse.

The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left.

This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would assign you a task based on your strengths and weaknesses. Once you have finished your mentor will review it and point out areas for potential growth the next time.

A important distinction the pattern makes is that we cannot use our profession to practice because when you practice, you make mistakes. You need to find time outside of your work session and make those mistakes when you practice.

I realize having a mentor may not always be realistic for everyone. However, I think I have a way to practice this over the summer. I have been talking to one of my classmates who has started a small consulting company. He offered me a position if I was interested, which I am.

They are currently is contracted by my alma mater, Quinsigamond Community College, to keep track of the information that is collected by their greenhouses. He has hinted that he might look to expand it if he is successful.

I feel this closely fits to what the pattern suggests. I will have a mentor. I will be practicing my skills and having close feedback. I will have room to make mistakes as my status as their employee does not solely rely on my performance. Don’t get me wrong, I still want to do a  good job, but it is not extremely high stakes. There is also the freedom to work when I choose, so I won’t be constrained by time, especially when I am going to be lifeguarding and taking a summer course. I am excited to begin this new chapter in my life — a new step on the journey towards mastery.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint.

My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close.

I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort.

I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few venues of communication, using the most appropriate for what we need. Most days, we have been back and forth in a group chat. Whenever we find resources, we add it to a Google Drive document.

The days of our classes have been incredibly productive for the most part. I am surprised what we can get done in a little over an hour. When I play around with parts of it on my own, I find I hit walls more easily. It is great to have the shared pool of resources to help each other out.

We have largely been working from the official Angular guide to how to work with tab components. We found this very early on, but it has been our primary guide to everything we have done so far. The great thing about is that we have a few different ideas of what we want the final product to look like, and there are examples with all the code we need to do what we pick.

I think the most important thing we do when we plan this last sprint is to finalize what we want the end product to look like. There is an idea of having a button to add a new tab, but we don’t have a clear idea what the content of that tab will be if we decide to go that route. It is key to plan it out fully before diving in so we don’t waste any of the little time we have left.

A part of me wishes we could have two more sprints after this, because once we finish this component, I would like to continue to try to create another after this. Perhaps, in a way I can. Even if I do not continue working for this project in particular, I can use all the skillsets that I have picked up to continue to work on project just like this independently.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Stay in the Trenches”

The long and short of the pattern is to not accept a lucrative position or promotion if it takes you away from practicing your technical skills. If those skills aren’t constantly honed, they will be lost or become outdated before long.

A family friend was a midlevel manager at a software development company before he was laid off. He had gotten away from doing the technical work. The trouble was that most companies promote from within, so it was hard for him to apply for a job that he had before. It was also hard for him to start a job doing the technical side because those skills weren’t as fresh in his mind. There’s a good lesson to be learned from his story.

I often hear from people complain their manager is out of touch. The pointy haired boss  from Dilbert strikes a chord for so many for a reason. Perhaps more fitting to this pattern is The Office’s (U.S.) Michael Scott. While he has his moments, he is by in large an extremely incompetent manager. However, he does go on some sales calls in the series, and it is clear that he is a brilliant salesman. It seems that it is common that people are promoted to the point where they are inept at that position and advance no further.

Although the pattern does not quite suggest that people are promoted until they aren’t the best managers they can be, it seems to suggest that if you are no longer using your technical skills, you will become more and more out of touch with that side. You will no longer be on track to become a master craftsman when you accept this route.

I do not want that to be me. I would like to continue to grow and learn. I have talked to people who have a technical background and become something else, such as a salesman or manager. I have been tempted to take this route. I am not saying that I won’t do something similar someday, but for the time being, this does not fit into my goals.

My goal is to become a master craftsman. I’m aware goals change over time, but I would like to pursue this for a while before reassessing. I feel as though the reason I would change tracks if I found that this career was no longer what I wanted. I don’t think that will be the case, but it is a possibility. The one thing I know I won’t do is change tracks if I’m happy where I’m at. Sometimes what seems like the logical next step to advance your career can actually be more of a step back. It is best to instead to choose the path that will lead you towards becoming a master instead.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The Long Road”

I once watched a video by a self-proclaimed “lifehack guru,” where he talked about what he claimed to be a revolutionary new way to “think stuff done.” I always take ideas like this with a grain of salt, but in this particular video, I thought there was something to the advice he gave.

He said to look at your cluttered desk (or area of your choice) and to imagine it clean. The important part is this: you pause and take some satisfied breaths about how good it feels to have a clean desk. Note you have not done anything yet, but you feel the satisfaction of what it will feel like when you are done. Already, you should find that you have, without meaning to, probably thought of a few steps to achieving it.

That’s a long way of getting around to introduce the pattern, “The Long Road,” but the action that it suggests feels very similar. It suggests to imagine your future ten years from now and further, even the most far fetched version, and use that thought experiment to help plan your future career choices.

The “guru’s” advice was surprisingly helpful for doing something as trivial as cleaning my desk. I keep that advice when I do a lot of tasks now, even years after I have last watched it. However, so far I have only used it for short term and slightly longer term tasks that I need to do. I have not thought about applying it to something as significant as career goals, as the pattern suggests.

The pattern talks about keeping your sights set on the long term. This is something that I have been neglecting. I keep my head down and work hard on what is in front of me, but I don’t often step back to see the big picture. This affects me because when the pressures of school or elsewhere aren’t there, I sometimes don’t know what to do with myself. Without something assigned and a deadline, I can sometimes waste my time because I haven’t set myself goals.

It can be hard to set goals without the long term plan of where you want to take it. Otherwise it seems meaningless. What I liked about the guru’s advice was the pause to meditate on the moment where you accomplished your goals and hold that image. Although that is not mentioned in the pattern, I will use that step as I map out my future.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group.
Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want.
Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.”
I failed to make a successful working prototype that did everything I wanted. It seems that I have less knowledge of how all these work together than I thought. This brings to mind the apprenticeship pattern mentioned earlier, “breakable patterns” — I leaned through failing.
I will return to the Angular “Tour of Heroes” the next day or two to fill in the gaps in my knowledge. I don’t think there’s very much that I’m missing, but what I am is important to making it work. I would like to do this as soon as possible to be as much of a useful contributing member of the group as I can be.
Last retrospective, I was optimistic about how much we would be able to do this sprint. In truth, I am a little disappointed that we were not able to complete as much as I hoped. I am still optimistic about what we can accomplish coming up, but I have to bear in mind there are only two sprints left.
I am hopeful we will get a lot accomplished, but I have to be realistic that it might not be as much as I would like. This is the time where I should be thinking about buckling down and dedicating several more hours per week on top of what I already dedicate to this class.
I do have to keep in mind the learning curve we are experiencing when working on a team project like this. It took us a long time to just get the program to build and run on our computers. We didn’t hear what we wanted the final product would look like from AMPATH until relatively recently.
However, I think we are approaching the end of the end of that learning curve. Once our scrum team gets one component finished, I am confident the second will come a lot easier. It is reasonable to hope we are able to do a third, and maybe a fourth if we we split up into smaller scrum teams. Anything beyond that might not be wishful thinking, but I learned my lesson for setting my expectations too high.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.