Category Archives: Technology

Breakable Toys || S.S. 6

Sams Ships (7)Recently, I have been seeing plenty of messages along the lines of “We learn from failure, not from success.” As someone who used to regularly watch all of Casey Neistat’s vlogs from the beginning days, it is something that has been ingrained in me to take risks and know that if I fail, then at least I did not give up and allowed myself to try.

When I saw the Breakable Toys apprenticeship pattern, I thought this would be the perfect opportunity to discuss trying things! This pattern is basically trying to explain to us that you need a safe space to learn something even if you work in an environment that may not allow for failure. It encourages us to seek our own way to sharpen our skills and take initiative, which would increase our confidence.

I found that this pattern is thought-provoking because where would you be if you did not take all the risks or new experiences beforehand to get to where you are today? I used to study biology and chemistry until I gave computer science a real chance. It was a little daunting at first to catch up but I made it (so far). If I did not take on leadership opportunities when given the chance, would I have the observation skills I have today when it comes to being involved on a team? Probably not!

If you do not allow yourself to try something out or practice something, I think you would feel a lot more pressure. It was reassuring to hear that someone like Steve Baker also experienced something like that, which makes it a lot more normalized.

As kids, we started learning how to interact with the world by playing with toys and developing our own sense of physics. Through that, we took risks like throwing things, sliding things down places, and etc., until we figured things like “oh, maybe I should not have accidentally thrown that ball too high and it went to the neighbors yard!” But at the same time, you’re a little proud that you’ve gotten better at throwing the ball harder.

That’s the same thing with developing yourself in your professional career. I will allow myself some time and space to learn something without that pressure and it may surprise me, once again, how far I may go.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Use Your Title || S.S. 5

Sams Ships (6)Having a software-induced identity crisis? Worry no further, I guess that may be a more common thing than I would have expected! This week’s individual apprenticeship pattern will be Use Your Title.

I thought this was really interesting because there is such a high likelihood that there will come a time when you find yourself in-between positions but called something higher because there was no pre-existing label or category that would perfectly suit you. It may feel weird to have to explain yourself in your title to someone who assumes what you do based on what they see or hear. But perhaps, I wanted to add that I feel like someone could just be feeling imposter syndrome; which is something I heard is common for women in certain career fields tend to feel. What if someone does 100% fit the title they feel that they need to explain their title for but just does not see themselves the way their supervisors do.

I like how this pattern tells us that the title is due to the organization we work for, not necessarily us whether or not it does not match us enough or over-exceeds our abilities. By removing ourself from the current situation, I like how we are encouraged to think how we would view or think about someone’s role based on what they actually did in their job. This perspective was thought-provoking to me because I had not considered

Something I tend to think about is knowing when you need to step out of your comfort zone. When should you move on from one thing to the next; how do you know to take that risk? Seeing the little feature on David Hoover’s actions after he achieved his goals, it was interesting learning how he decided to move forward by continuing to draw his own map.

Overall, the pattern has caused me to think a little more on my intended profession in terms of where I want to end up. Right now, assuming I will have a junior/associate position after I graduate and later become a ‘senior’ or ‘lead’; where would I like to go after that? What will be my ongoing goal?

 

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 1 Retrospective

Sams Ships (5).pngFor my first sprint retrospective, I wanted to start off by introducing what kind of project my team is working on and what we are hoping to do with it before I move onto the description of what is happening.

The project I will be working on for the rest of the semester has to do with AMPATH (Academic Model Providing Access to Healthcare); if you have not yet heard of it, it is a healthcare partnership based in Kenya made up of different organizations. Part of my sprint was getting more familiar with who they are and what we could potentially do to help them. It looks like they are mostly trying to ease or log more operations technology-wise to help people.

Our main tasks for this sprint were of course getting to know my team (classroom-wise) and getting our set-up tasks sorted. It is my first time using Trello for something and as a visual learner or visual person in general, I found it very convenient being able to see our “Product Backlog | Sprint Backlog | In Progress | Done” lined up. We decided to start by organizing because of course that is usually how projects are best done and kept on track. Along with setup tasks, we began by cloning the project and then installed Karma and Protractor.

