Before I became a Computer Science major and aspiring software craftsman, I was very much into reading what many people would consider “the classics”. Whether it was the Iliad and the Odyssey or A Brief History of Time, I have always been fascinated by works of literature that had such significant content or perspectives on the world that they were revered throughout centuries as “the classics”.

So when I came across this pattern, Study the Classics, I immediately resonated with the context they put forth and their motivation for including it in their book. The solution / action which they suggest to us budding apprentices is to collaborate with others and ask about a concept unfamiliar to us and to try and seek out the book which that concept was written about.

Immediately my mind drifted back to learning the Gang of Four’s software design pattern book, which I know for a fact to be highly revered and considered one of the “classic texts” in our craft. Even when I first read it for school assignments, I was enamored by how rich the concepts were and how articulately they were explained. My learning and overall understanding of software development as a whole is unquestionably markedly better than it ever would have been had I not been exposed to this book.

At the same time, I am aware that as good as this book is, and as valuable and timeless as the information in it is, it is definitely not a holy bible for software developers. There can not exist one text to rule them all, because there is no single entity capable of compiling everything we would possibly want or need to know into a single source. So in the future I will definitely seek out multiple individuals or groups of authors who are very well known and revered in our field, so I can add their works to the collection of books I need to read to be as knowledgeable and as prepared as possible for the uncertain road that lies ahead of me in my journey to competence in software development.

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

For the final pattern that I will be writing about for this capstone, I wanted to write about something that I’ve felt for a while, but I did not know if my intuition was correct. I picked this one because of this line, “someone who has never failed at anything has either avoided pushing at the boundaries of their abilities or has learned to overlook their own mistakes.”

I feel that I have faced setback after setback in my life. I like to believe that it helps make me into a better, stronger, and more resilient person. When I struggle to learn something, I find that I understand it more thoroughly than if it came easy. It will also be much less likely to forget.

The struggle is something to be embraced. It should not be a reason to give up. On the contrary, it should be a sign you’re going in the right direction. It’s like a video game where you’re not progressing in the level if there’s no bad guys in the way.

I thought the “action” piece that the authors suggest is an apt one. The long and short of it is that to practice, you should use a text editor instead of an IDE to write an implementation of an IDE in one sitting. Since there is no IDE, it might catch the errors that you would have otherwise overlooked. I have not started studying for my Unix final, and this might be something I might try. However, I think we’re mostly doing things with shell scripts and the like, which is somewhat like a text editor anyway.

I think this pattern goes well what I wrote about in my retrospective just now. For as much as I enjoyed working with my scrum team, we were not perfect. Reflecting on how we fell short will ensure that the next team I work with will be even better.

I find I perform best in the areas that I have reflected the most. A part of it feels like neurotics, but it is important to do it. I reflect on most areas of my life, whether or not I am graded or paid. I feel that it is an important step to self-betterment on the way to self-fulfillment and mastery.

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

For the final reflection of my Apprenticeship Patterns series, I’ve decided to choose Dig Deeper from Chapter 6: Construct Your Curriculum. This pattern suggests that you stay conscious of the fact that, as an engineer, you’ll be forced to learn new concepts at a sometimes alarming rate. As a result of this, you’ll likely only learn things at a relatively shallow level of understanding. That is, you’ll only have time to learn what is necessary in order to complete your current task. While this seems like enough, it often can result in issues (bugs and more) in what you’re working on — and it’s limiting your own potential growth at the same time. The solution is to remain vigilant. Put in the work required in order to fully understand a tool. The system, and you, will benefit in the long run if you put in the effort now to learn things properly. Dig into the depths of every concept you’ll be using so you can use it properly.

I’m graduating this month and that means that I’ll be out of formal education for some time. While I do intend to return for a master’s level degree, that won’t be for some time still. And, while I know I’ll be learning a tremendous amount in the workplace, there is still so much more that I want to learn over the next few years that I may not get on the job. It’s the start of my CS career, and I’d like to hit the ground running. I need to make sure that I dedicate time to learning more theoretical concepts at a deep level.

The book draws a distinction between those programmers who have achieved deep understanding over a concept vs. those who haven’t by identifying those who create piles of rubble, and those who create cathedrals. We have a set of tools at our disposal — it’s really easy to use them to create throw things together and construct something that has functionality that is limited to strictly function. However, it’s the true sign of a craftsmen when one can use those same tools in order to create something beautiful. That is exactly what digging deep into each tool you learn can give you, and it’s something I’m going to focus on going forward into my career as a software craftsman.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Hello dear readers. Welcome to my last blog post about the Apprenticeship Patterns. This is the 10th Pattern that I really found interesting and wanted to share with you all.

You are graduating, you probably have a job offer (or a few) in the table, you are ready to start this whole new journey and you think you have a good background to create a successful career. YES you do and Congratulations, but it doesn’t end here. You have worked hard to be here but you still got a lot of work to do.

After you Find your Mentor you will see that the Mentor will be giving you different exercises for you to work on based on your skills and weakness and you will see that every exercise will teach you something better or perfect your skills. When you start working in the company, you will face challenges in every project but don’t stop your exercising outside of work. I feel like in companies you apply a very specific knowledge and you would want to be on top of the new stuff that come out if you want to have a good career.

I really like the title of this pattern ” Practice, Practice, Practice”. I used to have a Math teacher in high school and she was always saying “It’s 99% hard work and 1% talent” and I totally agree with her now. That’s why the practice should never stop, doesn’t matter how far up you have gone in your career.

Also look at the bright side, while you just pick random exercises or small projects to work on, you don’t have to worry about deadlines and no pressure. You will notice at the end how happy you will feel about what you have worked on independently.

