Practice pattern:
You will learn by making mistakes and it is inevitable. How would you purposely make mistakes while on the job? This pattern suggests in order to do so you must find a mentor and have them hand you a task you are not comfortable with and move forward from there. Practice your skills and make improvements each time.

George Leonard says, “The people we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—and because of this they do get better. And then to complete the circle, the better they get the more they enjoy performing the basic moves over and over again.” I couldn’t agree with this quote more. Over the years we have completed numerous projects and learned many methods on solving problems we encounter while completing these projects. Over time we developed the skills of analyzing the way we go about writing code and fixing bugs without even realizing it.

10,000 hours. That is the amount of time it takes an individual to truly ‘master’ something. Now will that be the case for us? I wouldn’t say so to an extent due to the changes in technology but basic skills like planning, designing, problem solving and debugging would definitely improve given we put hours into working on these skills. The author also makes a very good point when he says practice does not make perfect if you are practicing the wrong skill over and over. There must be changes to improve on that skill each time one practices it.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my first individual Apprenticeship pattern I have chosen A different road. I will first summarize the pattern and then I will state my reaction of this pattern.

A Different Road summarized

After using Draw Your Own Map pattern and creating the map which you been following. You come to realized that the map you drew has led you away from the long road or the road your on is no longer the one for you. Even if you decide to take a detour and do something different from software development your software craftsmanship will always benefit you no matter what. Also, if you do leave and then decide to come back you will be bringing back with you new set of skills that will be beneficial because it will be a fresh new set of eyes with a new prospective. Although sometimes when you take a break some software organization might make you jump over a few hoops and ask you over 21 question seeking justification from you for leaving for a while and then deciding to come back.  The key is to no worry because you are a software craftsmen and everything you have learned will always be with you. An action you should take whenever you no longer want to be a software developer or you’re wondering what would/should you do? This pattern suggestion for you is to list the kind of jobs you would like to do and then find people who matches your jobs list and who also loves their job. Once you found that person you are to “Ask them what they love about it and compare that to the things you love about software development.”

My Reaction

This pattern helps you not worry and be confident that the road although different is not entirely different. It also, reassure you that its okay to take a different road. I agree with this idea. I found that this idea is not just interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think I will work because it has made me less worry and more confident in knowing that I should not be afraid to go on different roads because as a software craftsman I will have a set of quality that will last a life time.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For the first week of apprenticeship pattern readings, I chose to read Draw Your Own Map. This pattern focuses on the career path that you chose for yourself based on your future or current employer. It tells a tale of how employers can only lead to a limited amount of career opportunities from your current job status. To work through this system, it is necessary to create a plan or road map for your future endeavors after moving forward from where you currently are. By lining up paths that can be available to you based on your current desires, knowledge, and expertise. It will be easier to find yourself in work that suits yourself the best instead of settling for less. These roadmaps should easily be updated to your current situation whenever you see fit. The overall idea behind this is that no one will be able to tell you how your career will end up, everything is up to you.

What I found interesting were the two short stories provided near the bottom of the pattern which clearly showed how reality will present itself. By providing evidence of how some apprentices feel about their current work experience, realizing what they actually wanted, and making a rather small but big step towards their dream career path is inspiring. It also goes to show that not all companies will have their interests aligned with their employees. Also, the action listed at the bottom is helpful to show that. By mapping out from each job choice and their potential benefits and paths that could open or give an overview of how you will end up later on. By not limiting your choices and have a willingness to redo the diagram until you are satisfied with the end result. There is a big possibility you will find happiness at the very end. Otherwise,  I enjoyed the fact that this pattern is straightforward with budding apprentices like myself. As quoted, “Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Every decision lies in us, by having a plan, you can reduce the amount of roadblocks you will hit along the way and make more informed choices in your career path.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance discusses how to begin mastering gaps in your skillset that are relevant to your daily work. It is important to fill these gaps in whichever ways work best for you. For example, some people like to read introductory material until they have a good understanding of the basics, while others like to dive right in and learn by breaking things. Working with peers who are trying to learn the same skills will help you make better progress. Once you have a decent understanding, you must decide whether it’s more useful to dig deeper or start filling other gaps in your knowledge. There can also be negative side effects created by this pattern. If you implement an extremely complex system just to learn how to do it you can burden your coworkers and introduce unnecessary costs. It is also important to not let your education get in the way of delivering a product. A software craftsman must be willing to put the wider interests of the community before personal benefit.

