Author Archives: iisbor

Sprint Retrospective – 3

For our last and final Sprint Retrospective, we had a much shorter sprint, which made things quite a bit different from the previous two sprints! For one, it made things feel like much more of a time crunch, but at the same time, there was much less to do during the sprint.

Overall, despite only have about four issues, we still had a slight misweighting of one of them! But at least, we still had about a 75% accuracy in terms of our judgment! It could be much better at 100%, but it’s still much better than our sub 50% weighting of our first sprint.

Our biggest issues was working with making a testing suite in Chai. This was mostly the work of Andrew over the past few sprints, but since our last sprint had only a few issues, we were all able to jump on board. Sam jumped on first, since he was the most open, while Moses, Anesti, and I worked on more pipeline stuff! With a bit of luck, Moses cleaned out the pipeline issues, and so we all jumped on the Chai testing and… Boy, did it take a while to figure out. The main thing we realized was that our earlier sprints led to our downfall! Because we were less experience during our first sprint, we made mistakes to the Reporting System that made it so that our whole system was broken! But thankfully, we managed to figure things out by the skin of our teeth and get things resolve on the literal final day of our sprint! It was a close call, and to be honest, I think despite our mishap, it was within reason since we simply couldn’t have known what we did not know yet!

Overall, I think that our group did as well as could be expected, and as we developed as a team for the final sprint, we still were able to expand upon our abilities despite the short amount of time we had left. I think that our communication was at a high for the final portion, and if we could have kept going, I think we could have really done even more for the Reporting System. Regardless, I think we did well! Individually, we all steps up, and as a team, we all came together to help one another.

If I had to point to one thing that could have been done better, was to make sure that we verified our system before moving further on. Maybe as a side issue, someone could have checked over that the things we did in the past Sprints would not negative affected our future progress, but that would be a bit hard to do since we were still learning the ins and outs of the Reporting System. There might even need to be some sort of oversight, but I would consider this more of a nitpick than a real problem as we were still able to identify our problem thanks to our version history.

Since we didn’t have many issues, the only issues I had was This and then These were the collaborative issues.

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Draw your own map

As the semester comes to a close and I’m getting ever so closer to entering the workforce, the Draw Your Own Map pattern stuck out to me most. Especially since there is much unknown coming soon, and as I start my career, I am sure that I’ll encounter many situations that I would not expect or be familiar with.

Essentially, the Draw Your Own Map pattern deals with your goals and how you achieve them. Although it might be straightforward and easy to say, I want to be at XXX company in X years, or try to save YYY after Y years, it is much harder to break down the smaller short term goals, and that is what the Draw Your Own Map pattern deals with.

As important as it is to have long term goals, without the smaller steps along the way, you might find yourself lost as you pursue your dreams. Not only that, but these small steps allow you to formulate or cement your long term goals too! For example, if you find that as you work on your short term goals, you might realize that your goals in the long term actually aren’t where you want to be. It’ll allow you to pivot if you need to, and if you find that things are perfectly fine, then all the more reason to keep on striving for what you need to do!

Another important part of the pattern is that your map is connected with many other things in your life. A solid map will allow you to connect with “Kindred Spirits” or it’ll give you more “Sustainable motivations.” It’s all interconnected! A solid map will be your road map to course your journey, and though you can never plan for everything. After all, a map with some directions is better than none at all!

And finally, though I realize the importance of a map, if anyone is like me, I think it is also okay to NOT have a map. At least, right away. A map should be made soon, hopefully the earlier the better, but things are always unknown. It’s very easy to just say hey, do this, or do that, but in actuality, it is a bit more difficult. Especially when it comes to something as important as the course of your career or even your life. Instead, it’s okay to make a smaller map. Whether it be a map charting your next 100 steps, or a map for your next three, the point is to just draw a map!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Retrospective

For this sprint, overall, the team work significantly better. Not only did we continue to communicate well with one another, but there was a lot of improvement because we were much more experienced with the project. Not only were we more familiar with the coding side of things, but since we had a much firmer understanding of SCRUM as a whole, it allowed us to skip through a lot of the learning process that happened in the first sprint and get right to work instead.

For one, we had accurate weights for almost all of our issues. This is a huge contrast with Sprint 1, as Sprint 1 was littered with issues that should have been weights of 2-3, but instead they were 1s. With this more correct weights, we were able to delegate a lot better, and we also were just more aware of the types of problems we were facing. In Sprint 1 for example, I had moments where I picked up a ‘1’ weight issue, only to be stuck on it for almost a whole week or more because I had to learning about how things worked. Now in Sprint 2, because I can skip a bit of the learning, since I had already did it during Sprint 1, many of the ‘1’ weight issues were actually ‘1s,’ thankfully!

