Author Archives: technickal4

Practice Makes Perfect

Practice, Practice, Practice is an apprenticeship pattern that is all in the name. The pattern encourages one to constantly practice their craft. The goal is to eventually rewire the way your brain works and thinks about things until it is old hat and you can move on to practicing something else. As a pattern, its uses and merits are pretty obvious. The more you do something, the more you get used to it and commit it to memory, and therefore the easier it becomes to do that thing again.

As the text highlights, an important part of practice is that it is not stressful. It is challenging for many to learn in a stressful environment where deadlines and other stressors may come into play. Therefore, it is important to separate your practice from your work. Although you can still learn plenty of lessons from doing things, it is practicing the basics that will lead to a stronger foundation to support new knowledge.

I could personally benefit from more practice. As I have moved on to more advanced topics in Computer Science, I have found it important to constantly refresh myself on other things that I have learned. It can be hard to try to retain so much knowledge, and I think employing more practice more often would help me with that.

A way I often practice is to repeat assignment I’ve done that I struggled with, especially before a quiz or exam. Doing the assignment over and over again helps the process become almost muscle memory and helps me retain the knowledge for the quiz. It is something I need to do more often, and during more times than just quiz or test periods, as I absolutely benefit from the experience.

Everybody wants to practice their skills, but sometimes it is hard to find really effective ways to do it. I certainly need to find more effective methods of practicing, especially when it comes to answering job interview questions, as it doesn’t seem to get any easier. I believe that in time and with enough practice, anybody can learn anything.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Friendly Ghosts

Kindred Spirits is an apprenticeship pattern that revolves around mutual progress through your peers. Specifically, it is about making relationships with people where you can learn things you find valuable from them and share your knowledge with them when they are in need of it. This is especially important if you feel like you lack mentor ship and are trying to improve with somebody else’s assistance despite that.

The ability to form mutually beneficial relationships is an incredible skill. I’ve found that some of my greatest opportunities and chances for growth in life have come from others. Often those people are mentors, people who are there to guide you on your path and give you advice. But there are also Kindred Spirits, people whose trajectory in life is similar to yours, and someone who can offer you a different perspective or introduce you to a new topic. Obviously it is challenging to cultivate the sort of relationships that fit this criteria, and a lot of it feels like luck, but those relationships in my life where I’ve been able to learn alongside another and share knowledge have been truly beneficial.

One thing I definitely have to work on is being comfortable with reaching out to others for help and forming new bonds with people. There are a lot of great students in the Computer Science department that have a lot to offer in the way of knowledge, ideas, etc. Being more involved with the community at large would help me better prepare and get a grasp on my future. I never know the kind of help someone could offer, so it is important to find out for myself by reaching out.

Overall, I think Kindred Spirits makes a lot of sense as a pattern from my experiences. Working with other people is such a great way to learn and be exposed to new ideas, and I just wish it was a little bit easier for me. It is something I have to work on, as there is a wealth of knowledge to be uncovered that is contained within some of my fellow CS majors.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Sprint Reflection 2

On our second sprint, Team FIG definitely got more of the ball rolling with our progress on the project. Following a meeting with a representative from the food pantry, we were able to discuss some of our stories and tasks and what each member was going to work on, and were able to begin in earnest. I felt a lot better going into this sprint as it seems our goals were becoming more clear and it felt like I knew what I could do to make progress.

My tasks was to begin work on a front-end system that the food pantry could use to keep track of the weight they are giving out and automate some of the process of filling out an intake form and determining the proper amount of food in weight. I referred a lot to my final project from CS-443 last semester, developing a sort of “back-end” that enabled me to test the functionality of my front-end. After that was squared away, I began developing the front end. Since exactly what the customer wants still doesn’t seem crystal clear to me, I thought it would make the most sense to take the provided intake form and try to implement it in an online application.

