Author Archives:

Apprenticeship Pattern “Breakable Toys”

This week, I will be exploring another apprenticeship pattern, which is “Breakable Toys.” I briefly mentioned this pattern in my last post, and I thought it was worth revisiting.

The professor of my capstone, Dr. Wurst, had suggested for us to try to create something, even if it wasn’t exactly what we were trying to do. This would allow us to dive deep into learning one thing.

The term he used for what he was talking about was “spike,” which I isn’t exactly the same as this pattern, but it certainly is a similar idea. This pattern more pertains to doing projects on your own time to learn from your mistakes.

In school, it wouldn’t make sense to turn in projects that don’t work. It would be hard to pass most classes if I did. In many cases, school or work, failure is not an option. Of course the authors don’t advocate experimenting with those projects. They would rather you learn independently so that you can apply the skills you pick up.

For the past few blogs, I have talked about being more proactive. I have made a conscious effort, but it has been hard keeping it up. I have to realize that change doesn’t happen overnight, and it’s good to take these setbacks in stride to avoid being discouraged.

In the pattern, it uses the analogy of someone learning to juggle. I once read a study where of those instructed to juggle just five minutes a day, all of the participants were able to juggle by the end of the study. Reading this was enough to encourage me to try this experiment for myself. I set a timer for five minutes everyday, and I was able to pick it up after a few weeks.

The important thing to note is that five minutes was the minimum I set for myself, but I would invariably go for much longer than that. Currently I do not have any side projects that I am actively pursuing. If I were to set a five minute minimum to do something, although it would be small, it would be far better than nothing. I’m willing to bet most days it turn into much, much longer segments of time than five minutes.

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

Apprenticeship Pattern “Nurture Your Passion”

In this week’s post, I will be discussing the apprenticeship pattern “Nurture Your Passion,” as presented by Adewale Oshineye and Dave Hoover.
I chose this chapter because I think I have felt like I’ve been just getting by for a while now. The  problem it identifies as, “You work in an environment that stifles your passion for the craft.” I don’t think that’s quite fair to my school or professors. I think that in any discipline, if someone is only studying for the tests or working on the assigned projects and calling it a day when they have passed them in, they are not truly adopting the apprenticeship mindset.
Without a constant push forward, I will stagnate. I may get an “A” on the exam or project, but if I forget the material the next day, there is no point. The pattern suggests finding something that sparks interest and pouring myself into it. I have been wanting to do this for a while, but I have made excuse after excuse of not having enough time. The next sentence in the book says “consider putting in extra some time.” It often feels that is easier said than done.
I am reminded of the quote in the beginning of one of the chapters from this book by CS Lewis.  There should be no excuse for starting work. “Favourable conditions never come.” I got very little done over winter and spring break, and I won’t start the next break if I don’t start now.
The pattern goes through some other patterns and notes their relevance. I have blogged here about a few (e.g. “Kindred Spirits”), and a few others piqued my interest, so I read a few of them as well. “Breakable Toys” seemed particularly interesting. I may write here about it in the near future if another pattern doesn’t catch my eye.
I really liked the action. It was while commuting to work, think of three positive ideas to talk about, and when feeling down, shift the energy to one of the exciting ideas. They say this is to avoid getting dragged down. Furthermore, on the way home, they say to reflect on how successful the day was, and think how to improve my environment.
I like how this is a very achievable action. It doesn’t require me to spend any extra time on it. I commute to and from school everyday, and it will likely be the same when I start in the workforce. More often than not, I am already thinking about this sort of thing already, but in a different context. This will be a very natural thing to shift my way of thinking. I could see myself implementing this from here on out.

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

Sprint 3 Retrospective

At the beginning of this Sprint, we all watched the videos that AMPATH shared with us for ideas for projects they would like to incorporate into their app. It was really encouraging to make contact with them. I was wondering how much they would ask of us, but I was glad that they seem to value what we’re going to do. I like that it looks like we will be able to do some interesting projects. I hope we are able to get through as many stories as possible because I want to do a good job on this.

After watching the videos they provided, and we all decided that we wanted to start by trying to implement the story which was to creating tabs in the app so more than one form for multiple patents could be open at once.

After a quick google search, I found some good resources from the official Angular site. It provided with some examples of different ways to implement it. It also showed the code behind it in an interactive app that showed how all the components work together. Within the app, I was able to modify the code and see in real time the changes I made to the example.

I shared what I found with the team. It is very exciting because this was exactly what we wanted, and it was laid out in a way that was really intuitive and makes it straightforward to  see what we need to do next.

I think what may be our next biggest hurdle is getting something concrete started. After we have done that, I think it will be pretty straightforward assigning roles and dividing up tasks. When we have finished the first story, I think I will have enough of a feel of how things are done to branch out and form a sub-group so we are able to cover more ground.