On top of being more familiar with the code and the SCRUM process, we realized that we as a team, did not focus on the issues as heavily as we should have. Although we worked as a group somewhat in Sprint 1, Sprint 2 was much much more collaborative. We realized that the system is a lot more interlocked than we realized, and because of that, if Sam was working on one portion of the API, Moses might have insights, or vice versa. Many instances of issues being tackled was one of us starting it, and another member jumping in and finishing it together.

Other than the improvements in understand and our teamwork, I tackled setting up the Reporting Integrations repo. I figured that since everyone was working on the API, Backend, or a mix of the two, it would be a bit easier for me to tackle the creation of a whole separate part of the Reporting Systems. I think, this was for the best because although help might have useful at times, overall, I was worried that since the Reporting Integrations was going to be made from the ground up essentially, it would become a situation of too many cooks ruin the pot. I am glad I did this because once I set up Reporting Integrations, I had a very solid understanding of the different tools that we used such as the Pipeline, and with that understanding, I was able to help much of the team with some issues.

Pipeline updates
Reporting Integrations
Multi-Architecture Conversion Backend, Frontend, Swagger CLI

After that, things became much smoother as people collectively got a hold on the issues, and though we are still lacking experience in many areas, it feels like we have a better grasp on everything as a whole. I think that moving forward, we should keep our pacing, and improve our communication even more potentially. I do really enjoy how we are much more collaborative on the different issues, and though sometimes we have to focus on our own task, the team work aspect is very refreshing and helpful. We are almost like each other’s rubber ducks.

Somethings that still aren’t too good is that we still only focus on working together when we are face to face, but I think that is overall fine. It could be better if we paired up, or had meetings outside of class and would make things smoother, but things are passable. Also, this isn’t exactly our whole responsibility either!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Reflect as you work

So far, of all the patterns I’ve encountered, Reflect as you work seems to be the one that can be most easily tracked in a more concrete form! This is very interesting to me because many of the other patterns deal with almost abstract topics, whether it be considering how you yourself grow, or how to approach learning, it is usually hard to determine your growth, but Reflect as you work makes a tangible ‘map’ that someone can reference!

Reflecting as you work, to put it simply, is the process of making some sort of way to track what kinds of things you are doing. It seems like it could be a map of your skills and process, or it could be a variety of other things. But essentially, as long as you are making a way to visualize the types of skills you have, it is a way for you to go over each of those different skills and see if things are working, or if they are counterproductive. An example that was made was that if someone made a map of these skills, they can go over them as time goes on, and though this process or that approach might have worked in the past, it might need to be updated, or transformed all together.

Overall, this is something that I have never really thought about doing, but it seems incredibly helpful. No doubt, if I made a map of my own skills to reflect on, it would make it blatantly obvious to see which things I am lacking, or even better, which things to improve on. Already, I have an idea that my algorithm skills are a bit lacking, but I am sure that there are other things that I can improve upon as well. With the creation of a visualizer, I can much more easily reflect on the type of work I am doing, and overtime, I can also see if the things I am doing are good, or a bit flawed. I know for a fact, that if I looked back at my older works, I’d be complete horrified by some of the ways I fixed problems, and I know that in the future, it will be the same! This process of reflection is usually just internal, but with a concrete tool to use, it would probably be so, so much easier.

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Unleash your enthusiasm!

As I was going through the patterns, I came across the Unleash your enthusiasm. At first, I didn’t consider it too much, and took it at face value, and as it was explaining the pattern, I was frankly confused. From my perspective, it appeared like the author was trying to curb a bit of enthusiasm rather than nurture it, but there is actually more nuance to the whole pattern than it seems. Rather than the pattern being all about your own enthusiasm, I think that this pattern has much more connections with the team aspect.

The pattern does briefly go over this, but if you’re anything like me, it might have flown over your head, but I believe that this key fact is very important to processing the pattern. Mainly, if team morale is low, or if they aren’t as accepting, there are other ways to unleash your enthusiasm without compromising the team dynamic! I believe that out of the few patterns I’ve gone over so far, this pattern is the most grey! There is no definite answer to each and every team that you might join in, because there is just no ‘correct’ way to deal with people as a whole! It is very important to adjust your own standards, and thus, adjust your own enthusiasm on a case by case basis! Some people might be more receptive, while others might not be as receptive, but either way, it is important to find out beneficial ways to unleash your enthusiasm.

