Category Archives: tech

Draw Your Own Map || S.S. 9

csseries281829For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.

The Draw Your Own Map pattern caught my attention right away with “we might come across situations or colleagues or people in the society who will try to prove that programming will become an unsustainable activity as time passes by.” Throughout my job search process, I asked questions and requested advice from all different kinds of people across different fields (and especially within computer science) on how they knew what job they wanted to start with when given opportunities.

In the end, I must choose what I think is best for me in terms of what I’m looking for. I’ve finally came up with a list and that includes:

  • Having solid mentorship
  • Proper training (no room for imposter syndrome)
  • A company that tries to stay on top of new technology
  • Work-life balance that allows me to continue doing all the things I love to do outside of work and travel often

The Draw Your Own map pattern is very encouraging, reminding us that we have options elsewhere if we feel that our current company is hindering our learning and personal growth. I found that this pattern was interesting because I part of my decision-making process was “what if I am ____ amount of time into my first career and realize that I do not like what I am doing?” How would I move on out of that role to figure out what I may like better in terms of my day-to-day tasks?

The activity to list three jobs that I could do following my next was was really helpful to visualize future career possibilities. I know that we can always learn on the job and at new jobs but it is also important to build up your skills that can be transferred in the first place.

The pattern has helped me feel more confident in the decision I made to start out in software engineering. I will build up my skills starting here and then more onward from there!

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

Sustainable Motivations || S.S. 7

Sams Ships (9)From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.

The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.

I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.

The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.

Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.

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 2 Retrospective

Sams Ships (8).pngFor my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on Stack Overflow. Through the process of not being able to install angular-cli on my mac, it led me to installing nvm, where there was another series of instructions to follow through Github.

It is very relieving whenever we get stuck on something and are able to find similar scenarios from people around the world who have run into the same roadblock and they share advice on how to work around it. Thanks to their input, I was able to resolve my terminal errors and/or warnings that resulted from trying to build something. It also helped me try and see if I could assist any of my other teammates who were running into errors as well even on Windows. I would definitely continue using the internet as a resource when I get stuck on mac-specific issues. The same thing happens when an installation that is only available in .exe files is required, I must find a mac-appropriate version.

However, if I were to proceed any differently; I would have double-or-triple-checked what is necessary to move forward. If someone else were to follow these steps; I would highly recommend checking out the links I provided above when I was unable to install angular-cli on my mac.

So far, we have been hit with some New England weather™ which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.

A big update is we got some more information on the AMPATH x WSU collab right around the end of this sprint so I am looking forward to exploring that with my team. It will allow us to analyze what has been given to us and decide where to move forward with the project.

Overall this past sprint included a lot more learning and collaborating with my team. I’m excited to begin watching the walk-through videos that Greg uploaded of the wire-frames. They look like they are broken down well and all of them are combined into a playlist so I would say we are going to be learning a lot more. Stay tuned for the Sprint 3 retrospective!

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.

Sam’s Ships || Apprenticeship Patterns CH1 & CH 2-6 Intro

csseries281829Welcome aboard! Today we are going to discuss Apprenticeship Patterns based on the book by Adewale Oshineye and Dave Hoover.

What it means to be a software craftsman is to be on a continuous journey to absorb new things and implement them, then taking the time to reflect. To me, being a software craftsman seems like a journey to do better, seek more, and learn from experiences while remembering where you came from.

The three stages of becoming a software craftsman are the apprentice, the journeyman, and the master. Based on those, I thought it was reassuring to read about what changes in each modern-day phase, like a guide or what to expect or what may happen in the technology world with software development. It seems useful because instead of having a core timeline of expectations, it was more based on how people personally developed or tried to grow and learn more.

I found two sentences on the apprenticeship phase thought-provoking, “Th[e] transition [out of apprenticeship] may take longer for some people than for others. For some, the transition may take longer than their professional careers.” It made me think about whether people were settling or just not able to have the right resources to continue growing. Or maybe they had just switched into technology on the further end of their career spectrum.

The reading also made me think about the cycle of knowledge; an apprentice learns from a master, becomes a journeyman, and then hopefully becomes a master as well who ends up teaching skills to newfound apprentices. There was a time before our jobs and there will be a time after our jobs.

The chapter introductions which seem most relevant to me are two and three. From chapter two, I liked how we are encouraged to get really good at a language but not rely on it so that we can continue branching out and learning more. It made me more grateful for sites available today that just serve as online courses to teach and guide you to learning new languages from the beginning.

From chapter three, it feels very relevant to read about “valu[ing] learning and long-term growth opportunities over salary and traditional notions of leadership.” As I will be graduating in only a few months from now, I will have to make an important decision on my first official career. This was an interesting perspective after all the current trends of always hustling and being on the grind and people moving to bustling technology cities.  I will most likely be writing about some points brought up in future blog posts as well.

Overall, this book seems pretty reassuring in terms of helping a reader slow down for a little bit and think about what path they are on and which ones they are willing to cross as well. It helped me reflect on what I have learned so far and what I may want to focus on in the future.

 

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.

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.

Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

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

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.

Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

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

test | prueba | thử nghiệm

CS SERIES (10)If you happen to be reading this page translated from English to another language, hello there, you are one of the main characters of this blog post. Without linguistics, the study of language and its structure, we probably would not be able to figure out how to communicate everything we need to globally while being able to understand it at the same time while testing. There are so many online resources that cover what a specific country or region in a country uses in terms of data formats for their computer systems.

Stickyminds featured an article from Mukesh Sharma on Linguistic Testing: Setting Up Your Software for Global Quality. Sharma dives in by explaining what exactly linguistic testing is–which is testing not only localization but also internationalization. These words basically mean everything we are testing on the software either is or would be fully functioning across the globe.

I found this content thought-provoking as I never specifically thought about how developers and testers would have to consider culturally-aware attributes like the formatting for texts, dates, and currencies. As more and more people are gaining access to the internet across the world, that means there are even more and more platforms to test for gauging market readiness.

An example of a situation that could happen in real life I can think of when testing functionality on websites is for international shipping addresses. If a user, we’ll call him Zayn, from London, England is ordering something from a company based in Boston, Massachusetts (USA) and puts in his shipping address, it should not require him to select a “State” under one of the fields after he selects “United Kingdom / England” as his country option. If that field still requires Zayn to select a state when his country location does not have states, there is a problem.

This will change the way I think when I work as when developing code to solve problems or create something new, I will have to think about if the market or target audience goes beyond the USA. When testing the code, of course every possible scenario must be tested already but there will have to be more details to make sure it all goes smoothly–especially since international errors or problems usually take up more effort to fix as communication plays a big factor.

Article: https://www.stickyminds.com/article/linguistic-testing-setting-your-software-global-quality

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