Andrew was a huge help to our group. He pointed us in the direction of a lot of resources, especially how to interpret the code we have been provided.

I think a good goal for this upcoming sprint is to finish this one story that we have chosen. I think it is something that we can realistically do, and I don’t foresee that it will be all that challenging. It’s still early to say for the sprint after, but I would like to at that point do what I mentioned earlier and split up into smaller groups and between the four of us, tackle two more stories with two of us working on each.

Of course, I have coded enough to know that there will be unforeseen obstacles that we will have to overcome. There is a chance that one or several might cause quite a bit of delays, so I should not get too ambitious right out of the gate. After all, we have not done any real work of substance yet.

However, I believe it is important to set our goalposts high. If we don’t achieve all of our goals, we can just append it to the next sprint. I think we will achieve more of our goals if we are more ambitious setting them.

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

Pattern “Kindred Spirits”

This week, I will be discussing “Kindred Spirits” from Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. It is intuitive to surround yourself with people that are likeminded, trying to achieve the same goal. I wanted to read this section to know if I was going around it the right way.

I went into this wondering if they meant having good relationships with coworkers and classmates. It is always valuable to have a friend to ask for help, but it is not the whole picture. It is something that needs to be actively pursued.

The authors recommends joining or creating a group to foster your interests.  It seems that I am somewhat on the right track. I feel that I am pursuing this in my extracurricular activities. Currently, the only computer science group that I am actively engaged in is the Worcester State Computer Science Club (Re:coded, I think the official name is).

It encouraged me that the club they mentioned, Extreme Tuesday Club, boasts hundreds of members but usually has only a dozen or so people that will show up to a meeting. It seems that we have about the same ratio of members showing up to an event, with a few dozen members and a handful of “irregular regulars,” as the authors calls them.

Going forward, I would like to play a bigger role in leading our workshops. I have helped come up with some of the ideas for the last few, but I have largely been learning as I have been going along. This may not be the worst thing, as one of the apprenticeship patterns that I have read (but have not written about) is “be the worst.”

There was one quote that stuck out to me, which was, “If your group becomes large enough and energetic enough, it will sustain itself even when you are not there. That’s when you know you have a community.” I really hope that I will help it grow enough to this point so it will continue after the leaders and I graduate soon.

The thing that stood out to most was the advice to always continue to ask questions that shock the community. Something that I did not think about was what the tendency that group-think might develop. I think I do a good job of not allowing this, but I sometimes feel guilty when I don’t feel like a “team player.” This gives me permission to continue to do this, but less apologetically so.

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

Capstone Retrospective 2

Although we have not been given anything to work on from AMPATH, save yesterday’s meeting, I have made the most of my time to learn as much as I could about Angular. I haven’t gotten all the way through the tutorial, but I want to emphasize learning it throughly over rushing it.

The first time I was going through the tutorial, I was well over halfway done when I realized I was missing one of the steps to get it to work. This happened early on in the tutorial as well, and I resorted to blindly copying and pasting every step again to get it to work. It turned out to be a very minor fix. I was much further in this time, and I was about to do the same thing, but I realized I would be wasting my time if I did that. If I didn’t understand the code enough to diagnose these simple fixes, I am not getting much out of the tutorial doing it this way.

I was talking to members of my team about it, and we came to the conclusion that even if we individually only got through the first few sections of the tutorial, our time would be better spent if we understood what we were doing thoroughly over completing all the sections without as good of an understanding of the concepts.

Even though we have not been doing a lot of work together as a team for the clinic, it is really nice being able to bounce ideas off members of our team. It is great  to have the ability to share resources with people I am working towards the same goal.

It feels like I am living out some of the apprenticeship patterns that are laid out in the textbook for this course. I am challenging myself to learn new concepts, even without a looming test or set deadline. I have gotten better and better into the habit of carving out a small chunk of my time to learning a new concept here and there. I hope this continues as this course develops, and I hope to continue this trait for the rest of my life.

Yesterday, our group liked the idea of working on the projects described in the videos in part 2a and 2b. I liked everything that I saw, and would be more than happy to work on this. It’s not certain if we will be the ones who get to work on this, but we will coordinate that with the other groups. I am very happy to get started. This is what I’ve dreamed about doing since I decided to major in computer science. It is really exciting making that happen.

I also read a part of Edward R. Tufte’s book Visual Explanations, where he has a page giving an example of what an effectively-laid out medical chart might look like (p. 111). Although this might be the only example I could find on something for medical use, I think this book might prove to be a good resource for displaying the data. I’m sure there is a lot to be learned even from the examples that are not specific to medicine.