The pattern has a small action portion, but I believe that there are much more ways to show your enthusiasm! I think that if your team is not as receptive, you can show your enthusiasm by finding peers, or other like-minded communities! And if your team does welcome it, then there is no harm in showing the interest you have! Being able to find healthy ways to channel your enthusiasm will benefit not just yourself, but the whole team! As it even states, unleashing your enthusiasm will ensure that new perspectives aren’t missed, and with plenty of questions, everyone will grow! Staying silent would only be a detriment, because if you spot something that others might not, or if you keep questions to yourself, you won’t be able to reinforce ideas and also actively prevent yourself from learning! 

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Learn how to fail

To relate it to coding, like a few of the other patterns, if all one does is stay within their own box and safety, they will forever become used to their own skills. Hard problems might never be solved, even if the person is capable, and mediocre designs will stay mediocre. Failure is scary, but without failure, you can simply never know what you did is right or wrong. From failure, people are able to overcome their limits and grow! For example, there have been countless incidents where programming interns messed something up, like most recently, a Starbucks intern sent a out a test post publicly, and although I am sure they were worried, it is probably something they will never do again! These failures is what helps you grow as a programmer and coding, and it is so important to learn from these mistakes. In my experiences, if I didn’t mangle this project or mess up that problem, I think I would not be where I am today. I still have much to learn, but if I stumbled into one solution after another, I think I would be a very very poor programmer. By far, I have learned infinitely more from failure than I have from success!

Failure as a whole is not something that someone should be ashamed of, but something that someone should be critical of! If you fail, why did you fail! What will you do to prevent it next time, and what will you do if you keep failing! These are all important steps to learn, and as one becomes more familiar with each step, failure will become rarer and rarer. I personally don’t think anything can ever be perfect, but with enough time and dedication, things can come very close! And that is something that I believe everyone should strive for!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

For this week, I am going over the Sustainable Motivations pattern! To me, this pattern was both a bit confusing and also impactful at first! I felt that I had an idea of the type of guidance it was trying to show me, but at the same time, I felt that parts of it were a bit conflicting or irrelevant. That is, until I went ahead and tried it out in practice.

Specifically, the pattern calls for writing down fifteen (15) things that motivate you, then write another five (5) after waiting for a bit. Then, compare how different the two list are and what percentage of them are composed of external sources of motivation. Then, from both list, take the final five (5) that most motivate you.

From what I understood, it was trying to get you to differentiate between sources of motivation that are from your own self vs motivation that is pushed on by others, and also, ensure that the reason you continue to pursue programming is healthy. As it says right in the name, it is important to have sustainable motivations.

For example, if someone has, an ‘unsustainable’ motivation, they will be more prone to burn out, or even quit, but if someone has sustainable motivations, then even if they encounter difficulties in their work, project, or anything similar, they will continue to keep moving forward. This is obviously crucial, but the one part that I found a bit confusing at first was that I didn’t realize that external sources of motivation can also be fine as well as internal. I had assumed that all external sources were bad, but after writing down my list, I realized that, well, it’s okay to be motivated by those around you. It would be important to always have self confidence in yourself and it is important to continue coding because it is fun, or exciting, but there is no reason that you cannot have a healthy motivation because you want to follow in so and so’s footsteps because you respect them. From what I gathered, the pattern is not about internalization, but about a healthy balance of motivations to fight against burn out and stagnation!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Dig Deeper Pattern

Over this spring break, and after the first sprint, I had the realization that although I was able to grasp a lot of things, I felt that I had only a surface level understanding of many things. For better or worse, being thrown into the deep end of a project like Thea’s Pantry has made me come to understand that, although I do know a bit, and I also know that there is plenty I don’t understand, there is still much, much to refine before I truly believe that I can be capable.

The Dig Deeper Pattern seems to reflect my ideas. The Dig Deeper pattern establishes that you should try to become even more intimate and familiar with whatever you are working with. If, like me, you run into the issue where you feel like you have learned a lot, but then when push comes to shove, you become lost, then you should try to dive even deeper into the concepts and code. As it stands, Thea’s Pantry is almost like a trial by fire, and though it is difficult at times, and I feel lost, it is also the perfect time for me to truly learn the ins and outs of a project like this. Not only would it be helpful, for obviously my grade, but having a firm understanding will allow me to use my experience in all kinds of projects for the future.

Although I am still a bit lost, I am hoping to really push myself after this break with a refreshed mind and a motivated focus to dive deep into the code and start expanding my knowledge to the best of my abilities. I would go as far as saying that it is crucial to dig deep! From my experience in other things, the more fully I understand something, the more I will be able to intuitively solve problems. Even if these are problems that I have never dealt with before, if I am capable of understanding how things work, I can slowly track the issue down to the source, and eliminate it there! At least… That’s the hope! So, wish me luck!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