After I wrote all the functions to allow adding/changing of data in the back end, I developed the HTML part of the front-end, adding the input boxes and buttons for submission and making sure they used the right commands. Things I still need to add to the front-end are error messages for incorrect submissions (missing data, wrong input type, etc). It might also be prudent to add some way for authorized users to change customer information that has already been entered, in case of a mistake or changing information. I have also not began working with the CSS, as it has been low priority for me, and I have questions to ask about what sort of style we should be going for. I also have not done anything with keeping a running weight total or adding/removing from that total.

The current issue I am dealing with is a ‘fatal’ error preventing me from committing to GitHub that says the line endings need to be replaced with LF from CRLF, which seems to be an issue with the way Windows handles line endings. I decided this was a good place to stop anyways, as I was having trouble fixing the issue and had done a lot of work without being able to review it with my group. It is unfortunate that we have had three classes cancelled, as it definitely hurt my groups ability to meet up and their motivation to do so.

The biggest task our group has to work on now is creating a functional back-end that will be able to store the information. We have not determined exactly how this will be done yet, but it is something we will definitely discuss so we can begin work on it in Sprint 3.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Going Deep

The Deep End describes the situation where you feel like your skills have plateaued and you are having difficulty finding ways to improve. As it sounds, The Deep End is a pattern that encourages you to “dive in” to the deep end. That is, to take challenges that you know you could fail, knowing at least that you can learn form your failures and improve yourself as a result. It is not about taking uncalculated risks or lying to get opportunities, it’s more about taking on things that you aren’t certain you could do, but have the means to do so.

The Deep End is a pretty intuitive pattern. When you feel like you aren’t improving, push yourself in ways you haven’t before and turn it around. However, it can be very intimidating in practice to take on projects that you aren’t certain you can complete, especially if you think you have to worry about potential consequences. Although learning from failure is a very effective way of learning, it can also be very costly, and that definitely gives me anxiety.

That being said, it is important to take risks and leaps in my life and my career. It is the only way I am going to improve myself and get what I want, and being too nervous to take chances and opportunities as they come my way certainly wont help. I will make note of the lessons taught by this pattern and try to take more risks in the future. I think it will especially help me with my directed study this semester, which has begun to push me into learning many new languages and concepts all at once.

The Deep End is a cool pattern, and the it makes sense practically. Most people are definitely aware of the idea of taking on harder tasks to sharpen their skills. Most people want to improve, but it can be scary to tackle hard challenges and face the unknown. However, getting over that anxiety is crucial to becoming a smarter, more well-rounded individual. Life isn’t easy, and you need to be ready to solve hard problems at any moment.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Best of the Worst

This week, I read all about an apprenticeship pattern titled Be the Worst. This pattern details the benefits of being surrounded by people who are smarter than you and have more experience than you. The idea behind the pattern is that the more time you spend around others, the more information you can learn from them. Why spend your time figuring out a problem somebody already solved when you can learn the veteran’s way of handling it from a colleague? Surrounding yourself with more advanced developers can help build your skills and gain experience in ways you wouldn’t if you were learning concurrently with them.

This is a pattern I can absolutely relate with from experience. Some of my best classes where I learn the most are the ones where there are a few peers above my level to help me learn what they already have. Sometimes, the way someone explains something to you is difficult to make sense of, but another peer can explain it in a way that makes more sense and is easier to understand. Similarly, working with many people above your level gives you a wide variety of different methodologies and ways of doing things, which can help illuminate best practices and start insightful conversations.

The alternative, being the smartest person in the room, can be very unchallenging and doesn’t give you any room for development. It is nice to Share What You Know, but if that is all your doing it can be hard to progress your personal goals. A large disparity in the skill level of developers causes more time to be spent on closing that gap rather than working on the project at hand.

The challenge with this pattern is more the emotional toll it can take on you to be surrounded by smarter people. Being the dumbest person in the room can be beneficial from a self-centered learning perspective, however it can definitely feel a little embarrassing to be so far behind everyone else. Being able to swallow your pride for the development of yourself and the team is a challenge, but the rewards are worth it.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Sharing is Caring

