Author Archives: technickal4

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.

Apprenticeship Patterns

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye introduced me to the concept of an apprenticeship pattern. The first thing I thought of when I read the title of the book was the Gang of Four patterns that I became very familiar with in my previous semester. It is not surprising to me that many different work concepts and processes can be summarized by different patterns. Humans are pretty habitual, and we are good at finding out what works. With this in mind, I have a great amount of faith in the value and usefulness of these patterns.

The chapters following the introduction begin to introduce us to some of these patterns. The patterns that were introduced all have a lot in common. The most important thing seems to be the willingness and the drive to learn, independently of an instructor or master. Another important concept is the ability to get rid of preconceived notions and past knowledge that may not be as relevant or helpful as one might think. Wanting to learn and having to learn are two different processes and they will have different effects on your progress overall.

The short story about the master and the student at the beginning of Chapter 2 did a great job at illustrating an issue I run into a lot, being that it is hard to learn new things when you already know so much about something. Your previous knowledge definitely colors your perspective of new, similar things, and it can lead to a lot of dangerous assumptions. As scientists and engineers, we should never be making assumptions!

Another concept that showed up time and time again was not being afraid to fail. This idea is really close to me, as I have always believed that you learn a lot more from terrible failure than monumental success. There is so much value in learning how things can go wrong. That’s why chapter five definitely stood out for me. Anyone who thinks there is nothing more to learn will avoid all knowledge to prove themselves right. Every person you meet, whether you consider them above your level or below, has some new knowledge and information to offer from their experiences.

Overall, I think the book is a well-researched and accurate observation about the patterns of work and learning that fall behind “apprenticeships.” We can use these patterns to better understand how we work, as well as where our work can go wrong. Once we are able to acknowledge things about yourself such as your skill level, knowledge, and experience you can perform better and learn to learn so you can be the best version of you. You can’t improve until you know what improvement you are capable of.

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.

Software Capstone Introduction

This semester, I begin my software development Capstone, where I get to work with my peers on a semester long project. I will be making posts and reporting on my progress periodically throughout the semester on this blog, so keep up if you’re interested.

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.

Two-Factor Authentication

For my final blog post of the year, I wanted to select a more interesting topic. The article Two-Factor Authentication with Node.js by David Walsh covers two-factor authentication and shows how it works behind the scenes using JavaScript. He even includes examples of how to implement two-factor authentication using QR codes.

Two-factor authentication is a user-verification method used by many web applications and services today. When a user tries to log in, a verification code is sent to a previously specified external device or address, such as a phone number or email. This code usually expires after a set time. The user that requested the code then enters it in the application or program to verify themselves and gain access to their account. By splitting access to your account into multiple different forms, you greatly increase the security of your account. Nobody can log into your email, even if they know the password, if you have two-factor authentication that is being sent through SMS.

David Walsh explains how the system of two-factor authentication is divided up behind the scenes. The first step is to generate a secret unique key for the user to validate two-factor authentication codes in the future. Then, you must add the site to your authentication. Finally, this code must be provided by the user and then validated to confirm it matches what was expected. If not, the user can try again with a new key. Since most two-factor authentication services refresh the key every few seconds/minutes, it is not necessary to lock the user out if they get one wrong.

Two-factor authentication is an incredibly powerful and important new form of security that allows you to put an even tighter lock around your information. As a developer, it is important to consider allowing your users to use two-factor authentication for your application, especially if any sensitive data is stores or if access to your account leads to vulnerabilities in the system. It’s one of those things you don’t realize is so important and valuable until you get your account stolen and realize it could have been prevented.

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.