So far, I cannot say anything failed (and hope I will not have to report that anytime this semester for the sake of us progressing) but I hope we will have more concrete plans for what is coming up next for Sprint 2. I think it also has to do with me as a person being so used to always working moving forward or on with the “next thing” and it’s just different not having that yet. That way there will be things to continuously progress on and track more efficiently.

However, if I were to proceed any differently; I would have gone back and gotten a little more background knowledge because I feel like we tend to tell ourselves “I’ll just go back later and review” but of course that doesn’t always happen. It’s just a fact when you’re a highly involved student who works on the side; but when you plan or set some time for yourself you will be able to do what you need to.

A majority of what was done during this current sprint consisted of trying to understand and introduce ourselves to Karma; which is a test runner for JavaScript.

If someone else were to follow these steps; I would recommend going in this order: Getting to know your teammates, making sure the team has a solid enough understanding of what project we will be contributing to this semester, beginning setup tasks, and then setting goals for when you should check certain things out.

Overall, I enjoyed this first Sprint as I did not feel too much pressure in terms of what needs to happen yet so we can ease into producing software that will help benefit AMPATH.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Concrete Skills|| S.S. 4

Sams Ships (4)On this weekly individual apprenticeship pattern post, I’m going to discuss Concrete Skills. This pattern is pretty much explained with someone wanting to be a part of a good development team but they have not yet built up their development experience. My reaction to this pattern is that this would be a comforting one for students in college or upcoming graduates (and even entry-level developers) to feel a little less pressure on bridging the gap between starting fresh and being an experienced developer.

Concrete skills are interesting to me because you can have all the knowledge and information but being able to take what you know and apply it to something is different. The main takeaway I got from this pattern is to learn things that you will be able to apply even when you are still in the on-boarding phase. This has caused my to change the way I think about my intended profession because of course I want to get started and involved in projects right away. I like the feeling of being able to help people out when I have down time at my current opportunity just because I get to sharpen up a skill in one area instead of just sitting there.

A good question proposed in the pattern stood out to me, “If we hire you today, what can you do on Monday morning that will benefit us?” It’s interesting to imagine yourself in the role of a hiring manager; they have to hope to understand you well enough so that they can trust that you will be able to do your job and have an impact on the company. This thought makes me want to continue what I’ve been doing in terms of pursuing different learning experiences that will help me become a stronger developer not only knowledge-wise but skills-wise.

I do not disagree with something in the patterns as it gave me something new to think about and look forward to using in my future. I found it useful to hear their advice on considering looking at other CVs as references of what we would like to put on our potential list of skills.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Do You Hate Your Computer Too?

Sams Ships (3)Apparently doctors hate their computers, according to an article titled Why Doctors Hate Their Computers by Atul Gawande. Gawande started out the article by mentioning Epic, a company a lot of people know of because it is a leading provider of software for the healthcare industry. It’s funny because just the other day, a classmate who will not be named groaned when he heard Epic being mentioned by someone, as he works in a healthcare center.

I found the reading was interesting because I have no intentions of becoming a medical doctor one day but was able to hear about how it is being one while interacting with technology that exists today.

It seems like the tension of logging everything caused the system to make doctors’ lives harder instead of easier; this was noticeable when Sadoughi was talking about how she had to look over all notes from different doctors including herself per patient. Instead of being able to just see what is going on right away; it would take up time to gather all information and even then it was not always helpful because some notes were different than others and became dated. And then work-life balance had to be thrown off a little because people had to spend extra time, up to hours after-hours to catch up with the system and review things from the day.

The real customer for the system seemed to be patients because they have some benefits from using the system like logging when to take medications or see how they are doing. Doctors are also able to monitor how they are doing and communicate with them by being pinged.