The most useful tutorial I have found comes from Angular itself. It is a really easy-to-follow step by step guide that holds your hand through the entire thing: https://angular.io/docs

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

Diving Deep

This series explores Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This week, I decided to read the apprenticeship pattern “The Deep End.” 
To be completely honest, most career opportunities that are on the horizon are somewhat intimidating. I wonder if I have the ability to do a lot of the work they require. The chapter talks about getting into a rut, but my rut is working fast food. Making a transition to a career-oriented position is a big step, and it is a bit out of my comfort zone.
Instead of reluctantly accepting a task that I am not confident about, I should have the self-assurance to jump in at the deep end. This gives me permission to take on a task that might seem daunting when it presents itself. This is easier said than done, and I find it hard to entirely  abandon my initial timidness.
It is important to note that they also warn about getting too far out of your depth. It is okay to jump in the deep end, but “you still need to remember that if the water level is above your head it means you’re drowning.” This is key. They offer two other patterns for helping with this, which is “Finding Mentors” and “Kindred Spirits.” The titles seem descriptive enough to give a general sense of what you might need to look for. Perhaps one of these will be the topic of a future blog post to dive in more in depth.
The action it suggests is to measure the biggest projects I’ve accomplished based on a few factors of complexity. When the next project comes along, see how it compares. It claims this is a good indicator of where my career is heading, and it might be the basis of choices I make.
Already, when thinking of mapping my projects like this, I think to myself, “I need to do more independent projects.” I’ve done quite a bit for school, but I haven’t done anything incredibly ambitious on my own. I have vague goals of what I want to do, but I have done few concrete steps to fulfill them.
Most of my goals for independent projects are somewhat formidable at this point in the game. For example, I would like to make some sort of a web app that I would have to develop full stack. I have a few ideas in mind for what to do.

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

Pattern “Read Constantly”

The apprenticeship pattern I decided to choose for this week’s blog was “Read Constantly.” It was somewhat self-explanatory, but I thought it had some good insights nonetheless.

It recommended reading books over blogs. I would imagine that this is the right course of action from researching blogs last semester. All the material was good and informative, but many times when the host was interviewing someone, it felt like a summary of what could be a very interesting book. There’s only so much that can be gained from a blog post or a podcast. The things that you learn from those can be valuable, but it is better to go deeper when possible. Even if you have a very wide base of knowledge, it will only get you so far when you only scratch the surface.

The quote at the very beginning, from Steve McConnell, says that if you read a good programming book every other month, you will distinguish yourself from your peers. This seems like a worthwhile task, and frankly it is very doable. He chalks this up to be 35 pages a week, which is less than many reading assignments for school. Those don’t take me very long and aren’t very hard. It would be helpful to read more supplemental material, especially on break and after I graduate.

I haven’t read any research papers in this field, but that sounds like something I should start thinking about doing, especially when I pursue a graduate program. It recommends reading some at least every once in a while.

It also recommends keeping a slim book to fill dead time throughout the day. I think this is a good idea, especially when something can be overwhelming. It’s like the old adage of how to eat an elephant — one bite at a time. Or in this case, one page at a time and whenever you have a moment.

This is something that I’ve been trying on my own in general as well. When I was younger, I was an incredibly avid reader, and I’ve slowly gotten out of the habit as I’ve gotten older. I would like to read more of everything. I think it is a mark of a well-rounded and intelligent person to be well read.

It was a new year’s resolution to read more. I have been trying read a few chapters everyday of something, which has mostly been non-technical so far. I’m going to to change that and start adding more material that will not just better me as a person but better me as a software engineer.

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

Capstone Retrospective 1

Up until this point, it has felt like we have mostly been trying to simply get our project to run.
I am not sure if the other teammates have felt this way, but I am anxious to contribute. It would be nice to have something to show for our efforts. It has been slightly frustrating, but I should have expected this slight speed bump.

In light of this, I have not been able to do some of the less important tasks that I wanted to get done. I wanted to research about testing in angular. In addition, I have been wanting to complete a tutorial to refresh my knowledge on Angular. I feel that this is one area that I would really like to round out my knowledge on because I feel it is somewhat lacking.

The bright side is that I was able to get my code to build and run without as much trouble that many of my teammates and other teams have experienced. Also, by the end of yesterday (2/19/19), with some input from me and some of the other teams, it looked like all of us got it to build and run.

A takeaway from this is that I should dedicate at least a sliver of my time everyday to dedicate to this class and project. In the apprenticeship patterns textbook, there was a quote by CS Lewis that I particularly enjoyed, which said “The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavourable.”

I should apply this to learning this information. Even dedicating half an hour a day is better than nothing. I’m going to be a realist and say that on some days this class might be put on the back burner because of looming deadlines and exams from other classes, but I should never let that interfere with doing even a small amount every day.

