Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

This pattern is about the conflict between creating software that is beautiful and creating software that is useful. While you may find opportunities to do something truly fantastic, a craftsman should always focus on delivering value to the customer rather than advancing his or her own self-interests. You must find a way to balance the conflicting demands of creating quality software while still putting your customer’s interests first. Software built for customers can be beautiful, but it must always be useful. Following this pattern means that you must be willing to sacrifice beauty in favor of utility when it becomes necessary.

A craftsman must also produce satisfactory quality even if he or she doesn’t feel like it. Craftsmen can’t wait for inspiration to strike before delivering a product. However, it’s not about simply doing what is fastest. A craft artifact should always display at least a minimal level of quality. This means you must always be making trade-offs between beauty and utility, and sometimes you will make the wrong trade-off. However, by fixing these mistakes, you will learn lessons that are impossible to learn in any other way.

I enjoyed reading this pattern. I have always found it interesting how programming is so technical yet can be incredibly artistic at the same time. This pattern brings up a very valid point that even though you may be able to create something artistic, utility will always be a priority when software is made for a customer. I think the following sentence from the pattern sums it up perfectly: “The things we build for customers can be beautiful, but must be useful.”

As a programmer, it is often tough to decide whether to code something that gets the job done but is ugly, or something that takes more time but is beautiful. It is important to analyze the purpose of what you’re creating to decide which direction you should head in. Reading this pattern made me think a lot about utility vs beauty in software development. I do agree with the main point that as a craftsman creating something for a customer, utility should be prioritized. Overall, I thought this was an interesting and useful 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.

For this weeks Blog Post I will discussing the pattern known as “Sustainable Motivations”. The Sustainable Motivation pattern is almost what it sounds like, where you require motivation to keep going. Anyone who knows programming knows that if a programmer is given the chance to do it there way, that is there biggest motivation. The context behind this is that you must develop your technical skills because of this you will find yourself working in a messy reality of specified projects for customers with different demands. The problem that arises is that when working in the real world trenches of projects you will find rigorous, tedious, exhausting, frustrating and constraining effects. The solution to this is that you need to ensure your motivations for craftsmanship will be able to adapt and survive through the Long Road ‘s (pattern) trials. For the most part there will be days and more that you love your job, getting paid to develop software and such. Where the work will just come natural to you without much effort. These days wont be ordinary days, because most programming jobs you will face tedious, vague definitions, and overly complex problems. You could even face some spotty leadership problems, difficult coworker personalities and other troubles. Because of this you may begin to question your commitment to the craft. When faced with these problems its almost imperative that you are aligned with the Long Road. Some examples could include you hating your programming job and are only motivated by the money. Where you value climbing the corporate ladder over honing the skills of your craft. But also are motivated by your reputation as a technologist, allowing you to survive and endure to the sun shines once more in your job. Another example could be you are motivated by your enjoyment of actual programming, where you then come up on a length of time where you cant find the love. But you are motivated by the money, and that programming is financially the best option right now, causing you to be motivated. All of these are good examples of how to be motivated but the best way to figure out yourself is to write down some motivations for you. Keeping this list somewhere safe where you can come upon it when times get tough. This pattern is something 96% of people can relate to, in almost any motivational situation and one I will see myself using down the road.

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

I have some very exciting news to share: I have recently accepted a software engineer position to start after graduation! I can’t wait to get started with this company, and I’m counting down the days until my first day there! My final interview involved talking with different members of the engineering team, and there was time allotted throughout the discussions for me to ask my own questions. There was one question that I asked everyone: “What is some advice that you would give a new graduate from a computer science program who is just getting started in the field?” There was one answer that came up the most, which was to not stop being eager to learn new things. This brings me to the apprenticeship pattern for this week, “Expand Your Bandwidth.”

This pattern exactly reflects the advice that I was given during my interview. Expand Your Bandwidth provides context with a possible problem of software developers’ knowledge potentially being focused to the type of work that they take part in on a daily basis. The solution is to simply begin absorbing more new knowledge at a faster, deeper rate. While the developer may find this process to be overwhelming, it is crucial that they can improve their ability to increase the level of learning new concepts and applying them to their own work. This process of expanding bandwidth includes actively seeking out knowledge, possibly through blogs, podcasts, courses, and contact with others who are as passionate about the topic as the apprentice is.

I couldn’t agree more with the suggestions and solutions that this pattern provides. I already have a list of several projects and practice exercises that I hope to complete throughout my career. I am so fortunate that the company that I will be working for seems to be ever-changing with the type of engineering work that is being done. I am confident that I will not run into the problem of work becoming stale or too routine. Nonetheless, I will be sure to continue to keep on taking in new information and building my field knowledge.

Thanks for reading!

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.

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 eighth individual Apprenticeship pattern I decided to blog about “Nurture Your Passion” pattern.

Summary

When you feel as if you have been hired into a software developer job that is asphyxiating your passion. Sometimes the best solution is to work on some side projects that you find interesting in your work place. If you can not find something interesting at work, then you can dedicate some time on the side building some “Breakable Toys”. Another approach is to ensure that you keep reading great literature in our field that will essentially help carry you through difficult times, such as ones that threatens your passion for the craft. You should also make sure that when joining an organization, that you are joining one with a career path that is related or will lead to your passion. This pattern also suggest us to make sure we “set clear boundaries that define the sort of environment you are willing to work in”. Understand that sometimes you run the risk that the boundaries you set might cause you to “get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong”.

