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.”
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.
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.
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.
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.
samanthatran.com 