The lessons from this system do not only apply to Electronic Medical Record systems; they also apply to working in life because burnout can happen to anyone in the workforce. I thought it was interesting how one of the ways doctors were trying to save time and prevent burnout from technology was by hiring in-hospital scribes or even virtual scribes when necessary.

The reading has caused me to changing the way I think I will work based on if I ever end up creating software that affects people’s healthcare by considering how much time it takes to interact with it, no matter how “cool” or “innovative” it may be. In terms of the topic itself, the reading has caused me to think more about software that has altered people’s professions as a whole; which I thought of before but never this deeply.

I do not disagree with anything in the reading for now as I do not personally know what it is like to work in a profession that is not traditionally non-technical and then gets transformed into something that relies on it.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

The Deep End || Sam’s Ships S.S.3

Sams Ships (2)On today’s installment of the individual apprenticeship patterns series, we’re going to discuss The Deep End. The main takeaway of The Deep End is that you should throw yourself into an opportunity even if you are hesitating or unsure. Of course, it is not necessarily telling you to be reckless, it also emphasizes how it is your responsibility to offset the risks of your approach.

I found that this pattern was interesting because as a person, I continuously try to say yes to trying new things or taking on new roles when the opportunity arises. The Deep End is basically the pattern that represents that mindset and reinforces how important trying something you might think is “risky” turns into being one of the best choices you ever made.

The pattern has caused me to change the way I think about software development/engineering based on the “action” it tells us to consider; which is learning to see what choices are affecting where our career is heading and eventually learn how to make choices based on it. I will try to focus on not only reflecting and reviewing what has happened but I will also move forward by actively making decisions based on experiences.

I do not disagree with something in this pattern so far as the “risks” I have taken so far have always turned out bettering me as a person or helped me achieve something greater. Things like taking on new roles within Enactus when I was unsure about how much time it would take on top of my already busy schedule to how to actually do things were part of my worries. In the end, it turned out alright because I was able to work things around my schedule and people who knew what the role(s) consisted of were there for me as a resource or form of support.

Overall, I am pretty content with the things I have jumped into because like Enrique from the Jumping in With Both Feet story, I eventually felt “like a fish in water.” I liked being able to read about someone’s success story of an instance where they went after something and thought “hey, the worst thing that could happen is I don’t like it and I fly back.”

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance|| Sam’s Ships S.S.2

Sams Ships (1)For this next installment of the Apprenticeship Series, I wanted to discuss Expose Your Ignorance. This apprenticeship pattern involves being more direct with people to have the faster route on the road to journeyman instead of protecting one’s pride to find other ways to obtain the knowledge they are seeking. When someone exposes their ignorance, they will be able to learn more quickly instead of trying to appear like they are capable.

Based on what I have learned of this pattern so far, my reaction is that it was useful seeing examples of how this happens in real life for people. To me, this was something I thought of before without putting it into a framework of sorts. I found that this was interesting because of the way they explained it saying, “One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it.” It shows how ignorance does not necessarily mean they are at fault of something, it just means they are willing to work to move past it.

Taking this as a lesson to think about, the way I work will be pretty much the same. I once almost made a task over-complicated because I wanted to find my own way to work on it instead of just asking another developer for their opinion on whether I was doing something correctly. After deciding to ask for help thought, we figured out that there was a much more simple way of going about it instead of changing a whole system of developing a certain feature. Due to this, I have gained more confidence to ask people when I am uncertain about something because in the end it would save a lot more time and avoid confusion.

I did not disagree with anything brought up in the pattern so far because I believe people should be able to communicate when they are not confident about something or at least ask for clarification. After some thinking, I realized I’ve never expected anyone to know everything so why should I feel like other people should expect the same from me?

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

The White Belt || Sam’s Ships S.S.1

Sams Ships.png

So you either want to or have already been an apprentice for software development huh? I just read the section on the apprenticeship pattern for The White Belt and it was a nice beginning to approach what we are doing. It reminds me of a quote: “In any given moment we have two options: to step forward into growth or back into safety.” This is us stepping out of our comfort zone as we approach real-life situations and try to help them by starting our journey into development.

