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?

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.

 

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/

Adapt or Git Left Behind?

CS SERIES (15)As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.

On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.

I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).

Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.

An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.

I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.


Article: https://stackify.com/design-patterns-explained-adapter-pattern-with-code-examples/

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/

Nice Demete[r] You

CS SERIES (12).pngThere are lots of “rules” we must follow in object-oriented software development and the article The Genius of the Law of Demeter by Javadevguy summarizes how they are useful. From what I put together, it seems like the Law of Demeter took abstract concepts and basically put them into a universal set of rules for Object-Oriented code.

I thought that the law of demeter must be a big deal if someone decided to sit down and write a lengthy blog post about it. This content ended up being interesting as it tried to convince readers why they should obey this “law.” The Law of Demeter basically paves the way for what users can do to a given method. It is kind of like considering the restrictions or possibilities based on the method. One of the takeaways I got from this is how there is a lot of focus on communication between two objects.

Sam CS (18)

The rules listed in the article are as follows–noting that it says “For all classes C, and for all methods M attached to C, all objects to which M sends a message must be”:

  1. self (this in Java)
  2. M’s argument objects
  3. Instance variable objects of C
  4. Objects created by M, or by functions or methods which M calls
  5. Objects in global variables (static fields in Java)

Another useful takeaway I got from this article came from observing the code examples Javadevguy included; how Rule #1 covers that any method can be called on the current object. I also noted when there would be an instance where the law would prohibit something is not “sending a message” to any already existing object that is held in instance variables of other classes.

This will affect the way I continue to do work as an Object-Oriented developer. I mean, in life when you learn there is a more useful or structured way to help you achieve more effective results, you would want to try or follow it, right? For my future use, I will acknowledge (like other blogs and articles) that the Law of Demeter is less of a law and only a suggestion or a guideline.

Overall, I would say that the content has helped further solidified my understanding of some Object-Oriented coding concepts. I agree with the content as it is trying to help people become better developers or better understand the Law of Demeter in general.


Article: https://javadevguy.wordpress.com/2017/05/14/the-genius-of-the-law-of-demeter/

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