This week I read about the Share What You Learn pattern. The pattern is all about sharing the knowledge you gain with your peers. After all, what good is all that knowledge if you don’t share it with the rest of the world? Making good use of the pattern ensures that you and everyone around you will be up to date with all need-to-know information, and gives you a good opportunity to both brush up on your teaching and communication skills and also discover what your peers know that you don’t. Everybody benefits when you share your knowledge, as it allows your peers to focus their efforts on other endeavors that haven’t been solved yet.

It is not always easy to share what you learn. Sometimes you are engrossed in your own work and don’t want to take the time away to help someone else. Maybe you think what you know is obvious and not worth explaining. Either way, it is always worth the time to help out your coworkers or fellow students. First of all, when you need help, it will be good to be able to rely on others. Second, everyone being at the same level opens up more opportunities for learning and growth.

My biggest obstacle with sharing what I know is how to communicate effectively. I am a poor communicator, and often lose myself over which words to say. It can be hard for me to effectively teach something to someone, especially with no time for preparation, as my train of thought tends to go all over the place. Knowing this, I need to work on methods of communicating information and think more carefully about how I am saying something and how it is being understood.

In conclusion, Share What You Know is a useful pattern, and one I aim to improve at. Sharing knowledge across a team is better for all the individuals involved. The more you know, the more time you can dedicate to your work and the more diverse kinds of problems you can solve.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Sprint Reflection 1

Our first sprint was rather difficult and unproductive. We did not start off with many clear goals, so we weren’t able to move forward much and had no clear direction. This is definitely a huge hurdle and one I hope we can get over soon. Our group would definitely benefit from clear, tangible goals and perhaps a little more structure. Other than that, we had many productive and insightful conversations about the needs and features necessary to the application we are trying to develop for the food pantry.

One of the things I worked on a little bit was trying to find a way to interpret the a data set so that we can further search and manipulate it. The data source was provided from our professor and our goal was to find a way to display that information in a way that could interact with a REST API interface. A great help to this end was an article found by group member Andy Pham. Using the exact code by the provided article works to some degree, although the field headers need to be changed to appropriately handle the data set for the food pantry project. This doesn’t seem like it will be too difficult moving forwards, although there is still a little work to be done in this department to finish it up. Overall, in this task I think we are headed in the right direction and nearly complete. However, I question how useful this work will be, as we may find out that a lot of this beginning work is already complete by another group or another university.

Another big goal of ours is to set up a server that can run this REST API so we can use it across the network. My team members have been doing research into what resources we can use and what would be best, however it is a choice that is hard to make when we cant consider any of the other needs of the project (yet). This server doesn’t need to be big or complicated, as with what we have we would only need to host a small data set as well as a pretty simple REST API interface to interpret said data set. However, we are unsure where this server will be hosted or who will front any potential costs.

It is challenging having no practical or finished work to show, as it highlights a lack of progress and means we have no reference for how we are performing. However, I think as the ball gets rolling and our project goals become clear we can build up momentum and reach our goals as they come to us. In the meantime, Team FIG has been using our time to discuss what we could potentially need to work on and other elements of the project. We have looked up different universities and food banks solutions and what programs they used to maintain their databases, and are considering what might work for our University.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Mapping it Out

The next apprenticeship pattern I took on was Draw Your Own Map. The premise is simple: you are the only person who can choose the paths you go down and which roads you travel. You should not leave yourself to the mercy of your situation and those around you to determine the course your future will take. Is is a definitely a pattern of self-determination.

The Draw Your Own Map pattern is absolutely useful. I have always been a person who has difficulty relying on others. Although I acknowledge this as a weakness in most ways, one way it has strengthened me is I usually don’t find myself depending on others for approval or assistance. If I want to do something with my life, or make some future plans, the only person I ask is myself. This independence and selfishness is important, in my opinion. There is only every going to be one person looking out for your best interests: you, and so therefore it is your sole responsibility to map out your future and make the decisions that will lead to your happiness.