This week, the first sprint has concluded! And boy, there was a lot to learn and improve upon. For one, within my group, I was the Scrum Master, and it is a bit harder than I anticipated. I had some ideas to organize coming into it already, but sometimes, ideas don’t always meet with reality. At times, things were really effortless, and at others, they were rather difficult.

Some things that worked really well, was the overall organization. As a group, I realized that we were all heading into unknown waters, working with a code base that, though we had some idea of, in reality, we truly had no idea how much of it worked. Because of this uncertainty in many areas, I knew it was crucial to try and share our knowledge with each other as the sprint progressed. Some of the biggest boons, and though it was a bit of luck as well, was splitting our different members into the different portions of our issues.
As an example, we had a cluster of issues in our frontend, backend, and API that dealt with the same thing. Essentially, we had to update/add lots documentation, licenses, etc! This looked very simple at first, but there was some difficulty with clarity, since we simply weren’t familiar with what the specs were. We split three of our members into the three issues, and as we worked on the issues, I made a effort to make sure everyone is keeping each other updated, and this allowed us to realize that despite it being the same issue, we were actually doing things differently from one another. This allowed us to quickly establish what we should do as a group, and from there, we were able to progress forward without additional confusion.

Although things did work well because of our constant sharing of what we learned, not everything went smoothly. Some things that I tried to do as Scrum Master was make sure my group was not overly pressured or crunched for time. In my initial thoughts, I figured that we would have enough ‘brawn’ to sort out the issues with some commitment, and knowing how stressful a time crunch can be, I was very, very lax at times when important issues were being resolved. This relaxed attitude helped with the team morale, but it also did not do much to help with the issues and even stalled some issues. Moving forward, I hope to strike a balance between calming the team when things are not coming to a close, and trying to nudge them forward more when the deadlines are approaching.

As a team, I genuinely believe that we did very well. The biggest flaw in our teamwork, was not actually when we collaborated, but some team members doing things on their own, but these were only very minor issues such as changing issue names without telling anyone, which caused some confusion, as well as encountering a problem and trying to fix it without telling any other group members. Both instances, were very minor at best, and as soon as they were noticed, were stamped out already. Specifically, we know that moving forward, all group members need to try to communicate problems with the team before silently fixing them, and if a issue needs a new name, the new name needs to properly describe what the issue is.

Individually as well, I believe that I was very caught up with making sure that the team functioned, and though that was a great thing, it also negatively impacted my performance as an individual. I oversaw much of the progress, and was kept updated on how various systems worked, so I believe I have a good understanding of how the project works, but I have very little real work to show for it. Moving forward, despite being the Scrum Master, I have to not only manage the group and keep an eye on things, but also use my own abilities to push things forward.

Finally, as much as there was lacking, I believe that moving forward, things will be much smoother. Our group has many great developers, and this was our first time doing a sprint. I already have many ideas on how to improve, and though it might be a bit of trial and error at times, we as a team, have all the ability to clear out our issues!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Exposing/Confronting your Ignorance

Although we’re supposed to write about one pattern per blog post, I couldn’t help but feel that these two patterns are interlinked with one another. Exposing your ignorance and confronting your ignorance goes hand in hand with one another, and I believe that it is difficult to write about one while excluding the other. These two stuck out to me because it is something that I have recognized in myself.

While in the process of looking and applying for jobs, I realized that though I have many good traits as a programmer (hopefully), I am also lacking in a lot of things as well! I noticed that my knowledge of algorithms was much lower than I would like, and in pursuit of growth, I started to ask my friends for advice and help. I was exposing my ignorance to those around me in hopes of getting better, and though it was honestly a bit worrisome since I didn’t want others to think less of my abilities, I knew that it was the right thing to do. Like described, there is a balance to exposing and confronting your ignorance. If you simply expose your ignorance without any attempt to confront it, it leads to only helplessness and you become a burden, while if you don’t expose your ignorance and try to confront it, it leads to situations where you might hoard knowledge and create a culture of only success despite failure being essential to the learning process.

In my case, because of my exposing of my ignorance, I was pointed towards various resources that would help me up my algorithm design. For one, I think most people know about leetcode, but I also learned about Code Signals! These two are very similar, but I much prefer Code Signals as it feels a lot less intimidating to start with. It does not have as big of a wealth of different problems as leetcode, but in my opinion, it is much nicer to start with.

Then of course, with these resources now known to me, I started to confront my ignorance! I start to work on my faults through these websites, and though I still think that I am rather lacking, I know that I am a bit further down the road than I was before. I highly recommend anyone who might feel their skills are bit lacking to do something similar to me! At worst, you keep your skills honed and at best, you learn so much more than you could possibly expect! I know I did!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.