So just like the authors of this book suggest, go online and find different problems to work on. If you want to feel more challenged find coding competitions and enter them. Don’t worry if you don’t win. You will definitely learn something out of that experience.  After a while go back to where you started and you will see how you have progressed. my last advice you all of you would be: don’t just settle when you start working in a company. Keep growing outside of it. Practice, Practice, Practice…

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

Here we are – the last Apprenticeship Pattern of the semester! I’ve learned so much about how to successfully transition from a budding computer science undergraduate to a new software development professional. Now that the semester is just about over, I am going to be spending most of my time between now and the start of my new job learning about their tech stack. As I’ve discovered while getting to know the engineering team, I don’t have any experience with the technologies that they use. This brings me to the apprenticeship pattern for this week, “Confront Your Ignorance.”

Confront Your Ignorance pretty accurately describes the position that I am in right now. In this situation, the apprentice has identified several areas or skills that they don’t know much about, and they are interested in learning more. Sometimes, those around the apprentice may already feel comfortable with these skills. The simple solution for the apprentice is to begin “filling in the gaps” in what they know about any skill(s). This could be in the form of articles, tutorials, or Breakable Toys (personal, private projects that allow the apprentice to safely learn about different tools without consequence of failure), among other methods. This pattern is closely related to Expose Your Ignorance, another pattern that I wrote about in the past (found here). While it is possible to keep these patterns mutually exclusive, a balance should be made between the two so that the apprentice feels comfortable enough to share what they don’t know about different subjects with other teammates, as well as puts in the effort to work on it and learn more.

I have been able to relate to each of my discussed apprenticeship patterns in some way, and this pattern is no different. While I am aware that I have a lot of ground to cover in order to understand as much as I can about my company’s tech stack before the start date, it will be great to combat this by confronting this ignorance head-on with multiple learning strategies, mostly by reading more books and completing online coursework.

Thanks for reading! I hope to keep up with this blog as I continue self-learning throughout my professional career.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

For this weeks blog post I will be discussing the pattern known as Draw You Own Map. The context behind this one is that any given employer can offer only a limited subset of all possible career paths. The problem that would arise from this is that none of the career paths your employer provides actually fits you. The solution that would come from this situation would be to simply identify the next logical but ambitious next step in your career. Realize that it is not up to your employer, your career counselor or your professors to give you a hand up or decide your fate. Arriving at the next step and charting the course is a decision that ultimately comes down to your responsibility. You need to take the first step that is the most important part, even if that step doesn’t seem to significant. This first step should generate the momentum needed to help carry you toward your goal, no matter the terror you may feel. Try to define small, yet achievable steps allowing feedback that you can use to modify your road map which could also make it easier to get help from Kindred Spirits to achieve said goals. If the vision of which your employer sees of you and the one you see of yourself do not match your preferred accordance examine the opportunities to see if they’re heading in the desired direction. Instead follow other successful apprentice paths that share a resemblance to what you are going through. You should constantly reassess your map as your circumstances and values change. Sometimes the map will be in accordance with that of those around you, other times the map will require you to chart your own path through the wilderness. The only constant is that the map is yours, and you are free to redraw it at any time. A good action to take with this is that you could list three jobs that you think you could do while following the current one. Then begin to list three jobs each of those would lead to. Are these really the full range of desirable jobs for the next few years of your life? Ask yourself if this set of jobs is more representative of the range of career options you have before you and what places you want to take in this career. If you are unhappy with the list so far, repeating the exercise with different jobs, business or technology domains could help. Then repeat the exercise again to see where you would end up. Yet again this is something anyone who catches themselves in should do, as it will help you in the long run and in general.

From the blog CS@Worcester – Matt's Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

Today I read an article on baeldung.com about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

https://www.baeldung.com/java-hashmap

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

https://apiumhub.com/tech-blog-barcelona/top-benefits-of-unit-testing/

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. SDLC refers to whole process of software development. It defines and describes, each and every phase that contributed towards the development of the software.

What is the need for SDLC? Software Development is a tedious and complex job. As such, standard guidelines and established framework works well to carry out the development process in an effectively organized manner, repeatedly for each unique software product. Segregates the process of development life-cycle into separate phases, for their independent and smooth implementation. And to minimize failures in a software project. There are six phases of Software Development Life Cycle in a subsequent manner:

Requirement Gathering and Analysis: This phase visions the gathering of business requirements, followed by the analysis to study and validate the feasibility of these requirements for implementation in the system. Client and Project Manager are the key persons in this phase.

Design: blueprint/software design is prepared, based on inputs, provided from the requirement gathering and analysis phase. This blueprint helps in determining the requirements, needed in the development of software such as hardware and system requirements. The outcome of this phase is software design.

Implementation: The software design is implemented in this phase through coding and programming. This phase generally involves modules and codes. This phase is developed or working software product that acts as an input for the next stage.

Testing: developed software is handed over to the testing team, to evaluate and validate the functioning of the software product, in accordance with its pre-defined requirements and meet the end users’ expectations.

Deployment: After getting through testing phase, successfully, software product is ready to get deployed on customer’s side for its use

Maintenance: Maintenance phase is all about resolving defects or issues, occurring on the customer’s side, while using the software product. It ensures the fixing of all issues post the deployment of software product at the customer’s site.

This is the main steps of software review, it is a standard practice that empowers organizations to follow systematic & well-defined approach, for carrying out the development in an effective way, so as to achieve desired software product of highest quality. I find this blog helpful to follow and make sure product is going to the direction.  These steps need to apply to future product., as I have seen so many products got issues and have to call back.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.