A summary of the pattern would be after some time of developing skills, someone may feel that their growth has plateau-d, however there still remains confidence in their abilities to do something. I found that this was interesting because as someone approaching a career where I will be a life-long learner of technology and ways to develop it, I never considered getting stuck or feeling like I was not getting somewhere.

Based on what I have learned about the pattern, I think it will change the way I work based on their advice to set things we have previously learned aside in order to “unlearn what we have learned.” I like the idea of approaching something that is new to be able to fully appreciate it.

I could relate to the situation they describe about sacrificing productivity in order to improve our skills. From on-boarding as a junior developer, it was a different experience trying to do self-learning while getting assigned tasks to work on at the same time. It was interesting trying to find a good divide between learning something while trying to develop things compared to using internet references.

I agree with how they mentioned not basing everything you learn in other languages based on comparing it to a base language that you know. This made me realize how I have been doing this for a while; I sometimes forget that not everyone knows Java or a language that would seem “universal.” It would help take away the stress of thinking in a certain language’s syntax or process; allowing people to just code something that would work more efficiently and effectively.

Overall, I would say that this pattern is nice to hear about in the beginning so people can approach it in a way that allows them to learn things with a fresh start to programming. I also just liked how they called it The White Belt so people can level up.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

New Year, Same-mi

cs series (17)Hey guys, here’s to another (and my last) semester of this CS series of blog posts!

Hopefully you will HIIT–or should I say reach–all of your professional and personal goals for this year. There’s so many things to always keep improving on but it’s always easier when you break things down to smaller changes or achievements.

Here’s a picture of one of my personal goals as can be seen in my university’s Wellness Center:

Processed with VSCO with hb1 preset
“This Year I Want to ______”

One day I will be able to get up there without being lifted…alright I’ve gotta get back to practicing my jumps.

Best of Luck,

Sami

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

QAn’t Wait to See You Again

CS SERIES (16)Before I dive into my final installment of this CS series (for now), I wanted to say thank you if you actually read any of these posts and thank you to my new followers for dealing with the notifications you must have gotten.

For this last post, I wanted to discuss the article 5 Reasons You Are Wasting Your Testing Time by Joel Montvelisky. The author expresses how everyone can do testing but not everyone can do “good testing,” which incorporates more than just what is basic checking.

A short list of main reasons why a lot of people tend to waste time that could have been spent testing other things includes:

  • Not having clear goals
  • Not understanding what or how much the feature means to your End User
  • Not keeping track of what was tested and potential discoveries
  • Not consulting what you already know or using references
  • Not giving feedback that could be shared to help others

Sam CS (22)I agree with most of what Montvelisky says as I have personally noticed what has happened from my experience as a Software Quality Assurance Intern when any of the five things above took place based on a task. It is important to understand that sometimes these things may be out of your control but you should still try your best to avoid miscommunication wherever possible.

Montvelisky’s content has not necessarily changed the way I will work as I have already been consciously making an effort to understand what I am reviewing, how stuff is meant to work, logging tasks, connecting tasks to previous occurrences, and communicating with the QA team. If I had read this article before I started working, it would have been more useful as it would serve as a foundation to how one should think of testing beyond the basic functionalities.

Something I wanted to emphasize is the post-test reviews and feedback sessions with peers. I found that if someone else needed to learn about a project or a task had to be communicated with a client, logging any kinds of notes or information was better than not having anything prepared to discuss. They do not necessarily have to be posted for everyone to access but it would be good to note it in any sort of text editor for future reference. I think an example of when to note things is if you found something that does not prevent your current task from being approved but it still affects something for the overall program.

Overall, when testing things I believe you should trust your instincts on reporting things you find. It helps when you try to imagine how much it could affect a program in the long run if not brought to someone’s attention, even if it may seem minimal.

Best of Luck,

Sam

Article: https://qablog.practitest.com/5-reasons-you-are-wasting-your-testing-time/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.