In class yesterday, the code did not build and run right away, so I decided to go through step by step the commands that I got it to run the first time. You can imagine how nervous I felt when it did not start right away. I thought that since it had already been built, I could just run the last command to start it. It turns out that I had to go through them in order to get it to run the second time around.

The following is a list of commands that I used to get it to run, in this order:

(1) ng serve
(2) ng build —prod
(3) npm start

Note that this is run from the command line in the top layer of the directory that you have designated for the project. After these commands are prompted, go to your web browser, and type the following:

http://localhost:3000/#/login

For node or module problems, I found the solution was to do the following command:

npm rebuild

I experienced this when I was trying to rebuild it yesterday. I breathed a sigh of relief when it was such an easy fix.

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

Ignoramus? Me?

For this blog post, I will be discussing the Apprentice Pattern, Expose your Ignorance, found in the text Apprenticeship Patterns. This pattern piqued my interest. It discussed how to deal with inevitably not knowing something. It is comforting to hear that I am not the only one who sometimes feels out of their depth.

This pattern gave me a few things to work on. It can feel natural to tell people what they want to hear, but that isn’t a good way to build trust. I know it may seem obvious, but it is very easy to fall into that trap, and I know from experience. I like the idea of building a reputation on my ability to learn rather than what I say I know.

Ignorance isn’t something to hide — it is a chance to grow. This brings to mind a “growth mindset,” which means that instead of seeing challenges as something that sets one back is instead something that can be learned from and used as fuel to grow. It is clear that this book adopts this idea, even if it isn’t necessarily one of the patterns.

The pattern made me think of my ignorance in a new light. Instead of trying to pretend that I know more than I do, I should make it well known what I don’t know. My reputation shouldn’t come from what I know, it is my ability to learn new things.

I also liked how they wrote that being an expert is not the goal. The example of a marathoner having strong legs from running even if that wasn’t the goal seemed like an apt metaphor that being an expert is likewise a byproduct. In addition even if we are experts in one area, we will always be ignorant elsewhere. We should relish in what we do not know. Ignorance is something that should be welcomed because it means we are learning and growing.

I feel this pattern is tougher said than done. It is a simple concept, but it might take years to fully master. That being said, simply being aware of my shortcomings in this area is a huge step forward. This is something I intend to start immediately in every project that I am currently working on and every project in the future.

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

First, do no iHarm

In this post, I will be commenting on the New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande, from November 12, 2018. It focused on doctor’s frustrations with the transition to Electronic Medical Records, or EMRs.

Learning about this it has been surprising how painful the transition process has been. I have heard similar complaints from friends in the field, but I did not know how widespread it was.

By the sound of it, it is hundreds of little reasons that make the doctors’ lives harder. For one, it is much harder to add a simple note to a patients’ file. There is a lot of unnecessary information  that needs to be filled out, and many of these fields are mandatory. Another reason is that the computer gives the doctor arbitrary limits, like they cannot view lab results from a week before because their window for viewing it has expired.

Yet another reason is that the user interface is not very user friendly. It takes several more clicks than it should to do any one thing. The list of complaints seem to be endless, and unfortunately the issues brought up in the article are likely just the tip of the iceberg.

The real customer for the system is certainly not the two groups that would ideally benefit the most — the doctors (and nurses and the like) or the patients. It has made the doctor’s jobs much more difficult without much to show for it. The strain that it puts on the doctors are felt by the customers as well. There might be a few advantages, but most are marginal at best.

No, the real customer is the creator of the EMR systems. They stand to profit from it quite a bit. The fact that they were ridged to any outside influence to make the system better shows their true motives.

The lessons from the implementation from this system most certainly do not only apply to the Electronic Medical Record systems. The article touched on one of the patient’s experience in his own life working in construction. He echoed one of the complaints of his doctor, which was that the automated alerts created a signal fatigue, and the solution is to do the old school way of going back to picking up the phone over using the computer.

When I read about the doctor not being able to submit a form unless all the fields were complete, I thought about when I worked at the YMCA when I was sixteen. There was an extensive incident report that took forever to fill out, so consequently, we never used it save for major events. Of course, these were still done on paper, but if a paper could get in the way of doing our job properly, I have no doubt a much more complicated system would as well.

This reading has not changed my opinion because I was already aware on the topic. I have read up on it in the Boston Globe, and I have talked about it with friends who are in the field. The New Yorker article just confirms everything I have already thought about it.

I was hoping the article might forecast what might come. As they are now, EMRs are awful, but they are here to stay. They have only been around for a little over a decade most places. This is just the natural growing pains we have to get through in order to get to something that benefits us all.

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