I think that this pattern is very relevant because everybody eventually runs into ideas or techniques that they know nothing about while everyone around them seems to have them mastered. Knowing how to pick which skills are worth learning and being able to learn effectively are important traits required for success. Being able to confront your ignorance is something that everybody (especially software developers) should be comfortable doing.

While I agree with everything written in this pattern, I don’t think there is anything exceptionally thought-provoking about it. It’s basically another way of saying that you should continue learning throughout your career. I believe that this is an important thing to do, but there was nothing written in this pattern that will change the way I work or think about the profession. Overall I think that the content in Confront Your Ignorance is agreeable but I did not take away any new ideas by reading it. I do look forward to reading some of the other patterns that were linked in this one as they seem like they have related ideas that expand on what was written about in this pattern.

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

This is the first Apprenticeship Patterns Blog Posts, I choose “The White Belt” in the second chapter, it represents maintaining a beginner’s mind regardless of your expertise. This is the second chapter of book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. The young philosopher- “Can’t you see the cup is already full and overflowing?”. The more experience you already have, the more effort you will need to put into “emptying your cup,” meaning the more you learned the more you have to “emptying your cup”. We must be humble, to able to thrive and get to next level.

To able to have new mindset new skills, sometimes we must go back “The White Belt” to unlearn what we had learn. I thought this pattern is interesting, this help us how to learn new thing and our attitude go about it. Once we learned language, specially first language, we have pride in out skill. Although it is good for you have confident, if you want to learn new thing. In our mindset, we will try to relate to what we had learn. Sometimes that make we learn new thing much harder. To solve this, “The White Belt” suggest that we find an opportunity to unlearn something, like as we go back and wear white bell as beginner. You have to learn new language, with new structure as you first time learning the language. I have to agree on this pattern on this, we need to learn new language and new functional way of building. I need full attention into learn first, once I understand fully then I could compare what I have learn. Although I don’t have a large library of language, this technique will help me in my profession. This also would help me in career, it is good to know someone who do thing different than you. They will make you understand and learn from them.

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.

This semester, I begin my software development Capstone, where I get to work with my peers on a semester long project. I will be making posts and reporting on my progress periodically throughout the semester on this blog, so keep up if you’re interested.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Today I am going to discuss one of the software architectures: Hexagonal Architecture. Its purpose is to reduce the amount of time we need to maintain and modify the code, in order to improve the maintainability. The more we increase the maintainability, the less work is required to achieve the tasks. This software architecture is not called “Hexagonal” for no reason. It is actually represented by a hexagon which is very flexible, and it allows you to make changes anytime, because of the independent layers. Each side of the hexagon has an input, an output, and a domain model. The three components of a Hexagonal Architecture are Domain Model, Ports, and Adapters.

Since the Domain is placed in the middle of the hexagon, it makes the Domain the center layer of it, which works independently in the architecture. Also, the Domain Model is used to maintain all the business data and the rules related to that data.

Port is the way to get to the business logic, or in other words, it serves as an entry point. There exist primary and secondary ports. The primary ports are functions that allow you to make changes, and they get called by the primary adapters. The Secondary ports are the interfaces created for the secondary adapters, but other than the primary ports they get called by the core logic.

Adapter serves as a bridge to connect the application and the maintenance that is needed for this application. A primary adapter is an essential adapter which connects the user and the core logic through a piece of code. It might be a unit test for the core logic. A secondary adapter is an implementation of the secondary port (interface).

I found this article interesting because the writer knows who the audience is and explains everything in detail. Also, the topic is related to our CS-343 class and this might be a good start to get into the world of software architecture. Nowadays, we are looking for simplicity and flexibility and this is what Hexagonal Architecture is about. According to the article that I chose the benefits of a Hexagonal Architecture are:

– Agnostic to the outside world

– Independent from external services

– Easier to test in isolation

– Replaceable Ports and Adapters

– High Maintainability

Apparently, Hexagonal Architecture makes the work easier and more efficient, based on this article: https://apiumhub.com/tech-blog-barcelona/hexagonal-architecture/.

Thank you for taking the time to read my blog!

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

In computer science, there are a lot of things we would normally take for granted, but it might not be so easy to program. Take time, for instance. If we wanted to create an app to calculate how many seconds ago a time and date was, it seems straightforward. Of course we would account things like leap days, but as I discovered, it quickly becomes a lot more complicated than that.

As Tom Scott explains in an episode of the YouTube Channel, “Computerphile,” a simple-sounding app like this can be jarringly complicated. For starters, to create this app for a worldwide audience, it seems reasonable to make it available in all time zones.

To adjust it for each time zone seems straightforward enough. All you have to do is take the Greenwich Mean Time and add or subtract hours based on the time zone that the user is in, right? Not quite.

Take daylight savings time, for instance. It varies from country to country when daylight savings starts, and then there are some states/countries that don’t go on daylight savings time. This is just the tip of the iceberg of how complicated it gets.

There are times when countries skip days when they cross the international time zone. Countries can often switch time zones several times, even within the same year. Some countries can be in the same area but in separate time zones, such  as Israelis and Pakistanis. Historically, we haven’t alway been on the same calendar. Russia only switched to the Gregorian calendar in the twentieth century, complicating matters even more. There are even more confounding historical absurdities, such as the year used to start on the 25th of March, bizarrely.

There is even a such thing as leap second, but leap seconds don’t exist in astronomical time, and the differentiation is important because of how they manufacture telescopes and such.

This video revealed just how easy it is to take a problem and not realize how much more vastly complicated it can be and to appreciate the people who came before me and worked out this absurdly complicated problem.

I found it interesting because it was a problem I never thought about before. It seems like an easy enough problem until you find out how complicated it really is. Like I say, it is easy to take something like this for granted, and this makes me appreciate how seamlessly most technology that uses programmable clocks runs. Now that I can understand how vast and complicated the problem is, I can appreciate those who came before me and did the hard work to get it right.

https://www.youtube.com/watch?v=-5wpm-gesOY

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

“Coding with Clarity”

Software developer Brandon Gregory’s two-part post in the blog “A List Apart”, describes key concepts every software designer should follow in order to make the functions in our programs not only functional, but also efficient and professionally designed.

The first piece of advice Gregory shares with us is to maintain what he calls the “single responsibility principle”. In other words, each function should only focus on one process. By following this rule, we not only limit the margin of error in our code, but also increase the flexibility of them. Having simple functions makes the program easier to read, modify, and detect errors.

The next concept the author illustrates Gregory described as “command-query separation”. This means that a function should either carry out some work, or answer a question and return some data. The key advice is to not combine the two types. A function should either perform an action or answer a question, never both. If a program needed to both change data and return information, it would be better to write two separate functions to handle the tasks.

Finally, Gregory delves into the details of “loose coupling” and “high cohesion” in code. What he means by “loose coupling” is that each subsection of a program should be as independent as possible, not relying on the other parts of the code to inform a function. Similarly, the author advises us to stick to “high cohesion”, meaning that each object in a program should only contain data and functions that are relevant to that object.

Personally, I very much agree with and appreciate Gregory’s perspective and advice on writing clean code. In his advice, he very effectively clarified a lot of the concepts that I’ve trouble with implementing in my previous programs. One of my favorite lines in this post was “Large functions are where classes go to hide.” I found this quote very useful because it helps solidify the process of abstraction. From this point on, if I’m writing a function that becomes too unruly or long or complicated, I will ask myself “would this large function be better off as an independent class?” I definitely learned a lot about good practices in simplifying functions, and I will reflect on from now on when developing programs.

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