My Reaction

This pattern helps you understand the importance of doing something you are passionate about. I agree with this idea because it make sense, we need to insure that we are nurturing our passion in order for us to remain happy and passionate about what we do. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that it has made me realize that whatever I do, I should make sure it is something I am passionate about and I am always trying to find ways to keep that passion for the craft alive.

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 this week’s blog I decided to write about the chapter “Record What You Learn” from our textbook of software apprenticeship patterns. The context of this pattern is that you learn the same lessons/ideas/things over and over and over again but you never seem to retain the information or you retain it for a short period of time and then forget it. I personally find this to happen to me every so often. Sometimes in class we will learn a lesson and I will not retain the information and when it comes time to use the information we learned or to prove our knowledge of the subject on a test or examination or project (some form of graded material) I will draw a blank. This is extremely frustrating because most of the time I know that we have learned this topic and that I was in that lecture but somehow someway I have forgotten what that thing we learned is. The problem being set up by the book is this; You don’t learn from history or historical mistakes and you are doomed to this repetition of failure due to your lack of discipline to take notes or record what you learn in a way that you wont forget it. The solution to this problem is rather simple; record what you have learned. Do it in some way that sticks with you – a way that makes sense for you. Two different people might have two different ways of remembering information. Maybe I can write notes down in a journal from lecture and be all set whereas my classmate (let’s call him Jim for the sake of conversation) can’t retain information from reviewing basic lecture notes. Maybe in order for the information to stick with Jim he needs to do it hands-on a few times. Once he does it himself physically he will remember how to do it because he knows he’s done it before and has the confidence he’s done it correct in the past. I hope to improve my retention of knowledge by finding more avenues to retain my information as opposed to just relying on lecture notes.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

This is the blog call “AI at Google: our principles” by Sundar Pichai, he is Chief Executive Officer of Google. In this blog he talked about the principles of AI at Google. The main purpose of AI is to help us, its potential to improve our lives. Beyond that, AI to help people tackle urgent problems. These benefits are why Google invests heavily in AI research and development and makes AI technologies widely available to others via our tools and open-source code. This is powerful tool that mean we must be responsibility to get this right. These are seven principles to guide Google’s work going forward. They want to set to concrete standards that will actively govern the research, product development and business decisions.

Objectives for AI applications: Advances in AI will have trans formative impacts in a wide range of fields, including healthcare, security, energy, transportation, manufacturing, and entertainment. They also take into account a broad range of social and economic factors and will proceed where they believe that the overall likely benefits substantially exceed the foreseeable risks and downsides. They recognize that distinguishing fair from unfair biases is not always simple, differs across cultures and societies. They will seek to avoid creating or reinforcing unfair bias. They will continue to develop and apply strong safety and security practices to avoid unintended results that create risks of harm, and will incorporate our privacy principles in the development and use of AI technologies. AI tools have the potential to unlock new realms of scientific research and knowledge in critical domains like biology, chemistry, medicine, and environmental sciences. They aspire to high standards of scientific excellence as we work to progress AI development.

And the applications that they will not design AI for, such as weapons or other technologies whose principal purpose or implementation is to cause or directly facilitate injury to people. Technologies that cause or are likely to cause overall harm or gather or use information for surveillance violating internationally accepted norms.

Look at AI for long term, this is the technology that will stay with us in the future. There are many voices about this subject. Although I don’t have all my trust and believe in company and operation. This is the future we cannot avoid, that’s mean we have to be careful and monitor it to goes right direction. We need to set regulations and principles, I am agreed with these principles by Google. But we need to make sure that they keep their words.

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.

Hello dear readers. In this blog post I would like to write about Refactoring, documentation and software framework. While explaining what they are I will try define why are they needed.

Refactoring is very used term in software development and has played a major role in the maintenance of software. Refactoring is one of the most self-evident processes, but it is surprisingly difficult to perform properly. In most cases, we deviate from strict refactoring and execute an approximation of the process; sometimes, things work out and we are left with cleaner code, but other times, we get snared, wondering where we went wrong. In either case, it is important to fully understand the importance and simplicity of barebones refactoring. Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations. The cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring — which allows you to gradually refactor a system over an extended period of time.

I also want to talk about documentation in this blog post. For a programmer reliable documentation is always needed. The presence of documentation helps keep track of all aspects of an application and it improves on the quality of a software product. Its main focuses are maintenance, development, and knowledge transfer to other programmers. Successful documentation will make information easily accessible, simplify the product, help new users learn quickly, provide a limited number of user entry points and help cut support costs. Documentation is usually focused on the following components that make up an application: business rules, troubleshooting, server environments, application installation, database/files and code deployment.

A software framework is a concrete platform where common code with general functionality can be specialized or overridden by developers or users. Frameworks take the form of libraries, where a well-defined API is reusable anywhere within the software under development. There exist some features that make a framework different form other library form. These features are: default behavior, inversion of control, extensibility, non-modifiable framework code.

I am attaching the following links that will help you have a better understanding of these concepts as these blog posts also provide examples.
https://refactoring.com/
https://medium.freecodecamp.org/why-documentation-matters-and-why-you-should-include-it-in-your-code-41ef62dd5c2f
https://www.quora.com/What-is-a-framework-in-programming

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