Despite this, I do think there are limits to the pattern, even when applied to careers. For example, although your position in a company might not be immediately satisfying, with time there is potential to move throughout the company to a position that is better for your skills and abilities. There are some paths you can only get to by travelling on a bumpy, gravel road first. It’s not optimistic, or ideal, but the text definitely glossed over these potential scenarios where you prioritize long term gains over short term happiness.

Overall, Draw Your Own Map is not an interesting or a surprising apprenticeship pattern, but it is a hugely useful one and one I feel I’ve already been using to make college-related decisions for a long time anyways. Basically, only you can make the choices that will lead your life to happiness, nobody else will do it for it. Just as long as you are making ethical choices that don’t tread on anybody else’s map.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Doctors vs. Computers

The article Why Doctors Hate Their Computers by Atul Gawande discusses the issues many medical professionals have with the use of new and modern Electronic Medical Record (EMR) technology. The premise of the article is that the software used by doctors, surgeons, etc. to record patient medical information, schedule appointments, and pretty much every clerical medical function necessary.

The article gives a healthy dose of reasons why doctors have so many issues with this software. The big issue that many doctors had was ease-of-use. It can be especially intimidating for less tech-savvy doctors to navigate the system and work with the interface to do the things that they were used to doing by pen, paper and phone-call before. In addition, there are a number of quality of life improvements and minor issues with the system that add up and force doctors to spend more time than they’d like working on their computers instead of with their patients.

I consider accessibility to be one of the most important parts of a functional program. It doesn’t matter if your program is capable of doing everything it is supposed to; if it is too challenging to discern how to make the program do what you want, it might as well do nothing. “Accessibility” is a broad category however, and could be affected by user interface, design choices, and certain features. Making a system as accessible to its users as possible should be a priority in every project, as doing so greatly increases the effectiveness of your system.

Something I found frustrating was how important bureaucratic and political details were to the implementation of these systems. I’ve always found that all the regulation and red-tape, while obviously important, distracts from the main goal. The bigger problem is that with every project, so many different departments have different ideas and goals for what they can get out of it. However, compromise does not always lead to the ideal choice. I think it is important to consider the actual goal behind your product and weight every other goal based on how much it lines up with that one.

Interestingly, looking forward, this article has given me a lot to consider when working on the AWS Food Pantry group project this semester. I will definitely be trying to maintain the accessibility of whatever software we end up making, so that everyone who may find themselves needing to use it can. I am also going to try to balance the needs and goals of every facet that affects the project, whether it be regulation/law, customer needs, and the needs of the business. In this way, we can create the best version of the software we are asked to create.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern

The White Belt Pattern, as defined by Dave Hoover and Adewale Oshineye, is an apprenticeship pattern with the goal to learn new concepts or information. The way the pattern achieves this is by having the user abandon their previous knowledge and conceptions regarding the topic, and look at the topic from a fresh perspective with a willingness to learn, despite the potential difficulty and inefficiency of doing so. This comes in handy if you are trying to learn a new programming language or if you need to solve a problem using a new or unfamiliar algorithm.

I definitely can recognize times in my life where use of the white belt pattern would have been helpful. Often times when I’m working on a puzzling programming challenge, I try to think of it in terms of challenges I’ve had before and previous problems I’ve overcome. If I can apply a previous solution to this problem, wouldn’t that be the best way to do it? While I personally do still think this kind of thinking can be useful in reminding yourself of your steps to reaching a previous solution, it can also be distracting and push your mind in the wrong direction. Sometimes the best way to solve a problem is to approach it from a totally new angle and abandon anything you think you know about how to solve it. Some times it’s the knowledge you think is helping you that is actually getting in the way.

I can absolutely see me reminding myself of this pattern and its intentions in the future. If I find myself overthinking something, or trying to shoehorn a solution to a problem that doesn’t fit, I will try to forget what I know and open my mind up to new solutions and ways of doing things. Even outside of programming, freeing up some of my preconceptions on the ways I think things work could be very healthy. It’s important not to let our accumulated knowledge cloud our judgement and prevent us from learning even more. After all, if our goal is to learn, we should approach it from the most practical way possible.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.